20. Operational Considerations (Considérations opérationnelles)
Cette section examine les questions pertinentes pour les opérateurs de réseau cherchant à déployer ICE.
20.1. NAT and Firewall Types (Types de NAT et de pare-feu)
ICE a été conçu pour fonctionner avec les équipements NAT et pare-feu existants. Par conséquent, il n'est pas nécessaire de remplacer ou de reconfigurer les équipements pare-feu et NAT existants afin de faciliter le déploiement d'ICE. En effet, ICE a été développé pour être déployé dans des environnements où l'opérateur de voix sur IP (VoIP) n'a aucun contrôle sur l'infrastructure du réseau IP, y compris les pare-feu et le NAT.
Cela dit, ICE fonctionne mieux dans les environnements où les dispositifs NAT sont conformes à « behave », répondant aux recommandations définies dans [RFC4787] et [RFC5766]. Dans les réseaux avec NAT conforme à behave, ICE fonctionnera sans avoir besoin d'un serveur TURN, améliorant ainsi la qualité de la voix, diminuant les temps d'établissement des appels et réduisant les demandes de bande passante sur l'opérateur de réseau.
20.2. Bandwidth Requirements (Exigences de bande passante)
Le déploiement d'ICE peut avoir plusieurs interactions avec la capacité réseau disponible que les opérateurs doivent prendre en considération.
20.2.1. STUN and TURN Server Capacity Planning (Planification de la capacité des serveurs STUN et TURN)
D'abord et avant tout, ICE utilise des serveurs TURN et STUN, qui seraient généralement situés dans les centres de données de l'opérateur de réseau. Les serveurs STUN nécessitent relativement peu de bande passante. Pour chaque composant de chaque flux média, il y aura une ou plusieurs transactions STUN de chaque client vers le serveur STUN. Dans un déploiement VoIP IPv4 de base voix uniquement, il y aura quatre transactions par appel (une pour RTP et une pour RTCP, pour l'appelant et l'appelé). Chaque transaction est une requête unique et une réponse unique, la première étant longue de 20 octets et la seconde de 28. Par conséquent, si un système a N utilisateurs et que chacun effectue quatre appels en heure de pointe, cela nécessiterait N*1,7 bps. Pour un million d'utilisateurs, c'est 1,7 Mbps, un nombre très faible (relativement parlant).
Le trafic TURN est plus substantiel. Le serveur TURN verra un volume de trafic égal au volume STUN (en effet, si des serveurs TURN sont déployés, il n'est pas nécessaire d'avoir un serveur STUN séparé), en plus du trafic pour le trafic média réel. Le nombre d'appels nécessitant TURN pour le relais média dépend fortement des topologies de réseau et peut varier et variera au fil du temps. Dans un réseau avec 100 % de NAT conforme à behave, il est exactement de zéro. Au moment de la rédaction, les déploiements grand public à grande échelle voyaient entre 5 et 10 pour cent des appels nécessitant des serveurs TURN. En considérant un déploiement voix uniquement utilisant G.711 (donc 80 kbps dans chaque direction), avec 0,2 erlangs pendant l'heure de pointe, c'est N*3,2 kbps. Pour une population d'un million d'utilisateurs, c'est 3,2 Gbps, en supposant une utilisation de 10 % des serveurs TURN.
20.2.2. Gathering and Connectivity Checks (Collecte et vérifications de connectivité)
Le processus de collecte des candidats et d'exécution des vérifications de connectivité peut être gourmand en bande passante. ICE a été conçu pour cadencer ces deux processus. La phase de collecte et la phase de vérification de connectivité sont destinées à générer du trafic à peu près à la même bande passante que le trafic média lui-même. Cela a été fait pour garantir que, si un réseau est conçu pour prendre en charge le trafic multimédia d'un certain type (voix, vidéo ou simplement texte), il aura une capacité suffisante pour prendre en charge les vérifications ICE pour ce média. Bien sûr, les vérifications ICE entraîneront une augmentation marginale de l'utilisation totale ; cependant, il s'agira généralement d'une augmentation extrêmement faible.
La congestion due aux phases de collecte et de vérification s'est avérée être un problème dans les déploiements qui n'utilisaient pas le cadencement. Généralement, les liens d'accès devenaient congestionnés alors que les points finaux inondaient le réseau de vérifications aussi vite qu'ils pouvaient les envoyer. Par conséquent, les opérateurs de réseau doivent s'assurer que leurs implémentations ICE prennent en charge la fonctionnalité de cadencement. Bien que ce cadencement augmente les temps d'établissement des appels, il rend ICE respectueux du réseau et plus facile à déployer.
20.2.3. Keepalives (Keepalives)
Les keepalives STUN (sous la forme d'indications de liaison STUN) sont envoyés au milieu d'une session média. Cependant, ils ne sont envoyés qu'en l'absence de trafic média réel. Dans les déploiements qui n'utilisent pas la détection d'activité vocale (VAD), les keepalives ne sont jamais utilisés et il n'y a pas d'augmentation de l'utilisation de la bande passante. Lorsque la VAD est utilisée, les keepalives seront envoyés pendant les périodes de silence. Cela implique un seul paquet toutes les 15-20 secondes, bien moins que le paquet toutes les 20-30 ms qui est envoyé lorsqu'il y a de la voix. Par conséquent, les keepalives n'ont aucun impact réel sur la planification de la capacité.
20.3. ICE and ICE-lite (ICE et ICE-lite)
Les déploiements utilisant un mélange d'ICE et d'ICE-lite interopèrent parfaitement. Ils ont été explicitement conçus pour le faire, sans perte de fonction.
Cependant, ICE-lite ne peut être déployé que dans des cas d'utilisation limités. Ces cas, et les mises en garde impliquées, sont documentés à l'annexe A.
20.4. Troubleshooting and Performance Management (Dépannage et gestion des performances)
ICE utilise des vérifications de connectivité de bout en bout et place une grande partie du traitement dans les points finaux. Cela introduit un défi pour l'opérateur de réseau : comment peut-il dépanner les déploiements ICE ? Comment peut-il savoir comment ICE fonctionne ?
ICE dispose de fonctionnalités intégrées pour aider à résoudre ces problèmes. Les serveurs SIP sur le chemin de signalisation, généralement déployés dans les centres de données de l'opérateur de réseau, verront le contenu des échanges offre/réponse qui véhiculent les paramètres ICE. Ces paramètres incluent le type de chaque candidat (hôte, réflexif serveur ou relayé), ainsi que leurs adresses associées. Une fois le traitement ICE terminé, un échange offre/réponse mis à jour a lieu, signalant l'adresse sélectionnée (et son type). Ce re-INVITE mis à jour est effectué exactement dans le but d'éduquer l'équipement réseau (tel qu'un outil de diagnostic attaché à un serveur SIP) sur les résultats du traitement ICE.
En conséquence, grâce aux journaux générés par le serveur SIP, un opérateur de réseau peut observer quels types de candidats sont utilisés pour chaque appel et quelle adresse a été sélectionnée par ICE. C'est l'information principale qui aide à évaluer comment ICE fonctionne.
20.5. Endpoint Configuration (Configuration du point final)
ICE repose sur plusieurs éléments de données configurés dans les points finaux. Ces données de configuration incluent les minuteries, les informations d'identification pour les serveurs TURN et les noms d'hôtes pour les serveurs STUN et TURN. ICE lui-même ne fournit pas de mécanisme pour cette configuration. Au lieu de cela, on suppose que cette information est attachée à tout mécanisme utilisé pour configurer tous les autres paramètres dans le point final. Pour les téléphones SIP, des solutions standard telles que le cadre de configuration [SIP-UA-FRMWK] ont été définies.