Inhoud

Inleiding

Probleem

Inleiding

Dit document beschrijft het proces van het ontcijferen van de Real-Time Streaming (RTP)-stroom voor pakketverlies analyse in Wireshark voor spraak- en videooproepen. U kunt Wireshark filters gebruiken om simultane pakketvastlegging te analyseren die bij de bron en bestemming van een vraag is genomen of dicht bij de bron en de bestemming ervan. Dit is handig wanneer u problemen met de audio- en videokwaliteit moet oplossen wanneer netwerkverliezen worden vermoed.

Probleem

Dit voorbeeld gebruikt deze aanroep flow:

IP-telefoon A (centrale siteA) > 2960 switch > router > WAN-router (Central site) > IPWAN-router (site B) > router > 2960 > IP-telefoon B

In dit scenario is het probleem dat wordt ondervonden dat videogesprekken van IP telefoon A naar IP telefoon B resulteren in slechte videokwaliteit van centrale plaats A naar bijkantoor site B waar de centrale goede kwaliteit heeft maar de kant van de tak problemen heeft.

Zie de ontvanger verloren pakketten in de streamingstatistieken van de IP-telefoon van de tak:

Oplossing

De slechte kwaliteit wordt slechts aan de zijkant gezien en omdat de centrale site een goede afbeelding ziet, lijkt de stroom van het centrum naar de site te zijn weggelopen op pakketten via het netwerk.

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

Het pakket neemt de opnamen op de router van Centraal en Vestiging WAN en WAN daalt deze pakketten. Stel scherp op de RTP-stroom van een centrale IP-telefoon (192.168.10.146) naar een IP-telefoon op de aftakking (192.168.207.231). Deze stroom mist pakketten op de router van vertakt WAN als WAN de pakketten op de stroom van centrale WAN router aan de router van vertakt WAN laat vallen. Gebruik de filteropties in draak om het probleem te isoleren:

1. Open de vangst in wireshark.

2. Gebruik het filter ip.src==192.168.10.146 en ip.dst==192.168.207.231. Dit filtreert alle UDP-stromen uit van centrale IP-telefoon naar IP-aftakking.

3. Voer de analyse alleen uit aan de kant van de tak maar let op dat u deze stappen ook voor de centrale opname moet uitvoeren.

4. In dit screenshot wordt de UDP-stream gefilterd tussen de bron en de IP-adressen van de bestemming en bevat deze twee UDP-stromen (gedifferentieerd door de UDP-poortnummers). Dit is een videogesprek, dus er zijn twee stromen: audio en video. In dit voorbeeld zijn de twee stromen:

- Stroom 1: UDP-bronpoort: 20560, haven van bestemming : 20800

- Stream 2: UDP-bronpoort: 20561, haven van bestemming : 20801

5. Selecteer een pakket uit een van de stromen en klik met de rechtermuisknop op het pakket.

6. Selecteer Decode als... en type RTP.

7. Klik op Accepteren en OK om de stream als RTP te decoderen.

U blijft behouden met de ene stream gedecodeerd als RTP en de andere als niet-gedecodeerde UDP.

8. Selecteer een pakje in de niet-gedecodeerde stream en decoder het als RTP. Dit decodeert zowel de audio als de videostromen in RTP.

Opmerking: de audiostroom is in G.722-codec en het dynamische-RTP-97-type geeft het videoverloop RTP-stream aan.

Het probleem is nu alleen met de videokwaliteit. Stel scherp op de video RTP-stream en gebruik de UDP-poortnummers voor deze stream om andere stromen te filteren.

9. Bekijk het poortnummer door een van de pakketten te selecteren die de UDP poortinformatie in het onderste venster van het Wireless-shark hulpprogramma weergeven. In het vorige screenshot wordt een van de pakketten uit de videostream geselecteerd en u kunt de informatie over de SRC Port (20568) en de Dst Port (20808) in het ondervenster zien.

Tip: Gebruik dit filter: (ip.src==192.168.10.146 en ip.dst==192.168.207.231) en (udp.port eq 20568 en udp.port eq 2080 8). U ziet alleen de video RTP-stream die in dit screenshot wordt getoond.

Opmerking: Schrijf de eerste en de laatste RTP sequentienummers voor deze stroom op.

Het eerste RTP-sequentienummer is 45514 en het laatste is 50449 voor de gefilterde out video RTP-stream.

10. Zorg ervoor dat het eerste en het laatste RTP opeenvolgingsaantal pakketten in beide opnamen aanwezig zijn (bijvoorbeeld, centrale en bijtakking) en let erop dat SSRC voor de stroom op beide opnamen hetzelfde zou zijn.

11. Reinig het filter zodat alleen de pakketten tussen de eerste en de laatste RTP-stromen overeenkomen.

De sequentienummers worden gebruikt om de stroom te verfijnen voor het geval dat de opnamen niet tegelijkertijd werden genomen, maar met een lichte vertraging tussen beide.

Opmerking: Het is mogelijk dat de site een aantal sequentienummers kan starten na 45514.

12. Selecteer een begin- en eindsequentienummer. Deze pakketten zijn aanwezig in zowel de opnamen als het filter verfijnen om slechts die pakketten tussen het begin en de reeks van het eind RTP te tonen. Het filter van dit programma is:

(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 )
Wanneer opnamen tegelijkertijd worden genomen, worden er aan het begin of aan het eind geen pakketten gemist op beide opnamen. Als u ziet dat één van de opnames geen paar pakketten aan het begin/eind omvat, gebruik het eerste reeks of het laatste opeenvolgingsaantal in de opname gemist in beide pakketten om het filter voor beide opnamen te verfijnen. Neem de pakketten in acht die op beide punten tussen de zelfde opeenvolgingsnummers (RTP opeenvolgingsnummerreeks) worden opgenomen.

Wanneer u het filter toepast, ziet u dit op de centrale plaats en de locatie van het filter:

Centrale site :

Vestigingssite:

Merk op dat het gefilterde pakketnummer in het onderste venster op het programma Wireshark op beide opnamen zit. De weergegeven telling geeft het aantal pakketten weer dat overeenkomt met de gewenste filtercriteria.

De centrale site heeft 4.936 pakketten die overeenkomen met de gewenste filtercriteria tussen het begin (45514) en het eind (50449) RTP opeenvolgingsnummers terwijl er op de filiaallocatie slechts 4.737 pakketten zijn. Dit geeft een verlies van 199 pakketten aan. Let op dat deze 199 pakketten overeenkomen met de "Rcvr Lost Pkts" tel van 199 die werd gezien in de streamingstatistieken van de IP-telefoon aan de zijkant van de tak die aan het begin van dit document werd getoond.

Dit bevestigt dat alle Verloren Packets van Rcvr in feite netwerkverliezen waren die over WAN zijn gevallen. Dit is hoe het punt van pakketverlies in het netwerk geïsoleerd is terwijl de audio/videokwaliteit kwesties worden behandeld met verdachte netwerkdruppels.