Introduzione
In questo documento viene descritto come risolvere i problemi audio relativi alla rete in un ambiente VoIP (Voice over IP).
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- QoS
- reti VoIP
- SPAN (Switchport Analyzer)
- Wireshark
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- Catalyst 9200
- Catalyst 9300
- Catalyst 9400
- Catalyst 9500
- Catalyst 9600
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
In un'infrastruttura VoIP, la qualità dell'audio può essere influenzata da problemi relativi alla rete, i cui sintomi includono:
- Spazi intermittenti nella voce o audio discontinuo.
- Audio unidirezionale.
- Non isolato per un singolo utente, ma per un gruppo di utenti con caratteristiche comuni, ad esempio la condivisione della stessa VLAN o dello stesso switch di accesso.
Per risolvere i problemi relativi alla rete, è importante avere una topologia chiara dall'origine alla destinazione dei pacchetti voce. La diagnosi del problema può iniziare in qualsiasi punto della rete in cui i pacchetti voce vengono commutati o instradati, tuttavia si consiglia di iniziare la risoluzione dei problemi dal livello di accesso e passare al livello di routing.
Esempio di rete
Scegliere un punto di acquisizione nel percorso. Può essere A (il più vicino a un telefono IP), B (prima del routing), C (il più vicino alla destinazione).
L'acquisizione SPAN viene normalmente effettuata in entrambe le direzioni (TX e RX) per identificare entrambi i lati della conversazione ed estrarre il rispettivo audio, insieme ad altre variabili come il jitter o la perdita di pacchetti, dalla cattura per un'ulteriore analisi.
Dopo aver determinato il punto di acquisizione, configurare la configurazione SPAN sullo switch.
Switch(config)#monitor session 1 source interface Gig1/0/1 both
Switch(config)#monitor session 1 destination interface Gig1/0/6 encapsulation replicate
Switch#show monitor session all
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/6
Encapsulation : Replicate
Ingress : Disabled
Effettuare una chiamata di prova per acquisire il flusso audio dal punto di acquisizione scelto in un PC/notebook con Wireshark.
Analisi acquisizione
1. Aprire l'acquisizione del pacchetto effettuata con Wireshark e selezionare Statistics > Conversations (Statistiche > Conversazioni). Trovare la conversazione audio in base all'indirizzo IP dei dispositivi interessati (origine e destinazione del telefono IP).
2. Normalmente, i flussi audio sono trasportati dal protocollo UDP e, nella maggior parte dei casi, non vengono decodificati nel formato corretto per permettere a Wireshark di estrarre l'audio in essi incorporato. Quindi, il passo successivo è decodificare il flusso UDP in formato audio; per impostazione predefinita, viene utilizzato il protocollo RTP. Fare clic con il pulsante destro del mouse su un pacchetto del flusso, quindi selezionare Decodifica come.
3. Cercare la colonna Corrente e scegliere RTP. Fare clic su OK.
Wireshark decodifica l'intero flusso UDP in RTP e ora possiamo analizzarne i contenuti.
Attenzione: RTP Player è in grado di riprodurre qualsiasi codec supportato da un plug-in installato. I codec supportati da RTP Player dipendono dalla versione di Wireshark in uso. Le build ufficiali contengono tutti i plugin gestiti dagli sviluppatori di Wireshark, ma le build personalizzate/di distribuzione non includono alcuni di questi codec. Per controllare i plug-in del codec installati da Wireshark, eseguire le operazioni seguenti: Apri Guida > Informazioni su Wireshark. Selezionare la scheda Plugin. Nel menu Filtra per tipo, selezionare Codec.
4. Controllare le statistiche RTP per vedere se ci sono tremoli o perdite nel flusso audio. Per visualizzare l'analisi, selezionare Telefonia > RTP > Analisi flusso RTP.
Jitter: ritardo nell'invio dei pacchetti voce sulla rete. Ciò è spesso causato da congestione della rete o modifiche del percorso. Questa misura deve essere inferiore a 30 ms.
Persi: pacchetti non ricevuti come parte del flusso audio. La perdita di pacchetti non deve essere superiore all'1%.
5. Convertire l'onda audio da questo flusso in Telefonia > RTP > Flussi RTP
6. Selezionare il flusso per convertirlo in audio e fare clic su Riproduci flussi.
Deve comparire un'onda audio e il pulsante di riproduzione è disponibile per ascoltare i dati audio. L'ascolto dell'audio aiuta a identificare se ci sono problemi di voce discontinua o problemi audio unidirezionali con i flussi.
7. Esportate il flusso in un file audio con estensione .wav facendo clic su Esporta > Audio sincronizzato file.
Risoluzione dei problemi
Dopo aver usato la funzione SPAN per raccogliere e analizzare l'acquisizione con Wireshark, avremmo capito se il problema può essere correlato a jitter, perdita di pacchetti o audio unidirezionale. In caso di problemi nell'acquisizione del pacchetto, il passo successivo è quello di controllare il dispositivo su cui è stata effettuata l'acquisizione per individuare eventuali problemi comuni che possono influire su un flusso audio RTP.
Audio discontinuo
Una larghezza di banda insufficiente, l'instabilità e/o la perdita del pacchetto possono essere cause comuni all'udito di voce interrotta o distorsione nell'acquisizione audio.
1. Verificare se il jitter sull'acquisizione è > 30 ms. In caso affermativo, indica che si è verificato un ritardo nella ricezione dei pacchetti che può essere causato da policy QoS o da problemi di routing.
2. Verificare se il pacchetto perso durante l'acquisizione è > 1%. Se questo valore è alto, è necessario cercare le perdite dei pacchetti lungo il percorso del flusso audio.
3. Controllare eventuali cadute sulle interfacce in entrata ed in uscita interessate dal percorso.
Switch#show interface Gi1/0/1 | inc drops
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol drops
Switch#show interfaces Gi1/0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi1/0/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Gi1/0/1 0 0 0 0 0 0
Verificare che non vi siano cadute incrementali di input/output o altri errori incrementali sulle interfacce.
4. Controllare i criteri di uscita QoS sulle interfacce interessate dal percorso. Accertarsi che il traffico sia mappato/classificato nella coda Priorità e che non ci siano drop in questa coda.
Switch#show platform hardware fed switch 1 qos queue stats interface Gi1/0/1
----------------------------------------------------------------------------------------------
AQM Global counters
GlobalHardLimit: 3976 | GlobalHardBufCount: 0
GlobalSoftLimit: 15872 | GlobalSoftBufCount: 0
----------------------------------------------------------------------------------------------
High Watermark Soft Buffers: Port Monitor Disabled
----------------------------------------------------------------------------------------------
Asic:0 Core:1 DATA Port:0 Hardware Enqueue Counters
----------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
-- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 707354 2529238 0 <<< Priority Q
1 0 0 0 1858516 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
Asic:0 Core:1 DATA Port:0 Hardware Drop Counters
--------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
-- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0 <<< Priority Q Drops
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
Nota: in caso di cadute, verificare che il traffico vocale sia correttamente analizzato con i contrassegni DSCP Expedite Forwarding (EF) e confermare che non vi siano altri flussi anomali erroneamente contrassegnati con il bit EF, congestionando così la coda Priority.
Audio unidirezionale
Quando viene stabilita una telefonata, solo una delle parti riceve l'audio. Le cause più comuni di questo problema sono problemi di raggiungibilità, problemi di routing o problemi di NAT/Firewall.
1. Eseguire un ping alla subnet o al gateway di destinazione per verificare che sia possibile raggiungere il dispositivo in modo bidirezionale.
Switch#ping 192.168.1.150
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.150, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
2. Eseguire un traceroute tra la subnet di origine e di destinazione e viceversa. Ciò consente di controllare il numero di hop presenti nel percorso e di verificare se è simmetrico.
Switch#traceroute 192.168.1.150
Type escape sequence to abort.
Tracing the route to 192.168.1.150
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.2.12 2 msec * 1 msec
2 192.168.1.12 2 msec * 1 msec
3 192.168.1.150 2 msec 2 msec 1 msec
3. Verificare che il routing del dispositivo gateway per ciascuna subnet sia ottimale e che non vi siano percorsi asimmetrici che potrebbero influenzare la comunicazione.
Suggerimento: i comuni problemi di audio unidirezionale sono correlati a ACL non configurati correttamente sulle regole del firewall o su problemi NAT. Si consiglia di verificare se questi elementi possono influire sul flusso del flusso audio.
4. Acquisire un pacchetto sull'ultimo dispositivo in cui è stato rilevato il traffico audio nella direzione di errore. In questo modo è possibile isolare il dispositivo del percorso in cui il flusso audio è stato perso. Questo è importante perché il traffico ping può essere autorizzato tramite NAT o un dispositivo firewall, ma il traffico audio specifico può essere bloccato o non tradotto correttamente.
Informazioni correlate