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 UTC