[RTW] RTP Session Multiplexing (Re: Fwd: I-D Action:draft-perkins-rtcweb-rtp-usage-00.txt)

[Harald Alvestrand]

Short summary, to see if I understand Magnus correctly:

If we want to use RTP over UDP as it currently stands, we have to 
multiplex on port number. If one sender sends two media streams to one 
recipients, at least one part of the <sender ip:port>:<recipient 
ip:port> 4-tuple has to be different.

The alternatives involve modifying protocols that are not otherwise 
within the scope of this working group.

I think we have a good answer, at least for our first iteration....

               Harald

On 03/07/11 15:38, Magnus Westerlund wrote:
> Harald Alvestrand skrev 2011-03-07 13:44:
>> On 03/07/11 11:19, Magnus Westerlund wrote:
>>> Hi,
>>>
>>> Colin Perkins, Joerg Ott and I have created this draft about RTC-WEB's
>>> usage of RTP. Feedback and discussion are most appreciated.
>>>
>>> Cheers
>>>
>>> Magnus
>>>
>> Thank you, Magnus!
>>
>> Changing the subject line to take one topic at a time:
>>
>> Section 2.1 is stated almost totally in the negative: "because of THESE
>> considerations, do NOT do that". I have problems parsing that.
>>
>> In the RTCWEB situation, we will commonly have the situation (crummy
>> ASCII art alert):
>>
>>     Participant  ---->   FW  ---->  FW ---->  Participant
>>
>>       ----------------->  Audio -------------->
>>       ----------------->  Video --------------->
>>      ------------------>  Other --------------->
>> <--------------- Audio -------------------
>> <--------------- Video ------------------
>> <--------------- Other --------------------
>>
>> (I am too lazy to add RTCP into the picture)
>>
>> Due to the cost of firewall transition mechanisms, holding many port
>> pairs open is an expensive proposition, so the issue has been raised.
>>
>> Exactly what assignment of streams to<address, port, SSRC, PT>  is the
>> draft proposing that we use?
> The SSRC and PT have well established purposes, SSRC is used for media
> sources, like different cameras or microphones. For multi-party
> communication (especially with central node) they are also needed to
> keep track of the different particpants sources.
>
> When it comes to separating the RTP sessions from each other we are
> actually not suggesting how to solve it. Only trying to say that it
> needs to be solved.
>
> The alternatives I see are:
>
> 1. Use UDP ports as currently done today. Yes, requires to perform NAT
> traversal for several UDP flows. But the question is how big the cost is
> when you already have a good RTT measurement and know which candidate
> pair that worked previously. Without any packet loss that aren't
> introduced by lack of FW and NAT state, this should be possible to
> achieve within 2 RTT + some 20 ms of guard time. Yes, that also assumes
> that you learned your public address and port for this socket before.
> But if that is needed also then 3 RTTs plus some.
>
>
> 2. Add a multiplexing layer. Stick a shim between UDP and the payloads
> in all cases. A single byte should suffice from a number of streams.
> Moves certain scheduling and transmission buffering choices above the
> socket level. Deep packet inspection and QoS will be hurdles.
>
> 3. Change RTP to cope with multiplexing. This is a major effort I think
> as it basically redesigns several aspects of RTP and RTCP. It also hurt
> interoperability with any normal RTP clients. Does also not work with
> any datagram or byte stream service that you want to multiplex also on
> the same UDP flow.
>
> Needs discussion as far as I see it.
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------
>