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