Automatiseer Voice Over IP-probleemoplossing (VOIP)

by Philip Gervasi September 28, 2018

Meestal betekent het oplossen van VOIP-problemen het oplossen van een netwerkprobleem. Dit wil niet zeggen dat allen VoIP-problemen zijn netwerkproblemen: er kunnen problemen zijn met de manier waarop telefoons worden geregistreerd, met firmwareversies, met de configuratie van de callmanager, enzovoort, maar als het gaat om het oplossen van problemen, zijn er echte audioproblemen, zoals eenrichtingsaudio, interne oproepen die niet correct worden doorgeschakeld , of slechte geluidskwaliteit, heb ik gemerkt dat het bijna altijd aan het netwerk ligt.

Wanneer een oproep op een VoIP-telefoon wordt geplaatst, wordt de oproep eerst verbonden met de callmanager. De callmanager belt vervolgens de telefoon van de ontvanger en wanneer iemand opneemt, geeft de callmanager de audiostream vrij voor de afzonderlijke apparaten. Op dit punt spreken de twee telefoons in realtime rechtstreeks met elkaar.

"Hoe graag ik het ook toegeef, het oplossen van een VoIP-probleem betekent meestal het oplossen van een netwerkprobleem." – Een netwerkingenieur

Dat is een heel eenvoudig overzicht van hoe een typische oproepconfiguratie plaatsvindt, maar houd er rekening mee dat telefoons zich op verschillende geografische locaties en in verschillende subnetten kunnen bevinden. Het is niet langer alleen een kwestie van een telefoon die een callmanager kan bereiken. Bidirectionele communicatie tussen endpoints moet ook perfect werken, en in complexe netwerken betekent dat strijd met firewalls, dynamische routering, toegangscontrolelijsten en asymmetrische routering.

Het meeste VoIP-audioverkeer gebruikt het real-time transportprotocol of RTP als transport. RTP tussen twee eindpunten bestaat als een UDP-stream die volledig afhankelijk is van het onderliggende netwerk; daarom resulteert elk probleem met het netwerk dat verhindert dat de ene kant van de audiostream de andere kant bereikt, in een audioprobleem.

Nadat is bevestigd dat de telefoons zijn geregistreerd en de juiste IP-adressen en VLAN's hebben ontvangen, begint het oplossen van problemen meestal met het stap voor stap volgen van de stroom. Dit kan echter ongelooflijk vervelend en tijdrovend zijn. Het omvat het vastleggen van pakketten, inloggen op talloze apparaten, iemand vinden die persoonlijk toegang heeft tot telefoons en het netwerk hop voor hop doorzoeken met als doel precies te vinden waar in het pad de communicatie is verbroken.

“Ping en traceroute hebben ernstige beperkingen voor het oplossen van VoIP-audioproblemen.”

Doorgaans gebruiken technici eenvoudige hulpmiddelen zoals ping en traceroute om een ​​pad tussen telefoons in kaart te brengen. Dit zijn eenvoudig te gebruiken ingebouwde hulpmiddelen, dus ze zijn verreweg de meest gebruikelijke voor een ingenieur om mee te beginnen. Hoewel ze zeker hun plaats hebben in netwerken, hebben ping en traceroute ernstige beperkingen voor het oplossen van VoIP-audioproblemen.

1. Ten eerste kan het in een complex netwerk erg lang duren om het pad tussen eindpunten te traceren. Ik heb op deze manier uren besteed aan het oplossen van problemen, alleen om meerdere TAC-zaken en pakketopnames te openen - en dit wordt nog erger als je het netwerk niet zo goed kent.
2. Ten tweede kijkt traceroute alleen naar laag 3-hops, en alleen die laag 3-apparaten die zijn geconfigureerd om te reageren op ICMP, worden weergegeven in de tracering. Dit vormt een enorm probleem bij het oplossen van VoIP-audioproblemen. Als sommige apparaten door hun ontwerp niet reageren op traceroute, hoe kunnen we dan vaststellen waar het pad faalt?
3. Traceroute houdt geen rekening met asymmetrische routering, wat heel gebruikelijk is in grote netwerken. Ik werkte bijvoorbeeld aan een eenrichtingsaudioprobleem voor een klant die tientallen locaties in mijn regio had, en het pad van de ene site naar de andere was vaak anders dan het retourverkeer. Vooral als er een soort multipad-technologie wordt gebruikt, kan het volgen van tweerichtingspaden die van stroom tot stroom kunnen veranderen een zinloze oefening zijn.
4. Traceroute houdt geen rekening met laag 2-apparaten. Hoewel er misschien maar een paar routers tussen twee telefoons zijn, kunnen er heel goed tientallen schakelaars werken op laag 2 in het pad. In de context van een end-to-end Quality of Service-configuratie moet rekening worden gehouden met elk afzonderlijk apparaat in het pad. Dit omvat elke router, elke firewall en elke switch.

Traceroute is beperkt in zijn vermogen om precies te vinden waar in het pad de VoIP-communicatie is verbroken.

Ondanks de beperkingen van traceroute, is het analyseren van het volledige pad tussen endpoints nog steeds de sleutel tot het vinden van de oorzaak van veelvoorkomende VoIP-problemen, en hier komt intelligente netwerkmapping om de hoek kijken. NetBrainHet platform van het bedrijf is specifiek ontworpen om een ​​netwerk programmatisch in kaart te brengen, inclusief paden tussen eindpunten, en dit is ongelooflijk krachtig voor een technicus die veelvoorkomende VoIP-problemen oplost.

