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 of mail en leg het voor. Neem ik niet op, stuur dan even een mail.
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 ongeveer 32 seconden
Een klassieker: de ACK op de 200 OK komt nooit aan. De kant die opnam blijft de 200 OK herhalen en stuurt na 32 seconden (Timer H) een BYE. Bijna altijd NAT of een ALG die een privé-adres in de Contact laat staan, waardoor de ACK de verkeerde kant op gaat. Niet de audio zelf.
RTP-timeout
Asterisk hangt op als er een tijd geen audiopakketten meer komen, als je dat aanzet (rtp_timeout in pjsip, rtptimeout in chan_sip). 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 ongeveer 32 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, verlaag dan de MTU van de tunnel. MSS clampen helpt hier niet: dat werkt alleen voor TCP, en SIP en RTP gaan meestal over UDP.
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. Wegvallende gesprekken kunnen zo een netwerkprobleem blootleggen dat ook andere dingen raakt, maar nergens anders opvalt.
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 de ACK op de 200 OK niet aankomt. Wie opneemt, herhaalt de 200 OK tot Timer H afloopt, na 32 seconden, en hangt dan op. Meestal staat er door NAT of een ALG een privé-adres in de signalering, zodat de ACK naar een adres gaat dat niet bestaat. 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 kan ik het patroon gericht 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.
Wil je dit bespreken?
Bel of mail met je vraag. Neem ik niet op, stuur dan even een mail.
Terug naar Asterisk- en VoIP-specialist