Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

From: Salvatore Loreto <[email-masked]>
Date: Thu, 01 Apr 2010 09:36:06 +0200

Hi,

A good mechanism to discovery UA capabilities is essential to provide 
meaningful service:
So I am in favor of pursuing the work,
in particular the possibility to use a single OPTIONS request to 
retrieve the capabilities from ALL UAS(s) behind a forking proxy.

I agree with Christer, that as discussed in the ml and during the f2f 
meeting, the 3xx solution already provide this feature
even if with the limitations Paul has highlighted (e.g. honoring R-D is 
optional by the proxy).

I do think, it would be opportune document it in a BCP to 
document/clarify the ambiguous stuff, and I can help to co-edit it if we 
decide to write one.

Explore the possibility to use other mechanisms (e.g. presence, 
something similar to XEP-0115) and define it would be also interesting,
but IMO it would require a major effort and more cycles and I am not so 
sure there are enough people willing to accomplish such effort.

cheers
Sal

On 3/30/10 9:05 PM, Adam Roach wrote:
> [as chair]
>
> One of the topics of discussion at the recent face-to-face meeting in 
> Anaheim was the SIP OPTIONS method. We have had significant discussion 
> of some specific technical topics on the SIPCORE mailing list, such 
> that all participants should have a reasonable overview of the scope 
> that any related work may entail. Participants may also benefit from 
> reading through the minutes of the corresponding conversation in Anaheim:
>
> http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTIONS%20Method
>
> Rather than continue discussion of the specific technical topics 
> related to OPTIONS, the chairs would encourage the working group to 
> engage in a discussion around whether we should, as a group, work on 
> addressing some of the issues that have been identified.
>
> In particular, we would direct the group to consider the nature of 
> such work:
>
>     * Are we proposing to introduce new features, or fix existing bugs?
>     * If we are adding new features: is OPTIONS the best way to
>       introduce these features, or would other mechanisms (presence,
>       callee-caps) produce superior results?
>     * If we are fixing bugs: are the bugs theoretical, or can we cite
>       actual interoperability issues in the field?
>     * If there are identified interoperability issues: is the level of
>       effort involved in fixing them commensurate with the impact of
>       the problems?
>
> Finally, keep in mind that work does not happen unless participants 
> are willing to invest time. If you speak out in favor of pursuing this 
> work, please indicate the level of time commitment that you will 
> personally invest in bringing such work to a successful conclusion 
> (e.g., will author drafts; will perform dedicated reviews; etc).
>
> Thanks.
>
> /a

---

From: Adam Roach <[email-masked]>
Date: Thu, 01 Apr 2010 08:11:33 -0500

> A good mechanism to discovery UA capabilities is essential to provide 

[as an individual]

If this is true -- if it really is *essential* -- then we need something 
better than the "maybe it works, maybe it doesn't" level of 
functionality that we get from R-D. If discovery of UA capabilities is 
*essential*, then we need something that survives forking in all 
circumstances, like SUBSCRIBE/NOTIFY or something else that sends a 
request in both directions.

I suspect it's more in the "nice to have" category.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Apr 2010 18:25:11 -0400

Hi Christer,
Inline...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, March 31, 2010 1:56 AM
To: 'Adam Roach'; SIPCORE
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

Hi,

Adam, thanks for sending out the the e-mail!

First, a clarification regarding "new features":

When we say "new features", I assume (based on Hadriel's comment in the meeting) it means the possibility to, with a single OPTIONS request, retrieve the capabilities from ALL UAS(s) behind a forking proxy - instead of only one UAS (whoever sends the 200 OK to the forking proxy first).

Yeah what I meant was that in my opinion your slides had really two separate classes of topics: the first were "bugs", either in incorrectly or under-specific RFC cases/text.  Effectively things we would put into bugzilla, and possibly incorporate into any errata/bis someday.  The second was the "I want this request to go to all contacts for the AoR and get all their responses", which is not a bug of the current specs.

The message I got from the meeting, and also previous e-mail discussions, was that the "OPTIONS 3xx" solution already provideds this feature, and that it can be used (without defining new protocol elements etc).

Does it actually solve it?  Sorry I wasn'f following the discussion of it on the mailing list, but...What if there is more than one proxy in the path - which one is supposed to return 3xx?
What if the first proxy has two routes for the AoR, and one of those points to another proxy that also has two (different) routes for the AoR?
Do you only want 3xx for Registered contact URI's?  What if the proxy doesn't know whether they're Registered contact URI's vs. static routes?

So, in my opinion the "adding" word is a little missleading. Instead I think the question is whether we want to DOCUMENT that existing feature.

Second, regarding bugs and interoperability issues in the field. Personally I am not sure of any major ones at the moment, but that is probably because OPTIONS haven't been very much deployed in the first place (it has been used for some keep-alive/ping purposes, but in those cases it really doesn't matter what comes in the response etc).

Funny enough that's the only area I've ever actually seen OPTIONS interop problems - the response code.  We seem to need to map the response code to something different a lot.  Not sure why though.

Now, however, at least I am starting to get questions regarding the usage of OPTIONS, so I guess we need to ask ourselves whether we think the bugs WILL create interoperability issues.

And, the issue you raised regarding using the re-INVITE to re-create dialogs ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also affects OPTIONS, eventhough you want to keep them separate (which is ok).

Obviously I am in favor of pursuing the work, and will be willing to author drafts :)

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 30. maaliskuuta 2010 22:06
To: SIPCORE
Subject: [sipcore] SIP OPTIONS: Shall we work on this?
[as chair]

One of the topics of discussion at the recent face-to-face meeting in Anaheim was the SIP OPTIONS method. We have had significant discussion of some specific technical topics on the SIPCORE mailing list, such that all participants should have a reasonable overview of the scope that any related work may entail. Participants may also benefit from reading through the minutes of the corresponding conversation in Anaheim:

Rather than continue discussion of the specific technical topics related to OPTIONS, the chairs would encourage the working group to engage in a discussion around whether we should, as a group, work on addressing some of the issues that have been identified.

In particular, we would direct the group to consider the nature of such work:

 *   Are we proposing to introduce new features, or fix existing bugs?
 *   If we are adding new features: is OPTIONS the best way to introduce these features, or would other mechanisms (presence, callee-caps) produce superior results?
 *   If we are fixing bugs: are the bugs theoretical, or can we cite actual interoperability issues in the field?
 *   If there are identified interoperability issues: is the level of effort involved in fixing them commensurate with the impact of the problems?
Finally, keep in mind that work does not happen unless participants are willing to invest time. If you speak out in favor of pursuing this work, please indicate the level of time commitment that you will personally invest in bringing such work to a successful conclusion (e.g., will author drafts; will perform dedicated reviews; etc).

Thanks.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Apr 2010 18:33:19 -0400

Hi Salvatore,
When you say "is essential to providing meaningful service" in what way do you mean that?
Do you mean literally that you need any UAC anywhere to be able to discover the capabilities of any arbitrary UAS it might want to communicate with in the World using OPTIONS?
Or do you mean within a provider's domain, having an App Server figure out what each registered UA endpoint supports and putting that in some database is very useful? (which I could see 3GPP doing)
Because if it's the latter, then creating an options-tag for rfc3841 and putting it in Proxy-Require isn't that bad an idea - proxy-require only has deployment issues when you want to use it across proxies outside of your administrative control.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore Loreto
Sent: Thursday, April 01, 2010 3:36 AM
To: [email-masked]
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

Hi,

A good mechanism to discovery UA capabilities is essential to provide meaningful service:
So I am in favor of pursuing the work,
in particular the possibility to use a single OPTIONS request to retrieve the capabilities from ALL UAS(s) behind a forking proxy.

I agree with Christer, that as discussed in the ml and during the f2f meeting, the 3xx solution already provide this feature
even if with the limitations Paul has highlighted (e.g. honoring R-D is optional by the proxy).

I do think, it would be opportune document it in a BCP to document/clarify the ambiguous stuff, and I can help to co-edit it if we decide to write one.

Explore the possibility to use other mechanisms (e.g. presence, something similar to XEP-0115) and define it would be also interesting,
but IMO it would require a major effort and more cycles and I am not so sure there are enough people willing to accomplish such effort.

cheers
Sal

Thanks.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Apr 2010 19:25:07 -0400

Comments inline. I trimmed out the irrelevant.
I guessed which was Hadriel - apparently the only distinction was color, 
at least for me.

Hadriel Kaplan wrote:
> Hi Christer,
> 
> Inline…
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Christer Holmberg
> *Sent:* Wednesday, March 31, 2010 1:56 AM
> *To:* 'Adam Roach'; SIPCORE
> *Subject:* Re: [sipcore] SIP OPTIONS: Shall we work on this?
...
> The message I got from the meeting, and also previous e-mail 
> discussions, was that the "OPTIONS 3xx" solution already provideds this 
> feature, and that it can be used (without defining new protocol elements 
> etc).
> 
> Does it actually solve it?  Sorry I wasn’f following the discussion of 
> it on the mailing list, but…What if there is more than one proxy in the 
> path – which one is supposed to return 3xx? 
> 
> What if the first proxy has two routes for the AoR, and one of those 
> points to another proxy that also has two (different) routes for the AoR?  

That should all be handled by recursion on 3xx response processing.
The first proxy would return 3xx with its choices. One of those would 
lead to the 2nd proxy, that then would return its own 3xx.

> Do you only want 3xx for Registered contact URI’s?  What if the proxy 
> doesn’t know whether they’re Registered contact URI’s vs. static routes? 

IMO this is one of the big problems with the IMS approach to services. 
They aren't registered, and aren't anything that the S-CSCF could (or 
would) return as 3xx alternatives. So the caller will be limited in what 
options are visible to it.

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 2 Apr 2010 06:05:04 -0400

Hi all,

I agree with the assertion (Hadrials?) that there are two things here:
bugs in OPTIONS and a need to query multiple UAs.

I have not seen wide use of OPTIONS and have not encountered these
bugs, In general I favour fixing them but I am not sure if this is
more important that other work which could be done.

As for assessing multiple UA capabilities - I agree this is useful. Is
OPTIONS the only way forward here? Could I not use e.g. gruu-reg-event
and then send specifically targeted OPTIONS to each gruu? Is requiring
gruu support in UAs viewed as 'setting the bar too high?' This fails
to pick up forking due to dial plan entries - is that a requirement?

Peter Musgrave

---

From: Brett Tate <[email-masked]>
Date: Fri, 2 Apr 2010 04:59:13 -0700

> If discovery of UA capabilities is *essential*, then we need 
> something that survives forking in all circumstances, like 
> SUBSCRIBE/NOTIFY or something else that sends a request in 
> both directions.

Concerning forking, I agree that SUBSCRIBE/NOTIFY usage is better than OPTIONS.  However is there a routing issue concerning SUBSCRIBE?  More specifically since INVITE and OPTIONS supposedly result in the same response status code, OPTIONS supposedly gets routed like INVITE.  Is there currently a requirement upon middle boxes to route SUBSCRIBE the same as INVITE?

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Apr 2010 12:51:07 +0200

Hi,

>If this is true -- if it really is *essential* -- then we need something better than the "maybe it works, maybe it doesn't" level of functionality that we get from R-D. If discovery of UA capabilities is 
>*essential*, then we need something that survives forking in all circumstances, like SUBSCRIBE/NOTIFY or something else that sends a request in both directions.

SUB/NOT is only going to work if the involved entities support the associated event package. So, it's still a "maybe it works, maybe it doesn't".

It is true that we on a protocol level cannot ensure that proxies will support this, but in reality people will implement extensions based on the services and capabilities that they want to provide. 

Also, the more usefulness of extensions (in this case 3841) we can show, the more likely it is that people will implement/demand them.

>I suspect it's more in the "nice to have" category.

I don't agree. As Sal said, it is essential in some cases.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Apr 2010 13:00:30 +0200

Hi,

<Christer> I agree. I tried to make that separation in my presentation, by talking about "unclear specifications"/bugs and "forking". I never intended to say that the forking case was a bug, simply that the way it is normally used very much limits it's usability in forking cases.

<Christer> I have mostly been thinking about the registrar returning the 3xx, but there could be cases where another forking proxy also sends 3xx, and maybe the UAC can already make some decissions based on that. Now, in theory this could of course lead to a series of 3xx response, but in real life I don't think that is going to happen. When forking occurs in the first place, I think the majority of cases will contain one point of forking. In some cases there may be two points of forking, but more than that I think is going to be extremely rare... But, if someone thinks I'm wrong I would really much like to hear about it :)

Regards,

Christer

Regards,

Christer

Thanks.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Apr 2010 13:06:34 +0200

Hi, 

>I have not seen wide use of OPTIONS and have not encountered these bugs, In general I favour fixing them but I am not sure if this is more important that other work which could be done.
>
>As for assessing multiple UA capabilities - I agree this is useful. Is OPTIONS the only way forward here? Could I not use e.g. gruu-reg-event and then send specifically targeted OPTIONS to each gruu? Is 
>requiring gruu support in UAs viewed as 'setting the bar too high?' This fails to pick up forking due to dial plan entries - is that a requirement?

In the OPTIONS 3xx case, after the UAC has received the 3xx it would send individual OPTIONS request. The 3xx may contain gruus, or normal contacts.

So, it doesn't require support of gruu. It doesn't really require any support from the UAS.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Apr 2010 13:10:09 +0200

Hi, 

>The first proxy would return 3xx with its choices. One of those would lead to the 2nd proxy, that then would return its own 3xx.

That might happen, yes.

