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

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
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.


Received on Friday, 7 September 2012 22:50:03 UTC