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

[Harald Alvestrand <[e-mail]>]

On 09/05/11 14:03, Magnus Westerlund wrote:
> 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.
Looking forward to it.
>> - 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.
Yes, the application needs to adapt. That's an area where I expect 
applications to differ, and the successful ones will be the ones that 
adapt better.
>> - 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.
Yes, the application needs to consider all the factors when negotiating.
The typical challenging scenario I see is a 4-way call with 3 
participants on the same high speed network and 1 participant calling in 
from a 3G phone. If the meeting is not called primarily for the guy on 
the phone, the 3 other participants might want to see each other in full 
HD and listen to each other using wideband codecs; the 4th one has to 
make a reasonable apportioning of his bandwidth.
> 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.