While for various reasons I believe that the efforts to enforce E911 requirements on Voice over IP phones are bogus and largely designed to make it harder for smaller players to compete with established companies, there is a legitimate need for ways to give your location to emergency services.

To protect privacy, I suggest that this be done in the endpoints. To assist this, I would propose a set of option extensions to the DHCP protocol to tell an endpoint what the server knows about its location, including address, zip and even what emergency contact center to use. This would start with RFC3825 for geolocation, and move on to other features. The endpoint device, when calling 911 or other emergency services, could include this information in the SIP invite, or provide it on request.

For those who don't know, DHCP is the system which lets a computer connect to an ethernet and ask for an IP address as well as important local network information (such as the addresses of routers, name servers, domain names etc.) Some DHCP servers know exactly who the client device is and effectively act as the client's memory. Some just give the next available address and return information about the local network area.

For example, most people with home networks, and almost all of them who use Voice over IP services like Vonage have a local network with its own DHCP server, built into the home-router they use. That home router could be told the address of the home, and all devices, including VoIP phones, could learn it. For companies, it is the same.

DHCP is also used for ISPs to give addresses to DSL and Cable modem customers who hook up to the internet without a home gateway because they have only one computer. That's pretty rare for VoIP users. In these cases they may or may not know the street address of the computer. DHCP is also very common for people who connect to wireless access points. The AP in a Starbucks could easily tell your device the address of the Starbucks.

As noted, we could start by the device fetching this address and forwarding it on with emergency calls, but not doing so for regular calls. This puts privacy control in the hands of the user, where it should be.

However, we could do even more than just give location as in rfc3825. The DHCP server could publish the direct contact information for the local area for police, fire, ambulance or general emergencies. They could simply include the contact number of a PSAP (Public Service Access Point, the gateway to emergency services) for the location, or in a corporate setting, might direct emergency calls to the corporate security desk, with the PSAP/911 as a fall-back. (There should be laws however about use of such features and protection of privacy. Network owners can already reroute any traffic but we want it to be clear how this might be done.)
The flaw in the E911/VoIP rules it that it assumes that because something looks like a telephone, it must be regulated like one. We want emergency services, and we want to make phone calls to them, but we might also just like panic buttons that summon the police or other things not yet invented.

If we build in a smart-endpoint regime, where the endpoints have a way to learn their location and tell the emergency services, regardless of what protocol they use or what the application looks like, there's the answer.

Of course, older equipment would not know how to use this new information. So the VoIP companies providing 911 service would need a fallback method for people who can't set the new system up. This is what they are building now, but they don't plan for it to be the fallback, they expect it to be the main operation. But it's bad from a privacy standpoint, and probably less accurate too, with no ability to roam.

Note for security reasons we would also like a way to digitally sign DHCP results to know they can be trusted.

A recent commenter suggested the use of DNS LOC records. Aside from the fact that these are public, your domain and your network are not the same, even though they are often related. One might be at a wifi hotspot but still be using the domain and DNS servers of your "home," especially if behind a VPN. (Mind you if you are using a VPN you must understand you have two connected networks with possibly two DHCP addresses, and one is the local one.) Ideally you would do your (secure) VoIP over the local network unless calling somebody also inside the VPN, as using the VPN would degrade the call a lot.

Another comment brings up the troublesome point that spyware could make troublesome use of a locally available address information. However, it's hard to see a system that would allow convenient roaming and not allow spyware to pretend to be a phone asking for its address, which doesn't also create a public mapping of IPs to addresses. It may make sense to offer the DHCP street address only where people like to roam, and at residences to enter it permanently in the phones. Or, while it's messy, the DHCP server could contain the address encrypted with a public key available only to emergency services.

This key would probably be compromised over time, but the emergency services could just routinely issue new ones. They would continue to decrypt the old ones of course, but users concerned over spyware could switch to any of the new ones.