Hi Prabha, The suggested way in RFC 3264 for this scenario is to do a second OFFER/ANSWER to Lock down the codec.
Following is the text of RFC for your convenience... --snip-- 10.2 One of N Codec Selection A common occurrence in embedded phones is that the Digital Signal Processor (DSP) used for compression can support multiple codecs at a time, but once that codec is selected, it cannot be readily changed on the fly. This example shows how a session can be set up using an initial offer/answer exchange, followed immediately by a second one to lock down the set of codecs. The initial offer from Alice to Bob indicates a single audio stream with the three audio codecs that are available in the DSP. The stream is marked as inactive, since media cannot be received until a codec is locked down: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 0 4 18 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=inactive Bob can support dynamic switching between PCMU and G.723. So, he sends the following answer: v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=inactive Alice can then select any one of these two codecs. So, she sends an updated offer with a sendrecv stream: v=0 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv Bob accepts the single codec: v=0 o=bob 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv If the answerer (Bob), was only capable of supporting one-of-N codecs, Bob would select one of the codecs from the offer, and place that in his answer. In this case, Alice would do a re-INVITE to activate that stream with that codec. As an alternative to using "a=inactive" in the first exchange, Alice can list all codecs, and as soon as she receives media from Bob, generate an updated offer locking down the codec to the one just received. Of course, if Bob only supports one-of-N codecs, there would only be one codec in his answer, and in this case, there is no need for a re-INVITE to lock down to a single codec. --snip-- Regards Anshoo. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Prabha Sent: Monday, December 15, 2003 11:09 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Offer-answer queries Hello, Yes, i do agree with you that when both the parties support codec 3 and 5, the RTP payload also would be either 3 or 5 But i wanted to know whether the offeror could still send an ACK with sdp details by selecting one of the coders. Because i did come across some statements saying ACK should not be sent with sdp details if the offer is already sent in an INVITE. Is the following INVITE-200OK-ACK handshake against the RFC 3264 implementation OFFEROR (SDP details in INVITE) v= 0 o= A 1464112736 1464112736 IN IP4 151.209.33.190 s=Calling c=IN IP4 pgs-477 t=0 0 m=audio 2074 RTP/AVP 0 3 5 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/4000 a=rtpmap:5 ADPCM/4000 ANSWERER(SDP details in 200 OK ) v= 0 o= B1464112736 1464112736 IN IP4 151.209.33.194 s=Answering the call c=IN IP4 pgs-451 t=0 0 m=audio 2074 RTP/AVP 3 5 a=rtpmap:3 GSM/4000 a=rtpmap:5 ADPCM/4000 OFFEROR (SDP details in ACK) v= 0 o= A 1464112736 1464112736 IN IP4 151.209.33.190 s=Calling c=IN IP4 pgs-477 t=0 0 m=audio 2074 RTP/AVP 3 a=rtpmap:3 GSM/4000 If the above handshake is not allowed, then looking into the payload type in the RTP header is the the only way to find out for the negotiated codec ? Thanks, Prabha N ----- Original Message ----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Monday, December 15, 2003 10:37 AM Subject: RE: [Sip-implementors] Offer-answer queries Regards, Nataraju A.B. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Prabha Sent: Friday, December 12, 2003 6:41 PM To: Ranjit Avasarala (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS); [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Offer-answer queries Hi Ranjit, Thanks for the response. But i am still not clear. Here 200 Ok has been sent with codecs 3 and 5. It means to say that he is supporting both 3 and 5. Now how does an offeror identify the final negotiated codec without seeing the payload type in RTP header. If 200 OK would have come with one coder, then it is clear fto the offeror regarding the accepted codec details. [ABN] the result of the offer/answer negotiation is not the content of the data carried in the message but the agreed upon set of encodings supported by both the parties... If both the parties support codec 3 & 5 obviously the RTP payload could be one of the two offers carried in the initial offer... Please can you give some more inputs on this. Thanks, Prabha N ----- Original Message ----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Friday, December 12, 2003 5:15 PM Subject: RE: [Sip-implementors] Offer-answer queries Hi The accepted codec gets reflectd in 200 OK. so there is no need to send negotiated codecs in ACK. If no offer is sent in INVITE by caller, then the callee send his offer in 200 OK and the negotiated codec should be sent by caller in ACK Thanks & Regards Ranjit Wipro Technologies E-City, Bangalore Ph: 8520408/16 extn: 2173 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Prabha Sent: Friday, December 12, 2003 4:42 PM To: [EMAIL PROTECTED] Cc: Jonathan Rosenberg Subject: [Sip-implementors] Offer-answer queries Hello, I have a question regarding the SDP part of the Invite request. suppose user agent "A" wants to talk to user agent "B", he sends a INVITE request to B. the SDP part of the invite request is as follows, v= 0 o= A 1464112736 1464112736 IN IP4 151.209.33.190 s=Calling c=IN IP4 pgs-477 t=0 0 m=audio 2074 RTP/AVP 0 3 5 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/4000 a=rtpmap:5 ADPCM/4000 If user agent accepts the request and agrees to talk to user agent A, he sends a OK response with SDP as followed. v= 0 o= B1464112736 1464112736 IN IP4 151.209.33.194 s=Answering the call c=IN IP4 pgs-451 t=0 0 m=audio 2074 RTP/AVP 3 5 a=rtpmap:3 GSM/4000 a=rtpmap:5 ADPCM/4000 now why can't the user agent A send an ACK by selecting one of the coders specified in answer AS mentioned below ? v= 0 o= A 1464112736 1464112736 IN IP4 151.209.33.190 s=Calling c=IN IP4 pgs-477 t=0 0 m=audio 2074 RTP/AVP 3 a=rtpmap:3 GSM/4000 than analyzing the payload type (PT) header field in the RTP Packet. Thanks in advance Prabha N Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
