Hi,
On Mon, Apr 01 2013, Michelle Bu wrote:
> I was able to reproduce this bug. Firefox's onconnection is not fired
> for the second connection, which I can't really pinpoint a reason for
> right now. Perhaps it has something to do with the
> connectDataConnection calls and the ports I'm using. I'll look into it
> more tonight.
By the way, it looks like Firefox Nightly broke PeerConnection API
compatibility today (landing in tonight's Nightly), so you might want
to hold off on the release until peerjs works with those changes.
From Mozilla's #media:
15:37 <cjb> Hi, do we still need to call connectDataConnection(4000,4001);
(with ports flipped) after the changes that landed earlier today?
15:40 <jesup> cjb: Sorry, I need to post something. We landed a
break-protocol/API change last night. connectDataConnection() is
now a stub. You need to call createDataChannel() before
createOffer() for DataChannels to be usable. Eventually we'll
support re-negotation, and then calling createDataChannel after
createOffer will cause onnegotiationneeded to fire.
15:41 <jesup> cjb: you only need to call createDataChannel() once
before createOffer() - so it will include m=application in the offer
15:41 * jesup should make the connectDataConnection throw an
error telling people that for the next week or two before
removing it
15:43 <jesup> also note that the binary protocol on teh wire
changed (IETF86 decision), and so builds before the change and
after won't be able to talk to each other. Also, ondatachannel
now includes an event parameter per the spec, instead of just a
reference to the channel -- function new_channel(event) { channel
= event.channel;}
- Chris.
--
Chris Ball <
c...@laptop.org> <
http://printf.net/>
One Laptop Per Child