Subject: RE: [SIP] SDP in OPTIONS

From: Scott Godin <[email-masked]>
Date: Thu, 24 Feb 2005 12:12:53 -0500

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