W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Re: Goals of this work (Re: Poll for preferred API alternative)

From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Date: Fri, 7 Sep 2012 01:33:32 +0200
To: Matthew Kaufman <matthew.kaufman@skype.net>
CC: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <9298CC88-5DCF-4E6A-A3F0-76BE95DEF524@ericsson.com>


7 sep 2012 kl. 00:13 skrev "Matthew Kaufman" <matthew.kaufman@skype.net>:

> Yes, I believe that *all* of the use cases presented in the use case document (and any new ones that we come up with) should be addressed by the W3C API and IETF protocols with equal priority. So that, for instance, a solution which is slightly hard for browser-to-browser and equally hard for browser-to-PSTN would be preferred over one that is slightly easier for browser-to-browser and extremely difficult for browser-to-PSTN.
> 
> This is why I have raised objection to comments like "we'll never need to modify the SDP anyway because that isn't needed for browser-to-browser cases, and so it doesn't matter how difficult that might be".

A concern I have with getting rid of SDP is that it will not help "interoperability" with the mobile radio link configuration, which in part uses SDP based descriptions of the media
also for browser to browser (that is assuming one would want to use LTE QoS for Webrtc).

SDP may not be the ultimate design and there are indeed challenges but it is a common denominator for the api, what is on the wire and in solutions for configuring 
link layer and media end points. Dropping SDP and not even having an industry standard for it will not make it easier to fit the different parts together.

As to Your view on "slightly hard" I am not sure if You mean the web app developer effort or effort to implement in the browser. Assuming You mean developer effort, the difference between us may lie in the view on the different ways the web platforn will(hopefully) support realtime communication in the future- I have had in mind a discussion in tve What Wg list about telephony interworkng, namely that we have in some browsers the Tel URL which launches the native tel app. And now with the SysApps work- which You refer to in Your API description I believe- there is a Telephony API which as one of its providers can have a full PLMN stack, e.g in the modem. This would of course orovide for seamless interworking with PLMN/PSTN even codec, :-)

What is Your thinking about the SysApps and the Telephony API and its role in providng RTC capabilities in the Open Web Platforn?

Regards
Göran






> 
> Matthew Kaufman
> 
> -----Original Message-----
> From: Göran Eriksson AP [mailto:goran.ap.eriksson@ericsson.com] 
> Sent: Thursday, September 06, 2012 2:50 PM
> To: Matthew Kaufman
> Cc: Harald Alvestrand; public-webrtc@w3.org
> Subject: Re: Goals of this work (Re: Poll for preferred API alternative)
> 
> 
> 
> 6 sep 2012 kl. 23:37 skrev "Matthew Kaufman" <matthew.kaufman@skype.net>:
> 
>> This of course is NOT reflected in the use case document, which prioritizes all use cases, including PSTN interworking and other legacy software interworking equally, as I believe they should be.
> 
> That the main focus has been on securing inivation on tve webplatform, that is between interoperable browsers, has never been in doubt in my eyes (as one of the editors)- the interworking use cases are there as part of the ambition to make interworking usage as steamlined as possible, but not at the expense of the solution for browser to browser usage.
> 
> Do I understand it right that U are of another opinion namely that for instance telephony network interworking use cases are as important for tve work in w3c and ietf?
> 
> Thanks
> Göran
> 
Received on Thursday, 6 September 2012 23:33:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 23:33:59 GMT