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@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net On 3/7/11 5:08 PM, "Magnus Westerlund" <magnus.westerlund@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@ericsson.com ---------------------------------------------------------------------- _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web