Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture

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

On 2011-07-06 08:06, Bernard Aboba wrote:
> Stefan said:
>
> 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
>
> [BA] I agree that the WhatWG proposal is not inherently low, medium or high path.   The signalling mechanism is totally up to the signalling callback function.
>
> I did have a question about how the PeerConnection API manages the gathering of the ICE candidates, though.  It was my (naive?) assumption that beyond the host candidates (always included?),
> the other gathered candidates would based based on the Type information passed (e.g. STUN/STUNS, TURN/TURNS).   If the SDP Blob is not considered "opaque" the signalling
> callback could manipulate/change it, to affect the  subsequent ICE processing.  The peer could do the same thing on its end.  If this were true (is it?) then that would allow quite a bit
> of flexibility.
[SH] I have the same understanding.
>
> I was also a bit uncertain about the precise timing of when ICE connectivity checks are kicked off within the API, and how things like a NIC change are handled.   For example, is it
> envisaged that it would be possible to implement RTCWEB mobility (e.g. handoff of media between interfaces)?
[SH] I think that is the assumption. Quote from the API spec "...any 
time the network topology changes and the ICE Agent performs an ICE 
Restart".
>
>
>