Re: [rtcweb] Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt

[Jonathan Lennox <[e-mail]>]

On Jul 25, 2011, at 8:50 AM, Colin Perkins wrote:

> On 24 Jul 2011, at 16:44, Matthew Kaufman wrote:
>>  4. An RTP mixer would not be able to combine interleaved streams of
>>     incompatible media into one stream.
>> 
>> Not relevant to the RTCWEB peer-to-peer case as the browser is not an RTP mixer. Also not relevant to any RTCWEB use cases that I can identify. And, if an RTP mixer at one end it can simply not agree to use multiplexing.
> 
> This would work if you are directly talking to a mixer. It precludes the cases where you are talking indirectly to a mixer via a gateway, unless you define additional signalling to determine that there is a mixer on the remote side of the gateway.

Clearly, the gateway which is talking to the mixer needs to perform signaling negotiation with it, so it understands the RTP sessions at all, and so it will know if the mixer understands muxing or not.

>>  5. Carrying multiple media in one RTP session precludes: the use of
>>     different network paths or network resource allocations if
>>     appropriate;
>> 
>> Appears to not be relevant to the RTCWEB case where a unicast path will be negotiated using ICE.
> 
> An RTCWeb client using ICE could negotiate different network paths for the audio and video flows, and could use network-based QoS mechanisms, if flows were sent separately. Those mechanisms work just fine in unicast.

Yes, it could use these mechanisms, if they're appropriate.  If it's not appropriate, it wouldn't need to.

>> In all my reading today I have not been able to find anything more concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up if you are aware of any other relevant specifications that would argue against using SSRC to multiplex audio and video streams over a single RTP session between a pair of compatible endpoints that agree to do so.

[Quote from Colin's draft omitted]

A lot of these are responses to the ideas of doing PT muxing, or muxing several distinct RTP sessions onto a single transport flow.  They don't seem, mostly, to be addressing muxing RTP audio and video sources onto a single (proper) RTP session, i.e. with a single SSRC space, single (global) RTCP bandwidth value, single value for RTCP timing intervals, etc.

It's clearly the case that audio's share of 0.05 * (audio bw + video bw) is going to be much greater than 0.05 * (audio bw), so you're going to be sending audio RTCP a lot more frequently with mux'ed media than you would in an audio-only RTP session, whereas you'll send video RTCP slightly less frequently than a video-only session.  But this isn't, as far as I can tell, a problem, especially if you set a sensible value for trr_int (assuming AVPF).

In SSRC-muxing, RTX and FEC require a way of binding together original and repair streams, but RFC 5576 already defines a mechanism (ssrc-group) for doing this in SDP, and Magnus's SRCNAME proposal could alternately do it in RTCP.

I admit to not understanding the XRBlocks well enough to say whether it expects to send VoIP feedback reports for every source in a session that it thinks is audio, but presumably a monitoring device that's monitoring a VoIP RTP session already needs to be told whether the session it's monitoring is audio, video, or other, and would be able to (or have to) ignore a mux'd session.

--
Jonathan Lennox
[e-mail]