Fwd: I-D Action:draft-perkins-rtcweb-rtp-usage-00.txt
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
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? Harald
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@ericsson.com ----------------------------------------------------------------------
On 3/7/2011 6:38 AM, 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.
This seems like my list of three choices, only restated more clearly and with some alternate opinions. This seems like a good time to note that I have, since posting my list, independently found additional reasons to prefer #1, even though the NAT/firewall traversal (and state) overhead is higher. This is in addition to legacy interop, which is also important. (Though not actually that critical for audio-only interoperability, as there will likely only be one RTP stream and thus would only be one ssrc if one chose to use ssrc for the muxing) Matthew Kaufman Matthew Kaufman
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@ericsson.com ----------------------------------------------------------------------
Harald Alvestrand skrev 2011-03-08 13:10:
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.
Not strictly, I would say that both using unique 5-tuples and an explicit multiplexing layer is fine from RTP perspective. Explicit multiplexing layer is already used, for example when sending RTP over RTSP's signalling TCP connection [RFC2326].
The alternatives involve modifying protocols that are not otherwise within the scope of this working group.
Well, the charter isn't approved yet. And I think there will be need for a RTC-WEB WG to in some cases agree that some work is needed. Then the question of where can be raised, within the WG, in some other WG or in a new WG. Sure, this must be weighted against the time it takes to complete the work. An explicit multiplexing layer needs not be complex if one keeps the requirements simple. Thus if it is considered necessary then I think it can be developed in the RTC-web WG. If using different UDP flows are the preferred way, then that comes at a different set of trade-offs. Airing these trade-offs and gaols are likely the right way of achieving at least rough consensus going forward here. I want to be clear that I have not yet any strong view on what the right choice is here. Except that I don't want to redesign RTP now and for this. Secondly, I want to ensure that RTP sessions can be used, but that is just of question of ensuring that there some explicit indicator of what RTP session a particular packet belongs to. 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 ----------------------------------------------------------------------
A few comments on this. One of the primary arguments in favor of UDP/port muxing of sessions is backwards compatibility with existing RTP-based endpoints. I think it is important to point out that - even though backwards compatibility with existing RTP-based equipment is clearly desired - it is not yet clear that it is achievable within the security context of the browser. If we discount backwards compatibility, there are two high level reasons to do UDP muxing. One is to enable reuse of existing specifications (FEC for example) and the other is because of functional benefits (of which I see only one really - usage of differing network paths for different session types). The multi-path argument to me is really the compelling one. I'm in favor of giving the maximum flexibility for application designers, and this is clearly a point of flexibility. However, I do think we need a multiplexing layer. Being able to send application data between the browsers directly will have many uses. Games have been mentioned as one use case; even for a pure voice and video calls the usage of p2p messaging will prove invaluable for enabling innovation in the area of real-time feedback and control mechanisms. The browser environment will make these new use cases easy to deploy, and I think we'll see a lot of them. I think we're also going to see a LOT of video usage. At Skype, around 40% of our Skype-to-Skype calls are video. For these reasons, I think we want to include a multiplexing mechanism. Besides adding setup delays because of the need to run more port opening, it increases network traffic, and most importantly, increases the consumption of port bindings on the NAT. I think we need to start treating port bindings as a commodity which will grow scarcer over time. Indeed, I'd go so far as to say this - designing something new like browser RTC - without enabling operation on a single port in order to conserve NAT bindings - is irresponsible and potentially harmful to the Internet. Its usage should be strictly for backwards compatibility or for the cases in which it is a necessity for functional reasons (e.g., multiple network paths). Putting these together, it is my view that we should allow for IP/port based demux of differing sessions, but we should also design a demux layer that can enable everything on a single IP/port. And furthermore, the latter should be the preferred technique for browser-to-browser communication in the base case. Thanks, 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/9/11 5:20 PM, "Magnus Westerlund" <magnus.westerlund@ericsson.com> wrote:
Harald Alvestrand skrev 2011-03-08 13:10:
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.
Not strictly, I would say that both using unique 5-tuples and an explicit multiplexing layer is fine from RTP perspective. Explicit multiplexing layer is already used, for example when sending RTP over RTSP's signalling TCP connection [RFC2326].
The alternatives involve modifying protocols that are not otherwise within the scope of this working group.
Well, the charter isn't approved yet. And I think there will be need for a RTC-WEB WG to in some cases agree that some work is needed. Then the question of where can be raised, within the WG, in some other WG or in a new WG. Sure, this must be weighted against the time it takes to complete the work.
An explicit multiplexing layer needs not be complex if one keeps the requirements simple. Thus if it is considered necessary then I think it can be developed in the RTC-web WG. If using different UDP flows are the preferred way, then that comes at a different set of trade-offs. Airing these trade-offs and gaols are likely the right way of achieving at least rough consensus going forward here.
I want to be clear that I have not yet any strong view on what the right choice is here. Except that I don't want to redesign RTP now and for this. Secondly, I want to ensure that RTP sessions can be used, but that is just of question of ensuring that there some explicit indicator of what RTP session a particular packet belongs to.
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
I agree that a mux/demux layer will have high utility. CLUE has not yet reached a decision about how to transport the multiple streams it needs - but such a mux layer would IMHO be a very logical choice. Is this something which would be done in avtcore? Peter Musgrave On 2011-03-12, at 12:28 PM, Jonathan Rosenberg wrote:
Putting these together, it is my view that we should allow for IP/port based demux of differing sessions, but we should also design a demux layer that can enable everything on a single IP/port. And furthermore, the latter should be the preferred technique for browser-to-browser communication in the base case.
On Mar 12, 2011, at 5:28 PM, Jonathan Rosenberg wrote:
Putting these together, it is my view that we should allow for IP/port based demux of differing sessions, but we should also design a demux layer that can enable everything on a single IP/port.
Agree. It saves NAT resources, traversal effort, etc. to be able to multiplex, but for legacy compatibility and other use cases it is mandatory that we also support synchronized real-time audio/video on separate ports.
And furthermore, the latter should be the preferred technique for browser-to-browser communication in the base case.
Agreed, for resource utilization / "good for the Internet" reasons. Matthew Kaufman
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": 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? 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). Harald
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 ----------------------------------------------------------------------
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
Hi, I agree with Jonathan. Symmetric RTP is assumed for a number of functions (not only NAT traversal). Regards, Christer ________________________________________ From: rtc-web-bounces@alvestrand.no [rtc-web-bounces@alvestrand.no] On Behalf Of Jonathan Rosenberg [jonathan.rosenberg@skype.net] Sent: Saturday, March 12, 2011 6:59 PM To: Magnus Westerlund; Harald Alvestrand Cc: rtc-web@alvestrand.no Subject: Re: [RTW] Symmetric RTP/RTCP (Re: Fwd: I-D Action:draft-perkins-rtcweb-rtp-usage-00.txt) 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
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
participants (6)
-
Christer Holmberg -
Harald Alvestrand -
Jonathan Rosenberg -
Magnus Westerlund -
Matthew Kaufman -
Peter Musgrave