-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OnDataChannel not triggered by remote peer #19
Comments
Here's my brain dump for now. At this point https://github.com/keroserene/go-webrtc/blob/master/demo/chat/chat.go#L204 However, if this isn't
doesn't fire. When it does, however,
return early and prevents the That's because,
When it works (start in go),
All this to say, when you add the answer, |
This seems to be because,
|
Setting
|
* Should help with #19 but now seeing some panics.
Now seem to be hitting: https://bugs.chromium.org/p/webrtc/issues/detail?id=4757 |
Awesome tracing!! 👍 |
|
Despite my elation at a go-go chat last night, I don't think this is solved. The constraint we want (as you noted) is,
for DTLS/SCTP Data Channels, which are still stuck in the |
Aha, well, the merged patches did do one good things (fixing trying to access the deref'd pointer). If I try the |
Whoa, awesome! Right now I'm really excited that Go+Go chat works at all :) (re: #22 (comment)) I'm wondering if maybe we didn't build from the correct release branch of webrtc, given that the same webrtc provides working DTLS/SCTP in chrome. |
More notes: With a Chrome+Go chat session where Go is the "answerer", after copying pasting the generated answer and candidates, Chrome consistently thinks channel has opened successfully and allows chat to happen, while Go doesn't.
However! So DTLS is being setup. Furthermore, |
Yet more notes:
... However, Meanwhile, some stuff happens in a different thread with Soon after, ... Now I need to look into why |
Ok, I'm pretty convinced the problem is the call to So, I looked on master and the function is now called
I did a I'm happy to report go-go DTLS/SCTP DC, as well as chrome-go (with chrome the offerer), working as expected. That was fun! |
Super exciting! :) Thanks for figuring that out. Had a feeling it'd be something silly like gclient sync to the right version... about to try it. Do you know if there's a specific release branch, instead of HEAD, we should use for stable DTLS/SCTP data channels? Otherwise I suppose pinning our build script to commit (It seems the next thing we need is to make the libwebrtc_magic build script solid and easy to use for everyone else) |
Confirmed DTLS/SCTP DC working as well! 👍 Had to remove the chat demo's bundle policy, and had to update the Both Go+Go, and Go+Chrome (both directions) work great. With Firefox it's a bit fussy (the paste order of offers matters, and sometimes the data still only traverses in one direction.) but Firefox + Chrome are also fussy anyways. We may need to worry more about that after more progress on the PT. For now, hurray, thanks & that was indeed fun. |
\o/ |
Must be solved before a Go-to-Go data channel can be established.
This was already in email form, but listing this issue in greater detail here:
Currently, go-webrtc only works when it acts as the "offerer". This means
datachannel = PeerConnection.CreateDataChannel(...)
locally, which triggers ICE negotiation. Once connectivity is established,datachannel.OnOpen
callback fires, and then bytes can exchange successfully viadatachannel.Send(...)
anddatachannel.OnMessage(...)
.Here's the current connectivity determined through my chat demo:
When go-webrtc attempts to act as the "answerer", connectivity has so far never succeeded. This means
PeerConnection.SetRemoteDescription(...)
using received SDP offer from remote peer. However, ICE negotiation never completes, and theOnDataChannel
callback does occur as expected.More info:
Tracing with gdb,
webrtc::WebRtcSession::CreateDataChannel
is being called in response tosetRemoteDescription
, as expected. (when the SDP indicates remote peer created a datachannel). After that, there needs to be some sort of initial setup messages for the datachannel internally, once the negotiation succeeds, which should transition the readystate to "open", and trigger.OnDataChannel
. But this isn't happening.Rather, there are just many periodic
webrtc::WebRtcSession::OnSentPacket_w(...)
's firing, but something is being lost / failing relatively silently.The text was updated successfully, but these errors were encountered: