Solved

Inquiry regarding communication between InRobot server and our client PC

  • 6 July 2023
  • 9 replies
  • 104 views
I
Rank
Badge

I am writing to inquire about the communication process of InRobot between your servers and our client PC. We have encountered an issue where our client PC, connected to our internal LAN, are unable to receive video streaming from InRobot application Server when using InRobot application.

 

Upon investigation, we have determined that there seems to be an issue with the communication between your servers and our client PC. We have tested the network connectivity, and all other aspects of the application appear to be functioning correctly except for the video streaming. Could you please provide us with detailed information about the communication that occurs between your servers and our client PC? Specifically, we would like to understand the protocols and methods involved in transmitting data from the server to the client PCs. This knowledge would greatly assist us in troubleshooting and resolving the issue at hand.

 

Thank you in advance for your prompt attention to this matter. We look forward to your response and appreciate any assistance you can provide.

icon

Best answer by Niek Beckers 25 July 2023, 15:29

View original

9 replies

E
Rank

Hi, thanks for reaching out. We have this overview of the URL and what connections are needed: 

 

  1. Download docker images:

    • URL: registry-1.docker.io
    • Protocols: HTTPS, TCP
    • Ports: 443

  2. Video stream:

    • URLs: eu.robotics.cognitedata.com OR us.robotics.cognitedata.com
    • Protocols: RTP, UDP
    • Ports: 20000-40000, 5000-5050

  3. Video signaling:

    • URLs: eu.robotics.cognitedata.com 
    • Protocols: HTTPS, TCP
    • Ports: 443

  4. Cognite API:

    • URLs: {cognite cluster}.cognitedata.com (example: api.cognitedata.com)
    • Protocols: HTTPS, GRPC, TCP
    • Ports: 443

  5. Azure auth:

    • URL: login.microsoftonline.com
    • Protocols: HTTPS, TCP
    • Ports: 443

 

The laptop using InRobot will also need to have whitelisted: Video stream, Video signaling, Cognite  and Azure auth. I have also added a architecture drawing where you see the interaction between Inrobot, CDF, videostream and the robot. 
 

 


In addition I would recomend using firefox for debuging. If you visit “about:webrtc” url on firefox you get to a webrtc debugging tool where you can see what is failing for your webrtc connection. Then you can see if it is the signaling or stream which is failing and thus what ports that are blocking. If you also share a screen shot we could potentially help and have a look

https://www.webrtc-developers.com/debugging-webrtc-in-the-browsers/#firefox-aboutwebrtc

 

Hope this information helps and thanks againg for reaching out! 

I
Rank
Badge

Thank you for providing us with the information and the architecture drawing. We have reviewed the details and have a few follow-up inquiries and concerns regarding the video streaming communication.

Firstly, although we have already whitelisted the Video Streaming communication, we are still unable to view the video feed within the application. Furthermore, your Japanese support team had identified packet loss occurring within your server logs. We would appreciate further guidance or troubleshooting steps to resolve this issue.

Regarding the system architecture diagram, it appears that WebRTC communication is established from the Enterprise WebRTC media server to the client PCs. We would like to confirm if this interpretation is correct. Allowing communication from the internet to our internal LAN violates the security policies defined within our organization. We need to make any communication with external resources adhere to our established security guidelines. Therefore, Understanding the establishment of the session between the Enterprise WebRTC media server and the client PCs is of importance to us. Could you please provide detailed insights into how this session is established? Additionally, I want to highlight that I do not have our global IP address configured within InRobot App. Consequently, I believe it is not possible for the Enterprise WebRTC media server to establish a session with the client PCs directly.

Thank you for your continued support and prompt attention to our concerns. We eagerly await your response and any further assistance you can provide.

N
Rank
Userlevel 1

Hi! Thank you for your patience. Please see our answers below. 

Regarding the system architecture diagram, it appears that WebRTC communication is established from the Enterprise WebRTC media server to the client PCs. We would like to confirm if this interpretation is correct.


Yes, your interpretation is correct. The video stream service sets up a direct bidirectional WebRTC between the media server and the client PC. Each WebRTC connection is authenticated and encrypted.

 

## Session setup

Therefore, understanding the establishment of the session between the Enterprise WebRTC media server and the client PCs is of importance to us. Could you please provide detailed insights into how this session is established?

 