>>Do you only want 3xx for Registered contact URI's?  What if the proxy 
>>doesn't know whether they're Registered contact URI's vs. static routes?
>
>would) return as 3xx alternatives. So the caller will be limited in what options are visible to it.

I am not really sure I understand what you mean...

However, there are of course limitations on how much information the caller will get, based on what information the UAS have registered, and what information can be returned in the 3xx in the first place.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Apr 2010 13:15:16 +0200

Hi, 

>Do you mean literally that you need any UAC anywhere to be able to discover the capabilities of any arbitrary UAS it might want to communicate with in the World using OPTIONS?

Anyone associated with an AOR, yes, which of course may located anywhere in the world :)

>Or do you mean within a provider's domain, having an App Server figure out what each registered UA endpoint supports and putting that in some database is very useful? (which I could see 3GPP doing)

I guess that could be a potential use-case also.

>Because if it's the latter, then creating an options-tag for rfc3841 and putting it in Proxy-Require isn't that bad an idea - proxy-require only has deployment issues when you want to use it across 
>proxies outside of your administrative control.

Far from every proxy needs to understand RFC3841, and that is the problem with Proxy-Require - it requires everyone to understand something.

(It would be really great if it would be possible to require proxies to support stuff only in certain conditions, e.g. if they act as a registrar and intend to do forking).

Regards,

Christer

Hi,

cheers
Sal

[as chair]

Thanks.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 03 Apr 2010 09:32:39 -0400

> I am not really sure I understand what you mean...

For instance, suppose I want to talk to your voicemail, without ringing 
your regular phone(s). I might send an OPTIONS in hope of getting a list 
of Contacts, among which the VM contact might be found.

