20. Operational Considerations (Considerazioni operative)

Questa sezione discute le questioni rilevanti per gli operatori di rete che cercano di implementare ICE.

20.1. NAT and Firewall Types (Tipi di NAT e Firewall)

ICE è stato progettato per funzionare con apparecchiature NAT e firewall esistenti. Di conseguenza, non è necessario sostituire o riconfigurare le apparecchiature firewall e NAT esistenti per facilitare l'implementazione di ICE. Infatti, ICE è stato sviluppato per essere implementato in ambienti in cui l'operatore Voice over IP (VoIP) non ha alcun controllo sull'infrastruttura di rete IP, inclusi firewall e NAT.

Detto questo, ICE funziona meglio in ambienti in cui i dispositivi NAT sono conformi a "behave", soddisfacendo le raccomandazioni definite in [RFC4787] e [RFC5766]. Nelle reti con NAT conforme a behave, ICE funzionerà senza la necessità di un server TURN, migliorando così la qualità della voce, riducendo i tempi di configurazione delle chiamate e riducendo le richieste di larghezza di banda all'operatore di rete.

20.2. Bandwidth Requirements (Requisiti di larghezza di banda)

L'implementazione di ICE può avere diverse interazioni con la capacità di rete disponibile che gli operatori dovrebbero prendere in considerazione.

20.2.1. STUN and TURN Server Capacity Planning (Pianificazione della capacità del server STUN e TURN)

Innanzitutto, ICE fa uso di server TURN e STUN, che si troverebbero tipicamente nei data center dell'operatore di rete. I server STUN richiedono relativamente poca larghezza di banda. Per ogni componente di ogni flusso multimediale, ci sarà una o più transazioni STUN da ciascun client al server STUN. In un'implementazione VoIP IPv4 di base solo voce, ci saranno quattro transazioni per chiamata (una per RTP e una per RTCP, sia per il chiamante che per il chiamato). Ogni transazione è una singola richiesta e una singola risposta, la prima lunga 20 byte e la seconda 28. Di conseguenza, se un sistema ha N utenti e ciascuno effettua quattro chiamate in un'ora di punta, ciò richiederebbe N*1,7 bps. Per un milione di utenti, questo è 1,7 Mbps, un numero molto piccolo (relativamente parlando).

Il traffico TURN è più sostanziale. Il server TURN vedrà un volume di traffico uguale al volume STUN (infatti, se vengono implementati server TURN, non è necessario un server STUN separato), oltre al traffico per il traffico multimediale effettivo. La quantità di chiamate che richiedono TURN per il relay multimediale dipende fortemente dalle topologie di rete e può e varierà nel tempo. In una rete con NAT conforme al 100% a behave, è esattamente zero. Al momento della scrittura, le implementazioni consumer su larga scala vedevano tra il 5 e il 10 percento delle chiamate richiedere server TURN. Considerando un'implementazione solo voce utilizzando G.711 (quindi 80 kbps in ciascuna direzione), con 0,2 erlang durante l'ora di punta, questo è N*3,2 kbps. Per una popolazione di un milione di utenti, questo è 3,2 Gbps, supponendo un utilizzo del 10% dei server TURN.

20.2.2. Gathering and Connectivity Checks (Raccolta e controlli di connettività)

Il processo di raccolta dei candidati e l'esecuzione dei controlli di connettività possono richiedere un uso intensivo della larghezza di banda. ICE è stato progettato per regolare il ritmo di entrambi questi processi. La fase di raccolta e la fase di controllo della connettività sono pensate per generare traffico all'incirca alla stessa larghezza di banda del traffico multimediale stesso. Ciò è stato fatto per garantire che, se una rete è progettata per supportare il traffico multimediale di un certo tipo (voce, video o solo testo), avrà una capacità sufficiente per supportare i controlli ICE per quel supporto. Naturalmente, i controlli ICE causeranno un aumento marginale dell'utilizzo totale; tuttavia, questo sarà tipicamente un aumento estremamente ridotto.

La congestione dovuta alle fasi di raccolta e controllo si è rivelata un problema nelle implementazioni che non utilizzavano il pacing. Tipicamente, i collegamenti di accesso diventavano congestionati mentre gli endpoint inondavano la rete con controlli il più velocemente possibile. Di conseguenza, gli operatori di rete dovrebbero assicurarsi che le loro implementazioni ICE supportino la funzionalità di pacing. Sebbene questo pacing aumenti i tempi di configurazione delle chiamate, rende ICE amico della rete e più facile à implementare.

20.2.3. Keepalives (Keepalive)

I keepalive STUN (sotto forma di indicazioni di binding STUN) vengono inviati nel mezzo di una sessione multimediale. Tuttavia, vengono inviati solo in assenza di traffico multimediale effettivo. Nelle implementazioni che non utilizzano il rilevamento dell'attività vocale (VAD), i keepalive non vengono mai utilizzati e non vi è alcun aumento dell'utilizzo della larghezza di banda. Quando viene utilizzato VAD, i keepalive verranno inviati durante i periodi di silenzio. Ciò comporta un singolo pacchetto ogni 15-20 secondi, molto meno del pacchetto ogni 20-30 ms che viene inviato quando c'è la voce. Pertanto, i keepalive non hanno alcun impatto reale sulla pianificazione della capacità.

20.3. ICE and ICE-lite (ICE e ICE-lite)

Le implementazioni che utilizzano un mix di ICE e ICE-lite interagiscono perfettamente. Sono stati esplicitamente progettati per farlo, senza perdita di funzionalità.

Tuttavia, ICE-lite può essere implementato solo in casi d'uso limitati. Tali casi e le avvertenze coinvolte nel farlo sono documentati nell'Appendice A.

20.4. Troubleshooting and Performance Management (Risoluzione dei problemi e gestione delle prestazioni)

ICE utilizza controlli di connettività end-to-end e colloca gran parte dell'elaborazione negli endpoint. Ciò introduce una sfida per l'operatore di rete: come possono risolvere i problemi delle implementazioni ICE? Come possono sapere come sta funzionando ICE?

ICE ha funzionalità integrate per aiutare ad affrontare questi problemi. I server SIP sul percorso di segnalazione, tipicamente implementati nei data center dell'operatore di rete, vedranno il contenuto degli scambi offerta/risposta che trasmettono i parametri ICE. Questi parametri includono il tipo di ciascun candidato (host, server reflexive o relayed), insieme ai relativi indirizzi. Una volta completata l'elaborazione ICE, avviene uno scambio offerta/risposta aggiornato, che segnala l'indirizzo selezionato (e il suo tipo). Questo re-INVITE aggiornato viene eseguito esattamente allo scopo di istruire le apparecchiature di rete (come uno strumento diagnostico collegato a un server SIP) sui risultati dell'elaborazione ICE.

Di conseguenza, attraverso i log generati dal server SIP, un operatore di rete può osservare quali tipi di candidati vengono utilizzati per ogni chiamata e quale indirizzo è stato selezionato da ICE. Questa è l'informazione principale che aiuta a valutare come sta funzionando ICE.

20.5. Endpoint Configuration (Configurazione dell'endpoint)

ICE si basa su diversi dati configurati negli endpoint. Questi dati di configurazione includono timer, credenziali per i server TURN e nomi host per i server STUN e TURN. ICE stesso non fornisce un meccanismo per questa configurazione. Si presume invece che queste informazioni siano allegate a qualsiasi meccanismo utilizzato per configurare tutti gli altri parametri nell'endpoint. Per i telefoni SIP, sono state definite soluzioni standard come il framework di configurazione [SIP-UA-FRMWK].