Guide voice management

LE GUIDE UTILISATEUR DE VOTRE SOLUTION CALL CENTER

Retour au guide

Pré-requis d'utilisation du Voice Management

1.Poste de travail

1.1 Caractéristiques générales

Les performances de l’ordinateur doivent être suffisantes compte tenu des autres applications natives ou web chargées.
Un minimum de 8 Go de RAM est recommandé, dont au minimum 500 Mo libres pour les applicatifs Axialys.

1.2 Navigateur

Axialys recommande l’utilisation de Google Chrome ou Mozilla Firefox. L’usage d’un autre navigateur doit faire l’objet d’une validation.

2.Réseau

2.1 Performances

Un accès internet non saturé est nécessaire. À titre d’information, la bande passante symétrique requise est de l’ordre de 80 kbits/s par communication simultanée.

La latence à destination des installations Axialys devra être inférieure à 150ms; Axialys fournira des endpoints régionaux en fonction du continent d’où opère le client. 

2.2 Matrice de flux

Le déploiement du service Voice Management, lorsqu’il s’appuie sur le Centrex Axialys et le protocole WebRTC, nécessite une communication entre le poste de travail et les serveurs Axialys. Celle-ci nécessite le support des flux suivants :

Adresse / port départ Adresse / protocole / port destination Usage Symétrique
IP client / any
/ TCP / 443
Flux HTTPS normal pour le fonctionnement de l’interface utilisateur
Oui
IP client / any
IPs cloud Axialys / TCP / 443
Flux WebSocket (upgrade de la connexion HTTPS) pour la signalisation des appels (protocole SIP over WebSocket)
Oui
IP client / any
IPs cloud Axialys / UDP / 10000 - 20000
Flux UDP bidirectionnel (pour l’audio). Tous les flux sont initiés depuis les utilisateurs (interne client). Le flux retour est symétrique. L’usage du protocole UDP (faible latence, y compris en cas de perturbations / pertes de paquets) est indispensable pour garantir une qualité audio satisfaisante.
Oui

Les IPs Cloud Axialys incluent :

  • 217.146.224.0/20 : backbone Axialys mondial

  • 104.20.31.27 et 104.20.30.27 : IPs anycast Cloudflare dédiées à Axialys pour le HTTP(S)

Aucun trafic n’est initié d’Axialys vers le client.

2.3.Cas générale : Connexion non restreinte

Dans le cas le plus simple, la connexion du poste client est possible directement, avec, simplement, un mécanisme de NAT transparent au niveau du routeur local.

C’est le fonctionnement normal d’une box internet classique : 

  • tous les flux depuis le réseau local vers l’internet sont autorisés

  • seuls les flux “réponse” suite à une requête initiée dans le réseau local sont autorisés venant d’internet

Notre solution fonctionnera parfaitement avec un tel environnement, sans autre action.

Compte tenu du fonctionnement intrinsèque du NAT, cette solution ne présente aucun risque d’attaque depuis l’extérieur.

2.4.Cas particuliers

2.4.1.Proxy HTTPS(S)

Certains sites déploient des proxies HTTP, pour des questions de performance (cache) et/ou de filtrage sur les contenus.

D’une façon générale, nous recommandons d’éviter cette solution pour les flux Axialys si possible, par exemple en déclarant comme “DIRECT” au niveau du fichier proxy.pac les flux vers les URLs “*.axialys.net” et “*.axialys.com”. Il nous a en effet été rapporté des anomalies ou instabilités de fonctionnement qui ont été résolues par la suppression du proxy.

En tout état de cause, un éventuel proxy devrait impérativement supporter les WebSockets, faute de quoi la téléphonie dans le navigateur (WebRTC) ne pourra pas se connecter.

Enfin, le proxy ne doit pas nécessiter d’authentification récurrente, puisqu’il ne pourra pas produire d’interface d’authentification interactive pour l’utilisateur en cours de session.

2.4.2. VDI /bureau distant

Axialys déconseille l’usage de la solution à travers un bureau distant, puisque celui implique, tant au niveau réseau qu’interaction, un aller/retour supplémentaire via le serveur d’infrastructure.

