Start with retirement eligibility, not a new-build assumption
Microsoft's September 2026 notice identifies Azure Communication Services Direct Routing for retirement on September 30, 2028. It says existing inbound and outbound calling can continue during the transition for customer tenants with an ACS resource that existed at the September 2026 announcement. That is an eligibility boundary, not a general invitation to start a new deployment.
Inventory the tenant, subscription, resource creation evidence, workload, SDKs, numbers, SBCs, carrier service and support owners. Record the intended migration path and date. Microsoft points toward Teams Phone Extensibility, Teams Direct Routing or Operator Connect, but feature, licensing and application parity must be qualified for the selected workload.
Documented service facts
Reviewed 2026-10-09. Compare SIP trunk services →
SIP authentication
DocumentedThe Azure-facing peer is a provisioned, supported SBC identified by a public FQDN and paired with one Communication Services resource. Microsoft requires a publicly trusted certificate with the SBC FQDN in CN or SAN and Server Authentication EKU. This is not a generic digest-registration service. Preserve domain ownership, resource pairing, certificate identity, private-key custody, carrier-facing authentication and application access tokens as separate controls.
SIP registration
Not verifiedThe reviewed Direct Routing workflow describes SBC pairing, TLS and SBC-originated SIP OPTIONS rather than a universal SIP REGISTER transaction. Do not invent a registrar, Contact expiry or registration indicator. Confirm portal pairing, current TLS and OPTIONS status, the carrier-side trunk state and an accepted authorized call independently.
Inbound delivery
DocumentedInbound Direct Routing calls reach the Communication Services resource through the paired SBC and must then be handled by the intended Calling SDK or Call Automation application. Trunk delivery, application event delivery, reachable endpoint, application answer and media remain distinct states. Preserve the carrier DID, SBC normalization, Azure resource and application ownership rather than treating an online trunk as a completed destination.
Routing and failover
DocumentedOutbound voice routes match called-number regular expressions. SBCs within the same route priority are tried in random order; lower-priority routes are considered after higher-priority SBCs are unavailable. Microsoft documents failover to the next SBC only for SIP 408, 503 and 504 responses. Record route priority, pattern, health, response and carrier behavior; do not infer failover for every code or established calls.
Number and regional availability
Not verifiedDirect Routing connects an existing telephony service through a customer-controlled SBC; carrier serviceability, numbers and regulatory scope remain separate. Microsoft now identifies ACS Direct Routing for retirement, with transition-period continuation tied to eligible existing ACS resources. Azure region, paired SBC or carrier number does not establish new-resource eligibility, number portability or service at a requested address.
Audio codecs and DTMF
DocumentedMicrosoft lists SILK, G.711, G.722 and G.729 between the SBC and Cloud Media Processor, while the Calling SDK application leg uses G.722 in the reviewed infrastructure reference. This is an interface capability list, not proof of one offer, answer, packetization, transcoding, digit method or audio quality. Preserve SDP and packets on the Azure-facing and carrier-facing legs.
T.38 fax
Not verifiedThe reviewed retirement, infrastructure, SIP and provisioning records do not establish a universal T.38 or audio-fax entitlement, fallback, switchover, redundancy, device compatibility or completed-page result. Treat fax and other non-voice devices as separate carrier, SBC and application workflows with current support evidence.
Signaling and media encryption
DocumentedAzure Direct Routing requires TLS 1.2 on the SIP leg and publishes accepted cipher suites. Microsoft lists SRTP AES_CM_128_HMAC_SHA1_80 for media. The SBC certificate must use a trusted public CA and its FQDN; the ACS SBC FQDN must differ from a Teams Direct Routing FQDN. These Azure-facing controls do not prove the carrier-facing protection profile or end-to-end encryption.
Concurrent calls and call starts
Not verifiedThe reviewed pages do not publish one universal simultaneous-call entitlement, calls-per-second limit, carrier channel count or emergency reserve for every Direct Routing resource. Size SDK participants, Azure resource limits, SBC sessions and transcodes, carrier capacity, access bandwidth and failover headroom separately. Portal Online status is not accepted-load evidence.
Emergency calling
Not verifiedMicrosoft's ACS emergency-calling quickstart explicitly says emergency dialing is out of scope for Azure Communication Services Direct Routing. Do not transfer the direct-offer country list or SDK behavior onto a BYOC path. Establish the carrier, SBC, route, location, callback, notification, outage and provider-approved validation design independently or migrate to a documented Teams Phone scenario.
Pricing model
Not verifiedMicrosoft publishes consumption examples for the application and Direct Routing participant legs, but those examples do not establish the selected workload's current total and the service is in a retirement period. Bind dated Azure usage, SDK and support charges to carrier, SBC, access, number, emergency, implementation, tax, migration and replacement-platform terms.
Administration and support
DocumentedThe Azure portal reports TLS, SIP OPTIONS and overall SBC health. Microsoft says the SBC initiates OPTIONS and describes health from regular one-minute exchanges; the portal can take time to reflect a new trunk. Operations must now include a dated retirement inventory, eligible-resource evidence, migration target, Teams and Azure roles, distinct SBC FQDNs where systems coexist, rollback and final decommission.
SMS and MMS
Not verifiedThe reviewed Direct Routing records establish voice connectivity through an SBC, not SMS or MMS eligibility on the carrier-provided number. Azure messaging capabilities, sender registration, number type, country eligibility, retention, throughput and pricing remain separate products and evidence. Do not infer messaging from a functioning voice route.
Keep the Azure resource, SBC and carrier as separate services
ACS Direct Routing pairs a supported SBC to a Communication Services resource. The SBC connects separately to the organization's carrier trunks, PBX or other telephony systems. An Azure Online status does not establish the carrier order, DID activation, carrier-side authentication, routing, capacity or emergency service.
Preserve Azure and carrier contracts, the supported SBC model and software, public IP and DNS, Azure-facing and carrier-facing interfaces, numbers, application identities, monitoring and escalation. A supported-SBC list is a qualification input, not proof that a particular release and carrier configuration is accepted.
Build the Azure-facing identity with TLS and OPTIONS
Microsoft requires a public SBC FQDN, public DNS, a trusted public certificate whose CN or SAN includes that FQDN, Server Authentication EKU and TLS 1.2. The ACS SBC FQDN must differ from one used for Teams Direct Routing. SIP OPTIONS are enabled and the SBC must initiate the exchange.
Keep domain ownership, certificate validity, TLS session, OPTIONS exchange, portal status, accepted INVITE and completed call as separate states. The portal's TLS and OPTIONS indicators help locate the boundary but cannot prove carrier reachability, application event delivery or media.
Route by pattern, priority and bounded failover codes
Outbound calls select a voice route by called-number regular expression. SBCs sharing a priority are tried in random order, then a lower-priority route can be considered. Microsoft documents next-SBC failover only for SIP 408, 503 and 504. A rejection outside that set must not be assumed to trigger the next target.
Preserve the normalized number, matching expression, route priority, candidate SBCs, OPTIONS health, selected peer, response and carrier outcome. If no Direct Routing pattern matches, Microsoft documents a separate alternate-caller-ID path for an eligible Microsoft number; that is not proof of BYOC route success.
Treat the application as an inbound-call boundary
An inbound carrier call can traverse the SBC and reach the Communication Services resource without completing the application workflow. The intended Calling SDK or Call Automation application must receive the event, identify the resource and destination, answer or redirect and maintain its own control path.
Correlate carrier delivery, SBC transaction, Azure call identity, application notification, reachable endpoint, answer and media separately. A healthy trunk or portal Online state does not prove that an application listener was running or that a user, bot or workflow accepted the call.
Preserve media, emergency and messaging limits
Microsoft lists TLS 1.2 and an SRTP suite on the Azure-facing leg plus SILK, G.711, G.722 and G.729 between SBC and cloud media. Those are interface capabilities, not one call's negotiated result or end-to-end protection. Retain offer, answer, media addresses, packets and decoded audio on both SBC legs. Fax remains separately unverified.
The ACS emergency-calling quickstart says emergency dialing is out of scope for Direct Routing, so its direct-offer country list cannot be transferred to BYOC. Generic Direct Routing also does not establish SMS or MMS on the carrier number. Preserve an independently approved emergency design and qualify messaging separately.
Make migration an accepted service change
Microsoft's migration guide requires separate Azure and Microsoft 365 roles and notes that the same SBC FQDN cannot be used for ACS and Teams Direct Routing simultaneously. Build an inventory of inbound and outbound flows, application operations, numbers, emergency behavior, recording, media, monitoring, capacity and billing before selecting a target.
Use bounded coexistence or a staged cutover only where the current product guidance supports it. Define DNS and certificate changes, carrier route, application changes, test numbers, rollback, support owners and retirement of the old resource. No Azure resource, SBC, carrier service, call, emergency workflow, compatibility, capacity, availability or price was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Azure Communication Services retirement and breaking-changes guide ↗
- Provision Azure Communication Services Direct Routing ↗
- Azure Direct Routing infrastructure requirements ↗
- Azure Direct Routing SIP protocol specification ↗
- Monitor Azure Communication Services Direct Routing ↗
- Migrate ACS Direct Routing to Teams Phone ↗
- Azure Communication Services emergency-calling scope ↗
- Azure telephony known limitations ↗
- Certified SBCs for Azure Communication Services Direct Routing ↗
- Azure Communication Services pricing scenarios ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.