Re: [rtcweb] How to multiplex between peers

[Justin Uberti <[e-mail]>]

On Wed, Jul 20, 2011 at 3:59 PM, Justin Uberti <[e-mail]> wrote:

>
>
> On Wed, Jul 20, 2011 at 3:51 PM, Matthew Kaufman <
> [e-mail]> wrote:
>
>>
>> On Jul 20, 2011, at 12:46 PM, Justin Uberti wrote:
>>
>> >
>> > This is where I've ended up on this topic. We can easily multiplex
>> multiple RTP sources (of the same type) over a single RTP session using
>> SSRC. We can also mux RTCP over the RTP session using RTCP mux. So, for an
>> arbitrary video call, we have just 2 RTP sessions/NAT bindings.
>> >
>> > Is it worth going the extra mile to get down to 1 in v1.0, given the
>> lack of consensus that exists right now? Is there even a compelling argument
>> to do so?
>>
>> Yes and yes.
>>
>> I really can't understand why, if we can multiplex 3 totally different
>> types of video streams over the same RTP session using SSRC (with wildly
>> different bit-rates, inter-packet times, etc.) we can't also multiplex audio
>> and video. Not a single argument that has been presented has convinced me,
>> and getting from 2 to 1 is a *50%* reduction in NAT port utilization. (And a
>> significant reduction in the number of "strange" failure modes, where one
>> traversal worked and the other didn't.)
>>
>
> Clearly we can, but we need to do additional work to get there. This work
> will take time and delay v1.0, so we need a pretty convincing rationale to
> do so.
>
> I concur that solving strange failure modes is significant. But with regard
> to NAT port utilization, this ignores the utilization by the browser for
> HTTP; 50% reduction seems possible in theory only. (Here I am essentially
> restating 2.2.2 from
> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1,
> which I haven't yet seen a clear response to.)
>

Also: when falling back to send media over TCP/WebSockets, a lost packet may
cause a momentary audio dropout as the transport stalls while the packet is
retransmitted. I expect that this will occur more frequently if video and
audio are combined on the same TCP connection, if for no other reason than
the much higher packet rate.


>
>
>
>
>> Matthew Kaufman
>>
>>
>