Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (26)
A UAS that has already executed changes within a re-INVITE must not return an error response to undo them, because an error response is effectively requesting a session state change that the UAC cannot reject if it cannot execute the reversion — the UAC has no mechanism to communicate that failure to the UAS.
ACK routing for non-2xx final responses is fixed at re-INVITE send time via Via headers, independent of any target refresh that occurs mid-transaction. This is why a UAS that loses its old contact cannot receive the ACK, requiring special recovery procedures rather than normal dialog termination.
Piggybacking a target refresh with complex session changes in a single request is discouraged because it forces the remote UA into an all-or-nothing situation, making it unnecessarily hard to accept the target refresh while rejecting only the session modifications.
Target-refresh requests are explicitly non-atomic: even if a re-INVITE ends with a final error response, a remote target update conveyed in a prior reliable provisional response may have already taken effect. This is by design to allow UASs to authenticate target-refresh requests via challenge-response without losing the new target.
A UAC receiving an error response to a re-INVITE that undoes already executed changes may be facing a legacy UAS that does not implement RFC 6141. The UAC should treat this the same as a race condition and issue a synchronizing re-INVITE or UPDATE.
In glare situations, the UAS returns 491 (Request Pending) and the UAC retries after a randomly selected time interval determined by which UA owns the Call-ID. RFC 3311 extends these glare rules to cover collisions between an UPDATE carrying an offer and another offer-carrying message (UPDATE, PRACK, or INVITE).
Unreliable provisional responses to target-refresh requests must not be used to refresh the dialog's remote target. Consequently, a UAC on an established early dialog will not perform a target refresh upon receiving an unreliable provisional response with an updated Contact header.
A change to session state is considered executed when an offer/answer exchange without preconditions has completed successfully, or when the UA has sent or received media using the new parameters. TCP SYN messages, ICE connectivity checks, and precondition signaling are not considered media.
A UA SHOULD NOT use the same target-refresh request to both refresh the target and make complex session changes, unless those changes can be trivially accepted. Only when the target-refresh is a re-INVITE and the UAS supports reliable provisional responses or UPDATE MAY the UAC piggyback session changes.
A UAC that accepts a target refresh within a re-INVITE MUST ignore transport and timeout errors when generating an ACK for a non-2xx final response. Additionally, the UAC SHOULD generate a new re-INVITE to ensure both UAs share a common view of the session state.
A UAC that loses its contact during an ongoing re-INVITE SHOULD generate a CANCEL to cancel the re-INVITE and transition the INVITE client transaction to Terminated, then SHOULD send a new re-INVITE to synchronize session state with the UAS.
A UAC that receives an error response to a re-INVITE for which changes have already been executed SHOULD generate a new re-INVITE or UPDATE request to synchronize both UAs. The offer in this new exchange SHOULD reflect session parameters as close to the pre-re-INVITE state as possible.
A UAS SHOULD only return an error response to a re-INVITE if no changes to the session state have been executed since the re-INVITE was received. Such an error response indicates that no changes were executed as a result of the re-INVITE or any transaction within it.
A UAS that accepts a target refresh within a re-INVITE and never receives an ACK after sending a final response SHOULD NOT terminate the dialog if a new re-INVITE with a higher CSeq sequence number has been received.
If a re-INVITE is CANCELed and some of its requested changes had already been executed, the UAS returns a 2xx response per the Section 3.3 rules, rather than the 487 (Request Terminated) response that RFC 3261 specifies at the SHOULD level for CANCELed INVITEs.
If a UA generates an error response to a target-refresh request, the UA MUST NOT update its dialog's remote target URI.
If a UA receives a reliable provisional or 2xx response to a target-refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field, if present. If the UA receives an unreliable provisional response, it MUST NOT refresh the dialog's remote target.
If any of the changes requested in a re-INVITE or in any transaction within it have already been executed, the UAS SHOULD return a 2xx response rather than an error response. Using an error response in this case is prohibited because the UAC cannot reject a forced revert it cannot execute.
It is RECOMMENDED that when a UAS decides to start using new parameters for a stream for which all mandatory preconditions have been met, the UAS either sends media using the new parameters or sends a new offer with precondition-related attributes removed, to signal that the parameters are in use.
To avoid race conditions between response-based and request-based target refreshes, if the protocol permits a UA to use a target-refresh request at the point it wishes to refresh its local target, the UA MUST use a target-refresh request rather than a response for the refresh.
When a properly authenticated target-refresh request is received, the UA SHOULD generate a reliable provisional or 2xx response. If not possible, it SHOULD send an in-dialog request using the new remote target. On doing so, the UA MUST replace the dialog's remote target URI with the URI from the Contact header of the target-refresh request.
A dialog's local target URI is the SIP or SIPS URI recorded by a UA at which the peer can communicate with it, equal to the URI in the Contact header of requests and responses the UA sends. The remote target URI is the complementary URI from messages received from the peer.
A re-INVITE is an INVITE request sent within an existing dialog to modify session parameters (e.g., IP address for a media stream), dialog parameters (e.g., the remote target URI), or both. It carries an offer/answer exchange and is a target-refresh request.
A target-refresh request is any SIP request sent within a dialog that can modify the remote target of the dialog. re-INVITEs are target-refresh requests; 2xx responses to target-refresh requests can also update the remote target.
re-INVITEs and UPDATE requests SHOULD be secured using a mechanism equivalent to or stronger than the initial INVITE that created the session. If the initial INVITE was end-to-end integrity protected or encrypted, subsequent re-INVITEs and UPDATE requests should be as well to avoid downgrading session security.
UAS re-INVITE handling has two behavioral states based on whether changes have been executed: (1) 'no changes executed' — UAS may return an error response or 2xx; (2) 'changes executed' — UAS MUST return 2xx and use UPDATE to undo unwanted changes rather than issuing an error response.