On Wed, 2005-10-19 at 12:43 -0400, Paul Kyzivat wrote: > BEWARE! > > There is an ambiguity in 481: there is no way to distinguish between the > *dialog* going away and the *dialog-usage* going away. > > This doesn't matter unless you are using a dialog for multiple purposes. > But suppose you had a dialog established by an invite, and within it you > sent a REFER, and thus got an implicit subscription to the refer event > package. > > Then, suppose both ends send a BYE and terminate their invitation. When > the BYE reaches the other end, there will be no invite dialog usage > around, so a 481 response will be sent to the BYE. But the subscription > could still be active.
I hadn't understood that, that a BYE only terminates an INVITE dialog- usage, and not the dialog containing it (unless there is only one dialog-usage in the dialog). > In this case it is important: > - not to tear down the dialog itself while the subscribe is still active > - to explicitly terminate the subscribe when you don't want it any longer But it does look like RFC 3261 requires that a 481 received by a UA will cause the UA to terminate the dialog, not just the dialog-usage relevant to the request: > >> Note that, as stated in Section 12.2.1.2, if the non-2xx final > >> response is a 481 (Call/Transaction Does Not Exist), or a 408 > >> (Request Timeout), or no response at all is received for the re- > >> INVITE (that is, a timeout is returned by the INVITE client > >> transaction), the UAC will terminate the dialog. Although I would expect it to be uncommon for a UA to "lose" a dialog- usage without losing its containing dialog, so there should be little practical penalty for having a 481 terminate the dialog. Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
