Gesprekken vallen weg of haperen
Wegvallende of haperende gesprekken zijn hardnekkiger dan een centrale die helemaal niet werkt: het gaat om timing, pakketverlies en soms om één tussenliggende hop. Het patroon waarin het gebeurt, verraadt bijna altijd de oorzaak.
Loop je hier nu tegenaan?
Bel en leg het voor. Vaak is in tien minuten duidelijk waar het aan ligt. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Herken je dit?
- Gesprekken vallen weg na ongeveer 30 seconden, altijd rond hetzelfde moment.
- Audio hapert, klinkt robotachtig of valt kort weg tijdens het gesprek.
- Het gebeurt alleen als er meerdere gesprekken tegelijk lopen.
- Het gebeurt alleen bij thuiswerkers of op één locatie.
- Het lijkt erger op momenten dat er veel ander netwerkverkeer is.
Waar het meestal aan ligt
In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.
Wegvallen na precies 30 seconden
Een klassieker: de ACK of de re-INVITE komt niet aan, waarna de sessietimer het gesprek opruimt. Bijna altijd NAT of een firewall die de retour niet doorlaat, niet de audio zelf.
RTP-timeout
Asterisk hangt op als er een tijd geen audiopakketten meer komen (rtptimeout). Dat is een symptoom: de echte vraag is waarom de audiostroom stopte.
Jitter en pakketverlies
Haperende of metalige audio duidt op verlies of ongelijkmatige aankomsttijden. Bij VoIP is 1% verlies al hoorbaar; bufferen helpt maar tot een bepaald punt.
Geen QoS op een volle uplink
Zodra iemand een grote upload doet, komt de audio in de wachtrij achter dat verkeer. Zonder prioritering op de router is telefonie het eerste dat je hoort afbrokkelen.
MTU- en fragmentatieproblemen
Vooral over VPN's of PPPoE: te grote pakketten worden gefragmenteerd of gedropt. Signalering met veel SDP-regels past soms niet meer in één pakket.
Transcoding of een overbelaste centrale
Veel gelijktijdige gesprekken die van codec moeten wisselen, kosten CPU. Loopt de load op, dan komt de audio met vertraging de machine uit.
Wat ik als eerste check
Doe deze stappen zelf, of bel en dan lopen we ze samen door.
- 1
Kijk of er een patroon in de tijd zit
Wegvallen na precies 30 seconden is een signaleringsprobleem, niet een audioprobleem. Willekeurig wegvallen of haperen wijst op verlies of jitter. Dat onderscheid bepaalt waar je gaat kijken.
- 2
Lees de CDR's en de logs
In de logs staat wie het gesprek beëindigde en met welke reden (
BYEvan de provider,RTP timeout, sessietimer). Dat is het verschil tussen "de andere kant hangt op" en "wij hangen op". - 3
Meet het pad, niet alleen de eindpunten
Met
mtrnaar de provider zie je verlies per hop en jitter over tijd. Een enkele ping zegt niets; je wilt minuten meten tijdens een gesprek. - 4
Controleer de kwaliteitsstatistieken van het gesprek
Met
pjsip show channelstats(of de RTCP-rapporten) zie je jitter en verlies per gesprek. Daarmee weet je welke richting het verliest. - 5
Test met QoS aan en uit
Zet prioritering aan voor je SIP- en RTP-poorten op de uplink en kijk of het patroon verandert. Verdwijnt het bij een lege lijn en komt het terug bij drukte, dan heb je je oorzaak.
- 6
Sluit MTU uit
Loopt het verkeer over een VPN, dan test je met
ping -M do -s 1400of grote pakketten er ongeschonden doorkomen. Zo niet, dan MSS clampen of de MTU verlagen.
Timing, niet techniek als verwijt
Bij gesprekskwaliteit gaat het om marges. Een webpagina die 200 milliseconden later komt, merkt niemand; bij audio hoor je het meteen. Daardoor is telefonie de eerste toepassing die klaagt als er iets mis is in het netwerk — en dus ook het beste meetinstrument. Vaak vind ik bij een onderzoek naar wegvallende gesprekken een netwerkprobleem dat ook andere zaken raakte, maar nergens anders opviel.
Meten in plaats van gokken
Wegvallende gesprekken zijn goed te herleiden, zolang je meet terwijl het gebeurt. Ik kan meekijken tijdens een storing, aan beide kanten meten en daarna zeggen wat er moet veranderen: de centrale, de firewall, de uplink of de provider.
Veelgestelde vragen
- Waarom valt een gesprek precies na 30 seconden weg?
- Omdat dat de standaardtermijn is waarop SIP de sessie opnieuw bevestigt. Komt die bevestiging niet aan — meestal door NAT of een firewall die het retourpakket niet doorlaat — dan wordt het gesprek netjes opgeruimd. Het is dus een signaleringsprobleem, ook al hoor je het als een audioprobleem.
- Mijn internet is snel genoeg, dus het kan geen bandbreedte zijn.
- Bandbreedte is zelden het probleem; een gesprek kost ongeveer 100 kbit/s. Het gaat om de wachtrij: één grote upload zonder prioritering zet je audiopakketten achteraan. Snelheid helpt daar niet tegen, QoS wel.
- Kan het aan mijn toestellen liggen?
- Dat kan, vooral bij verouderde firmware of wifi-toestellen. Maar als het op meerdere toestellen en meerdere modellen gebeurt, is het netwerk of de centrale waarschijnlijker. Dat pel je van buiten naar binnen af.
- Wat heb je van mij nodig om dit te onderzoeken?
- Toegang tot de centrale, het tijdstip van een gesprek dat wegviel, en idealiter de mogelijkheid om een meting op de uplink te doen. Met die combinatie is een wegvalpatroon meestal binnen een paar uur te herleiden.
Verwante problemen
One-way audio: je hoort de klant wel, de klant jou niet
One-way audio komt bijna altijd doordat de audio (RTP) de verkeerde kant op gaat. NAT, externip, SIP ALG of je firewall. Dit check ik als eerste.
[MTU & pakketverlies]Pakketverlies en MTU-problemen vinden
Sommige sites laden niet, VPN-verkeer hapert, grote bestanden blijven hangen: typische MTU-symptomen. Zo onderscheid je MTU van echt pakketverlies.
[VPN-tunnel]VPN-tunnel komt niet op of is instabiel
Site-to-site VPN die niet opkomt, elke paar uur wegvalt of waar alleen groot verkeer misgaat. WireGuard, IPsec en OpenVPN: dit zijn de oorzaken.
Zelf geen tijd of geen zin om te blijven zoeken?
Ik kijk mee, zeg eerlijk wat er aan de hand is en los het op. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Terug naar Asterisk specialist inhuren