SIP Protocols & StandardsKnowledge baseGeneric SIP · RFC 3261 / RFC 4028

Understanding In-Dialog Re-INVITE Requests in SIP

Overview

This guide provides a comprehensive technical overview of in-dialog re-INVITE requests within the Session Initiation Protocol (SIP). Readers will learn how re-INVITEs alter established dialog states, manage SDP media renegotiation, handle SIP glare scenarios, and execute common VoIP features such as call hold, session keep-alives, and T.38 fax switchover.

Illustration for Understanding In-Dialog Re-INVITE Requests in SIP

Key takeaways

In-dialog re-INVITEs share the existing dialog identifiers (Call-ID, From tag, To tag) but increment the CSeq counter.
Common applications include modifying media directionality (hold/resume), changing IP/port endpoints, renegotiating codecs, and driving RFC 4028 Session Timers.
SDP offer/answer rules apply fully: a re-INVITE can carry an updated offer, or it can be sent without SDP to solicit an offer in the 200 OK response.
SIP glare occurs when both peers transmit a re-INVITE concurrently; it is resolved via a 491 Request Pending status code and randomized backoff timers.

Prerequisites

Fundamental understanding of SIP call setup (INVITE, 200 OK, ACK).
Familiarity with the SDP Offer/Answer model (RFC 3264).
Basic comprehension of SIP dialog parameters (Call-ID, From/To tags, Request-URI).

Guide

section #1
Architecture and Matching Criteria of an In-Dialog Re-INVITE An in-dialog re-INVITE is a standard SIP INVITE request transmitted within an already established SIP dialog. According to RFC 3261 Section 14, a SIP request is identified as 'in-dialog' when its Call-ID header, From tag, and To tag match the parameters stored in the dialog state table established by the initial 2xx response. Crucially, the Request-URI of the re-INVITE must target the remote contact URI established during the initial dialog setup (or updated by a subsequent target-refresh request). The CSeq header field must contain the same method name (INVITE) but with a strictly incremented sequence number relative to previous requests originated by that endpoint within the dialog.
```
INVITE sip:alice@192.168.1.50:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK-reinv-01
Max-Forwards: 70
From: <sip:bob@example.com>;tag=src-tag-1234
To: <sip:alice@example.com>;tag=dst-tag-5678
Call-ID: c3a900a12000-dialog-id@192.168.1.20
CSeq: 102 INVITE
Contact: <sip:bob@192.168.1.20:5060>
Content-Type: application/sdp
Content-Length: 230
```
section #2
Media renegotiation and SDP Modification The primary role of a re-INVITE is to modify session parameters mid-call without disrupting the underlying control relationship. The accompanying Session Description Protocol (SDP) body can introduce changes to media streams, such as altering RTP IP addresses or ports (for call transfer or session anchoring updates), changing media codecs (e.g., switching from G.729 to G.711u), or updating media directionality attributes. For instance, to place a call on hold, an endpoint sends a re-INVITE containing an SDP offer where the media stream attribute is updated to 'a=sendonly' or 'a=inactive'. Upon receiving a 200 OK with matching answer parameters, the media path is updated immediately.
```
v=0
o=bob 2890844526 2890844527 IN IP4 192.168.1.20
s=SIP Call
c=IN IP4 192.168.1.20
t=0 0
m=audio 40002 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendonly
```
section #3
Common Operational Use Cases In-dialog re-INVITEs are leveraged across several essential VoIP functionalities. Beyond call hold and resume ('a=sendrecv'), re-INVITEs execute mid-call codec changes and media plane re-anchoring when an SBC redirects RTP streams directly between endpoints (direct media or reinvite-offload). Additionally, RFC 4028 Session Timers regularly issue periodic re-INVITEs (or UPDATE requests) as keep-alives to detect stale dialogs caused by silent network outages. Another crucial application is T.38 fax switchover: upon detecting fax tones (CNG/CED), a VoIP gateway sends a re-INVITE changing the media stream from 'm=audio' to 'm=image 40000 udptl t38'.
section #4
Offer/Answer Dynamics: Early Offer vs. Delayed Offer in Re-INVITEs The SDP Offer/Answer model (RFC 3264) governs how media capabilities are negotiated during a re-INVITE exchange. In an 'Early Offer' re-INVITE, the initiator includes an SDP payload containing the new offer directly inside the re-INVITE request; the target peer responds with its SDP answer inside the 200 OK. Conversely, in a 'Delayed Offer' re-INVITE, the initiator sends the re-INVITE without an SDP payload. The target endpoint is then forced to generate an SDP offer inside its 200 OK response, and the original initiator completes the negotiation by returning an SDP answer inside the final ACK request.
```
Delayed Offer Re-INVITE Sequence:
Initiator                  Target
    |                         |
    |------ re-INVITE ------->|  (No SDP)
    |<------ 200 OK ----------|  (SDP Offer)
    |------- ACK ------------>|  (SDP Answer)
    |                         |
```
section #5
Handling Glare Conditions (491 Request Pending) A SIP 'glare' condition arises when both endpoints in an established dialog send a re-INVITE to each other simultaneously before receiving the remote end's request. Because neither endpoint can process an incoming re-INVITE while its own re-INVITE transaction is outstanding, RFC 3261 dictates that both parties must resolve this race condition predictably. Upon detecting an incoming re-INVITE while waiting for a response to an outgoing re-INVITE, an endpoint should reject the incoming request with a '491 Request Pending' response. The endpoints then schedule a retry using randomized backoff timers based on who initiated the original dialog (the owner waits between 2.1 and 4.0 seconds, while the non-owner waits between 0.0 and 2.0 seconds).
```
Endpoint A                 Endpoint B
    |                         |
    |--- re-INVITE (CSeq 102)->|  (Simultaneous issue)
    |<-- re-INVITE (CSeq 205)--|
    |
    |--- 491 Request Pending->|  (A rejects B's re-INVITE)
    |<-- 491 Request Pending--|  (B rejects A's re-INVITE)
    |
    |  [Randomized Timer]     |  (Owner vs. Non-Owner)
    |                         |-- re-INVITE --> (Retry)
```
section #6
Session Border Controller (SBC) and Proxy Considerations SBCs and B2BUAs (Back-to-Back User Agents) handle in-dialog re-INVITEs with specific policy considerations. When an SBC provides topology hiding, it rewrites the SDP connection details (`c=` lines) and media ports to force RTP media to stay anchored at the SBC rather than leaking private internal IP structures. If an SBC receives a re-INVITE requesting a codec modification that the remote peer or carrier trunk does not support, the SBC may either transcode the media stream locally or absorb and reject the re-INVITE with a 488 Not Acceptable Here status code without forwarding the invalid request downstream.

Understanding In-Dialog Re-INVITE Requests in SIP

Overview

Key takeaways

Prerequisites

Guide

Further reading