Feedback Edit

Direct routing - definitions and RFC standards

  • Article
  • 3 minutes to read
  • Applies to:
    Microsoft Teams

This article describes how Microsoft Phone System Direct Routing implements RFC standard protocols. This article is intended for voice administrators who are responsible for configuring the connection between the on-premises Session Border Controller (SBC) and the Session Initiation Protocol (SIP) proxy service.

The customer SBC interfaces with the following components in the Microsoft Teams backend:

  • The SIP proxy for signaling. This is the Internet-facing component of Direct Routing that handles SIP (TLS) connections between the SBCs and Direct Routing.

  • The media processors for media. This is the Internet-facing component of Direct Routing that handles media traffic. This component uses SRTP and SRTCP protocols.

For more information about Direct Routing, see Phone System Direct Routing.

For more information about how Direct Routing implements the SIP protocol, see Direct Routing - SIP protocol.

RFC standards

Direct Routing complies with RFC standards. The SBC connected to Direct Routing must also comply with the following RFCs (or their successors).

Standards applicable to devices that support non-media bypass mode

The following standards are applicable to devices that support only non-media bypass mode:

  • RFC 3261 SIP: Session Initiation Protocol
  • RFC 3325. Private Extension to the Session Initiation Protocol for asserted identity within Trusted Networks--Sections about handling P-Asserted-Identity header. Direct Routing sends P-Asserted-Identity with Privacy ID headers.
  • RFC 4244 An extension to Session Initiation Protocol (SIP) for required History Information. See also: Routing SIP Protocol description for more information.
  • RFC 3892 The Session Initiation Protocol Referred-By mechanism
  • RFC 3891 The Session Initiation Protocol (SIP) "Replaces" Header
  • RFC 6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model. See the “Deviations from RFC” section.
  • RFC 3711 and RFC 4771. Protect RTP traffic using SRTP. The SBC must be able to establish keys using SDES.
  • RFC 8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing

Standards applicable to devices that support media bypass mode

In addition to the standards listed as applicable to non-bypass mode, the following standards are used for media bypass mode:

Standards applicable to support conveying location information to E911 providers

Deviations from the RFC's

The following table lists the sections of the RFC(s) in which Microsoft's implementation of the SIP or media stack deviates from the standard:

RFC and sections Description Deviation
RFC 6337, section 5.3 Hold and Resume of Media RFC allows using “a=inactive”, “a=sendonly”, a=recvonly” to place a call on hold. The SIP proxy only supports “a=inactive” and does not understand if the SBC sends “a=sendonly” or “a=recvonly”.
RFC 6337, section 5.4 “Behavior on Receiving SDP with c=0.0.0.0 RFC3264 requires that an agent is capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer. The SIP proxy does not support this option.

Operational modes

There are two operational modes for Direct Routing:

  • Without media bypass in which all RTP traffic flows between the Teams client, the media processors, and the SBC.

  • With media bypass in which all RTP media flows between the Teams endpoints and the SBC.

Note that SIP traffic always flows via the SIP proxy.

DTMF

In-band DTMF is not supported by media stack.