Re: New version of editor's draft (20130116)

On 2013-01-17 22:45, piranna@gmail.com wrote:
> Hi Adam. On the Peer-to-Peer Data API section is specified:
>
> "Data channel setup signaling (signaling via SDP and application
> specific signaling channel or first channel via SDP and consecutive
> channels via internal signaling)."
>
> The second option seems very nice since it's very probably you know in
> advance if you'll need channels on your application, although use this
> first channel as signaling between the two peers for media or to
> create more DataChannels without requiring anymore the initial
> signaling channel is really a great feature :-D I have two doubts
> here:
>
> * reading the changes done in the latest version of the specification
> it seems that when a DataChannel object is created its PeerConnection
> object is not needed anymore and could be closed and also garbage
> collected (previously the DataChannel needed to check the status of
> the PeerConnection object and now it have been removed all references
> to it). Is that correct?

A DataChannel could be seen as a special type of stream. For this 
reason, the "parent" PeerConnection in still required to manage the 
connectivity. Closing it will close down all "child" DataChannels as well.

You're right that the closing procedure in the previous version had an 
"early return" if the PeerConnection object was in the closed state. 
That step was removed when the closing procedure was reworked to more 
align with WebSockets. A notable consequence is that it allows the close 
event to fire on every open DataChannel when the corresponding 
PeerConnection is closed (which will lead to the DataChannels closing as 
well).

> * Using the initial DataChannel for signaling is a great idea, but you
> need an external initial signaling channel, and for pure client-side
> webapps this is a problem. Has something been though about this? I
> have had some time ago the idea that since to establish the connection
> both ends need their SDP (that they have already) and the other end
> SDP, you could interchange "by hand" the SDP of one of the ends and
> this one automatically send its SDP to the other one, probably through
> the TURN server, but currently there's no way on the API to detect
> messages received from the TURN/STUN server. Is it feasible, or I'm
> saying silly things? If it's not possible, what other options would be
> possible (specially without having to modify the API)?

Yes, you need an initial signaling channel to exchange session 
description objects. How do you define as a "pure client-side" webapp, 
and why is this a problem for such an app? Even if PeerConnection could 
transport the SDPs via the TURN/STUN server, you would need that initial 
channel to find out who to communicate with since all that is up to the 
application.

/Adam

Received on Friday, 18 January 2013 06:54:03 UTC