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

[Magnus Westerlund <[e-mail]>]

On 2011-09-03 07:31, Stefan Håkansson LK wrote:
> Harald 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.
> 
> To me an RTP session was connected to a port/IP address, so I don't
> understand how this could be one session (the destination port/IP
> would be different for each stream). (I expect to be corrected!) Is
> multicast assumed?
> 

No, no multicast assumed. This uses the fundamental definition of an RTP
session as a joint SSRC space as the basis. What Harald talks about here
is what I call multi-unicast, where one basically configure a
replication module under the regular RTP/RTCP stack processing to send
out each RTP and RTCP packet to multiple destinations using unicast. All
incomming traffic would preferably be received on a single port (pair)
from the other peers.


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]
----------------------------------------------------------------------