WarmTransfer
sip media · published

Hold resume and conference signaling

Verified 2026-09-24 · 60 sources · tier 1–2

Hold and resume signaling modifies existing media sessions through session descriptions, while conference signaling coordinates multi-party media streams across user agents and conference focuses 9​26. These operations rely on Session Description Protocol (SDP) direction attributes, SIP re-INVITE transactions, and call control headers 6​3​27.

SDP Offer and Answer for Hold and Resume

Under RFC 3264, a media stream that was previously sendrecv is placed on hold by marking it sendonly in a new offer 9. If a stream was previously recvonly, it is placed on hold by marking it inactive 8. RFC 3264 specifies that the recipient of an offer placing a stream on hold SHOULD NOT automatically answer with its own side of that stream on hold 12.

Responses to directional SDP offers must follow specific mapping rules under RFC 3264:

  • An answer to a stream offered as sendonly MUST mark that stream recvonly or inactive 6.
  • An answer to a stream offered as recvonly MUST mark that stream sendonly or inactive 5.
  • An answer to a stream offered as inactive MUST mark that stream inactive 4.
  • An answer to a stream offered as sendrecv MAY mark that stream sendonly, recvonly, sendrecv, or inactive 7.

When an offerer wishes to keep a session but neither send nor receive media on a stream, it MUST mark that stream inactive 10. RFC 6337, an Informational RFC published in August 2011, notes that a user agent (UA) may initiate hold by offering inactive instead of sendonly if it does not intend to transmit any media while on hold 42​38. RFC 6337 notes that the sendonly hold model assumes the holding UA will play music on hold (MOH), which is not always the case 39. Under RFC 6337's general principle, a UA's offer states what it and its user want to do at that time regardless of what the other party indicated previously 37. Consequently, a UA already placed on hold with inactive that then wants to initiate its own hold using inactive need not send a new offer 40. When both sides are on hold, each side must clear its own hold state, and the first UA to come off hold sends an offer with sendrecv 41.

RFC 8866, published in January 2021, obsoletes RFC 4566 as the SDP specification 47. RFC 8866 states that if no media direction attribute is present at the session or media level, sendrecv SHOULD be assumed 44. A media-level direction attribute overrides a session-level direction attribute, and the session-level attribute applies to media streams that carry none 46.

RFC 3264 lists RFC 2543 as obsoleted 13. RFC 3264 states that using connection address 0.0.0.0 to put a call on hold is no longer recommended because it prevents RTCP on held streams, does not work with IPv6, and breaks connection-oriented media 17. However, RFC 3264 requires an agent to be capable of receiving SDP with connection address 0.0.0.0 and to treat it as meaning neither RTP nor RTCP should be sent to the peer 16. RFC 6337 states that an answer to an offer with c=IN IP4 0.0.0.0 must still choose its direction attribute from the direction attribute of the offered stream 43. RFC 5359 notes that older UAs may set the connection address to 0.0.0.0 to hold, but this is deprecated in favor of inactive when no media is sent or sendonly when media is still sent 36.

For RTP media, RFC 3264 states that RTCP is still sent and received on sendonly, recvonly, and inactive streams 15. RFC 8866 affirms that an RTP-based system MUST still send RTCP packets when in receive-only mode 48, and MUST still send RTCP if RTCP is used even when a stream is inactive 45.

Any modified offer under RFC 3264, such as a hold or resume offer, must increment the version in the SDP origin (o=) line by exactly 1 from the previous SDP 14. Furthermore, a modified SDP must contain at least as many m= lines as the previous SDP 11.

SIP Dialog and Transaction Handling

A UAC MUST NOT start a new INVITE (such as a hold or resume re-INVITE) while another INVITE transaction is in progress in the same dialog 3. If a UAC receives a 491 response to a re-INVITE, it waits a random 2.1 to 4 seconds before retrying if it owns the Call-ID, and 0 to 2 seconds otherwise 1. If a re-INVITE fails (for example, with a 488 response), the existing call does not fail, and the session continues with the previously negotiated characteristics 2.

