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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 07 Sep 2012 11:10:10 +0200
Message-ID: <5049B9F2.4020000@alvestrand.no>
To: Matthew Kaufman <matthew.kaufman@skype.net>
CC: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 09/07/2012 12:13 AM, Matthew Kaufman wrote:
> 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.
I totally don't agree here.

I believe all participants have a ranking of the use cases in their own 
mind. That ranking is not made explicit because it's not been needed so 
far - the day we conclude that a particular use case or requirement is 
*impossible* to satisfy under a given proposal, we'll have to address 
the issue of whether we change the proposal or remove the use case or 
requirement.

So far, we've not encountered that situation. People seem to think that 
it's possible to achieve all the listed scenarios using the present 
approach - even if some scenarios require more JS code and API points 
than others.
>   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.
(separate issue)

Matthew, if I try to map this statement to the current two proposed 
approaches, you lost me again.

You seem to be arguing that the CU-RTC approach is superior for 
gatewaying to the PSTN because it doesn't use SDP, it uses a completely 
novel means of controlling the aspects of transmission that matter to 
gatewaying.

This is in contrast with PeerConnection, which, like all PSTN gateways I 
know of, uses SDP, which gives a description of the transmission 
configuration in a way that all implementors of PSTN gateways are 
already familiar with - including long experience in how to deal with 
SDP produced by other SDP implementations, with lesser or greater degree 
of standards conformance.

So by NOT using the session description tool most familiar to PSTN 
gateway implementors, we're making it EASIER to interwork with PSTN 
gateways?
>
> 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".
I'd like to see the context for your quotation. It doesn't seem like 
something I've heard anyone say.
Received on Friday, 7 September 2012 09:10:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 09:10:41 GMT