Sending SDP in OPTIONS has no meaning and is usually not sent. An Accept header field SHOULD be included in OPTIONS to indicate the type of message body the UAC wishes to receive in the response.
Accordering to RFC 3261, Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. A message body MAY be sent. more details refer to RFC 3261 section 11 > Is there any use of sending SDP in options?? > Also, will the response to options contain the media > capabilities and other things by default or do we need > to explicitily ask for it? > I mean an options sent with no SDP, will the response > still contain the SDP capabilities of the callee! > > --- "J. Jaikumar" <[EMAIL PROTECTED]> wrote: > >> > >5> if you send an options request, how does the >> other >> > >side notify about its capabilities and which all >> of >> > >them??( does it tell abt its media capabilities >> too). >> > > >> "Options" method is responded with an OK. >> OK response shall contain all the information about >> supported media >> capabilities (codec), supported methods, option >> tags, content types, etc >> >> rgds >> jai >> >> >> >> > Please see my response in line below.. >> > >> > varun wrote: >> >>Hi, >> >>1> In the invite offer, lets say a list of codecs >> with >> >>send/recv mode are send..! >> >>So in 200 OK, the calle just picks one of these >> codecs >> >>and replies back or it can also send a list of >> codecs >> >>with a ordered preference?? >> >> >> > In 3261, the callee is supposed to honor the >> caller codec preference >> > unless it has a compelling reason to choose its >> own preference. >> > Therefore, in general case, the caller will >> response in 200 OK with the >> > codec that is listed first in the caller's SDP >> >>2> Also, after sending INVITE, the caller opens >> its >> >>media port ( ready to receive media)...how does it >> >>receive media from calle before 200 ok/or any >> >>provisional reponse...i mean since 200 >> OK/provisional >> >>response would specify the actual common media >> >>format..! >> >> >> > Early dialog can have media flow before 200 OK. >> Early dialog can happen >> > when the UAS sends 183 with SDP and there could be >> RTP after that, no >> > need to wait for 200 OK. And again, the SDP in 183 >> message would honor >> > the caller's codec preference. >> >>3> Also, can send and receive media formats be >> >>different in a SIP call ( like h.323)...! >> >>This would require multiple offer-Answer ??? >> >> >> > In SIP, if one of the parties wants to change the >> media type, it will >> > need to re-INVITE or UPDATE with SDP. The other >> party will accept with >> > 200 OK. The media type should be the same for both >> send and receive >> > though. I don't think you can have caller sends >> one type of media and >> > the other sends another type and the call would >> work. >> >>4> what abt update method..how does it modify he >> >>negotiated media formats?? >> >> >> > UAC would send the UPDATE with its codec >> preference in SDP. The UAS will >> > determine if it can honor the UAC's preference and >> respond with 200 OK >> > that has its codec of choice in the SDP >> >>5> if you send an options request, how does the >> other >> >>side notify about its capabilities and which all >> of >> >>them??( does it tell abt its media capabilities >> too). >> >> >> >>Would appreciate your response. >> >> >> >>Thanks >> >>Naveen >> >> >> >>__________________________________________________ >> >>Do You Yahoo!? >> >>Tired of spam? Yahoo! Mail has the best spam >> protection around >> >>http://mail.yahoo.com >> _______________________________________________ >> >>Sip-implementors mailing list >> >>[email protected] >> >>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> >> >> >> > >> > >> > _________________________________________________________________ >> > Express yourself instantly with MSN Messenger! >> Download today it's FREE! >> > >> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> > >> > _______________________________________________ >> > Sip-implementors mailing list >> > [email protected] >> > >> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > >> >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
