[MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs)

[Harald Alvestrand <[e-mail]>]

On 11/15/2012 08: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.
actually my caricature of the history of SDP is 4 years of multicast, 
where multiple streams per RTP session was the norm, 10 years of 
telephony, with only one stream of each type that mattered in each 
direction, and 12 months of trying to get multiple streams working again.

While beating down the resistance of the RTP people against having 
different media types in one RTP session, I've been told over and over 
again that having multiple media streams of the *same* media type in one 
RTP session is just fine and dandy "because that's what we designed RTP 
to do", and now we're finally getting explicit about addressing the idea 
of whether we tolerate more than one media stream per <control surface 
unit> - where the only control surface unit that's been used for the 10 
years of telephony is the M-line.

The M-line is problematic because it binds together multiple things:

- A top level media type
- A set of parameters for media transmission *in all directions* (bound 
to payload type)
- Transport information (the "RTP session" data)


SDP M-lines are already problematic as soon as you want different 
parameters in the two directions. It only goes downhill from there when 
one does multiple flows with varying characteristics.

As I said in Atlanta: SDP M-lines have been walking with one foot on the 
"I'm an RTP session" bank of the canal and with the other foot on the 
"I'm a media stream description" bank of the canal.

The canal is growing wider. Fast.