Wowza WebRTC issues through NAT. Related to a lack of full STUN ?

Hi guys.

I am having issue getting the WebRTC Play sample working through our corporate firewall. Wowza installation lives on a local IP address which is NATed to a public facing IP address.

Locally the stream works perfectly, but not outside the firewall.

I have the certificate issued to the public IP address and I can happily access the example play page on my Wowza via streamlock DNS alias, but the actual video/audio stream wont work for the life of me.

I am using Chrome for this test.

my configuration in WebRTC Application:

[HTML]

webrtcIceCandidateIpAddresses 10.23.205.221|{PUBLIC_IP},UDP String webrtcUDPBindAddress 0.0.0.0 String [/HTML] I have tried **webrtcUDPBindAddress** to be set to the same IPs as the **webrtcIceCandidateIpAddresses** but that made no difference. I have also tried using TCP instead of UDP in **webrtcIceCandidateIpAddresses** but again to no success. Looking at the console output on a client outside my firewall, where I a trying to play the stream, I don't see any issues. Almost identical response I get locally and the stream plays fine here is the console output: [HTML] startPlay: wsURL:wss://xxxxxxxxxx.streamlock.net/webrtc-session.json streamInfo:{"applicationName":"webrtc","streamName":"rtsp01.stream","sessionId":"276464373"} wsConnection.onopen wsURL: wss://xxxxxxxxxxx.streamlock.net/webrtc-session.json sendGetOffer: {"applicationName":"webrtc","streamName":"rtsp01.stream","sessionId":"276464373"} wsConnection.onmessage: {"status":200,"statusDescription":"OK","direction":"play","command":"getOffer","streamInfo":{"applicationName":"webrtc/_definst_","streamName":"rtsp01.stream","sessionId":"418944370"},"sdp":{"type":"offer","sdp":"v=0\r\no=WowzaStreamingEngine-next 1775640611 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 15:E9:03:E5:63:2D:15:F7:67:8F:AE:93:7E:53:D7:AB:16:DD:43:D2:4D:E5:DE:66:7E:1F:02:25:38:58:FC:2D\r\na=group:BUNDLE video audio\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=video 9 RTP/SAVPF 97\r\na=rtpmap:97 H264/90000\r\na=fmtp:97 packetization-mode=1;profile-level-id=4D401F;sprop-parameter-sets=Z01AH/QCgF35cBEAAAMAAQAAAwAy4mAA9CQAHoTkogD4sXU=,aN48gA==\r\na=cliprect:0,0,720,1280\r\na=framesize:97 1280-720\r\na=framerate:25.0\r\na=control:trackID=2\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:7b9ea5ad0a123a09b0bc7ef4aa11c3b6\r\na=ice-ufrag:c8602c50\r\na=mid:video\r\na=msid:{c04dd407-13d1-4726-8b08-6941127c939f} {3f6af38d-9280-4eb4-a5c8-0a710a8e2d65}\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:1421411033 cname:{b153d842-c4d1-41b6-ad98-ce94fc0fed34}\r\nm=audio 9 RTP/SAVPF 96\r\na=rtpmap:96 OPUS/48000/2\r\na=control:trackID=1\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:7b9ea5ad0a123a09b0bc7ef4aa11c3b6\r\na=ice-ufrag:c8602c50\r\na=mid:audio\r\na=msid:{c04dd407-13d1-4726-8b08-6941127c939f} {d6c3e53f-a4bf-45c0-8936-a90644790815}\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:295612224 cname:{b153d842-c4d1-41b6-ad98-ce94fc0fed34}\r\n"}} sdp: {"type":"offer","sdp":"v=0\r\no=WowzaStreamingEngine-next 1775640611 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 15:E9:03:E5:63:2D:15:F7:67:8F:AE:93:7E:53:D7:AB:16:DD:43:D2:4D:E5:DE:66:7E:1F:02:25:38:58:FC:2D\r\na=group:BUNDLE video audio\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=video 9 RTP/SAVPF 97\r\na=rtpmap:97 H264/90000\r\na=fmtp:97 packetization-mode=1;profile-level-id=4D401F;sprop-parameter-sets=Z01AH/QCgF35cBEAAAMAAQAAAwAy4mAA9CQAHoTkogD4sXU=,aN48gA==\r\na=cliprect:0,0,720,1280\r\na=framesize:97 1280-720\r\na=framerate:25.0\r\na=control:trackID=2\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:7b9ea5ad0a123a09b0bc7ef4aa11c3b6\r\na=ice-ufrag:c8602c50\r\na=mid:video\r\na=msid:{c04dd407-13d1-4726-8b08-6941127c939f} {3f6af38d-9280-4eb4-a5c8-0a710a8e2d65}\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:1421411033 cname:{b153d842-c4d1-41b6-ad98-ce94fc0fed34}\r\nm=audio 9 RTP/SAVPF 96\r\na=rtpmap:96 OPUS/48000/2\r\na=control:trackID=1\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:7b9ea5ad0a123a09b0bc7ef4aa11c3b6\r\na=ice-ufrag:c8602c50\r\na=mid:audio\r\na=msid:{c04dd407-13d1-4726-8b08-6941127c939f} {d6c3e53f-a4bf-45c0-8936-a90644790815}\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:295612224 cname:{b153d842-c4d1-41b6-ad98-ce94fc0fed34}\r\n"} gotRemoteStream: [object MediaStream] gotDescription sendAnswer wsConnection.onmessage: {"status":200,"statusDescription":"OK","direction":"play","command":"sendResponse","streamInfo":{"applicationName":"webrtc/_definst_","streamName":"rtsp01.stream","sessionId":"418944370"},"iceCandidates":[{"candidate":"candidate:0 1 UDP 50 10.23.205.221 7008 typ host generation 0","sdpMid":"","sdpMLineIndex":0},{"candidate":"candidate:0 1 UDP 49 {PUBLIC_IP} 7008 typ host generation 0","sdpMid":"","sdpMLineIndex":0}]} webrtc.js:144 iceCandidates: {"candidate":"candidate:0 1 UDP 50 10.23.205.221 7008 typ host generation 0","sdpMid":"","sdpMLineIndex":0} webrtc.js:144 iceCandidates: {"candidate":"candidate:0 1 UDP 49 {PUBLIC_IP} 7008 typ host generation 0","sdpMid":"","sdpMLineIndex":0} webrtc.js:160 wsConnection.onclose [/HTML] I can see there is a known issue with the NAT in Firefox: "*If using IP Network Address Translation (NAT)boundaries, where the Wowza Streaming Engine instance has a private address but a public address is used for access, WebRTC may not work when using the public IP address*" Is the same applicable to Chrome ? and if so, does this have anything to do with the lack of full STUN support? and if so again, when can we expect to see it implemented. Thanks Svyatko

Svyatko,

Where you able to resolve your issue - if so how? I am experiencing the same issue.

Tim

Wowza is sending stream on UDP port 7008 and your firewall is blocking that port on your network.

actually, if you chose to use UDP for WebRTC, wowza allocates ports dynamically in the range starting from 6970, onwards.

I have managed to get this working in latest Wowza 4.7.3 using WebRTC over TCP @ 1935 and then with network’s team mercy over UDP by opening a range 6970-10000. Every new UDP connection will get a new UDP port, so the whole range needs to be open.

TBH, for the sake of simplicity on the NAT and networking TCP is ideal, but it only works with Chrome. FF doesnt like WebRTC over TCP from wowza, but works well with UDP.

1 Like