Subject: [Sipping] Proposed Addition to Replaces header

From: Rohan Mahy <[email-masked]>
Date: Wed, 25 Jun 2003 15:49:03 -0700

Hi,

I am now making a few small edits to Replaces in response to AD review  
(mostly security clarifications).

In an earlier thread, Venkatesh described a race condition with using  
Replaces for Call Pickup. We have a few options for dealing with the  
issue he raised:

1) provide a "state" parameter in the Replaces header which has a list  
or states that are acceptable for the dialog to "match".  for example:
	Replaces: xyz;to-tag=123;from-tag=456;state="early,confirmed"

2) provide an "early-only" parameter in the Replaces header which only  
matches for early dialogs.

3) live with the race condition as is

Replaces is only defined for early and confirmed dialogs.  We have a  
number of cases where the UAC doesn't care which of these target dialog  
is in (state="early,confirmed").  Venkatesh gave an example where we  
only want to match for early dialogs (state="early"), but I could not  
come up with any application where the UAC only wanted to match is the  
dialog is confirmed (since the dialog will never transition from  
confirmed to early, there is no race condition).  Based in this I am  
recommending we go with option #2.  Unless I hear any strong objections  
I will make appropriate changes and submit a version with this approach  
on Friday.

many thanks,
-rohan

> Per section 2.16 of the
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service- 
> examples-04.t
> xt draft, call pick up is acheived by using a INVITE with Replaces  
> header.
> An INVITE with Replaces header is also used for consultative  
> transfers. A UA
> that receives the a INVITE with Replaces header attempts to match an
> existing dialog with details provided in the replaces header and if  
> found
> accept the same, it then proceeds to tear down the existing dialog.  
> However,
> the call flow for pick up presented in 2.16  is prone to race  
> conditions
> which could produce undesirable end user behavior.
>
> Per the example in 2.16:
>
> 1. Alice calls Bob. Bob's phone is ringing.
> 2. Carol decides to pick the call.
> 3. Carol sends a SUBSCRIBE to Bob's dialog state. Bob's UA sends out a
> NOTIFY providing the dialog details.
> 4. Carol initiates a INVITE with Replaces header.
>
> However, between step 3 and step 4, it could so happen that Bob  
> decided to
> pickup his phone to answer the call. The call is established and the  
> two
> start talking..... Now the INVITE with Replaces (step 4)  comes along.
> Alice's UA accepts this request, tears down the session with Bob and  
> the
> call gets established with Carol. This produces undesirable results  
> from a
> end user perspective.
>
> Would it be a good idea to extend the Replaces header to contain the  
> dialog
> state based on the dialog state draft as well so that the recipient can
> compare the dialog identifiers AND the dialog state to decide whether  
> to
> allow the same or not?
>
> regards,
> Venkatesh

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP