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

[Rohan Mahy <[e-mail]>]

On Tuesday, August 19, 2003, at 04:08 PM, Paul Kyzivat wrote:

>
>
> Rohan Mahy wrote:
>> 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.
>
> Based on your clarifications below, maybe the wording is ok as long as 
> wording elsewhere that hints at another meaning is fixed.
>
>>> 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.
>
> I'm just applying logic to the example. Alice is in role X because she 
> sent the invite. Alice also answers the invite/replaces. According to 
> your rule, she would have had to refuse it if she was not the 
> initiator of the dialog. So she must be the initiator of the dialog. 
> So in my terms role X is the dialog initiator and hence role Y is not 
> the dialog initiator.
>
> Hence I agree that this example is consistent with what you say below, 
> that Y cannot accept the invite/replaces.
>
>>> 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.
>
> Here is logic:
>
> - "... Cathy in an early dialog with Bob"
>
> => Cathy sent INVITE to Bob, OR Bob sent INVITE to Cathy
>    AND that INVITE hasn't completed yet
>
> - "but he does not answer"
>
> => the INVITE must have been from Cathy to Bob
>
> - "Alice replaces Cathy ..."
>
> => Alice sends INVITE/Replaces to Bob
> => the invite/replaces exceeds (else Alice won't replace Cathy)
>
> This means Cathy is in role X and Bob in role Y. Using either my 
> terminology or yours, this is the case where the recipient of the 
> invite/replaces must refuse it.
>
> So this example seems to violate your rule.
>
> > 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.
>
> Well, it isn't motivational for me. :-)
>
> Its just confusing. I now think I understand that you intend this as a 
> counterexample, of what bad things could happen if the restriction 
> were not in place.

yes

> But as worded it isn't clear that it is an example that isn't possible 
> given the restriction.

bummer.  can you propose some rewording?

> And I think it is nonsensical - what would lead Alice to do such a 
> stupid thing? I'm not sure it is possible to come up with an example 
> that makes much sense.

you'd be *amazed*.

thx,
-r

> 	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