Het analyseren van het volledige pad tussen eindpunten is de sleutel tot het vinden van de oorzaak van veelvoorkomende VoIP-problemen.

Eerste, NetBrain's Dynamic Maps maak een real-time en interactieve kaart van het netwerk zonder apparaat naar apparaat te hoeven crawlen traceroute en toon cdp-buren. Je kunt heel snel onderscheiden met wat voor soort apparaten je te maken hebt en waar ACL's actief zijn, NAT wordt uitgevoerd, herverdeling van routes plaatsvindt, enzovoort.

In mijn ervaring is dit misschien genoeg om te zien waar de probleemplekken zijn. NAT, ACL's en herdistributie van routes zijn allemaal boosdoeners geweest van audioproblemen die ik in de loop der jaren heb moeten oplossen. Om u echter op een specifieke audiostroom te concentreren, NetBrain's A/B-padcalculator brengt dynamisch het daadwerkelijke pad tussen eindpunten in kaart. In het kader van VoIP-probleemoplossing kan deze tool letterlijk uren besparen.

Geef gewoon een bron- en bestemmingsadres op om het daadwerkelijke pad tussen eindpunten dynamisch in kaart te brengen.

gebruik NetBrainMet de A/B Path Calculator kunt u de IP-adressen van twee willekeurige eindpunten specificeren, of u nu naar laag 2 of laag 3 wilt kijken, en welk protocol u wilt analyseren. Voer voor een audiotest de twee IP-adressen van de telefoon in, selecteer laag 3 om te starten en selecteer UDP in de protocollijst. Binnen enkele seconden heb je het real-time pad dat de apparaten gebruiken in een interactief display. U kunt heel snel onderscheiden waar ACL's zijn, welk pad RTP-verkeer volgt en waar de storing in de stroom plaatsvindt. Dit is een ongelooflijke stap voorwaarts in het oplossen van spraakproblemen in vergelijking met het onhandig pingen over een netwerk en het gebruik van traceroute tussen apparaten.

Binnen enkele seconden heeft A Dynamic Map toont u ACL's, RTP traffic paths, en waar de storing in de stroom optreedt.

Een andere veelvoorkomende oorzaak van audioproblemen is een slechte verbindingskwaliteit of verbindingen met een lage bandbreedte in het pad tussen eindpunten. Dit is de reden waarom Quality of Service is ontwikkeld: om in de wachtrij te staan, prioriteiten te stellen en er anderszins voor te zorgen dat bepaald verkeer (meestal spraak) alle netwerkbronnen krijgt die het nodig heeft voor een goede eindgebruikerservaring.

Omdat een audiostream UDP gebruikt, is deze inherent onbetrouwbaar en heeft het geen foutcontrolemechanisme om slechte pakketten opnieuw te verzenden. Bovendien, als er aanzienlijke congestie is op een link en er geen QoS is geconfigureerd om prioriteit te geven aan audioverkeer, zal het eindresultaat waarschijnlijk audio van zeer slechte kwaliteit zijn of zullen oproepen helemaal worden verbroken.

Het probleem met QoS is dat het perfect end-to-end moet worden geconfigureerd om effectief te zijn.

 

Maar het probleem met QoS is dat het perfect end-to-end moet worden geconfigureerd om effectief te zijn. Elke toegangspoort die wordt gebruikt om spraakverkeer tot stand te brengen, elke trunkpoort en elke laag 3-afsluiting moet een consistent servicebeleid hebben. In een groot netwerk kan dit een enorm aantal interfaces zijn. Meestal betekent dit dat eerst het pad tussen eindpunten moet worden getraceerd en vervolgens op elk afzonderlijk apparaat moet worden ingelogd om te zien of de QoS-configuratie aanwezig en correct is.

NetBrain lost dit probleem ook programmatisch op door ingebouwde en aanpasbare Qapps te gebruiken om informatie op te halen van alle netwerkapparaten in het pad en een interactieve kaart met relevante informatie weer te geven, zoals QoS-configuratie op elk apparaat en daadwerkelijke wachtrijdalingen die wijzen op een probleem met het beleid.

Haal automatisch live gegevens op van elk apparaat langs het pad, markeer het interfacebeleid en detecteer het wegvallen van wachtrijen.

Door deze informatie programmatisch te kunnen verzamelen, kan een technicus een VoIP-probleem snel oplossen. Anders kost het ongelooflijk veel tijd om QoS-informatie apparaat voor apparaat handmatig op te halen.

Het handmatig verkrijgen van dit niveau van QoS-informatie, apparaat voor apparaat, zou ongelooflijk veel tijd kosten.

Hoe graag ik het ook toegeef, het oplossen van een VoIP-probleem betekent meestal het oplossen van een netwerkprobleem. Tot voor kort moesten ingenieurs hinken met eenvoudige tools zoals traceroute om de breuk in het netwerk te vinden. Echter, met moderne netwerkprogrammeerbaarheidssoftware zoals NetBrain's Dynamic Maps en A/B Path Calculator is het oplossen van eenrichtingsaudio, slechte gesprekskwaliteit, doorschakelproblemen en andere veelvoorkomende VoIP-problemen nu sneller, eenvoudiger en met een veel kortere tijd tot oplossing.