In the RFC 5359 call hold service example, a call is placed on hold using a re-INVITE whose SDP carries sendonly, which is answered with recvonly 33. For music on hold, the RFC 5359 example illustrates the holding party sending a REFER to a music server, which then sends an INVITE with a Replaces header to the held party to stream music 34. The holding party retrieves the call by sending its own INVITE with Replaces to the held party 35.

Conference Signaling Architectures

RFC 4579 was published in August 2006 as Best Current Practice BCP 119 24. Under RFC 4579, a conference focus MUST include the isfocus feature parameter in its Contact header unless it wishes to hide that it is a focus 26. A conference-aware UA SHOULD subscribe to the conference event package when the remote target URI of its dialog carries isfocus 31. RFC 4579 also defines a conference factory URI such that a successful call to it automatically creates a new conference and its focus 25.

RFC 4579 defines several REFER mechanisms for conference management:

  • A focus receiving a REFER whose Refer-To is a SIP URI SHOULD send an INVITE to that new participant 29.
  • A UA wishing to add a participant SHOULD send that participant a REFER whose Refer-To contains the conference URI 30.
  • A point-to-point call is moved into a conference by placing an escaped Replaces header in the Refer-To URI, causing the focus's INVITE to replace the original dialog at the other party 27.
  • A participant is removed by sending the conference URI a REFER whose Refer-To names the participant with the method parameter set to BYE 28.

RFC 5359 gives two three-way conference examples: Section 2.10 where the third party is added and Section 2.11 where the third party joins by calling 32.

RFC 3911 defines the SIP Join header and the option tag join, requiring UAs that support the header to include join in a Supported header field 19. A UAS with enough resources to handle a Join request locally SHOULD accept it and perform the media mixing or combining 21. If a UAS finds no dialog matching the Join header, it rejects the INVITE with 481 Call/Transaction Does Not Exist 18. A request carrying both Join and a header with contradictory semantics, such as Replaces, MUST be rejected with 400 Bad Request 20.

RFC 4575 defines the SIP event package named conference, using notification bodies formatted as application/conference-info+xml 23. RFC 4575 specifies endpoint status values including connected, disconnected, on-hold, muted-via-focus, pending, alerting, dialing-in, dialing-out, and disconnecting 22.

Platform Implementations

Cisco Unified Communications Manager (CUCM) 12.0(1) SIP line messaging documentation states that the SIP line side supports hold using both RFC 2543 c=0 and RFC 3261/3264 sendonly or inactive 54. When a SIP phone hosts a locally mixed three-way call on CUCM 12.0(1), it can drop out and connect the remaining 2 parties using REFER with an embedded Replaces 53.

The Microsoft Direct Routing SIP protocol documentation states that Direct Routing does not support Delayed Offer INVITE (an INVITE without SDP) 55. As of 2026-08-21, the Microsoft Direct Routing SIP protocol article contains no guidance on which SDP direction attribute is used for hold or on music on hold 56.

Applicability

Applies to: IETF SIP, IETF SDP, IETF SIP service examples, IETF SIP conferencing, IETF SIP Join header, IETF SIP conference event package, Microsoft Teams Phone Direct Routing, and Cisco Unified Communications Manager. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-24. CUCM line-side details are stated for CUCM 12.0(1) 54​53. Absence of hold and music-on-hold guidance in Microsoft Direct Routing documentation is confirmed as of 2026-08-21 56.

What remains uncertain

The following items are not covered by the sources below:

  • CUCM SIP profile "Send send-receive SDP in mid-call INVITE" and "Require SDP Inactive Exchange" settings are not covered by the sources below.
  • Teams Direct Routing hold SDP direction and music on hold behaviour beyond the documented absence of guidance in the protocol article are not covered by the sources below.
  • CUCM hold signaling using an inactive re-INVITE followed by a delayed-offer re-INVITE for MOH or resume is not covered by the sources below.
  • Direct Routing Replaces conflict resolution between the reject note and the must-support section is not covered by the sources below.
  • Webex Calling local gateway hold and MOH signaling is not covered by the sources below.
  • JSEP transceiver direction for WebRTC hold under RFC 8829 is not covered by the sources below.
  • Cisco CUBE default midcall-signaling behaviour and the Scenario-Behavior table for sendonly and inactive are not covered by the sources below.
  • Conference hold signaling toward carrier SIP legs is not covered by the sources below.

