Connection Problems and Diagnostics

[fredl...@comcast.net]

I have complained for a long time that there are connection problems with the WebRTC clients.  It tries to connect, but I get no audio or video.  Occasionally I get audio with no video or sometime a one-way connection, but usually it either works or doesn't work. Chrome is better than Firefox, but both have problems.  The problem is evident with STUN only configurations and also present is STUN/TURN configurations.  It is worse across two networks.  Two networks with two different browsers is even worse. Everyone always blames it on the network and I need TURN, etc., but I have done so many tests that I don't believe it and never have.  Here is a test that I ran today that is a really good example.

I have a desktop PC and a laptop PC on my desk.  Both run Windows 7.  I also have two networks/routers, etc.  One is ATT and the other is Comcast; both large and well respected networks.  We have developed a native client for a PC.  I ran the Chrome browser on one PC and on the other PC I had both a native client and the Chrome browser.  Now I compared the results of calling Chrome to Chrome and Chrome to native client.  Chrome to Chrome always failed going from ATT to Comcast, but if I run the exact same test Chrome to native client, it always worked. I can call Chrome to Chrome going from Comcast to ATT, but not the opposite direction.  What is interesting about this test is the network didn't change nor did the WebRTC server, the STUN/TURN application (we use the 5766 one), or the PC's.  We are using vs 32 of Chrome. The only thing that changed in this test is the client on one end.  Everything else was the same. It tells me that Chrome has a problem in this area.  I have done many other tests that tell me the same thing, but this is the most conclusive.

What would really be nice is to have a diagnostic tool that would help to diagnose this kind of problem.  It seems like the available tools don't really get to the heart of the issue.  I can see the SDP, the ice candidates, etc., but when it comes to the connectin itself, there is nothing.  A connected call and an unsuccessful attempt looks the same.  I want to know that it failed and why.  I also want to know how it connected assuming a connection.  Was it point 2 point or was it through a relay and if so, what relay.  It seems like those tools should be built in.

[Oleg Moskalenko]

I can only give you a diagnostics advise from the TURN server point of view.

If you have two different client networks (ATT and Comcast) the chance is that the clients MUST use the TURN server to get connected. Any other "ephemeral" candidates are unreliable. The problem, I guess, is in those "ephemeral" ICE candidates which have to be filtered out, somehow, by the client applications.

Try to do the client test:

1) Restart the TURN server (to get the clean state for the stats information).
2) Go to the TURN server telnet console:

  $ telnet 127.0.0.1 5766

3) Start two clients connection session.
4) Run "ps" command in the telnet and see the progression of the changes in the TURN sessions list.
5) Run the other test with different clients combination.
6) Compare the results of the telnet console output. That will tell you what is the difference between the network communications.

There may be different variations. For example, your native client may always run TCP, but the browser is trying UDP first.

Oleg
 

[fredl...@comcast.net]

Oleg,  Thanks for the post.  It sounds like a good idea to try.  Hopefully, first, we can figure how how to do that and second, it will show us something useful. I have always had a problem with connections on these two networks.  Ususally it is only a one way problem--a call to the Comcast network.  I don't know of any unusual settings on my router/firewall.  My development team is in India and they can call into my Comcast network easier than I can call between the two PC's on my desk.  We don't even use "TURN to do it.  We close down the TURN portion and only use STUN and it works fine so I can't figure out how they can do it and I can't do it myself.

[Dennis E. Dowhy]

The best tool here IMO is running wireshark on both pcs and just doing basic packet analysis to see where the stun packets are being blocked/dropped or any other unusual behavior.  It really makes a world of a different seeing this happen in real time and knowing what the behavior should be and what is actually happening on the network. 

Sent from my iPhone

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Deiana Pchelarova]

Did you check your your network connection performance? You can try to check it here -> http://www.netscan.co/

There is The Connectivity Checker will perform a series of network tests for modern Web Services like WebSockets and WebRTC. A unique url will be created with the results which you can then share with an expert to get your problem diagnosed.

It was helpful for me, I hope that it will be as helpful for you too.

[Justin Uberti]

The iceConnectedState should be different between a connected call and an unsuccessful attempt. In addition, chrome://webrtc-internals will show the status of the various ICE candidate pairs while the call is being set up. Lastly, getStats will return information about which ICE candidate pair was ultimately used.

--

[Fred Clark]

Justin,  Thanks for the response.  We finally got the connection problems figured out.  We are using the Stats feature and find it very helpful.

 

I do have a question regarding the STUN/TURN server that we have never been able to figure out.  We would like to be able to put more than one STUN/TURN server IP address into the SDP and if the first one is down, the application would just use the second one.  Is there a way to do that.  We have tried, but it always just uses the first entry and never tries the second even though we take the first one offline.  It seems like we should be able to do that, but haven’t figured out how.

Thanks,

Fred

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/yNia2v93MQ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vikas]

Hi,

Sorry but I did not get what you mean by passing STUN/TURN in sdp. The STUN/TURN servers are passed to the iceServer array when you create a peerconnection. Currently in Chrome if multiple TURN servers are passed, we will gather candidates from all of them, but will use the connection will least RTT.

/Vikas

[Fred Clark]

Vikas,  Let me explain.  I am trying to provide a simple redundancy step for my TURN/STUN server.  I have two servers running side by side.  Both have my WebRTC application running and both have the 5766 TURN/STUN app running.  I want to use A for the primary WebRTC app and B for the primary TURN/STUN app.  If B should go down I would like it to use A automatically.  I was hoping I could accomplish that by putting B in the TURN/STUN definition followed by A.  Have not been able to get that to work however.  I would think that the RTT time is going to be pretty much the same as the two servers are setting side by side.  So far we have found that it uses the first one in the list and ignores the second even though the first one is turned off.  Can you give me a suggestion?

Thanks,

Fred

[Mallinath Bareddy]

Fred,

I don't think that kind of (hot) redundancy is supported in webrtc framework, as candidates allocated by both the TURN server might have same candidate priority. So PeerConnection might select either one based on other connection attributes.

Chrome use to select first turn server from the list, but that was a while back. Currently if both STUN and TURN servers are provided to chrome, chrome will use try to allocated candidates on all supplied TURN server list. 

But when it gets both STUN and TURN server list, it will use just first TURN server from the list for getting STUN candidate (srflx). This is true only for STUN candidates not for TURN.

[Justin Uberti]

As Mallinath says, at call startup we can try both A and B, and pick whichever works/has the best RTT. But we will discard whichever one is not selected.

If we pick A, and then A dies in mid-call, the app will be notified, and it can again try A and B, and end up on B (assuming B is still dead).

If keeping both A and B hot is desirable, please file a FR on this.

For more options, visit https://groups.google.com/d/optout.