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!).
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.
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.
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 used to have code in here that did fake audio streams, or did
OfferToSendAudio:true and other such things, but as I've read, all of that
stuff that used to be needed isn't, anymore.
I've also tried with and without the `DtlsSrtpKeyAgreement` and
`RtpDataChannels` in the `peer_connection_options`, with no change in FF (or
Chrome) behavior.
------------
Lastly, here's a recent SDP from FF (which failed, obviously):
{"type":"offer","sdp":"v=0\r\no=Mozilla-SIPUA-27.0a1 23947 0 IN IP4
0.0.0.0\r\ns=SIP Call\r\nt=0
0\r\na=ice-ufrag:f6125c1c\r\na=ice-pwd:248cdc570ad5ace8ba1144e7e1932811\r\na=fingerprint:sha-256
46:0B:51:4A:26:D7:19:C6:C2:56:0C:AE:C8:59:B7:D9:76:C1:0A:A8:9D:81:FE:1B:BB:C6:B4:61:A9:BA:74:64\r\nm=application
41577 DTLS/SCTP 5000 \r\nc=IN IP4 50.198.161.161\r\na=sctpmap:5000
webrtc-datachannel 16\r\na=setup:actpass\r\na=candidate:0 1 UDP 2130379007
192.168.29.222 64975 typ host\r\na=candidate:2 1 UDP 1694236671 50.198.161.161
41577 typ srflx raddr 192.168.29.222 rport 64975\r\n"}
And an SDP from Chrome (which worked!):
{"sdp":"v=0\r\no=- 8346274114848387671 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0
0\r\na=group:BUNDLE data\r\na=msid-semantic: WMS\r\nm=application 1 DTLS/SCTP
5000\r\nc=IN IP4
0.0.0.0\r\na=ice-ufrag:3PNV2NDaJ0QJWAgV\r\na=ice-pwd:7oeCvbyDBezDnAZz4DcJ9KEZ\r\na=ice-options:google-ice\r\na=fingerprint:sha-1
7E:5E:80:41:85:81:3D:E3:B3:B9:E8:B0:0C:AD:58:19:F4:72:45:B5\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000
webrtc-datachannel 65536\r\n","type":"offer"}
HELP! :)
--Kyle
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
