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

[Paul Kyzivat <[e-mail]>]

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. But as worded it isn't clear that it is an example that 
isn't possible given the restriction.

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.

	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