Az utóbbi időben egy idegesítő hibával küzdöttem: iPhone + Groundwire softphone mobilnetről simán felépítette a hívást a saját Asterisk/Issabel PBX-emre, a túloldal hallott engem, de a telefon felé nem jött be hang. Klasszikus „egyirányú hang” tünet, minden VoIP‑os rémálma.
A helyzetet bonyolította, hogy mobilneten, dupla NAT/CGNAT mögött vagyok, így elsőre mindenki NAT‑ra mutogat. De a konkrét ok végül nem a Groundwire‑ben, hanem a PBX NAT/média beállításában volt.
Tünetek: minden jelzés oké, csak a hang hiányzik
A hívások jelzés szinten hibátlanul működtek:
- REGISTER / INVITE / 200 OK / ACK szépen lement.
- A hívás felépült, a túloldal rendesen hallott.
- A Groundwire oldalon viszont néma volt a bejövő hang.
A Groundwire debug logjaiban látszott, hogy:
- a kliens folyamatosan küldi az RTP csomagokat a PBX felé (Sent Audio RTP packet…),
- viszont bejövő RTP‑ről semmi nyom, és a hívás közben „AudioIoaudioDataReadAccumulate Not Enough Data” üzenetek jelentek meg.
Vagyis: uplink van, downlink nincs – ez szinte mindig NAT/média irányú probléma.
Első nyomok: mit mond az SDP?
Megnéztem az INVITE/200 OK SDP‑ket.
A PBX (pintyo‑s rendszer) így hirdette a médiát:
v=0
o=root 1233995227 1233995227 IN IP4 84.224.109.185
s=Asterisk PBX 18.19.0
c=IN IP4 84.224.109.185
t=0 0
m=audio 18314 RTP/AVP 8 0 3 107 101
a=rtpmap:8 PCMA/8000
...
a=sendrecv
A Groundwire erre az alábbi saját SDP‑vel válaszolt:
c=IN IP4 192.168.11.91
m=audio 60330 RTP/AVP 8 101
...
a=sendrecv
A kliens tehát a 192.168.11.91:60330‑ról küldi az RTP-t kifelé. Mobilnet + Wi‑Fi‑s környezetben ez a cím valójában egy belső IP, ami CGNAT után egy teljesen más publikus IP/portra fordul át. A PBX viszont nem azt a címet használta vissziránynak, ahonnan ténylegesen érkezett az RTP, hanem a saját NAT‑logikáját követte.
Kulcs: mit tud a chan_sip peer NAT‑ról?
A következő lépés az volt, hogy megnézzem a 201-es mellék státuszát Asteriskben:
asterisk -rx "sip show peer 201"
A fontos részek:
Force rport : No
Symmetric RTP: No
DirectMedia : No
Addr->IP : 167.99.119.203:31645
Reg. Contact : sip:201@10.65.11.2:31645;rinstance=...
A DirectMedia (canreinvite) szerencsére már eleve ki volt kapcsolva, viszont:
- Force rport: No
- Symmetric RTP: No
Tehát a chan_sip peer gyakorlatilag nem használta azt a forrás IP/port párost, ahonnan a kliens valójában jött, hanem az SDP‑ben megadott címre próbált visszaküldeni. Ez LAN‑on még elmegy, de CGNAT mögött biztos bukás.
Ezzel tulajdonképpen meg is volt a diagnózis:
nem a Groundwire, hanem a chan_sip NAT/média logikája volt alkalmatlan CGNAT‑os kliensekhez.
A megoldás: NAT a PBX oldalán, nem a kliensben
A fix három lépésből állt.
1. Globális NAT beállítás chan_sip-hez
Először a globális SIP NAT‑ot tettem rendbe:
; /etc/asterisk/sip_general_custom.conf
externip = 84.224.109.185
localnet = 192.168.0.0/16
nat = force_rport,comedia
externip– a PBX publikus IP‑je.localnet– a belső háló(k).nat = force_rport,comedia– ez adja meg a kívánt NAT‑viselkedést (rport + comedia).
Ez biztosítja, hogy a PBX tudja, mikor van NAT mögött, és hogyan kezelje a kliens címét.
2. NAT és DirectMedia kikapcsolása a 201-es melléken
Mivel a mellékeket az Issabel GUI kezeli, a per‑peer NAT‑ot a webes felületen állítottam:
- A 201-es melléknél a NAT mezőt
Yes-re tettem. - A Direct Media (canreinvite) alapból
No, de ha látszik ilyen mező, akkor mindenképpNolegyen.
A háttérben ez a konfiguráció jött létre:
[201]
host=dynamic
type=friend
context=from-internal
secret=...
nat=force_rport,comedia
directmedia=no
...
Reload után újra megnéztem:
asterisk -rx "sip show peer 201"
És végre ez fogadott:
Force rport : Yes
Symmetric RTP: Yes
DirectMedia : No
Vagyis:
- rport használat: bekapcsolva
- symmetric RTP: bekapcsolva
- direct media / canreinvite: kikapcsolva
Pont ez kell CGNAT mögötti kliensekhez.
3. Újratesztelés Groundwire-rel
Ugyanabból a mobilnetes környezetből indítottam újra a hívást a 201-es mellékre Groundwire-rel.
Eredmény:
- A hívás jelzés szinten ugyanúgy felépült.
- A túloldal továbbra is hallotta a mobilt.
- És végre a Groundwire‑en is megjelent a bejövő hang – kétirányú, stabil be
