# E911 test calls and validation

Canonical: https://warmtransfer.net/knowledge/e911-testing-procedures

Last verified: 2026-09-25

Emergency test calls allow administrators to validate that multi-line telephone systems (MLTS) and unified communications platforms route emergency traffic with accurate calling party and location data[^22][^33]. Testing mechanisms include automated 933 test services, standardized test SIP Uniform Resource Names (URNs), and coordinated live 911 calls[^35][^31][^19].

## Regulatory requirements for MLTS testing and validation

Under 47 CFR 9.16(b)(1), an MLTS must be configured and installed so that callers can initiate a 911 call directly from any station without dialing an additional prefix, code, digit, or post-fix[^22]. Additionally, 47 CFR 9.16(b)(2) mandates that MLTS notification must be initiated contemporaneously with the 911 call, must not delay the call, and must be delivered to a location where someone is likely to see or hear it[^27]. MLTS notification is defined under 47 CFR 9.3 as a feature capable of sending notice to a central location at the facility or to another person or organization regardless of location[^25].

Federal regulations also govern location delivery:
* **Dispatchable location**: 47 CFR 9.3 defines dispatchable location as the validated street address of the caller plus additional information, such as suite or apartment, necessary to adequately identify the caller's location[^24]. 
* **Compliance deadlines**: 47 CFR 9.16(b)(3) required MLTS dispatchable location to accompany 911 calls from on-premises fixed devices by January 6, 2021, and from on-premises non-fixed and off-premises devices by January 6, 2022[^23].
* **Automatic Location Information (ALI)**: 47 CFR 9.3 defines ALI as information transmitted during E911 service delivery that permits emergency service providers to identify the caller's geographic location[^21].

## Automated 933 test calling

Automated 933 dialing allows administrators and endpoints to verify provisioned addresses and line identifications without routing calls directly to emergency dispatchers[^35][^9].

### Microsoft Teams

In Microsoft Teams, users with Calling Plan, Operator Connect, or Teams Phone Mobile in the United States or Canada can dial 933 to validate emergency calling configurations[^33]. The Teams 933 test number routes to an automated bot that reads back the caller's calling line ID, the emergency address or location, and whether an actual emergency call would route automatically to the Public Safety Answering Point (PSAP) or be screened first[^35].

When configuring Teams emergency calling:
* Emergency numbers such as 911 and 933 are predefined for Calling Plan and Operator Connect, whereas Direct Routing administrators must manually define them in an emergency call routing policy[^45].
* Microsoft directs Direct Routing customers in the United States to coordinate with their Emergency Routing Service Provider (ERSP) for a test service rather than offering a predefined Microsoft 933 bot[^39]. Microsoft notes that some ERSPs in the United States offer an emergency calling test bot[^41].
* Teams Direct Routing requires the Session Border Controller (SBC) PSTN gateway setting `PidfloSupported` to be set to true to insert location data into the outgoing SIP INVITE[^40].
* Extended notifications defined for 933 do not send alerts to the security desk because 933 is a test number[^34].
* In the United States, an emergency call placed by a Calling Plan user who is not at a tenant-defined dynamic emergency location is screened by a national call center prior to transfer to the PSAP[^48].
* In Canada, all Calling Plan emergency calls are screened nationally before transfer to the PSAP, even when a dynamic location is acquired[^37].

### Webex Calling

In Webex Calling enhanced emergency calling with RedSky, dialing 933 connects the caller to an interactive voice response (IVR) system that announces the caller ID and the currently known address for the device[^52]. Cisco instructs administrators to place 933 test calls to confirm proper routing before enabling full 911 routing for a location[^51]. Webex Calling 933 test calls can be placed from all endpoints assigned to the location, including HELD-capable devices, soft phones and non-HELD devices[^50].

### Bandwidth carrier services

Bandwidth structures static E911 onboarding as a 3-step sequence: provision a 911 endpoint, make a 933 call, and then complete live 911 testing[^19]. Customers reach the 933 service by sending a SIP INVITE addressed to 933 instead of 911[^5]. 

