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

Jonathan Rosenberg jonathan.rosenberg at skype.net
Sat Mar 12 17:59:10 CET 2011


To add a little more color here...

As Magnus has said, symmetric RTP is a consequence of firewalls and NATs,
but it is not driven solely by STUN. Without symmetric RTP, it is almost
impossible to utilize any kind of NAT traversal technique. Session Border
Controllers, for example, also rely on the usage of symmetric RTP in order
to operate. TURN requires it. Application-layer solutions, such as always
sending media to something like a PSTN gateway, also require it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist
jdrosen at skype.net                              http://www.skype.com
jdrosen at jdrosen.net                            http://www.jdrosen.net




On 3/7/11 5:08 PM, "Magnus Westerlund" <magnus.westerlund at ericsson.com>
wrote:

>Harald Alvestrand skrev 2011-03-07 14:32:
>> Having finished reading the rtp-usage draft, I am impressed. This is
>> good work, and will help a lot going forward.
>> 
>> One thing I want to check, because it seems that the only place that
>> says "Using ... is REQUIRED" rather than "Support ... is REQUIRED":
>> 
>
>It is primarily a question of inconsistent writing. It needs to be
>supported, but likely also forced to be used.
>
>This is one thing that needs to be tighten in the doc if it was to
>become a specification. Which features needs to be supported, and which
>needs to be always used, as there is a difference.
>
>
>> 5.3.  Symmetric RTP/RTCP
>> 
>>     RTP entities choose the RTP and RTCP transport addresses, i.e., IP
>>     addresses and port numbers, to receive packets on and bind their
>>     respective sockets to those.  When sending RTP packets, however,
>>they
>>     may use a different IP address or port number for RTP, RTCP, or
>>both;
>>     e.g., when using a different socket instance for sending and for
>>     receiving.  Symmetric RTP/RTCP requires that the IP address and port
>>     number for sending and receiving RTP/RTCP packets are identical.
>> 
>>     Using Symmetric RTP and RTCP [RFC4961] is REQURIED.
>> 
>> In the STUN-based firewall traversal scenario, STUN will discover a
>> <sender address/port, recipient address/port> at the sender that will
>> cause delivery of packets with a corresponding (not necessarily
>> identical) <sender address/port, recipient address/port> at the
>> recipient, and that the recipient can swap those addresses around and
>> have the packets delivered to the sender (the STUN connectivity check
>>is 
>> bidirectional). No guarantees are made for any other <sender
>> address/port, recipient address/port> pair, so non-symmetric RTP/RTCP
>> seems likely to fail.
>> 
>> Is this the (only) reasoning that led to this requirement?
>
>NATs and Firewalls are the core of the need for symmetric RTP. If they
>didn't exist, then knowing the source address and port for a packet
>would have less value. But today, then not using symmetric RTP leads to
>failure to communicate. There is simple no realistic option to not use it.
>
>> 
>> If so, should it be inserted into the document so that people can
>> reproduce the thinking? (and if there are other reasons, which I
>>haven't 
>> thought of, it might be good to document those too).
>
>Yes, we should add a bit of motivation and not only description why
>symmetric RTP is necessary.
>
>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
>----------------------------------------------------------------------
>_______________________________________________
>RTC-Web mailing list
>RTC-Web at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/rtc-web




More information about the RTC-Web mailing list