Subject: [dispatch] SIP OPTIONS rework proposal

From: Salvatore Loreto <[email-masked]>
Date: Thu, 21 Jan 2010 16:31:36 +0200

Hi there,

there as been a short discussion in SIP Core ml
about the fact that the OPTIONS method to discovery capabilities is 
pretty broken.

As discovery capabilities is a meaningful mechanism to provide enhanced 
services,
it would be important, at least in my opinion, to do some serious rework 
on it!

Below an initial description of the problem as derived from the exchange 
of mails with Paul.

Comments are very welcome!

Regards
Sal

----------

OPTIONS as discovery capabilities mechanism
=============================

The SIP method OPTIONS allows you to query the capabilities of another 
UA or a proxy server.
The method provides a way to discover information about the supported 
methods,
content types, extensions, codecs, etc. without "ringing" the other party.

The target of the OPTIONS request is identified by the Request-URI, 
which could identify another UA
or a SIP server. However SIP OPTIONS also inherits the "traceroute" 
behaviour from HTTP/1.1, where
a server receiving an OPTIONS request with a Max-Forwards header field 
value of 0 MAY respond
to the request regardless of the Request-URI.
So the original intent and design of OPTIONS seems to be that whoever 
responds to an OPTIONS method
does it for itself.

However in the case the request is addressed to an AoR, and there is a 
proxy responsible for that AoR
(that will typically route requests via contact routing), it is not 
clear the right behaviour of the proxy.

    e.g. Alice sends a SIP OPTIONS request to discover the Bob
    capabilities; if Bob has registered two or more
            UAs, then the proxy responsible for the Bob AoR forks the
    OPTIONS request letting it arrive to all the
            registered UAs. A possible behavior for the proxy
    responsible for the Bob AoR may be to send back
            to Alice only the first response it receives. However this
    is just a possible behaviour, others are also
            possible or at least not prohibited!

A nice thing to be able to learn, through a discovery capabilities 
mechanism, would be the full set of capabilities
associated to the different UAs an user has registered and not just the 
capabilities of the UA that answers more quickly.
The question is whether OPTIONS is the way to achieve it, or it would 
make more sense to leave OPTIONS alone
and create something new.

Moreover the assumption that the capabilities of a UA are stable over 
time and are context free is also pretty broken.
UA capabilities can change for a lot of different reasons: a user switch 
off/on one of his registered UAs; or context changed
than when the query has been received.

    For instance, if Bob's device is handling a call when it receives
    the query, does the response reflect what
    it can do concurrently with the call, or what it will be able to do
    once the call had ended?

So the description of the context and of the reasons that can let 
capabilities to chance over time could provide useful
pieces of information.

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 21 Jan 2010 09:49:01 -0500

Hi Sal,

I think the notion of finding different UA capabilities for an AOR is
interesting.

It seems like rich grounds for discussion since:
- I may want to direct messages to specific UAs based on capability (So can
I rely on e.g. sip-instance tags or gruu stuff in the responses? I forget if
OPTIONS does this)
- Can I learn things a user may not want me to know (i.e. is detecting the
registration of a specific UA a security issue? Although I suspect this is
an existing issue with OPTIONS?)
- do I have to do "lowest common denominator" or will a "real-world" proxy
know that e.g. it can forward 100rel stuff to one endpoint but not others
etc.

Peter

On Thu, Jan 21, 2010 at 9:31 AM, Salvatore Loreto <
[email-masked]> wrote:

> about the fact that the OPTIONS method to discovery capabilities is pretty
> broken.
>
> it would be important, at least in my opinion, to do some serious rework on
> it!
>
> Below an initial description of the problem as derived from the exchange of
> mails with Paul.
>
> The SIP method OPTIONS allows you to query the capabilities of another UA
> or a proxy server.
> The target of the OPTIONS request is identified by the Request-URI, which
> could identify another UA
> (that will typically route requests via contact routing), it is not clear
> the right behaviour of the proxy.
>
>  e.g. Alice sends a SIP OPTIONS request to discover the Bob capabilities;
> if Bob has registered two or more
>        UAs, then the proxy responsible for the Bob AoR forks the OPTIONS
> request letting it arrive to all the
>        registered UAs. A possible behavior for the proxy responsible for
> the Bob AoR may be to send back
>        to Alice only the first response it receives. However this is just a
> possible behaviour, others are also
> The question is whether OPTIONS is the way to achieve it, or it would make
> more sense to leave OPTIONS alone
> Moreover the assumption that the capabilities of a UA are stable over time
> and are context free is also pretty broken.
> For instance, if Bob's device is handling a call when it receives the
> query, does the response reflect what
> it can do concurrently with the call, or what it will be able to do once
> the call had ended?
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2010 11:54:32 -0500

