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

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.

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

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.

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