Decifratura del flusso RTP per l'analisi della perdita di pacchetti in Wireshark per chiamate voce e video

Opzioni per il download

PDF (1.2 MB)
Visualizza con Adobe Reader su diversi dispositivi
ePub (835.5 KB)
Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (944.8 KB)
Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi

Aggiornato:28 luglio 2014

ID documento:117881

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Sommario

Introduzione

Problema

Introduzione

Questo documento descrive il processo di decifrazione del flusso RTP (Real-Time Streaming) per l'analisi della perdita di pacchetti in Wireshark per chiamate vocali e video. I filtri Wireshark possono essere usati per analizzare acquisizioni simultanee di pacchetti all'origine o vicino alla destinazione di una chiamata. Questa funzione è utile quando è necessario risolvere problemi di qualità audio e video quando si sospetta la presenza di perdite nella rete.

Problema

In questo esempio viene utilizzato il flusso di chiamata seguente:

IP Phone A (sito centrale A) > switch 2960 > Router > router WAN (sito centrale) > IPWAN > router WAN (sito B) > Router > 2960 > IP Phone B

In questo scenario, il problema riscontrato è che le videochiamate dal telefono IP A al telefono IP B determinano una cattiva qualità video dal sito centrale A al sito di succursale B, dove il sito centrale è di buona qualità ma il lato della succursale presenta dei problemi.

Vedere i pacchetti persi dal ricevitore nelle statistiche di streaming del telefono IP della filiale:

Soluzione

La cattiva qualità è visibile solo sul lato della filiale e, poiché il sito centrale vede una buona immagine, sembra che il flusso dal sito centrale al sito della filiale stia perdendo pacchetti sulla rete.

IP addressing scheme
Central IP phone: 192.168.10.146
Central Gateway: 192.168.10.253
Central WAN router: 192.168.10.254
Branch WAN router: 192.168.206.210
Branch Gateway: 192.168.206.253
Branch IP phone: 192.168.207.231

I pacchetti vengono acquisiti sul router WAN centrale e di branch e la WAN scarta questi pacchetti. Mettere a fuoco il flusso RTP dal telefono IP centrale (192.168.10.146) al telefono IP della filiale (192.168.207.231). Il flusso non riceve i pacchetti sul router WAN della succursale se la WAN scarta i pacchetti sul flusso dal router WAN centrale al router WAN della succursale. Usare le opzioni di filtro in wireshark per isolare il problema:

Aprire la cattura in wireshark.
Usare il filtro ip.src==192.168.10.146 && ip.dst==192.168.207.231. In questo modo vengono esclusi tutti i flussi UDP dal telefono IP centrale al telefono IP della filiale.
Eseguite l'analisi solo sull'acquisizione lato diramazione, ma dovete eseguire questi passi anche per l'acquisizione centrale.
In questa schermata, il flusso UDP viene filtrato tra gli indirizzi IP di origine e di destinazione e contiene due flussi UDP (differenziati dai numeri di porta UDP). Questa è una videochiamata, quindi ci sono due flussi: audio e video. In questo esempio, i due flussi sono:
- Flusso 1: Porta di origine UDP: 20560, porta di destinazione : 20800
- Flusso 2: Porta di origine UDP: 20561, porta di destinazione : 20801
Selezionare un pacchetto da uno dei flussi e fare clic con il pulsante destro del mouse sul pacchetto.
Selezionare Decodifica con nome... e digitare RTP.
Per decodificare il flusso come RTP, fare clic su Accept (Accetto) e Ok.

Vi resta un flusso decodificato come RTP e l'altro come UDP non decodificato.
Selezionare un pacchetto dal flusso non decodificato e decodificarlo come RTP. In questo modo, vengono decodificati sia i flussi audio che video in RTP.

Nota: il flusso audio è in formato codec G.722 e il tipo di payload Dynamic-RTP-97 indica il flusso RTP video.

Il problema ora riguarda solo la qualità video. Attivare il flusso RTP video e utilizzare i numeri di porta UDP per questo flusso per filtrare altri flussi.
Visualizzare il numero di porta selezionando uno dei pacchetti per la visualizzazione delle informazioni sulla porta UDP nel riquadro inferiore dell'utility Wireshark. Nella schermata precedente, viene selezionato uno dei pacchetti dal flusso video e nel riquadro inferiore vengono visualizzate le informazioni sulla porta Src (20568) e sulla porta Dst (20808).

Suggerimento: Utilizzare questo filtro: (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 e udp.port eq 20808). In questa schermata verrà visualizzato solo il flusso RTP video.

Nota: Annotare il primo e l'ultimo numero di sequenza RTP per il flusso.

Il primo numero di sequenza RTP è 45514 e l'ultimo è 50449 per il flusso RTP video filtrato.
Accertarsi che il primo e l'ultimo pacchetto del numero di sequenza RTP siano presenti in entrambe le clip (ad esempio, acquisizioni centrali e di rami) e notare che la SSRC per il flusso sarebbe la stessa su entrambe le clip.
Perfezionare il filtro in modo che corrisponda solo ai pacchetti tra il primo e l'ultimo flusso RTP.

I numeri di sequenza vengono utilizzati per perfezionare il flusso nel caso in cui le clip non siano state acquisite contemporaneamente, ma con un lieve ritardo tra di esse.

Nota: È possibile che il sito di succursale inizi alcuni numeri di sequenza dopo 45514.
Selezionare un numero di sequenza iniziale e finale. Questi pacchetti sono presenti sia nella clip che nel filtro per visualizzare solo i pacchetti tra il numero di sequenza RTP iniziale e finale. Filtro:
```
(ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 
 and udp.port eq 20808) && ( rtp.seq>=44514 && rtp.seq<=50449 )
```
Quando si acquisiscono due clip contemporaneamente, non si perde alcun pacchetto all'inizio o alla fine di entrambe le acquisizioni. Se una delle acquisizioni non include alcuni pacchetti all'inizio o alla fine, usare il primo numero di sequenza o l'ultimo numero di sequenza nella cattura non effettuata in entrambi i pacchetti per rifinire il filtro per entrambe le acquisizioni. Osservare i pacchetti acquisiti in entrambi i punti tra gli stessi numeri di sequenza (intervallo di numeri di sequenza RTP).

Quando si applica il filtro, questo viene visualizzato nel sito centrale e nel sito di succursale:

Sito centrale:

Sito di succursale:

Notare il numero di pacchetti filtrati nel riquadro inferiore dell'utilità Wireshark in entrambe le clip. Il conteggio Visualizzato indica il numero di pacchetti che soddisfano i criteri di filtro desiderati.

Il sito centrale ha 4.936 pacchetti che soddisfano i criteri del filtro desiderati tra i numeri di sequenza RTP iniziale (45514) e finale (50449), mentre il sito della filiale ha solo 4.737 pacchetti. Ciò indica una perdita di 199 pacchetti. Notare che questi 199 pacchetti corrispondono al conteggio "Rcvr Lost Pkts" di 199, che è stato visualizzato nelle statistiche di streaming del telefono IP lato filiale mostrato all'inizio di questo documento.

Ciò conferma che tutti i pacchetti perduti RCV erano in realtà perdite di rete a livello di WAN. In questo modo, viene isolato il punto di perdita dei pacchetti nella rete, mentre i problemi di qualità audio/video vengono gestiti usando cadute sospette nella rete.