AFAIK, IMS isn't set up in a way to have an identifiable contact for the 
VM server that it could return in the 3xx. (But I'll be pleasantly 
surprised to learn I'm wrong.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 3 Apr 2010 12:19:36 -0400

Hi Christer, 
comments inline...
(also, let's keep this plain text format :)

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Saturday, April 03, 2010 7:01 AM
> To: Hadriel Kaplan; 'Adam Roach'; SIPCORE
> Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this?
>
> I agree. I tried to make that separation in my presentation, by talking
> about "unclear specifications"/bugs and "forking". I never intended to say
> that the forking case was a bug, simply that the way it is normally
> usedvery much limits it's usability in forking cases.
 
No debate there - as far as I can tell rfc3841 req-disp is used in very limited and constrained cases, under specific configuration control. (when it's used at all)

> I have mostly been thinking about the registrar returning the 3xx, but
> there could be cases where another forking proxy also sends 3xx, and maybe
> the UAC can already make some decissions based on that. Now, in theory
> this could of course lead to a series of 3xx response, but in real life I
> don't think that is going to happen. When forking occurs in the first
> place, I think the majority of cases will contain one point of forking. In
> some cases there may be two points of forking, but more than that I think
> is going to be extremely rare... But, if someone thinks I'm wrong I would
> really much like to hear about it :)

Easy answer: go beyond the local domain.  If the SIP request goes inter-domain, it's not uncommon for proxies along the path to have multiple routes.  For example to multiple transits, or to multiple ingress/egress point next-hops, or to PSTN-fallback gateways, etc.  These are all "forks" (serial forks).

Even within the domain, it's not always obvious that the reg-proxy knows which database entries are registered contacts vs. static routes - for example fallback routes, or voicemail routes, or invoked b2bua app-servers - and even if it knows, the request-disposition does not specify what types it applies to.

So ISTM that this thing will need to be configured: enabled on specific proxies for specific route types, and possibly for specific methods.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 3 Apr 2010 12:40:18 -0400

> Sent: Saturday, April 03, 2010 7:15 AM
> To: Hadriel Kaplan; Salvatore Loreto; [email-masked]
> 
> Far from every proxy needs to understand RFC3841, and that is the problem
> with Proxy-Require - it requires everyone to understand something.

No debate there - but I don't know how you get "guaranteed" usage otherwise.
For example, if your OPTIONS request crosses a proxy which recurses on 3xx, and that proxy forwards it to a proxy which understands req-disp and sends back the 3xx.  The recursing middle-proxy will handle it, not send it back to you.  And across domains 3xx-recursing proxies are common.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Apr 2010 06:31:37 +0200

Hi, 

>>Far from every proxy needs to understand RFC3841, and that is the 
>>problem with Proxy-Require - it requires everyone to understand something.
>
>For example, if your OPTIONS request crosses a proxy which recurses on 3xx, and that proxy forwards it to a proxy which understands req-disp and sends back the 3xx.  The recursing middle-proxy will 
>handle it, not send it back to you.  And across domains 3xx-recursing proxies are common.

I agree, that might happen.

But, that is a general 3xx response "feature", and again one of thoese things where there is very little we can do on a protocol level - we just have to hope people will configure their deployments in a right way. And, having a document (e.g. a BCP, in this case) would help them in doing that, in my opinion.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Apr 2010 06:43:21 +0200

Hi, 

>>I agree. I tried to make that separation in my presentation, by 
>>talking about "unclear specifications"/bugs and "forking". I never 
>>intended to say that the forking case was a bug, simply that the way 
>>it is normally usedvery much limits it's usability in forking cases.
> 

I think 3841 is the hidden jewel of SIP. And, eventhough I may not like every detail init, in my opinion it can be a very useful tool. 

>>there could be cases where another forking proxy also sends 3xx, and 
>>maybe the UAC can already make some decissions based on that. Now, in 
>>theory this could of course lead to a series of 3xx response, but in 
>>real life I don't think that is going to happen. When forking occurs 
>>in the first place, I think the majority of cases will contain one 
>>point of forking. In some cases there may be two points of forking, 
>>but more than that I think is going to be extremely rare... But, if 
>>someone thinks I'm wrong I would really much like to hear about it :)
>
>Easy answer: go beyond the local domain.  If the SIP request goes inter-domain, it's not uncommon for proxies along the path to have multiple routes.  For example to multiple transits, or to multiple 
>ingress/egress point next-hops, or to PSTN-fallback gateways, etc.  These are all "forks" (serial forks).

Agree. But, in this case I don't really see a big reason in those proxies sending a 3xx response, since the request is forwarded towards the same destination, simply using different routes.

I think this is another case where we seem to think that the world spins around the protocol, and operators won't be able to configure their equipment... :)

>Even within the domain, it's not always obvious that the reg-proxy knows which database entries are registered contacts vs. static routes - for example fallback routes, or voicemail routes, or invoked 
>b2bua app-servers - and even if it knows, the request-disposition does not specify what types it applies to.

You can define new feature tags/feature tag values, if needed, e.g. to indicate "voicemail". Maybe that would be very useful, if I e.g. need to leave you a message, but I don't have time to talk with you in person at this moment. 

And, local policies can be used on what contacts to return in the 3xx.

>So ISTM that this thing will need to be configured: enabled on specific proxies for specific route types, and possibly for specific methods.

For example, yes.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Apr 2010 06:51:41 +0200

Hi, 

>For instance, suppose I want to talk to your voicemail, without ringing your regular phone(s). I might send an OPTIONS in hope of getting a list of Contacts, among which the VM contact might be found.

As I also indicated in my reply to Hadriel's e-mail, for this case I think it would be very useful to have a VM feature tag, or something else in the returned contact that indicates voicemail.

>AFAIK, IMS isn't set up in a way to have an identifiable contact for the VM server that it could return in the 3xx. (But I'll be pleasantly surprised to learn I'm wrong.)

IMS uses 3841.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Apr 2010 09:03:17 -0400

[as individual]

> As I also indicated in my reply to Hadriel's e-mail, for this case I think it would be very useful to have a VM feature tag, or something else in the returned contact that indicates voicemail.

Its already there, defined in 3840: actor="msg-taker".

>> AFAIK, IMS isn't set up in a way to have an identifiable contact for the VM server that it could return in the 3xx. (But I'll be pleasantly surprised to learn I'm wrong.)

Yeah, I know that it uses 3841, but the last I knew it only did so to 
select among the registered contacts, after it has already applied all 
of the configured services. And its my impression that VM is applied as 
a service, that sits in the signaling path, observes the responses from 
UAs, and then eventually routes to VM (using a configured URI). I don't 
see how 3841 preferences (either to prefer or reject VM) would ever be 
operable in this environment.

But I'd be pleased to hear that I'm wrong about this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Apr 2010 21:02:50 +0200

Hi,

>Its already there, defined in 3840: actor="msg-taker".

True.

>Yeah, I know that it uses 3841, but the last I knew it only did so to select among the registered contacts, after it has already applied all of the configured services.
>
>And its my impression that VM is applied as a service, that sits in the signaling path, observes the responses from
>UAs, and then eventually routes to VM (using a configured URI). I don't see how 3841 preferences (either to prefer or reject VM) would ever be

As far as I know you can use ANY information, including feature tag values, to choose the application servers to which an initial request is to be routed (the procedure is called initial filter criteria in IMS language) - or decide not to route the request to any ASs. And, I don't think there is anything in the IMS specifications that forbids a user to have a "local" voice mail service.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 5 Apr 2010 17:40:01 -0500

On Apr 5, 2010, at 8:03 AM, Paul Kyzivat wrote:
> g-taker".
>
>>> AFAIK, IMS isn't set up in a way to have an identifiable contact  
>>> for the VM server that it could return in the 3xx. (But I'll be  
>>> pleasantly surprised to learn I'm wrong.)
>> IMS uses 3841.
>
> Yeah, I know that it uses 3841, but the last I knew it only did so  
> to select among the registered contacts, after it has already  
> applied all of the configured services. And its my impression that  
> VM is applied as a service, that sits in the signaling path,  
> observes the responses from UAs, and then eventually routes to VM  
> (using a configured URI). I don't see how 3841 preferences (either  
> to prefer or reject VM) would ever be operable in this environment.

AFAIK, the AS MAY divert the INVITE to the configured VM URI if there  
is one, the user's profile allows this, and the request indicates a  
preference for VM.
--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Apr 2010 19:09:35 -0400

Dean Willis wrote:
>>>> AFAIK, IMS isn't set up in a way to have an identifiable contact for 
>>>> the VM server that it could return in the 3xx. (But I'll be 
>> of the configured services. And its my impression that VM is applied 
>> as a service, that sits in the signaling path, observes the responses 
>> from UAs, and then eventually routes to VM (using a configured URI). I 
>> don't see how 3841 preferences (either to prefer or reject VM) would 
>> ever be operable in this environment.
> 
> AFAIK, the AS MAY divert the INVITE to the configured VM URI if there is 
> one, the user's profile allows this, and the request indicates a 
> preference for VM.

My *impression* is that the AS would receive the call initially, note 
that VM is configured, set a timer for itself, Record-Route itself, and 
forward the call back to the S-CSCF. Eventually the S-CSCF will get 
around to considering registered contacts. If it honors 
Request-Disposition:redirect, then it will return a 3xx with the 
registered contacts.

That 3xx will be received by the AS. If it is clever, it will realize 
the best thing it can do is add its VM contact to the 3xx, with a lower 
priority than all the others.

If so, then the caller should indeed see all the possibilities, with 
their capabilities, and be able to make its own choice.

That's actually the best outcome I have ever seen for this with IMS.
I hope it all works that way. Without Request-Disposition:redirect I 
have not seen how this would ever work right for IMS.

Chalk up another success for redirect rather than forking.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 5 Apr 2010 19:08:54 -0500

On Apr 5, 2010, at 6:09 PM, Paul Kyzivat wrote:
>>
>
> My *impression* is that the AS would receive the call initially,  
> note that VM is configured, set a timer for itself, Record-Route  
> itself, and forward the call back to the S-CSCF. Eventually the S- 
> CSCF will get around to considering registered contacts. If it  
> honors Request-Disposition:redirect, then it will return a 3xx with  
> the registered contacts.
>
> That 3xx will be received by the AS. If it is clever, it will  
> realize the best thing it can do is add its VM contact to the 3xx,  
> with a lower priority than all the others.
>

Hmm.I thought that the S-CSCF would chain the INVITE through a series  
of AS, and if an AS's service needed to, it would just divert the call  
to VM instead of sending it to the next AS. At least that's the way we  
wrote the stuff originally, and it's how Dynamicsoft's stuff worked.

In other words, an AS can generate the 200 OK on an initial INVITE,  
short-circuiting the other ASs (as well as any Registered Contacts)  
that might have been invoked by the profile. This 200OK follows the  
inverted route back through any other AS that had been invoked on the  
call, on to the S-CSCF, and back towards the originating UA.

So, for example if the first AS invoked is set up to do a "Busy  
Everywhere", that's what gets returned to the caller, no matter what  
other AS might have been in the profile or what contacts might be  
registered. It makes for some careful service composition logic -- yo  
ucan shoot yourself in the foot -- but the composition mechanics are a  
lot easier than what I think you;re describing.

Did somebody change this stuff while I wasn't looking?

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 07:35:17 +0200

Hi, 

>>that VM is configured, set a timer for itself, Record-Route itself, 
>>and forward the call back to the S-CSCF. Eventually the S- 
>>CSCF will get around to considering registered contacts. If it honors 
>>That 3xx will be received by the AS. If it is clever, it 
>>will realize the best thing it can do is add its VM contact to the 3xx, with a 
>>lower priority than all the others.
>>
>Hmm.I thought that the S-CSCF would chain the INVITE through 
>a series of AS, and if an AS's service needed to, it would 
>just divert the call to VM instead of sending it to the next 
>AS. At least that's the way we wrote the stuff originally, 
>and it's how Dynamicsoft's stuff worked.
> 
>In other words, an AS can generate the 200 OK on an initial 
>INVITE, short-circuiting the other ASs (as well as any 
>Registered Contacts) that might have been invoked by the 
>profile. This 200OK follows the inverted route back through 
>any other AS that had been invoked on the call, on to the 
>S-CSCF, and back towards the originating UA.
> 
>So, for example if the first AS invoked is set up to do a 
>"Busy Everywhere", that's what gets returned to the caller, 
>no matter what other AS might have been in the profile or 
>what contacts might be registered. It makes for some careful 
>service composition logic -- yo ucan shoot yourself in the 
>foot -- but the composition mechanics are a lot easier than 
>what I think you;re describing.
> 

You haven't been looking for a long time :)

Anyway, I don't think it has been changed. But, I think you are talking about an INVITE 3xx use-case, not an OPTIONS 3xx use-case.

OPTIONS is used in order to query capabilities, and I think it is a policy/implementation issue whether the operator wants to return contacts pointing to specific services.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Apr 2010 08:49:21 -0400

Dean Willis wrote:
>> and forward the call back to the S-CSCF. Eventually the S-CSCF will 
>> get around to considering registered contacts. If it honors 
>> the best thing it can do is add its VM contact to the 3xx, with a 
> Hmm.I thought that the S-CSCF would chain the INVITE through a series of 
> AS, and if an AS's service needed to, it would just divert the call to 
> VM instead of sending it to the next AS. At least that's the way we 

My knowledge is probably no more recent than yours.
AFAIK it *could* do that. But in the case of VM, it first has to know 
that VM is required on the call. Normally that doesn't happen until the 
registered contacts are tried. And VM isn't one of the registered contacts.

So I *think* the AS just lurks as a proxy to see what else will happen, 
and then later might divert the call to VM.

> short-circuiting the other ASs (as well as any Registered Contacts) that 
> might have been invoked by the profile. This 200OK follows the inverted 
> route back through any other AS that had been invoked on the call, on to 
> the S-CSCF, and back towards the originating UA.

It could do that if it was able to conclude that VM was the desired 
outcome without trying any of the other candidates. But how would it 
figure that out?

> Did somebody change this stuff while I wasn't looking?

Probably not.

But either we should stop talking about it here, or else we should get 
somebody who really knows to tell us the answer.

	Thanks,
	Paul

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Tue, 6 Apr 2010 16:01:26 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Salvatore Loreto [[email-masked]]
Sent: Thursday, April 01, 2010 3:36 AM

A good mechanism to discovery UA capabilities is essential to provide meaningful service:
So I am in favor of pursuing the work,
in particular the possibility to use a single OPTIONS request to retrieve the capabilities from ALL UAS(s) behind a forking proxy.
_______________________________________

I think it is a misconception to use UA discovery to provide services.  The difficulty is that the set of available UAs for a given destination URI changes unpredictably -- elements become inacessible (mobile phone out of range!), call routing changes due to time of day, etc.  Instead, SIP provides a remarkably effective system for selecting the best target of a call *at the moment the call is initiated* -- the caller declares his preferences, and the various intermediate elements combine the caller's desires with the routing information that they possess to forward the call closer to the preferred destination.

As a developer, I've had to wrestle with this.  In order to provide clean "Is extension 1234 busy?" information, our "BLF agent" maintains subscriptions to the "reg" event package for the AOR "sip:[email-masked]".  For each reported contact for the AOR, it maintains a dialog subscription to the contact.  Only by tracking the "reg" events can it keep track of the UAs available for that AOR.  And even then, it is at the mercy of network failures.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 22:08:04 +0200

Hi Dale,

>From my perspective, the main use-case is not to discover services, but to discover capabilities in order to determine what services can be applied.

The idea is also that the OPTIONS request would be sent prior to the INVITE, to try to make sure that the returned contacts are actually available.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of WORLEY, DALE R (DALE) [[email-masked]]
Sent: Tuesday, April 06, 2010 11:01 PM
To: Salvatore Loreto; [email-masked]
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

Dale
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Tue, 6 Apr 2010 16:10:20 -0400

No matter what we do here, it is inevitable that the implementions of OPTIONS in the network will be very uneven.  Uneven to the degree that it is unlikely that any SIP element will be able to depend on another SIP element's OPTIONS response to automatically decide how to proceed.  (Possibly with the exception of "If I send OPTIONS to an IP address and get a response, then the SIP element at that IP address is functional.")  The sipXecs system that I work on uses OPTIONS for liveness testing when we are manually monitoring a system, but the failure responses are handed over to a human for comprehension; forking et al. considers only responses to "real" requests.

Within that context, if we want to define robust ways to probe the SIP network, we should define new protocol elements, preferably new methods, with carefully defined behaviors.

On the other hand, I see benefit in defining not best practices (which we consider should exclude all others) but "good practices" (guides to implementors of OPTIONS) and especially "warnings to users" (caveats to users of OPTIONS that it may not function as they desire).

Dale

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Tue, 6 Apr 2010 16:12:05 -0400

> From: Christer Holmberg [[email-masked]]

> From my perspective, the main use-case is not to discover services,
> but to discover capabilities in order to determine what services can be applied.

That's very difficult, though, as you need to monitor when the contacts become available
and unavailable.  It's more reliable to attempt the call with the service active, and if it fails,
fall back to attempting the call without the service.

> The idea is also that the OPTIONS request would be sent prior to the INVITE,
> to try to make sure that the returned contacts are actually available.

Why not just send the INVITE and see if it fails?  In the most common case (success), that
saves one round-trip.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 22:55:04 +0200

Hi,

>Why not just send the INVITE and see if it fails?  In the most common case (success), that saves one round-trip.

Because that is crappy protocol design. And, the INVITE might trigger different resources etc to be reserved, so you don't want to keep sending those.

Please not that functionwise I am not trying to "enhance" OPTIONS as such - I am simply trying to solve the forking case.

Otherwise, if we think OPTIONS is useless, it should be removed from the protocol...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 23:05:40 +0200

Hi,

>No matter what we do here, it is inevitable that the implementions of OPTIONS in the network will be very uneven.  Uneven to the degree that it is unlikely that any SIP element will be able to depend on another SIP element's OPTIONS response to automatically decide 
>how to proceed.  (Possibly with the exception of "If I send OPTIONS to an IP address and get a response, then the SIP element at that IP address is functional.")

I don't agree. There is much usable information you can receive in the OPTIONS response.

>The sipXecs system that I work on uses OPTIONS for liveness testing when we are manually monitoring a system, but the failure responses are handed over to a human for comprehension; forking et al. considers only responses to "real" requests.

So, maybe you can now start using OPTIONS for what it was intented to be used for :)

>Within that context, if we want to define robust ways to probe the SIP network, we should define new protocol elements, preferably new methods, with carefully defined behaviors.

Sure, if someone comes up with cases that OPTIONS can't be used for. At this point I think we are only speculating, especially since OPTIONS hasn't been used very much for capability quering. And, the forking issue has at least been one reason for that.

>On the other hand, I see benefit in defining not best practices (which we consider should exclude all others) but "good practices" (guides to implementors of OPTIONS) and especially "warnings to use…

Whatever you wanna call it :)

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 08:31:57 +0200

I agree with Dale. What happens to an OPTIONS request will not necessarily be reflected when an INVITE request is sent shortly afterwards. As a further examples, in contact centres, it is usual to distribute calls cyclically or randomly between qualified and available agents. Sending an INVITE request to a UA determined by responses to an OPTIONS request would break that model - the issuer of the OPTIONS and INVITE requests cannot be expected to obey the same rotation rules as the domain proxy that routes INVITE requests. Issuing an INVITE request to the AOR is unlikely to result in it being delivered to the UA that might be expected from analysis of responses to an OPTIONS request.

I don't think we should work on trying to make OPTIONS work for this purpose. If we really need to do anything with OPTIONS, we should just issue warnings about its unsuitability for purposes other than a simple ping.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of WORLEY, DALE R (DALE)
> Sent: 06 April 2010 21:01
> From: [email-masked] [[email-masked]] On 
> Behalf Of Salvatore Loreto [[email-masked]]
> in particular the possibility to use a single OPTIONS request 
> to retrieve the capabilities from ALL UAS(s) behind a forking proxy.
> I think it is a misconception to use UA discovery to provide 
> services.  The difficulty is that the set of available UAs 
> for a given destination URI changes unpredictably -- elements 
> become inacessible (mobile phone out of range!), call routing 
> changes due to time of day, etc.  Instead, SIP provides a 
> remarkably effective system for selecting the best target of 
> a call *at the moment the call is initiated* -- the caller 
> declares his preferences, and the various intermediate 
> elements combine the caller's desires with the routing 
> information that they possess to forward the call closer to 
> the preferred destination.
> 
> As a developer, I've had to wrestle with this.  In order to 
> provide clean "Is extension 1234 busy?" information, our "BLF 
> agent" maintains subscriptions to the "reg" event package for 
> the AOR "sip:[email-masked]".  For each reported contact 
> for the AOR, it maintains a dialog subscription to the 
> contact.  Only by tracking the "reg" events can it keep track 
> of the UAs available for that AOR.  And even then, it is at 
> the mercy of network failures.
> 
> Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 08:37:29 +0200

Hi, 

>I agree with Dale. What happens to an OPTIONS request will 
>not necessarily be reflected when an INVITE request is sent 
>shortly afterwards. As a further examples, in contact 
>centres, it is usual to distribute calls cyclically or 
>randomly between qualified and available agents.

Sure, there are cases when it may not be feasible.

>Sending an INVITE request to a UA determined by responses to an OPTIONS 
>request would break that model - the issuer of the OPTIONS 
>and INVITE requests cannot be expected to obey the same 
>rotation rules as the domain proxy that routes INVITE 
>requests. Issuing an INVITE request to the AOR is unlikely to 
>result in it being delivered to the UA that might be expected 
>from analysis of responses to an OPTIONS request.

I think the main use-case is when you want to contact end users. 

>I don't think we should work on trying to make OPTIONS work 
>for this purpose. If we really need to do anything with 
>OPTIONS, we should just issue warnings about its 
>unsuitability for purposes other than a simple ping.

Again, protocolwise we don't need to do anything for OPTIONS 3xx, because we already have the tools to do it :)

The question is whether it would be good to document it.

Regards,

Christer

> > From: [email-masked] [[email-masked]] 
> On Behalf Of 
> > Salvatore Loreto [[email-masked]]
> > So I am in favor of pursuing the work, in particular the 
> possibility 
> > to use a single OPTIONS request to retrieve the 
> capabilities from ALL 
> > UAS(s) behind a forking proxy.
> > I think it is a misconception to use UA discovery to 
> provide services.  
> > The difficulty is that the set of available UAs for a given 
> > destination URI changes unpredictably -- elements become 
> inacessible 
> > (mobile phone out of range!), call routing changes due to 
> time of day, 
> > etc.  Instead, SIP provides a remarkably effective system for 
> > selecting the best target of a call *at the moment the call is 
> > initiated* -- the caller declares his preferences, and the various 
> > intermediate elements combine the caller's desires with the routing 
> > information that they possess to forward the call closer to the 
> > preferred destination.
> > 
> > As a developer, I've had to wrestle with this.  In order to provide 
> > clean "Is extension 1234 busy?" information, our "BLF 
> agent" maintains 
> > subscriptions to the "reg" event package for the AOR 
> > "sip:[email-masked]".  For each reported contact for the AOR, it 
> > maintains a dialog subscription to the contact.  Only by 
> tracking the 
> > "reg" events can it keep track of the UAs available for 
> that AOR.  And 
> > even then, it is at the mercy of network failures.
> > 
> > Dale

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 08:55:57 +0200

> Sent: 07 April 2010 07:37
> To: Elwell, John; WORLEY, DALE R (DALE); Salvatore Loreto; 
> [email-masked]
[JRE] A contact centre agent is indeed an end user.

> Again, protocolwise we don't need to do anything for OPTIONS 
> 3xx, because we already have the tools to do it :)
[JRE] Yes, but a forking proxy at present probably doesn't issue 3xx responses, so for the mechanism to be usable we would need to mandate this behaviour. Then we would still be left with legacy forking proxies that don't support the newly mandated behaviour, so do we have to specify an option tag and Proxy-Require? I am not convinced we already have the tools.

> The question is whether it would be good to document it.
[JRE] As somebody else pointed out, if you want to obtain OPTIONS responses from individual UAs registered against an AOR, you can use the registration event package to identify them and send OPTIONS requests to them individually. If we are going to document a practice (which I do not necessarily agree with), we should at least consider alternatives.

John

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 09:01:48 +0200

Hi, 

>[JRE] A contact centre agent is indeed an end user.

Yes, but not the same kind of end user :)

>>Again, protocolwise we don't need to do anything for OPTIONS 3xx, 
>>because we already have the tools to do it :)
>[JRE] Yes, but a forking proxy at present probably doesn't 
>issue 3xx responses, so for the mechanism to be usable we 
>would need to mandate this behaviour. Then we would still be 
>left with legacy forking proxies that don't support the newly 
>mandated behaviour, so do we have to specify an option tag 
>and Proxy-Require? I am not convinced we already have the tools.

We have the Request-Disposition "redirect" feature tag.

No, I know that not all proxies support it, but the tool exists.

There is NO mechanism which will ensure that it always works. If the remote end doesn't support it - it won't work.

>[JRE] As somebody else pointed out, if you want to obtain 
>OPTIONS responses from individual UAs registered against an 
>AOR, you can use the registration event package to identify 
>them and send OPTIONS requests to them individually. If we 
>are going to document a practice (which I do not necessarily 
>agree with), we should at least consider alternatives.

