Hi Vineet, Please check section "10.2 One of N Codec Selection" of RFC 3264.
"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." Hope it helps. regards, Aman Aggarwal Aricent -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Vineet Menon Sent: Wednesday, March 07, 2012 10:11 AM To: Worley, Dale R (Dale) Cc: Paul Kyzivat; [email protected] Subject: Re: [Sip-implementors] Capability negotiation control HI list, Hi Robert, What about the case when UAS responds with just one codec? Would OPAL make the UAC send a reINVITE with that again?? Something like this, UAC -------------------INVITE/ 261,263,264 ----------> UAS UAC <-------------------200/OK/ 264------------------------ UAS UAC ------------------- reINVITE/264----------------------UAS ??????????? UAC <--------------------200/OK/264------------------------UAS ??????????? Regards, Vineet Menon On 7 March 2012 01:28, Worley, Dale R (Dale) <[email protected]> wrote: > > From: Paul Kyzivat [[email protected]] > > > > Another is when multiple RTP streams are multiplexed on the same RTP > > session - distinguished by SSRC. (I may have the terminology wrong > > there.) This hasn't been considered much in sip until recently, but is > > now increasingly going to be used. > > I don't know if it is done much, but that would be natural in > conferencing situations, with the conference focus simply copying the > chosen incoming stream to all the outgoing streams. As the chosen > speaker changes, the outgoing streams could switch between codecs. > > > From: Robert Jongbloed [[email protected]] > > > > I know there are some implementations that do exactly this for audio. The > > OPAL implementation unfortunately is not designed to wait till the first > RTP > > packet arrives before creating codecs, starting video grabbers, blah, > blah, > > blah. It does it when the 200 OK arrives. So, OPAL gets around the > ambiguity > > by immediately sending a re-INVITE selecting one of the codecs the remote > > answered with. > > Yeah, but the "remote" can refuse the re-INVITE, forcing OPAL to > continue to accept all the codecs that it offered in the first place. > > Dale > > _______________________________________________ > 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 =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
