Re: [rtcweb] Media negeotiation and signalling archatecture

[Matthew Kaufman <[e-mail]>]

On Jun 29, 2011, at 8:07 AM, Cullen Jennings wrote:

> 
> One of the complicated architectural issues for this WG is what path the signaling information gets passed over, and in the parts of that that path that need to be standardized, what does the signaling information looks like. To help get discussion going on that, I have described 3 models of how the information could flow in the some pictures in the following PDF. 
> 
> http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/WikiStart/RTCWeb-Signaling.pdf
> 
> I split these up into 3 models that I call High, Mid, and Low based on the path the signaling information goes. There has been a fair amount of discussion of High and Mid models in the past in this WG thought pretty much no discussion of the Low model. The interesting things is that when I look at what is getting implemented and prototyped, a lot of it is the low model. 

I think this deck is a bit in two ways.

First, in the first slide you say (and I agree) that we agree that if there's >1 web server we don't care how they talk to each other (I'm suspecting something like SIP in most cases)... but then in the "high path" you say it "gets complicated to define what happens on the orange line"... but I disagree here. If we agree that it is SIP and SDP on the orange line then clearly the things that are needed to do NAT traversal (ICE) and codec negotiation are all able to be carried in SDP. As another alternative you could simply carry something that the browser understood natively on that orange path. 

In fact in the "low path" slide, you talk about the current Chrome implementation and the WhatWG proposal, but both of those are actually suggesting transporting a JSON blob via the "high path" to do the ICE negotiation... and there's no reason to believe that if you can send the blob needed to do ICE that you couldn't also do the media type negotiation via the same path.

Second, the "high path" is still needed to do the actual call signaling... you can't even get the two browsers connected to the two different web services interested in setting up a session using ICE if there hasn't been communication over the "high path" to set up a call.

Matthew Kaufman