Ontdek de RTP-stream voor pakketverlies analyse in Wireless-shark voor spraak- en video-oproepen

Downloadopties

PDF (1.2 MB)
Met Adobe Reader op diverse apparaten bekijken
ePub (835.6 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (944.9 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:28 juli 2014

Document-id:117881

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

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:

Open de vangst in wireshark.
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.
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.
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
Selecteer een pakket uit een van de stromen en klik met de rechtermuisknop op het pakket.
Selecteer Decode als... en type RTP.
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.
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.
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.
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.
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.
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.