See also

Referenced by

Sources

  1. 1
    RFC 3261 says a UAC receiving 491 to a re-INVITE waits a random 2.1 to 4 seconds before retrying if it owns the Call-ID and 0 to 2 seconds otherwise.
    RFC 3261 — SIP: Session Initiation Protocol · Section 14.1 UAC Behavior · Checked 2026-09-24
  2. 2
    RFC 3261 says that if a re-INVITE fails (for example with 488) the existing call does not fail and the session continues with the previously negotiated characteristics.
    RFC 3261 — SIP: Session Initiation Protocol · Section 14.2 UAS Behavior · Checked 2026-09-24
  3. 3
    RFC 3261 says a UAC MUST NOT start a new INVITE (such as a hold or resume re-INVITE) while another INVITE transaction is in progress in the same dialog.
    RFC 3261 — SIP: Session Initiation Protocol · Section 14.1 UAC Behavior · Checked 2026-09-24
  4. 4
    Under RFC 3264 an answer to a stream offered as inactive MUST mark that stream inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-24
  5. 5
    Under RFC 3264 an answer to a stream offered as recvonly MUST mark that stream sendonly or inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-24
  6. 6
    Under RFC 3264 an answer to a stream offered as sendonly MUST mark that stream recvonly or inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-24
  7. 7
    Under RFC 3264 an answer to a stream offered as sendrecv MAY mark that stream sendonly or recvonly or sendrecv or inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-24
  8. 8
    Under RFC 3264 a media stream that was previously recvonly is placed on hold by marking it inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8.4 Putting a Unicast Media Stream on Hold · Checked 2026-09-24
  9. 9
    Under RFC 3264 a media stream that was previously sendrecv is placed on hold by marking it sendonly in a new offer.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8.4 Putting a Unicast Media Stream on Hold · Checked 2026-09-24
  10. 10
    Under RFC 3264 an offerer that wants to keep the session but neither send nor receive media on a stream MUST mark that stream inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 5.1 Unicast Streams · Checked 2026-09-24
  11. 11
    Under RFC 3264 a modified SDP must contain at least as many m= lines as the previous SDP.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8 Modifying the Session · Checked 2026-09-24
  12. 12
    RFC 3264 says the recipient of an offer that puts a stream on hold SHOULD NOT automatically answer with its own side of that stream on hold.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8.4 Putting a Unicast Media Stream on Hold · Checked 2026-09-24
  13. 13
    RFC 3264 lists RFC 2543 as obsoleted.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Document header Obsoletes line · Checked 2026-09-24
  14. 14
    Under RFC 3264 a modified offer such as a hold or resume offer must increment the version in the SDP origin (o=) line by exactly one from the previous SDP.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8 Modifying the Session · Checked 2026-09-24
  15. 15
    RFC 3264 states that for RTP media RTCP is still sent and received on sendonly and recvonly and inactive streams.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 5.1 Unicast Streams · Checked 2026-09-24
  16. 16
    RFC 3264 requires an agent to be capable of receiving SDP with connection address 0.0.0.0 and to treat it as meaning neither RTP nor RTCP should be sent to the peer.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-24
  17. 18
    RFC 3911 says a UAS that finds no dialog matching the Join header rejects the INVITE with 481 Call/Transaction Does Not Exist.
    The Session Initiation Protocol (SIP) "Join" Header · Section 4 User Agent Server Behavior: Receiving a Join Header · Checked 2026-09-24
  18. 19
    RFC 3911 defines the option tag join and says UAs that support the Join header MUST include it in a Supported header field.
    The Session Initiation Protocol (SIP) "Join" Header · Section 7.2 New option tag for Require and Supported headers · Checked 2026-09-24
  19. 20
    RFC 3911 says a request carrying both Join and a header with contradictory semantics such as Replaces MUST be rejected with 400 Bad Request.
    The Session Initiation Protocol (SIP) "Join" Header · Section 4 User Agent Server Behavior: Receiving a Join Header · Checked 2026-09-24
  20. 21
    RFC 3911 says a UAS with enough resources to handle a Join request locally SHOULD accept it and perform the media mixing or combining.
    The Session Initiation Protocol (SIP) "Join" Header · Section 4 User Agent Server Behavior: Receiving a Join Header · Checked 2026-09-24
  21. 22
    RFC 4575 endpoint status values are connected disconnected on-hold muted-via-focus pending alerting dialing-in dialing-out and disconnecting.
    A Session Initiation Protocol (SIP) Event Package for Conference State · Section 5.7.3 <status> (under 5.7 <endpoint>) · Checked 2026-09-24
  22. 23
    RFC 4575 defines the SIP event package named conference whose notification bodies use application/conference-info+xml.
    A Session Initiation Protocol (SIP) Event Package for Conference State · Section 3.1 Event Package Name and Section 3.4 NOTIFY Bodies · Checked 2026-09-24
  23. 24
    RFC 4579 was published August 2006 as Best Current Practice BCP 119.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Document header · Checked 2026-09-24
  24. 25
    RFC 4579 defines a conference factory URI such that a successful call to it automatically creates a new conference and its focus.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Section 3.2 Conference Factory URI · Checked 2026-09-24
  25. 26
    RFC 4579 says a conference focus MUST include the isfocus feature parameter in its Contact header unless it wishes to hide that it is a focus.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Section 4.2 Session Establishment · Checked 2026-09-24
  26. 27
    RFC 4579 moves a point-to-point call into a conference by putting an escaped Replaces header in the Refer-To URI so that the focus's INVITE replaces the original dialog at the other party.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Section 5.10 Replaces Header Field: Transferring a Point-to-Point Session in to a Conference · Checked 2026-09-24
  27. 28
    RFC 4579 removes a participant by sending the conference URI a REFER whose Refer-To names the participant with method set to BYE.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Section 5.11 REFER with BYE: Requesting That the Focus Remove a Participant from a Conference · Checked 2026-09-24
  28. 29
    RFC 4579 says a focus that receives a REFER whose Refer-To is a SIP URI SHOULD send an INVITE to that new participant.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Section 5.5 REFER: Requesting a Focus to Add a New Resource to a Conference · Checked 2026-09-24
  29. 30
    RFC 4579 says a UA wishing to add a participant SHOULD send that participant a REFER whose Refer-To contains the conference URI.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Section 5.6 REFER: Requesting a User to Dial in to a Conference Using a Conference URI · Checked 2026-09-24
  30. 31
    RFC 4579 says a conference-aware UA SHOULD subscribe to the conference event package when the remote target URI of its dialog carries isfocus.
    Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents · Section 3.4 Conference-Aware UA · Checked 2026-09-24
  31. 32
    RFC 5359 gives two three-way conference examples: Section 2.10 where the third party is added and Section 2.11 where the third party joins by calling.
    Session Initiation Protocol Service Examples · Sections 2.10 and 2.11 headings · Checked 2026-09-24
  32. 33
    The RFC 5359 call hold example places the call on hold with a re-INVITE whose SDP carries sendonly and is answered with recvonly.
    Session Initiation Protocol Service Examples · Section 2.1 Call Hold · Checked 2026-09-24
  33. 34
    The RFC 5359 music-on-hold example has the holding party send a REFER to a music server which then sends an INVITE with Replaces to the held party and streams music to it.
    Session Initiation Protocol Service Examples · Section 2.3 Music on Hold introductory paragraph · Checked 2026-09-24
  34. 35
    In the RFC 5359 music-on-hold example the holding party retrieves the call by sending its own INVITE with Replaces to the held party.
    Session Initiation Protocol Service Examples · Section 2.3 Music on Hold introductory paragraph · Checked 2026-09-24
  35. 36
    RFC 5359 says older UAs may set the connection address to 0.0.0.0 to hold and that this is deprecated in favour of inactive when no media is sent or sendonly when media is still sent.
    Session Initiation Protocol Service Examples · Section 2.1 Call Hold second paragraph · Checked 2026-09-24
  36. 37
    RFC 6337's general principle is that a UA's offer states what it and its user want to do at that time regardless of what the other party indicated previously.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.1 General Principle for Constructing Offers and Answers · Checked 2026-09-24
  37. 38
    RFC 6337 says a UA may initiate hold by offering inactive instead of sendonly if it does not intend to transmit any media while on hold.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.3 Hold and Resume of Media · Checked 2026-09-24
  38. 39
    RFC 6337 notes that the sendonly hold model assumes the holding UA will play music on hold and that this is not always the case.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.3 Hold and Resume of Media · Checked 2026-09-24
  39. 40
    RFC 6337 says a UA already placed on hold with inactive that then wants to initiate its own hold also using inactive need not send a new offer.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.3 Hold and Resume of Media · Checked 2026-09-24
  40. 41
    RFC 6337 says that when both sides are on hold each side must clear its own hold state and the first UA to come off hold sends an offer with sendrecv.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.3 Hold and Resume of Media · Checked 2026-09-24
  41. 42
    RFC 6337 on SIP usage of the offer/answer model is an Informational RFC published August 2011.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Document header Category and date · Checked 2026-09-24
  42. 43
    RFC 6337 says an answer to an offer with c=IN IP4 0.0.0.0 must still choose its direction attribute from the direction attribute of the offered stream.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.4 Behavior on Receiving SDP with c=0.0.0.0 · Checked 2026-09-24
  43. 44
    RFC 8866 says that if no media direction attribute is present at session or media level sendrecv SHOULD be assumed.
    SDP: Session Description Protocol · Section 6.7 Media Direction Attributes · Checked 2026-09-24
  44. 45
    RFC 8866 says an RTP-based system MUST still send RTCP if RTCP is used even when a stream is inactive.
    SDP: Session Description Protocol · Section 6.7.4 inactive · Checked 2026-09-24
  45. 46
    RFC 8866 says a media-level direction attribute overrides a session-level one and the session-level attribute applies to media that carry none.
    SDP: Session Description Protocol · Section 6.7 Media Direction Attributes · Checked 2026-09-24
  46. 47
    RFC 8866 published January 2021 obsoletes RFC 4566 as the SDP specification.
    SDP: Session Description Protocol · Document header Obsoletes line · Checked 2026-09-24
  47. 48
    RFC 8866 says an RTP-based system in receive-only mode MUST still send RTCP packets.
    SDP: Session Description Protocol · Section 6.7.1 recvonly · Checked 2026-09-24
  48. 49
    The CUBE mid-call signaling guide says re-INVITEs are not consumed when media flow-around or media anti-tromboning is configured.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Restrictions under Mid-call Signaling Passthrough - Media Change · Checked 2026-09-24
  49. 50
    The CUBE mid-call signaling guide lists Multicast Music On Hold (MMOH) as not supported.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Restrictions (the section it sits under, media-change or block, is unconfirmed) · Checked 2026-09-24
  50. 51
    On CUBE with midcall-signaling passthru media-change mid-call re-INVITEs are passed through only when bidirectional media such as T.38 fax or video is added.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Section Mid-call Signaling Passthrough - Media Change · Checked 2026-09-24
  51. 52
    On CUBE midcall-signaling preserve-codec disables mid-call codec negotiation and keeps the codec negotiated at call setup.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Section Mid Call Codec Preservation · Checked 2026-09-24
  52. 53
    The CUCM 12.0(1) SIP line messaging guide says a SIP phone hosting a locally mixed three-way call can drop out and connect the remaining two parties using REFER with an embedded Replaces.
    SIP Line Messaging Guide (Standard Edition) for Cisco Unified Communications Manager - SIP Standard Line Interface · Section Three-Way Calling · Checked 2026-09-24
  53. 54
    The CUCM 12.0(1) SIP line messaging guide says the SIP line side supports hold both by RFC 2543 c=0 and by RFC 3261/3264 sendonly or inactive.
    SIP Line Messaging Guide (Standard Edition) for Cisco Unified Communications Manager - SIP Standard Line Interface · Section Simple Hold and Resume · Checked 2026-09-24
  54. 55
    The Microsoft Direct Routing SIP protocol article says Direct Routing does not support Delayed Offer INVITE (an INVITE without SDP).
    Teams Phone System Direct Routing: SIP protocol · Section Inbound call: SIP dialog description > Non-media bypass flow, Note under Call accepted · Checked 2026-09-24
  55. 56
    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.
    Teams Phone System Direct Routing: SIP protocol · Whole article (absence confirmed across all sections as rendered) · Checked 2026-09-24
  56. 57
    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
    Teams Phone System Direct Routing: SIP protocol · Section Processing the incoming request: finding the tenant and user, Note under the OPTIONS example table · Checked 2026-09-24
  57. 58
    The Microsoft Direct Routing SIP protocol article says the SBC must support INVITE with Replaces.disputed
    Teams Phone System Direct Routing: SIP protocol · Section Replaces option · Checked 2026-09-24
  58. 59
    The Twilio conference Participant resource's endConferenceOnExit controls whether the conference ends when that participant leaves and defaults to false.
    Conferences Participants subresource · Participant request parameters, endConferenceOnExit · Checked 2026-09-24
  59. 60
    The Twilio conference Participant resource's holdUrl defaults to Twilio's standard hold music and may return an MP3 or WAV file or TwiML with Play Say Pause or Redirect.
    Conferences Participants subresource · Participant request parameters, holdUrl · Checked 2026-09-24

