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:

1. Aprire la cattura in wireshark.

2. 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.

3. Eseguite l'analisi solo sull'acquisizione lato diramazione, ma dovete eseguire questi passi anche per l'acquisizione centrale.

4. 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

5. Selezionare un pacchetto da uno dei flussi e fare clic con il pulsante destro del mouse sul pacchetto.

6. Selezionare Decodifica con nome... e digitare RTP.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.