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

[Magnus Westerlund]

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