Re: [rtcweb] Plan A, respun

[Harald Alvestrand <[e-mail]>]

On 05/12/2013 03:00 PM, Emil Ivov wrote:
> On 12.05.13, 14:58, Harald Alvestrand wrote:
>> On 05/12/2013 11:39 AM, Emil Ivov wrote:
>>> Coming back to this for a sec:
>>>
>>> On 08.05.13, 14:00, Harald Alvestrand wrote:
>>>> To put a blunt point on it: Either send less than ~32 streams, or give
>>>> a=ssrc attributes.
>>> Wouldn't it make more sense to either send ~32 streams or you don't use
>>> bundle? If you run out of PTs for a single m-line then you may also
>>> reconsider use of rtcp-mux.
>> 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 (remember, this is plan A, not plan B), 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).

Plan A is certainly creating an use case for more than one bundle, but 
it's still implying code that swings into action at the 32 track 
boundary, and is unused before that.

>
> 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!

>
>> I hadn't even considered the possibility of driving off that particular
>> cliff at that boundary.
> Fortunately I don't think anyone is.
>
>>> 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...

>
>> 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
>
>