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
