Re: [rtcweb] New topic: Model for multi-unicast support

Colin Perkins <> Tue, 06 September 2011 11:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B164821F8640 for <>; Tue, 6 Sep 2011 04:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.501
X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d16MquIYgsmp for <>; Tue, 6 Sep 2011 04:11:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D56921F855F for <>; Tue, 6 Sep 2011 04:11:17 -0700 (PDT)
Received: from ([]) by with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R0taR-0001zr-ka; Tue, 06 Sep 2011 11:13:03 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <>
In-Reply-To: <>
Date: Tue, 06 Sep 2011 12:13:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Harald Alvestrand <>
X-Mailer: Apple Mail (2.1084)
Cc: "" <>
Subject: Re: [rtcweb] New topic: Model for multi-unicast support
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Sep 2011 11:11:19 -0000

On 1 Sep 2011, at 12:57, Harald Alvestrand wrote:
> In the thread about draft-perkins-rtcweb-usage, the following exchange took place:
>>> >  Speaking for some implementors of the WEBRTC API, it's also clear that there's a significant cost to implementing the multiway RTP session concept - both in code complexity and API complexity. I think this warrants more discussion, where all 3 outcomes should be on the table:
>>> >  >  - We recommend doing multi-unicast with a shared RTP session only
>>> >  - We recommend supporting both shared and split RTP sessions for multi-unicast
>>> >  - We recommend doing multi-unicast with split RTP sessions only
>>> >  >  We should probably do this in a new thread.
>> Indeed; I'd be interested to know what complexity you're seeing. I would have expected the shared RTP session model to decrease complexity, since the RTP layer can be oblivious to the detail of the underlying transport connections, and wouldn't have to worry about tracking SSRC and payload type mapping separately for each session.
> I think this is a topic that deserves its own thread.
> The context is use case 4.2.7, "Multiparty video communication", the one without a central server; each party sends its video and audio streams to all participants in the meeting directly.
> One can imagine supporting this with a single RTP session, where all video streams are equal and sent with the same SSRC to all participants, all participants send receiver reports (RRs) about all the SSRCs they see to all other participants, and all senders send their SR reports to all participants.
> Now, this has implications for both API design, service design and protocol operation.
> API: The model presented is no longer "this object is your connection to A; that object is your connection to B". There has to be a representation of your "cloud" as a multidestination object, with procedures for adding to and subtracting from the list of participants. Error reporting must include which participant the error relates to.

Agree. This is the model RTP suggests for a session: a group-communication cloud, with the details of whether that's implemented as a single point-to-point flow, a centralised mixer, multi-unicast, or a multicast group being hidden below the RTP layer. 

You can model transport layer flow as its own RTP session, but then you get into coordination issues between the RTP sessions. Also, it doesn't solve the issue that "your connection to B" is not necessarily meaningful,  it B is a reflector that expands to multiple participants.

> Service: The requirement for perfect equality means that you cannot allow any party to adapt its presence to what it can receive; for instance, as I understand it, nobody can drop the video and only be an audio participant, because that would break the model of equality, rendering sender reports meaningless to some participants.

This is why audio and video are usually sent in separate RTP sessions. 

> Protocol: The requirement for a single agreed RTCP bandwidth means that this bandwidth has to be computed for the session as a whole - with the simplistic answer being 5% of the lowest common denominator.

This is a problem if you have flows with significantly different rates in the same RTP session, yes.

> In contrast, if one chooses the multiple-RTP-session approach:
> - the API retains its "one object, one destination" orientation.
> - the degree to which service is equal to all parties is a matter for the application, not the protocol
> - rate adaption, choice of RTP bandwidht and so on can be negotiated on each link individually
> I think this forum needs to pick one of the options in my initial note, and design its protocols and APIs accordingly.
> Thoughts?

I'm not sure it's a simple as picking one model or the other. There are some scenarios where the model of a single RTP session across multiple transport-layer flows makes a lot of sense (e.g., centralised conferences using a mixer, for the reasons described in RFC 5117), but in other cases there are stronger arguments for treating each transport layer flow separately (e.g., multi-unicast, if you're multiplexing audio and video in a single session, and sending only a subset of media flows to some of the participants). A better model might be to provide an appropriate RTP session API, plus a higher layer API that manages the grouping of RTP sessions into a single multimedia conference. 

This would also make legacy interoperability easier, since there are legacy systems that use both the single RTP session and multiple RTP sessions models.


Colin Perkins