We follow the WebRTC protocol, which roughly consist of the following four sequential steps (see this reference a more comprehensive overview and details):

  1. Signalling
  2. Connection
  3. Securing
  4. Communicating

Each sequential step needs to be 100% successful in order to establish a secure video stream between peers (the client PC and the media server).

During signalling, the client PC and server reach out to each other to exchange the Session Description Protocol (SDP). The signaling is authenticated using OIDC on Azure AD and the communication is encrypted using TLS. Once the signaling is complete, the initial handshake between peers is secured with DTLS.


After signalling is completed successfully, the connecting step starts, in which a bidirectional connection is set up between the client and the server. The process described above is called Interactive Connectivity Establishment (ICE). Each ICE Agent publishes the ways it is reachable, these are known as candidates. A candidate is essentially a transport address of the agent that it believes the other peer can reach. ICE then determines the best pairing of candidates. This page describes in more detail what the substeps and requirements of that connection are.

Specific to InRobot, the STUN server for candidate identification we use is stun:stun2.l.google.com:19302, for which both URL and port might need to be whitelisted in addition to the ones described above. Our TURN servers’ URLs are `*.robotics.cognitedata.com`, with port range 20000-40000, 5000-5050, UDP and RTP (as listed in the previous answer).

Communication. Media (video and audio) are encrypted using SRTP.

The likely reason you cannot see the video stream is because your firewall is blocking the traffic in one of the above mentioned stages. Most likely, your firewall is blocking the RTP packets sent via UDP.

Lastly, you can consider setting up a DMZ in your corporate network specific for InRobot.

We’re happy to help identify the solution for the video streaming, please let us know if you have additional questions!

I
Rank
Badge

Thank you for the detailed response and explanations regarding the Video Streaming using the WebRTC media server. We greatly appreciate your assistance in clarifying the communication process.

To ensure we have a complete understanding, could you please confirm whether the session setup for Video Streaming occurs from the LAN to the internet? Understanding the direction of this communication will help us verify if our firewall blocks the Video Streaming. We noted that even in cases of bidirectional communication, if the session is established from the LAN to the internet direction, the firewall does not block the traffic. In our experimentation environment, we have confirmed that despite internet-to-LAN communication being blocked by our firewall, we are still able to utilize the Video Streaming feature of InRobot.

In our experimentation environment, the firewall passes all communication from the LAN to the internet, while blocking all traffic from the internet to the LAN. On the other hand, within our internal LAN, the firewall only passes HTTP/HTTPS communication from the LAN to the internet, and all incoming traffic from the internet to the LAN is blocked.

Given these firewall configurations, it appears that the firewall settings in our internal LAN are likely the cause of Video Streaming not functioning properly within our corporate network. Specifically, the limited permission for LAN-to-Internet communication other than HTTP/HTTPS within our internal LAN may be preventing the necessary communication required for Video Streaming in InRobot.

Once again, we appreciate your support and expertise in resolving these technical matters. Your continued guidance is highly valued.

I
Rank
Badge

Hello,

I would be grateful if you could let us have your answer concerning this matter. Could you please provide me with an update on the status of this matter?

E
Rank

Irie, 

So sorry for the late reply! 

I have reached out to our engineers again to get a propper answer, will get back to you as soon as possible. 

N
Rank
Userlevel 1

Hi Irie,

Yes, your analysis seems reasonable. 

To help us understand the problem better and to confirm your analysis, could you run the following web test and share a screenshot (ideally in your internal and experiment environment)? https://networktest.twilio.com/ 

These tests check your browser and network configuration with respect to WebRTC. We are moving our video streaming service to Twilio, and these network tests will test basic- as well as Twilio-specific requirements. This will confirm whether the initial signalling works (which is LAN → internet), as well as the UDP and TCP or TLS connectivity for the resulting session. 

Thank you again for your patience.

C
Rank
Userlevel 3

Hi @Irie, do you need any further help from us?

I
Rank
Badge

Thank you for your support and the suggested web test. I appreciate your assistance in resolving the Video Streaming issue.

I will perform the tests as you've recommended. Please allow me some time to complete them.

Your patience is greatly appreciated, and I'll keep you updated on the progress and results.

Reply


Terms & ConditionsCookie Settings