Bien que rien ne soit spécifiquement bloquant, un tel environnement implique plus de risques d’aléas techniques, possiblement délicats à diagnostiquer / isoler.

2.4.3.VPN

Dans le cas où la politique SSI du client prévoit l’usage d’un VPN pour les utilisateurs nomades, nous recommandons qu’il : 

  • soit restreint au seul accès vers les ressources du client, et qu’il ne concerne donc pas l’accès internet en général, et notamment les services Axialys

  • ou qu’il mette en oeuvre du split tunneling gérant en exception le trafic vers Axialys hors VPN.

Le trafic vers Axialys peut être identifié à l’aide des IPs ci-dessus.

2.4.4.Firewall restrictif

Dans le cas où la politique SSI du site restreint les connexions sortantes, nous recommandons d’autoriser spécifiquement les flux destinés aux instances de service Axialys.

Les destinations à autoriser (en sortie + réponse symétrique) sont celles indiquées dans la première partie du document. Des plages plus petites peuvent être fournies si besoin (avec cependant la nécessité d’évolution de paramétrage côté client en cas d’évolution de l’infrastructure Axialys).

2.4.5.Lien privé vers Axilays

Axialys propose, en option, la mise en place d’un lien privé (fibre) entre le site du client (ou un POP du client dans un datacenter) et l’un des POP Axialys.

L’intérêt principal d’une telle solution est d’offrir un niveau de performances garanti aux utilisateurs, évitant tout aléa d’internet pouvant influer sur la qualité des communications audio.

Axialys fournira un routeur de terminaison qui sera généralement situé en amont du routeur/firewall client, au même niveau que le routeur de son fournisseur d’accès; le routeur du client assurera le routage différencié vers les IPs référencées dans la première partie du document, et un éventuel secours sur le lien principal du client (Internet) en cas de défaillance. Le lien Axialys peut également en option servir de backup Internet au client (sur demande).

Enfin, nous recommandons de modifier la résolution DNS des ressources HTTP Axialys (“*.axialys.com” et *.axialys.net”) afin d’éviter de passer par Cloudflare, qui représenterait, dans un tel scénario, un éventuel point de fragilité superflu. Le routeur Axialys inclut un serveur DNS capable de résoudre ces adresses directement et de façon optimale.

2.4.6. Réseau non routé

Dans le cas où le réseau du client bloque, sans exception possible, le trafic vers Internet, de façon totale ou partielle (TCP seulement autorisé, UDP interdit par exemple), et fait appel à un mécanisme de proxy, l’audio WebRTC ne pourra fonctionner (le service pourra fonctionner avec un système de téléphonie tiers, cependant).

Afin de permettre le fonctionnement de la téléphonie WebRTC Axialys dans un tel environnement, Axialys peut proposer en option une infrastructure hybride s’étendant dans le réseau du client, et permettant un accès d’apparence local (LAN) aux utilisateurs.

Les mécanismes suivants devront être mis en place.

2.4.6.1.Routeur Axialys sur site avec lien ou VPN Axialys

Axialys fournira un équipement (“routeur”) capable de : 

  • se connecter à l’infrastructure Axialys, via un lien privé fourni par Axialys et/ou un VPN (dans ce cas, l’infrastructure client devra permettre l’établissement de ce VPN entre le routeur et Axialys)

  • faire transiter tous les flux concernés vers Axialys

  • assurer le proxy applicatif SIP pour la téléphonie

Ce routeur disposera d’une IP privée dans le réseau du client.

2.4.6.2.DNS privé

Le résolveur DNS utilisé par les utilisateurs devra indiquer aux clients internes l’IP privée du routeur Axialys (librement joignable) pour les diverses adresses des endpoints Axialys (liste fournie).

Il est vivement recommandé, dans cette configuration, que le trafic des postes ne passe pas par un proxy HTTP (cf 2.4.1 Proxy HTTP(S))

  • Table des matières

1.Poste de travail

2. Réseau