Time out when negotiating connection #1256
Answered
by
ppv-milestone
ppv-milestone
asked this question in
Q&A
-
|
Hi, 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.
Answered by
ppv-milestone
Feb 12, 2025
Replies: 2 comments 20 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.
9 replies
-
|
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.
-
|
Sorry for the delayed response - I have been offline for a few days due to the holidays. |
Beta Was this translation helpful? Give feedback.
-
|
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.
-
|
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.
-
|
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.
-
|
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 aaron@sipsorcery.com to avoid publishing you IP addresses. |
Beta Was this translation helpful? Give feedback.
11 replies
-
|
From what I have been told it should be coturn, but I will verify that, and have also reached out to the server team. They are in another time zone, so might take a while. |
Beta Was this translation helpful? Give feedback.
-
|
We have now tried running with a coturn server we set up ourselves in order to verify whether it happens there as well, but also to get access to the logs. The issue happens less frequently with this server, but it still happens, and the logs does not really provide any clue about what happens. Any suggestions on something to try on our side in order to get any further on this? |
Beta Was this translation helpful? Give feedback.
-
|
I'm struggling for ideas as well. It's very crude but what about putting a timer in your app and if the RTCPeerConnection isn't in a connected state after 10s then restart ICE and see if that does anyting. |
Beta Was this translation helpful? Give feedback.
-
|
The server-side provider did some changes a week or two ago, which was not supposed to have any affect on this, but nevertheless I am no longer able to reproduce the issue (no changes in neither my code nor the SIP Sorcery), so my best guess is that this was related to the server side after all. |
Beta Was this translation helpful? Give feedback.
Answer selected by
ppv-milestone
-
|
Great to hear it got resolved in the end (hopefully the issue doesn't come back). Just in case it helps someone else in the future if the server was a public product or platform can you reveal what it is? |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately I cannot reveal that at the moment, except that it is CoTurn that is used as the TURN server. But currently the endpoint is not public as such, so no one else should be implementing towards it for the time being. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The server-side provider did some changes a week or two ago, which was not supposed to have any affect on this, but nevertheless I am no longer able to reproduce the issue (no changes in neither my code nor the SIP Sorcery), so my best guess is that this was related to the server side after all.
I apologize for having involved you in this, but want to provide my sincere gratitude for your support on this matter. My team and I will do our best to provide improvements to the library to pay a little bit back to the community.