Client Workstation Requirements

To use the Sharpen platform as it is intended, we recommend the following specifications to provide a positive user experience while running with your other tools. Though the application may function while operating below these standards, we will focus our support on systems compliant with our recommendations.

Network Requirements

Ports and Protocols

It is important to make sure the following ports/protocols are free to communicate with our environment.

Universal Domains

Access to these domains need to be open regardless of the isolation zone (IZ0,IZ1) in which your account is built. These include some supporting services and libraries which allow Sharpen to run as designed.

Isolation Zone Domains

Access to these domains should be open with respect to which isolation zone your account is built in.

• Isolation Zone 0 | Your users login to app.sharpencx.com

• Isolation Zone 1 | Your users login to app.iz1.sharpen.cx

If whitelisting by IP is necessary, the following ranges/addresses apply. *IPs subject to change.

Prioritization

Use Quality of Service to maintain prioritization
Configuring Quality of Service (QoS) can help to maintain traffic priority across the network. It is beneficial to tag your voice traffic with the appropriate tags, so it can be prioritized anywhere in the network in the event of saturation. This will help to prevent any audio issues caused by voice and data competing for the same bandwidth over your internet connection.

Use traffic shaping to offer voice traffic the necessary bandwidth
Due to potential contention of competing data on your network, it is important to ensure that your voice traffic has enough bandwidth to operate. As such, traffic shaping rules can be implemented to allow voice traffic to use additional bandwidth, or even limit other types of traffic to prioritize voice traffic.

QoS Settings

Voice Protocols

SIP (Session Initiation Protocol)

• 5060 UDP (Desk phone) and 9002 TCP (Webrtc) Traffic -  this is the call setup/signaling information about the call, such as phone 1 is calling phone 2 on server XYZ.

• 10000-20000 UDP Traffic - this is the Real-time Transfer Protocol (RTP) stream where actual packets of voice data are transmitted. This is the audio of the call.

While at rest, the phones only send 5060 UDP data as a ‘keep alive’ method for Network Address Translation (NAT), during this period there is no RTP traffic. Once a phone call is made and audio established, RTP traffic is sent from the phone to our servers.

WebRTC

WebRTC is an HTML5 specification which can be used to facilitate real-time media communications (video and audio) between browsers and other audio endpoints. The Sharpen Q phone built into the Sharpen Q application leverages WebRTC, allowing for seamless integration to the platform within the browser. *See “Ports and Protocols” above to make sure you have the proper ports open.

Network performance

Uninterrupted, consistent network performance is required for a good experience with the Sharpen platform. Due to the inherent nature of Voice interactions to be real-time, we need consistency in the underlying network. Otherwise, users may experience dropped calls, choppy call quality, latency, or an overall slow experience.

Assessment

Run this basic speed test to obtain your download, upload, latency, and jitter results.

• <150ms latency to *.sipvbx.com (example: us1-webrtc-11.sipvbx.com for east coast US, or us2-webrtc-02.sipvbx.com for west coast US)

• Average latency variation < 30ms

  • High variation represents interruption to your connection. This may be a result of competing network traffic, or general hardware/network instability

  • While high latency on its own simply means delay, latency variation typically comes coupled with packet loss, which will mean dropped calls and/or choppy audio

• >10Mb/s internet connection

  • While voice itself is a fairly light operation, we recommend having enough bandwidth to handle all your operations. This value is more of a guideline, rather than a requirement. Most important is making sure your collection of tools, including Sharpen, have sufficient bandwidth.

  • The best way to determine bandwidth needs is to sample your tool set usage, and extrapolate from there.

  • Sharpen bandwidth utilization can vary widely based on how it is used some base-line examples of usage are as follows

    • Sharpen Q page load for single agent logged into 4 queues

      • ~350 KB transferred

      • ~7 MB page resources

    • 1 minute outbound call from Sharpen Q

      • ~125 KB transferred

      • ~1 MB page resources

    • Reporting/Insights (10 reports) page load

      • ~150 KB transferred

      • ~ 8 MB page resources

• < 1% packet loss

  • For a positive experience, voice requires minimal packet loss. If packets are dropped, it will interrupt the audio stream. You may experience disruptive delay or choppy audio. Enough packet loss will cause dropped calls.

• < 30ms jitter

  • Jitter is the variation in delay of packets. Having high jitter will also cause poor call quality.

Common interruptions

• SIP ALG is enabled

  • Perhaps contrary to its name, SIP ALG is not compatible with most enterprise VoIP solutions, such as Sharpen. Depending on the manufacturer, network device configurations will show up as “SIP ALG”, “SIP”, “VoIP”, or something similar. Intermittent disconnection, dropped calls, one-way audio, and the inability to register are common symptoms when SIP ALG is enabled.

  • Depending on your device manufacturer or ISP, it may be difficult to get a straight answer on confirming this setting is off. Commonly, ISPs will have this setting enabled, because it supports their own options for VoIP solutions. It is not uncommon to have to work through a couple layers of support or technical team members to validate the proper setting is turned off. 

