Ganesh Sivaraman wrote:
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.
Already answered I think.
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?
For one thing, you can't tell whether the NOTIFY is in response to the refresh subscribe, or is simply the next notify from the original subscribe.
For another thing, a refresh *is* different. It can't fork, and doesn't establish a dialog - it is being sent to the other participant in the existing dialog.
One reason for sending a refresh is simply to do a liveness test on the other end. If it doesn't respond to your message, then you presume it is dead. If you get a NOTIFY after you send the subscribe, you might presume it was sent earlier, before that device died. Or there could be something more exotic wrong, like messages go one direction but not the other.
In the case of the original subscription, you don't know if it forked. Because of forking, and the way that proxies work, and because the response to the subscription must pass thru the proxy while the notify need not, it is not hard for a notify to overtake the subscription response. The rules are set up so that you will create the proper dialogs in that case. It is hard to distinguish the normal case from the abnormal except in retrospect.
One scenario might be that a proxy forwarded the original subscribe on the UAS. The UAS then sent both the response to the subscribe and a notify. But the proxy crashes before delivering the response to you. The notify doesn't go through the proxy and so arrives. This gives exactly the scenario you posed. So the two cases are different.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
