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

[Harald Alvestrand <[e-mail]>]

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.

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?

                     Harald