Comments (13)
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:
- 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?
- 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.
- 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.
Related Issues (20)
- Simplify Agent.updateConnectionState() HOT 1
- Reenable IPv6 UDPMux tests in i386
- Active TCP candidates? HOT 7
- Support server reflexive TCP candidate type HOT 13
- Fix type of CandidatePairState enum
- TestAgentActiveTCP test is failing due to data race
- Active TCP performs network operations in main thread HOT 7
- Connection failing to TCP candidate when listening on multiple interfaces using `MultiTCPMux` and `NAT1To1IPs` HOT 5
- Noisy warnings if TURN/STUN host is not reachable via IPv6
- Panic when adding candidate HOT 5
- bug(log): webrtc using ice will print wrong log HOT 1
- ice v2 depends on transport v2.2.2, which had a breaking change HOT 1
- Candidate type is not changed from peer-reflexive to host HOT 1
- Allow users to pass custom 'CandidateSelectorControlling` and `CandidateSelectorControlled` HOT 3
- ConnectionState changes may be reported incorrectly HOT 4
- Please add a new release tag HOT 2
- Android 11 ListenUDP permission denine
- Support ipv6 for mDNS Server HOT 2
- Start the listening port by default above 1024 HOT 1
- Doubts about discarding monotonic time HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ice.