[RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)

[Elwell, John]

> -----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.

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.

John

> 
>                  Harald
> 
>