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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
