Kurento WebRTC Connection Problem (but only in ~30% of cases, same network, same devices, same signalling!)

[raphael]

Hi

I have spent days hunting down a connection problem without any luck. I'm trying to implement a relatively simple one2one Call with Kurento.

Attached are logs of cases that worked (they have "working" in the filename) and logs of cases that failed (they have "notworking" in the filename). The files that don't have "debug" in the filename have the loglevel set to "3,Kurento*:4,kms*:4,sdp*:4,webrtc*:4,*rtpendpoint:4,rtp*handler:4,rtpsynchronizer:4,agnosticbin:4", the files that have "debug" in the file name have the log level set to "3,Kurento*:4,kms*:5,sdp*:5,webrtc*:5,*rtpendpoint:5,rtp*handler:4,rtpsynchronizer:4,agnosticbin:4".

Any help or new input is greatly appreciated!

Description of the Problem: 

In about 30% of cases, the WebRTC connection cannot be established. Unfortunately I'm short of any kind of patttern when the Connection can be established and when not, it seems completely random. I'm in the same network, using the same devices, using the same TURN server, using the same signalling protocol, but in 30% of cases the connection cannot be established.

When I run the application locally, it seems to work much more reliably, the connection can be established almost 100% of the time (or maybe even 100% of time, I have tested so many times I lost track). I set up the infrastructure locally with docker, and run the different containers (TURN, Kurento, Signalling) in separate networks to mimic a production deployment. 

We experience the same behavior in our development and production environment. In our development environment we have absolutely no firewalls in place, so that doesn't seem to be the problem.

What I have tried to find the cause of the Problem:

Mostly I have been comparing logs of cases that worked and cases that didn't work but I have failed to find any significant difference between them that could point me to the problem. 

I have tested the WebRTC connection over the TURN server (with Firefox and the force_relay flag) and over Kurento directly, but in both cases the connection fails in ~30% of cases.

I have tried filtering all ICE candidates that are not Relay candidates.

I have sniffed traffic between our signalling server (which also controls Kurento) and Kurento to see any difference in the JSON RPS messages exchanged but they appear to be essentially the same.

I have tested our STUN and TURN server using this tool: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ and I get both serverreflexive and relay candidates that look correct

I have sniffed the traffic from the clients of a successful and unsuccessful connection but could spot a significant difference

I have simplified the Kurento media pipeline (no recording, no Hubs) but the behavior is the same

I have used different browsers (Chrome, Firefox and a native iOS implementation) but the behavior is the same

[raphael]

I you need more logs of anything (clients, signalling server, kurento trace logs?) of cases that worked or didn't work please just let me know and I will provide! 

[raphael]

After days of searching for the cause of this problem we finally found it: The problem was that our Socket.IO client did not correctly URL-Encode its JSON payload when xhr-polling, which resulted in all plus signs being changed into spaces on the sevrer. This meant that the ufrag in the clients SDP was invalid if it contained a plus sign! That's why only some of the connections failed because not all ufrags contain plus signs.

[Micael Gallego]

Ufff... Very very hard bug to catch

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/e21c1e1b-7dba-4fb8-aeb7-2d15d9756ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Suresh R]

I am new to Kurento, now I am facing the same issue. Can any one tell me the solution? How and where to fix this issue?

[Juan Navarro]

Make sure you depend on libraries that don't break communications under your feet. That depends on what software you use, and it is outside of scope for Kurento.

Also resurrecting long-dead threads is rude. Just open your own topic.