For question 1 below, I think the RFC 3265 clearly suggests that "If an initial SUBSCRIBE request is not sent on a pre-existing dialog, the subscriber will wait for a response to the SUBSCRIBE request or a matching NOTIFY" The only issue there would be that the 'expires' would have been in the 2xx class response that never reached. If the NOTIFY did not contain the 'expires' parameter in the subscription-state, we are left with the only option of keeping the 'expires' in the request, and deem the subscription to be successful. Also, like Paul mentioned, a non-2xx response if originated by the only notifier, is a serious offence. However, if due to forking, a non-2xx response is received, it is filtered by the proxy in between.
For question 2, I think we must retain the subscription until previous 'expires' expires. -Kannan ----- Original Message ----- From: "Paul Kyzivat" <[EMAIL PROTECTED]> To: "Ganesh Sivaraman" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 8:04 PM Subject: Re: [Sip-implementors] Query on Early NOTIFYs > > > Ganesh Sivaraman wrote: > > Hi, > > I have a couple of queries on treatment of early NOTIFYs (i.e. NOTIFY > > received before 2XX to SUBSCRIBE). > > > > 1. UAC1 UAC2 > > Initial SUBSCRIBE ------------> > > 2XX not received <------- send 2XX > > NOTIFY(act/pend) <------------ send NOTIFY act/pend > > (Dialog-state is > > created from NOTIFY) > > > > UAC 1 sends SUBSCRIBE to UAC2 and receives a NOTIFY(active/pending) > > ahead of any 2XX response. According to RFC3265, the subscription and > > dialog are created. Now, if the 2XX response never arrives i.e. > > SUBSCRIBE client transaction times out, what should UAC1 do: > > (a) Delete the created subscription? OR > > (b) If it was a NOTIFY(act), should the timeout be ignored since the > > subscription has already been activated? > > (c) If it was a NOTIFY(pend), what should be done? > > I don't think the form of the NOTIFY should have any impact on the > result, except if the NOTIFY indicates termination of the subscription. > > In cases of forking, several dialogs can be established, in which case > all but one will lack any corresponding 2xx. So the lack of a 2xx after > the notify should not be especially upsetting, though it is odd. It > would be even more peculiar if you were to receive a NOTIFY and then get > a 4xx for the subscribe. That would indicate a serious protocol > violation by somebody. I don't know what the proper handling of that is. > > > > > 2. What if the above scenario was for a SUBSCRIBE refresh instead of an > > initial SUBSCRIBE? Should the solution for the above scenario be any > > different? > > In the case of a subscribe refresh, you can't tell if the NOTIFY you > receive is a result of the refresh, or was sent before the UAS received > the refresh. But maybe that isn't what you are asking. Are you simply > asking what you should do if you get no response to a subscribe refresh? > > In that case I think you just assume the subscription is gone. Or, if > you want to be a very good citizen, you could send another refresh with > a zero expiration time to tell the other end you are cancelling the > subscription. > > Paul > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