I have no problem to also look at other solutions, and we can even allow different alternatives. It would be good to document the pros and cons of each alternatives, and people can then choose what to use based on their use-cases and requirements etc.

And, keep in mind that the event package solution requires support of the event package, so it won't always work either :)

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 09:09:44 +0200

> Sent: 07 April 2010 08:02
[JRE] So what kind of end user is within scope of this work? How does the issuer of OPTIONS/INVITE requests know whether he is targeting the right sort of end user for the mechanism to work? I think it is dangerous to base mechanisms on assumptions about particular types of end user.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 7 Apr 2010 09:23:52 +0200

This is a special case. And the application you are talking about is a
B2BUA, right?

In this case the AOR addressed is an application address without registered
contacts. One can argue that the OPTIONS request should return the general
capabilities of the application. No OPTIONS forking is happening in this
case, no registered contacts. No issue?

In reality what the B2BUA will do with the OPTION request (forward or
answer) depends on the fantasy of the B2BUA developer.

I dont think this scenario is actually usefull in discussing whether or not
to write a BCP on OPTIONS handling. Or maybe it is as implication of B2BUA
behaviours can be taken into account.

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John <
[email-masked]> wrote:

> I agree with Dale. What happens to an OPTIONS request will not necessarily
> be reflected when an INVITE request is sent shortly afterwards. As a further
> examples, in contact centres, it is usual to distribute calls cyclically or
> randomly between qualified and available agents. Sending an INVITE request
> to a UA determined by responses to an OPTIONS request would break that model
> - the issuer of the OPTIONS and INVITE requests cannot be expected to obey
> the same rotation rules as the domain proxy that routes INVITE requests.
> Issuing an INVITE request to the AOR is unlikely to result in it being
> delivered to the UA that might be expected from analysis of responses to an
> OPTIONS request.
>
> I don't think we should work on trying to make OPTIONS work for this
> purpose. If we really need to do anything with OPTIONS, we should just issue
> warnings about its unsuitability for purposes other than a simple ping.
>
> John
>
>
> > the AOR "sip:[email-masked] <[email-masked]>".  For each
> reported contact

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 7 Apr 2010 09:34:15 +0200

On Wed, Apr 7, 2010 at 9:09 AM, Elwell, John <
[email-masked]> wrote:

> [JRE] So what kind of end user is within scope of this work? How does the
> issuer of OPTIONS/INVITE requests know whether he is targeting the right
> sort of end user for the mechanism to work? I think it is dangerous to base
> mechanisms on assumptions about particular types of end user.
>
> [HE] I guess as long as the AOR addressed represents the user and the AOR's
domain portion is owned by the proxy at which the user registered with the
AOR's user-portion. Then there is no need to distinguish end users.

Throwing in any B2BUA or other anomaly will of course break things. But that
is in the nature of SIP's design.   And maybe not really relevant for this
discussion.

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 10:41:53 +0200

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 07 April 2010 08:24
> To: Elwell, John
> Cc: WORLEY, DALE R (DALE); Salvatore Loreto; [email-masked]
> This is a special case. And the application you are talking 
> about is a B2BUA, right?
[JRE] Not necessarily. A proxy can be scripted to cycle between multiple registered contacts. This doesn't make it a B2BUA.

John

> 
> In this case the AOR addressed is an application address 
> without registered contacts. One can argue that the OPTIONS 
> request should return the general capabilities of the 
> application. No OPTIONS forking is happening in this case, no 
> registered contacts. No issue?
> 
> In reality what the B2BUA will do with the OPTION request 
> (forward or answer) depends on the fantasy of the B2BUA developer.
> 
> I dont think this scenario is actually usefull in discussing 
> whether or not to write a BCP on OPTIONS handling. Or maybe 
> it is as implication of B2BUA behaviours can be taken into account. 
> 
> /Hans Erik van Elburg
> 
> 
> 
> On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> 	I agree with Dale. What happens to an OPTIONS request 
> will not necessarily be reflected when an INVITE request is 
> sent shortly afterwards. As a further examples, in contact 
> randomly between qualified and available agents. Sending an 
> INVITE request to a UA determined by responses to an OPTIONS 
> 	I don't think we should work on trying to make OPTIONS 
> work for this purpose. If we really need to do anything with 
> 	> the AOR "sip:[email-masked] 
> <mailto:[email-masked]> ".  For each reported contact

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 7 Apr 2010 11:18:15 +0200

Of course you can implement all kind of policies, but that makes this AOR
quite of a special user. I would argue that this is some kind of service AOR
and not a "normal" user AOR. The service AOR representing a group of
different and dynamically changing users...

Demonstrating that this is not a "normal" user.

I expect that in practice one would solve this differently... making the
case rather artificial.

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John <
[email-masked]> wrote:

> [JRE] Not necessarily. A proxy can be scripted to cycle between multiple
> registered contacts. This doesn't make it a B2BUA.
>
> John
>
> >
> >       > the AOR "sip:[email-masked] <[email-masked]>
> > <mailto:[email-masked] <[email-masked]>> ".  For each
> reported contact

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 12:26:25 +0200

Hi,

The forking proxy can also have policies what it returns in the 3xx, depending on what the end-users actually represent.

And, also with other mechanisms the returned data per end-user may depend on what type of end-point it represents. I don't think that is bound to a specific mechanism as such.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: 7. huhtikuuta 2010 12:18
To: Elwell, John
Cc: WORLEY, DALE R (DALE); [email-masked]
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

Of course you can implement all kind of policies, but that makes this AOR quite of a special user. I would argue that this is some kind of service AOR and not a "normal" user AOR. The service AOR representing a group of different and dynamically changing users...

I expect that in practice one would solve this differently... making the case rather artificial.

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John <[email-masked]<mailto:[email-masked]>> wrote:

> From: Hans Erik van Elburg [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: WORLEY, DALE R (DALE); Salvatore Loreto; [email-masked]<mailto:[email-masked]>

John

> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>       > From: [email-masked]<mailto:[email-masked]>
>
>       > [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> WORLEY, DALE R (DALE)
>       > To: Salvatore Loreto; [email-masked]<mailto:[email-masked]>
>       > From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On
>       > Behalf Of Salvatore Loreto [[email-masked]<mailto:[email-masked]>]
>       > the AOR "sip:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> ".  For each reported contact
>       > [email-masked]<mailto:[email-masked]>
>       [email-masked]<mailto:[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 13:04:09 +0200

> Sent: 07 April 2010 11:26
> To: Hans Erik van Elburg; Elwell, John
> The forking proxy can also have policies what it returns in 
> the 3xx, depending on what the end-users actually represent.
>  
> And, also with other mechanisms the returned data per 
> end-user may depend on what type of end-point it represents. 
> I don't think that is bound to a specific mechanism as such.
[JRE] Quite true. But Dale's point still holds - you might as well just send the INVITE request and see what happens.

John

> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> 	Of course you can implement all kind of policies, but 
> that makes this AOR quite of a special user. I would argue 
> that this is some kind of service AOR and not a "normal" user 
> AOR. The service AOR representing a group of different and 
> dynamically changing users...
> 	
> 	I expect that in practice one would solve this 
> differently... making the case rather artificial.
> 	
> 	/Hans Erik van Elburg
> 	
> 	
> 	On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John 
> 		[JRE] Not necessarily. A proxy can be scripted 
> to cycle between multiple registered contacts. This doesn't 
> make it a B2BUA.
> 		
> 		John
> 		
> 
> 		>
> [[email-masked]] On
> 		>       > A good mechanism to discovery UA 
> capabilities is essential to
> 		>       > provide meaningful service:
> 		>       > to retrieve the capabilities from ALL 
> UAS(s) behind a
> 		> forking proxy.
> <mailto:[email-masked]> 
> 		
> 		> <mailto:[email-masked] 
> <mailto:[email-masked]> > ".  For each reported contact
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 13:08:33 +0200

Hi, 

>>The forking proxy can also have policies what it returns in the 3xx, 
>>depending on what the end-users actually represent.
>>  
>>And, also with other mechanisms the returned data per end-user may 
>>depend on what type of end-point it represents.

Of course. But, as I said, that is really bad protocol design, and it may trigger unwanted resource reservation actions etc in the network.

And, there could even be cases where the INVITE doesn't fail, but you don't get the optimized user experience since the request may have looked different should you have known what the receiver supports.

Regards,

Christer

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 7 Apr 2010 07:29:53 -0400

Hi,

So in the interests of good protocol design...

Should we recap the different use cases we want this behaviour for?

Some cases may fall into the 'just send an INVITE camp' and others
which may be probing for support of event packages or specific media
capabilities and sending an INVITE is not helpful.

I had at first liked the idea but of using reg-events for some of this
- but endpoints which disappear (and do not expire their registration)
will not be reported absent until the next refresh cycle - which makes
that approach not usable IMHO.

Use cases I can (personally) see wanting:
- basic fork to see IF there even are multiple UAs at the AOR (and get
their gruus so a specific UA can subsequently be called, subscribed to
etc.))
- gather event support and media capabilities of the UAs
- others?

Peter

On Wed, Apr 7, 2010 at 7:08 AM, Christer Holmberg
<[email-masked]> wrote:
>> >             > -----Original Message-----
>> >             > From: Hans Erik van Elburg
>> > [mailto:[email-masked]]
>> >             > Sent: 07 April 2010 08:24
>> >             > To: Elwell, John
>> >             > Cc: WORLEY, DALE R (DALE); Salvatore Loreto;
>> > [email-masked]
>> >             > Subject: Re: [sipcore] SIP OPTIONS: Shall we
>> > work on this?
>> >             >
>> >
>> >             > This is a special case. And the application
>> > you are talking
>> >             > about is a B2BUA, right?
>> >
>> >             >
>> >             > In this case the AOR addressed is an
>> > application address
>> >             > without registered contacts. One can argue
>> > that the OPTIONS
>> >             > request should return the general capabilities of the
>> >             > application. No OPTIONS forking is happening
>> > in this case, no
>> >             > registered contacts. No issue?
>> >             >
>> >             > In reality what the B2BUA will do with the
>> > OPTION request
>> >             > (forward or answer) depends on the fantasy of
>> > the B2BUA developer.
>> >             >
>> >             > I dont think this scenario is actually
>> > usefull in discussing
>> >             > whether or not to write a BCP on OPTIONS
>> > handling. Or maybe
>> >             > it is as implication of B2BUA behaviours can
>> > be taken into account.
>> >             >
>> >             > /Hans Erik van Elburg
>> >             >
>> >             >
>> >             >
>> >             > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John
>> >             > <[email-masked]> wrote:
>> >             >
>> >             >
>> >             >       I agree with Dale. What happens to an
>> > OPTIONS request
>> >             > will not necessarily be reflected when an
>> > INVITE request is
>> >             > sent shortly afterwards. As a further
>> > examples, in contact
>> >             > centres, it is usual to distribute calls cyclically or
>> >             > randomly between qualified and available
>> > agents. Sending an
>> >             > INVITE request to a UA determined by
>> > responses to an OPTIONS
>> >             > request would break that model - the issuer
>> > of the OPTIONS
>> >             > and INVITE requests cannot be expected to
>> > obey the same
>> >             > rotation rules as the domain proxy that routes INVITE
>> >             > requests. Issuing an INVITE request to the
>> > AOR is unlikely to
>> >             > result in it being delivered to the UA that
>> > might be expected
>> >             > from analysis of responses to an OPTIONS request.
>> >             >
>> >             >       I don't think we should work on trying
>> > to make OPTIONS
>> >             > work for this purpose. If we really need to
>> > do anything with
>> >             > OPTIONS, we should just issue warnings about its
>> >             > unsuitability for purposes other than a simple ping.
>> >             >
>> >             >       John
>> >             >
>> >             >
>> >             >
>> >             >       > -----Original Message-----
>> >             >       > From: [email-masked]
>> >             >
>> >             >       > [mailto:[email-masked]] On Behalf Of
>> >             > WORLEY, DALE R (DALE)
>> >             >       > Sent: 06 April 2010 21:01
>> >             >       > To: Salvatore Loreto; [email-masked]
>> >             >       > Subject: Re: [sipcore] SIP OPTIONS:
>> > Shall we work on this?
>> >             >       >
>> >             >       > ________________________________________
>> >             >
>> >             >       > From: [email-masked]
>> >             >       > Behalf Of Salvatore Loreto
>> > [[email-masked]]
>> >             >       > Sent: Thursday, April 01, 2010 3:36 AM
>> >             >       >
>> >             >       > A good mechanism to discovery UA
>> >             >       > provide meaningful service:
>> >             >       > So I am in favor of pursuing the work,
>> >             >       > in particular the possibility to use
>> > a single OPTIONS request
>> >             >       > to retrieve the capabilities from ALL
>> > UAS(s) behind a
>> >             > forking proxy.
>> >             >       > _______________________________________
>> >             >       >
>> >             >       > I think it is a misconception to use
>> > UA discovery to provide
>> >             >       > services.  The difficulty is that the
>> > set of available UAs
>> >             >       > for a given destination URI changes
>> > unpredictably -- elements
>> >             >       > become inacessible (mobile phone out
>> > of range!), call routing
>> >             >       > changes due to time of day, etc.
>> > Instead, SIP provides a
>> >             >       > remarkably effective system for
>> > selecting the best target of
>> >             >       > a call *at the moment the call is
>> > initiated* -- the caller
>> >             >       > declares his preferences, and the
>> > various intermediate
>> >             >       > elements combine the caller's desires
>> > with the routing
>> >             >       > information that they possess to
>> > forward the call closer to
>> >             >       > the preferred destination.
>> >             >       >
>> >             >       > As a developer, I've had to wrestle
>> > with this.  In order to
>> >             >       > provide clean "Is extension 1234
>> > busy?" information, our "BLF
>> >             >       > agent" maintains subscriptions to the
>> > "reg" event package for
>> >             >       > the AOR "sip:[email-masked]
>> >             > <mailto:[email-masked]
>> >             >       > for the AOR, it maintains a dialog
>> > subscription to the
>> >             >       > contact.  Only by tracking the "reg"
>> > events can it keep track
>> >             >       > of the UAs available for that AOR.
>> > And even then, it is at
>> >             >       > the mercy of network failures.
>> >             >       >
>> >             >       > Dale
>> >             >       >
>> >             >       > sipcore mailing list
>> >             >       > [email-masked]
>> >             >       > https://www.ietf.org/mailman/listinfo/sipcore
>> >             >       >
>> >             >       _______________________________________________
>> >             >       sipcore mailing list
>> >             >       [email-masked]
>> >             >       https://www.ietf.org/mailman/listinfo/sipcore
>> >             >
>> >             >
>> >             >
>> >             >
>> >
>> >
>> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 13:35:33 +0200

Hi,

The use-case to gather capabilities of an UAS is already there - I assume that's the reason OPTIONS was added in the first place :)

What we are discussing is simply to get the capabilities in the forking case, when there are multiple UASs associated with the AOR.

So, I am simply trying to make an existing capability usable for the the forking case. Nothing more - nothing less :)

If we don't like OPTIONS, let's deprecate it... Having methods and functions, but at the same time saying that it doesn't work and we therefor shouldn't use it, is very confusing...

Regards,

Christer

> From: Peter Musgrave [mailto:[email-masked]] 
> Sent: 7. huhtikuuta 2010 14:30
> To: Christer Holmberg
> Cc: Elwell, John; Hans Erik van Elburg; WORLEY, DALE R 
> (DALE); [email-masked]
> Some cases may fall into the 'just send an INVITE camp' and 
> others which may be probing for support of event packages or 
> specific media capabilities and sending an INVITE is not helpful.
> 
> - but endpoints which disappear (and do not expire their 
> registration) will not be reported absent until the next 
> refresh cycle - which makes that approach not usable IMHO.
> 
> - basic fork to see IF there even are multiple UAs at the AOR 
> (and get their gruus so a specific UA can subsequently be 
> called, subscribed to
> etc.))
> >>[JRE] Quite true. But Dale's point still holds - you might 
> as well just send the INVITE request and see what happens.
> >
> > Of course. But, as I said, that is really bad protocol 
> design, and it may trigger unwanted resource reservation 
> actions etc in the network.
> >
> > And, there could even be cases where the INVITE doesn't 
> fail, but you don't get the optimized user experience since 
> the request may have looked different should you have known 
> what the receiver supports.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >
> >
> >> >     Of course you can implement all kind of policies, but that 
> >> > makes this AOR quite of a special user. I would argue 
> that this is 
> >> > some kind of service AOR and not a "normal" user AOR. 
> The service 
> >> > AOR representing a group of different and dynamically changing 
> >> > users...
> >> >
> >> >             > Subject: Re: [sipcore] SIP OPTIONS: Shall 
> we work on 
> >> > this?
> >> >             >
> >> >
> >> >             > This is a special case. And the 
> application you are 
> >> > talking
> >> >             [JRE] Not necessarily. A proxy can be 
> scripted to cycle 
> >> > between multiple registered contacts. This doesn't make 
> it a B2BUA.
> >> >
> >> >             John
> >> >
> >> >
> >> >             >
> >> >             > In this case the AOR addressed is an application 
> >> > address
> that the 
> >> > OPTIONS
> >> >             > application. No OPTIONS forking is 
> happening in this 
> >> > case, no
> >> >             > In reality what the B2BUA will do with the OPTION 
> >> > request
> >> >             > (forward or answer) depends on the fantasy of the 
> >> > B2BUA developer.
> >> >             >
> >> >             > I dont think this scenario is actually usefull in 
> >> > discussing
> handling. Or 
> >> > maybe
> >> >             > it is as implication of B2BUA behaviours 
> can be taken 
> >> > into account.
> >> >             >
> >> >             > /Hans Erik van Elburg
> >> >             >
> >> >             >
> >> >             >
> >> >             >       I agree with Dale. What happens to 
> an OPTIONS 
> >> > request
> >> >             > will not necessarily be reflected when an INVITE 
> >> > request is
> >> >             > sent shortly afterwards. As a further examples, in 
> >> > contact
> >> >             > centres, it is usual to distribute calls 
> cyclically 
> >> > or
> >> >             > randomly between qualified and available agents. 
> >> > Sending an
> responses to an 
> >> > OPTIONS
> >> >             > request would break that model - the issuer of the 
> >> > OPTIONS
> >> >             > and INVITE requests cannot be expected to obey the 
> >> > same
> >> >             > requests. Issuing an INVITE request to the AOR is 
> >> > unlikely to
> >> >             > result in it being delivered to the UA 
> that might be 
> >> > expected
> >> >             >       I don't think we should work on 
> trying to make 
> >> > OPTIONS
> >> >             > work for this purpose. If we really need to do 
> >> > anything with
> >> >             >       > [mailto:[email-masked]] 
> On Behalf 
> >> > Of
> >> >             > WORLEY, DALE R (DALE)
> >> >             >       > in particular the possibility to 
> use a single 
> >> > OPTIONS request
> >> >             >       > I think it is a misconception to use UA 
> >> > discovery to provide
> >> >             >       > services.  The difficulty is that 
> the set of 
> >> > available UAs
> >> >             >       > become inacessible (mobile phone out of 
> >> > range!), call routing
> >> >             >       > declares his preferences, and the various 
> >> > intermediate
> >> >             >       > elements combine the caller's desires with 
> >> > the routing
> >> >             >       > As a developer, I've had to wrestle with 
> >> > this.  In order to
> >> >             >       > provide clean "Is extension 1234 busy?" 
> >> > information, our "BLF
> >> >             >       > agent" maintains subscriptions to 
> the "reg" 
> >> > event package for

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 14:56:38 +0200

> Sent: 07 April 2010 12:09
> To: Elwell, John; Hans Erik van Elburg
> the 3xx, 
> design,
[JRE] Why is it bad protocol design?

> and it may trigger unwanted resource reservation 
[JRE] Concerning resource reservation, there are two ways of looking at it. By doing resource reservation, you find out straight away if the resources needed to reach the UA are not available, so resource reservation could be considered a good thing. An OPTIONS transaction is never going to provide this information. On the other hand, if you want to avoid resource reservation, just send an offerless INVITE request.

John

> 
> And, there could even be cases where the INVITE doesn't fail, 
> but you don't get the optimized user experience since the 
> request may have looked different should you have known what 
> the receiver supports.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> > > 		> forking proxy.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 7 Apr 2010 15:05:28 +0200

John,

You are illustrating the case that bad design leads to: You need to be aware
of the side effects of one method, so that you can circumvent these to use
it for other purposes then it was intended for.

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 2:56 PM, Elwell, John <
[email-masked]> wrote:

> [JRE] Concerning resource reservation, there are two ways of looking at it.
> By doing resource reservation, you find out straight away if the resources
> needed to reach the UA are not available, so resource reservation could be
> considered a good thing. An OPTIONS transaction is never going to provide
> this information. On the other hand, if you want to avoid resource
> reservation, just send an offerless INVITE request.
>
> John
>
>
> >
> > > >           >       > the AOR "sip:[email-masked]<[email-masked]>
> > > > <mailto:[email-masked] <[email-masked]>>
> > > >
> > > >           > <mailto:[email-masked]<[email-masked]>
> > > > <mailto:[email-masked] <[email-masked]>> > ".
>  For each reported contact
> > > >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 15:05:49 +0200

Hi, 

>>Of course. But, as I said, that is really bad protocol design,

Since we have a mechanism where we can query users, I think is nicer to use.

Now, I am not saying that you need to send OPTIONS prior to every call. My main use-case is where the INVITE itself may look different depending on the capabilities. So, again, an INVITE may not even fail, but you may not get exactly what you would have wanted.

>>and it may trigger unwanted resource reservation actions etc in the 
>>network.
>[JRE] Concerning resource reservation, there are two ways of 
>looking at it. By doing resource reservation, you find out 
>straight away if the resources needed to reach the UA are not 
>available, so resource reservation could be considered a good 
>thing.

You will most likely not figure out whether the resources are available, in case there is no provisional response etc.

>An OPTIONS transaction is never going to provide this information. On the other hand, if you want to avoid resource 

That is going to bring other issues, if the SDP is part of the service information etc.

In addition, the resources do not necessarily be related to the SDP and the media plane.

Regards,

Christer

> fail, but you 
> > don't get the optimized user experience since the request may have 
> > looked different should you have known what the receiver supports.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > > 	Of course you can implement all kind of 
> policies, but that makes 
> > > > this AOR quite of a special user. I would argue that 
> this is some 
> > > > kind of service AOR and not a "normal" user AOR. The 
> service AOR 
> > > > representing a group of different and dynamically changing 
> > > > users...
> > > > 	
> scripted to cycle between 
> > > > multiple registered contacts. This doesn't make it a B2BUA.
> > > > 		
> > > > 		John
> > > > 		
> > > > 
> > > > 		>
> > > > 		> (forward or answer) depends on the 
> fantasy of the B2BUA 
> > > > developer.
> > > > 		>
> > > > 		> it is as implication of B2BUA

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 15:30:03 +0200

> Sent: 07 April 2010 14:06
> end-user may 
[JRE] But even if you then target the INVITE request at the GRUU of the preferred user, there is no guarantee it will succeed (e.g., no media resources, UA has become busy in the meantime), and because it is targeted directly, you lose the opportunity to take alternative action, e.g., forwarding to voicemail or to another UA with similar capabilities. It is a case of the calling user trying to override policies associated with the called user, which I think is a bad thing. The result of the OPTIONS request can only ever act as a guideline - it is effectively no better than presence.

It would be helpful to have a concrete example of something that could go into an INVITE request targeted at a particular UA known to have a particular capability, that could not go into an INVITE request targeted at the AOR and with caller preferences RECOMMENDING selection of a UA with that particular capability. Apologies if such an example has already been given earlier in the discussion.

John

> 
> Now, I am not saying that you need to send OPTIONS prior to 
> every call. My main use-case is where the INVITE itself may 
> look different depending on the capabilities. So, again, an 
> INVITE may not even fail, but you may not get exactly what 
> you would have wanted.
> 
> You will most likely not figure out whether the resources are 
> available, in case there is no provisional response etc.
> 
> >An OPTIONS transaction is never going to provide this 
> information. On the other hand, if you want to avoid resource

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Apr 2010 09:53:12 -0400

> Sent: Tuesday, April 06, 2010 4:08 PM
> To: WORLEY, DALE R (DALE); Salvatore Loreto; [email-masked]
> From my perspective, the main use-case is not to discover services, but to
> discover capabilities in order to determine what services can be applied.
> 
> The idea is also that the OPTIONS request would be sent prior to the
> INVITE, to try to make sure that the returned contacts are actually
> available.

But you know that would never work in practice/the-real-world.  Think about all the routing rules people have for INVITEs - in some cases *only* for INVITEs.  And even if they route OPTIONS identically in the SIP domain, for any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, or a H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a foobar-protocol-gateway, or a vmail server, or an announcement server, or an app server, etc.  Just because the OPTIONS reaches the end of the SIP domain, means nothing about whether an INVITE to the higher-layer target (which in practice is a E.164 number, that crosses from SIP into many other protocol domains) is actually available to receive a call.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Apr 2010 10:01:08 -0400

> Sent: Tuesday, April 06, 2010 4:55 PM
> >
> > Dale Worley said:
> > Why not just send the INVITE and see if it fails?  In the most common
> > case (success), that saves one round-trip.
> 
> Because that is crappy protocol design. And, the INVITE might trigger
> different resources etc to be reserved, so you don't want to keep sending
> those.

What's so crappy about using an INVITE to say you want to start a session?  A failure of an INVITE request isn't a protocol failure or error condition (unless the response code is an error condition type).  

What's next, we need an OPTIONS before the OPTIONS to make sure the second OPTIONS won't fail??  ;)

Sure the INVITE might trigger resources reservation - that's GOOD, because it verifies the resources are available - if those resources aren't available the request will fail, whereas for an OPTIONS it wouldn't have.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 7 Apr 2010 16:05:11 +0200

In such cases you will get the capabilities of the gateway where the SIP
domain is left. Why isn't that info useful?

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan <[email-masked]>wrote:

> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Christer Holmberg
> But you know that would never work in practice/the-real-world.  Think about
> all the routing rules people have for INVITEs - in some cases *only* for
> INVITEs.  And even if they route OPTIONS identically in the SIP domain, for
> any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, or a
> H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a
> foobar-protocol-gateway, or a vmail server, or an announcement server, or an
> app server, etc.  Just because the OPTIONS reaches the end of the SIP
> domain, means nothing about whether an INVITE to the higher-layer target
> (which in practice is a E.164 number, that crosses from SIP into many other
> protocol domains) is actually available to receive a call.
>
> -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Apr 2010 10:31:59 -0400

Because it means nothing about the capabilities for the INVITE, because the INVITE session's capabilities is dictated by the far-end beyond that gateway.

For example, I don't know what types of capabilities you guys are thinking of, but let's say it was for getting the codecs.  So you send an OPTIONS, and it gets to an H.323 gateway.  The gateway supports lots of codecs, so it gives you some nice big SDP.  Then you send an INVITE, thinking it can do some new-fangled codec.  But that INVITE makes an H.323 call get setup, where the H.245 from the far-end only did G.711, so the call fails.

