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

On 7 Sep 2012, at 16:08, Harald Alvestrand wrote:

> On 09/08/2012 12:49 AM, Tim Panton wrote:
>> 
>> 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.
> I don't know - my experience with object models is that if two people independently write an object model for something, there's always some assumption that doesn't match.

True, unless it is a well documented and designed object model that everyone agrees upon.

> 
> We already have a representation of an object model - it's called SDP. And we all map to it. More than one "canonical representation" leads to interesting effects - in email gateways, we used to call this the "3-body problem".

I think this is where we diverge - I can't see (however hard I try) SDP as an object model. (nor does it have the other properties I mentioned above). WebRTC could treat the
browser object model as canonical, and the SIP world can treat SDP as canonical. Somewhere we'd need to convert between the 2.


> 
> BTW - for the case that uses no relay (assuming that you've managed to find a PSTN gateway that can live without a relay in front of it), I'd be delighted if you could point out the pieces of Chrome's SDP that the PSTN gateway needs to have mangled for it before communication can happen.

I know of no PSTN gateway that does the chrome flavour of ICE, so we always need a relay - but only for 'de-icing' The SRTP travels just fine after that.

I'll try to work through our code and submit a bug report to the chrome team detailing our findings.

> 
> When a relay is involved, the 2 configurations are different, so it seems natural that the SDP will be too.

Different, yes, but only by the amount indicated by the relay. 
Typically we go from 54 lines of chrome SDP to <18 lines in our re-write.

>