Subject: Re: [sipcore] OPTIONS: What does it mean?

From: Brett Tate <[email-masked]>
Date: Mon, 1 Mar 2010 05:35:04 -0800

> > *If* the OPTIONS has a to-tag, and there is no matching 
> > dialog there are several things that might happen:
> > - it might be rejected with a 481
> > - it might succeed because it is treated as if received 
> >   outside a dialog

<snip>

> > - it might cause the dialog to be recreated, and then 
> >   succeed within it
> > In the latter case, presumably the dialog would then end, 
> > because there are no dialog usages.
> 
> And, this will of course depend on whether the UAS still has 
> any knowledge about the dialog.
> 
> Personally I think this alternative is rather strange, and 
> I've never heard about it being used. But, I agree that the 
> text seems to allow it.

Regardless if justified by the above bullets 2 or 3, some venders do return 200 instead of 481.  For instance if OPTIONS is sent within dialog associated with a currently/formerly known subscription, the UAS wouldn't want to return 481 (because of the potential impacts) unless it actually verified that the subscription is no longer known.

Since it highlights why potentially relevant to get OPTIONS 481 ambiguity clarified, the following is snippet a 2008 thread.

"Just trying to understand what rfc3261 and rfc5057 indicate or tried to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the related impacts upon the dialog usages if OPTIONS 481 is received, 3) OPTIONS' ability to temporality revive/recreate the dialog per UAS' desire to return 200.

If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent requests/responses to terminate the dialog, I'm sure some would like to use it within early dialogs, subscriptions, and elsewhere."

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Mar 2010 19:39:30 +0100

Hi,

If we forget what the RFCs say (or, what we believe they say :), how would people like the UAS to handle OPTIONS in the case when it contains a to-tag but the UAS currently has no state of a dialog associated with that to-tag value?

Regards,

Christer

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: 1. maaliskuuta 2010 15:35
To: Christer Holmberg; SIPCORE
Subject: RE: [sipcore] OPTIONS: What does it mean?

> > *If* the OPTIONS has a to-tag, and there is no matching dialog there 
> > are several things that might happen:

<snip>

> > In the latter case, presumably the dialog would then end, because 
> > there are no dialog usages.
> 
> And, this will of course depend on whether the UAS still has any 
> knowledge about the dialog.
> 
> Personally I think this alternative is rather strange, and I've never 
> heard about it being used. But, I agree that the text seems to allow 
> it.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2010 13:58:48 -0500

IMO, if the request has a to-tag, then the UAS should treat it as an 
in-dialog request not associated with any particular usage. If there is 
no matching dialog, then it should return a 481 response.

	Thanks,
	Paul

Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Brett Tate <[email-masked]>
Date: Mon, 1 Mar 2010 11:39:49 -0800

> If we forget what the RFCs say (or, what we believe they say :),
> how would people like the UAS to handle OPTIONS in the case when 
> it contains a to-tag but the UAS currently has no state of a 
> dialog associated with that to-tag value?

To avoid encouraging the use of OPTIONS to check dialog state (INVITE usage and/or SUBSCRIBE usage), I'd prefer it not be mandatory to return 481.

> Regardless if justified by the above bullets 2 or 3, some venders do
> return 200 instead of 481.  For instance if OPTIONS is sent within
> dialog associated with a currently/formerly known subscription, the UAS
> wouldn't want to return 481 (because of the potential impacts) unless
> it actually verified that the subscription is no longer known.
> 
> Since it highlights why potentially relevant to get OPTIONS 481
> ambiguity clarified, the following is snippet a 2008 thread.
> 
> "Just trying to understand what rfc3261 and rfc5057 indicate or tried
> to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2)
> the related impacts upon the dialog usages if OPTIONS 481 is received,
> 3) OPTIONS' ability to temporality revive/recreate the dialog per UAS'
> desire to return 200.
> 
> If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent
> requests/responses to terminate the dialog, I'm sure some would like to
> use it within early dialogs, subscriptions, and elsewhere."

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 1 Mar 2010 20:44:39 +0100

