Re: [rtcweb] Media negeotiation and signalling archatecture

[Stefan Håkansson LK <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Cullen Jennings
>Sent: den 29 juni 2011 17:08
>To: [e-mail]
>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. 
>
>http://trac.tools.ietf.org/wg/rtcweb/trac/raw-attachment/wiki/W
>ikiStart/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. 
>
>
>
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb
>