Re: [RTW] [dispatch] RTCWEB I-D with thoughts on the framework
I agree to large parts of the document, and I think that the section on interoperability with existing VoIP gear brings up important aspects. However, I am not completely comfortable with a couple of things: * The application would be responsible for rate adaptation, but what is the incentive for the application developer to do something that is fair to other applications or users? I would prefer that this is part of the browser (and with the auto update feature most browsers use the update cycles could be short anyway) * Are you suggesting that the <video> (and consequently also the <audio>) tag should not be used? I don't think this is a good idea. Since they are accepted and used by the web community we should use them also for RTC-Web rather than trying to invent something new. --Stefan
-----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: den 8 februari 2011 15:49 To: 'DISPATCH list' Subject: [dispatch] RTCWEB I-D with thoughts on the framework
Some of my colleagues from Skype and I have put together a draft which gives our thoughts on the scope of the protocols and functionality for enabling browser RTC. I've just submitted the draft, which you can find here:
http://www.ietf.org/id/draft-rosenberg-rtcweb-framework-00.txt
Some of the key points:
* keep it minimal * APIs for controlling behaviors of the various media components, with defaults for those that dont care * no SIP or Jingle; leave that to proprietary over websockets/HTTP * no ICE - just STUN. ICE can be a javascript library.
Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
On 2/11/11 8:25 AM, Stefan Håkansson LK wrote:
* Are you suggesting that the<video> (and consequently also the<audio>) tag should not be used? I don't think this is a good idea. Since they are accepted and used by the web community we should use them also for RTC-Web rather than trying to invent something new.
I don't think any group in the IETF is in a position to standardize HTML semantics. We're defining what goes on the wire. The stuff that goes inside the browser has to come from W3C. /a
Exactly my point. //S
-----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: den 11 februari 2011 15:46 To: Stefan Håkansson LK Cc: Jonathan Rosenberg; rtc-web@alvestrand.no; 'DISPATCH list' Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework
On 2/11/11 8:25 AM, Stefan Håkansson LK wrote:
* Are you suggesting that the<video> (and consequently also the<audio>) tag should not be used? I don't think this is a good idea. Since they are accepted and used by the web community we should use them also for RTC-Web rather than trying to invent something new.
I don't think any group in the IETF is in a position to standardize HTML semantics. We're defining what goes on the wire. The stuff that goes inside the browser has to come from W3C.
/a
* 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.
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@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Timothy B. Terriberry Sent: den 23 februari 2011 09:03 Cc: Jonathan Rosenberg; rtc-web@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
participants (3)
-
Adam Roach -
Stefan Håkansson LK -
Timothy B. Terriberry