ICE Connection with relay candidates using coTURN failed #65
Comments
|
I have updated the above logs (correctly showing TRACE level logs). With the This must be the "Send Indication" request received on port 3478. The log says "processed, success", but the remote end does not see the packet. @Sean-Der, now, I have two questions:
|
|
1.) That makes sense to me, but I think that is something that will need to be solved on the coTURN side. I don't think WebRTC clients can do anything to influence this behavior (not for sure though) 2.) https://www.w3.org/TR/webrtc/#rtcicetransportpolicy-enum
|
|
Right, (1) is totally server side issue. Specifically, AWS's NAT issue. If hairpin routing is not possible, then we have to make sure both ends use different relay servers, I believe. |
|
@Sean-Der I was able to run coTURN on my local PC. Data channel connection was successfully established using ICETransportPolicyRelay! But... answerer side (being an echo server) does not seem to receive data (dc.OnMessage does not seem to be called) although the handshake at SCTP level and below succeeded. (it has bidirectional connectivity up to SCTP layer, specifically DCEP layer) If I turn off ICETransportPolicyRelay option, echo comes back. It does not really make sense to me but do you have any thoughts on this? (How ICETransportPolicyRelay option affect OnMessage callback?) Note: I am using today's latest webrtc, ice and turnc |
Open issue:
|
|
@Sean-Der quick question... could you tell me why we have two a=candidate lines with the same transport address?
|
|
I am still searching for reasons why my test does not receive application data via a datachannel. I added the printfs around In my test, both ends' ice conn state go to "connected", then it successfully finishes DCEP handshake. But after that, the Read() method never returns although sending side is sending data to the data channel (OnMessage() does not get called, because, SCTP's readLoop stops receiving data) ... so weird. |
|
I fixed a bug last night in master where DTLS/SCTP would improperly stop. Might be relevant? Is ICE getting the incoming data? The readLoop for that is in candidate_base.go I will setup coturn on AWS tonight and start debugging! I am doing errands today sorry |
|
@Sean-Der I think that is not related. I found something interesting. When the data channel message is greater than 888 bytes, the remote does not receive it. I am still not sure whether that is dropped by turnc or coturn. I modified the pion-to-pion example to send the text longer than 888, and that problem happens. The message longer than 888 bytes reach CandidateRelay, |
|
Looking at wireshark, a 1000-byte message is transmitted to coTurn as a "Send Indication" packet (which contains 1065 bytes of DATA), then it returns "Data Indication" packet (which includes the identical DATA) to the remote candidate. So, coTURN is routing the large data. But I do not see any log indicating reciving the data on the receiving end... |
|
Good to close! Let me close... |
Your environment.
What did you do?
What did you expect?
Both ends would connect with each other through a relay candidate
What happened?
Gathering relay (TURN) candidates are successful, but ICE connection state goes to "failed" in about 10 sec
Logs
Answerer side
Offerer side
coTURN log
The text was updated successfully, but these errors were encountered: