# Early media and ringback behavior Canonical: https://warmtransfer.net/knowledge/early-media-ringback Last verified: 2026-09-24 Standard examples generated by the callee include ringing tone and announcements such as queuing status[^34]. ## Standards and Signaling Models RFC 3960 (Early Media and Ringing Tone Generation in SIP) was published in December 2004 with category Informational[^35]. In RFC 3960's gateway model, early media sessions are managed with offer/answer exchanges carried in reliable provisional responses, PRACKs, and UPDATEs[^20]. Reliable provisional responses are defined in RFC 3262, a Proposed Standard published in June 2002 to facilitate PSTN interworking[^33]. Under RFC 3262, if an initial INVITE includes the 100rel option tag in a Require header, the UAS must send every non-100 provisional response reliably, whereas in a Supported header the tag signals capability[^2]. RFC 3262 forbids sending 100 (Trying) reliably, permitting only provisional responses numbered 101 to 199 to be sent reliably[^1]. RFC 3262 defines the PRACK method to acknowledge reliable provisional responses, utilizing the RSeq header in the provisional response and the RAck header in the PRACK[^30]. Reliable provisional responses are retransmitted with exponential backoff starting at T1 until a PRACK arrives, or for up to 64*T1 seconds[^32]. Session descriptions may be exchanged in reliable provisional responses and PRACK so the session can be established before call completion[^38]. RFC 6337 notes that SDP in an unreliable provisional response before any reliable response serves as a preview of the answer, while the actual answer is the first SDP in a reliable non-failure response[^50]. A UAC receiving SDP in an unreliable provisional response should act as if it received the answer but must not send a new offer until receiving the same SDP in a reliable non-failure response[^31]. RFC 6337 recommends that a UAS send an SDP answer reliably before sending early media, if possible[^6]. Once a UAS sends an answer in a reliable provisional response, it should not repeat SDP in later responses, and a UAC should ignore SDP repetitions from non-conforming peers[^22]. RFC 3960 provides an alternative application server model that uses separate offer/answer exchanges for early media carried as early-session bodies, allowing a UAC to reject or mute early media offers without affecting the regular session[^7]. RFC 3959 defines the early-session Content-Disposition type and a matching early-session option tag that a UA uses to show it understands that disposition type[^17]. RFC 3960's security considerations advise UAs to encrypt session descriptions with mechanisms such as S/MIME and employ media-level authentication such as SRTP, because attackers may send packets to transport addresses exposed in early session descriptions[^37]. ## Ringback Tone Generation and Control A 180 (Ringing) response indicates the callee is being alerted, and RFC 3960 directs a UAS to send it whenever alerting occurs regardless of early media session status[^3]. RFC 3960 outlines a recommended policy for POTS-like SIP UAs: - Never generate local ringing unless a 180 (Ringing) response has been received[^29]. - If 180 (Ringing) is received and no incoming media packets are arriving, generate local ringing[^27]. - If 180 (Ringing) is received and incoming media packets are arriving, play the incoming packets, refrain from generating local ringing, and stop any local ringing already under way[^28]. The Alert-Info header specifies which tone to play when the UAC generates local ringing, but RFC 3960 states it does not govern when to generate local ringing[^5]. RFC 5009 introduces the P-Early-Media header for networks to authorize backward or forward early media cut-through under defined policies[^24]. RFC 5009 restricts P-Early-Media to a trust domain, noting it is not applicable to the Internet at large or inter-domain use[^25]. Defined parameters include supported, sendrecv, sendonly, recvonly, inactive, and gated, where sendonly authorizes backward early media (UAS to UAC) and inactive revokes or denies authorization[^23]. A UAC can use P-Early-Media to determine whether to render UAS early media instead of local ringback from a 180 response[^26]. The SIP Forum ratified SIPconnect 2.0 in January 2017, which added guidance on early media compared with version 1.1[^39]. ## Forking and Early Media Limitations RFC 3960 notes that the gateway model does not work well with forking[^21]. When a UAC receives early media from multiple UASs following a fork, it typically picks one early dialog at random and mutes the remaining dialogs[^19]. If a muted early dialog becomes the answered dialog, media clipping is likely because the UAC must send an UPDATE with a new offer, and the UAS cannot send media until that offer is received[^18]. ## Platform Implementations ### Microsoft Teams Direct Routing In Teams Direct Routing, a Teams endpoint's Call progress is converted by the SIP proxy into a 180 message, prompting the SBC to generate local ringing[^40]. Media answers are converted into a 183 with media candidates in SDP, connecting the SBC to those media candidates[^43]. Delayed Offer INVITEs without SDP are not supported[^46]. The SBC can receive 1 provisional 183 per session in non-bypass mode and multiple 183 messages in media bypass mode, though calls in either mode can proceed with or without 183[^42]. When a Teams user has multiple endpoints, the SIP proxy can send separate 180 Ringing responses per endpoint Call progress, each acting as a distinct early dialog with a unique To tag[^45]. In non-bypass mode, the proxy replaces client SDP in 183 Session Progress with Media Processor SDP, generated only once by either the Ring Bot or an endpoint[^44]. If a Teams user forwards a PSTN call, the SIP proxy sends a 181 Call is being forwarded provisional response[^41]. ### Cisco Gateways and CUBE On Cisco IOS/IOS XE gateways and CUBE, early media cut-through is the default treatment for a 180 response carrying SDP[^9]. A 180 response without SDP triggers local ringback, which remains unchanged by the Enhanced 180 feature[^8]. A 183 response with SDP always receives early media cut-through, unaffected by disable-early-media 180[^10]. The command disable-early-media 180 in sip-ua or voice class tenant mode causes the gateway to ignore SDP in a 180 response and generate local ringback, while the no form restores cut-through[^14]. The command was introduced in Cisco IOS 12.2(13)T, with voice class tenant and system keywords added in 15.6(2)T and IOS XE Denali 16.3.1, and YANG support added in IOS XE Dublin 17.10.1a[^13]. Beginning in IOS XE Denali 16.3.1, CUBE consumes multiple forked 18x responses with SDP by default if the inbound leg does not support PRACK or UPDATE[^15]. This consumption does not support Delayed-Offer to Delayed-Offer calls, SDP passthrough, SRTP passthrough, ANAT, media flow-around, media anti-trombone, or early-dialog UPDATE block[^12]. ### Webex Contact Center Webex Contact Center SIP interoperability guidelines list SIP Early Media and SIP Early Offer as Not Supported, marking both as future roadmap items[^52][^53]. In contrast, SIP Delayed Offer is listed as Supported[^51]. ### Twilio Twilio's TwiML `` attribute `answerOnBridge` defaults to false; setting it to true keeps the inbound leg ringing until the dialed party answers, sending a 180 or 183 over SIP before the 200 connects[^48]. The `ringTone` attribute takes an ISO 3166-1 alpha-2 country code (or `us-old`) to override caller ringback, defaulting to the carrier's ringtone[^49]. ## See also - [SIP transactions dialogs and call setup](https://warmtransfer.net/knowledge/sip-transactions-dialogs) - [SDP offer answer and codec negotiation](https://warmtransfer.net/knowledge/sdp-offer-answer) - [SIP response codes and failure interpretation](https://warmtransfer.net/knowledge/sip-response-codes) - [Webex Contact Center voice channel and PSTN options](https://warmtransfer.net/knowledge/webex-cc-voice-channels) ## Applicability Applies to: IETF SIP, SIP Forum SIPconnect 2.0, Microsoft Teams Phone Direct Routing, Cisco Unified Border Element, Cisco IOS, Cisco Webex Contact Center, and Twilio Programmable Voice TwiML. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-24. The disable-early-media 180 command applies to Cisco IOS from 12.2(13)T through 17.10.1a, with tenant mode from 15.6(2)T and IOS XE Denali 16.3.1, and YANG support from IOS XE Dublin 17.10.1a[^13]. Forked 18x consumption applies to Cisco IOS XE Denali 16.3.1 onwards[^15]. ## What remains uncertain - Which provisional responses (180/183 with or without SDP) and PRACK use Webex Contact Center sends toward PSTN/LGW/BYoPSTN is not covered by the sources below. - CUCM SIP Profile Disable Early Media on 180 setting and its default is not covered by the sources below. - Webex Calling Local Gateway early media and ringback handling is not covered by the sources below. - Early media and ringback behaviour on other contact center platform SIP trunks is not covered by the sources below. - Certified SBC vendor guidance for Teams ringback (180 to 183 conversion and local ringback) is not covered by the sources below. - Core SIP RFC text for 180 Ringing and 183 Session Progress is not covered by the sources below. - SIPconnect 2.0 early media requirements (P-Early-Media / 18x handling) is not covered by the sources below. - IMS gating of ringback and early media specifications outside the RFCs in this article is not covered by the sources below. ## Sources [^1]: RFC 3262 forbids sending 100 (Trying) reliably; only provisional responses numbered 101 to 199 may be sent reliably. Source: [RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3262.html), Section 3 (UAS Behavior). Checked 2026-09-24. [^2]: Under RFC 3262, if the initial INVITE carries the 100rel option tag in a Require header, the UAS must send every non-100 provisional response reliably. In a Supported header the tag only signals capability. Source: [RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3262.html), Sections 3 and 4 (UAS and UAC behavior). Checked 2026-09-24. [^3]: RFC 3960 states that a 180 (Ringing) response means the callee is being alerted, and a UAS should send it when the callee is being alerted regardless of the status of the early media session. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.2 (Ringing Tone Generation), note after the policy list. Checked 2026-09-24. [^4]: On a Cisco gateway or CUBE, a 183 with SDP from a far end that then sends no audio will likely leave the caller with silence rather than local ringback, because the 183 always gets cut-through and 180-based local ringback is not triggered (inferred). Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Enhanced 180 Provisional Response Handling](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-sip-enhance180-prov.html), SIP Enhanced 180 Provisional Response Handling > treatment of 183 with SDP; combined with RFC 3960 Section 3.2. Checked 2026-09-24. [^5]: Per RFC 3960, the Alert-Info header tells the UAC which tone to play if it generates local ringing, but not when to generate local ringing. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 5 (Alert-Info Header Field). Checked 2026-09-24. [^6]: RFC 6337 recommends that a UAS send an SDP answer reliably, if possible, before it starts sending early media. Source: [RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model](https://www.rfc-editor.org/rfc/rfc6337.html), Section 3.1.1. Checked 2026-09-24. [^7]: RFC 3960's application server model uses a separate offer/answer exchange for early media, carried as early-session bodies, so a UAC can reject or mute early media offers without muting the regular session. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 4 (The Application Server Model). Checked 2026-09-24. [^8]: On Cisco IOS/IOS XE gateways and CUBE, a 180 response without SDP gets local ringback, and the Enhanced 180 feature does not change that. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Enhanced 180 Provisional Response Handling](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-sip-enhance180-prov.html), SIP Enhanced 180 Provisional Response Handling > treatment table / information section. Checked 2026-09-24. [^9]: On Cisco IOS/IOS XE gateways and CUBE, early media cut-through is the default treatment for a SIP 180 response that carries SDP. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Enhanced 180 Provisional Response Handling](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-sip-enhance180-prov.html), SIP Enhanced 180 Provisional Response Handling > information / default treatment. Checked 2026-09-24. [^10]: On Cisco IOS/IOS XE gateways and CUBE, a 183 response with SDP always gets early media cut-through; the disable-early-media 180 setting does not affect it. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards: SIP Enhanced 180 Provisional Response Handling](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-sip-enhance180-prov.html), SIP Enhanced 180 Provisional Response Handling > treatment table / information section. Checked 2026-09-24. [^11]: CUBE's forked 18x handling is controlled with voice-class sip early-media update block (dial-peer) or early media update block (global SIP), with an optional re-negotiate keyword to renegotiate media after connect. Source: [Cisco Unified Border Element Configuration Guide: Consumption of Forked 18x Responses with SDP During Early Dialog](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-forked-18x-responses.html), Configure ... forked 18x responses (configuration section). Checked 2026-09-24. [^12]: CUBE's forked 18x consumption does not support Delayed-Offer to Delayed-Offer calls, SDP passthrough, SRTP passthrough, ANAT, media flow-around, media anti-trombone or early-dialog UPDATE block. Source: [Cisco Unified Border Element Configuration Guide: Consumption of Forked 18x Responses with SDP During Early Dialog](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-forked-18x-responses.html), Restrictions section. Checked 2026-09-24. [^13]: The disable-early-media 180 command was introduced in Cisco IOS 12.2(13)T. A system keyword and voice class tenant support were added in 15.6(2)T and IOS XE Denali 16.3.1, and YANG support in IOS XE Dublin 17.10.1a. Source: [Cisco IOS Voice Command Reference - D through I: disable-early-media through dualtone](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d2.html), disable-early-media 180 command entry: Command History table. Checked 2026-09-24. [^14]: The Cisco IOS command disable-early-media 180 (sip-ua or voice class tenant mode) makes the gateway ignore SDP in a 180 response and play local ringback; the no form restores early media cut-through. Source: [Cisco IOS Voice Command Reference - D through I: disable-early-media through dualtone](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d2.html), disable-early-media 180 command entry: Command Modes and Usage Guidelines. Checked 2026-09-24. [^15]: From IOS XE Denali 16.3.1, if the inbound leg does not support PRACK or UPDATE, CUBE by default consumes multiple forked 18x responses with SDP received during the early dialog. Source: [Cisco Unified Border Element Configuration Guide: Consumption of Forked 18x Responses with SDP During Early Dialog](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-forked-18x-responses.html), Consumption of Forked 18x Responses with SDP During Early Dialog > information and feature history. Checked 2026-09-24. [^16]: RFC 3959 requires early-session bodies to follow the offer/answer model and allows them in the same messages as session bodies, with specified exceptions. Source: [RFC 3959: The Early Session Disposition Type for the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3959.html), Section 4. Checked 2026-09-24. [^17]: RFC 3959 (Standards Track, December 2004) defines the early-session Content-Disposition type and a matching early-session option tag that a UA uses to show it understands that disposition type. Source: [RFC 3959: The Early Session Disposition Type for the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3959.html), Sections 4 (disposition type) and 6 (option tag). Checked 2026-09-24. [^18]: RFC 3960 warns that media clipping is likely when a muted early dialog becomes the answered dialog, because the UAC sends an UPDATE with a new offer and the UAS cannot send media until it receives that offer. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.1 (Forking). Checked 2026-09-24. [^19]: Per RFC 3960, when a UAC receives early media from several UASs after forking it typically picks one early dialog at random and mutes the rest. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.1 (Forking). Checked 2026-09-24. [^20]: In RFC 3960's gateway model, early media sessions are managed with offer/answer exchanges carried in reliable provisional responses, PRACKs and UPDATEs. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3 (The Gateway Model). Checked 2026-09-24. [^21]: RFC 3960 states that the gateway model does not work well with forking. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.1 (Forking). Checked 2026-09-24. [^22]: RFC 6337 says that once a UAS has sent the answer in a reliable provisional response it should not include SDP in later responses to the INVITE, and a UAC should be ready to receive and ignore such SDP from non-conforming peers. Source: [RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model](https://www.rfc-editor.org/rfc/rfc6337.html), Section 3.1.1. Checked 2026-09-24. [^23]: RFC 5009 defines P-Early-Media parameters supported, sendrecv, sendonly, recvonly, inactive and gated; sendonly authorizes backward early media only (UAS to UAC) and inactive denies or revokes authorization. Source: [RFC 5009: Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media](https://www.rfc-editor.org/rfc/rfc5009.html), Section 8 (Syntax / parameter definitions). Checked 2026-09-24. [^24]: RFC 5009 defines the P-Early-Media header so that SIP networks can authorize cut-through of backward and/or forward early media when their early media policies allow it. Source: [RFC 5009: Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media](https://www.rfc-editor.org/rfc/rfc5009.html), Section 1 (Introduction). Checked 2026-09-24. [^25]: RFC 5009 limits P-Early-Media to use inside a trust domain and says it is not applicable to inter-domain use or the Internet at large. Source: [RFC 5009: Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media](https://www.rfc-editor.org/rfc/rfc5009.html), Section 2 (Applicability Statement). Checked 2026-09-24. [^26]: RFC 5009 notes that a UAC can use P-Early-Media to decide whether to render early media from the UAS instead of local ringback triggered by a 180 Ringing response. Source: [RFC 5009: Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media](https://www.rfc-editor.org/rfc/rfc5009.html), Section 8.1. Checked 2026-09-24. [^27]: Under the RFC 3960 policy, if a 180 (Ringing) has been received but no incoming media packets are arriving, the UA generates local ringing. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.2 (Ringing Tone Generation), policy item 2. Checked 2026-09-24. [^28]: Under the RFC 3960 policy, if a 180 (Ringing) has been received and incoming media packets are arriving, the UA plays them and does not generate local ringing, stopping any local ringing already under way. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.2 (Ringing Tone Generation), policy item 3 and following paragraph. Checked 2026-09-24. [^29]: RFC 3960's recommended policy for a POTS-like SIP UA is to never generate local ringing unless a 180 (Ringing) response has been received. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.2 (Ringing Tone Generation), policy item 1. Checked 2026-09-24. [^30]: RFC 3262 defines the PRACK method to acknowledge a reliable provisional response, with the RSeq header in the provisional response and the RAck header in the PRACK. Source: [RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3262.html), Sections 6 and 7 (PRACK method; RSeq and RAck headers). Checked 2026-09-24. [^31]: RFC 6337 says a UAC receiving SDP in an unreliable provisional response should act as if it received the answer, but must not send a new offer until it receives the same SDP in a reliable non-failure response. Source: [RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model](https://www.rfc-editor.org/rfc/rfc6337.html), Section 3.1.1. Checked 2026-09-24. [^32]: Under RFC 3262 a reliable provisional response is retransmitted with exponential backoff starting at T1 until a PRACK arrives, or for up to 64*T1 seconds. Source: [RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3262.html), Section 3 (UAS Behavior). Checked 2026-09-24. [^33]: RFC 3262, which defines reliable provisional responses in SIP, is a Standards Track (Proposed Standard) RFC published in June 2002 and gives PSTN interworking as its motivation. Source: [RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3262.html), Header block; Section 1 (Introduction). Checked 2026-09-24. [^34]: RFC 3960 gives ringing tone and announcements such as queuing status as typical examples of early media generated by the callee. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 1 (Introduction). Checked 2026-09-24. [^35]: RFC 3960 (Early Media and Ringing Tone Generation in SIP) was published in December 2004 with category Informational. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), RFC 3960 header block (Category). Checked 2026-09-24. [^36]: RFC 3960's ringing-tone policy is keyed on 180 (Ringing) and incoming media; the fetched text did not show it assigning any role to 183 (Session Progress) (inferred). Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 3.2 (Ringing Tone Generation); whole-document search reported by fetch. Checked 2026-09-24. [^37]: RFC 3960's security considerations say UAs should encrypt session descriptions (for example with S/MIME) and use media-level authentication such as SRTP, because attackers may send packets to the transport address in an early session description. Source: [RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3960.html), Section 6 (Security Considerations). Checked 2026-09-24. [^38]: RFC 3262 allows session descriptions to be exchanged in reliable provisional responses and in PRACK, so the session can be established before the call completes. Source: [RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3262.html), Section 5 (Provisional Responses and Offer/Answer). Checked 2026-09-24. [^39]: The SIP Forum ratified SIPconnect 2.0 in January 2017, and the announcement says it adds guidance on early media, among other topics, compared with version 1.1. Source: [SIP Forum Announces Ratification of Version 2.0 of the SIPconnect Technical Recommendation](https://www.sipforum.org/2017/01/sip-forum-announces-ratification-of-version-2-0-of-the-sipconnect-technical-recommendation/), Press release body paragraph listing 2.0 enhancements. Checked 2026-09-24. [^40]: 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. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Inbound call: SIP dialog description > Non-media bypass flow. Checked 2026-09-24. [^41]: 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. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Call forwarding. Checked 2026-09-24. [^42]: 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. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Inbound call: SIP dialog description, comparison table (Non-bypass mode / Bypass mode). Checked 2026-09-24. [^43]: 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. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Inbound call: SIP dialog description > Non-media bypass flow. Checked 2026-09-24. [^44]: 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. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Multiple endpoints ringing with provisional answer, step 4. Checked 2026-09-24. [^45]: 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. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Multiple endpoints ringing with provisional answer, step 3. Checked 2026-09-24. [^46]: Teams Direct Routing does not support a Delayed Offer INVITE (an INVITE without SDP). Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Inbound call: SIP dialog description > Non-media bypass flow, note under Call accepted. Checked 2026-09-24. [^47]: 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). Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Non-media bypass flow (180 and 183 handling), read with RFC 3960 Section 3.2. Checked 2026-09-24. [^48]: With Twilio TwiML (default false), the inbound call keeps ringing until the dialed party answers; for SIP, Twilio first sends a 180 or 183 and returns 200 only once the connects. Source: [TwiML Voice: ](https://www.twilio.com/docs/voice/twiml/dial), Attributes > answerOnBridge. Checked 2026-09-24. [^49]: Twilio's ringTone attribute takes an ISO 3166-1 alpha-2 country code (plus us-old) and overrides the ringback tone Twilio plays to the caller during ; it defaults to the carrier's ringtone. Source: [TwiML Voice: ](https://www.twilio.com/docs/voice/twiml/dial), Attributes > ringTone. Checked 2026-09-24. [^50]: RFC 6337 treats SDP in an unreliable provisional response before any reliable response as a preview of the answer; the actual answer is the first SDP in a reliable non-failure response. Source: [RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model](https://www.rfc-editor.org/rfc/rfc6337.html), Section 3.1.1. Checked 2026-09-24. [^51]: Webex Contact Center's SIP interoperability guidelines list SIP Delayed Offer as Supported. Source: [Set up voice channels for Webex Contact Center](https://help.webex.com/en-us/article/nhy3codb/Set-Up-Voice-Channel-for-Webex-Contact-Center), Set up voice channels for Webex Contact Center > SIP interoperability guidelines. Checked 2026-09-24. [^52]: Webex Contact Center's SIP interoperability guidelines list SIP Early Media as Not Supported, marked as a future roadmap item. Source: [Set up voice channels for Webex Contact Center](https://help.webex.com/en-us/article/nhy3codb/Set-Up-Voice-Channel-for-Webex-Contact-Center), Set up voice channels for Webex Contact Center > SIP interoperability guidelines. Checked 2026-09-24. [^53]: Webex Contact Center's SIP interoperability guidelines list SIP Early Offer as Not Supported, marked as a future roadmap item. Source: [Set up voice channels for Webex Contact Center](https://help.webex.com/en-us/article/nhy3codb/Set-Up-Voice-Channel-for-Webex-Contact-Center), Set up voice channels for Webex Contact Center > SIP interoperability guidelines. Checked 2026-09-24. [^54]: Because Webex Contact Center does not support SIP early media, a deployment should not expect in-band ringback or announcements from Webex Contact Center before answer; any ringback a caller hears before answer would have to come from local generation upstream (gateway, SBC or carrier) (inferred). Source: [Set up voice channels for Webex Contact Center](https://help.webex.com/en-us/article/nhy3codb/Set-Up-Voice-Channel-for-Webex-Contact-Center), SIP interoperability guidelines (Early Media: Not Supported), read with RFC 3960 Section 3.2. Checked 2026-09-24.