Re: [rtcweb] Plan A, respun

[Emil Ivov <[e-mail]>]

On May 12, 2013 5:54 PM, "Harald Alvestrand" <[e-mail]> wrote:
>>> So you're saying that when using 1-31 streams, we use a single port
>>> pair, but when we use 32 streams, we use 32 port pairs?
>>
>> Most certainly not! I am suggesting that if you fill up your PT space
>> you could stop using bundle for your (presumably two, audio and video)
>> m= lines. So rather than using a single port for RTP, you'll fall back
>> to using two ports for audio and video.
>
> Hmmm... how would you do that? Since you're using one M-line per
> video source

No, I am not. I am using one m= line for many video sources.

> (remember, this is plan A, not plan B),

Correct, and again I am not talking about plan A.

> you're using the PT
> number for getting back to your M-line, which means that you're now
> creating more than one bundle, each bundle being limited to 32 PTs
> (and therefore 32 M-lines).

My point was NOT to use bundle in case PTs are insufficient. So in most
cases you'd have one m= line for video (with as many sources as you wish)
and one for audio.

>> If you start lacking numbers again, you could consider turning off
>> rtcp-mux which would again almost double your choices (presuming that
>> you limited yourself to using the 96-127 range because you wanted to
>> make rtcp demuxing easier).
>>
>> Just to clarify, I consider Plan B's use of m= lines (i.e. 1 m=line for
>> many SSRCs) very natural and in-line with RTP design. I am not arguing
>> against this. (I would actually strongly argue against the alternative).
>
> Thanks for the clarification!

>>>> It seems to me that the consequences of not using bundle in some
>>>> specific scenarios, especially in cases where trickle ICE is also
>>>> supported, are far lesser than requiring everyone to support
>>>> pre-announcement of SSRCs.
>>>
>>> Why?
>>>
>>> Remember: In Plan B, the only applications who have to support
>>> pre-announcement of SSRCs are those that want to send more than one
>>> media stream in a single RTP session.
>>
>> And it is exactly those applications that I am worried about. Imagine I
>> am a conference focus that remotely controls an RTP translator. I would
>> hence invite you with a single m= line for audio and a single m=line for
>> video.
>>
>> On either of these you would end up getting a bunch of SSRCs for all the
>> other participants. Or maybe you would just get one if the translator
>> decides to mix rather than translate for some reason.
>>
>> Either way I can't send you all SSRCs in advance because there's know
>> way for me to learn those of the other participants unless I use some
>> unnecessary, unnecessarily complicated and unnecessarily time-consuming,
>> signalling.
>
>
> Or you could signal none of them and depend on the fallback case in
> draft-ietf-mmusic-msid to handle them in a consistent manner, and
> use other methods to figure out how to handle them...

If you are referring to section 4.1 that you also pasted earlier in this
thread, it only talks about one track, per stream, per m= line. This
doesn't cover the conferencing case I described in my previous mail (quoted
above).

Cheers,
Emil

--sent from my mobile

>
>
>>
>>> Any application that is satisfied with having mulitple RTP sessions
>>> corresponding to multiple M-lines can just signal as they're used to,
>>> without BUNDLE or SSRC signalling (although it will work a lot better if
>>> they use a=content consistently).
>>
>> Again, that's not the kind of alternative that I was arguing for.
>>
>> Emil
>>
>>
>