Re: [RFC 4235 & draft-kuthan-sip-derive] 481 "Call doesn't exist" for initial SUBSCRIBE ?

Hold on a minute - are we sure the notifier should send a 481?

I have always thought about the call-id, and tag Event package 
parameters as essentially a filter - that is only send me notifies about 
this particular dialog.  If I subscribe to an event package with a 
filter, but nothing matches the filter at that moment, would we normally 
expect the subscription to be refused?  Instead, I would expect an 
immediate notification saying subscription is created but then not get 
any notifications until the filter conditions are met.   Or is my 
understanding of how filtering works wrong?

As such, I think it still works - if the subscriber does not receive any 
notifications that match the dialog, he does not get the DERIVE 
authentication he is after.

Thanks,
Alan

Rohan Mahy wrote:
> Be generous in what you expect, but send a 481.   ;-)
> thanks,
> -rohan
>
> On Nov 12, 2008, at 2:31 PM, Adam Roach wrote:
>> We can argue about whether a UA should send a 481 in this case. What 
>> we can't do is change what any given deployed UA actually does in 
>> this case.
>>
>> The difference between "should" and "does" is critical when trying to 
>> leverage deployed behavior.
>>
>> /a
>>
>> On 11/9/08 4:02 PM, Rohan Mahy wrote:
>>> Hi Jiri,
>>>
>>> I am just saying that you if you send a 481 in this case, the 
>>> semantics are clear and consistent with some other event package 
>>> that uses call-id attributes. If you receive a 481 in this case you 
>>> can act accordingly. You could also get back a NOTIFY with a body 
>>> with full state with no dialogs, but this is less useful.
>>>
>>> thanks,
>>> -rohan
>>>
>>> On Nov 9, 2008, at 1:45 PM, Jiri Kuthan wrote:
>>>
>>>> Hi Rohan,
>>>>
>>>> is this our wishful thinking (I would like it too for it simplifies 
>>>> few
>>>> things) only, or is there a normative reference (which I can't find).
>>>> The way I read the related stuff is I get a 200 for the SUB back, and
>>>> an "empty" NOTIFY.
>>>>
>>>> -jiri
>>>>
>>>> Rohan Mahy wrote:
>>>>> Hi,
>>>>> The UA should respond with a 481.  In the case of an out of dialog 
>>>>> request the *meaning* of the response in this context is easy to 
>>>>> understand. A receiving UA realizes that it referred to some 
>>>>> dialog that does not exist. There are far too few response codes 
>>>>> for us to create a new one in this situation, and it is unlikely 
>>>>> that an automaton will be able to recover from this error if it 
>>>>> has a different code.
>>>>> thanks,
>>>>> -rohan
>>>>> On Oct 25, 2008, at 10:26 AM, Iñaki Baz Castillo wrote:
>>>>>> This SUBSCRIBE arrives to Alice's UA which is not aware of that 
>>>>>> dialog. Which
>>>>>> response should it reply? The flow suggests "481 Call/Transaction 
>>>>>> doesn't
>>>>>> exist", but... is it correct?
>>>>>>
>>>>>> AFAIK, a 481 should be replied when an *in-dialog* request 
>>>>>> arrives to an UAS
>>>>>> which is not aware of that dialog. But in the above case we have 
>>>>>> an *initial*
>>>>>> request and the 481 refers to the specific dialog in the "Event" 
>>>>>> header.
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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
>
>

_______________________________________________
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