ICE Connection with relay candidates using coTURN failed about ice HOT 13 CLOSED

I have updated the above logs (correctly showing TRACE level logs).

With the -V option with turnserver, I can see:

73: session 001000000000000002: realm <sgcoturn.xxx.com> user <1560060033>: incoming packet SEND processed, success

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. If the allocate port on the SAME coTURN server running on EC2 can can communicate with each other. These ports are on the public IP address assigned for the EC2 instance. Do these public ports do hairpinning?
2. Even when ICETransportPolicyRelay is used, shouldn't the connectivity check be performed from non-relay local candidates if the remote candidate is of type relay?

from ice.

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

ICETransportPolicyRelay effects the local gathering, so the only candidates that will exist locally are relay. The remote is still free to add any candidate types it wants.

from ice.

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.

from ice.

@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

from ice.

@enobufs nice!

That is really strange, I was unable to reproduce it unfortunately :( I patched pion-to-pion like this

If you do a tcpdump do you see the messages coming through?

from ice.

@Sean-Der

• pion-to-pion example works with local coturn
• pion-to-pion example also fails with cotrun on EC2 (definitely a server side issue)

Open issue:

• Why my test's OnMessage() did not get called when ICETransportPolicyRelay is used
• Issue with coturn on EC2 (non-pion issue)

from ice.

@Sean-Der quick question... could you tell me why we have two a=candidate lines with the same transport address?

v=0
o=- 12549196 1560120562 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 C7:1F:12:BC:27:D0:D3:E8:FE:F2:45:DF:AD:F7:65:27:7C:AC:FA:7B:6C:60:9C:BD:B5:7A:48:B6:B5:D0:0A:63
a=group:BUNDLE 0
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=setup:active
a=mid:0
a=sendrecv
a=sctpmap:5000 webrtc-datachannel 1024
a=ice-ufrag:BhcimdpcpjPYygCW
a=ice-pwd:dmUZPNqUevdzpNCniScTulhdeJdjmcAG
a=candidate:foundation 1 udp 16777215 192.168.86.220 15864 typ relay raddr 127.0.0.1 rport 63492 generation 0
a=candidate:foundation 2 udp 16777215 192.168.86.220 15864 typ relay raddr 127.0.0.1 rport 63492 generation 0
a=end-of-candidates

above is from the pion-to-pion example.

from ice.

I am still searching for reasons why my test does not receive application data via a datachannel. I added the printfs around a.netConn.Read(buffer) in the sctp association.go.

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.

from ice.

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

from ice.

@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, permission.Write(). FYI.

from ice.

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...

from ice.

We fixed the issue of small MTU when using TURN with b28205a

@enobufs any other researching/fixing we should do? Or good to close

from ice.

Good to close! Let me close...

from ice.