Philipp Hancke
11 years ago
Lance and I were talking about webrtc negotiated datachannels today.
Negotiated datachannels are useful when you want to create interoperable
clients because you don't have a random channel popping up in a
ondatachannel event but rather set it up explicitly using signaling.
We ended up with the following:
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<sctpmap xmlns='urn:xmpp:jingle:transports:dtls-sctp:1' number='5000'
protocol='webrtc-datachannel' streams='1024'/>
<channel xmlns='somens' id='3' reliable='true'/>
...
The attributes of that element need to match those defined in
http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcdatachannelinit-members
I'd go for a new namespace instead of reusing the dtls-sctp one because
of rumors about quic-based datachannels.
This way, we get arbitrary descriptions that can be combined with a
datachannel transport. For example, we might want to have a volume
description, an active speaker description, a simulcast controlchannel
description etc, all without having to reinvent the transport over and over.
Ironically, most of the time the description would be empty, used just
to identify the protocol used over a certain datachannel.
webrtc caveat: don't send data on reliable data channels before you get
a jingle iq-response for your signaling message. Those "reliable"
datachannels might loose data otherwise.
If you don't want to use negotiated datachannels 0343 works still quite
well without that.
Jens: shall I send a patch?
I'd also change the title to "Use of WebRTC datachannels with Jingle"
because it get's more specific to that and I don't really see any use of
that particular combination of ice-udp/dtls/sctp stack in other contexts.
Negotiated datachannels are useful when you want to create interoperable
clients because you don't have a random channel popping up in a
ondatachannel event but rather set it up explicitly using signaling.
We ended up with the following:
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<sctpmap xmlns='urn:xmpp:jingle:transports:dtls-sctp:1' number='5000'
protocol='webrtc-datachannel' streams='1024'/>
<channel xmlns='somens' id='3' reliable='true'/>
...
The attributes of that element need to match those defined in
http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcdatachannelinit-members
I'd go for a new namespace instead of reusing the dtls-sctp one because
of rumors about quic-based datachannels.
This way, we get arbitrary descriptions that can be combined with a
datachannel transport. For example, we might want to have a volume
description, an active speaker description, a simulcast controlchannel
description etc, all without having to reinvent the transport over and over.
Ironically, most of the time the description would be empty, used just
to identify the protocol used over a certain datachannel.
webrtc caveat: don't send data on reliable data channels before you get
a jingle iq-response for your signaling message. Those "reliable"
datachannels might loose data otherwise.
If you don't want to use negotiated datachannels 0343 works still quite
well without that.
Jens: shall I send a patch?
I'd also change the title to "Use of WebRTC datachannels with Jingle"
because it get's more specific to that and I don't really see any use of
that particular combination of ice-udp/dtls/sctp stack in other contexts.