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