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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.