Re: [rtcweb] Plan A, respun

[Emil Ivov <[e-mail]>]

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.

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

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

> 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


-- 
https://jitsi.org