Nick, What if such equipment (e.g. Cisco gateway) gets INVITE without SDP offer? This means they have to send 200 (Ok) with SDP Offer and get the SDP Answer in the ACK and the problem will happen again.
Another way to try and avoid this problem (which is quite common by the way, this is because many Equipment manufacturers port to SIP systems that support H.323 and the H.323 solve that with the openLogicalChannel model. So you can allow your self to support only one codec at a time). Anyway to try to avoid this: Try to always be the SDP answerer and not the SDP offerer. Meaning always send INVITE with no SDP and answer on ACK. Thanks, Eran. Eran Shen Intel Corporation Telecommunications and Embedded Group P.O Box 58, Migdal Tefen, Israel Tel: +972-4-9105020 <mailto:[EMAIL PROTECTED]> -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 4:56 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Two media type in SDP answer. If UAS supports only one codec at a time, it should pick just one codec in its answer, e.g. PCMA. But if the UAS supports both codecs and can switch between them, it is allowed to include both codecs in its answer. Your example is perfectly correct. The difficulty is when the UAC supports either codec, but only one at a time. Some equipment (e.g. Cisco gateways) resolve the problem by sending a *third* session description in the ACK. This seems to be a perfectly good solution. It would be convenient if this was allowed. Unfortunately in sip bis-05 it has been declared a violation of the "offer/answer" model. I can imagine two things the UAC can do to get around the restriction: (a) It could start with an OPTIONS to discover what codecs are supported, then INVITE the UAS, picking just a single codec. [This assumes that OPTIONS gives an answer consistent with INVITE.] (b) It could ACK the response then immediately re-INVITE it with just a single codec. [This delays the call startup, and if the ACK was lost it could get into an awkward "Retry-After" scenario.] Neither solution is ideal... Nick > Take a look to this scenario! > > A UAC sends an INVITE containing SDP like the following: > > v=0 > o=- 0 0 IN IP4 149.35.48.216 > s=SIP Call > c=IN IP4 149.35.48.216 > t=0 0 > m=audio 5008 RTP/AVP 0 8 4 18 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:4 G723/8000 > a=rtpmap:18 G729/8000 > > The UAS respond with an OK containing the following SDP: > > v=0 > o=MxSIP 0 0 IN IP4 149.35.48.175 > s=SIP Call > c=IN IP4 149.35.48.175 > t=0 0 > m=audio 5006 RTP/AVP 0 8 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > > The UAC start to send RTP packet using PCMU codec. > The UAS start to send RTP packet using PCMA codec. > > Who are making a mistake? > I think UAS have to respond supporting only one media (PCMU or PCMA). > In this case it receive a SDP offer. In the answer UAS must select one of the > possible codec. > Let me know your opinion! > > Thanks > Lorenzo -- Nick Hollinghurst [EMAIL PROTECTED] Research Engineer Phone: +44 1223 343364 AT&T Laboratories, Cambridge, England Fax: +44 1223 313542 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
