Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01

[Ben Campbell <ben at estacado.net>]

On Apr 3, 2008, at 9:39 AM, Jari Urpalainen wrote:

[...]

>>>>>> You cannot safely use non-sequential CSeq to detect missing  
>>>>>> NOTIFY requests. For example, if the NOTIFY request is  
>>>>>> challenged by an intervening proxy, the subscriber will see non- 
>>>>>> sequential CSeq values. It may be unusual for NOTIFY to get  
>>>>>> challenged, but unless we forbid it, then we cannot depend on  
>>>>>> CSeq for this purpose.
>>>>> ok, didn't think about that at all.
>>>>
>>>> This one needs some thought, then. There are actually a lot more  
>>>> causes than just digest challenges that may cause the client to  
>>>> see non-sequential CSeqs. If detection of lost notifies is  
>>>> critical, we need another solution (either to detect lost  
>>>> notifies or to remove the need to do so.)
>>> now I've managed to put this "utter crap" myself :-), sorry, i.e.  
>>> unordering doesn't happen when the notifier acts _properly_, so  
>>> it's better to move that text altogether.
>>
>> The text was more about missing NOTIFY requests than it was out-of- 
>> order NOTIFYs (CSeq will actually catch the out-of-order case). Are  
>> you saying that it is okay to not be able to detect missing  
>> NOTIFYs, even in patch mode? Note that missing and out-of-order  
>> notifies can (rarely, we hope)  happen due to intervening devices  
>> even if the notifier is perfectly well behaved.
>>
> the implicit rule _now_ for the notifier is: if you don't get a  
> final 200 ack for a notify, do not send a new request and for a  
> timeout, tear down the session (this is what i propose but as  
> explicit). So what happens with  4xx, 5xx, 6xx etc is unspecified.  
> So the rule for waiting for the 200 OK rules out-of-order. So if you  
> get 4/5/6xx will that mean drop-out possibility ? no imo, since you  
> can't send a new one unless the previous one has been sent  
> successfully. So personally i _could_ go that far that tear down  
> always if return code != 200, but probably some intelligent  
> notifiers could resolve e.g. 413, though i have my doubts....

Ah, I _think_ that helps, although keep in mind that not all non-200  
responses necessarily indicate the subscription should be torn down.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip