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: Sat, 08 Sep 2012 10:04:01 +0200
Message-ID: <504AFBF1.1050801@alvestrand.no>
To: Tim Panton <thp@westhawk.co.uk>
CC: public-webrtc@w3.org
On 09/08/2012 01:27 AM, Tim Panton wrote:
> 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.
Yes - the time it's taken from the code complete to standards compliant 
ICE showing up in chrome is an embarassment to me....
> 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.
I know we produce extra stuff for the extra features of PeerConnection - 
if that can be safely ignored, that's OK; that's the SDP extension model.

If there's anything that a responder chokes on, or when we require stuff 
in the response that isn't required by the SDP spec or the functions we 
require (like ICE), that's definitely stuff we should fix. (I think 
there's some of that.)

Looking forward to your report!
Received on Saturday, 8 September 2012 08:04:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:33 UTC