Mixedreality-webrtc: Receiving Video Stream From Non Local Network

Created on 14 Apr 2020  路  7Comments  路  Source: microsoft/MixedReality-WebRTC

Hi,
I am trying to implement the VideoChatDemo in Unity UWP platform. The project is working properly when two laptops are connected in the same network. But I am trying to receive a video stream to a laptop running the same exact project but connected to a different network (A friend of mine in fact residing in the other end of the city). I guessed that it would not work with the current setup. But I do not know how to make it work. Could anyone please help me with this?

I don't know if this is the correct platform to pose this question but I did not find any good forum about this topic so I am asking it here

question

All 7 comments

There is not much different between a local and non-local network. The only thing that may be different is if one of you is behind a NAT, in which case you need to setup a STUN server for NAT punching in PeerConnection.IceServers. What signaler are you using? node-dss / NodeDssSignaler? You need to make sure that the NodeDssSignaler.HttpServerAddress is valid for both peers, that is one of them at least has the HTTP address of the node-dss server instead of 127.0.0.1. And of course make sure the node-dss is reachable from the outside, so that the other peer can connect to it (so check Windows firewall for NodeJS, _etc._).

Hi,
I am using node-dss / NodeDssSignaler
As I said before in my other issue, I am very new to this. So could you explain how to check if one of the systems is behind a NAT please? I think I can Google how to setup a STUN server for NAT punching so I will do that now.

And also, I was using the public IP of the other system in both systems. As in:
System A Http server address : http://<System_B_Public_IP>/3000
System B Http server address : http://<System_A_Public_IP>/3000

I got the public IP by searching my IP in google.

And also using the other system name for the remote peer connection.

All I am getting is:
Network error trying to send data to http://122.163.54.154/3000/: Cannot connect to destination host

Is there something wrong I am doing?

