PBX gond: mellékeket nem lehet hívni

VoIP

Sziasztok!

Szívatom magam, de nem tudok rájönni, mit rontottam el.

Van egy működőképes FrePBX / Asterisk alapú telefonrendszer néhány Grandstrem telefonnal + 2 kapucsengővel. Minden működik. Viszont a rendszer már öregszik, 4-5 éves a telepítés, a PBX alatt levő oprendszer (CentOS) már nem támogatott, valamint van egy kis HW gond is, mert a szoftveres RAID rendszeresen szétesik.

Gondoltam, rendbeteszem, megnézem, mi a HW problémája, valamint megkapja a legújabb, már Debian alapú rendszert. Fogtam egy használaton kívüli, működőképes gépet, feltelepítettem, bekonfiguráltam úgy, hogy minden beállítás, azonosítók, jelszók, IP címek ugyanazok, mint az eredeti gépen. A terv, hogy amíg régi gépet rendberakom, ez lesz berakva helyette. Természetesen teszteltem is, amennyire lehetett, bár csak szoftveres mellékkel tudtam ezt megtenni.

Aztán amikor ki akartam cserélni a két gépet, jött a szívás. Szóval a jelenlegi helyzet:
- A trönk beregisztrál
- A telefonok beregisztrálnak, a webes felületükön legalább is ezt kommunikálják
- Kifele menő hívás tökéletesen működik a mellékekről
- A befele jövő hívás működik, egészen addig a pontig, amíg nem kellene melléken csörögnie (tehát felmondja az IVR-t, működik a hangpostafiók, stb)
- Melléket nem lehet hívni sehonnan, 486-os hibával elutasít. Úgy viselkedik a rendszer, mintha nem látná a mellékeket, hogy be lennének regisztrálva. De közben a mellékekről lehet hívást indítani!

A problémát nem befolyásolta a tűzfal állapota, se kikapcsolva, se bekapcsolva nem megy.

Merrefele keresgéljek? A munkahelyemen már készítettem ilyen szervert, itt működik is rendesen. Ennek a gépnek az elkészítésénél is igyekeztem lépésről lépésre mindent ugyanúgy csinálni.

Gábor

  • 978 megtekintés

( coco | 2026. 02. 25., sze – 13:50 )

Feltételezem NAT mögött van, a szolgáltató támogatja a NAT detectiont? Ha nem akkor externhost-ot kell állítani, illetve a megfelelő portot (valószínűleg 5060) be kell forwardolni. Amikor ráhivsz látod bejönni a SIP kérést? 

Szia!

Mint írtam, a kimenő és a bejövő hívások működnek, a trönk be van regisztrálva. A bejövő hívás eljut az IVR-ig (bejelentkező menü), illetve a hangpostafiókig is, csak a mellékeket nem tudja a rendszer csöngetni.

Két mellék sem tudja egymást hívni!

Azon kívül eddig is ilyen rendszer üzemelt, csupán a vas és a pbx verzió változott.

Gábor

FreePBX-et nem ismerem, Asterisket viszont kezdetektől használok.

Két mellék sem tudja egymást hívni!

Ha bármi gond van, én mindig azzal szoktam kezdeni, hogy Asterisk Console, a kellő verbozitással. Nagyjából a szomszédom apósa ükanyjának a DNS mintázatát is megtudom két másodperc múlva. És akkor még ott vannak a logok is.

( gabrielakos v | 2026. 02. 25., sze – 21:13 )

Ha látod a DIAL parancsot de nem cseng, RTP/NAT gond. Ha a dialplan el sem indul, contexting gond.

( E-Medve v | 2026. 02. 25., sze – 21:35 )

Egy ideje már nem foglalkozok voippal, de arra nézz már rá, hogy a trunk irányából milyen kodekkel esik be a hívás az IVR-ig és hogy az a kodek támogatott-e a kliensekben. Ugyanígy a régi rendszeren (ha még megvan) volt-e valami extra barkács a canreinvite vagy a directmedia beállításokkal és/vagy változott-e az alapértelmezett beállítás azóta.

Illetve ahogy már írták: Linux parancssorból asterisk -rvvv (nyilván ahány v, annyira verbose)

Ha nagyon nem boldogulsz az asterisk konzollal, akkor még a tcpdump is segíthet, a keletkezett dumpot szépen tudod analizálni Wiresharkban (Telephony -> SIP Flows).

+1 az Asterisk konzolra.

Illetve, amikor keresgélsz, akkor főleg Asterisk-re keress, ne specifikusan FreePBX-re. A FreePBX csak egy fancy webfelület, a lelke mélyén ez egy Asterisk.