Bandwidth's 933 service reads back the telephone number and address provisioned in the 911 Access portal[^9]. For Teams Direct Routing using Bandwidth Dynamic E911, administrators enable 933 testing by adding 933 to the Teams Emergency Call Routing Policy; the read-back then plays the provisioned phone number, user name, civic address, and place[^17][^16].

Operational requirements for Bandwidth 933 testing include:
* **Scope**: Bandwidth positions 933 as a partial test validating basic interoperability to the Bandwidth SBC, one-way audio, and a correctly provisioned endpoint[^7]. It is a courtesy service rather than a full address verification service, and an abbreviated address read-back can still represent a successful test[^6].
* **Rate limits**: Bandwidth asks customers to limit test calls to 1 call per minute[^8].
* **Error codes**: Enhancements effective February 16, 2023, provide dynamic messages containing error codes and failure reasons when a test is unsuccessful[^4].

## Location validation and network policy behavior

Dynamic location matching requires administrative validation before deployment[^36]. A Teams emergency address must be marked validated before assignment to a user or network identifier, and addresses generated through the Teams admin center map search validate automatically[^36].

Location resolution within Microsoft Teams follows specific behaviors:
* **Match priority**: When a Teams client resolves its location against the Location Information Service (LIS), the first match is selected in the order of wireless access point, Ethernet switch port, Ethernet switch, and then subnet[^42].
* **Verification**: A successful network-site match does not confirm that the client acquired an emergency address; Microsoft instructs administrators to place test emergency calls to verify the returned location rather than relying on a site match[^47].
* **Propagation time**: Modifications to Teams network settings, including new addresses or network identifiers, can take up to 4 hours to propagate to clients[^43].
* **Client support**: The Teams web client does not support dynamic emergency calling or security desk notifications[^49].

Security desk notifications in Teams adhere to policy precedence: a policy assigned to the network site where the client is located applies first; otherwise, the user's assigned policy applies[^46]. A client that obtains no emergency calling policy has security desk notifications disabled[^46]. Supported notification modes are chat only, conferenced in and muted, or conferenced in muted with unmute capabilities; external PSTN numbers may be conferenced in but cannot unmute[^44]. If any extended notification uses a conferenced-in mode, a default entry without a dial string must be configured with a conferenced-in mode and at least 1 user, group, or PSTN number[^38].

## Live 911 testing procedures

Bandwidth recommends placing test calls from every 911-provisioned IP address at initial provisioning and after any network change[^18]. For onboarding, Bandwidth's live 911 test procedure places 1 live call to the primary SBC and a second live call to the failover route SBC[^13]. However, Bandwidth does not recommend live 911 calls for routine operational updates (such as adding a user to a Teams tenant) due to the disruption caused to PSAP operations[^11].

When placing live 911 test calls, Bandwidth establishes the following protocols:
* **Advance coordination**: Customers must call the PSAP's 10-digit non-emergency number to inform the 911 operator in advance that test calls will occur[^14].
* **Call conduct**: Testers must state immediately upon answer that the call is a test and not an emergency[^15]. Testers must not hang up, but must confirm the call taker has time to verify the caller information[^10].
* **Timing**: Live calls should be placed during off-peak windows, such as 6:00 a.m. rather than between 4:00 and 6:00 p.m.[^12]. Testers should avoid 6:00–9:00 a.m., 4:00–7:00 p.m., and the local lunch hour in the caller's time zone[^20].

## IETF RFC 6881 test architecture

RFC 6881 defines standardized automated emergency test call architecture using SIP INVITE requests directed to service URNs prefixed with `test.`, such as `urn:service:test.sos.fire`[^31]. An answering PSAP returns a `200` response if recognized, `404` if the URN is not recognized or the PSAP lacks testing support, or `486` if the test service is busy[^31].

