Re: [rtcweb] How to multiplex between peers

[Justin Uberti <[e-mail]>]

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





> Matthew Kaufman
>
>