Re: [rtcweb] How to multiplex between peers

[Colin Perkins <[e-mail]>]

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. 

-- 
Colin Perkins
http://csperkins.org/