by Philip Gervasi September 28, 2018
Meestal betekent het oplossen van problemen met VoIP het oplossen van een netwerkprobleem. Dit wil niet zeggen allen VoIP-problemen zijn netwerkproblemen: er kunnen problemen zijn met de manier waarop telefoons registreren, met firmwareversies, met de configuratie van oproepbeheer, enzovoort, maar als het gaat om het oplossen van VoIP-problemen, zijn er daadwerkelijke audioproblemen zoals eenrichtingsaudio, interne oproepen die niet worden doorgestuurd goed of slechte audiokwaliteit, ik heb gemerkt dat het bijna altijd aan het netwerk ligt.
Wat is VoIP?
Wanneer er wordt gebeld op een “Voice over Internet Protocol”, oftewel VoIP, telefoon, het gesprek wordt eerst verbonden met de gespreksmanager. De callmanager belt vervolgens de telefoon van de ontvanger en wanneer iemand opneemt, geeft de callmanager de audiostream vrij naar de afzonderlijke apparaten. Op dit punt praten de twee telefoons rechtstreeks in realtime met elkaar.
“Hoezeer ik het ook haat om het toe te geven, het oplossen van VoIP-problemen 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.
VoIP-problemen oplossen
Nadat is bevestigd dat de telefoons zijn geregistreerd en de juiste IP-adressen en VLAN's ontvangen, begint het oplossen van VoIP-problemen doorgaans met het traceren van de stroom, hop voor hop. Dit kan echter ongelooflijk vervelend en tijdrovend zijn. Het omvat het vastleggen van pakketten, het inloggen op talloze apparaten, het vinden van iemand die persoonlijk toegang heeft tot telefoons en het hop voor hop doorzoeken van het netwerk met als doel precies te vinden waar in het pad de communicatie wordt verbroken.
“Ping en traceroute hebben ernstige beperkingen bij het oplossen van audioproblemen via VoIP.”
Meestal gebruiken ingenieurs eenvoudige tools zoals ping en traceroute om een pad tussen telefoons in kaart te brengen. Dit zijn eenvoudig te gebruiken ingebouwde tools, dus om te beginnen zijn ze veruit het meest gebruikelijk voor een ingenieur. Hoewel ze zeker hun plaats hebben in netwerken, hebben ping en traceroute echter ernstige beperkingen bij het oplossen van audioproblemen via VoIP.
- Ten eerste kan het volgen van het pad tussen eindpunten in een complex netwerk erg lang duren. Ik heb op deze manier uren besteed aan het oplossen van VoIP-problemen, alleen om meerdere TAC-cases te openen en pakketopnamen te maken - en dit wordt nog verergerd als je het netwerk niet zo goed kent.
- Ten tweede kijkt traceroute alleen naar laag 3-hops, en alleen die laag 3-apparaten die zijn geconfigureerd om op ICMP te reageren, zullen in de trace verschijnen. Dit vormt een groot probleem bij het oplossen van audioproblemen via VoIP. Als sommige apparaten door hun ontwerp niet reageren op traceroute, hoe kunnen we dan vaststellen waar het pad faalt?
- 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.
- 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 VoIP is speciaal ontworpen om een netwerk programmatisch in kaart te brengen (inclusief paden tussen eindpunten) en dit is ongelooflijk krachtig voor een VoIP-technicus die veelvoorkomende 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 NetBrain's A/B Path Calculator kunt u de IP-adressen van twee willekeurige eindpunten opgeven, of u nu naar laag 2 of laag 3 kijkt en welk protocol u wilt analyseren. Voor een audiotest voert u de twee IP-adressen van de telefoon in, selecteert u laag 3 om te starten en selecteert u UDP in de protocollijst. Binnen enkele seconden heeft u het realtime pad dat de apparaten gebruiken op een interactief display. U kunt heel snel zien waar ACL's zich bevinden, welk pad het RTP-verkeer volgt en waar de storing in de stroom optreedt. Dit is een ongelooflijke stap voorwaarts bij het oplossen van VoIP-problemen vergeleken 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 wil toegeven, het oplossen van VoIP-problemen betekent meestal het oplossen van een netwerkprobleem. Tot voor kort moesten engineers met simpele tools als traceroute hinken om de breuk in het netwerk te vinden. Echter, met moderne netwerkprogrammeersoftware zoals NetBrain's Dynamic Maps en A/B-padcalculator, VoIP-probleemoplossing voor éénrichtingsaudio, slechte gesprekskwaliteit, problemen met het doorschakelen van oproepen en andere veelvoorkomende VoIP-problemen zijn sneller, eenvoudiger en met een veel kortere tijd tot oplossing geworden.