> 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
