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

Adam,

I'm open to different approaches for addressing multiple RTP streams. So 
far ISTM there are drawbacks to all the ones I have seen discussed.

The m-line per stream approach has problems if you don't know a priori 
how many, or which, streams you will have need to send over the session.

I think there is also a problem with how RTCP works, and how the 
attributes that affect it apply, in the m-line per session approach. 
(And there are also problems here if you allow multiple streams per m-line.)

	Thanks,
	Paul

On 11/19/12 11:24 AM, Adam Roach wrote:
> On 11/19/12 10:04, Harald Alvestrand wrote:
>> On 11/19/2012 04:38 PM, Adam Roach wrote:
>>>
>>>
>>> There are, at the moment, 176 attributes in the IANA registry that
>>> are applicable to m= sections:
>>> ...
>>> Some of these are applicable to the RTP session; others only make
>>> sense as applied to a single media stream.
>> And some make absolutely no sense at all in the RTCWEB context.
>
> Perhaps not for RTCWEB, but I'm fairly certain that we'd like to see the
> same solutions applies to CLUE as RTCWEB. I concede that some of these
> are applicable only to technologies that are dead or dying; however...
>
>> I have at one point in my life dealt with T-series fax
>
> ...T.38 fax isn't one of them. Sadly.
>
> It sure would be nice to discount all of the existing mechanisms, but I
> suspect that they're not as wholly worthless are you're implying.
> Perhaps when I have a bit more time, I'll sit down and do a
> mechanism-by-mechanism evaluation of applicability of each to RTCWEB and
> CLUE. Until then, I expect it's relatively safe to assume that people
> haven't been putting values into that registry by performing utterly
> meaningless work; and, further, that only a fraction of it has been
> overtaken by technological progress.
>
> /a
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>