• Stateful Packet Inspection (SPI) is enabled

  • Similar to SIP ALG, SPI is a setting which has its benefits, but can conflict with the proper operation of voice traffic. Stateful Packet Inspection is a dynamic packet filtering technology for firewalls which inspects the state of packets to determine whether packets should be blocked or allowed. WebRTC traffic is stateless, and thus you may experience issues with the inability to establish a connection or 2 way audio if it is enabled. This happens because SPI may not recognize webRTC and thus treat it as unapproved UDP traffic.

• NAT misconfigurations

  • NAT (Network Address Translation) exists to provide security and preserve local IPv4 addresses. NATs associate or bind private IP:port addresses to public IP:port addresses. Hosts outside the local network will only see and know of the bound outside IP:Port.  Hosts directing traffic to this bound IP:port will first arrive at the NAT before being translated and sent to the actual destination IP:Port.

  • With VoIP and webRTC, NAT can cause challenges if not configured optimally. Though the STUN protocol exists to overcome this challenge through its participation with ICE candidate negotiation. Some NAT configurations can still get in the way. For instance, utilizing a Sonicwall firewall without the use of its “Consistent NAT” feature, will result in 1-way audio. Consistent NAT uses an MD5 hashing method to consistently assign the same mapped public IP address and UDP Port pair to each internal private IP address and port pair.

• UDP timeout is set less than 240 seconds

  • Sharpen’s expected SIP registration interval is 4 minutes (240 seconds). If your network is set to “timeout” UDP connections at less than that, it will disconnect an active registration. Depending on when this happens, you’ll see the following symptoms.

    • Dropped calls

    • Inability to be reached on the phone which has lost its connection. 

    • You’ll be able to dial outbound without issue, since registration is established on an attempted outbound call, if it does not already exist. 

    • You’re probably seeing a sawtooth pattern in your latency graphs.

• ISP provided “combination” network equipment

  • Especially if you’re working from home on your residential internet connection, be weary of the Internet Service Provider (ISP) controlled settings which may exist on these managed devices. “Combination” devices are typically those which integrate modem, router, and wifi into one device. While in principle, the integration of these functions problematic, they can sometimes come with configuration hurdles which are difficult to overcome since you, as the borrower of the device, do not have administration access to the devices. It is not uncommon for settings like SIP ALG to be enabled but invisible to you as the user. These situations require that you work with your ISP’s support team to change a setting. 

  • As a result, Sharpen discourages the use of combination network equipment. Instead we recommend purchasing a stand alone modem which is compatible with your ISP, and connecting a router of choice to it. This allows you full control of any potentially conflicting setting. Most self-managed devices have these problematic settings disabled by default.

  • If you can not acquire a stand-alone modem and router, we recommend reaching out to your ISP to see if they can place your combination device in “bridge” mode, then purchasing and connecting a 3rd party router to handle the local networking. 

• VPN

  • VPNs have many valid use cases, especially for work from home users. However, VPNs are not always configured to be optimal for voice traffic. Adding the additional virtual layer to the network, in most situations, will cause a recognizable degradation in network performance. Voice requires low latency, with minimal packet loss. As a result, if the VPN introduces too much interruption, your quality of service will be impacted. If VPN is necessary, it is recommended to configure it so Sharpen traffic can be omitted through the us of split tunneling.

• MPLS

  • Similar to VPN, an MPLS has its place in the enterprise network configuration realm. However, the use of an MPLS with Sharpen is strongly discouraged. Most commonly, customers will have had MPLS configurations remaining from previous on-premise or direct to data center VoIP solutions. This makes sense because you have narrowly identified VoIP endpoints which you can create a specific path to through the MPLS. Your users then connect to your corporate network and then their traffic tunnels through that optimal connection. However, this architecture actually causes problems for a more universally available cloud-based solution such as Sharpen. 

  • Consider this example. You’re a user based in San Jose working for an organization headquartered in Chicago. You have an MPLS configured to connect from Chicago HQ to your datacenter in Indianapolis, where your ISP has its terminating hardware. All internet traffic from Chicago traverses the MPLS to get to its final destination. I, the San Jose user, connect to the VPN so I can access my corporate network assets. I login to Sharpen. My connection, which could go directly, over the internet, to our west coast Oregon location, instead is connecting over 1 virtual layer, then a physical MPLS to Indianapolis to get to the internet. At this point, the quickest available path to Sharpen becomes our east coast Virginia location. You know how a user connecting across the United States for a voice connection which most optimally works on a low latency, low packet loss environment.

  • The best solution is a solid internet connection with standalone network equipment. This allows for the lowest latency path to our resources, and the best experience.