WarmTransfer
sip media · published

Troubleshooting calls that drop on hold or transfer

Verified 2026-09-30 · 60 sources · tier 1–2 · 2 disputed

Disputed: 2 sources below carry conflicting evidence.

Under the Session Description Protocol (SDP) offer/answer model, placing a call on hold or executing a transfer modifies active media sessions and dialog states via mid-call signaling 40​55. When user agents, session border controllers (SBCs), or intermediate proxies fail to negotiate session descriptions, mismanage timers, or misroute transfer requests, these transactions can result in dropped calls 51​35​23.

Signaling hold and resume

A media stream with no direction attribute at the session or media level defaults to sendrecv 19. To place a stream on hold under the SDP offer/answer model, an agent sends a new offer that marks a previously sendrecv stream as a=sendonly 40. If the stream was previously recvonly, the hold offer marks it a=inactive 39. When a stream is offered as sendonly, the answering agent MUST respond by marking the stream recvonly or inactive 7. RFC 6337 notes that while RFC 3264 uses non-normative language, the conventional acknowledgement for an a=sendonly hold offer is an answer carrying a=recvonly 38. If a stream is offered as recvonly, the answer MUST mark it sendonly or inactive, whereas an offer of sendrecv MAY be answered as sendonly, recvonly, sendrecv, or inactive 7​8.

Older implementations signal hold by setting the SDP connection address to 0.0.0.0 under RFC 2543, but this practice is no longer recommended because it prevents RTCP on held streams, fails on IPv6, and breaks connection-oriented media 59. User agents are still required to receive SDP with a 0.0.0.0 connection address, which instructs the receiver not to send RTP or RTCP to the peer 60.

Modified SDP offers must retain a matching media stream for every stream in the preceding SDP, and the version number in the origin (o=) line MUST increment by 1 44. Agents MUST NOT create a new offer while an outstanding sent or received offer remains unanswered or unrejected 45.

Mid-call transaction errors and glare

When an agent receives a re-INVITE while its own offer is pending, re-INVITE glare occurs: the UAS responds with a 491 (Request Pending), prompting the UAC to retry after a randomized interval based on which agent owns the dialog's Call-ID under RFC 3261 sections 14.1 and 14.2 5. If a re-INVITE is rejected with a non-2xx final response, the session does not change state and continues with its prior parameters 51. WarmTransfer's reading of the sources is that receiving a 488 response to a hold or resume re-INVITE does not itself drop the call under SIP rules; any subsequent disconnect stems from a device choosing to send a BYE rather than an outcome enforced by the rejection 4.

A UAS should only return an error to a re-INVITE if no session modifications have been executed since receipt 58. If any requested modification has already taken effect, the UAS SHOULD return a 2xx response instead of an error 57. A UAC receiving an error after requested changes were executed SHOULD initiate a new re-INVITE or UPDATE to resynchronize the session state between both agents 56. When responding to an offerless re-INVITE, the generated offer should present all codecs the user agent is currently able and willing to use rather than only previously negotiated codecs 46.

Session timers and call drops

SIP session timers function as a keepalive mechanism using periodic re-INVITE or UPDATE session refresh requests to maintain the session 53. RFC 4028 recommends sending the refresh once half the session interval has elapsed 48. UPDATE is recommended over re-INVITE when peer support is known; a refresh UPDATE is recommended without an SDP offer, whereas a refresh re-INVITE SHOULD contain an offer 50. The absolute minimum duration for Session-Expires is 90 seconds, 1800 seconds (30 minutes) is recommended, and the default value when Min-SE is absent is 90 seconds 52​43. An endpoint or proxy returns 422 (Session Interval Too Small) if an incoming Session-Expires falls below its configured minimum 1. If a refresh request times out or receives a 408 or 481 response, the UAC terminates the call with a BYE 49.

Call transfer mechanics

Basic call transfers begin with the Transferor placing the Transferee on hold with a re-INVITE before issuing a REFER that specifies the Transfer Target 55. Completing a REFER transaction does not terminate the dialog between Transferor and Transferee; ending that original session requires an explicit BYE 47. Attended transfers include an escaped Replaces header within the Refer-To header field so the newly formed dialog between Transferee and Target replaces the Transferor-to-Target dialog 9.

Platform implementations

