Thanks for reply, comments in-line.... On Mon, 2003-02-24 at 20:04, Paul Kyzivat wrote: > > > 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.
Ganesh> If a 2XX to the initial SUBSCRIBE was not received, then how is the dialog-state built? Specifically, how do I set the route-set of this dialog (initiated by the SUBSCRIBE)? Should the Route headers in the early NOTIFY be used to build the route-set at the UAC? Then wouldn't this violate RFC3261, 12.1.2 UAC Behavior which says that Record-Route header from the response must be used for route-set creation? The other dialog-states, remote CSeq, remote target etc. can be set from the early NOTIFY. 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. Ganesh> Why this differential treatment for the initial SUBSCRIBE and refresh SUBSCRIBEs? In both cases, an early NOTIFY was received but the SUBSCRIBE transaction timed out, so shouldn't the handling be somewhat similar? > > Paul > Thanks Ganesh _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
