[RTW] [dispatch] RTCWEB I-D with thoughts on the framework
Stefan Håkansson LK
stefan.lk.hakansson at ericsson.com
Wed Feb 23 10:24:59 CET 2011
I agree fully, the API(s) must provide enough info so that a proper negotiation can take place. This is one feedback I intend to give to the W3C charter.
> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no
> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Timothy
> B. Terriberry
> Sent: den 23 februari 2011 09:03
> Cc: Jonathan Rosenberg; rtc-web at alvestrand.no; 'DISPATCH list'
> Subject: Re: [RTW] [dispatch] RTCWEB I-D with thoughts on the
> framework
>
> >> * no SIP or Jingle; leave that to proprietary over websockets/HTTP
>
> One of the issues that will have to be solved, even without
> SIP or Jingle in the browser, is codec negotiation. If the
> webserver is using SIP on the back-end, then it needs to know
> about the clients' codec support in enough detail to enable
> the SIP negotiation process. Your simple example sends no
> details at all about the clients' supported codecs, which I
> guess means the server can only assume support for the MTI codecs.
>
> Maybe this is a question for the W3C, and not IETF, but I
> don't think the existing canPlayType API is sufficient. It
> doesn't give a guarantee more promising than "probably", and
> doesn't allow for negotiating specific codec parameters
> (e.g., bitrate, sampling rate). For example, even with an MTI
> codec like Opus, some devices with limited memory may not
> support stereo. Presumably these would not be devices capable
> of running a web browser, but they might be the one talking
> to the web browser, and the browser needs to know not to send
> them stereo frames.
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
More information about the RTC-Web
mailing list