-
Notifications
You must be signed in to change notification settings - Fork 444
Time out when negotiating connection #1256
Replies: 2 comments · 12 replies
-
I can replicate the same behaviour and log messages if I re-use an RTCPeerConnection instance. Each instance is only intended to be used once. For each new WebRTC peer connection you should be creating a brand new instance. If it helps I use the webrtccmdline tool to test scenarios like this. Signalling server peer:
Signalling client peer:
|
Beta Was this translation helpful? Give feedback.
All reactions
-
I'm still trying to reproduce this. It turns out the issue I had previously was due to my ICE candidates not being exchanged properly. Are you able to test your TURN server connection with UDP instead of TCP? It would be useful to know if the issue happens with UDP as well. |
Beta Was this translation helpful? Give feedback.
All reactions
-
Sorry for the delayed response - I have been offline for a few days due to the holidays.
|
Beta Was this translation helpful? Give feedback.
All reactions
-
In an attempt to try to figure out what goes different between when connection is established correctly and when not, I started adding some logging various places (as debugging will cause the issue to stop from happening). |
Beta Was this translation helpful? Give feedback.
All reactions
-
Can you add the two debug messages as below to your app. The idea is to see if a STUN response is being received to the use candidate check.
|
Beta Was this translation helpful? Give feedback.
All reactions
-
I have now run again with these added (log starts with "INFO - WebRTC:".
Failed attempt:
I am truely grateful for your continued support on this. Thanks! Please let me know if there is anything else I should try out. |
Beta Was this translation helpful? Give feedback.
All reactions
-
Thanks for the additional logs. The key difference between the success and failure cases is this log message:
In the success case that STUN response is received AFTER the ICE candidate is nominated, which is indicated in the log message below with the
The question is now why isn't the STUN binding success response received from the TURN server in some cases. If you're able to use WireShark it would be very helpful to get a packet capture of the STUN messages to/from the TURN server during the success and failure cases. That should fairly definitively point to the sipsorcery library being the culprit or not. If you do capture a WireShark trace you can send it directly to me at [email protected] to avoid publishing you IP addresses. |
Beta Was this translation helpful? Give feedback.
All reactions
-
I have now mailed you the two pcap files. Please let me know if you do not receive them. |
Beta Was this translation helpful? Give feedback.
All reactions
-
Got them, thanks. |
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
The problem is that after the sipsorcery end sends the nominated ICE candidate STUN binding request, as indicated by:, the log message below the response is not received from the TURN server.
In the success case this log message lets the sipsorcery end know the ICE channel is connected and to proceed to the DTLS handshake (note the response needs to be after the request sent in the preceeding log message):
In the failure case that log message never appears and from an initial look at the WireShark captures the response is not showing up in it either. The next question is why the remote peer is not sending the BindingSuccessResponse? Is the remote peer a browser? If it's chrome could you see if anything shows up in chrome://webrtc-internals/ when you get a failure particularly around the ICE events. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I have an implementation using WebRTC part of SIPSorcery in place which 2 out of 3 times works fine, but approximately every third attempt the flow seems to stop midway and then eventually times out. The logs will show the below (I have replaced TURN server address with 1.2.3.4, TURN server uri with TURNURI and certificate with XYZ), but then next line will be a timeout:
The times where it work I get the exact same, but then it will continue with this:
We have another web based client towards the same servers and do not see the same issue there. Does anyone have an idea what could be the reason why "ICE RTP channel sending connectivity check for" often times out?
Beta Was this translation helpful? Give feedback.
All reactions