RFC 6881 outlines the following behavior:
* **Test payload**: An answering PSAP MAY return a `text/plain` body specifying the PSAP identity, the requested service, and the reported location[^32].
* **Cadence**: User agents SHOULD execute a full test call with media loopback roughly every 30 days and following an IP address change after a disconnect[^30].
* **Boot restrictions**: User agents MUST NOT initiate a test call immediately upon booting, and must wait a random duration if an IP address changes after boot[^28].
* **Refusal**: PSAPs are permitted to refuse repeated test attempts from a single device within a short window, signaling refusal using SIP response codes `486` or `488`[^29].

## See also

* [Teams emergency calling and location policies](https://warmtransfer.net/knowledge/teams-emergency-calling)
* [Webex Calling enhanced emergency calling](https://warmtransfer.net/knowledge/webex-calling-emergency-calling)
* [Setting up Webex Calling emergency calling with RedSky](https://warmtransfer.net/knowledge/webex-calling-redsky-e911-setup)
* [Troubleshooting Teams Direct Routing](https://warmtransfer.net/knowledge/teams-direct-routing-troubleshooting)
* [Dispatchable location and nomadic user handling](https://warmtransfer.net/knowledge/dispatchable-location)
* [US emergency calling regulatory requirements](https://warmtransfer.net/knowledge/e911-us-regulatory)
* [Meeting Kari's Law and RAY BAUM's Act on an enterprise phone system](https://warmtransfer.net/knowledge/kari-ray-baum-compliance)
* [NG911 and i3 architecture transition](https://warmtransfer.net/knowledge/ng911-transition)
* [Voice for remote and home workers](https://warmtransfer.net/knowledge/remote-worker-voice)
* [Cisco Emergency Responder](https://warmtransfer.net/knowledge/cucm-emergency-responder)
* [Cisco Emergency Responder setup](https://warmtransfer.net/knowledge/cisco-emergency-responder-setup)
* [RedSky E911 for enterprise UC](https://warmtransfer.net/knowledge/redsky-e911)
* [Intrado enterprise 911 routing services](https://warmtransfer.net/knowledge/intrado-enterprise-911)
* [SRST on Cisco IOS XE](https://warmtransfer.net/knowledge/srst-configuration)
* [Planning a contact center platform migration](https://warmtransfer.net/knowledge/contact-center-migration-planning)
* [International emergency calling requirements](https://warmtransfer.net/knowledge/emergency-calling-international)

## Applicability

Applies to: Microsoft Teams Phone, Microsoft Teams Phone Direct Routing, Microsoft Teams Phone with Calling Plans, Cisco Webex Calling, Bandwidth 911 Access, Bandwidth Dynamic E911 for Microsoft Teams, Bandwidth 933 test service, IETF SIP emergency calling, FCC Multi-line telephone systems, and FCC 911 requirements. Deployments: on-premises, hybrid, multi-tenant, carrier-service, and standard. Sources checked 2026-09-25. The 933 test call features described for Microsoft Teams apply to the United States and Canada[^33]. Dynamic emergency call screening policies differentiate between the United States and Canada for Calling Plan users[^48][^37]. Webex Calling and Bandwidth test procedures apply to the United States[^52][^19]. Federal Communications Commission MLTS regulations under 47 CFR apply within the United States[^22]. Bandwidth dynamic failure error messages reflect enhancements announced as effective February 16, 2023[^4].

## What remains uncertain

Whether additional carrier test services support dynamic failure codes outside of Bandwidth is not covered by the sources below. Specific PSAP response times or regional policies regarding live test call acceptance are not covered by the sources below.

## Sources

[^1]: 933 behaves as an industry test-number convention implemented by 911 service providers (Microsoft, RedSky for Webex, Bandwidth), with read-back contents that differ by provider, rather than as a number defined by the FCC MLTS rules (inferred). Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Test emergency calling; compared with cisco-help-av6oo3 and Bandwidth 933 sections and 47 CFR 9.16. Checked 2026-09-25.
[^2]: A 933 read-back confirms what the 911 service provider holds for the caller, but because 933 is answered by a provider IVR and not a PSAP it does not show what the PSAP's ALI display receives; only a coordinated live 911 call shows that (inferred). Source: [911 failover and interoperability testing](https://www.bandwidth.com/support/en/articles/12823287-911-failover-and-interoperability-testing), 933 service section (partial 911 testing), read with the static guide's three-step order. Checked 2026-09-25.
[^3]: Bandwidth's own pages disagree on whether 6 a.m. is a good time for a live 911 test call: the static E911 guide offers 6:00 a.m. as an off-hours example while the tips article lists 6-9 a.m. as a peak period to avoid (disputed). Source: [Tips for a successful 911 test call](https://www.bandwidth.com/support/en/articles/12823288-tips-for-a-successful-911-test-call), Tip 2, compared with bandwidth-support-static-voip-e911-testing-guide Live 911 testing section. Checked 2026-09-25.
[^4]: Bandwidth announced 933 enhancements, stated as effective February 16, 2023, that include dynamic messages giving failure reasons and error codes when a test is unsuccessful. Source: [Upcoming enhancements to 933 testing](https://www.bandwidth.com/support/en/articles/12822838-upcoming-enhancements-to-933-testing), Enhancements bullet list. Checked 2026-09-25.
[^5]: To reach Bandwidth's 933 service a customer sends the SIP INVITE to 933 instead of 911. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), 933 service section. Checked 2026-09-25.
[^6]: Bandwidth describes 933 as a courtesy service not meant as a full address verification service, and an abbreviated read-back of the address can still indicate a successful test. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), 933 service section, courtesy-service note and Denver address example. Checked 2026-09-25.
[^7]: Bandwidth describes 933 as partial 911 testing that validates a correctly provisioned endpoint, basic interoperability to the Bandwidth SBC and one-way audio. Source: [911 failover and interoperability testing](https://www.bandwidth.com/support/en/articles/12823287-911-failover-and-interoperability-testing), 933 service section. Checked 2026-09-25.
[^8]: Bandwidth asks customers to limit 933 test calls to one call per minute. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), 933 service section. Checked 2026-09-25.
[^9]: Bandwidth's 933 service reads back the telephone number and address provisioned for the endpoint in the 911 Access portal. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), 933 service section. Checked 2026-09-25.
[^10]: Bandwidth advises not hanging up when a live 911 test call connects, but telling the call taker it is a test and asking whether they have a few moments to verify the caller's information. Source: [Tips for a successful 911 test call](https://www.bandwidth.com/support/en/articles/12823288-tips-for-a-successful-911-test-call), Tip 5. Checked 2026-09-25.
[^11]: Bandwidth does not recommend live 911 calls for later routine tests such as adding a new user to a Teams tenant, because live 911 calls disrupt normal PSAP operations. Source: [Dynamic E911 for Microsoft Teams integration and testing guide](https://www.bandwidth.com/support/en/articles/12822946-dynamic-e911-for-microsoft-teams-integration-and-testing-guide), Live 911 testing section. Checked 2026-09-25.
[^12]: Bandwidth's static guide recommends live 911 test calls in off-hours such as 6:00 a.m. rather than between 4:00 and 6:00 p.m. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Live 911 testing section. Checked 2026-09-25.
[^13]: Bandwidth's onboarding live 911 testing places one live call to the primary designated SBC and a second to the SBC designated for the failover route. Source: [Dynamic E911 for Microsoft Teams integration and testing guide](https://www.bandwidth.com/support/en/articles/12822946-dynamic-e911-for-microsoft-teams-integration-and-testing-guide), Live 911 testing section. Checked 2026-09-25.
[^14]: Before live 911 test calls, Bandwidth tells customers to call the PSAP's 10-digit non-emergency number and advise the 911 operator in advance that test calls will be made. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Live 911 testing section. Checked 2026-09-25.
[^15]: Bandwidth's guide tells the tester to state immediately on answer that the call is not an emergency and is a test. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Live 911 testing section. Checked 2026-09-25.
[^16]: Bandwidth's 933 read-back for Teams plays the provisioned emergency location including phone number, user name, civic address and place. Source: [Dynamic E911 for Microsoft Teams integration and testing guide](https://www.bandwidth.com/support/en/articles/12822946-dynamic-e911-for-microsoft-teams-integration-and-testing-guide), 933 testing section. Checked 2026-09-25.
[^17]: For Teams Direct Routing with Bandwidth Dynamic E911, 933 testing is enabled by adding 933 to the Teams Emergency Call Routing Policy. Source: [Dynamic E911 for Microsoft Teams integration and testing guide](https://www.bandwidth.com/support/en/articles/12822946-dynamic-e911-for-microsoft-teams-integration-and-testing-guide), 933 testing section. Checked 2026-09-25.
[^18]: Bandwidth strongly recommends placing test calls from every 911-provisioned IP address, both at initial provisioning and after any change. Source: [911 failover and interoperability testing](https://www.bandwidth.com/support/en/articles/12823287-911-failover-and-interoperability-testing), Failover testing section. Checked 2026-09-25.
[^19]: Bandwidth's static E911 onboarding is a three-step sequence: provision a 911 endpoint, make a 933 call, then complete live 911 testing. Source: [E911 for Static VoIP integration & testing guide](https://www.bandwidth.com/support/en/articles/12822950-e911-for-static-voip-integration-testing-guide), Testing section, three-step process statement. Checked 2026-09-25.
[^20]: Bandwidth's 911 test call tips say to avoid 6-9 a.m., 4-7 p.m. and the lunch hour in the caller's time zone. Source: [Tips for a successful 911 test call](https://www.bandwidth.com/support/en/articles/12823288-tips-for-a-successful-911-test-call), Tip 2. Checked 2026-09-25.
[^21]: 47 CFR 9.3 defines Automatic Location Information as information transmitted while providing E911 service that permits emergency service providers to identify the calling party's geographic location. Source: [47 CFR § 9.3 - Definitions (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.3), 47 CFR 9.3, Automatic Location Information (ALI). Checked 2026-09-25.
[^22]: 47 CFR 9.16(b)(1) requires an MLTS to be installed and configured so a user can directly initiate a 911 call from any station without dialing an additional digit, code, prefix or post-fix. Source: [47 CFR § 9.16 - General obligations for MLTS (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.16), 47 CFR 9.16(b)(1). Checked 2026-09-25.
[^23]: 47 CFR 9.16(b)(3) requires MLTS dispatchable location to be conveyed with 911 calls from on-premises fixed devices by January 6, 2021, and from on-premises non-fixed and off-premises devices by January 6, 2022. Source: [47 CFR § 9.16 - General obligations for MLTS (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.16), 47 CFR 9.16(b)(3). Checked 2026-09-25.
[^24]: 47 CFR 9.3 defines dispatchable location as the validated street address of the calling party plus additional information such as suite or apartment needed to adequately identify the caller's location. Source: [47 CFR § 9.3 - Definitions (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.3), 47 CFR 9.3, Dispatchable location. Checked 2026-09-25.
[^25]: 47 CFR 9.3 defines MLTS notification as an MLTS feature that can send notice to a central location at the facility or to another person or organization regardless of location. Source: [47 CFR § 9.3 - Definitions (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.3), 47 CFR 9.3, MLTS notification. Checked 2026-09-25.
[^26]: The text of 47 CFR 9.16 as read for this packet contains no requirement to perform or document 911 or 933 test calls, so test cadence and records are set by vendor, carrier or state guidance rather than this federal section (inferred). Source: [47 CFR § 9.16 - General obligations for MLTS (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.16), 47 CFR 9.16, whole section. Checked 2026-09-25.
[^27]: 47 CFR 9.16(b)(2) requires MLTS notification to be initiated contemporaneously with the 911 call, not to delay the call, and to go to a location where someone is likely to see or hear it. Source: [47 CFR § 9.16 - General obligations for MLTS (Cornell LII republication)](https://www.law.cornell.edu/cfr/text/47/9.16), 47 CFR 9.16(b)(2). Checked 2026-09-25.
[^28]: RFC 6881 says user agents MUST NOT place a test call immediately after booting and should wait a random time if the IP address changes after boot. Source: [RFC 6881 (BCP 181): Best Current Practice for Communications Services in Support of Emergency Calling](https://www.rfc-editor.org/rfc/rfc6881.html), Section 15, ED-81. Checked 2026-09-25.
[^29]: RFC 6881 allows PSAPs to refuse repeated test requests from the same device in a short period, signalling refusal with 486 or 488. Source: [RFC 6881 (BCP 181): Best Current Practice for Communications Services in Support of Emergency Calling](https://www.rfc-editor.org/rfc/rfc6881.html), Section 15, ED-82. Checked 2026-09-25.
[^30]: RFC 6881 says user agents SHOULD run a full test call including media loopback after an IP address change following a disconnect, and approximately every 30 days. Source: [RFC 6881 (BCP 181): Best Current Practice for Communications Services in Support of Emergency Calling](https://www.rfc-editor.org/rfc/rfc6881.html), Section 15, ED-80. Checked 2026-09-25.
[^31]: RFC 6881 defines automated emergency test calls as SIP INVITEs to a service URN beginning with test., such as urn:service:test.sos.fire, answered 200 if recognized, 404 if not or if the PSAP does not support testing, and 486 if the test service is busy. Source: [RFC 6881 (BCP 181): Best Current Practice for Communications Services in Support of Emergency Calling](https://www.rfc-editor.org/rfc/rfc6881.html), Section 15, ED-77. Checked 2026-09-25.
[^32]: Under RFC 6881 a PSAP answering a test call MAY return a text/plain body identifying the PSAP, the requested service and the location reported. Source: [RFC 6881 (BCP 181): Best Current Practice for Communications Services in Support of Emergency Calling](https://www.rfc-editor.org/rfc/rfc6881.html), Section 15, ED-78. Checked 2026-09-25.
[^33]: In Microsoft Teams, Calling Plan, Operator Connect and Teams Phone Mobile users in the United States or Canada can dial the predefined test emergency number 933 to validate their emergency calling configuration. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure dynamic emergency calling > Test emergency calling, first bullet. Checked 2026-09-25.
[^34]: A Teams emergency calling policy can define an extended notification for 933, and because it is a test number no notifications are sent to the security desk for those calls. Source: [Configure security desk notifications](https://learn.microsoft.com/en-us/microsoftteams/emergency-calling-security-desk-notifications), Configure extended notifications, second bullet. Checked 2026-09-25.
[^35]: The Teams 933 test number routes to a bot that echoes back the caller's calling line ID, the emergency address or location, and whether a real emergency call would be automatically routed to the PSAP or screened first. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure dynamic emergency calling > Test emergency calling, first bullet. Checked 2026-09-25.
[^36]: A Teams emergency address must be marked validated before it can be assigned to a user or network identifier, and addresses created via the Teams admin center map search are validated automatically. Source: [Plan and manage emergency calling](https://learn.microsoft.com/en-us/microsoftteams/what-are-emergency-locations-addresses-and-call-routing), Plan and manage emergency calling > Emergency address validation. Checked 2026-09-25.
[^37]: For Teams Calling Plans in Canada, all emergency calls are screened nationally before transfer to the PSAP, even when a dynamic location is acquired. Source: [Considerations for Calling Plans](https://learn.microsoft.com/en-us/microsoftteams/considerations-calling-plan), Dynamic emergency calling for Calling Plans, final paragraph; and Canada row of the routing table. Checked 2026-09-25.
[^38]: If any Teams extended notification uses a conferenced-in notification mode, a default entry with no dial string must be set with at least one user, group or PSTN number and a conferenced-in mode. Source: [Configure security desk notifications](https://learn.microsoft.com/en-us/microsoftteams/emergency-calling-security-desk-notifications), Configure extended notifications, Note after the example table. Checked 2026-09-25.
[^39]: Microsoft directs Teams Direct Routing customers in the United States to coordinate with their Emergency Routing Service Provider for a test service rather than offering a predefined Microsoft 933 bot. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure dynamic emergency calling > Test emergency calling, second bullet. Checked 2026-09-25.
[^40]: For Teams Direct Routing, the SBC's PSTN gateway setting PidfloSupported must be set to true so location information is added to the outgoing emergency INVITE. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Emergency calling prerequisites for Direct Routing. Checked 2026-09-25.
[^41]: Microsoft states that some Emergency Routing Service Providers in the United States offer an emergency calling test bot. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure dynamic emergency calling > Test emergency calling, lead sentence. Checked 2026-09-25.
[^42]: When a Teams client matches the Location Information Service, the first match wins in the order wireless access point, Ethernet switch/port, Ethernet switch, then subnet. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure dynamic emergency calling > Plan for emergency calling, step 2. Checked 2026-09-25.
[^43]: Some Teams network settings changes, such as a new address or network identifier, can take up to four hours to propagate to Teams clients. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure dynamic emergency calling > Configure network settings. Checked 2026-09-25.
[^44]: Teams security desk notification modes are chat only, conferenced in and muted, or conferenced in muted with the ability to unmute; an external PSTN number can be conferenced in but is not allowed to unmute. Source: [Configure security desk notifications](https://learn.microsoft.com/en-us/microsoftteams/emergency-calling-security-desk-notifications), Introduction, second paragraph. Checked 2026-09-25.
[^45]: With Teams Calling Plan or Operator Connect the emergency numbers (911 and 933 in Microsoft's US example) are predefined, whereas Direct Routing admins must define them in an emergency call routing policy. Source: [Configure security desk notifications](https://learn.microsoft.com/en-us/microsoftteams/emergency-calling-security-desk-notifications), Configure extended notifications, paragraph after the Note. Checked 2026-09-25.
[^46]: For Teams security desk notification, a policy on the network site where the client is located is used first, otherwise the user's policy, and a client that obtains no emergency calling policy is not enabled for security desk notification. Source: [Configure security desk notifications](https://learn.microsoft.com/en-us/microsoftteams/emergency-calling-security-desk-notifications), Configure security desk notifications, bullet list. Checked 2026-09-25.
[^47]: Microsoft states that a successful Teams network-site match does not confirm the client obtained an emergency address, and tells admins to follow the test emergency calling steps to confirm the returned location rather than rely on a site match. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure Location Information Service > IPv6 subnet matching, Important note and closing paragraph. Checked 2026-09-25.
[^48]: For US Calling Plan users, an emergency call from a Teams client not at a tenant-defined dynamic emergency location is screened by a national call center before transfer to the PSAP. Source: [Considerations for Calling Plans](https://learn.microsoft.com/en-us/microsoftteams/considerations-calling-plan), Emergency call routing for different countries/regions, United States row, second bullet. Checked 2026-09-25.
[^49]: Teams dynamic emergency calling, including security desk notification, is not supported on the Teams web client. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure dynamic emergency calling > Supported clients, second Note. Checked 2026-09-25.
[^50]: Webex Calling 933 test calls can be placed from all endpoints assigned to the location, including HELD-capable devices, soft phones and non-HELD devices. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Requirements for E911 Service Integration with Webex Calling. Checked 2026-09-25.
[^51]: Cisco instructs Webex Calling admins to place 933 test calls to confirm calls route properly before enabling full 911 routing for a location. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Enable the E911 service for Webex Calling locations. Checked 2026-09-25.
[^52]: In Webex Calling enhanced emergency calling (RedSky), a 933 test call connects the caller to an IVR that announces the caller ID and the currently known address for that device. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Enable the E911 service for Webex Calling locations. Checked 2026-09-25.
[^53]: Zoom's special service numbers article lists 933 as a reserved number for the United States and Canada in Zoom Phone. Source: [Special service numbers](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0062274), United States and Canada row. Checked 2026-09-25.