Presence is an existing mechanism that can potentially provide much of 
this functionality.

	Thanks,
	Paul

Salvatore Loreto wrote:
>            registered UAs. A possible behavior for the proxy responsible
>     for the Bob AoR may be to send back
>            to Alice only the first response it receives. However this is
>     just a possible behaviour, others are also

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 21 Jan 2010 20:32:59 +0200

while I agree that much of the functionalities to discovery the 
capabilities can be potentially provided by Presence,
Presence service is not always present in a Network;
and moreover people tend to use OPTIONS for this kind of work,
perhaps because it gives a flavour of real time information,
but for sure because the definition of OPTIONS is too vague in several 
aspect of what is allowed to do with it
and how OPTIONS is intended to work.

/Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2010 13:53:31 -0500

> and how OPTIONS is intended to work.

I agree that presence often isn't present, or if present isn't 
accessible to as many callers as OPTIONS might be.

OTOH, if we are talking about *extending* what it is that OPTIONS does, 
in ways that overlap further with presence, then we it may make more 
sense to rely on presence and just expand its availability.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 21 Jan 2010 21:08:34 +0200

> sense to rely on presence and just expand its availability.
I am talking only about better define/specify the general philosophy of how
OPTIONS is intended to work.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2010 20:24:10 +0100

Hi,

>The target of the OPTIONS request is identified by the Request-URI, which could identify another UA
>or a SIP server. However SIP OPTIONS also inherits the "traceroute" behaviour from HTTP/1.1, where
>a server receiving an OPTIONS request with a Max-Forwards header field value of 0 MAY respond
>So the original intent and design of OPTIONS seems to be that whoever responds to an OPTIONS method
>does it for itself.

I am not sure I understand... If the M-F header field reaches 0 it should be rejected by a 483 response. That is generic SIP behavior.

Or, is it somewhere said that it doesn't apply to OPTIONS?

--------

>However in the case the request is addressed to an AoR, and there is a proxy responsible for that AoR
>(that will typically route requests via contact routing), it is not clear the right behaviour of the proxy.
>

e.g. Alice sends a SIP OPTIONS request to discover the Bob capabilities; if Bob has registered two or more
       UAs, then the proxy responsible for the Bob AoR forks the OPTIONS request letting it arrive to all the
       registered UAs. A possible behavior for the proxy responsible for the Bob AoR may be to send back
       to Alice only the first response it receives. However this is just a possible behaviour, others are also
       possible or at least not prohibited!

Do you have something particular other possibility in mind?

--------

>A nice thing to be able to learn, through a discovery capabilities mechanism, would be the full set of capabilities
>associated to the different UAs an user has registered and not just the capabilities of the UA that answers more quickly.
>The question is whether OPTIONS is the way to achieve it, or it would make more sense to leave OPTIONS alone

I guess you are talking about a case where I would send a single OPTIONS request to the registrar which serves you, and it would return the capabilities that your UA(s) have registered?

That could be a useful feature, but in order to return SDP information for the UAs they would have to provide SDP when they register.

--------

>Moreover the assumption that the capabilities of a UA are stable over time and are context free is also pretty broken.
>UA capabilities can change for a lot of different reasons: a user switch off/on one of his registered UAs; or context changed
For instance, if Bob's device is handling a call when it receives the query, does the response reflect what
it can do concurrently with the call, or what it will be able to do once the call had ended?

>So the description of the context and of the reasons that can let capabilities to chance over time could provide useful
>pieces of information.

I don't think OPTIONS was ever used to retrieve information which is expected to be valid for a long time.

--------

When I read the issues above I think they are more or less related to how OPTIONS are treated by the network. I haven't seen anything regarding the definition of OPTIONS as such.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2010 14:40:08 -0500

> I am not sure I understand... If the M-F header field reaches 0 it should be rejected by a 483 response. That is generic SIP behavior.

3261, section 11:

    Alternatively, a server receiving an OPTIONS request with a Max-
    Forwards header field value of 0 MAY respond to the request
    regardless of the Request-URI.

       This behavior is common with HTTP/1.1.  This behavior can be used
       as a "traceroute" functionality to check the capabilities of
       individual hop servers by sending a series of OPTIONS requests
       with incremented Max-Forwards values.