Documents

tier 1 standards and regulators

A Session Initiation Protocol (SIP) Event Package for Conference State

IETF / RFC Editor · 2006-08-01 · accessed 2026-09-24

tier 1 standards and regulators

RFC 3261 — SIP: Session Initiation Protocol

IETF / RFC Editor · 2002-06 · accessed 2026-09-04

tier 1 standards and regulators

RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)

IETF / RFC Editor · 2002-06 · accessed 2026-09-04

tier 1 standards and regulators

RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model

IETF / RFC Editor · 2011-08-01 · accessed 2026-09-24

tier 1 standards and regulators

SDP: Session Description Protocol

IETF / RFC Editor · 2021-01-01 · accessed 2026-09-24

tier 1 standards and regulators

Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents

IETF / RFC Editor · 2006-08-01 · accessed 2026-09-24

tier 1 standards and regulators

Session Initiation Protocol Service Examples

IETF / RFC Editor · 2008-10-01 · accessed 2026-09-24

tier 1 standards and regulators

The Session Initiation Protocol (SIP) "Join" Header

IETF / RFC Editor · 2004-10-01 · accessed 2026-09-24

tier 2 current vendor documentation

Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling

Cisco Systems · accessed 2026-09-24

tier 2 current vendor documentation

Conferences Participants subresource

Twilio · 2026-06-22 · accessed 2026-09-24

tier 2 current vendor documentation

SIP Line Messaging Guide (Standard Edition) for Cisco Unified Communications Manager - SIP Standard Line Interface

Cisco Systems · accessed 2026-09-24

tier 2 current vendor documentation

Teams Phone System Direct Routing: SIP protocol

Microsoft · 2026-08-21 · accessed 2026-09-23

Cite this page

APA

WarmTransfer. (2026, September 24). Hold resume and conference signaling. WarmTransfer. https://warmtransfer.net/knowledge/hold-resume-conference

BibTeX

@misc{warmtransfer-hold-resume-conference,
  title  = {Hold resume and conference signaling},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/hold-resume-conference},
  note   = {Verified 2026-09-24}
}