Hi Vineet, If Bob support only one codec in answer, out of all codec Sended by Alice in his offer, then there is no need to send re-INVITE to lock the single supported codec.
Regards, Satish On Wed, Mar 7, 2012 at 10:11 AM, Vineet Menon <[email protected]>wrote: > 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 > -- Thanks & Regards Satish Agrawal New Delhi-24. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