> That could be a useful feature, but in order to return SDP information for the UAs they would have to provide SDP when they register.

In theory, the "proxy"/registrar server could act as a UA for OPTIONS.
Before responding it could send distinct OPTIONS requests to all 
registered contacts. Then it could assemble the responses of them all 
into a single response to the original request. IOW, it could act as an 
OPTIONS exploder.

The significant word above is *could*. (Perhaps when hell freezes over.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2010 20:53:27 +0100

Hi,

>       with incremented Max-Forwards values.

True. I guess the ideal would be to be able to indicate whether the UA wants a 200 or 483 in this case.

And, if you get 200 for every request, can you be sure that you have actually reached the node you wanted to reach?

--------

>into a single response to the original request. IOW, it could act as an

Yes, either that, or simply send a reply based on the feature tags that the UAs have registered.

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 21 Jan 2010 22:08:01 +0200

> The significant word above is *could*. (Perhaps when hell freezes over.)

so what is the right behaviour in this undefined scenario: when the 
request is addressed to an AoR?
that is something we should try to clarify and explicetly allow or forbid

reading the spec is not clear, in theory the "proxy"/registrar can
- forward back the first response (to the forked OPTIONS request) it 
receives: acting as all the other forked request
or
- as the request is targeted to an AoR, and the "proxy"/registrar is in 
some sense responsible for the AoR, it could
   decide: to answer with the information it has stored at the 
registration time or decide to act as an OPTION exploder

/Sal

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Jan 2010 15:08:11 -0500

I was thinking about this when the topic came up a few days ago. A consolidated 
response that is a union of the individual responses may not be sufficient, if 
what the OPTIONS sender is looking for is a single UA with a specified set of 
capabilities. On the other hand, a consolidated response that lists capabilities 
by UA may have security implications.

As you said: when hell freezes over.

Paul Kyzivat wrote:
...

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2010 18:45:05 -0500

Salvatore Loreto wrote:

>>> I guess you are talking about a case where I would send a single 
>>> OPTIONS request to the registrar which serves you, and it would 
>>> return the capabilities that your UA(s) have registered?
>>>
>>> That could be a useful feature, but in order to return SDP 
>>> information for the UAs they would have to provide SDP when they 
>>> register.
>>>      

I think what is right depends on the eye of the beholder.
A lot of people seem to want to use OPTIONS as a ping.
They might be happy to have the proxy return for itself.

Others want and e2e test and perhaps a busy check. They want it to be 
routed as an INVITE would be.

Others ...

I think I would opt for expecting proxies to route it like regular out 
of dialog request (assuming it *is* out of dialog), just because that is 
likely to be the closest to "typical" behavior in the wild today. But if 
the proxy routes to servers based on the method, and there are only 
servers that get routed specially on method then I guess it should 
either route to (one of?) them, or answer on its own.

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Jan 2010 11:37:30 +0100

Hi,

I still fail to see any issue which led to the removal of the OPTIONS text in the info events draft. The text was about how UAs set the header field in the OPTIONS request/response (in case of 200 OK).

No, I am not suggesting to put the text back, I just have a hard time to understand what the problem was :)

Regards,

Christer

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 22. tammikuuta 2010 1:45
> To: Salvatore Loreto
> Cc: Christer Holmberg; [email-masked]
> Subject: Re: [dispatch] SIP OPTIONS rework proposal
> 
> 
> 
> Salvatore Loreto wrote:
> 
> >> into a single response to the original request. IOW, it 
> could act as 
> >> an OPTIONS exploder.
> >>
> > receives: acting as all the other forked request or
> > - as the request is targeted to an AoR, and the 
> "proxy"/registrar is 
> > in some sense responsible for the AoR, it could
> Others want and e2e test and perhaps a busy check. They want 
> it to be routed as an INVITE would be.
> 
> Others ...
> 
> I think I would opt for expecting proxies to route it like 
> regular out of dialog request (assuming it *is* out of 
> dialog), just because that is likely to be the closest to 
> "typical" behavior in the wild today. But if the proxy routes 
> to servers based on the method, and there are only servers 
> that get routed specially on method then I guess it should

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Jan 2010 09:16:22 -0500

> No, I am not suggesting to put the text back, I just have a hard time to understand what the problem was :)

I was neutral on whether it be there or not.