Subject: [rtcweb] Media negeotiation and signalling archatecture

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Jun 2011 09:07:53 -0600

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. 

It certainly possible to support more than one of these but I'm interested in the pro and cons of all these but from my point of view, one of the key issues is how hard is for people to use. If you look at what things have succeeded in HTML, it is typically the things that in there simplest form provide a very simple interface to use them. Yes, they might have a more complex form that allows richer control but the basics are simple. Take the HTML5 video tag for streaming video media for example. There are zillion things that could have been passed and controlled to this flag yet the proposals that one out were the ones that provided something that was incredibly simple to use. Another example is the iPhone interface to make a phone call from the browser has been very successful from an adoption point of view.

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 29 Jun 2011 09:16:16 -0700

> http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/WikiStart/RTCWeb-Signaling.pdf

The computer-mouse with built-in printer provides proof of technology in 
usage. The graph paper delegates units of space, bits. I'm surprised 
people have not used the optic-computer-mouse to align what they draw on 
graph paper (to have the process in reverse from screen to paper).

Scalability, so scientists find the scalars and business patents the 
flow to the engineers. Software patents are not bad for such 
standardization, yet this begs the question if low, medium, and high are 
patentable in real-time based on localization. Should we consider the 
word throttle as one scalar? "Materials" is an easier word as 
macro-economies and then micro- prefix means essentially low in such 
relation, without materials.

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 29 Jun 2011 16:23:27 -0700

> 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…

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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 30 Jun 2011 08:41:18 +0200

A couple of quick comments:

* The last slide now says that WhatWG proposal is low path; this is not true. The WhatWG proposal as I read it is mute on how the SDPs are exchanged, it just hands those SDPs over to the application (though high path is indicated: "Communications are coordinated via a signaling channel provided by script in the page via the server, e.g. using XMLHttpRequest.")

* Notably the WhatWG PeerConnection API does allow both high path and low path. You can exchange all the SDPs over the server as the spec indicates, but if your application initially only sets up a PeerConnection with no media Streams, there will be a peer-to-peer datagram channel available. It can be used by the web app to exchange the SDPs for media negotiation when you add Streams (then we have a separate thread on that datagram channel - is it reliable or not - or would the app have to add reliability)

* Even if you use the low path approach you still need a high path available all the time. It is needed to exchange candidates so that ICE can be used to open the low path - and this would have to be done at the start of the session and every time you do a NIC change (a use case you added BTW!)

Stefan

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Cullen Jennings
>Sent: den 29 juni 2011 17:08
>To: [email-masked]
>Subject: [rtcweb] Media negeotiation and signalling archatecture
>
>
>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. 
>
>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. 
>
>It certainly possible to support more than one of these but 
>I'm interested in the pro and cons of all these but from my 
>point of view, one of the key issues is how hard is for people 
>to use. If you look at what things have succeeded in HTML, it 
>is typically the things that in there simplest form provide a 
>very simple interface to use them. Yes, they might have a more 
>complex form that allows richer control but the basics are 
>simple. Take the HTML5 video tag for streaming video media for 
>example. There are zillion things that could have been passed 
>and controlled to this flag yet the proposals that one out 
>were the ones that provided something that was incredibly 
>simple to use. Another example is the iPhone interface to make 
>a phone call from the browser has been very successful from an 
>adoption point of view. 
>
>
>
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Niklas Enbom <[email-masked]>
Date: Thu, 30 Jun 2011 10:39:56 +0200

Cullen, what is meant by "current Chrome implementation" in this doc? At
least what we're implementing is not using the Jingle protocol on the net.
We are using libJingle internally, but the API we're building is essentially
the whatwg proposal with some tweaks.

Niklas

On Wed, Jun 29, 2011 at 5:07 PM, Cullen Jennings <[email-masked]> 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.
>
>
> 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.
>
> It certainly possible to support more than one of these but I'm interested
> in the pro and cons of all these but from my point of view, one of the key
> issues is how hard is for people to use. If you look at what things have
> succeeded in HTML, it is typically the things that in there simplest form
> provide a very simple interface to use them. Yes, they might have a more
> complex form that allows richer control but the basics are simple. Take the
> HTML5 video tag for streaming video media for example. There are zillion
> things that could have been passed and controlled to this flag yet the
> proposals that one out were the ones that provided something that was
> incredibly simple to use. Another example is the iPhone interface to make a
> phone call from the browser has been very successful from an adoption point
> of view.
>
>
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Jun 2011 19:04:50 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Matthew Kaufman
> Sent: 30 June 2011 00:23
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [rtcweb] Media negeotiation and signalling archatecture
> 
> 
> 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 
> > 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. 
> 
> 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. 
[JRE] And to add to what Matthew says concerning complexity of SIP, much of the complexity is between a UA and its domain registrar/proxy (e.g., SIP outbound, GRUU assignment, Path) and a lot of features that are implemented on SIP-PBXs, say, only operate between a UA and its domain registrar/proxy (or B2BUA). In the high path, the web server takes on the role of domain registrar/proxy, so the SIP interface is an inter-proxy, or inter-domain interface, where a lot of the complexities of SIP don't appear.

John

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