Érdemes lehet átnézni a generált Asterisk konfigokat is (akár másold ki a gépről, és AI-val nézesd át), lehet hogy ott megy valami félre.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( Luckye | 2026. 02. 26., cs – 11:39 )

Sziasztok!

Köszönöm mindenkinek a hozzászólást.

Azt hiszem, van ötletem, mi van elrontva, de leghamarabb hétvégén tudom megnézni, ténylegesen ez a baj. Az ötletem, hogy a telefonokban van a port rosszul beállítva: míg a pjsip az 5060-at szereti, azt látom, hogy a használt telefonokon ennél nagyobb van beállítva. Ehhez hozzátenném, hogy a jelenlegi konfigurációban chan_sip típusúak a mellékek és ott be van állítva a megváltoztatott port... Hogy anno 22-ben ezt miért csináltam, azt már a fene tudja.

Ennek fényében érthető a működés: a mellék beregisztrál, mert a pbx-et az elvárt 5060-on szólítja meg, de a pbx már nem éri el a készüléket, mert az az 5060-ra nem válaszol....

Leghamarabb a jövő héten tudok reagálni, mindenképp megírom, hogy ez volt-e a probléma.

Gábor

Ui: Elnézést, én mindig keverem, hogy melyik az Asterisk és melyik a PBX... Igyekszem megjegyezni, hogy az Asterisk a központ és a PBX a felület.

míg a pjsip az 5060-at szereti,

Nem. Az 5060-as port  a SIP protokoll portja, csak régen a chan_sip,   most már a chan_pjsip használja. Régebbi freepbx ekben így a chan_sip átkerült a 5160 as portra. 

Jelenlegi asterisk meg már nem is támogatja a régi chan_sip protokollt.

Fedora 43, Thinkpad x280

Hát, ez érdekes adalék, de nincs szinkronban a beállításokkal, amit mondasz.

A régi rendszer, ami még chan_sipe-t használ, ezt írja a General fülön, bármelyik Extensiont is választom ki: "This device uses CHAN_SIP technology listening on Port 5060 (UDP)"
Eközben néhány melléknél az Advanced fülon a portra 5160 van beállítva.

Közben a telefonokon a Local SIP Port hol 5060, hol 5062, hol 5160. Csoda, hogy jelenleg működik a rendszer....

 

Tisztában vagyok a chan_sip megszűnésével, ezért lett az új gépen pjsip. A régin nincs is engedélyezve a pjsip.

( _ventura_ v | 2026. 02. 26., cs – 12:15 )

rossz helyre ment ...

Fedora 43, Thinkpad x280

( gabrielakos v | 2026. 02. 26., cs – 22:22 )

jól értem h az egyik telefonnal nem tudod felhívni a másikat?

( Luckye | 2026. 02. 27., p – 10:31 )

Apró előrelépés:

Az újonnan telepített gépet üzembe tudtam helyezni egy másik környezetben, (másik hálózat, másik kliens telefonok), itt korrektül működik az összes mellék.

Szóval úgy tűnik, a telefonok beállítási között kell keresnem a problémát.

Gábor

Én anno ezer éve tftp serverrel konfigoltam a telefonokat.
Egyszer csináltunk egy szállodát, kibontástól működésig nagyjából 1 perc volt per készülék.
Nyilván miután odáig automatizáltuk hogy a telefon mac adressét kellett csak vonalkód olvasóval beolvasni, melléket melléírni. 
 

( Luckye | 2026. 03. 01., v – 20:15 )

Na, sikerült. Megosztom, mert számomra tanulságos.
A problémát alapvetően az oldotta meg, hogy a készülékeket fizikailag újraindítottam.

A művelet során több dolog is kiderült:
- Hiába van a pbx-en a tűzfal kikapcsolva, az Intrusion Detection (ID) továbbra is működik. Ez becsapott, mert amikor a Connectivity -> Firewall menüpont alatt tiltom a tűzfalat, akkor eltünteti az ID fülét is. Mivel gyanús lett a dolog, megnéztem az Admin -> System Admin felületen az ID szekciót, látszottak a bannolt IP címek.
- Hiába volt az ID white list-je úgy beállítva, hogy 192.168.0.0/24 legyen engedélyezve, ennek ellenére bannolta többek között a 192.168.0.201-es címet is....
- A készülékek egy részénél elég volt az, hogy az admin felületükön kértem egy újraindítást, de voltak olyan készülékek, amiknél ez nem volt elég, kellett a fizikai áramtalanítás is. Ez csak a kaputelefon miatt volt nehezebb, mert ott mászhattam fel a plafon alatti rack szekrényhez....

Gábor

( debtamas88 | 2026. 03. 04., sze – 21:34 )

"tcpdump" helyett "sngrep" ha már SIP-t kell debuggolni :)