Re: [rtcweb] How to multiplex between peers

[Jonathan Lennox <[e-mail]>]

On Jul 21, 2011, at 2:51 AM, Colin Perkins wrote:

> On 21 Jul 2011, at 00:24, Jonathan Lennox wrote:
> ...
>> I've read draft-perkins-rtcweb-rtp-usage-02, and I still don't understand what you're claiming SSRC-muxing would break.
>> 
>> Running audio and video (and FEC, and RTX, and simulcast video, and Real-Time Text, and etc. etc.) in a single RTP session does, not, as far as I've been able to tell (after a lot of thought), break anything in RTP.
>> 
>> To be sure, it's not backward compatible with RTP endpoints that assume a single source per session.  It would also be hard to retrofit SDP to describe and negotiate it.  And for some use cases it requires some source-level signaling, as in RFC 5576.  But the RTP model, per se, is perfectly amenable to it, as far as I can tell.
> 
> 
> Section 2.2.1 of draft-perkins-rtcweb-rtp-usage-02 lists several problems that occur when multiplexing RTP sessions onto a single lower-level flow. 
> 
> There are clearly some limitations caused: separate endpoints, quality of service, limitations with mixers and translators, retransmission, FEC, sampling group membership, and so on. There is also some breakage when several sessions are multiplexed: RTCP is problematic with several clock rates per session, SSRC allocation is broken, and the RTCP reporting interval and timing rules are broken.
> 
> You may not think some of these are important. Some can be avoided by the use of appropriate signalling. Some can be mitigated by allowing multiple different media types in an RTP session, or by splitting the SSRC space. I'm not arguing that there aren't ways to fix this problem, or ignore it in some cases, but they cause various degrees of change to RTP, and need to be carefully evaluated by AVTCORE if they're to be done. 

I absolutely agree that multiplexing several RTP sessions into a single lower-level flow could break things, but that's not what I'm advocating.  Instead, I'm only advocating relaxing the rule that every source in a *single* RTP session -- a session which follows all the RFC 3550 rules -- must have the same top-level media type.

Since RTP was defined to allow up to 2^32-1 distinct sources in a session, all the rules of RFC 3550 seem to follow naturally, as do other RTP-family specs except those whose designers forgot to take RTP's group-communication nature into account.

It may be useful to relax *more* rules, for the topological cases that Stephan mentioned (endpoint-endpoint or RTCP-terminating-MCU) -- particularly since a lot of RTP's (or specifically, RTCP's) existing timing rules don't make a lot of sense in scenarios where you have widely asymmetric bandwidths.  This might need to formally be a new RTP profile, though I'd rather avoid that if possible.  But the starting point should be, I think, assuming a single RTP session with arbitrarily many distinct sources, and see if the RFC 3550 rules lead us somewhere bad *in that scenario*.

--
Jonathan Lennox
[e-mail]