Subject: RE: [SIP] SDP in OPTIONS

From: "Peter Hedman (LD/EAB)" <[email-masked]>
Date: Wed, 2 Mar 2005 08:57:20 +0100

Thanks for the comments!

Just to be sure that I understood this.

RFC3264 states in chapter 9 Indicating Capabilities: "The port MUST be set to zero, but the connection address is arbitrary.  The usage of port zero makes sure that an SDP formatted for capabilities does not cause media streams to be established if it is interpreted as an offer or answer."

RFC3264 further states the following in chapter 6 "To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero." 

As the SDP in the OPTIONS request would indicate a capability the ports should be set to zero, i.e. UAS can't express whether the media is supported or not as the UAS would always set the ports to zero in the response.

Then I hope the following example is correct interpretation:
If UAC indicates support for audio and video, the UAC would set the ports to zero in the OPTIONS request. 
The UAS would then only indicate what it supports in the OPTIONS response, e.g. if only audio the UAC wouldn't include any video m= line and set the port for the audio to zero.

BR,
Peter
> -----Original Message-----
> From: Scott Godin [mailto:[email-masked]]
> Sent: den 24 februari 2005 18:13
> To: 'James M. Polk'; Scott Godin; Peter Hedman (LD/EAB); [email-masked]
> Cc: 'Robert Sparks'
> Subject: RE: [SIP] SDP in OPTIONS
> 
> 
> After re-reading Section 11 of RFC3261 - there doesn't really 
> seem to be any
> definitive answer to this.  The following quotes are what I based my
> assumptions on:
> 
> "The response code chosen MUST be the same that would have 
> been chosen had
> the request
> been an INVITE. That is, a 200 (OK) would be returned if the 
> UAS is ready to
> accept a call, a 486 (Busy
> Here) would be returned if the UAS is busy, etc. This allows 
> an OPTIONS
> request to be used to determine
> the basic state of a UAS, which can be an indication of 
> whether the UAS will
> accept an INVITE request."
> 
> Technically this quote refers to the response code - but it 
> would seem to
> make sense to apply to the other parts of the options response too.
> 
> "A message body MAY be sent, the type of which is determined 
> by the Accept
> header field in the OPTIONS
> request (application/sdp is the default if the Accept header 
> field is not
> present). If the types include one that
> can describe media capabilities, the UAS SHOULD include a body in the
> response for that purpose. Details
> on the construction of such a body in the case of application/sdp are
> described in [12]."
> 
> This quote references RFC3264 (SDP Offer Answer) as a 
> mechanism to form the
> SDP response.
> 
> Scott
> 
> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: Thursday, February 24, 2005 10:56 AM
> To: Scott Godin; 'Peter Hedman (LD/EAB)'; [email-masked]
> Subject: RE: [SIP] SDP in OPTIONS
> 
> At 08:20 AM 2/24/2005 -0500, Scott Godin wrote:
> >My understanding is that if an SDP if provided in the 
> OPTIONS request the
> >SDP in the 200 response should be the same as it would be if 
> the UA was
> >responding to an INVITE request
> 
> I thought the SDP in the 200 OK could/would include all the session 
> parameters the UAS was willing to reveal (including all the 
> codecs the UAS 
> was willing to communicate with).
> 
> >  - of course the SDP exchange should not be
> >acted on - it is only used for capability discovery.
> >
> >Scott
> 
> 
> cheers,
> James
> 
>                                 *******************
>                  Truth is not to be argued... it is to be presented
> 

_______________________________________________
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: Wed, 02 Mar 2005 04:57:31 -0500

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. Indeed, a UAS should reject an OPTIONS request 
with a body unless the body was marked as optional using the 
Content-Disposition header field. Putting an SDP in the body of an 
OPTIONS request, even with an optional content-disposition, feels like a 
misuse of OPTIONS to me.

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.

-- 
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