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

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

From: Tim Panton <thp@westhawk.co.uk>
Date: Fri, 7 Sep 2012 15:49:32 -0700
Cc: Matthew Kaufman <matthew.kaufman@skype.net>, Göran Eriksson AP <goran.ap.eriksson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <891DFA55-7A7B-4AE6-BF8B-99B528C73FA1@westhawk.co.uk>
To: Harald Alvestrand <harald@alvestrand.no>

On 7 Sep 2012, at 02:10, Harald Alvestrand wrote:

> On 09/07/2012 12:13 AM, Matthew Kaufman wrote:
> 
> 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?

I think this last statement may be true, at least with the current Chrome SDP as a guide.
Since no PSTN gateway I have tried will consume chrome's SDP
we:
1) ask chrome for SDP
2) Parse it
3) create some sort of object model
4) extract the 'relevant' objects (possibly setting up a relay or 2)
5) generate PSTN style simple SDP
6) send that on to a PSTN gateway 

(and Duplicate the process in reverse to pass a 'complex' answer back to chrome.)

Given that under the hood Chrome must have an object model of the available devices/networks/codecs that closely 
matches what we make in 3) it may well be simpler and more reliable to expose that and skip straight to step 4.

Tim.
 
Received on Friday, 7 September 2012 22:50:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 22:50:04 GMT