Microsoft Teams Direct Routing

Teams Direct Routing selects its transfer mechanism based on SBC capabilities: if the SBC advertises REFER in its Allow header, the Microsoft SIP proxy sends a REFER to the SBC as Transferor; if not, the proxy acts as Referee to handle the transfer itself 36. SBC REFER handling is Microsoft's preferred transfer model, is mandatory for media bypass certification, and is required because transfers without SBC REFER support are unsupported in media bypass mode 28. A REFER may arrive from any Microsoft signaling IP address over a new TLS connection regardless of the IP used earlier in the call, requiring firewalls and SBCs to permit all Microsoft signaling IP addresses 26.

When the SBC receives a REFER from the Microsoft SIP proxy, it must send the new INVITE back to the SIP proxy rather than out to the PSTN or other endpoints, even for external PSTN targets 27. The SBC must populate the new INVITE Request-URI strictly using the Refer-To URI, include the Referred-By header, and copy both values without modification 29. For consultative transfers, the Microsoft SIP proxy terminates the original call with BYE upon receiving a NOTIFY containing a SIP 200 OK payload from the SBC, meaning the SBC must transmit 202 Accepted and NOTIFY updates 22. Since June 2026, per Message Center post MC1296872, Microsoft ends the original leg for blind transfers immediately after the SBC accepts the transfer, without waiting for the final transfer result 20. Transfers drop before completion if the Microsoft SIP proxy times out waiting for a 202 Accepted or NOTIFY from the SBC, or if the SBC transmits a BYE prematurely 35.

Direct Routing does not support Delayed Offer INVITE requests lacking SDP 25. When a media bypass call is transferred to a Skype for Business client, Teams Web client, or Teams VDI client, Direct Routing inserts a Media Processor and triggers an ICE restart with new candidates, ice-pwd, and ice-ufrag via re-INVITE, which the SBC must support 24. Because media bypass and Local Media Optimization require multiple re-INVITEs by design, SBC re-INVITEs arriving out of order or at incorrect times cause race conditions that delay negotiation and audio 31.

Direct Routing session timer behavior differs across modes:

  • The SIP proxy always offers session timers on non-bypass calls, omits them on media bypass calls, and does not require the SBC to use them 34.
  • Calls dropping cleanly without error codes after 10 to 60 minutes are attributed to session timer issues where re-INVITE refreshes fail to update the Session-Expires duration 23.
  • When configured, refresher=uac assigns refresh duty to the INVITE sender, refresher=uas assigns it to the receiver, and refreshes normally occur halfway through the interval 30.
  • Session timer drops can originate outside the SBC, such as carrier networks sending BYE requests that SBCs relay to the SIP proxy 21.

Cisco Unified Border Element (CUBE)

CUBE includes mid-call signaling controls to mitigate interoperability issues by consuming re-INVITE and UPDATE messages rather than passing them through 14. Administrators configure these modes globally under voice service voip > sip using midcall-signaling, or at the dial-peer level with voice-class sip midcall-signaling 13.

Configuration Mode Behavior Operational Constraints
passthru media-change Does not consume re-INVITEs when media flow-around or anti-tromboning is set 16 SDP passthrough, video transcoding, and multicast music on hold unsupported 16
block Blocks mid-call media signaling to trunk, rejects video escalation and T.38 11 Rejects mid-call INVITE with 488 when media flow-around is configured 12
preserve-codec Disables mid-call codec negotiation and preserves prior codec 17 Mid-call codec alterations are not negotiated 17

Cisco advises using midcall-signaling block only when basic calling is the primary focus and mid-call signaling can be safely absorbed 11.

See also

Applicability

Applies to: IETF SIP, Microsoft Teams Phone Direct Routing, and Cisco Unified Border Element. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-30. The blind transfer handling change for Microsoft Teams Direct Routing takes effect from June 2026 20.

What remains uncertain

Sources disagree regarding Direct Routing's support for Replaces headers: one Microsoft Direct Routing SIP protocol section states that Direct Routing rejects SIP requests containing Replaces headers and directs administrators to ensure SBCs do not use them, while another section in the same document states the SBC must support INVITE with Replaces, and Microsoft's transfer troubleshooting documentation lists INVITE with Replaces as the second-preference transfer method 32​33.

See also

Referenced by

Sources

  1. 1
    422 (Session Interval Too Small) is generated by a UAS or proxy when a request's Session-Expires duration is below its minimum timer.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 6 (422 Response Code Definition) · Checked 2026-09-30
  2. 2
    A 481 or 408 response to a re-INVITE, unlike other non-2xx responses, leads the UAC to terminate the dialog.
    RFC 3261 — SIP: Session Initiation Protocol · Section 14.1 (UAC Behavior); see also Section 12.2.1.2 · Checked 2026-09-30
  3. 3
    488 (Not Acceptable Here) means the responding party could not accept the media offered; a Warning header may accompany it to explain why.
    RFC 3261 — SIP: Session Initiation Protocol · Section 21.4.26 (488 Not Acceptable Here) · Checked 2026-09-30
  4. 4
    A 488 to a hold or resume re-INVITE does not by itself end the call under the SIP rules; a drop that follows is a decision by one of the devices (for example sending BYE), not a consequence required by the rejection.inferred
    RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) · Section 3.1, read together with RFC 3261 Section 14.1 · Checked 2026-09-30
  5. 5
    When re-INVITE glare occurs, the UAS returns 491 (Request Pending) and the UAC retries the offer after a randomly selected time that depends on which user agent owns the dialog's Call-ID, as specified in RFC 3261 sections 14.1 and 14.2.
    RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) · Section 3.5 (Glare Situations) · Checked 2026-09-30
  6. 6
    On a 491 to a re-INVITE the UAC should wait a random 2.1 to 4 seconds if it owns the Call-ID, or 0 to 2 seconds if it does not, then retry the re-INVITE once more if it still wants the change.
    RFC 3261 — SIP: Session Initiation Protocol · Section 14.1 (UAC Behavior), 491 timer paragraph · Checked 2026-09-30
  7. 7
    When a stream is offered as sendonly, the answer MUST mark the corresponding stream recvonly or inactive; when offered as recvonly, the answer MUST mark it sendonly or inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 (Unicast Streams) · Checked 2026-09-30
  8. 8
    When a stream is offered as sendrecv, the answer MAY mark it sendonly, recvonly, sendrecv or inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 · Checked 2026-09-30
  9. 9
    Attended transfer uses an escaped Replaces header field inside the Refer-To header so that the new Transferee-to-Target dialog replaces the Transferor-to-Target dialog.
    RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer · Section 7 (Transfer with Consultation Hold), attended transfer · Checked 2026-09-30
  10. 10
    If no session refresh arrives, the side not performing refreshes should send BYE slightly before the session expires; the recommended margin is the smaller of 32 seconds and one third of the session interval.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 10 (Performing Refreshes) · Checked 2026-09-30
  11. 11
    midcall-signaling block blocks all mid-call media-related signaling to the SIP trunk, rejects video escalation and T.38, and Cisco says to configure it only when basic calling is the focus and mid-call signaling can be consumed.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Mid-call Signaling Block · Checked 2026-09-30
  12. 12
    With midcall-signaling block and media flow-around both configured, CUBE rejects a mid-call INVITE with a 488 error.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Restrictions for Mid-call Signaling Block · Checked 2026-09-30
  13. 13
    CUBE mid-call signaling modes can be set globally under voice service voip > sip (midcall-signaling ...) or per dial peer (voice-class sip midcall-signaling ...).
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Configuring Mid-call Signaling sections (global and dial-peer) · Checked 2026-09-30
  14. 14
    CUBE's mid-call signaling feature exists to reduce interoperability problems by consuming mid-call re-INVITEs and UPDATEs instead of forwarding them; it offers three modes: passthru media-change, block and preserve-codec.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Overview · Checked 2026-09-30
  15. 15
    With midcall-signaling passthru media-change, CUBE passes a re-INVITE to the other leg only when bidirectional media such as T.38 or video is added, and consumes re-INVITEs that only change media direction.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Mid-call Signaling Passthrough - Media Change · Checked 2026-09-30
  16. 16
    In passthru media-change mode, re-INVITEs are not consumed when media flow-around or media anti-tromboning is configured, and SDP passthrough, video transcoding and multicast music on hold are unsupported.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Restrictions for Mid-call Signaling Passthrough - Media Change · Checked 2026-09-30
  17. 17
    midcall-signaling preserve-codec disables mid-call codec negotiation and keeps the codec negotiated before the call.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Mid-call Signaling Codec Preservation · Checked 2026-09-30
  18. 18
    When CUBE mid-call signaling consumption is configured, session timer handling is done leg by leg.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Mid-call Signaling · Mid-call Signaling Passthrough - Media Change, behaviour list · Checked 2026-09-30
  19. 19
    A media stream with no direction attribute at media or session level is sendrecv by default.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 · Checked 2026-09-30
  20. 20
    Since a change in June 2026, for blind transfers Microsoft terminates the original call immediately after the SBC accepts the transfer, without waiting for the transfer's final result; the page points to Message Center post MC1296872.
    Issues with call transfers - Microsoft Teams · Calls drop before the transfer is completed, final paragraph · Checked 2026-09-30
  21. 21
    Microsoft notes a session timer failure can sit elsewhere in the path, such as at a PSTN carrier, which sends BYE to the SBC; the SBC relays it and the SIP proxy ends the call, so the fix is to find the source of the BYE.
    Issues that affect inbound Direct Routing calls · Calls drop after several minutes > Resolution, second paragraph · Checked 2026-09-30
  22. 22
    For a consultative transfer, the Microsoft SIP proxy ends the original call with BYE once it receives a NOTIFY from the SBC carrying a SIP 200 OK payload, so the SBC must send 202 Accepted and NOTIFY progress updates.
    Issues with call transfers - Microsoft Teams · Calls drop before the transfer is completed · Checked 2026-09-30
  23. 23
    Microsoft attributes a Direct Routing call that drops without an error code after roughly 10 to 60 minutes to a session timer or session refresh problem tied to the Session-Expires header: the call ends at the stated time unless a reinvite refreshes it first.
    Issues that affect inbound Direct Routing calls · Calls drop after a specific duration > Calls drop after several minutes · Checked 2026-09-30
  24. 24
    When a media bypass call is transferred to a Skype for Business, Teams Web or Teams VDI client, Direct Routing inserts a Media Processor and starts an ICE restart by changing ice-pwd and ice-ufrag and offering new candidates in a reinvite; the SBC must support ICE restarts.
    Teams Phone System Direct Routing: SIP protocol · ICE Restart: Media bypass call transferred to an endpoint that doesn't support media bypass · Checked 2026-09-30
  25. 25
    Teams Direct Routing does not support Delayed Offer INVITE (an INVITE without SDP).
    Teams Phone System Direct Routing: SIP protocol · Inbound call: SIP dialog description > Non-media bypass flow, second Note · Checked 2026-09-30
  26. 26
    A REFER from Microsoft can arrive from any Microsoft signalling IP address on a new TLS connection, even if the earlier part of the call came from a different address, so firewall and SBC rules must allow all Microsoft signalling addresses.
    Issues with call transfers - Microsoft Teams · No SIP REFER received by the SBC from the SIP proxy, step 2 · Checked 2026-09-30
  27. 27
    After receiving a REFER from the Microsoft SIP proxy, the SBC must send the new INVITE back to the SIP proxy, not to the PSTN or any other destination, even when the transfer target is an external PSTN number.
    Issues with call transfers - Microsoft Teams · Call transfer methods, REFER process step 2 · Checked 2026-09-30
  28. 28
    Having the SBC handle REFER is Microsoft's preferred transfer method, is mandatory for media bypass certification, and transfer without SBC REFER handling is not supported in media bypass mode.
    Teams Phone System Direct Routing: SIP protocol · Call transfer > SIP proxy send the Refer to the SBC and acts as a Transferor · Checked 2026-09-30
  29. 29
    The SBC must set the new INVITE's Request-URI only to the string in the Refer-To header, include the Referred-By header, and copy both strings from the REFER without changing them.
    Issues with call transfers - Microsoft Teams · Call transfer methods, REFER process steps 3 to 5 · Checked 2026-09-30
  30. 30
    Per Microsoft, refresher=uac means the party that sent the INVITE must send the refresh reinvite, refresher=uas means the party that received it must, and reinvites are usually sent at the halfway point of the session timer.
    Issues that affect inbound Direct Routing calls · Calls drop after several minutes, Note · Checked 2026-09-30
  31. 31
    Microsoft says media bypass and Local Media Optimization require several reinvites by design, and that a reinvite from the SBC arriving at the SIP proxy in the wrong order or at the wrong time creates a race condition that lengthens negotiation and delays audio.
    Issues that affect inbound Direct Routing calls · Delay when answering PSTN calls in Teams · Checked 2026-09-30
  32. 32
    Microsoft's Direct Routing SIP protocol article states that Direct Routing rejects SIP requests that have Replaces headers and tells administrators to make sure the SBC is not using them.disputed
    Teams Phone System Direct Routing: SIP protocol · Processing the incoming request: finding the tenant and user, Note, third bullet · Checked 2026-09-30
  33. 33
    The same Microsoft article states that the SBC must support INVITE with Replaces, and Microsoft's transfer troubleshooting page lists INVITE with a Replaces header as the second-preference transfer method.disputed
    Teams Phone System Direct Routing: SIP protocol · Replaces option · Checked 2026-09-30
  34. 34
    The Microsoft 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.
    Teams Phone System Direct Routing: SIP protocol · Session timer · Checked 2026-09-30
  35. 35
    Microsoft lists two causes for Direct Routing calls dropping before a transfer completes: the SIP proxy times out because the SBC sent no 202 Accepted or NOTIFY for the REFER, or the SBC's BYE arrives too early.
    Issues with call transfers - Microsoft Teams · Calls drop before the transfer is completed · Checked 2026-09-30
  36. 36
    Teams Direct Routing chooses its transfer method from the capabilities the SBC advertises: if the SBC's Allow header includes REFER, the SIP proxy sends REFER to the SBC and acts as Transferor; otherwise the proxy handles the transfer itself as Referee.
    Teams Phone System Direct Routing: SIP protocol · Call transfer · Checked 2026-09-30
  37. 37
    When a transfer fails, the Transferee reports the failure to the Transferor in a NOTIFY and the Transferor resumes the held session with an unhold re-INVITE.
    RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer · Section 6, failed-transfer call flow (subsection number reported as 6.3; unconfirmed) · Checked 2026-09-30
  38. 38
    The conventional acknowledgement of a hold offer carrying a=sendonly is an answer carrying a=recvonly; RFC 6337 notes RFC 3264 describes this in non-normative language.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.3 (Hold and Resume of Media) · Checked 2026-09-30
  39. 39
    A stream that was previously recvonly is placed on hold by marking it a=inactive.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8.4 · Checked 2026-09-30
  40. 40
    Under the SDP offer/answer model, a stream that was sendrecv is placed on hold by sending a new offer that marks it a=sendonly.
    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-30
  41. 41
    The Webex Calling Local Gateway article describes a diagnostic signature, reported by the fetch as DS 65221, that detects abnormal call disconnects with SIP errors 403, 488 and 503.
    Configure Local Gateway on Cisco IOS XE for Webex Calling · Implement diagnostic signatures > Monitor abnormal call disconnects · Checked 2026-09-30
  42. 42
    Cisco's Webex Calling Local Gateway configuration article includes the command 'no session refresh', described as disabling SIP session refresh for calls between CUBE and Webex.
    Configure Local Gateway on Cisco IOS XE for Webex Calling · Webex tenant configuration, 'no session refresh' command explanation · Checked 2026-09-30
  43. 43
    When the Min-SE header field is absent its default value is 90 seconds.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 5 (Min-SE Header Field Definition) · Checked 2026-09-30
  44. 44
    A modified SDP offer MUST keep a matching media stream for every stream in the previous SDP, and the version in the origin (o=) field MUST increment by 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-30
  45. 45
    An agent MUST NOT generate a new offer while it has received an offer it has not yet answered or rejected, or while it has sent an offer that has not yet been answered or rejected.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 4 (Protocol Operation) · Checked 2026-09-30
  46. 46
    An offer sent in response to an offerless re-INVITE should include all codecs the UA is currently willing and able to use, not only those negotiated in earlier offer/answer exchanges.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.2.5 · Checked 2026-09-30
  47. 47
    A successful REFER transaction does not terminate the session between Transferor and Transferee; ending that session requires a subsequent BYE.
    RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer · Section 5, as reported by the fetch (confirm section number) · Checked 2026-09-30
  48. 48
    It is RECOMMENDED that the refresher send the session refresh once half the session interval has elapsed.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 7.2, as reported by the fetch (confirm subsection) · Checked 2026-09-30
  49. 49
    If a session refresh request times out or receives a 408 or 481 response, the UAC sends a BYE.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 10 (Performing Refreshes) · Checked 2026-09-30
  50. 50
    For session refresh, UPDATE is RECOMMENDED over re-INVITE when the peer is known to support it; a refresh UPDATE is recommended to carry no offer, whereas a refresh re-INVITE SHOULD contain one.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 7.4 (Generating Subsequent Session Refresh Requests) · Checked 2026-09-30
  51. 51
    If a re-INVITE is rejected with a non-2xx final response, no session state change is made and the session continues with its previously negotiated parameters.
    RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) · Section 3.1 (Background on Re-INVITE Handling by UASs), citing RFC 3261 Section 12.2.2 · Checked 2026-09-30
  52. 52
    The absolute minimum Session-Expires value is 90 seconds and 1800 seconds (30 minutes) is RECOMMENDED.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 4 (Session-Expires Header Field Definition) · Checked 2026-09-30
  53. 53
    SIP session timers are a keepalive: user agents send periodic re-INVITE or UPDATE requests, called session refresh requests, to keep the session alive.
    RFC 4028: Session Timers in the Session Initiation Protocol (SIP) · Section 1 (Introduction) · Checked 2026-09-30
  54. 54
    RFC 6337 warns that unless a UA offers a=sendrecv when it has no hold of its own to maintain, calls can become stuck on hold, especially when a third-party call controller is involved.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.3, concluding paragraph · Checked 2026-09-30
  55. 55
    In the basic transfer flow the Transferor first places the Transferee on hold with a re-INVITE and then sends a REFER naming the Transfer Target.
    RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer · Section 6 (Basic Transfer) · Checked 2026-09-30
  56. 56
    A UAC that receives an error response to a re-INVITE for which changes were already executed SHOULD send a new re-INVITE or UPDATE so both user agents share the same view of the session state.
    RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) · Section 3.4 (UAC Behavior) · Checked 2026-09-30
  57. 57
    If any change requested in a re-INVITE, or in a transaction within it, has already been executed, the UAS SHOULD return a 2xx response rather than an error.
    RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) · Section 3.3 (UAS Behavior) · Checked 2026-09-30
  58. 58
    A UAS should return an error response to a re-INVITE only if no session state changes have been executed since the re-INVITE was received.
    RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) · Section 3.3 (UAS Behavior) · Checked 2026-09-30
  59. 59
    Signalling hold by setting the SDP connection address to 0.0.0.0 is the RFC 2543 method and is no longer recommended, because it prevents RTCP on held streams, does not work with IPv6 and breaks connection-oriented media.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8.4 · Checked 2026-09-30
  60. 60
    An agent is still required to be able to receive SDP with a connection address of 0.0.0.0, which means neither RTP nor RTCP should be sent to the peer.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.4 · Checked 2026-09-30

Documents

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 4028: Session Timers in the Session Initiation Protocol (SIP)

IETF / RFC Editor · 2005-04-01 · accessed 2026-09-30

tier 1 standards and regulators

RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer

IETF / RFC Editor · 2009-06 · accessed 2026-09-16

tier 1 standards and regulators

RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)

IETF / RFC Editor · 2011-03-01 · accessed 2026-09-30

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-30

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

Configure Local Gateway on Cisco IOS XE for Webex Calling

Cisco Systems, Inc. (Webex Help Center) · 2026-07-09 · accessed 2026-09-04

tier 2 current vendor documentation

Issues that affect inbound Direct Routing calls

Microsoft · 2026-06-30 · accessed 2026-09-25

tier 2 current vendor documentation

Issues with call transfers - Microsoft Teams

Microsoft · 2026-08-31 · accessed 2026-09-25

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 30). Troubleshooting calls that drop on hold or transfer. WarmTransfer. https://warmtransfer.net/knowledge/sip-reinvite-call-drops

BibTeX

@misc{warmtransfer-sip-reinvite-call-drops,
  title  = {Troubleshooting calls that drop on hold or transfer},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sip-reinvite-call-drops},
  note   = {Verified 2026-09-30}
}