No. ECG is not a law firm, and we don't give legal advice. We do work with external telecom legal consultants, including firms like Marashlian & Donahue, the COMMlaw Group, and can connect you to those attorneys when you need legal advice on your specific situation.

What we provide is technical engineering, network audits, compliance reviews against published rules, testing, and documentation. Legal interpretation and legal advice come from attorneys.

Both enterprises (which operate a business phone system - a "Multi-Line Telephone System", MLTS) and service providers have obligations. 

Federal fines can run up to $10,000 plus $500 per day for ongoing non-compliance.

But the real cost is both safety and liability. If somebody suffers or dies because they couldn't reach 911 from your phone system, or because dispatch went to the wrong location, you face  both the moral guilt and the civil liability charges -- along with reputational damage.   Complying with these laws isn't about the fines. It's about doing the right thing for people on your network. 

Microsoft Teams uses a Location Information Service (LIS) that you populate as an administrator. You map WiFi BSSIDs, Ethernet switch ports, IP subnets, and wireless access points to civic addresses with floor, room, and suite information.

Whenever a user makes a 911 call, the Teams client queries the LIS with network identifiers it can detect, and the LIS returns a location encoded as PIDF-LO and inserted into SIP signaling.

You're responsible for building that database accurately, keeping it updated as your network changes, handling remote workers and nomadic devices, setting up central notification, and testing end-to-end. Most enterprises skip that last part.

 A registered location is the address the user gave you when they signed up – basically, their home or office address on file. That's the worst-case minimum.

A dispatchable location is where the user actually is at the time of the call, including floor, room, suite, and enough detail for first responders to find them inside the building.

The law is moving toward an automatic, dispatchable location for all VoIP, but you generally still need a registered location and must provide users with an easy way to update it from the CPE itself. 

This is a gray area and not entirely clear. Some interpretations say that if you're providing SIP trunking and somebody hangs an MLTS off of it, the MLTS is what has to comply, not the trunk. However, it's not always that clean.

If you're a service provider offering SIP trunking and you can provide central notification or related capabilities, you should consult a telecom attorney about your specific situation. We can help you think through the technical aspects and connect you with legal counsel for interpretation. 

RFC 6442 defines a Geolocation header field for SIP that carries either the location itself (location-by-value, typically as PIDF-LO XML) or a reference to a location database (location-by-reference, as SIP or HTTP URI). It also defines a Geolocation-Error header and a 424 response code for an unusable location.

The rule is that intermediary SBCs forwarding location values must not modify them. Your SBC should pass the Geolocation header and PIDF-LO body parts through unchanged when not originating the location.

We've seen SBCs that strip the Geolocation header in the name of header normalization, which breaks E911 in ways that are hard to debug.

Emergency location technology varies by location, but in much of the world similar requirements help keep people safe. 

We focus primarily on US regulations, where deep, specific regulatory work is required.

Yes. We can prepare technical documentation, packet captures, network diagrams, location database snapshots, and testing records that demonstrate what your system was actually doing at the time of an incident.

We work alongside your legal counsel to ensure the technical narrative aligns with legal strategy. If you don't have telecom legal counsel, we can connect you with attorneys who do this work regularly.