Re-INVITE Handling draft-camarillo-sipping-reinvite-00.txt

To Roll Back or not to Roll Back: That is the Question What are the semantics of an error response to a re-INVITE? Section of RFC 3261 says: Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed. What are the state changes associated with a re-INVITE?

State Changes Changes performed by the re-INVITE and any transactions within it –Dialog target refreshes Generally accepted that target refreshes are special and are never rolled back –Offer/answer exchanges

Situation as Specified Today Initial INVITEs and Re-INVITEs are treated equally –The semantics are based on the method, which is INVITE Full Roll Back –Error response (e.g., 4xx)

Two issues The error response modifies the session parameters but cannot be rejected by the UAC Offer/answer glare detection mechanisms do not consider error responses

The Session Modification Cannot be Rejected On receiving a 4xx, the UAC may not be able to return to the pre-re-INVITE state –Similar issue as offers in 2xx responses to re- INVITEs, described in Section 14.2 of RFC 3261 The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. –The pre-re-INVITE state may not overlap with the current state (e.g., IP address change)

Solution The UAC ACKs and sends an UPDATE right away If the UPDATE beats the ACK (not shown in the figure), the UAS thinks it is a glare situation –New UPDATE needed This whole issue is generally considered to be minor

Glare Conditions (1) UAS notices the glare and rejects the UPDATE. State remains in synch in both scenarios.

Glare Conditions (2) UAC notices the glare. State may (left) or may not (right) remain in synch. UAC generates a new UPDATE (just in case) to get both states in synch.

Glare Conditions (3)

Alternatives to Address These Issues 1.Clarify how to use the current specs to avoid them 2.Specify new different semantics for error responses to re-INVITEs Additional proposals

Additional Proposals Classify session modifications into different categories and specify different rules for different categories Complex in a number of ways –Need logic to classify session modifications and apply the rules specific to each particular modification –Newly defined parameters would need to be classified as well –Impossible to understand the current state by just looking the call flow; details about the messages would be needed

1. Clarify Current Specifications It is clear that –If all the changes requested in a re-INVITE and the transactions within it were executed The UAS generates a 2xx response –If none of the changes were executed The UAS generates an error response What should the UAS generate if some of the changes were executed?

UAS Behavior If changes have already been executed –Dont return an error response to the re-INVITE –UPDATE (OK) to the re-INVITE instead E.g., Accept new IP address but reject video stream (left) Full rollback (right)

CANCEL Handling A CANCEL request triggers a 487 response to the re-INVITE –The 487 response triggers a full rollback –No glare condition possible since UAC knows it is cancelling the re-INVITE If some changes have been executed, the UAS can return a 200 OK to the re-INVITE –This is backwards compatible

Backwards Compatibility There has been changes but the UAC receives an error response anyway –UAC is talking to a legacy UAS UAC can send a new UPDATE to be completely sure that both sides are in synch –This addresses the potential glare condition

2. Specify New Different Semantics Error responses to re-INVITEs do not trigger any rollback The session parameters in use would be the same before and after the error response

Problems (1) Semantics of an error response to an initial INVITE and to a re-INVITE would be different –Initial INVITEs are rolled back (i.e., early media disappears) Legacy UACs would perform a roll back per RFC 3261 while new UASs would not

Problems (2) In normal circumstances (i.e., no preconditions), an error response and a 2xx response to a re- INVITE would have exactly the same effect –We would be creating a new mechanism to do something an existing mechanism already does –CANCEL for re-INVITEs would not have any effect –With preconditions, the error response would stop the precondition negotiation for un-met preconditions

Way Forward? 1.Clarify how to use the current specs Full roll back 2.Specify new different semantics for error responses to re-INVITEs No roll back

Media State under Preconditions draft-camarillo-sipping-precon-00.txt

Background States of a media stream –Preconditions not met –Preconditions met –Media parameters in use Session establishment (initial INVITE) –183 Session Progress –180 Ringing The preconditions for all streams have been met –200 OK

Session Modification Preconditions met –Preconditions signalling informs the UAS when the preconditions on the UACs side have been met –If requested by the UAC, informs the UAC when the preconditions on the UASs side have been met New media parameters in use –UAS starts using them –UAC notices it at the media level –200 OK response to the re-INVITE

Issue The UAS can start using new media parameters before sending the 200 OK to the re-INVITE –Audio-only session –Change in IP address plus addition of video –The change in IP address for the audio stream requires that Its preconditions are met –The addition of the video stream requires that Its preconditions are met The user accepts it Intermediaries (e.g., B2BUAs) cannot know when the new parameters start being used –A similar issue was found in previous specs of ICE; the SIP signalling was not explicit enough for intermediaries to do the right thing

Typical Message Flow

Explicit Message Flow

Message Details How to signal that a stream is in use Removing the precondition attributes –Regular semantics of a stream in plain SDP m=audio RTP/AVP 0 c=IN IP a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv Preconditions met m=audio RTP/AVP 0 c=IN IP Stream in use