Re: [AVTCORE] [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt

Jonathan Lennox <> Sun, 13 November 2011 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54A5021F86AA; Sun, 13 Nov 2011 13:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ngfromaUYmvO; Sun, 13 Nov 2011 13:17:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 738A321F86A6; Sun, 13 Nov 2011 13:17:21 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id C09E27A2D0A; Sun, 13 Nov 2011 16:17:16 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB016.mail.lan (unknown []) by (Postfix) with ESMTP id 49E4E7A2D34; Sun, 13 Nov 2011 16:17:16 -0500 (EST)
Received: from BE235.mail.lan ([]) by HUB016.mail.lan ([]) with mapi; Sun, 13 Nov 2011 16:17:15 -0500
From: Jonathan Lennox <>
To: Colin Perkins <>
Date: Sun, 13 Nov 2011 16:17:13 -0500
Thread-Topic: [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt
Thread-Index: AcyiHfyR6IKAmjCsQHKJtY3bzl7hTQAKqtYg
Message-ID: <C3759687E4991243A1A0BD44EAC823034C439A3493@BE235.mail.lan>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, IETF AVTCore WG <>
Subject: Re: [AVTCORE] [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Nov 2011 21:17:22 -0000


I believe this would work under the logic I describe in media-type-mux: you still send RR or SR packets for every source, you just treat your sources other than the reporting source as though they're "disconnected" receivers, i.e. don't include redundant reports in their SRs/RRs.

The number of SR/RR packets is linear in the number of sources in a session -- it's the number of reports that's quadratic, and thus problematic.

If there's a need for some XR reports to choose a reporting source that has the same media type as the source being reported on, that should be fine.

-----Original Message-----
From: Colin Perkins [] 
Sent: Monday, November 14, 2011 12:05 AM
To: Jonathan Lennox
Subject: Re: [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt


A more compelling argument for reporting from all SSRCs may be that various AVPF and RTCP XR packets make no sense unless sent from the SSRC corresponding to the correct media type. Sending just those, but not regular RTCP reports, will cause havoc to the RTCP participant timeout rules, and SSRC collision detection, unless you signal and heavily special-case the code. This doesn't seem worth it, for tiny bandwidth savings.

Reporting on yourself is harder to defend, I agree, but the potential to confuse monitoring equipment (and given the activity in XRBLOCK, someone must care about that...), and the additional signalling needed, again seem to outweigh the bandwidth cost.


On 27 Oct 2011, at 23:57, Jonathan Lennox wrote:
> Hi, Colin --
> Thanks for taking a look my draft!
> I saw this recommendation in the multiplex-architecture draft, after I finished my own (I didn't get a chance to read any other -00 drafts before finishing my own before the deadline).
> I think this is an AVTCore issue, so I'm following up there...further discussion should probably just be on AVTCore, unless there are WebRTC-specific issues.
> The multiplexing-architecture draft in general is a very good draft -- it's extremely thorough and useful -- but I admit to not being very convinced by that section of it.
> At small numbers of sources, self-reporting and cross-reporting does indeed use a fairly small amount of bandwidth, but the problem is that their bandwidth usage is quadratic in the number of sources, since every source must report on every other. So as the number of sources grows, they begin to consume all RTCP bandwidth sending redundant or trivial information.
> And this for the sake of third-party monitors, which (personally) I've never seen deployed outside a research environment, and seem architecturally dubious to me, at least for offer-answer negotiated streams. (IPTV and other declarative-SDP architectures are probably different.)
> On Oct 27, 2011, at 11:12 AM, Colin Perkins wrote:
>> Jonathan,
>> Thanks for submitting. This is a good draft.
>> One comment: Section 3.1 suggests that a source generating multiple RTP streams, with multiple SSRCs, should not send RTCP reports for its own media, and should pick a single SSRC to use when sending reports on other media. I agree that this would save a small amount of bandwidth, but I think the savings are negligible, it complicates the monitoring model, and so is a mistake. We talk about this in draft-westerlund-avtcore-multiplex-architecture-00 (Section 9, in particular).
>> Cheers,
>> Colin
> --
> Jonathan Lennox
> _______________________________________________
> rtcweb mailing list

Colin Perkins