Voice Management Guide

The Voice Management user guide

Back to guide

Voice Management requirements

1.Workstation

1.1 General Characteristics

The computer’s performance must be sufficient given the other native or web applications loaded. A minimum of 8 GB of RAM is recommended, with at least 500 MB free for Axialys applications.

1.2 Navigateur

Axialys recommends using Google Chrome or Mozilla Firefox. The use of any other browser must be validated.

2. Network

2.1 Performance

An unsaturated internet connection is necessary. For information, the required symmetric bandwidth is about 80 kbits/s per simultaneous communication.

The latency to Axialys installations must be less than 150ms; Axialys will provide regional endpoints based on the continent where the client operates.

2.2 Flow Matrix

The deployment of the Voice Management service, when based on Axialys Centrex and the WebRTC protocol, requires communication between the workstation and Axialys servers. This requires support for the following flows:

Source Address/Port Destination Address/Protocol/Port Usage Symmetric
Client IP / any
/ TCP / 443
Normal HTTPS flow for the user interface
Yes
Client IP / any
/ TCP / 443
WebSocket flow (upgrade from HTTPS connection) for call signaling (SIP over WebSocket protocol)
Yes
Client IP / any
/ UDP / 10000-20000
Bidirectional UDP flow (for audio). All flows are initiated from the users (internal client). The return flow is symmetric. The use of the UDP protocol (low latency, even in case of disturbances/packet loss) is essential to ensure satisfactory audio quality
Yes

Axialys cloud IPs include:

  • 217.146.224.0/20: global Axialys backbone
  • 104.20.31.27 and 104.20.30.27: Cloudflare anycast IPs dedicated to Axialys for HTTP(S)

No traffic is initiated from Axialys to the client.

2.3 General Case: Unrestricted Connection

In the simplest case, the client workstation can connect directly, with only a transparent NAT mechanism at the local router level. This is the normal operation of a standard internet box:
all flows from the local network to the internet are allowed
only “response” flows following a request initiated in the local network are allowed from the internet
Our solution will work perfectly in such an environment without any further action.
Given the intrinsic operation of NAT, this solution presents no risk of attack from the outside.

2.4 Special Cases

2.4.1 HTTP(S) Proxy

Some sites deploy HTTP proxies for performance (cache) and/or content filtering reasons.

In general, we recommend avoiding this solution for Axialys flows if possible, for example by declaring as “DIRECT” in the proxy.pac file the flows to the URLs “.axialys.net” and “.axialys.com”. We have indeed received reports of anomalies or instabilities that were resolved by removing the proxy.

In any case, any potential proxy must imperatively support WebSockets, otherwise telephony in the browser (WebRTC) will not be able to connect.
Finally, the proxy must not require recurring authentication, as it will not be able to produce an interactive authentication interface for the user during the session.

2.4.2 VDI / Remote Desktop

Axialys advises against using the solution through a remote desktop, as it involves, both at the network and interaction levels, an additional round trip via the infrastructure server.

Although nothing is specifically blocking, such an environment implies more risks of technical uncertainties, possibly difficult to diagnose/isolate.

2.4.3 VPN

If the client’s SSI policy requires the use of a VPN for mobile users, we recommend that it:

  • be restricted to access only the client’s resources, and therefore does not include general internet access, especially Axialys services.
  • Or implement split tunneling managing exceptions for traffic to Axialys outside the VPN.

Traffic to Axialys can be identified using the above IPs.

2.4.4 Restrictive Firewall

If the site’s SSI policy restricts outgoing connections, we recommend specifically allowing flows destined for Axialys service instances.
The destinations to be allowed (outgoing + symmetric response) are those indicated in the first part of the document. Smaller ranges can be provided if necessary (with the need for configuration evolution on the client side in case of Axialys infrastructure evolution).

2.4.5 Private Link to Axialys

Axialys offers, as an option, the setup of a private link (fiber) between the client site (or a client POP in a data center) and one of Axialys POPs.
The main interest of such a solution is to offer a guaranteed level of performance to users, avoiding any internet uncertainties that could affect the quality of audio communications.
Axialys will provide a termination router that will generally be located upstream of the client router/firewall, at the same level as the client’s internet service provider’s router; the client router will ensure differentiated routing to the IPs referenced in the first part of the document, and a possible backup on the client’s main link (Internet) in case of failure. The Axialys link can also optionally serve as an internet backup for the client (on request).
Finally, we recommend modifying the DNS resolution of Axialys HTTP resources (“*.axialys.com” and *.axialys.net”) to avoid going through Cloudflare, which would represent, in such a scenario, a potential unnecessary point of fragility. The Axialys router includes a DNS server capable of resolving these addresses directly and optimally.

2.4.6 Non-Routed Network

If the client’s network blocks, without possible exception, traffic to the internet, totally or partially (only TCP allowed, UDP prohibited for example), and uses a proxy mechanism, WebRTC audio will not work (the service can work with a third-party telephony system, however).
To enable Axialys WebRTC telephony in such an environment, Axialys can offer an optional hybrid infrastructure extending into the client’s network, allowing users apparent local (LAN) access.
The following mechanisms must be implemented.

2.4.6.1 On-Site Axialys Router with Axialys Link or VPN

Axialys will provide equipment (“router”) capable of:

  • Connecting to Axialys infrastructure, via a private link provided by Axialys and/or a VPN (in this case, the client’s infrastructure must allow the establishment of this VPN between the router and Axialys)
  • Transiting all concerned flows to Axialys
  • Ensuring SIP application proxy for telephony

This router will have a private IP in the client’s network.

2.4.6.2 Private DNS

The DNS resolver used by the users must indicate to the internal clients the private IP of the Axialys router (freely reachable) for the various Axialys endpoint addresses (list provided).

In this configuration, it is strongly recommended that workstation traffic does not pass through an HTTP proxy (see 2.4.1 HTTP(S) Proxy).

  • Table of Contents

1. Workstation

2. Network