<aside> <img src="/icons/reorder_blue.svg" alt="/icons/reorder_blue.svg" width="40px" />
MENU
Welcome
Pour démarrer
Conseiller
Superviseur
IA
Voice Pilot
Admin
API
Intégrations
Statistiques </aside>
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.
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.
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 |
Les IPs Cloud Axialys incluent :
Aucun trafic n’est initié d’Axialys vers le client.
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 :
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.
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.
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.
Dans le cas où la politique SSI du client prévoit l’usage d’un VPN pour les utilisateurs nomades, nous recommandons qu’il :
Le trafic vers Axialys peut être identifié à l’aide des IPs ci-dessus.
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).
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.
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.
Axialys fournira un équipement (“routeur”) capable de :
Ce routeur disposera d’une IP privée dans le réseau du client.
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))