Unable to negotiate a connection when behind restrictive proxy

[Eradj_K_]

Hi there, we are trying to get connectivity working when running behind restrictive proxy. This is quite normal setup for all of entreprises the network configuration is as follows:

- client is not allowed to send any UDP, it is blocked a the firewall level

- all communication must go through proxy which allows only 443 outbound

Everything that I read seems to indicate that once turn and stun servers are setup and in play, the client should resort to turn communication. However, trying numerous configurations, can't seem to get the media to negotiate. I have included the full output of the Intel client below. Can you please advise if there is anything that needs to be done on the client or server? 

Used the following settings for the test:

[{"urls":
   ["turn:64.233.191.127:19305?transport=udp",
   "turn:[2607:f8b0:4001:c1a::7f]:19305?transport=udp",
   "turn:64.233.191.127:443?transport=tcp",
   "turn:[2607:f8b0:4001:c1a::7f]:443?transport=tcp"],
   "username":"CIDxoc0FEgbEqOQgsWwYzc/s6OMTIICjBQ",
   "credential":"ZSpyl7U5pAXm2EdV6oM33jJRwyI="},
{"urls":["stun:stun.l.google.com:19302"]}]

videosdk.webrtc.intel.debug - IntelWebRTCClient.isLibInUseByOtherProcess called args =[object Arguments]
videosdk.js:3167 videosdk.info - SDK.join - sPortal=map100.set.iconf.net, sKey=598a2e95452f2d0b37c9d954, sFeedId=3583337, bPin=false, nTimeoutPeriod=120000
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.join - join called args = {"0":"map100.set.iconf.net","1":"598a2e95452f2d0b37c9d954","2":3583337,"3":"","4":120000}
videosdk.js:3167 videosdk.info - SDK._setJoinState - Join state set - nState=1
videosdk.js:3167 videosdk.info - SDK._setJoinState - Join state set - nState=1
videosdk.js:3167 videosdk.info - SDK.join - bSuccess=true
videosdk.js:3167 videosdk.webrtc.intel.info - IntelWebRTCClient.join - got token=eyJ0b2tlbklkIjoiNTlhNzI5NjdkYWI3ZGUxMGJmMDlmOTk3IiwiaG9zdCI6Im13czEwMC5zZXQuaWNvbmYubmV0OjQ0MyIsInNlY3VyZSI6dHJ1ZSwic2lnbmF0dXJlIjoiT0dGbFlUVm1aRGhqWVRkak5ERTNPRE15WTJSak4ySmhZems1TlRoa05UYzJNR1ZrTlRjeU1qQTVOR014WlRjek5HRTROMlJpWW1VMVlXSmxaak16TVE9PSJ9
videosdk.js:3167 videosdk.info - SDK._setJoinState - Join state set - nState=2
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds called args =[object Arguments]
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds localStreams={} remoteStreams={"598a2e95452f2d0b37c9d954":{"bitRate":{},"from":""}}
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds: user in conference:{"id":"G7EfNCAxe-m_xsPqAAAA","name":"3583337","role":"presenter"}
videosdk.js:3167 videosdk.webrtc.info - StatTracker.startStatsCollection - starting stats collection
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds called args =[object Arguments]
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds localStreams={} remoteStreams={"598a2e95452f2d0b37c9d954":{"bitRate":{},"from":""}}
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds: user in conference:{"id":"G7EfNCAxe-m_xsPqAAAA","name":"3583337","role":"presenter"}
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.join - stream in conference:{"id":"598a2e95452f2d0b37c9d954","audio":true,"video":{"device":"mcu","resolutions":[{"width":640,"height":480}],"layout":[]},"attributes":{}}
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.join - user in conference:{"id":"G7EfNCAxe-m_xsPqAAAA","name":"3583337","role":"presenter"}
video.html:495 onJoined :: ready to pull down the list of videofeeds
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds called args =[object Arguments]
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds localStreams={} remoteStreams={"598a2e95452f2d0b37c9d954":{"bitRate":{},"from":""}}
videosdk.js:3167 videosdk.webrtc.intel.debug - IntelWebRTCClient.getAllVideoFeeds: user in conference:{"id":"G7EfNCAxe-m_xsPqAAAA","name":"3583337","role":"presenter"}
video.html:495 getAllVideoFeeds  sJsonVideoFeeds = [{"partid":"3583337","dispname":"3583337","uri":""},{"partid":"mixed","dispname":"mixed","uri":"598a2e95452f2d0b37c9d954","isMixed":true}]
VM192:8 Invalid frame rate value, ignored.
n @ VM192:8
c.create @ VM192:8
(anonymous) @ videosdk.js:4945
IntelWebRTCClient.startSelfView @ videosdk.js:4940
_callVideoClientApi @ videosdk.js:2330
SDK.startSelfView @ videosdk.js:1350
startSelfView @ video.html:1797
fOnClickVideo @ video.html:916
VM192:8 Stable!
VM192:8 Sending message {type: "offer", sdp: "v=0
↵o=- 7258079891256840682 2 IN IP4 127.0.0.1
↵s…3119 label:a2ad9923-b14b-42b9-ab4a-3d66524f699c
↵"}sdp: "v=0
↵o=- 7258079891256840682 2 IN IP4 127.0.0.1
↵s=-
↵t=0 0
↵a=group:BUNDLE video
↵a=msid-semantic: WMS i604o9Dy7uDPYgchM8XAG9oAckaFUTikkUvA
↵m=video 9 UDP/TLS/RTP/SAVPF 96 98 100 102 127 97 99 101 125
↵c=IN IP4 0.0.0.0
↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:izgr
↵a=ice-pwd:x//kWD9SJVTbviV2LSCrhoS/
↵a=ice-options:trickle
↵a=fingerprint:sha-256 58:0D:BA:3C:CE:6B:17:F8:CE:19:75:C4:28:29:5F:23:00:9B:8E:79:0F:C6:FA:25:E5:E1:C7:3A:46:0B:27:EE
↵a=setup:actpass
↵a=mid:video
↵a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
↵a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
↵a=extmap:4 urn:3gpp:video-orientation
↵a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
↵a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
↵a=sendrecv
↵a=rtcp-mux
↵a=rtcp-rsize
↵a=rtpmap:96 VP8/90000
↵a=rtcp-fb:96 ccm fir
↵a=rtcp-fb:96 nack
↵a=rtcp-fb:96 nack pli
↵a=rtcp-fb:96 goog-remb
↵a=rtcp-fb:96 transport-cc
↵a=rtpmap:98 VP9/90000
↵a=rtcp-fb:98 ccm fir
↵a=rtcp-fb:98 nack
↵a=rtcp-fb:98 nack pli
↵a=rtcp-fb:98 goog-remb
↵a=rtcp-fb:98 transport-cc
↵a=rtpmap:100 H264/90000
↵a=rtcp-fb:100 ccm fir
↵a=rtcp-fb:100 nack
↵a=rtcp-fb:100 nack pli
↵a=rtcp-fb:100 goog-remb
↵a=rtcp-fb:100 transport-cc
↵a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
↵a=rtpmap:102 red/90000
↵a=rtpmap:127 ulpfec/90000
↵a=rtpmap:97 rtx/90000
↵a=fmtp:97 apt=96
↵a=rtpmap:99 rtx/90000
↵a=fmtp:99 apt=98
↵a=rtpmap:101 rtx/90000
↵a=fmtp:101 apt=100
↵a=rtpmap:125 rtx/90000
↵a=fmtp:125 apt=102
↵a=ssrc-group:FID 3160000871 384613119
↵a=ssrc:3160000871 cname:bHEUgjAd446cGWDY
↵a=ssrc:3160000871 msid:i604o9Dy7uDPYgchM8XAG9oAckaFUTikkUvA a2ad9923-b14b-42b9-ab4a-3d66524f699c
↵a=ssrc:3160000871 mslabel:i604o9Dy7uDPYgchM8XAG9oAckaFUTikkUvA
↵a=ssrc:3160000871 label:a2ad9923-b14b-42b9-ab4a-3d66524f699c
↵a=ssrc:384613119 cname:bHEUgjAd446cGWDY
↵a=ssrc:384613119 msid:i604o9Dy7uDPYgchM8XAG9oAckaFUTikkUvA a2ad9923-b14b-42b9-ab4a-3d66524f699c
↵a=ssrc:384613119 mslabel:i604o9Dy7uDPYgchM8XAG9oAckaFUTikkUvA
↵a=ssrc:384613119 label:a2ad9923-b14b-42b9-ab4a-3d66524f699c
↵"type: "offer"__proto__: Object
VM192:9 Storing candidate:  1 {sdpMLineIndex: 0, sdpMid: "video", candidate: "a=candidate:649832045 1 udp 2122260223 10.0.13.142…879 typ host generation 0 ufrag izgr network-id 1"}
VM192:9 Set remote and local description v=0
o=- 0 0 IN IP4 127.0.0.1
s=IntelWebRTCMCU
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS qjLpKYTMBe
m=video 1 RTP/SAVPF 96 98 100 102 127
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:1 1 udp 2013266431 10.184.96.107 10000 typ host generation 0
a=ice-ufrag:dY74
a=ice-pwd:fL8rO8OXYzCTtdPFwWRXAb
a=fingerprint:sha-256 7A:21:91:13:D1:77:4C:7B:AB:92:7E:F4:A4:EE:DC:01:C4:BB:0C:8A:DE:9A:ED:7C:16:CD:0D:4A:D9:14:34:26
a=sendrecv
a=mid:video
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 goog-remb
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 goog-remb
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42e01f;packetization-mode=1
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 red/90000
a=rtpmap:127 ulpfec/90000
a=ssrc:55543 cname:o/i14u9pJrxRKAsu
a=ssrc:55543 msid:qjLpKYTMBe v0
a=ssrc:55543 mslabel:qjLpKYTMBe
a=ssrc:55543 label:qjLpKYTMBev0
a=ssrc:55555 cname:o/i14u9pJrxRKAsu
a=ssrc:55555 msid:qjLpKYTMBe v0
a=ssrc:55555 mslabel:qjLpKYTMBe
a=ssrc:55555 label:qjLpKYTMBev0

VM192:9 Candidates to be added:  0 []
VM192:9 Local candidates to send: 1
VM192:8 Sending message {type: "candidate", candidate: {…}}candidate: candidate: "a=candidate:649832045 1 udp 2122260223 10.0.13.142 54879 typ host generation 0 ufrag izgr network-id 1"sdpMLineIndex: 0sdpMid: "video"__proto__: Objecttype: "candidate"__proto__: Object
VM192:8 Sending message {type: "candidate", candidate: {…}}candidate: candidate: "a=candidate:1748523677 1 tcp 1518280447 10.0.13.142 9 typ host tcptype active generation 0 ufrag izgr network-id 1"sdpMLineIndex: 0sdpMid: "video"__proto__: Objecttype: "candidate"__proto__: Object
VM192:8 Sending message {type: "candidate", candidate: {…}}candidate: candidate: "a=candidate:2628927590 1 udp 25108479 64.233.191.87 26506 typ relay raddr 216.191.42.62 rport 4218 generation 0 ufrag izgr network-id 1"sdpMLineIndex: 0sdpMid: "video"__proto__: Objecttype: "candidate"__proto__: Object
VM192:8 MCU reports connection failed for stream: 169978084042668350

[Jianjun_Z_Intel]

Hi Eradj,

It looks like the connection between your client and TURN server works since there is a relay candidate collected. I guess something went wrong in the server side. If your server also deployed in a network with NAT, please try to config STUN/TURN at server side as well.

[Eradj_K_]

Hello Jianjun Z.,

Thank you for your reply. I have reviewed configuration for 3.4.1 and unable to deduce the configuration file that should be used to set the turn server. I was able to find webrtc_agent/agent.toml, but the section only defines a STUN server. Also does the turn server need to support TURNS, or just TURN is sufficient. Although clientSDK reports "MCU reports connection failed for stream", but the local stream/camera is ON, seems it is in the broadcasting state. Another observation when local offer is set the candidates for the MCU reported using UDP only, without any references to relay or even tcp. I am suspecting that's where the problem might be. If by chance your team tested a valid configuration for "coturn" server, would you be able to share it? Any help would be much appreciated. Thank you so much! 

[Jianjun_Z_Intel]

Hi Eradj,

"MCU reports connection failed..." means the WebRTC connection fails or there is something wrong happened at server side. It does not stop local stream, so the camera is still on.

[Eradj_K_]

Hello Jianjun, Can you please indicate what file and where to specify the actual turn server to use from the server side in the Intel WebRTC CS config?

[Eradj_K_]

Hi there, 

Could anyone please specify how to configure a turn server from the server perspective? 

[Jianjun_Z_Intel]

Hi Eradj,

Sorry for the late reply. For MCU server, we considered it is unlike WebRTC client, usually directly serve with public IP or only STUN support is enough. Server side deployment need TURN support is not typical.

[Eradj_K_]

Hi Jianjun,

I guess I got a bit confused by your comment: " If your server also deployed in a network with NAT, please try to config STUN/TURN at server side as well.". Configuration that we are running includes a STUN server already. How would we go about troubleshooting this issue: "M192:8 MCU reports connection failed for stream: 169978084042668350". We have attempted to enable debug logging, but can't really see that anything changed in the logs. Would  you advise on the logs level and components that would normally be helpful in these cases? 

[Jianjun_Z_Intel]

Hi Eradj,

The ICE component we are using at MCU side is libnice. If you need detailed log about how ICE works in your data center, you probably need to enable log for libnice. It can be achieved by setting environment variables. We assume MCU server, or at least WebRTC agent, is deployed in a public network so TURN support at server side is not highly prioritized at this time.