Re: [MMUSIC] Wisdom sought: Prioritization of codecs

[Paul Kyzivat <[e-mail]>]

On 11/15/12 2:55 PM, Adam Roach wrote:
> On 11/15/12 10:57, Paul Kyzivat wrote:
>> The whole notion of codec preference breaks down even more for
>> multiplexed streams. You may very explicitly prefer/require different
>> streams to use different codecs.
>>
>> So I don't think we can rely too much on parsing the existing text for
>> guidance on how to use SDP to represent multiplexed sessions. (Unless
>> of course we use bundle, with a separate m-line for each stream.)
>> AFAIK we are breaking new ground here.
>
> This kind of "we fixed this problem once and get to fix it all over
> again" issue is exactly the kind of thing I was speaking to at the
> microphone in MMUSIC in Atlanta. The further we drift from the
> established semantics of SDP, the less applicable previously developed
> mechanisms become. Bundle and similar approaches that maintain one m=
> line per stream allow us to leverage 14 years of extensions and
> clarifications. If we decide to split from that (rather fundamental,
> IMHO) characteristic of SDP, we are effectively forking the protocol,
> and throwing away years of prior work.

I would like to agree with you. But when multiplexing RTP streams it is 
problematic to prearrange every stream in SDP. That requires knowing in 
advance how many there will be, what their SSRCs will be, and what the 
mapping from SSRC to codec will be.

We are still thrashing that out for CLUE. We have some use cases where 
it seems we can't do all of that in advance, and doing an O/A after we 
get packets is too late. Maybe we will find a way around that. Too early 
to tell.

And AFAIK RTCWEB has only been planning to use bundle to give a separate 
m-line for audio and one for video, not necessarily a separate one for 
every media stream. I think there is still an implication that a given 
m-line might be multiplexed, and might use different codecs (among those 
that are negotiated) for the different multiplexed streams.

And even our 14 years of experience on this haven't resulted in a spec 
that fully lines up with what is deployed in the wild. There is an 
assumption in the specs that if you offer multiple codecs and the answer 
accepts multiple codecs, then you can accept packets in any of the 
negotiated codecs, and switch among them, even though we know 
implementations that depend on only one codec being used. (With a 
special case for telephone-events.)

We are now encountering applications that have more complex needs than 
were anticipated over those 14 years. It's nice if we can reuse what we 
have without change to meet those needs. But lets not constrain new 
applications to the sorts of things we had in mind 14 years ago.

	Thanks,
	Paul