Below is a general diagram for network communication between SafeNSound and the Hospital Network.
- An ADT interface for processing patient details and orders then matching them to the devices in the SafeNSound application.
- The second interface is a connection to the onsite Spacelabs XprezzNet server. This server allows SafeNSound to push and pull data from the monitors and automates much of the workflow management and alarm reporting. This server (can be virtual) is required for automation of the system.
- The third interface is a connection between the SafeNSound application servers and your local Active Directory servers. This allows all authentication to pass directly to your own internal systems. The SafeNSound system does NOT store any passwords.
- The forth and less common is a connection to your staffing services. This allows the SafeNSound system to auto sync all staffing changes.
- The fifth interface to Twillio is a connection between SafeNSound and Twillio used for the communication. This enables SafeNSound to make and receive calls and quick messages.
Why do we need a Site-to-Site connection?
The site-to-site connection is used to connect the Spacelabs Cloud and to the local Spacelabs system. This connection allows our systems to securely process the encrypted data and report on that data through our interface.
Monitoring and Redundancy
The site-to-site connection is monitored 24/7 with auto escalation on alerts if connectivity fails.
Spacelabs Cloud Endpoints
USA Firewalls
- IP: 52.6.70.250
- IP: 52.73.18.190
IPSec VPN Tunnel
- Local ID: 52.6.70.250
URL's
Replace {account#} with your system account number provided by Spacelabs Cloud Services team.
- https://{account#}.safensound.io
- https://export-download.{account#}.safensound.io
- https://bridge.{account#}.safensound.io
- https://api-1.{account#}.safensound.io
- https://api-2.{account#}.safensound.io
- https://api-3.{account#}.safensound.io
- https://api-4.{account#}.safensound.io
- https://api-5.{account#}.safensound.io
- https://api-6.{account#}.safensound.io
- https://waveform-proxy.{account#}.safensound.io
- https://waveform-proxy-1.{account#}.safensound.io
- https://waveform-proxy-2.{account#}.safensound.io
- https://waveform-proxy-3.{account#}.safensound.io
- https://waveform-proxy-4.{account#}.safensound.io
- https://waveform-proxy-5.{account#}.safensound.io
- https://waveform-proxy-6.{account#}.safensound.io
- https://waveform.{account#}.safensound.io
- https://waveform-1.{account#}.safensound.io
- https://waveform-2.{account#}.safensound.io
- https://waveform-3.{account#}.safensound.io
- https://waveform-4.{account#}.safensound.io
- https://waveform-5.{account#}.safensound.io
- https://waveform-6.{account#}.safensound.io
Communication Networking and Firewall
SafeNSound utilizes Twilio to programmatically make and receive phone calls. Please insure all IP’s and Ports listed below are open on the monitor technician PC’s. This is required for the communications to work properly. Not applying this configuration could delay communications or cause a complete failure:
Applications using Twilio's Voice SDKs require connectivity to Twilio's infrastructure to be able to place and receive calls. As shown in the diagram below, two types of connections are required: Signalling and Media.
The signalling connection is a secure TLS connection that is used for sending and receiving control information to set up calls.
The media connection is a secure SRTP (Secure Real-time Transport Protocol) connection that is used to send and receive audio.
Twilio's Programmable Voice infrastructure is deployed in edges all over the world. By default, the SDKs use Global Low Latency (GLL) to determine the optimal Twilio edge to connect to.
Firewall Configuration
In a typical organization network setup, a firewall is used to protect the private network hosts from the Internet. Firewalls are configured with rules to block or allow traffic to and from Internet destinations based on direction, protocol, and IP address.
To access Twilio, your firewall should allow outgoing TCP and UDP traffic from your applications to Twilio's infrastructure and allow return traffic in response. Twilio will never initiate a connection to the SDK applications. Therefore, the firewall should not allow externally initiated connections back into the network.
In the Connectivity Requirements sections that follow, the required destination IP addresses and ports are listed. Your firewall should be configured to allow connectivity to the Media Servers and the Signalling Gateways corresponding to the SDK you are using.
Voice Media Server Connectivity Requirements
Secure Media (ICE/STUN/SRTP) Edge Locations | Protocol | Source IP | Source Port † | Destination IP Ranges | Destination Port Range |
roaming (gll) | UDP | ANY | ANY | 168.86.128.0/18 | 10,000 - 60,000 |
† The SDK will select any available port from the ephemeral range. On most machines, this means the port range 1,024 to 65,535.
Signaling Connectivity Requirements
Your Intranet | Allowed destinations | ||||
Protocol | Source IP | Source Port † | Destination | Destination Port | |
Voice JavaScript SDK | |||||
Secure TLS connection to Twilio signalling Gateway | TCP | ANY | ANY | chunderw-gll.twilio.com, chunderw-vpc-gll.twilio.com, voice-js.roaming.twilio.com | 443 |
Secure TLS Insights logging gateway | TCP | ANY | ANY | eventgw.twilio.com | 443 |
Mobile Voice SDKs | |||||
Secure TLS connection to Twilio GLL Signalling Gateway | TCP | ANY | ANY | chunderm.gll.twilio.com | 443 |
Secure TLS to Insights Gateway | TCP | ANY | ANY | eventgw.twilio.com | 443 |
Secure TLS to Registration Server | TCP | ANY | ANY | ers.twilio.com | 443 |
† The client will select any available port from the ephemeral range. On most machines, this means the port range 1,024 to 65,535.
Network Bandwidth Requirements
Bandwidth (Uplink/Downlink) | Opus*: 40kbps / 40kbps |
PCMU: 100kbps / 100kbps | |
Latency (RTT) | < 200ms |
Jitter | < 30ms |
Packet Loss | < 3% |
* Opus is the default codec for Mobile.
Global Low Latency requirements
GLL is an AWS Route53 feature that resolves a hostname to the edge location with the least latency. This removes the need for the application developer to determine where the end user is connecting from or manually choosing which edge to connect to.
However, in order for GLL to give accurate results, the intermediate DNS must:
- Support RFC 7871 - Client Subnet in DNS Queries.
- Reside in the same edge as the SDK endpoint. For example, a host in the US configured with a VPN to Europe or configured with a DNS server that resides in Europe will result in connecting that host to Twilio edge in Europe
Use Twilio's Network Traversal Service (NTS) when UDP ports are disallowed
For best audio quality, your firewall should allow your local hosts to initiate the connection to twilio and send UDP (DTLS/SRTP) traffic to the Twilio Media servers.
However, If your network policy prohibits UDP connectivity, you can utilize Twilio's Global Network Traversal Service (NTS) to establish media connectivity over TCP or TLS. Please refer to the NTS documentation for a list of TURN servers and ports that will also need to be allowed.
Note, using TURN incurs extra charges as per NTS pricing. Refer to Global Network Traversal Service for more information.
Network Diagnostics and Testing
If you're experiencing issues with calling, here are some steps you can take to diagnose the problem:
1. Determine what part of the call process is failing.
- Quick messages from Monitor tech to Caregiver
- Calls from SNS to the Caregiver
- Calls from the caregiver to the Monitor tech
- On the caregiver's workstation go to https://networktest.twilio.com/ and ensure all voice tests pass.
- Check Your Internet Connection: Ensure that your internet connection is stable and working properly.
- Restart Your Device: Sometimes, simply restarting your computer or device can resolve connectivity issues.
- The Mic and Speaker must be plugged into the PC before launching the desktop application.
Mic Access Issues
Confirm that your device policy allows mic access for all Twillio and SafeNSound URLs. If access is blocked the call when not be successful and will abruptly disconnect.
Speaker Access Issues
Confirm that your device policy allows speaker access for all Twillio and SafeNSound URLs. If access is blocked the call when not be successful and will abruptly disconnect.
No audio or one-way audio
- Check open network ports in your router / firewall / antivirus software
- Confirm the hardware is correctly attached and ensure the correct microphone and speakers are selected in software settings
- Check to ensure the microphone is not muted (some have a hardware mute button) and the speaker volume is turned up.
Call audio cutting out or stops transmitting
- Twilio Voice requires a high speed and low latency network connection. Benchmark the network by testing your throughput and ping at speedtest.net and aim to improve the scores.
- Enable router QoS or prioritize traffic for Twilio Voice.
- Reduce network activity not related to VoIP or use a separate network for VoIP workstations.
- Try using a wired connection or move closer to your wi-fi router or base station. Connection jitter or packet loss can produce choppy or "robotic" sounding call audio.
Call audio is garbled or contains artifacts
- Try a different headset
- Reduce ambient noise such as nearby speakers or fans.
- Adjust the distance of the microphone from the mouth - too close can cause audio clipping.
- Adjust microphone levels in the computer’s sound settings.
- Ensure computer has resources available to process a call.
- CPU and RAM are not over-utilized
- Close un-needed applications and browser tabs
- Try disabling antivirus software
- Try using a wired connection or move closer to your wi-fi router or base station. Connection jitter or packet loss can produce choppy or "robotic" sounding call audio.
External Call Testing
If you continue to experience issues with calling the next step is to do an external call test.
1. Enter a phone number on a patient to an outside number in SafeNSound. Please refer to this documentation for details.
2. Log into SafeNSound under a Monitor Tech role and attempt to call the number that was setup.
3. Call the SafeNSound assigned number to try and reach the Monitor Tech.
4. If the call is still not able to be completed with audio. Call Spacelabs Healthcare Global Tech Support.