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

Re-INVITE Handling

draft-camarillo-sipping-reinvite-00.txt

[email protected]

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?

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)

UAC

(1) INVITE SDP1

UAS

(4) 200 OK SDP4

(3) UPDATE SDP3

(2) 183 Session Progress SDP2

(5) 4xx

(6) ACK

State1

State2

State3

State1

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

UAC

(1) re-INVITE SDP1

UAS

(5) UPDATE SDP3

(6) 200 OK SDP4


(3) 4xx

(4) ACK

• 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)UAC

(1) re-INVITE SDP1

UAS

(6) ACK


(4) UPDATE SDP3

(3) 4xx

(5) 4xx

UAC

(1) re-INVITE SDP1

UAS


(3) UPDATE SDP3 (4) 4xx

(5) ACK(6) 4xx

UAS notices the glare and rejects the UPDATE.

State remains in synch in both scenarios.


(1) re-INVITE SDP1

UAS

(6) 200 OK SDP4


(3) UPDATE SDP3

(4) 4xx

(5) ACK

UAC

(1) re-INVITE SDP1

UAS


(3) UPDATE SDP3

(5) 4xx

(4) 200 OK SDP4

(6) ACK

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.


(1) re-INVITE SDP1

Proxy

(6) UPDATE SDP3

(10) 200 OK SDP4


UAS

(2) re-INVITE SDP1


(7) ACK

(5) 4xx

(8) UPDATE SDP3

(11) 200 OK SDP4

(9) 4xx

(12) ACK

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

– 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)

UAC

(1) re-INVITE SDP1

UAS

(3) UPDATE SDP3

(4) 200 OK SDP4


(5) 200 OK

(6) ACK

State1

State2

State1

State1

UAC

(1) re-INVITE SDP1

UAS

(3) UPDATE SDP3

(4) 200 OK SDP4


(5) 200 OK

(6) ACK

State1

State2

State3

State3

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

UAC

(1) re-INVITE SDP1

UAS

(4) 200 OK SDP4

(3) UPDATE SDP3


(5) 4xx

(6) ACK

State1

State2

State3

State3

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

[email protected]

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

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 FlowUAC

(1) re-INVITE SDP1

UAS


(5) 200 OK(6) ACK

(3) UPDATE SDP3

(4) 200 OK SDP4Preconditions met

New audio parameters in use

Video stream in use

Explicit Message FlowUAC

(1) re-INVITE SDP1

UAS

(5) UPDATE SDP3

(6) 200 OK SDP4


(9) 200 OK(10) ACK

(3) UPDATE SDP3

(4) 200 OK SDP4Preconditions met

(7) UPDATE SDP3

(8) 200 OK SDP4

New audio parameters in use

Video stream in use

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

Documents

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