AppRTC - fails (not Skype, Hangout) behind Enterprise network + ProxyServer + Low bandwidth

[SProgrammer]

I thought latest AppRTC have some fix for this but still same. where same location Skype, Google Hangout, Bria works. 

I have been meeting some random enterprise networks. Newly found the one which knocked me out totally:

1) All Enterprise users has to go to internet using there own ProxyServer 

(IE, Firefox, Safari, Midori, Opera, Google Chrome cant browse anything TCP port 80, TCP port 443 unless ProxyServer is configured + website or IP is allowed)

2) Having ProxyServer already a nightmare, beside that what extra they are doing is per session (users/browsers) they are limiting the bandwidth for example total users or individual users with very low bandwidth limitation:

$ wondershaper eth0 50 50  # reference: http://superuser.com/a/223975/82524

NOTE: everything going out from that ProxyServer has to have download/upload of 50 kilobits limited 

(so at a time lot of users will be impossible almost i have just shown the worst value here)

3) What ever the Enterprise users browse over such setup is a hell/deadly slow 

(this SLOW experience is similar to one of those cheap Motels where WiFi is rocket science to get one. finally once you get one its deadly slow)

In such Enterprise networks, what is surprising is that the connection gets AUTO Disconnect while using AppRTC. But with same network Skype, Google Hangout, Bria works fine, it just does not fail like AppRTC completely kills the connection, which is very  frustrating scenario onsite.

first i thought its something to do with Stunnel or ProxyPass or SSL CONNECT method asynchronous issues but later i understood, that it is completely the Network admin who is using ProxyServer + on that server they are lowering per session the bandwidth usage to very low.

But even in such setup Skype, Google Hangout, Bria is breaking and making the life easier for the users, where AppRTC i tested again and it just fails, few seconds connection is alive and then auto disconnects from initiator such as its sending Bye signal from the Peer who initiated the call.

---

Can we make the AppRTC compatible with less then 50 kilobits upload/download (disable video explicitly or make video 1/2 frame per second) so that even they use such ProxyServer + lower the bandwidth explicitly, still AppRTC can be tune to crack it ( like Skype, Google Hangout, Bria is doing already) ?

Thank you

Regards

Shamun

[Justin Uberti]

Yes. There is an open bug in AppRTC GitHub to handle spurious disconnects of the type you mention.

[SProgrammer]

@Justin Uberti: Thank you. Mostly the disconnect happens when Peer 1 initiate the call waiting for someone to join, and then Peer 2 joins the room, now Peer 2 after few seconds mostly triggers the bye command, so i comment out the onRemoteHangup() ; completely and noticed that the Auto disconnect is not happening.  

As a result i have now longer duration the connection alive even there is no internet between P1, P2 which is fine for the time being.

---

But how could you send a very FINAL bye/disconnect signal/command on that specific session manually or from outside using some sort of?

  } else if (message.type === 'bye') {
    mystatus = 'free';
    callplaced = false;
    console.log('>>>>>>>>>>>>>>>>>>>>>>> BINGO bye >>> ' + mystatus);
    //onRemoteHangup();

[SProgrammer]

TURN server relay is used but still it fails because the Enterprise network is using: > WatchGaurd HTTP Proxy

Some other Enterprises are using many different HTTP proxy similar to WatchGuard HTTP PRoxy, which causing TURN method with the Turn-server to fail (same network zone running with WatchGuard HTTP PRoxy works for Skype, Google Hangout, Bria, Logmein, TeamViewer)

Q. What can we do about this?

[Sergio Garcia Murillo]

Are you using turn over tls? Is the proxy configured on the browser or its it a transparent one?

Best regards
Sergio

--

---
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/d/optout.

[SProgrammer]

@Sergio: Thank you.

- turn over tls with or without random settings i have tried, but all failed. (TCP port 80 or port 443 used with SSL connect method etc etc)

- Also proxy configured on the browser or without (transparent) caused same result. 

Both/Random retry has been applied but no luck so far. 

[Sergio Garcia Murillo]

Could you check if websockets work through that proxy?

--

[SProgrammer]

@Sergio: YES - webSockets work through that proxy. 

[Sergio Garcia Murillo]

Have you tested with canary? IIRC there was an issue with the SSL certificate for TURN on Chrome 35 that has been already solved in canary.

If it still doesn't work it would be very interesting to get an ethereal capture with TURN over TLS on port 443 and the proxy configured on the browser. HTTP CONNECT + TURN over TLS was supposed to traverse most of the HTTP proxies.

Best regards
Sergio

--

[Ben Weekes]

Does this test link work?

https://usa.saypage.com/user/demo/w.jsp

[SProgrammer]

@Sergio: Thank you

- No i have not used Google Canary

- i will arrange to be onsite and do the testing later

will let you know. 

Reg

Shamun

[Gustavo Garcia]

We reported this bug that makes impossible to connect from some enterprise networks:
https://code.google.com/p/webrtc/issues/detail?id=3384

Try using IP addresses instead of names for the TURN server and/or star that issue if you think it could help in your scenario.

G.

[Shamun Toha]

Tested with Google Chrome, Google Canary with same Enterprises running Proxy servers ( http://www.waronerrors.com/kb/request-denied-by-watchguard-http-proxy.aspx) still same no luck, does not work yet.

[Warren McDonald]

Hi Sham,
If you are saying that the proxy is denying the request, then there is nothing that can be done without involving the firewall administrator to allow the requests to the TURN server.

If you are saying that this has already been done, then you would need debug level logs from the firewall to see why the request is still matching a block pattern (or not matching an allowed pattern). That is something not appropriate to share in this forum so likely to best taken up with Watchguard support.

Warren

[Shamun Toha]

Hello Warren,

Please kindly see as following: 

If you are saying that the proxy is denying the request, then there is nothing that can be done without involving the firewall administrator to allow the requests to the TURN server.

> Proxy is not denying the request

> Firewall administrators were involved, 

and they confirmed there is nothing blocking for the Peer to reach TURN SERVER

If you are saying that this has already been done, then you would need debug level logs from the firewall to see why the request is still matching a block pattern (or not matching an allowed pattern). 

> CORRECT - this has been done. This is what i get from TURN SERVER, where it clearly shows that firewall is not blocking, its allowing to reach TURN SERVER, and then the peer disconnect the TURN session. Now this auto TCP closed is Google Chrome or WebRTC issue, i am not yet sure why this TCP auto close happening from Google Chrome/WebRTC? Is it because the TLS was not properly set? or is it something else?

Jul 16 09:19:18 ns429490 turnserver: 3116851: session 005000000000000235: TCP socket closed remotely 103.230.107.25:63175
Jul 16 09:19:18 ns429490 turnserver: 3116851: session 005000000000000235: closed (2nd stage), user <root>, local 34.187.150.4:80, remote 103.230.107.25:63175, reason: TCP connection closed by client (callback)
Jul 16 09:19:18 ns429490 turnserver: 3116851: session 005000000000000235: delete: username=<root>

That is something not appropriate to share in this forum so likely to best taken up with Watchguard support.

> YES sure (Just sharing transparently what is happening out there to be aware of)

Thank you

Reg

Shamun

[Warren McDonald]

I think more detailed network trace on the TURN server side and/or the chrome side may be required.

It is possible that the proxy may be hiding/rewriting too much of the request or return traffic so that the client rejects the session.

The only real way to see is to have packet level trace. You could start on the client end and see what is different in the negotiation to when a known good proxy is used.

Can you successfully use your turn server through a known good squid proxy, which you can trace to serve as reference?

[Shamun Toha]

OK - Warren. Thank you

- i will do the trace in all end points and see why the TURN session is getting automatically closed. Wild guess: a) Proxy server: WatchGuard http proxy server could be the main culprit b) Administrators themselves confused/human error c) TURN server setup issue, i maybe screwed!!

- Regarding Squid proxy, not yet done it. I will setup a full working Proxy server  in my lab, behind that i will put my PC's and simulate the real environment like i had in most Enterprises, once that is done i can find more details 

* I will update later once i prepare all those simulated setup in my lab first