[Sip] Re: draft-ietf-sip-replaces-04.txt

[Rohan Mahy <[e-mail]>]

On Monday, August 18, 2003, at 10:24 AM, Paul Kyzivat wrote:

> Here is another point that I find fuzzy, in Section 3:
>
>   "If the Replaces header field matches an early dialog that was not
>    initiated by this UA, it returns a 481 (Call/Transaction Does Not
>    Exist) response to the new INVITE, and leaves the matched dialog
>    unchanged. Note that since Replaces matches only a single dialog, 
> the
>    replacement dialog will not be retargeted according to the same
>    forking logic as the original request which created the early
>    dialog.
>    (Currently no use cases have been identified for replacing just a
>    single dialog in this circumstance.)"
>
> I don't know how to interpret this. Suppose X sent an invite to Y, and 
> Y returned a 183 establishing an early dialog. I think you are saying 
> that an INVITE/Replaces referencing this dialog should be rejected if 
> received by one of these UAs, but which one?
>
> (X initiated the invitation which resulted in the dialog, but Y sent 
> the response with a To-tag that actually initiated the specific 
> dialog.)

No, the spec is pretty clear on this.  X initiated the dialog.  Y 
caused the dialog to become an early dialog.  If you can come up with a 
rewording which is more precise and still clear, I am happy to 
incorporate it.

> In example 7.1 Alice, who is in the role of X above, answers the 
> invite/replaces. This implies that you intend to have the party in 
> role Y refuse the replacement.

I don't follow you here.

> But in Section 4 I see:
>
>    For example, if Alice replaces Cathy in an early dialog with Bob, 
> but
>    he does not answer, Alice's replacement request will not match other
>    dialogs to which Bob's UA redirects, nor other branches to which his
>    proxy forwards. Although this specification takes reasonable
>
> In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must 
> be by Alice sending an invite/replaces to Bob. You seem not to want 
> this to fail either.

I am not following X = Cathy, Y = Bob.  In any case, this paragraph is 
motivational explaining why you shouldn't send a Replaces header for a 
dialog you know is still in the early state, unless you are sending the 
replacement request to the initiator of the request you want to replace.

> So, I am confused with what you are trying to restrict.

Y cannot accept an INVITE with Replaces for the early dialog between X 
and Y.

is that clear?

thanks,.
-rohan

>
> 	Paul
>


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