Teams Phone System Direct Routing: SIP protocol

Publisher

Microsoft

URL

https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip

Published

2026-08-21

Updated

unknown

Accessed

2026-09-23

HTTP status

200

License

Microsoft Learn terms of use; no-redistribution; short excerpts and locators only

Source notes citing this source

• In Teams Direct Routing, a Teams endpoint's Call progress is converted by the SIP proxy into a 180 message, and on receiving 180 the SBC must generate local ringing. in context
• When a Teams user forwards a call and the caller is a PSTN user, the Direct Routing SIP proxy generates a 181 Call is being forwarded provisional response to the caller. in context
• In Teams Direct Routing, the SBC can receive one 183 per session in non-bypass mode and multiple 183 messages in media bypass mode; in both modes a call may proceed with or without a provisional 183. in context
• In Teams Direct Routing, an endpoint's Media answer is converted by the SIP proxy into a 183 with media candidates in SDP, and on receiving 183 the SBC is expected to connect to those media candidates. in context
• In non-bypass Direct Routing, the SIP proxy replaces the client's SDP in the 183 Session Progress with the Media Processor's SDP, and the 183 is generated only once, either by the Ring Bot or a client endpoint, on an existing or new fork. in context
• When a Teams user has several endpoints, the Direct Routing SIP proxy can send several 180 Ringing responses, one per endpoint Call progress, each a separate early dialog with a different To tag. in context
• Teams Direct Routing does not support a Delayed Offer INVITE (an INVITE without SDP). in context
• For Teams Direct Routing, an SBC that follows the RFC 3960 policy would play local ringing after the 180 and switch to media from the SDP candidates once the 183 arrives and media flows. inferred in context
• The Microsoft Direct Routing SIP protocol article says Direct Routing does not support Delayed Offer INVITE (an INVITE without SDP). in context
• The Microsoft Direct Routing SIP protocol article as of 2026-08-21 contains no guidance on which SDP direction attribute is used for hold or on music on hold. in context
• The Microsoft Direct Routing SIP protocol article says Direct Routing rejects SIP requests that carry Replaces headers and tells admins to make sure the SBC is not using them. disputed in context
• The Microsoft Direct Routing SIP protocol article says the SBC must support INVITE with Replaces. disputed in context
• In Teams Direct Routing, when the SBC gets a 503 with a Retry-After header in response to an INVITE, it must terminate that connection and try the next available Microsoft datacenter. in context
• If several missed calls appear for one declined call, the SBC or PSTN provider retry logic is misconfigured, and the SBC must be set to stop retrying on a 603 response. in context
• An INVITE or OPTIONS to the Direct Routing SIP proxy whose Contact header uses an IP address instead of the SBC FQDN is refused with 403 Forbidden. in context
• Direct Routing requires a successful OPTIONS exchange (200 OK) between the SBC and the Microsoft SIP proxy before calls can be set up. in context
• A busy Direct Routing datacenter can send the SBC a Retry-After with a one-second interval. in context
• Microsoft recommends using only the Contact header, not Record-Route, when no proxy SBC is in use. Record-Route is needed when a proxy SBC with Local Media Optimization must stay in the path, and if both headers are used their values must be identical. in context
• For in-dialog requests, the Direct Routing SIP proxy picks the next hop from the top Record-Route first. If there is no Record-Route, it uses the Contact header. in context
• Direct Routing does not support an IP address in Record-Route or Contact. Only an FQDN that matches the SBC certificate's CN or SAN is supported, and an IP address or mismatched FQDN makes the call fail. in context
• The Teams Direct Routing SIP proxy always offers the session timer on non-bypass calls, does not offer it on media-bypass calls, and does not require the SBC to use it. in context
• When a Teams user forwards a call from a PSTN caller, the Direct Routing SIP proxy sends the caller a 181 Call Is Being Forwarded provisional response, and the forwarded INVITE's Request-URI carries a cause parameter. in context
• Microsoft says that several missed calls for one declined call mean the SBC or PSTN trunk provider's retry mechanism is misconfigured, and the SBC must be reconfigured to stop retrying on a 603 response. in context
• Microsoft's Direct Routing SIP article cites RFC 4244 for History-Info, although RFC 7044 obsoleted RFC 4244 in February 2014. in context
• In Direct Routing, the trunk's ForwardCallHistory parameter controls whether History-Info is populated, and inbound History-Info is preserved only when ForwardCallHistory is enabled. in context
• Microsoft's Direct Routing SIP guidance says the History-Info header should be used for loop prevention in call-forwarding scenarios. in context
• The Direct Routing SIP proxy adds History-Info for simultaneous ring and call forwarding but not for call transfer. in context
• The Direct Routing SIP proxy always offers the session timer on non-media-bypass calls and does not offer it on media bypass calls. in context
• Microsoft states that use of the session timer by the SBC is not mandatory for Direct Routing. in context
• Every OPTIONS and INVITE sent to the Microsoft SIP proxy must carry the paired SBC FQDN, matching the certificate CN or SAN, in the Contact header. A Contact header with an IP address is refused with 403 Forbidden. in context
• Direct Routing doesn't support Delayed Offer INVITEs (INVITE without SDP) and doesn't support SIPS URIs. in context
• If the SBC advertises REFER in its Allow header, the Direct Routing SIP proxy sends REFER to the SBC and acts as Transferor (RFC 5589 section 6). Otherwise the proxy terminates the client's REFER itself and acts as Referee. in context
• SBC handling of REFER is mandatory for devices seeking Direct Routing media bypass certification, and call transfer without SBC REFER support isn't supported in media bypass mode. in context
• For incoming calls, the phone number in the Request-URI (and in the From header, for blocking and reverse lookup) must contain a leading plus sign. in context
• On an incoming call, Direct Routing finds the tenant by looking up the full Contact-header FQDN as a registered domain, then falls back to the FQDN minus its host portion. If neither matches, the call fails. in context
• If an INVITE or OPTIONS sent to the Microsoft SIP proxy has an IP address instead of an FQDN as the Contact header hostname, the proxy refuses it with 403 Forbidden. An IP address in Record-Route or Contact also fails the certificate check. in context
• If a Direct Routing datacenter is busy, it can send the SBC a 503 with Retry-After (one-second interval) in response to an INVITE. The SBC must then terminate that connection and try the next available Microsoft datacenter. in context
• Wildcard SBC certificates are supported for Direct Routing when they follow RFC 2818 matching, where *.a.com matches foo.a.com but not bar.foo.a.com. in context

Cite this source record

APA

WarmTransfer. (2026, August 21). Teams Phone System Direct Routing: SIP protocol. WarmTransfer. https://warmtransfer.net/knowledge/sources/ms-learn-dr-protocols-sip

BibTeX

@misc{warmtransfer-ms-learn-dr-protocols-sip,
  title  = {Teams Phone System Direct Routing: SIP protocol},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sources/ms-learn-dr-protocols-sip},
  note   = {Microsoft, accessed 2026-09-23}
}