No, the NodeDssSignaler.HttpServerAddress is the address of the node-dss server, not the address of the other peer. You need to have 1 machine run node-dss somewhere, possibly on your PC, and then both peers need to use the IP address of that machine. Both peers will talk to the node-dss server to discover each other, so they don't need each other's IP. In general the signaling server is deployed in some cloud instance or similar, so that all participants can reach it at a known stable public IP address. For testing generally one PC is hosting the node-dss server locally instead, so that PC can use 127.0.0.1 as a shortcut (or use the actual PC IP address, it's the same), and the other use the IP of that PC too to be able to reach the node-dss server.

There is no need to setup a STUN server, you can use the public Google one for testing stun.l.google.com:19302. Don't deploy to production with it though, you'll likely get blocked by Google. It's for testing/debugging only AFAIK.

Hi, Sorry for the delayed reply, I have fever for the last two days. But I am testing it out today and I am facing some problems that I cannot overcome again.

I am running the node-dss server from the remote PC, that is my friend's Laptop. And when I hit the Create Offer Button, I am getting the log below in the command prompt:

dss:body {"MessageType":3,"Data":"candidate:4278134664 1 udp 2122260223 192.168.1.8 53206 typ host generation 0 ufrag hHfk network-id 1 network-cost 10|0|0","IceDataSeparator":"|"} +1m
  dss POST /data/KTPL-LAP-210 200 - - 1.029 ms +445ms
  dss:body {"MessageType":1,"Data":"v=0\r\no=- 5278331949767623427 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0 1\r\na=msid-semantic: WMS local_av_stream\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 102 0 8 106 105 13 110 112 113 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:hHfk\r\na=ice-pwd:MWGuhHc/3fnY2v1CWfblWnk2\r\na=ice-options:trickle\r\na=fingerprint:sha-256 7E:7C:54:06:53:F3:45:E4:0D:99:63:C7:4F:FC:87:64:BB:AB:F9:AC:34:24:EF:4A:09:67:F1:B0:F5:B7:E6:98\r\na=setup:actpass\r\na=mid:0\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=sendrecv\r\na=msid:local_av_stream local_audio\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=rtcp-fb:111 transport-cc\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:9 G722/8000\r\na=rtpmap:102 ILBC/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:110 telephone-event/48000\r\na=rtpmap:112 telephone-event/32000\r\na=rtpmap:113 telephone-event/16000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:2361494280 cname:opzNWNKteYqafmqL\r\na=ssrc:2361494280 msid:local_av_stream local_audio\r\na=ssrc:2361494280 mslabel:local_av_stream\r\na=ssrc:2361494280 label:local_audio\r\nm=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127 124 125\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:hHfk\r\na=ice-pwd:MWGuhHc/3fnY2v1CWfblWnk2\r\na=ice-options:trickle\r\na=fingerprint:sha-256 7E:7C:54:06:53:F3:45:E4:0D:99:63:C7:4F:FC:87:64:BB:AB:F9:AC:34:24:EF:4A:09:67:F1:B0:F5:B7:E6:98\r\na=setup:actpass\r\na=mid:1\r\na=extmap:2 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:4 urn:3gpp:video-orientation\r\na=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type\r\na=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing\r\na=extmap:10 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07\r\na=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=sendrecv\r\na=msid:local_av_stream local_video\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:96 VP8/90000\r\na=rtcp-fb:96 goog-remb\r\na=rtcp-fb:96 transport-cc\r\na=rtcp-fb:96 ccm fir\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtpmap:97 rtx/90000\r\na=fmtp:97 apt=96\r\na=rtpmap:98 VP9/90000\r\na=rtcp-fb:98 goog-remb\r\na=rtcp-fb:98 transport-cc\r\na=rtcp-fb:98 ccm fir\r\na=rtcp-fb:98 nack\r\na=rtcp-fb:98 nack pli\r\na=fmtp:98 x-google-profile-id=0\r\na=rtpmap:99 rtx/90000\r\na=fmtp:99 apt=98\r\na=rtpmap:100 multiplex/90000\r\na=rtcp-fb:100 goog-remb\r\na=rtcp-fb:100 transport-cc\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100 nack\r\na=rtcp-fb:100 nack pli\r\na=fmtp:100 acn=VP9;x-google-profile-id=0\r\na=rtpmap:101 rtx/90000\r\na=fmtp:101 apt=100\r\na=rtpmap:127 red/90000\r\na=rtpmap:124 rtx/90000\r\na=fmtp:124 apt=127\r\na=rtpmap:125 ulpfec/90000\r\na=ssrc-group:FID 2469760159 1160967364\r\na=ssrc:2469760159 cname:opzNWNKteYqafmqL\r\na=ssrc:2469760159 msid:local_av_stream local_video\r\na=ssrc:2469760159 mslabel:local_av_stream\r\na=ssrc:2469760159 label:local_video\r\na=ssrc:1160967364 cname:opzNWNKteYqafmqL\r\na=ssrc:1160967364 msid:local_av_stream local_video\r\na=ssrc:1160967364 mslabel:local_av_stream\r\na=ssrc:1160967364 label:local_video\r\n","IceDataSeparator":""} +2ms
  dss POST /data/KTPL-LAP-210 200 - - 4.197 ms +2ms
  dss:body {"MessageType":3,"Data":"candidate:4278134664 1 udp 2122260223 192.168.1.8 53207 typ host generation 0 ufrag hHfk network-id 1 network-cost 10|1|1","IceDataSeparator":"|"} +2ms
  dss POST /data/KTPL-LAP-210 200 - - 0.527 ms +2ms
  dss GET /data/KTPL-LAP-207 404 - - 0.104 ms +77ms
  dss:body {"MessageType":3,"Data":"candidate:1470146653 1 udp 1686052607 122.163.54.154 53207 typ srflx raddr 192.168.1.8 rport 53207 generation 0 ufrag hHfk network-id 1 network-cost 10|1|1","IceDataSeparator":"|"} +95ms
  dss POST /data/KTPL-LAP-210 200 - - 0.589 ms +18ms
  dss:body {"MessageType":3,"Data":"candidate:1470146653 1 udp 1686052607 122.163.54.154 53206 typ srflx raddr 192.168.1.8 rport 53206 generation 0 ufrag hHfk network-id 1 network-cost 10|0|0","IceDataSeparator":"|"} +3ms
  dss POST /data/KTPL-LAP-210 200 - - 0.959 ms +3ms
  dss:body {"MessageType":3,"Data":"candidate:2960972664 1 tcp 1518280447 192.168.1.8 62495 typ host tcptype passive generation 0 ufrag hHfk network-id 1 network-cost 10|0|0","IceDataSeparator":"|"} +2ms
  dss POST /data/KTPL-LAP-210 200 - - 1.369 ms +3ms
  dss:body {"MessageType":3,"Data":"candidate:2960972664 1 tcp 1518280447 192.168.1.8 62496 typ host tcptype passive generation 0 ufrag hHfk network-id 1 network-cost 10|1|1","IceDataSeparator":"|"} +3ms

My system name is KTPL-LAP-210 and the remote system is KTPL-LAP-207.

But when I am trying running the project on my side, it is giving the below error:

Network error trying to send data to http://122.163.54.154/3000/: Cannot connect to destination host

I got the IP by searching my IP in the remote laptop.

Please help me out if I am doing something wrong.

Edit
I turned on VPN on my system and now I am getting this error
Network error trying to send data to http://192.168.1.8/3000/: Received no data in response
Network error trying to send data to http://122.163.54.154/3000/: Received no data in response

This time I actually tried getting IP from ipconfig and google search my IP both. And both are giving the same result.

I also checked Windows Firewall Advanced Settings, Apparently the Unity Editor was blocked from Incoming connection and I also disabled the rule. But I am still getting same error.

Please help

I have gotten this working across cellular networks with a signaling server running in my house with a public accessible domain name. A few things to keep in mind. You have to make sure there is a port forwarding rule on your internet router to route traffic to the signaling server behind it. Second, the first google stun server has never worked for me. Try the second one in the list of stun servers that you can search for.

Hi, Sorry for the delayed reply. I had a very bad case of fever last couple of days. Currently my issue is same as #284 I can start the video in Local Network But not in remote network. I am checking Firewall settings and port forwarding to see if that is the case. Will update how it goes.

And it goes without saying, thank you so much @djee-ms and @astaikos316 for all your help. It really made me learn a lot of new things.

Hi, For now I have stopped looking for the remote connection problem. I am facing another problem. Please let me know if this warrants a new issue log. I will close this one then and open a new issue.

I am trying to create a particular situation Where one build is deployed in a Windows standalone machine and sending video from the webcam and another build is deployed in Hololens Emulator which is just receiving the video stream and showing on screen.

But while running, I am receiving the following error in the development console.
image

I am guessing that this is due to HoloLens Emulator not being able to access the webcam of the host computer. I am searching for a way so that it will bypass the video capture device and not throw an error.

Till now I have found the CreateOffer() function which is in metadata so I cannot see it's body. Could you please point me in the correct direction to achieve this?

Thanks in advance.

Was this page helpful?
0 / 5 - 0 ratings