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

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 1 Nov 2008 14:11:29 +0100

El Viernes, 31 de Octubre de 2008, [email-masked] escribió:
> I would expect that many SIP implementations would not handle Event
> parameters (filtering) correctly, and would just return all dialogs
> present at the UAC.  So the UAS will have to inspect the event body to
> see if its dialog is listed.

Yes, I imagine the same, devices ignoring Event parameters would show all 
their dialogs. So, even if the proxy just forward SUBSCRIBE if Event header 
contains call-id and to-tag parameters, it will imply a privacy risk for the 
device which doesn't implement correctly RFC 4235.

-- 
Iñaki Baz Castillo
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 7 Nov 2008 13:50:32 -0800

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.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 8 Nov 2008 16:48:34 +0100

> automaton will be able to recover from this error if it has a

Thanks for your reply.
I agree with you, 481 is an enough good response in this case, but I'd really 
prefer if it was specified in RFC 4235 (it doesn't appear at all).

Thanks a lot.

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Sun, 9 Nov 2008 14:50:45 +0100

> prefer if it was specified in RFC 4235 (it doesn't appear at all).

Thanks for the clarification. Since this is something unspecified in
RFC 4235, we'll include some explanatory text on this in version 01.
-- 
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 09 Nov 2008 22:45:14 +0100

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:
> 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
> 
>> response should it reply? The flow suggests "481 Call/Transaction doesn't
>> AFAIK, a 481 should be replied when an *in-dialog* request arrives to 
>> an UAS
>> request and the 481 refers to the specific dialog in the "Event" header.
>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 9 Nov 2008 14:02:27 -0800

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:

>> 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
>>> 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*

---

From: Adam Roach <[email-masked]>
Date: Wed, 12 Nov 2008 16:31:10 -0600

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:
> 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
>

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 12 Nov 2008 15:52:50 -0800

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
>
>> 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
>>
>>>> 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
>>>>> which is not aware of that dialog. But in the above case we  
>>>>> have an *initial*

---

From: Alan Johnston <[email-masked]>
Date: Wed, 12 Nov 2008 20:00:29 -0600

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:
>> 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.
>>
>>> 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
>>>

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 12 Nov 2008 19:53:28 -0800

Hi Alan,

I don't think of the Event package parameters as a filter in the same  
sense as a filter body in the SUBSCRIBE request. The main difference  
here is that it is not meaningful to think about updating the Event  
package parameters for the same subscription, while it is perfectly  
acceptable to modify a SUBSCRIBE filter body.

thanks,
-rohan

On Nov 12, 2008, at 6:00 PM, Alan Johnston wrote:

> 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:
>>> 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
>>>
>>>>>> 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
>>>>>>> This SUBSCRIBE arrives to Alice's UA which is not aware of  
>>>>>>> that dialog. Which

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Nov 2008 08:56:29 -0500

> understanding of how filtering works wrong?

I'm inclined to think of it in much this way, but there are some odd 
twists to it:

- These options (or filter) also serve as data used for authentication
   and authorization. Namely, possessing a valid dialog id is considered
   a form of identity, that is then coupled to authorization to subscribe
   with a limitation on seeing only data about that dialog.

- IMO it can be assumed that if someone supplies the notifier with what
   should be one of its own dialog ids, and it isn't currently defined,
   then it won't be valid in the future, and so should not serve as a
   valid identification. So such a subscription should fail, except
   perhaps if the subscriber can be authorized to subscribe on some
   other basis.

On that basis, I can see a 403 response if the dialog id isn't valid and 
the subscriber has no intrinsic authorization to subscribe.

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.

	Thanks,
	Paul

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Thu, 13 Nov 2008 15:37:26 +0100

2008/11/13 Paul Kyzivat <[email-masked]>:

> 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.

?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Nov 2008 08:52:28 -0600

Perhaps I'm being misled by the subject line. I thought this discussion 
arose from the DERIVE work -- for which "what a UA *should* do" is 
highly irrelevant. The only thing that matters for DERIVE is "what 
deployed UAs *actually* do." And given that *we* don't even know the 
answer to the *first* question, I would put my money on betting the 
answer to the second one is all over the map.

But, if we're having the argument...

Paul Kyzivat wrote:
>
> On that basis, I can see a 403 response if the dialog id isn't valid 
> and the subscriber has no intrinsic authorization to subscribe.
>
> 481 already has three distinct meanings, so adding another doesn't 
> seem like a great idea.

I agree with Paul, with one minor revision: I would change the final 
clause of his final sentence to "...so adding another seems like a 
really, really bad idea."

/a

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Nov 2008 09:16:12 -0600

> b) The indicated dialog in the "Event: dialog;call_id=xxx,to_tag=xxx"
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)

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 13 Nov 2008 16:24:03 +0100

On Thu, Nov 13, 2008 at 4:16 PM, Robert Sparks <[email-masked]> wrote:
> 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."
-- 
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Nov 2008 09:45:47 -0600

re-subjecting.

On Nov 13, 2008, at 9:24 AM, Victor Pascual Ávila wrote:

>>>> 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

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.