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

1. Gonzalo.Camarillo@ericsson.com Re-INVITE Handlingdraft-camarillo-sipping-reinvite-00.txt

2. 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 12.2.2 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?

3. 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

4. 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)

5. 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

6. 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)

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

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

9. 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.

10. Glare Conditions (3)

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

12. 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

13. 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?

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

15. 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

16. 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

17. 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

18. 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

19. 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

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

21. Gonzalo.Camarillo@ericsson.com Media State under Preconditionsdraft-camarillo-sipping-precon-00.txt

22. 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

23. Session Modification • Preconditions met • Preconditions signalling informs the UAS when the preconditions on the UAC’s side have been met • If requested by the UAC, informs the UAC when the preconditions on the UAS’s 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

24. 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

25. Typical Message Flow

26. Explicit Message Flow

27. 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 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv Preconditions met m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 Stream in use