Can't immediately send over a newly 'received' data channel...

[Mark Sibly]

Hi,

I'm having a problem setting up a simple p2p datachannel over a peer connection. However, it only seems to be happening when a webapp that uses plain JS WebRTC is the 'local' (CreateOffer) end of the connection, and an equivalent native c++ desktop app that uses libwebrtc.a is the 'remote' (CreateAnswer) end. With webapp->webapp everything works but this could be because there's some bigger delays behind the scene (see below). I can't get native->native connecting at all as yet, perhaps that's a STUN/TURN issue?

Anyway, the problem is that when the remote end (ie: the native app) receives it's 'view' of the datachannel via the PeerConnectionObserver::OnDataChannel callback, it can't be used straight away as the first message(s) sent always seem to go missing. I've checked that the data channel is open and DataChannel::Send returns true, so IMO it *should* be working?

I can fix it by inserting a slight delay before using the datachannel, but I'd rather find out what's really going on.

One minor thing I've noticed is that JS WebRTC generates an 'onopen' event for datachannels received via 'ondatachannel' events (even though it's already open when you receive it), but libwebrtc.a doesn't so maybe there's something else that needs to be done before it is usable?

Bye!

Mark

[Mark Sibly]

OK, found the problem...

When you're given a datachannel on the remote end via onDataChannel, it can have messages queued up on it which will get delivered immediately you call RegisterObserver, so you need to make sure everything's ready to handle incoming message before that, and I hadn't. Delaying sends a bit was simply making sure nothing got queued up.

Kind of obvious in retrospect, but it's taken me half a day to find - argh! Very nice having full source code to look through though.

Bye,

Mark