On 10/19/2013 6:12 PM, getify wrote:
I am running FF nightly (as of 10/19) and I cannot get some code I've written
to make DataChannel communication between two FF instances (haven't tried
FF-Chrome yet, but I hear that's just now possible!).
Chrome is still working out a few bugs in their DataChannel setup. In
particular, 65536 channels in the initial SDP is invalid, the max is
65535. This does hit a bug in our code where it wraps around and
results in our responding (in an answer) with 0 channels (our patch for
that bug may land this weekend or Monday latest).. Try limiting the
number of channels in their offer to 2048 (or even 65535) and things
should work better. This will likely be fixed in a couple of days.
You can try just limiting it in the SDP you send to us, though I
suspect it's better to limit it in the SDP for their side
SetLocalDescription as well.
The same code works perfectly in Chrome Canary (32), of course, and no matter
what manner of code voodoo I've done I cannot get it to work in FF.
What happens is the PeerConnection negotiates itself between the two FF
instances just fine, meaning (through my signaling) the SDP exchange happens
without errors. I create my DataChannel after creating my PeerConnection
object, but BEFORE I create the offer from the caller side.
Ok, good.
I observe that FF throws a bunch of null ice-candidates out, which I initially thought
was the problem, but then I read that FF negotiates its ice-candidates not as
"trickle" but embedded in the SDP.
In addition to seeing the SDP exchange go through error-free, I also get the
`onopen` event fire on the data-channel instance, indicating (at least I would
think) that the DataChannel has actually been... opened. Again, no errors
exposed on either side, both sides fire the onopen.
I then start trying to send messages across that DataChannel, and again no
errors, but they are never received (in either direction). I have it re-try
those message sendings for about 10 seconds before my app gives up.
Ok. there's a misunderstanding here I think. One side should be
creating the channel (offerer); the other side should be getting
ondatachannel. If you're calling createDataChannel() on both sides,
both sides will open separate channels and get onopen, but no one is
listening on the other side. This explains the behavior in FF-FF calls.
Chrome likely has one of two bugs that are causing this to work: either
they're still using their old non-spec behavior of matching channels
based on label (my guess), or they're assigning channel numbers starting
at 0 independently at createDataChannel() time (before the
setRemoteDescription()/createAnswer()) and colliding by accident (which
is supposed to be impossible if they implement the even/odd behavior
based on DTLS roles, but I think they may not have implemented that yet,
making collisions possible if both sides call createDataChannel()
more-or-less at the same time).
I am sending text, actually a data-URL of an image. So my app is essentially trying to do
pic exchange. But, I also send a "hello" message between the two at the
beginning, and even that short text never makes it.
------------
Some specific tech details of how I'm configuring these objects:
peer_connection_options = {
optional: [
// FF/Chrome interop?
// https://hacks.mozilla.org/category/webrtc/as/complete/
{ DtlsSrtpKeyAgreement: true },
{ RtpDataChannels: true }
]
},
iceServers = [
{ url: "stun:23.21.150.121" },
{ url: "stun:stun.l.google.com:19302" }
],
data_channel_opts = {
reliable: true,
ordered: true // the newest according to the spec?
}
pc = createPeerConnection(
{ iceServers: iceServers },
peer_connection_options
);
dc = pc.createDataChannel(
channel_id
data_channel_opts
);
I assume there's a comma after channel_id.
You need something like this:
var channel; // assume only one for now - you can use an array and push
them, etc
pc.ondatachannel = function(event) {
channel = event.channel;
channel.onmessage = function(event) { ... };
channel.onclose = function() {...};
}
and then call createDataChannel() just on the offerer side. Note: while
the channel should remain active just because it's open and has
onmessage set (like websockets), that's not fully implemented in FF yet
(don't know about chrome), and so you want to make sure to keep a
reference to any data channels in use for now.
You can look at code in
http://mozilla.github.com/webrtc-landing/data_test.html; which purposely
sets up a data channel from each side to verify that works, though the
chat is all done through one of the channels in that demo.
I tried making a version of that page that supports chrome, but am stuck
on chrome not executing:
<script type=application/javascript;version=1.7">
alert("runs!");
</script>
(to ensure 'let' support - this works on Chrome if I do text/javascript,
but then I don't get let support)
I'm sure it's something simple/dumb, but it's late.
If you still have problems, let me know, and/or join us in #media on
irc.mozilla.org.
--
Randell Jesup, Mozilla
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
