Subject: [dispatch] [Fwd: SIP OPTIONS rework proposal]

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 14 Feb 2010 09:27:26 +0200

Hi,

speaking as SIPCORE chair this time, the SIPCORE WG has received an
agenda request to discuss this topic in Anaheim. Given that OPTIONS
requests are specified in RFC 3261, it sounds reasonable for SIPCORE to
have an initial look at what to do with this. So, if you have comments
about this topic, you may want to discuss them on the SIPCORE list.

Thanks,

Gonzalo

-------- Original Message --------
Subject: 	[dispatch] SIP OPTIONS rework proposal
Date: 	Thu, 21 Jan 2010 15:31:36 +0100
From: 	Salvatore Loreto <[email-masked]>
To: 	[email-masked] <[email-masked]>

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.

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