One-way audio: je hoort de klant wel, de klant jou niet
Het gesprek komt tot stand, de telefoon gaat over, er wordt opgenomen. En dan hoort één van de twee niks. Irritant, want de signalering werkt duidelijk wél. Het zit bijna altijd in de audio (RTP) en niet in SIP.
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?
- Je hoort de klant, maar de klant hoort jou niet. Of precies omgekeerd.
- Intern werkt alles prima, alleen extern gaat het mis.
- Het gebeurt op één trunk, of bij één provider.
- Alleen thuiswerkers hebben het, of alleen één locatie.
- Het begon na een nieuwe firewall, router of provider.
Waar het meestal aan ligt
In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.
Asterisk kent zijn eigen publieke IP niet
Staat external_media_address en external_signaling_address (pjsip) of externip en localnet (chan_sip) niet goed, dan zet Asterisk zijn interne IP in de SDP. De andere kant stuurt de audio dus naar een adres dat op internet niet bestaat.
SIP ALG in je router of firewall
Veel consumentenrouters en sommige zakelijke firewalls herschrijven SIP-pakketten. Behulpzaam bedoeld, en het werkt ook prima tot het niet meer werkt. SIP ALG uitzetten is bij one-way audio bijna altijd stap één.
RTP-poorten niet doorgezet of dicht
SIP loopt over 5060, maar de audio gaat over een reeks UDP-poorten (standaard 10000-20000). Staat die reeks dicht, dan komt de signalering wel aan en het geluid niet.
Verkeerde media-richting in de SDP
Een verkeerd overgenomen directmedia-instelling, of een re-INVITE van je provider die je kant niet verwacht. In de trace zie je dan RTP maar één richting op lopen.
Codec-mismatch of transcoding die faalt
Is de enige gemeenschappelijke codec niet beschikbaar (G.729 zonder licentie, Opus zonder module), dan komt het gesprek tot stand en blijft de audio stil.
Dubbel NAT of een tweede router
Een modem in routermodus met daarachter nog een router: twee keer NAT. Het publieke IP dat Asterisk denkt te hebben, is dan niet het adres waarop de audio binnenkomt.
Wat ik als eerste check
Doe deze stappen zelf, of bel en dan lopen we ze samen door.
- 1
Kijk welke richting stil is
Bel intern, bel uit, laat je bellen. De stille richting vertelt wie de audio verkeerd stuurt. Alleen inkomend stil? Dan ontvangt jouw kant het RTP niet (firewall of NAT). Alleen uitgaand stil? Dan kan de andere kant jouw SDP niet volgen.
- 2
Draai een SIP-trace mee
Met
sngrepop de centrale zie je in één mislukt gesprek de hele SDP-onderhandeling. Kijk welk IP in dec=-regel staat. Een adres uit 10.0.0.0/8, 172.16.0.0/12 of 192.168.0.0/16 terwijl het gesprek over internet gaat: dat is je oorzaak. - 3
Controleer de NAT-instellingen van Asterisk
Bij pjsip:
external_media_address,external_signaling_addressenlocal_netin de transport-sectie. Bij chan_sip:externipofexternhost,localnetennat=force_rport,comedia. Leg het publieke IP dat daar staat naast het IP dat je router echt gebruikt. - 4
Zet SIP ALG uit
Zoek in je router of firewall op SIP ALG, SIP-helper of VoIP-passthrough en zet het uit. Op MikroTik is dat
/ip firewall service-port set sip disabled=yes. Daarna toestellen opnieuw laten registreren. - 5
Vergelijk de RTP-poorten met je firewall
Zet
rtp.conf(rtpstartenrtpend) naast wat je firewall doorlaat en forward. Die hele reeks moet als UDP open, niet alleen poort 5060. - 6
Kijk of het bij één provider of één locatie zit
Alleen op één trunk? Dan onderhandelt die provider anders, bijvoorbeeld met
rtcp-muxof een SBC die media vanaf een ander IP stuurt. Alleen bij één toestel of locatie? Dan zit het in dat netwerk en niet in je centrale.
Waarom dit zo vaak misgaat
SIP en RTP zijn twee losse stromen. SIP regelt wie wie belt en spreekt af waar de audio naartoe moet. De audio zelf gaat daarna een eigen weg, rechtstreeks tussen de toestellen of via je centrale. Die afspraak staat in de SDP, en daarin zet elke kant het IP-adres waarop hij audio wil ontvangen.
Zit je centrale achter NAT en weet hij dat niet? Dan vult hij daar netjes zijn interne adres in. De andere kant gelooft dat, stuurt de audio naar 192.168.x.x en die pakketten komen nergens aan.
SIP blijft intussen prima werken. Vandaar dat je wel verbinding hebt en toch niks hoort.
Even meekijken?
Een SIP-trace lezen is vooral weten waar je moet kijken. Stuur me een sngrep-opname van één mislukt gesprek, of geef me even toegang, dan zeg ik je waar de audio blijft. Ook als je daarna zelf de firewall aanpast.
Veelgestelde vragen
- Waarom werkt het intern wel en extern niet?
- Intern gaat de audio niet door NAT of firewall heen. Beide kanten zien een adres dat werkt. Zodra er een publiek IP tussen zit, moet Asterisk het juiste externe adres in de SDP zetten en moet het RTP langs je firewall komen. Daar gaat het mis.
- Ik heb poort 5060 doorgezet, maar het blijft stil.
- Poort 5060 is alleen de signalering. Het geluid loopt over een aparte UDP-reeks, standaard 10000 tot 20000. Zolang die dicht staat krijg je precies dit beeld: bellen werkt, geluid niet.
- Kan het aan mijn provider liggen?
- Ja, dat komt voor. Een SBC die media vanaf een ander IP-bereik stuurt dan de signalering, of een re-INVITE die jouw kant niet verwacht. Met een trace aan jouw kant kan je dat aantonen, en dan heb je iets concreets om je provider voor te leggen.
- Hoe snel is dit meestal opgelost?
- Met toegang tot de centrale en de firewall vind ik dit vrijwel altijd binnen een uur. De trace wijst het aan. Het lange zoeken zit in niet weten waar je moet kijken.
Verwante problemen
SIP-registratie mislukt: toestel of trunk komt niet online
Toestel of SIP-trunk registreert niet? 403 Forbidden, 401 Unauthorized en 408 Timeout hebben elk een eigen oorzaak. Dit betekenen ze.
[Gesprekskwaliteit]Gesprekken vallen weg of haperen
Gesprekken die na 30 seconden wegvallen, haperende audio of robotstemmen. Meestal RTP-timeouts, jitter, MTU of QoS. 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.
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