Handover to Data Channel

[lgrahl]

As soon as the signalling channel has done its job, there is no good reason to leave the signalling connection open. Further ICE candidates and other signalling messages can be sent over a dedicated signalling data channel.

• ID Negotiation
• Linger Minimum Timeout

[dbrgn]

Should the signalling channel get the ID 0 or 1023?

The call flow draft says 1023, but I remember reading somewhere that it should be 0.

[dbrgn]

Also, what happens if one peer does the handover while the other one does not?

[lgrahl]

I think at default the id should be 0. If the use case requires that id for another data channel, a different id can be negotiated. The negotiation for this should happen in the auth message as part of the data field (see #33) and needs to be described by the task.

Proposal: For a simple task to set up a WebRTC peer connection, the responder sends a range of usable data channel ids. The initiator then choses one of the ids and sends the chosen id in the auth data field (or closes with some kind of negotiation error close code which also needs to be propagated to the other peer somehow - but that is another matter).

(We really have to open a few tickets for the task feature at some point)

[lgrahl]

Also, what happens if one peer does the handover while the other one does not?

This should also be negotiated by the WebRTC task. If the responder does not wish to use the handover feature, it shall set the value in task's data field to false. The initiator then knows that that there will be no handover. In case the initiator doesn't want to use the handover feature, it shall send false in the task's data field.

[lgrahl]

On second thought, I think the responder should send a list of ids that need to be excluded. The initiator then chooses a data channel id. Default is 0.

[dbrgn]

By the way, why do we use negotiated channels instead of using in-band signaling to simply open a new data channel with random id?

[lgrahl]

Because we are more flexible to the user's needs this way. If a user requires the id 0, that's fine for us. If for some reason a user requires that no dynamic ids are being assigned - fine by us. Also, negotiation requires another RTT (see the DCEP protocol) which we can avoid. (Although it is possible to send data directly with the opening handshake, I'm not sure how properly this is implemented in the browsers regarding the onopen event.)