|443||WSS, HTTPS||*.senso.cloud||Services on these addresses provide front-end and back-end functionality.|
|443||WSS, HTTPS||*.service.signalr.net||Required for client communication.|
|443||HTTPS||sensoeugeneral.blob.core.windows.net||Required for general storage functionality.|
|443||HTTPS||sensoeustorage.blob.core.windows.net||Required for downloading modules.|
|443||HTTPS||sensologarchivestorage.blob.core.windows.net||Required to view archived logging data.|
|443, 3478||UDP, STUN, TURN, HTTPS||ne-1-turn.senso.cloud|
The default server will be determined by the URL your portal uses. For example, if you are directed to https://ne-1.senso.cloud after logging in you will use the ne-1-turn.senso.cloud TURN server.
|Required for live thumbnails and module feedback.|
|30100||TCP||The Broadcast Sender will listen on the Port and the Receiver will connect to that Port. Senso will attempt to make the local Windows firewall change automatically on the Sender PC.||Only used for Screen Broadcasting when both Sender and Receiver are on the same LAN.|
How can I specify a proxy server for the senso client to use?
The senso client will make every effort to detect the correct proxy settings to use, however, it may occasionally be required to override these. To do this please follow the instructions in the article here - How to specify a proxy server for the senso client to use
How does the senso client route traffic?
The senso client uses 3 methods for making a secure connection between the client and the console.
Where possible WebRTC will attempt to connect using host candidates, which will keep traffic local to the network. In scenarios where this is not possible; restrictive VLANs, guest networks, over the Internet, etc... then it will attempt to connect using server reflexive candidates. To do this WebRTC makes use of UDP hole punching as a method of establishing connections between clients and as such outbound UDP ports are required to be accessible, if they are not then server reflexive candidates will fail to connect and relay candidates will be attempted. However, as these are routed through the TURN server (Method 3) they will be much slower.Please see RFC 5389 for a detailed explanation of the STUN protocol - https://tools.ietf.org/html/rfc5389. This protocol is used with SIP as well, so if you have an VoIP system, you may already have exclusions in place for other STUN servers.
Destination: (ANY) To limit the destinations, please specify the IP addresses, subnets (host) or public IPs (srflx) of the clients you are trying to connect to.
The senso client tries to establish a connection by using the senso relay servers.
Destination: ne-1-turn.senso.cloud; ne-2-turn.senso.cloud; ne-3-turn.senso.cloud; ne-4-turn.senso.cloud; ne-5-turn.senso.cloud