[BUG] - Connection issue on LAN in network restricted environment

[luming222]

UE Version: E.g. UE 5.1.1

Frontend Version: E.g. UE5.3-0.3.0

Problem component E.g. Signalling Server, Frontend, Pixel Streaming C++ plugin

Description WEBRTC CONNECTION NECOTIATED

Steps to Reproduce:

1. The environment is configured as a back-end computer to deploy the UE5 push service. The front-end machine obtains the UE5 push service, but the overall process is deployed on the LAN, and the front-end machine is not connected to the public network
2. After I open the pixel stream service at the back end, the front end has already received it, but it will be stuck in the "WEBRTC CONNECTION NEGOTIATED" page. When I open the front-end developer tool, I initially find that several front-end pages are missing, like font libraries. Later I think the network administrator has applied for access to 'fonts.gooleapis.com','fonts.gstatis.com' but there is a new problem later, fonts is obtained but seems to be of no use
3. I would like to ask if the front-end browser needs to request external resources of the public network when it is displayed, because it is deployed in the internal network, the front-end machine may intelligently access specific urls to obtain resources, and whether these urls can be explained

Expected behavior

Screenshots If applicable, add screenshots to help explain your problem.

Platform (please complete the following information):

Additional context

[lukehb]

And does this occur is you use the latest version of PixelStreamingInfrastructure repository from master branch too?

[lukehb]

Can you attach a larger version of the first screenshot? The resolution is too low to read it clearly.

[luming222]

你能附上第一个屏幕截图的更大版本吗？分辨率太低，无法清晰阅读。

[luming222]

[lukehb]

Okay thanks!

Yes, as I said before, can you try using the latest version of PixelStreamingInfrastructure repository from master branch too to see if the problem happens there too?

[luming222]

@lukehb I have opened the network of the front-end machine, but in this case, can you ask what network ports need to be opened if the back-end UE5 is the server? I wonder if it is because the network ports are not fully opened

[lukehb]

This is not a ports issue. It looks to be a failure in the JavaScript side. I note you are using mismatched versions of UE and frontend (UE 5.1.1) and 5.3-0.3.0 for the frontend, this is not recommended. I am trying to determine if a newer frontend version will fix this for you. If it does not, I would also ask you to try the frontend version for 5.1.

[luming222]

@lukehb Thank you for remembering now that my UE5 is version 5.1, but the signaling server is displayed above 5.2, but there is no problem in my local LAN test. Now this problem occurs when I deploy the test environment, so I always suspected that it was a network problem. I will now try to pull the master branch for operation if you can solve the problem I would be very gratefu

[lukehb]

Please match all three components: signalling server, UE, and frontend to the same version if possible. If not possible, please try the latest signalling server and frontend from master.

[luming222]

@lukehb Excuse me, I found out that my pixel stream is the result of the packaging of the UE5 plugin, but it works on my local LAN, but it does not work in the test environment. I feel that it is not a version mismatch problem. It may be that the relevant front-end library is not linked to，Because there was a guy who had the same problem before but he solved the problem after connecting to a library and I tried to contact him to solve it

[lukehb]

Okay if all components are a result of packaging that should be fine.

Next things to try is in the case where it does not connect could you open chrome://webrtc-internals and share the ICE candidate grid that is displayed. This should tell us if there is a network connectivity issue or not.

[luming222]

Okay if all components are a result of packaging that should be fine.

Next things to try is in the case where it does not connect could you open chrome://webrtc-internals and share the ICE candidate grid that is displayed. This should tell us if there is a network connectivity issue or not.

@lukehb There seems to be a problem here

[lukehb]

Okay, yes, there does seem to be a network connectivity issue between the two machines.

WebRTC will try to open a UDP connection on a random port between 49152 and 65535. This is not configurable in UE 5.1, if you upgrade to UE 5.4 it can be configured though.

Windows firewall can also block the incoming/outgoing connections on the browser/UE side so you may wish to disable that or add an exception.

[luming222]

@lukehbHello, I am still waiting for the administrator to enable the UDP related port on my UE5 machine. However, I tested it on my own local LAN and found that there seems to be no development of the UDP related port on UE5

[lukehb]

You can verify the connection type by starting Pixel Streaming and connecting and then going to chrome://webrtc-internals and expanding the ICE candidate grid and looking for the connected candidate pair. You will note the column called "protocol/candidate type".

This table will show you the transport protocol used (e.g. TCP/UDP) and the ports used on both sides.

HOST candidate means a connection using your local addresses (which is what you would expect over LAN).

[luming222]

My display is as shown in the picture @lukehb

[lukehb]

The above image is between the two machines that do not successfully connect, correct? As you can see it is trying to perform a connection on the local machine (browser) on UDP port 9 and then in next candidate pair on 49893. As I mentioned above, you will have to get your network admin to open UDP ports in the range 49152-65535.

If you would like, you can also check the ICE candidate grid from the case where a successful connection is made (e.g. all running on the same machine) and you can note the transport protocol and ports used in a successful connection case.

[luming222]

@lukehb Is it the UDP port of the machine where UE5 is deployed？

[lukehb]

In the table above the:

• "local-candidate" are addresses and ports it is trying on the web browser (e.g. in the image above UDP port 9)
• "remote-candidate" are addresses and ports it is trying on the UE machine (e.g. in the image above UDP port 56747)

[lukehb]

Both sides need UDP ports accessible for inbound and outbound UDP traffic.

[luming222]

@lukehb I'm sorry to bother you for so long. Since I've just been in contact with this, I still don't quite understand. Is it because the port over there is not open, as shown in the picture? Is it because neither side of the machine is open or one is not open

[lukehb]

Is it because the port over there is not open?

Is it because neither side of the machine is open?

or one is not open?

I can't know the answer to any of those from my side and neither can WebRTC. Only you (or your network adminstrator) can tell if you have the UDP ports open or not.

I can tell you in order to connect both your local machine and the UE machine must allow inbound and outbound traffic on UDP ports in the range 49152-65535.

[luming222]

@lukehb I switched to version 5.1 signaling and related content

[luming222]

@lukehb He's much better now than before

[luming222]

@lukehb Now the network is connected, the right is my local test, it's normal, the left is abnormal, there is no transmission, it seems that there are two missing data, I think maybe the problem will be here

[luming222]

@lukehb I'm sorry that the last message was sent incorrectly The left is correct, and the right is the machine that cannot be displayed

[lukehb]

Unfortunately those screenshots do not have any useful information in them (the ICE candidate grid that I showed you above it more useful for debugging network connectivity). Have you (or your network admin) opened the ports I mentioned?

[luming222]

I think I may have found the problem, but it's a bit strange because during the local testing, there was no TCP involved. Now I realize that the TCP port is not open, and my understanding is correct. Is the pixel flow possible to be useful in the entire ICE process during webrtc sdp negotiation? TCP

[luming222]

@lukehb

[lukehb]

TCP being closed should be okay. WebRTC can use TCP in some browsers, but it is not the recommended way as transmission is much slower in congestion or case of packet loss. Having only the UDP ports open should be acceptable.

[github-actions[bot]]

Issues go stale after 30 days of inactivity. Please comment or re-open the issue if you are still interested in getting this issue fixed.