Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <4E5F7344.4060803@alvestrand.no>
Date: Tue, 6 Sep 2011 12:13:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D9019B2-B788-422E-82AC-03FB3585A743@csperkins.org>
References: <4E5F7344.4060803@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New topic: Model for multi-unicast support
Precedence: list

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.
>=20
> 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.
>=20
> 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.
>=20
> Now, this has implications for both API design, service design and =
protocol operation.
>=20
> 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.=20

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.=20=


> 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:
>=20
> - the API retains its "one object, one destination" orientation.
>=20
> - the degree to which service is equal to all parties is a matter for =
the application, not the protocol
>=20
> - rate adaption, choice of RTP bandwidht and so on can be negotiated =
on each link individually
>=20
> 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.=20

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





--=20
Colin Perkins
http://csperkins.org/