An edge of 4235 (was Re: [RFC 4235 & draft-kuthan-sip-derive] 481 "Call doesn't exist" for initial SUBSCRIBE ?)
Robert Sparks <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
re-subjecting. On Nov 13, 2008, at 9:24 AM, Victor Pascual Ávila wrote: > On Thu, Nov 13, 2008 at 4:16 PM, Robert Sparks > <[email protected]> wrote: >> >> On Nov 13, 2008, at 8:37 AM, Iñaki Baz Castillo wrote: >> >>> 2008/11/13 Paul Kyzivat <[email protected]>: >>> >>>> I understand the reasoning behind 481 but I am a *bit* troubled >>>> by it. It >>>> is >>>> a distinct semantic for 481, though one that is unambiguous. But >>>> 481 >>>> already >>>> has three distinct meanings, so adding another doesn't seem like >>>> a great >>>> idea. >>> >>> I agree, imagine if you sends such a SUBSCRIBE but as refresh >>> SUBSCRIBE (in-dialog request), and you get 481. What does it mean?: >>> >>> a) The current SUBSCRIBE dialog doesn't exist anymore. >>> b) The indicated dialog in the "Event: >>> dialog;call_id=xxx,to_tag=xxx" >>> doesn't exist. >> >> It might be a bit of a stretched analogy, but in this particular >> situation: >> The response to the subscribe definitely talks about the >> subscription usage >> (its the envelope) >> Information about the pointed-to dialog ending is carried in >> NOTIFYs (its >> the stuff in the envelope) > > IMO, RFC 4235 establishes a relationship between the envelope and > the content: > Section 3.4. Subscription Duration > "In that case, when the dialogs terminate, so too does the > subscription." That doesn't change the answer above though. The response to the subscribe is about the subscription-usage being gone. That might be the case because all the dialogs being subscribed to are gone, but the error doesn't tell you that. Further, when those dialogs went away, NOTIFYs would have been generated. The only case where you wouldn't have that information before your resubscribed failed is if the NOTIFYs and the reSUBSCRIBE crossed on the wire. > > -- > Victor Pascual Ávila _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip