Though gateways are a key component in the web architecture and critical indeed for connectivity with other networks, I believe the scope as outlined here by Harald is the correct first step. As for interoperability at the video codec level, several items have to be balanced 1. The benefits for users (includes cost and performance) first and foremost 2. Give a chance to new and free codec technologies such as VP8 or Theora 3. Interoperability with existing H.264 based systems Or does anyone think "H.264 for ever"? Thanks, Henry On 1/7/11 11:38 AM, "Elwell, John" <john.elwell@siemens-enterprise.com> wrote:
-----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 07 January 2011 14:25 To: Elwell, John Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba; rtc-web@alvestrand.no; dispatch@ietf.org Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
On 01/07/11 14:41, Elwell, John wrote:
-----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 07 January 2011 13:07 To: Elwell, John Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba; rtc-web@alvestrand.no; dispatch@ietf.org Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
On 01/07/11 10:56, Elwell, John wrote:
I also agree that codecs such as H.264 AVC need to be considered, because of interworking with non-RTC-web users, conference bridges, etc.. An important part of the proposed charter is: "* interoperate with compatible voice and video systems that are not web based" This can turn out to be seriously problematic if we don't constrain it carefully - when we wrote this, my thinking was that it meant "if devices send and receive media in formats that we support, and the setup is performed in a reasonable way through intermediaries,
we should be
able to send media directly to them".
I see the use case that we *have* to support as the browser-to-browser use case. If we are able to support other use cases too, that is a good thing, but very much a lower priority to me. Opinions may differ. [JRE] I disagree. I believe the ability to work with non-RTP-web users is equally important. Take enterprises for example - they don't want a flag day when every user changes to RTP-web at the same time - they need to migrate users at a convenient pace. We have the same situation today when people migrate off PABXes onto either VOIP-phones or onto mobile phones; the answer in those cases seems to be gateways. Why wouldn't that work in this case? One of the benefits of reusing existing protocols such as RTP is that interworking with non-RTP-web users and other equipment (such as MCUs) should be feasible. But this also means using appropriate codecs, to avoid having to insert transcoders. Can you be more specific about what devices you're thinking of, and how many of them there are? In particular, which devices do you expect to see that don't support RTCWeb, but do support STUN? [JRE] It is true that a lot of existing devices do not support STUN, and rely on intermediaries (SBC) to achieve NAT traversal. However, those intermediaries could be made to mediate between RTC-Web devices and other devices. Getting those intermediaries to handle STUN on the RTC-Web side is feasible - getting them to do transcoding, particularly for video, is an entirely different matter. So in other words, it depends how much functionality we are prepared to put into the gateway.
John
Harald