Agree.

/Hans Erik van Elburg

On Mon, Mar 1, 2010 at 7:58 PM, Paul Kyzivat <[email-masked]> wrote:

> in-dialog request not associated with any particular usage. If there is no
> matching dialog, then it should return a 481 response.
>
>        Thanks,
>        Paul
>
>
> Christer Holmberg wrote:
>
>> Hi,
>>
>> If we forget what the RFCs say (or, what we believe they say :), how would
>> people like the UAS to handle OPTIONS in the case when it contains a to-tag
>> but the UAS currently has no state of a dialog associated with that to-tag
>> value?
>>
>> Regards,
>>
>> Christer
>>
>>
>> From: Brett Tate [mailto:[email-masked]] Sent: 1. maaliskuuta 2010
>> 15:35
>>  *If* the OPTIONS has a to-tag, and there is no matching dialog there are
>>>> several things that might happen:
>>>> - it might succeed because it is treated as if received  outside a
>>>> dialog
>>>>
>>>
>> <snip>
>>
>>  - it might cause the dialog to be recreated, and then  succeed within it
>>>> In the latter case, presumably the dialog would then end, because there
>>>> are no dialog usages.
>>>>
>>> heard about it being used. But, I agree that the text seems to allow it.
>>>
>>
>> return 200 instead of 481.  For instance if OPTIONS is sent within dialog
>> associated with a currently/formerly known subscription, the UAS wouldn't
>> want to return 481 (because of the potential impacts) unless it actually
>> verified that the subscription is no longer known.
>>
>> Since it highlights why potentially relevant to get OPTIONS 481 ambiguity
>> clarified, the following is snippet a 2008 thread.
>>
>> "Just trying to understand what rfc3261 and rfc5057 indicate or tried to
>> indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the
>> related impacts upon the dialog usages if OPTIONS 481 is received, 3)
>> OPTIONS' ability to temporality revive/recreate the dialog per UAS' desire
>> to return 200.
>>
>> requests/responses to terminate the dialog, I'm sure some would like to use
>> it within early dialogs, subscriptions, and elsewhere."
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2010 15:24:00 -0500

Brett,

I would prefer that what to respond in this case had always been 
unambiguous.

Given that is has been ambiguous, the question is whether its worthwhile 
to attempt to fix it. Practically speaking, the UAC will have to deal 
with UASes that were implemented long ago with the ambiguity. So it will 
continue to be improper to draw a conclusion about the status of the 
dialog from a 200 response.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Mar 2010 22:50:02 +0100

Hi,

>dialog from a 200 response.

I agree. But, just because it has been ambiguos, it doesn't mean we can clarify how it should be in future.

Regards,

Christer

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 01 Mar 2010 16:40:45 -0600

> no matching dialog, then it should return a 481 response.

+1 (based entirely on my desire to not have to special-case OPTIONS when
deciding whether a request is to be treated as in-dialog or not)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Mar 2010 11:04:40 -0600

On Mar 1, 2010, at 12:58 PM, Paul Kyzivat wrote:

> in-dialog request not associated with any particular usage. If there  
> is no matching dialog, then it should return a 481 response.
>

I haven't thought this thru: Is there any chance of this being used to  
fish for existing dialogs? If not, then your position seems reasonable.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Mar 2010 14:32:42 -0500

> fish for existing dialogs? If not, then your position seems reasonable.

There is a *possibility* of using it that way.
But I don't think that is a very practical approach to anything.

If you don't already have access to the dialog info, but suspect there 
is a dialog and want to discover it, the namespace of dialog ids is 
*very* large. Trying to guess and verify this way would be very expensive.

And, if you thought this was useful, and we blocked use of OPTIONS for 
this, you could simply switch to some other message - e.g. UPDATE.

	Thanks,
	Paul