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

[Magnus Westerlund <[e-mail]>]

On 2011-09-01 13: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.
> 
> 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.
> 
> 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.

I agree with the issues of having it being represented like this. And so
far I don't think I have identified a use case that requires a joint RTP
session for the multi-unicast case.

The centralized mixer use case has certain benefits for a joint RTP
session, but there you can apply a RTP mixer to enable difference in
service on what being delivered and in what quality to each participant.

> 
> In contrast, if one chooses the multiple-RTP-session approach:
> 
> - the API retains its "one object, one destination" orientation.

I mostly agree, there are a few thinks I think it is important to
discuss here. And I will have slides on this relation ship for Thursday.

> 
> - the degree to which service is equal to all parties is a matter for 
> the application, not the protocol

Yes, it is not dictated by the protocol, but I don't think the
application will be in full control either. It can indicate what is
desired, but local and network resources needs to be included in the
consideration.

> 
> - rate adaption, choice of RTP bandwidht and so on can be negotiated on 
> each link individually

Yes, but there is clearly a need to take the combinations into account.
An issue is clearly that one need to divide the available uplink
bit-rate between the streams one needs to send. Another issue is that if
one has three peers, and each request a different resolution one may not
have the computing resources to encode three versions, and may have to
limit it too two resolutions, where one is delivered to two peers.

Also the need for joint identifiers between peers for streams that are
the same source but may vary in representation likely needs to be kept
between the different legs. Otherwise the application logic is

> 
> I think this forum needs to pick one of the options in my initial note, 
> and design its protocols and APIs accordingly.

Sorry, I don't know which initial note you are referencing.

But I do think we need to agree on how we handle RTP sessions in
relation to the relevant API constructs and what binding between API
resources that are needed to allow the lower layer to correctly keep
semantics.

We will have some opportunity to discuss this on Thursday in the Interim
meeting.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------