Teams Direct Routing Emergency Calls Failing

[kmanikowski]

We have a fully working Teams Direct Routing integration with 3CX. Regular inbound and outbound calls are functioning correctly. However, emergency calls (911/933) from the Teams client are failing with a 415 Unsupported Media Type error returned by 3CX.

- 3CX V20.0.8.1131 hosted on Linux

WHAT HAPPENS

When a Teams user dials 933, Microsoft Teams identifies the call type as ByotOutEmergency and sends a SIP INVITE containing Content-Type: multipart/mixed with both SDP audio negotiation and PIDF-LO location data in the body. 3CX returns a 415 Unsupported Media Type response, rejecting the call.


MICROSOFT TEAMS ADMIN PORTAL DIAGNOSTICS CONFIRM

- Voice Route Matched: 3CX Voice Route

- Call Type: ByotOutEmergency

- Customer SBC Matched

- Final result: 415 Unsupported Media Type

- Microsoft subcode: 560415



WHAT WE HAVE CONFIRMED

1. Setting PidfLoSupported = False on the Teams gateway does not prevent Teams from sending PIDF-LO on emergency calls. Microsoft forces PIDF-LO on ByotOutEmergency call types regardless of gateway settings.

2. When the call accidentally connects without PIDF-LO, it routes to the national PSAP registry instead of the correct local PSAP because no location data is delivered to Bandwidth.

3. All non-emergency calls work correctly — the issue is isolated to emergency calls only.

4. PidfLoSupported is currently set to True on the gateway as this is the correct configuration for E911.



Can 3CX be configured to:

1. Accept multipart/mixed content type in SIP INVITEs on the Teams trunk for emergency calls

2. Pass through the PIDF-LO location data to the outbound Bandwidth ESIP trunk so Bandwidth can route to the correct local PSAP

3. If PIDF-LO passthrough is not supported, what is the recommended approach for E911 with Bandwidth when using Teams Direct Routing?

 

[N_G]

3CX currently does not support SIP INVITEs with Content-Type: multipart/mixed for Teams Direct Routing. The PBX only parses and accepts application/sdp as the primary content type for INVITEs, and will reject requests with multipart bodies (like those containing PIDF-LO location information for E911) with a 415 Unsupported Media Type. There is no configurable option in 3CX to accept, parse, or pass through PIDF-LO location data from Teams. The system will not forward multipart bodies or location XML to downstream SIP trunks, including Bandwidth.

For proper E911 and local PSAP routing with Bandwidth on Teams Direct Routing, you cannot currently rely on Teams sending PIDF-LO data through 3CX. The industry workaround is to route Teams emergency calls directly to Bandwidth or another E911-enabled SBC that supports PIDF-LO, bypassing 3CX for those emergency scenarios. Alternatively, configure static location routing in Bandwidth or Teams, but this will send all calls to the national PSAP when no dynamic location data is provided.

If E911 compliance and proper local PSAP routing is a requirement, do not use 3CX as the intermediary for Teams emergency calls. Instead, route those calls via a certified SBC or native SIP trunk that can handle PIDF-LO as Microsoft sends it.

---

Official 3CX Documentation:

• Configuring Microsoft Teams Direct Routing
• Microsoft Teams Integration FAQs

Relevant Community Threads:

• Teams Integration Outbound Calling

 

[N_G]

To add to this, we are looking whether we can support this in a future release

UPDATE: We are making progress on this

 

[N_G]

We are testing this for implementation in update 10....