Then there are 3PCC call scenarios, and middlebox transcoders, and codec-based routing, etc.  Different things happen with INVITES, at different times, due to different policies - none of which apply to OPTIONS.
The reality of the INVITE world is ugly. :(

-hadriel

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: Wednesday, April 07, 2010 10:05 AM
To: Hadriel Kaplan
Cc: Christer Holmberg; WORLEY, DALE R (DALE); Salvatore Loreto; [email-masked]
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

In such cases you will get the capabilities of the gateway where the SIP domain is left. Why isn't that info useful?

/Hans Erik van Elburg
On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Christer Holmberg
> To: WORLEY, DALE R (DALE); Salvatore Loreto; [email-masked]<mailto:[email-masked]>

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 7 Apr 2010 16:43:21 +0200

At the moment, my view is "Do nothing". The amount of resource needed for this discussion does not justify the problem.

If someone wants to submit an author draft on a specific issue and fix, then fine, I'll reconsider.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, March 30, 2010 8:06 PM
To: SIPCORE
Subject: [sipcore] SIP OPTIONS: Shall we work on this?

[as chair]

Thanks.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Apr 2010 09:49:18 -0500

[as an individual]

I think Hadriel is right.

The more I read through this thread, the more it looks like we're 
running around with a hammer, desperately looking for nails to hit. 
Barring nails, we'll settle for screws. Or bolts. Or maybe kittens, if 
it comes to that.

If you're trying to accomplish something, I would strongly recommend 
starting from the other end. Instead of saying "I have a tool, let's 
make a problem for it to solve," let's concentrate on clearly defining 
existing problems. Once we agree on the problems, we can talk about what 
tools make sense to solve them.

/a

On 4/7/10 9:31 AM, Hadriel Kaplan wrote:
>
> Because it means nothing about the capabilities for the INVITE, 
> because the INVITE session's capabilities is dictated by the far-end 
> beyond that gateway.
>
> For example, I don't know what types of capabilities you guys are 
> thinking of, but let's say it was for getting the codecs.  So you send 
> an OPTIONS, and it gets to an H.323 gateway.  The gateway supports 
> lots of codecs, so it gives you some nice big SDP.  Then you send an 
> INVITE, thinking it can do some new-fangled codec.  But that INVITE 
> makes an H.323 call get setup, where the H.245 from the far-end only 
> did G.711, so the call fails.
>
> Then there are 3PCC call scenarios, and middlebox transcoders, and 
> codec-based routing, etc.  Different things happen with INVITES, at 
> different times, due to different policies -- none of which apply to 
> OPTIONS.
>
> The reality of the INVITE world is ugly. L
>
> -hadriel
>
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* Wednesday, April 07, 2010 10:05 AM
> *To:* Hadriel Kaplan
> *Cc:* Christer Holmberg; WORLEY, DALE R (DALE); Salvatore Loreto; 
> [email-masked]
> In such cases you will get the capabilities of the gateway where the 
> SIP domain is left. Why isn't that info useful?
>
> /Hans Erik van Elburg
>
> > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On 
> Behalf
> > Of Christer Holmberg
> <mailto:[email-masked]>
> but to
> But you know that would never work in practice/the-real-world.  Think 
> about all the routing rules people have for INVITEs - in some cases 
> *only* for INVITEs.  And even if they route OPTIONS identically in the 
> SIP domain, for any given AoR it'll go to any of: a SIP UA, or a PSTN 
> gateway, or a H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a 
> foobar-protocol-gateway, or a vmail server, or an announcement server, 
> or an app server, etc.  Just because the OPTIONS reaches the end of 
> the SIP domain, means nothing about whether an INVITE to the 
> higher-layer target (which in practice is a E.164 number, that crosses 
> from SIP into many other protocol domains) is actually available to 
> receive a call.
>
> -hadriel
>
> [email-masked] <mailto:[email-masked]>

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Wed, 7 Apr 2010 10:46:01 -0400

If the UAC would send different INVITEs based on its idea of what facilities are present in the potential UASs, that is a severe failure of the architecture of the SIP system.  In proper use of SIP, the UAC specifies what it prefers in the INVITE, and the intermediate and destination elements determine how those preferences are to be satisfied based on the destination resources available at the moment of the INVITE.

If you have a use-case where the UAC cannot specify its needs in a way that conforms to the SIP architecture, there is a need for enhancement of how SIP allows the UAC to express its preferences.

Dale

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Apr 2010 09:52:40 -0500

[as an individual]

On 4/7/10 9:43 AM, DRAGE, Keith (Keith) wrote:
> At the moment, my view is "Do nothing". The amount of resource needed 
> for this discussion does not justify the problem.

I'm inclined to agree.

> fix, then fine, I'll reconsider.

To be fair, someone has.

http://www.ietf.org/id/draft-jones-sip-options-ping-00.txt

I'm not saying I support this document (nor do I necessarily oppose it), 
but there *is* a concrete proposal on the table.

/a

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Wed, 7 Apr 2010 10:55:39 -0400

________________________________________
From: Adam Roach [[email-masked]]
[as an individual]

If you're trying to accomplish something, I would strongly recommend starting from the other end. Instead of saying "I have a tool, let's make a problem for it to solve," let's concentrate on clearly defining existing problems. Once we agree on the problems, we can talk about what tools make sense to solve them.
________________________________

I think that Christer has a definite use situation in mind but hash't been very clear about exactly what it is.

IMHO, we need to consider several questions:

1. Is the proposed mechanism well-built?
2. Is the proposed mechanism a good way to achieve the desired functionality?
3. Is the desired functionality an architecturally sound way to satisfy the users' need?

Now, I think that clarifying how OPTIONS works is in general a good thing, even if the answer to questions 2 and 3 are No.  But to take this up as real WG work, we need to verify that questions 2 and 3 are Yes, before we start worrying about the details of the proposal.

So the first task is to lay out the users' needs that we are trying to address, and see if this sort of usage of OPTIONs is a reasonable solution to them.

Dale

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Wed, 7 Apr 2010 11:17:22 -0400

________________________________________
From: Hans Erik van Elburg [[email-masked]]

But a lot of AORs actually are service AORs and not "normal" users (that represent a small set of UAs that is fixed over long periods of time).  Worse, "service" AORs account for a much larger fraction of the traffic than their numbers indicate.  Consider "my company's IT helpdesk number".  You don't want to invent a mechanism that works for 90% of the AORs but only 10% of the calls made.

But also consider any sort of "intelligent network services".  Even moderately sophisticated call forwarding for a private household can eradicate the concept that an AOR is the front-end for a definite set of UAs.

If you want to get a call to the "right" destination, send the INVITE to the AOR.  Processing incoming INVITEs in a sensible manner is the one SIP functionality every intermediate element is likely to get right, because otherwise users would notice and complain.  And the only alternative is for the UAC to attempt to second-guess all the routing processing of every intermediate element, and every UAS, of every AOR.

Dale

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 7 Apr 2010 17:28:52 +0200

Your real  world scenario breaks any SIP specific feature... ;-)
Not sure if that was your point.

Still unclear what use case we are discussing here... but OPTIONS does not
necessarily need be used in combination with INVITE.

Just speculating: It could be used by application servers to detect the
capabilities devices a user has registered and do something with that. In
those scenarios maybe a presence server is to much of a burden and there is
no dark interworking nightmare that needs to be taken into account. 3xx
could well be used in this scenario to get all the capabilities of all the
registered devices.

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 4:31 PM, Hadriel Kaplan <[email-masked]>wrote:

>  Because it means nothing about the capabilities for the INVITE, because
> the INVITE session’s capabilities is dictated by the far-end beyond that
> gateway.
>
>
>
> For example, I don’t know what types of capabilities you guys are thinking
> of, but let’s say it was for getting the codecs.  So you send an OPTIONS,
> and it gets to an H.323 gateway.  The gateway supports lots of codecs, so it
> gives you some nice big SDP.  Then you send an INVITE, thinking it can do
> some new-fangled codec.  But that INVITE makes an H.323 call get setup,
> where the H.245 from the far-end only did G.711, so the call fails.
>
>
>
> different times, due to different policies – none of which apply to OPTIONS.
>
>   ------------------------------
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 Apr 2010 16:19:11 -0500

On Apr 7, 2010, at 6:35 AM, Christer Holmberg wrote:
>
> If we don't like OPTIONS, let's deprecate it... Having methods and  
> functions, but at the same time saying that it doesn't work and we  
> therefor shouldn't use it, is very confusing...
>

As I'm no longer the SIP chair, I think I can say that I feel the same  
way about forking. If we deprecate that, we fix the forking OPTIONS  
problem at the same time.

Seriously, OPTIONS+forking is a bad combination. If we don't formally  
deprecate forking, at least we can recommend it not be used for  
OPTIONS requests. Or we could amend 3261 to say "proxies MUST NOT fork  
OPTIONS request messages". Or we could add an options tag, and say  
"Proxies that support this extension MUST NOT fork OPTIONS".

Or we could go back to our comfortable head-in-sand positions. I'm OK  
with that; I just pull mine out occasionally to laugh at the other  
ostrich-bottoms on display.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 Apr 2010 16:23:41 -0500

On Apr 7, 2010, at 4:19 PM, Dean Willis wrote:

>
> Seriously, OPTIONS+forking is a bad combination. If we don't  
> formally deprecate forking, at least we can recommend it not be used  
> for OPTIONS requests. Or we could amend 3261 to say "proxies MUST  
> NOT fork OPTIONS request messages". Or we could add an options tag,  
> and say "Proxies that support this extension MUST NOT fork OPTIONS".
>

I left out OR we require that a proxy that would ordinarily fork the  
request instead act as a B2BUA and return an aggregate response.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 23:26:11 +0200

Hi,

>and say "Proxies that support this extension MUST NOT fork OPTIONS".

Using the O-3xx (I'm getting tired of writing OPTIONS 3xx :) mechanism the OPTIONS request isn't forked.

>I left out OR we require that a proxy that would ordinarily fork the request instead act as a B2BUA and 
>return an aggregate response.

That is of course one alternative, but the "beauty" of O-3xx is that you don't need to standardize anything. The tools are available (yes, I know we can't be 100% sure that it will always work), so the question is whether we somehow want to document how we can solve the forking problem by combining those tools.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Apr 2010 18:20:39 -0400

Sent: Wednesday, April 07, 2010 11:29 AM

Your real  world scenario breaks any SIP specific feature... ;-)
[hsk] Yup, and that's the real world of inter-domain routing right now. :(
Still unclear what use case we are discussing here... but OPTIONS does not necessarily need be used in combination with INVITE.

[hsk] we're only discussing that because it was one example Christer described for using he OPTIONS fork/3xx need.

Just speculating: It could be used by application servers to detect the capabilities devices a user has registered and do something with that. In those scenarios maybe a presence server is to much of a burden and there is no dark interworking nightmare that needs to be taken into account. 3xx could well be used in this scenario to get all the capabilities of all the registered devices.

[hsk] That was the exact question I asked previously on this topic - whether that App-server was the use-case in mind, because for that the problem is much simpler, and putting a new options-tag in a proxy-require is not only likely to work, but also reasonably easy to deploy.  As long as you constrain the use-case to be within the local domain, then doing things like proxy-require or even manual configuration and such is all reasonable, imho.  If you're talking about using it across domains instead, between any UAC to any UAS in the World/Internet, this thing is about as likely to fail as Tiger Woods' marriage.

/Hans Erik van Elburg

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 Apr 2010 19:25:01 -0500

On Apr 7, 2010, at 4:26 PM, Christer Holmberg wrote:

