Number
E.164 value, provider, number type, licensed usage, inventory status, port/order, and lifecycle state.
Microsoft Teams Phone operations and emergency readiness
Teams Phone Number and Emergency Address Inventory Guide
Reconcile every telephone number with its purpose, assignee, PSTN connectivity model, validated emergency location, network mapping, policy path, business owner, and test evidence. A trustworthy inventory makes routine moves safer and emergency calling failures easier to prevent.
Calling Plan, Operator Connect, Mobile, and Direct Routing
Users, resource accounts, and service numbers
Addresses, places, LIS, policies, and test evidence
Inventory objective
Make the emergency-calling chain auditable before a move or incident
The Teams admin center can display phone numbers, users, emergency locations, network topology, and policies in separate places. Carriers, on-premises directory attributes, session border controllers, emergency routing providers, and facilities records may hold additional facts. None of those screens is a complete operational inventory by itself.
The inventory should let an administrator answer one practical question for every person, shared service, device, and site: if this endpoint places an emergency call from this network or remote location, what identity, calling line, dispatchable location, route, and notification outcome should be presented—and when was that outcome last validated?
Minimum evidence package
- Acquired-number export and the current assignment state.
- User and resource-account identity, license, usage location, and ownership.
- Emergency address, place, validation/geocode state, and country alignment.
- Trusted IPs, sites, subnets, Wi-Fi access points, switches, and ports used by LIS.
- Emergency calling and routing policy assignments at both user and site scope.
- Carrier, Operator Connect, Teams Phone Mobile, SBC, ERS, or ELIN dependencies.
- Test date, client, network, caller ID, announced location, result, exception, and owner.
Safety rule: never use a real emergency number as an informal test. Use Microsoft’s supported test number or the emergency routing provider’s approved test service where available, follow local requirements, and coordinate any test that could notify a security desk or public-safety workflow.
Six records that must agree
Reconcile the control chain, not six isolated exports
Treat these records as linked keys. A mismatch at any point can produce the wrong caller identity, the wrong location, a failed notification, an unassigned service number, or an emergency call that follows an unintended route.
Assignee
User, shared device, resource account, conference bridge, or unassigned reserve with a named owner.
Address and place
Validated civic address, building, floor, suite, room, geocode, country, and facilities owner.
Network location
Trusted IP, network site, subnet, Wi-Fi BSSID, switch chassis, or port mapped through LIS.
Policies and route
Emergency calling notification, Direct Routing emergency route, voice route, caller ID, and carrier path.
Evidence
Approved change, propagation window, client/network tests, reported location, exception, and next review date.
| Inventory field | What to record | Primary evidence | Failure detected |
|---|---|---|---|
| Telephone number | E.164 number, country, provider, PSTN connectivity type, geographic/toll-free type, acquired date, order or port reference | Teams Phone numbers export, carrier portal, order history, contract or CSR where applicable | Shadow number pools, duplicate records, numbers stranded during a port, or carrier inventory drift |
| Usage and assignment | User, voice app, or conference usage; assigned/unassigned; UPN, object ID, resource account, auto attendant, call queue, bridge, or reserve purpose | Teams admin center, `Get-CsPhoneNumberAssignment`, resource-account and conferencing records | Wrong service type, orphaned assignee, number held without an owner, or service number assigned as a user number |
| Identity and license | Account state, Teams Phone entitlement, Calling Plan where required, usage location, hybrid authority, support owner | Microsoft 365/Teams user record, license export, Entra object, synchronized directory attributes | Assignment blocked by licensing, country mismatch, disabled identity, or stale `msRTCSIP-Line` authority |
| Emergency location | Emergency address ID, place ID, civic details, geocode/validation, assigned number/user, last facilities attestation | Teams emergency-locations export, address validation result, facilities source of truth | Wrong suite/floor, old building record, address that cannot map to a network identifier, or user/number/location country mismatch |
| Dynamic location | Trusted external IP, region, site, subnet, BSSID, chassis, port, LIS location, emergency policies | Network topology and LIS exports, Locations and Networks report, DHCP/Wi-Fi/switch evidence | Unmatched client, stale subnet, NAT/proxy ambiguity, incorrect site policy, or missing dispatchable place |
| Validation | Test number/provider, date/time, test user, client, physical/network location, announced caller ID/location, notification and routing result | Approved test record, client diagnostic, security-desk confirmation, provider evidence, incident/change ticket | Configuration that looks complete in admin portals but fails from a representative client or network |
Connectivity and ownership
Document who controls each field for each PSTN model
Calling Plan, Operator Connect, Teams Phone Mobile, and Direct Routing do not place the same responsibilities in the same portal. The inventory needs an authority column so a help-desk technician does not attempt to change a carrier-controlled field in Teams—or assume Microsoft manages a Direct Routing dependency.
| PSTN model | Number and address authority | Emergency-routing dependency | Inventory emphasis |
|---|---|---|---|
| Microsoft Calling Plan | Numbers and emergency locations are managed through Microsoft tooling, subject to country/region requirements | Microsoft provides supported emergency routing; user/site emergency calling policy governs notifications | Usage location, number/location country, address validation, assignment, notification, 933 result where supported |
| Operator Connect | The operator uploads numbers and may control whether the emergency location can be assigned or changed in Teams | Operator capabilities and regional service determine routing behavior | Operator owner, escalation path, address-edit authority, carrier confirmation, uploaded inventory, and test evidence |
| Teams Phone Mobile | Mobile operator manages the number and capabilities; Teams assignment and location options depend on the operator | Mobile/operator emergency behavior plus Teams policy and client context | SIM/mobile identity, operator authority, device/client scenario, remote/location behavior, and support handoff |
| Direct Routing | Carrier and tenant administrators manage number ownership; Microsoft 365 or on-premises directory may be authoritative for assignment | SBC, voice route, emergency route policy, PIDF-LO support, and an ERS provider or ELIN design as applicable | SBC and carrier owner, uploaded acquired-number inventory, routing policy, ERS/ELIN, source attributes, failover, and controlled testing |
Direct Routing inventory note: uploading Direct Routing numbers to Microsoft’s telephone-number management inventory is optional, but it improves visibility in the Teams admin center and supports `Get-CsPhoneNumberAssignment` and acquired-number exports. A number assigned to a user is uploaded if it is not already present. Release planning is required before porting an uploaded Direct Routing number to another PSTN model.
Operational runbook
Build the inventory in a controlled sequence
Define scope and data owner
List countries, offices, remote populations, PSTN models, carriers, SBCs, emergency-routing providers, business hours, and accountable voice/facilities/security owners. Record regional legal or carrier review requirements rather than assuming a U.S.-only model.
Export every number source
Export acquired numbers and assignments from Teams, obtain carrier or Operator Connect inventories, include Direct Routing ranges, resource accounts, conferencing numbers, unassigned reserves, port orders, and numbers retained for a future project.
Normalize and deduplicate
Normalize to E.164, preserve extensions separately, reconcile country and number type, and flag duplicate, missing, unexpectedly uploaded, unavailable, or carrier-only entries. Never treat display formatting as a different number.
Resolve assignment and license
Map the number to a user, shared device, resource account, voice app, or bridge; verify account state, Teams Phone licensing, usage location, supported number usage, and whether synchronized on-premises attributes still control the value.
Attest every address and place
Reconcile the emergency address with facilities records. Validate building, floor, suite, room/place, country, geocode, and operational status. Retire duplicates only after confirming they are not assigned to numbers or network identifiers.
Map network and LIS evidence
Export trusted IPs, regions, sites, subnets, Wi-Fi access points, switches, and ports. Map each identifier to the intended emergency location and site policies, then investigate match failures in the Locations and Networks report.
Reconcile policy precedence
Capture user and network-site emergency calling policy, Direct Routing emergency call routing policy, voice route, caller ID policy, and security-desk destination. Identify which assignment should win when a user roams into a configured site.
Test representative paths
Wait for the documented propagation window, then test supported desktop, mobile, desk-phone, room, wired, Wi-Fi, VPN, remote, and failover scenarios. Record announced calling number/location, notification, routing, and any provider screening behavior.
Close gaps and schedule review
Assign each exception a risk owner, remediation date, temporary safeguard, and retest. Review monthly operational drift and quarterly owner/location attestation; add event-driven review for moves, ports, carrier changes, network redesign, and SBC changes.
Preserve a reversible change packet
Retain before/after exports, object IDs, PowerShell commands or GUI steps, approvals, expected propagation, validation results, carrier case, and a tested failback sequence. Phone-number and emergency-location changes should never depend on screenshots alone.
Emergency location hierarchy
Separate civic address, dispatchable place, network match, and user confirmation
Emergency address
The civic address is validated with Azure Maps when entered in Teams. When no match is found, administrators can manually create the address and use a pin. For automated routing in the United States, locations assigned to network identifiers need associated geocodes.
Place within the address
A place adds dispatchable detail such as building, floor, suite, room, or office area. The facilities inventory should use durable identifiers so a renamed department does not silently break location ownership or audit comparisons.
Dynamic or remote location
On a trusted corporate network, the client can obtain a location through LIS network identifiers. At a remote location, policy can permit the user to confirm or enter an address. Treat user-entered records as a governed support workflow, not a substitute for maintained corporate topology.
Current Microsoft caveats: emergency addresses that are more than a couple of years old may be unavailable for assignment to network identifiers and may need to be recreated. The emergency location, phone number, and user must be in the same country. Some countries also require the emergency address to match the number’s area code. Confirm the current country and carrier rules before activation.
Dynamic emergency calling
Verify the client can acquire the intended location
Location Information Service path
- Trusted external IP identifies whether the client is on the organization’s network.
- Network sites and subnets can deliver emergency calling and Direct Routing emergency-route policies.
- LIS subnets, Wi-Fi BSSIDs, switch chassis IDs, and ports map the client to an emergency location.
- Subnets used in network topology must also be defined in LIS when they are expected to render a dynamic location.
- Network-setting changes can require up to four hours to propagate to clients.
Client and network limitations
- Dynamic emergency calling and security-desk notification are not supported in the Teams web client.
- Subnet location is broadly supported; Wi-Fi location is not supported on Teams phones.
- Ethernet/LLDP support varies by operating system and device and may require supporting software.
- Cloud proxy services that modify the client’s source IP can prevent the expected network-configuration lookup.
- VPN split/full-tunnel behavior, NAT changes, IPv6, wireless refreshes, switch replacement, and remote work all need representative tests.
| Control | Applies to | What it governs | Inventory proof |
|---|---|---|---|
| Emergency calling policy | Calling Plan, Operator Connect, Teams Phone Mobile, and Direct Routing | External location lookup and security-desk notification behavior; can be assigned to users or network sites | Policy definition, effective assignment, notification targets/mode, test-call exception behavior, owner |
| Emergency call routing policy | Direct Routing only | Emergency numbers, optional masks, PSTN usage/route; can be assigned to users or network sites | Policy, number pattern, PSTN usage, voice route, SBC/ERS path, effective user/site assignment |
| Trusted IP and network site | Dynamic emergency calling and site-based policy | Establishes corporate-network context and the site that delivers policy | Public IP, region/site, subnet, policy links, match/not-match telemetry |
| LIS network identifier | Dynamic location | Maps subnet, Wi-Fi AP, switch, or port to an emergency address/place | Identifier, location ID, description, network owner, client match evidence |
| Direct Routing gateway | Direct Routing | Conveys location data and routes to the emergency service design | SBC identity, `PidfLoSupported`, carrier/ERS or ELIN design, route, failover, validation |
Top operational risks
Common failures hidden by a phone-number-only spreadsheet
A list can be numerically complete and still be operationally unsafe. Treat these findings as reconciliation defects requiring ownership, evidence, and retesting.
Address assigned, place missing
The building is correct but the floor, suite, or room required for a dispatchable location is absent or stale.
Wrong usage or assignee
A number intended for an auto attendant, call queue, conference bridge, or person has the wrong licensed usage or account type.
Country mismatch
The number, emergency location, and user usage location do not align, preventing assignment or producing an invalid operating assumption.
Hybrid attribute conflict
An on-premises `msRTCSIP-Line` value remains authoritative and blocks or overwrites the intended Microsoft 365 assignment.
Stale LIS identifier
A subnet, BSSID, switch, or port changed during a network refresh, so clients no longer obtain the approved location.
Site and user policy drift
The administrator records a direct user policy but roaming users receive a different site-based result that was never tested.
Carrier authority unclear
An Operator Connect or Teams Phone Mobile location cannot be changed in Teams, but no operator owner or escalation path is documented.
Direct Routing route gap
The number exists, but the SBC, PIDF-LO, emergency route, ERS/ELIN, or failover dependency is absent from the inventory.
Unsupported client assumption
Teams web, Wi-Fi on a Teams phone, proxy-modified source IP, VPN, or another client/network limitation invalidates the expected dynamic location.
Unassigned has no purpose
Reserve and porting numbers remain unassigned without a business owner, expiration, carrier cost review, or planned use.
Portal-only validation
All fields look populated, but no representative client test confirms the announced caller ID, location, routing, and notification outcome.
Move completed without retest
Facilities, network, and voice teams close separate tasks without proving that the new physical and network location resolves correctly.
Validation and ongoing evidence
Test the scenario the user will actually experience
In the United States and Canada, Calling Plan, Operator Connect, and Teams Phone Mobile users can use 933 where supported to hear the calling number, emergency address/location, and expected routing treatment. Direct Routing customers should coordinate with their emergency routing provider. Confirm the current regional and provider procedure before every test campaign.
Before the test
Approve scope, confirm the supported test service, verify that notification recipients know a test is planned, record the user/number/client/network, and allow propagation after changes.
During the test
Capture the announced caller ID and location, route/screening outcome, security-desk notification, client location display, timestamp, network path, and any difference from the expected result.
After the test
Attach evidence to the change, assign exceptions, retest after remediation, update the inventory’s last-tested and next-review fields, and preserve provider or security-desk confirmation.
Locations report
Use the Teams Locations and Networks report for 7- or 28-day match/not-match evidence across network sites, LIS identifiers, trusted IPs, IPv4, and IPv6. High-volume nonmatches require root-cause review.
Monthly operations
Reconcile new, ported, assigned, released, disabled, and unassigned numbers; expiring reserves; carrier tickets; failed tests; network changes; and address exceptions.
Quarterly attestation
Have voice, facilities, network, security, and business owners attest active sites, places, service numbers, remote policies, notification targets, provider paths, and recovery contacts.
Cross-control dependency: use the voice and video QoS guide for call-quality design, the Teams Phone security guide for fraud and administrative controls, and the client environment documentation guide for ownership and dependency records. Emergency-location accuracy does not replace call quality, security, or change governance.
Related IT Perfection support
Turn a static list into a maintained voice-operations record
IT Perfection can help Orange County and Southern California organizations inventory Teams Phone numbers, resource accounts, locations, network identifiers, carrier dependencies, policy assignments, test evidence, and change ownership as part of Microsoft 365 managed services or a focused Teams Phone review.
For broader Microsoft 365 architecture, identity, collaboration, security, and operational guidance, use the Microsoft 365 resource center. Learn about the experience behind these guides on Ali Hassani’s profile.
Authoritative Microsoft references
- Acquire and manage Teams Phone numbers
- Assign, change, or remove a user phone number
- Manage organizational emergency locations
- Configure dynamic emergency calling
- Manage Teams network topology
- Manage emergency calling policies
- Emergency addresses for remote locations
- Use the Locations and Networks report
- Enable Direct Routing users and inventory numbers
- Review emergency numbers by country or region
Frequently asked questions
Teams Phone number and emergency address inventory FAQ
What is the minimum Teams Phone emergency inventory?
At minimum, record the E.164 number, provider and PSTN model, number/usage type, assignment status, assignee or reserve purpose, identity and license, usage location, emergency address/place, network/LIS mapping, effective emergency policies, route/provider dependencies, business and technical owners, last validated result, and next review date.
Is assigning an emergency address to the phone number enough?
No. The civic address may still lack a dispatchable place, the client may not match the intended LIS network identifier, the site may deliver a different policy, a remote user may need location confirmation, or a Direct Routing route may have a separate dependency. Validate the effective client outcome.
What is the difference between an emergency calling policy and an emergency call routing policy?
The emergency calling policy controls external location lookup and security-desk notification behavior across supported PSTN models. The emergency call routing policy applies only to Direct Routing and defines emergency numbers, optional masks, and the PSTN usage/route. Both can be assigned to users or network sites.
How often should the inventory be reviewed?
Reconcile operational changes monthly, conduct a multidisciplinary owner/location attestation at least quarterly, and trigger immediate review after office moves, floor changes, network redesign, carrier or port events, number reassignment, resource-account changes, SBC or ERS changes, security-desk changes, and failed tests.
Can administrators test emergency calling with 911?
Do not place an informal test call to a real emergency number. In supported United States and Canada scenarios, 933 can provide a test bot for Calling Plan, Operator Connect, and Teams Phone Mobile. Direct Routing organizations should coordinate with their emergency routing provider. Always follow current regional and provider procedures.
Can IT Perfection help reconcile and test this environment?
Yes. IT Perfection can help inventory numbers and assignees, reconcile Teams and carrier records, review emergency locations and LIS/network mappings, document policy and routing dependencies, prepare controlled test plans, close exceptions, and establish an ongoing operations cadence.
Make every number, location, and route accountable
Build a Teams Phone inventory that supports routine operations and emergency readiness
IT Perfection can reconcile phone numbers, users and resource accounts, carrier authority, emergency addresses and places, network/LIS mappings, policies, Direct Routing dependencies, and validation evidence—then turn the result into a practical review and change-control process.
This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, legal/regulatory review, carrier or emergency-service-provider engineering, or tenant-specific emergency-calling validation. Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, Microsoft infrastructure, networking, and business technology experience.
