Subject: RE: [SIP] SDP in OPTIONS

From: "Peter Hedman (LD/EAB)" <[email-masked]>
Date: Thu, 3 Mar 2005 09:21:10 +0100

Thanks for your comments.

3GPP is discussing use cases where the capabilities of the remote UAs should be known prior to sending the INVITE, i.e. to be able to present a set of possibilities to the user. E.g. if there is an existing non-SIP communication between two users (e.g. CS call), SIP could be used to learn the capabilities of the remote UA.

Different mechanisms have been discussed e.g. use of Presence or using INVITE with inactive media. The initial use of OPTIONS was favourable. To avoid sending 2 pair of request/reponse exchanges for a large amount of e.g. CS calls it would be beneficial to optimize the procedure to one request/response exchange. 

Of course, the intention has always been to do this in a backward compatible manner.

Some comments inline.

BR,
Peter

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: den 2 mars 2005 10:58
> OPTIONS is meant to solicit the capabilities of the UAS, 
> including SIP 
> things (Allow, Accept, Accept-Encoding) and media things (through the 
> SDP in the body). It was not meant to be a way to do some kind of 
> capability negotiation.
[Peter] Agree, there should not be a negotiation.

> Indeed, a UAS should reject an OPTIONS request 
> with a body unless the body was marked as optional using the 
> Content-Disposition header field.
[Peter] Agree, as require is default...

> Putting an SDP in the body of an 
> OPTIONS request, even with an optional content-disposition, 
> feels like a 
> misuse of OPTIONS to me.
[Peter] I can't judge whether it is a misuse, but it seems like SIP is able to handle such an optimisation.

> 
> That said, I don't understand the specific problem 3gpp is looking to 
> solve by including a body in an OPTIONS request. Can you 
> elaborate on that?
> 
> Thanks,
> Jonathan R.
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Mar 2005 10:01:11 -0500

inline.

Peter Hedman (LD/EAB) wrote:

> 3GPP is discussing use cases where the capabilities of the remote UAs
> should be known prior to sending the INVITE, i.e. to be able to
> present a set of possibilities to the user. E.g. if there is an
> existing non-SIP communication between two users (e.g. CS call), SIP
> could be used to learn the capabilities of the remote UA.
> 
> Different mechanisms have been discussed e.g. use of Presence or
> using INVITE with inactive media. The initial use of OPTIONS was
> favourable.

Either presence or OPTIONS would work. Presence is clearly better if the 
user is someone you already are subscribing to. Prescaps will give you 
much the same information you will get from an OPTIONS, though it won't 
tell you the list of supported codecs.

> To avoid sending 2 pair of request/reponse exchanges for
> a large amount of e.g. CS calls it would be beneficial to optimize
> the procedure to one request/response exchange.

As I mentioned, doing that is not an appropriate use of OPTIONS. The 
OPTIONS request body is NOT meant to convey the capabilities of the 
requester.

>> Putting an SDP in the body of an OPTIONS request, even with an
>> optional content-disposition, feels like a misuse of OPTIONS to me.
>> 
> 

Its not a match for the semantics of the method. Quoting RFC 3261:

11 Querying for Capabilities

    The SIP method OPTIONS allows a UA to query another UA or a proxy
    server as to its capabilities.  This allows a client to discover
    information about the supported methods, content types, extensions,
    codecs, etc. without "ringing" the other party.  For example, before

Nowhere in there does it talk about OPTIONS being used to inform the 
other side of its capabilities.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 04 Mar 2005 08:43:50 -0800

I'm unclear on what exactly you want to accomplish here but if it is. Is it:

A is going to call B. A wants to find out the media capabilities of B then
allow the user of device A to make some choice before B starts alerting.

If so, you might consider pre conditions of some sort. Anyways, I'd be
curios to better understand what it is 3GPP wants to accomplish here.

Cullen

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Mar 2005 11:14:15 -0600

> curios to better understand what it is 3GPP wants to accomplish here.
Just guessing, but I suspect A wants to find out if it has any codecs 
(and perhaps transports, aka v6)  in common with B, or is going to need 
to route through a transcoder application instead, BEFORE alerting B.

So, preconditions would appear to work.

We should have built this protocol around a two-stage (or n-stage, 
where n >1, I suppose) commit model from day 1.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Mar 2005 12:31:13 -0500

> to route through a transcoder application instead, BEFORE alerting B.

Endpoint A doesnt need to include its SDP in the OPTIONS request to 
figure this out. It get can the capabilities from endpoint B from the 
OPTIONS response and compare with its own. If there is something in 
common, it can make the call.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2005 12:46:55 -0500

I don't *know* what they are trying to achieve. But I've been scratching 
my head trying to figure out what they could possibly be up to. Based on 
other things I have seen mentioned, I think possibly they need the SDP 
in the options in order to route the request to the appropriate 
application, and so get the answer that is appropriate to what they 
intend to do. So perhaps they need to see the SDP to choose the PTT 
application rather than the IM application or the video application.

If so, this points up another problem with routing based on SDP.

	Paul

Dean Willis wrote:
> We should have built this protocol around a two-stage (or n-stage, where 
> n >1, I suppose) commit model from day 1.
> 
> 
> -- 
> Dean
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 04 Mar 2005 21:00:41 -0800

Well, since this is such a fun guessing game... How about this solution

A sends INVITE with all it's codec to B. B say nope to all of them. A
decided that A must need a transcoder. A sends to B2BUA style transcoder,
called T, and T calls B offering all it's codecs.

I'm willing to bet this will have less post dial delay on your average call
that does not need a transocder than sending an option before very call.