> Using the O-3xx (I'm getting tired of writing OPTIONS 3xx :)  
> mechanism the OPTIONS request isn't forked.

Right. Saying proxies MUST NOT fork OPTIONS does not preclude sending  
a 302 response. Or a new error code saying "Can't do that, too many  
targets", or anything else.

> That is of course one alternative, but the "beauty" of O-3xx is that  
> you don't need to standardize anything. The tools are available  
> (yes, I know we can't be 100% sure that it will always work), so the  
> question is whether we somehow want to document how we can solve the  
> forking problem by combining those tools.

Assuming your application doesn't have to be absolutely sure that the  
OPTIONS isn't forking, then you're right; this could be done entirely  
on an informational basis. Might even be reasonable as an individual  
informational: "An Alternative to Forking for OPTIONS Requests to  
Enable the Discovery of User-Agent-Server Capabilities in the Session  
Initiation Protocol." Sounds like a good thesis project for a telecom  
student or senior project for an undergrad. Probably doesn't need to  
be a working-group effort.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 11:46:56 +0200

Hi,

>>>Why not just send the INVITE and see if it fails?  In the most 
>>>common case (success), that saves one round-trip.
>> 
>>different resources etc to be reserved, so you don't want to keep 
>>sending those.
> 
>What's so crappy about using an INVITE to say you want to 
>start a session?  A failure of an INVITE request isn't a 
>protocol failure or error condition (unless the response code 
>is an error condition type).  
> 
>Sure the INVITE might trigger resources reservation - that's 
>GOOD, because it verifies the resources are available - if 
>those resources aren't available the request will fail, 
>whereas for an OPTIONS it wouldn't have.

The resources will be released when the first INVITE is rejected, and a new resource reservation procedure will start when the next INVITE comes.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 12:12:34 +0200

Hi,
 
>[JRE] But even if you then target the INVITE request at the 
>GRUU of the preferred user, there is no guarantee it will 
>succeed (e.g., no media resources, UA has become busy in the 
>meantime), and because it is targeted directly, you lose the 
>opportunity to take alternative action, e.g., forwarding to 
>voicemail or to another UA with similar capabilities. It is a 
>case of the calling user trying to override policies 
>associated with the called user, which I think is a bad 
>thing. The result of the OPTIONS request can only ever act as 
>a guideline - it is effectively no better than presence.
> 
>It would be helpful to have a concrete example of something 
>that could go into an INVITE request targeted at a particular 
>UA known to have a particular capability, that could not go 
>into an INVITE request targeted at the AOR and with caller 
>preferences RECOMMENDING selection of a UA with that 
>particular capability. Apologies if such an example has 
>already been given earlier in the discussion.

I don't think I have said that the INVITE would necessarily be targeted to a particular UA. There MAY of course be use-cases where you would target also the INVITE to a specific UAS. For example, if an UAS supports a specific capability, and you don't want the call to proceed unless that UAS accepts the INVITE. Then, if the INVITE fails, it may still be possible for the call to be forwarded to a voice mail etc, depending on policies and service design in the network.

But, the main point of the O-3xx mechanisms is that it allows you to target *OPTIONS* request to particular UAs, in order to get the capabilities of those.

That is the only thing the mechanism is supposed to provide. What you then do with that information is a separate issue, and that seems to be what the discussion is now about.

Now, we can discuss use-cases etc, but I just want to make it clear that the O-3xx mechanism itself does not make any assumptions regarding use-cases. It only allows the usage of OPTIONS in forking scenarios - nothing more, nothing less. Apart from providing a way to deal with the forking issue, it does not solve any other issues, bugs or shortcomings there may be with OPTIONS.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 06:16:02 -0400

> Sent: Thursday, April 08, 2010 5:47 AM
> 
> Hadriel said:
> The resources will be released when the first INVITE is rejected, and a
> new resource reservation procedure will start when the next INVITE comes.

Yup, but I don't see what that has to do with what we're talking about? (the statement confuses me in this context)

And again it's GOOD that the resources are reserved again.  It may not be good from a performance perspective, but it guarantees accuracy.  Resources change constantly.  There are any number of resource availability changes in the network between the OPTIONS and the INVITE, or between two INVITES.  Obviously you could do a resource reservation model that is separate from INVITEs (or SIP altogether), but I don't see how that's relevant to this discussion. (I must be missing something?)

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 12:29:58 +0200

Hi, 

>But you know that would never work in practice/the-real-world. Think about all the routing rules 
>people have for INVITEs - in some cases *only* for INVITEs.  
>And even if they route OPTIONS identically in the SIP domain, 
>for any given AoR it'll go to any of: a SIP UA, or a PSTN 
>gateway, or a H.323-gateway, or an MGCP call-agent, or an 
>IP-PBX, or a foobar-protocol-gateway, or a vmail server, or 
>an announcement server, or an app server, etc.  Just because 
>the OPTIONS reaches the end of the SIP domain, means nothing 
>about whether an INVITE to the higher-layer target (which in 
>practice is a E.164 number, that crosses from SIP into many 
>other protocol domains) is actually available to receive a call.

The assumption is that the OPTIONS request reaches the registrar, that returns the registered contacts. It is never forwarded to any UAS.

Then, at some point an INVITE is sent, and it is addressed to the same AOR (the INVITE request might be routed differently than the OPTIONS request). Based on the UAS information, the INVITE may now contain feature tags etc that indicates a wish to reach an UAS with certain capabilities.

Now, unless the INVITE is addressed to a specific UAS, it can of course not be guranteed that the INVITE will actually reach such UAS. But, that is a "feature" of RFC 3841, and it would be the case even if you had never sent any OPTIONS. What OPTIONS allows provides you is capability information about the UAS(s) associated with the AOR, which might be useful when sending the INVITE.

No, it does not guarantee that the user is available - it only provides you with that same information as OPTIONS in a non-forking case does.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 12:31:47 +0200

Hi, 
	
>If someone wants to submit an author draft on a specific issue and fix, then fine, I'll reconsider.

My intention has been to submit a draft that describes the OPTIONS 3xx mechanism.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 12:35:45 +0200

Hi, 

>The more I read through this thread, the more it looks like we're running around with a hammer, desperately looking for nails to hit. Barring nails, we'll settle for screws. Or bolts. Or maybe 
>kittens, if it comes to that.
>	
>If you're trying to accomplish something, I would strongly recommend starting from the other end. Instead of saying "I have a tool, let's make a problem for it to solve," let's concentrate on 
>clearly defining existing problems. Once we agree on the problems, we can talk about what tools make sense to solve them.

That problem is that OPTIONS doesn't work in forking cases, which makes is quite useless in those cases.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 06:44:40 -0400

Hi Christer,
I know you're frustrated we keep going back to a use-case, but you're asking for consensus on whether people are interested in working on the solution.  Without an actual use-case, how can we do that?  Why would people agree to spend time on something they don't see any use for solving?

-hadriel

> Sent: Thursday, April 08, 2010 6:13 AM
> I don't think I have said that the INVITE would necessarily be targeted to
> a particular UA. There MAY of course be use-cases where you would target
> also the INVITE to a specific UAS. For example, if an UAS supports a
> specific capability, and you don't want the call to proceed unless that
> UAS accepts the INVITE. Then, if the INVITE fails, it may still be
> possible for the call to be forwarded to a voice mail etc, depending on
> policies and service design in the network.
> 
> But, the main point of the O-3xx mechanisms is that it allows you to
> target *OPTIONS* request to particular UAs, in order to get the
> capabilities of those.
> 
> That is the only thing the mechanism is supposed to provide. What you then
> do with that information is a separate issue, and that seems to be what
> the discussion is now about.
> 
> Now, we can discuss use-cases etc, but I just want to make it clear that
> the O-3xx mechanism itself does not make any assumptions regarding use-
> cases. It only allows the usage of OPTIONS in forking scenarios - nothing
> more, nothing less. Apart from providing a way to deal with the forking
> issue, it does not solve any other issues, bugs or shortcomings there may
> be with OPTIONS.
> 
> Regards,
> 
> Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Apr 2010 12:49:51 +0200

Christer,

Thanks for that clarification - I wasn't certain about my interpretation.

So we have the ability to target OPTIONS requests at individual UAs that are contacts for a given AOR. From that I discover that UA N supports feature X. I want to submit an INVITE request that uses feature X. If you say we don't target the INVITE request at UA N, then presumably I would target it at the AOR, which may or may not result in the request being forwarded to UA N. I could use caller-prefs to indicate a preference for a UA that supports feature X, and this will doubtless increase the chances that the INVITE request will be forwarded to UA N.

What exactly have I gained by compared with skipping OPTIONS and just sending an INVITE request to the AOR with a caller-pref for feature X? For example, are you suggesting it would be harmful to send the INVITE request in a case where no UA supports feature X?

Note that in the typical SIP trapezoid, with 3 registered contacts, use of OPTIONS would result in a significant amount of additional signalling traffic. Assuming the second proxy sends back 3xx with 3 contacts, resulting in 3 further OPTIONS requests:
- 1st OPTIONS request over two hops, with response: 4 message-hops
- 2nd, 3rd and 4th OPTIONS requests, each over three hops, with responses: 18 message-hops
In other words, 22 additional SIP message hops (assuming the eventual INVITE request results in the same amount of signalling whether or not OPTIONS is used). So optimisation can hardly be claimed as a benefit.

John 

> Sent: 08 April 2010 11:13
> I don't think I have said that the INVITE would necessarily 
> be targeted to a particular UA. There MAY of course be 
> use-cases where you would target also the INVITE to a 
> specific UAS. For example, if an UAS supports a specific 
> capability, and you don't want the call to proceed unless 
> that UAS accepts the INVITE. Then, if the INVITE fails, it 
> may still be possible for the call to be forwarded to a voice 
> mail etc, depending on policies and service design in the network.
> 
> But, the main point of the O-3xx mechanisms is that it allows 
> you to target *OPTIONS* request to particular UAs, in order 
> to get the capabilities of those.
> 
> That is the only thing the mechanism is supposed to provide. 
> What you then do with that information is a separate issue, 
> and that seems to be what the discussion is now about.
> 
> Now, we can discuss use-cases etc, but I just want to make it 
> clear that the O-3xx mechanism itself does not make any 
> assumptions regarding use-cases. It only allows the usage of 
> OPTIONS in forking scenarios - nothing more, nothing less. 
> Apart from providing a way to deal with the forking issue, it 
> does not solve any other issues, bugs or shortcomings there 
> may be with OPTIONS.
> 
> Regards,
> 
> Christer
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 14:22:52 +0200

Hi John,

But if you only want to probe the devices behind the AOR for some reason
(knowing the limitations of the obtained information), then you do not want
to use INVITE do you?

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 12:49 PM, Elwell, John <
[email-masked]> wrote:

> So we have the ability to target OPTIONS requests at individual UAs that
> are contacts for a given AOR. From that I discover that UA N supports
> feature X. I want to submit an INVITE request that uses feature X. If you
> say we don't target the INVITE request at UA N, then presumably I would
> target it at the AOR, which may or may not result in the request being
> forwarded to UA N. I could use caller-prefs to indicate a preference for a
> UA that supports feature X, and this will doubtless increase the chances
> that the INVITE request will be forwarded to UA N.
>
> What exactly have I gained by compared with skipping OPTIONS and just
> sending an INVITE request to the AOR with a caller-pref for feature X? For
> example, are you suggesting it would be harmful to send the INVITE request
> in a case where no UA supports feature X?
>
> Note that in the typical SIP trapezoid, with 3 registered contacts, use of
> OPTIONS would result in a significant amount of additional signalling
> traffic. Assuming the second proxy sends back 3xx with 3 contacts, resulting
> in 3 further OPTIONS requests:
> In other words, 22 additional SIP message hops (assuming the eventual
> INVITE request results in the same amount of signalling whether or not
> OPTIONS is used). So optimisation can hardly be claimed as a benefit.
>
> John
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Apr 2010 15:39:52 +0200

I thought we were talking about doing OPTIONS as a prelude to doing INVITE (or SUBSCRIBE or MESSAGE or whatever), in which case you could just send the request concerned and see what happens - no need to bother with OPTIONS. But you now seem to be suggesting the use of OPTIONS standalone.

In either case, nobody seems to have given a convincing use case where probing all the devices behind an AOR is of significant benefit, and if there is a significant benefit, why you can't just obtain the device contact URIs using the reg event package and then send OPTIONS to each.

John

> Sent: 08 April 2010 13:23
> To: Elwell, John
> Cc: Christer Holmberg; WORLEY, DALE R (DALE); [email-masked]
> But if you only want to probe the devices behind the AOR for 
> some reason (knowing the limitations of the obtained 
> information), then you do not want to use INVITE do you?
> 
> /Hans Erik van Elburg
> 
> 
> 
> On Thu, Apr 8, 2010 at 12:49 PM, Elwell, John 
> 	So we have the ability to target OPTIONS requests at 
> individual UAs that are contacts for a given AOR. From that I 
> discover that UA N supports feature X. I want to submit an 
> INVITE request that uses feature X. If you say we don't 
> target the INVITE request at UA N, then presumably I would 
> target it at the AOR, which may or may not result in the 
> request being forwarded to UA N. I could use caller-prefs to 
> indicate a preference for a UA that supports feature X, and 
> this will doubtless increase the chances that the INVITE 
> request will be forwarded to UA N.
> 	
> 	What exactly have I gained by compared with skipping 
> OPTIONS and just sending an INVITE request to the AOR with a 
> caller-pref for feature X? For example, are you suggesting it 
> would be harmful to send the INVITE request in a case where 
> no UA supports feature X?
> 	
> 	Note that in the typical SIP trapezoid, with 3 
> registered contacts, use of OPTIONS would result in a 
> significant amount of additional signalling traffic. Assuming 
> the second proxy sends back 3xx with 3 contacts, resulting in 
> 3 further OPTIONS requests:
> 	In other words, 22 additional SIP message hops 
> (assuming the eventual INVITE request results in the same 
> amount of signalling whether or not OPTIONS is used). So 
> optimisation can hardly be claimed as a benefit.
> 	
> 	John
> 	
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 10:01:04 -0400

[as individual]

It seems that Christer has come close to offering a use case, even if 
that was not his intent. And its still a little incomplete. I'll try to 
fill it out a bit:

Alice wants to call Bob.
Her phone app first queries Bob's AOR with OPTIONS.
The response to that is a 3xx with Contact URIs for
Bob's home phone and his mobile phone. So Alice's phone
sends additional OPTIONS requests to each of those.
 From the responses it learns that Bob's mobile phone support
audio and video, while his home phone (behind a pstn gateway)
only supports audio.

Alice has video support on her phone, and since Bob may be able to 
support video too, decides to make an audio+video call. The
phone sends an INVITE with both, and caller preferences indicating
a preference for audio+video.

The INVITE reaches the server handling Bob's AOR.
It processes the callerprefs, and so decides to initially send the 
invite to Bob's mobile phone. But there is no answer there, so
the server forks the invite toward Bob's home phone. Bob answers that 
one, accepting the audio and rejecting the video.

The result of this is exactly the same as if no OPTIONS was ever sent, 
and the INVITE was sent indicating Alice's own preferences. That is the 
point that John already made.

The only "benefit" I can see from use of options here would be if it was 
discovered that Bob had no video support. In that case, the invite could 
have been sent without offering video. Is that advantageous? Does it 
cost more to initiate a call that offers video? Does it take more 
network resources to do so, even when ultimately the video is rejected?

The only real benefit I can see to this is if the calling user is given 
an enhanced user interface - akin to what one gets with buddy lists - 
where there is a display showing that Bob has two devices with differing 
capabilities, with Alice having the option to choose one or allowing the 
phone to make the choice.

To provide that feature, presence would be a much better choice.
OPTIONS is in a sense "poor man's presence". Christer has mentioned that 
he considers presence to be too "heavy weight" for this, but I remain to 
be convinced of that. Perhaps maintaining persistent subscriptions to 
presence status of everyone you might possibly call is too heavy weight, 
but doing a polling subscription prior to a call won't be any heavier 
than all this options stuff.

It may be that lots of devices don't publish presence state. But that 
can be solved in many ways. A registrar can synthesize basic presence 
state from registration data. And it could even use OPTIONS to refine that.

I suspect the real hidden issue here is about presence, and so I'd 
prefer to see it addressed from that direction. If that in turn leads to 
a desire to use OPTIONS to get some degree of presence state from 
devices that don't otherwise publish it, then lets confront it in that 
context. And if the issue is that presence is typically not authorized 
for as many requesters as OPTIONS is, then lets look at possible policy 
recommendations in that regard.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 08 Apr 2010 17:08:52 +0200

Hi Paul,

the use case you have written down is exactly the one I have in mind and 
was going to send to this ml.

I want add one more benefit in knowing all the capabilities of the 
different Bob devices in advance and
not just of one device.
An OPTIONS response (or another mechanism!) that contains a level of 
granularity that let Alice (or rather Alices device)
know that Bob can take only audio on one device, but 
audio/video/text/picture on his other device (as describe in Paul use case),
would help Alice's device understand that starting a voice session with 
only voice Bob device, there is no way a re-INVITE to add video would work;
so if she thinks that a voice call could be then transformed in a 
voice+video, she knows that should contact directly the 
audio/video/text/picture device.

cheers
Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Apr 2010 09:13:04 -0600

FWIW, this is exactly what we do in XMPP.

On 4/8/10 9:08 AM, Salvatore Loreto wrote:
>>>> about all the routing rules
>>> The assumption is that the OPTIONS request reaches the registrar,
>>> that returns the registered contacts. It is never forwarded to any UAS.
>>>
>>> Then, at some point an INVITE is sent, and it is addressed to the
>>> same AOR (the INVITE request might be routed differently than the
>>> OPTIONS request). Based on the UAS information, the INVITE may now
>>> contain feature tags etc that indicates a wish to reach an UAS with
>>> certain capabilities.
>>>
>>> Now, unless the INVITE is addressed to a specific UAS, it can of
>>> course not be guranteed that the INVITE will actually reach such UAS.
>>> But, that is a "feature" of RFC 3841, and it would be the case even
>>> if you had never sent any OPTIONS. What OPTIONS allows provides you
>>> is capability information about the UAS(s) associated with the AOR,
>>> which might be useful when sending the INVITE.
>>>
>>> No, it does not guarantee that the user is available - it only
>>> provides you with that same information as OPTIONS in a non-forking
>>> case does.
>>>
>>> Regards,
>>>
>>> Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 11:36:14 -0400

[as individual]

> audio/video/text/picture device.

If this kind of feature is desired, then lets spell that out and discuss 
alternative ways of achieving that result.

The original sip philosophy was that choice of device to respond to a 
request is a policy decision to be made by the server responsible for 
the AOR. It might take the wishes of the caller into account but that is 
still based on callee policy.

Presence turns that on its head. In the presence model, the "caller" is 
given a menu by the callee, and allowed to choose. Since that is what 
you seem to wish, I think presence is where to start in looking for a 
solution.

As an aside, if I have a video device that can be added into the current 
(audio) call, then *I* want to be the one that makes that decision. I 
find the idea of having the caller do it a bit creepy.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 13:31:17 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 10:01 AM
> 

Well... when you put it that way, there is actually a small advantage.  In many resource reservation deployments the INVITE would be rejected if there isn't sufficient bandwidth for the highest-bitrate codec or the aggregate of all offered medias.  Afaict this is due to either bad design, or the protocols being used to policy servers which can't really handle an if-else-else type reservation model.

So in theory the INVITE would succeed had Alice only asked for audio.

But there are so many other policy decisions involved that it's a crap-shoot anyway, no matter how much info you give the UAC.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Apr 2010 13:27:11 -0500

[as individual]

On 4/8/10 9:01 AM, Paul Kyzivat wrote:
> that was not his intent. And its still a little incomplete. I'll try 
> to fill it out a bit:
>
> ...
>

*ding* *ding* *ding*

We have an answer!

That's why I'm asking for use cases. Every use case *I* can come up with 
is better suited for something like presence, callerprefs, etc. Now, 
Christer clearly has some problem he's trying to solve. If he'd just 
describe the problem in terms of a use case (instead of "forking breaks 
OPTIONS"), then I think we could make some progress.

I'm not saying that the answer won't be OPTIONS, simply that a concise 
statement of the use case(s) that need to be supported is likely to make 
it clearer to everyone what kind of solution is actually called for.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 21:32:22 +0200

Hi Hadriel,

I don't think documenting the O-3xx mechanism would require much work. And, as some have indicated, it might even be done as an individual draft.

Then, if we don't think OPTIONS is good enough in the first place, and want to define some other procedure, which actually requires some work, the situation is different. But, I have not suggested that.

Regards,

Christer

________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Thursday, April 08, 2010 1:44 PM
To: Christer Holmberg; Elwell, John; Hans Erik van Elburg
Cc: WORLEY, DALE R (DALE); [email-masked]
Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this?

Hi Christer,

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Apr 2010 17:41:58 -0500

On Apr 8, 2010, at 8:39 AM, Elwell, John wrote:
>
> In either case, nobody seems to have given a convincing use case  
> where probing all the devices behind an AOR is of significant benefit,

That's indeed the question.

What would you do differently if you knew about the capabilities of  
all the potential responding UAs before sending an INVITE?

Our traditional logic has been "put everything YOU support in the  
offer, and let the combination of RFC 3840/3841 working in the proxy  
pick a UA that best-matches what you have. Of course, this can  
sometimes lead to requests getting sent to the phone that is the  
closest feature match rather than the one that's closest to the called  
party.

Another alternative is to make an INVITE that offers only the bare  
minimum, then explore upgrading the call once it is established to  
engage additional features.

But perhaps we have a problem. I want to offer a "rich" INVITE, but  
the low-end client with no features keeps answering before the  
"better" box. Now, we need to know the "best" set of capabilities, so  
that we can construct an INVITE that only the "right" UA is going to  
answer.

> and if there is a significant benefit, why you can't just obtain the  
> device contact URIs using the reg event package and then send  
> OPTIONS to each.

That one's easy. I'm not letting you subscribe to my reg-event  
information. I don't even HAVE reg-event information, as my registrar  
doesn't do it.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Apr 2010 17:00:40 -0700

On Apr 7, 2010, at 7:49 , Adam Roach wrote:

> The more I read through this thread, the more it looks like we're running around with a hammer, desperately looking for nails to hit. Barring nails, we'll settle for screws. Or bolts. Or maybe kittens, if it comes to that.

+1 - I have a potato peeler and I'm not afraid to use it. But I'm not seeing a problem here that OPTIONS looks like it solves. 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Apr 2010 17:00:29 -0700

On Apr 8, 2010, at 15:41 , Dean Willis wrote:

> 
> What would you do differently if you knew about the capabilities of all the potential responding UAs before sending an INVITE?

Well, one things I might do if I knew the capability of the far end before the INVITE is not do Offer/answer and instead just tell the far end what to do. More like how SDP is used in RTSP. All this offer answer stuff is hard to get right. Some times I wonder if the use case is actually it's hard to get offer / answer right so really what people want to send is an "offer you can't refuse" in the INVITE and are trying to discover capability's to make that possible. All a very interesting discussion but none of this has inspired me to start work on anything to do with OPTIONS.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 20:06:59 -0400

Dean Willis wrote:
> 
> But perhaps we have a problem. I want to offer a "rich" INVITE, but the 
> low-end client with no features keeps answering before the "better" box. 
> Now, we need to know the "best" set of capabilities, so that we can 
> construct an INVITE that only the "right" UA is going to answer.

I would recommend that you then set up callerprefs to *prefer* (but not 
require) the "rich" capabilities. With luck the call will be offered to 
the rich device first, and if that one doesn't answer then the dumber 
ones will still be tried.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 20:11:24 -0400

> +1 - I have a potato peeler and I'm not afraid to use it. But I'm not seeing a problem here that OPTIONS looks like it solves. 

Maybe we could find a kitten for you to peel with it. :-)

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Apr 2010 00:27:33 -0500

On Apr 8, 2010, at 7:06 PM, Paul Kyzivat wrote:

>> "better" box. Now, we need to know the "best" set of capabilities,  
>> so that we can construct an INVITE that only the "right" UA is  
>> going to answer.
>
> I would recommend that you then set up callerprefs to *prefer* (but  
> not require) the "rich" capabilities. With luck the call will be  
> offered to the rich device first, and if that one doesn't answer  
> then the dumber ones will still be tried.
>

Do you feel lucky?

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 08:24:15 +0200

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 08 April 2010 23:42
> To: Elwell, John
> Cc: Hans Erik van Elburg; WORLEY, DALE R (DALE); [email-masked]
> information. 
[JRE] If my policy is not to let you subscribe to reg-event, I would anticipate having a similar policy not to reveal my registered contacts through 3xx to OPTIONS.

> I don't even HAVE reg-event information, as my 
> registrar  
> doesn't do it.
[JRE] Equally, I don't support 3xx to OPTIONS because my proxy doesn't do it. I agree that 3xx to OPTIONS might be easier to implement than reg-event, but you still need all the authentication/authorisation stuff.

John

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 09 Apr 2010 10:42:51 +0200

IMO it would be useful having in SIP a similar mechanism to the one used 
in XMPP
as an alternative way to do OPTIONS

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Apr 2010 09:16:30 -0400

Dean Willis wrote:
>> offered to the rich device first, and if that one doesn't answer then 
>> the dumber ones will still be tried.
>>
> 
> Do you feel lucky?

Never. I'm definitely a "glass half empty" person.

OTOH, if it doesn't work, its the callee's fault, not mine. If he wants 
his "rich" devices to be useful he ought to get a smarter proxy.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Apr 2010 10:47:28 -0500

On Apr 9, 2010, at 1:24 AM, Elwell, John wrote:
> [JRE] If my policy is not to let you subscribe to reg-event, I would  
> anticipate having a similar policy not to reveal my registered  
> contacts through 3xx to OPTIONS.
>
> [JRE] Equally, I don't support 3xx to OPTIONS because my proxy  
> doesn't do it. I agree that 3xx to OPTIONS might be easier to  
> implement than reg-event, but you still need all the authentication/ 
> authorisation stuff.
>

Both good arguments. I'm inclined more than ever to suggest that  
proxies should just never fork OPTIONS.

Besides using it as a very inefficient PING, what do we really use  
OPTIONS for in the real world? Even when used as a "ping", what does  
it mean to fork it? Does contact-routing of OPTIONS (including  
forking) create a security hole?

If we suggest proxies don't fork OPTIONs, how should they respond to  
an OPTIONS request for an AOR for which they are responsible? With  
their own capabilities? Perhaps with a 302 listing the public GRUUs,  
if any?

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 18:40:33 +0200

> Sent: 09 April 2010 16:47
> To: Elwell, John
[JRE] I think this misses my point. If the proxy returns a 302 with all my contacts (GRUUs), I have revealed to the caller how many devices I have and their individual addresses, i.e., basically the same information as reg-event would give the caller. So similar authorisation policies should apply.

John

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Apr 2010 14:18:28 -0500

On Apr 9, 2010, at 11:40 AM, Elwell, John wrote:

> [JRE] I think this misses my point. If the proxy returns a 302 with  
> all my contacts (GRUUs), I have revealed to the caller how many  
> devices I have and their individual addresses, i.e., basically the  
> same information as reg-event would give the caller. So similar  
> authorisation policies should apply.

Well, the public GRUUs do list the different devices, but not their IP  
Addresses, per se. One could also use temp-gruu for the same function.

I like the idea of returning some sort of "OPTIONS aggregate", but  
this leads to questions of disjoint feature sets across devices. For  
example what happens if one picks two "must" features out of the  
aggregate and constructs a request around them, when in reality there  
are two different devices, each of which has only one of the features?

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Apr 2010 09:44:54 +0200

> Sent: 09 April 2010 20:18
> To: Elwell, John
[JRE] In fact RFC 5628 considers temp-gruu to be a bigger security risk, and states in section 5:
"This element SHOULD NOT be
   included if the subscriber is not authorized to register to the AOR,
   unless there is an explicitly configured policy directing that it be
   included."
So if 3xx to OPTIONS reveals temp-gruus, this should be subject to the same authorisation policy as reg-event.

John

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Apr 2010 15:22:57 +0200

Hi,

As has been said, there can always be policies regarding what is returned - no matter what mechanism is used.

So, in the case of OPTIONS, if there is a policy to not return the contacts, the proxy might return some kind of "OPTIONS aggregate". 

We don't need to define those policies, we just say how things are done if applied.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 9. huhtikuuta 2010 22:18
> To: Elwell, John
> Well, the public GRUUs do list the different devices, but not 
> their IP Addresses, per se. One could also use temp-gruu for 
> the same function.
> 
> I like the idea of returning some sort of "OPTIONS 
> aggregate", but this leads to questions of disjoint feature 
> sets across devices. For example what happens if one picks 
> two "must" features out of the aggregate and constructs a 
> request around them, when in reality there are two different 
> devices, each of which has only one of the features?
> 
> --
> Dean
> 
>