[RTW] Gateways and does anyone think "H.264 for ever"?

[Henry Sinnreich]

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 at siemens-enterprise.com>
wrote:

>  
> 
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald at alvestrand.no]
>> Sent: 07 January 2011 14:25
>> To: Elwell, John
>> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;
>> rtc-web at alvestrand.no; dispatch at 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 at alvestrand.no]
>>>> Sent: 07 January 2011 13:07
>>>> To: Elwell, John
>>>> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;
>>>> rtc-web at alvestrand.no; dispatch at 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
>>