Konfiguracja FreePBX - odpowiedzi na najczęściej zadawane pytania
W tym miejscu chcemy umieszczać odpowiedzi na najczęściej zadawane przez Was pytania dotyczące FreePBX. Zachęcamy do komentowania i zadawania pytań pod tym artykułem a nasi inżynierowie będą aktualizować odpowiedzi tak często, jak to tylko możliwe. Jeżeli nie znajdziecie tu tego co Was interesuje zapraszamy do kontaktu z naszym biurem obsługi klienta pod numerem 122 100 900
Jesteśmy dostawcą hostingu FreePBX! Jeżeli chcesz mieć własną centralę FreePBX w chmurze tu znajdziesz coś interesującego
Przychodzące połączenia telefoniczne zrywają się po kilkudziesięciu sekundach od wybrania numeru, nic nie słychać w słuchawce, po okresie pół minuty połączenie jest kończone
To jeden z najczęściej spotykanych problemów zgłaszany przez naszych klientów podczas uruchamiania nowej centrali telefonicznej. Podczas konfiguracji FreePBX należy pamiętać o bardzo dużej ilości czynników, które mogą wpływać na możliwość komunikowania się centrali ze światem zewnętrznym.
Przeanalizujmy zatem jaki problem występuje podczas wykonywania połączenia przychodzącego:
Logujemy się do FreePBX przez SSH i wpisujemy komendę asterisk -rvvvv:
root@localhost> asterisk -rvvvv
W tym momencie uzyskujemy podgląd wszystkiego co dzieje się na naszej centrali podczas połączenia przychodzącego. W poniższym przykładzie połączenie powinno zostać skierowane do IVR, ale gdy dzwonimy słychać tylko ciszę, a po 30 sekundach połączenie jest przerwane. Jak to wygląda w końcowej części logu
localhost*CLI>
-- Executing [s@macro-dial:8] Set("SIP/voip-operator-inbound-0000008a", "DIALSTATUS=NOANSWER") in new stack
-- Executing [s@macro-dial:9] GosubIf("SIP/voip-operator-inbound-0000008a", "0?NOANSWER,1") in new stack
-- Executing [600@ext-group:12] Gosub("SIP/voip-operator-inbound-0000008a", "sub-record-cancel,s,1()") in new stack
-- Executing [s@sub-record-cancel:1] Return("SIP/voip-operator-inbound-0000008a", "") in new stack
-- Executing [600@ext-group:13] Set("SIP/voip-operator-inbound-0000008a", "SIP/voip-operator-inbound-0000008a", "0?nodest") in new stack
-- Executing [600@ext-group:15] Set("SIP/voip-operator-inbound-0000008a", "SIP/voip-operator-inbound-0000008a", "blkvm-clr,") in new stack
-- Executing [s@macro-blkvm-clr:1] Set("SIP/voip-operator-inbound-0000008a", "SHARED(BLKVM,SIP/voip-operator-inbound-0000008a)=") in new stack
-- Executing [s@macro-blkvm-clr:2] Set("SIP/voip-operator-inbound-0000008a", "SIP/voip-operator-inbound-0000008a", "") in new stack
-- Executing [600@ext-group:17] Goto("SIP/voip-operator-inbound-0000008a", "ivr-2,s,1") in new stack
-- Goto (ivr-2,s,1)
-- Executing [s@ivr-2:1] Set("SIP/voip-operator-inbound-0000008a", "_IVR_CONTEXT_ivr-SIP/voip-operator-inbound-0000008a", "_IVR_CONTEXT=ivr-2") in new stack
-- Executing [s@ivr-2:3] Set("SIP/voip-operator-inbound-0000008a", "SIP/voip-operator-inbound-0000008a", "0?skip") in new stack
-- Executing [s@ivr-2:5] Answer("SIP/voip-operator-inbound-0000008a", "") in new stack
-- Executing [s@ivr-2:6] Wait("SIP/voip-operator-inbound-0000008a", "1") in new stack
-- Executing [s@ivr-2:7] Set("SIP/voip-operator-inbound-0000008a", "IVR_MSG=custom/NewIVR") in new stack
-- Executing [s@ivr-2:8] Set("SIP/voip-operator-inbound-0000008a", "TIMEOUT(digit)=3") in new stack
-- Digit timeout set to 3.000
-- Executing [s@ivr-2:9] ExecIf("SIP/voip-operator-inbound-0000008a", "1?Background(custom/NewIVR)") in new stack
-- <SIP/voip-operator-inbound-0000008a> Playing 'custom/NewIVR.slin' (language 'en')
-- Executing [s@ivr-2:10] WaitExten("SIP/voip-operator-inbound-0000008a", "15,") in new stack
[2020-06-25 12:01:24] NOTICE[1911]: chan_sip.c:29115 check_rtp_timeout: Disconnecting call ‘SIP/voip-operator-inbound-0000008a’ for lack of RTP activity in 31 seconds
== Spawn extension (ivr-2, s, 10) exited non-zero on ‘SIP/voip-operator-inbound-0000008a’
– Executing [h@ivr-2:1] Hangup(“SIP/voip-operator-inbound-0000008a”, “”) in new stack
== Spawn extension (ivr-2, h, 1) exited non-zero on 'SIP/voip-operator-inbound-0000008a’
localhost*CLI>
Zwróćmy szczególną uwagę na końcowy fragment dziennika zdarzeń, gdzie podana jest przyczyna rozłączenia rozmowy:
"Disconnecting call ‘SIP/voip-operator-inbound-0000008a’ for lack of RTP activity in 31 seconds"
Na tej podstawie wiemy, że problem związany jest z niemożliwością skierowania strumienia RTP do centrali. Najczęstszym powodem takiej sytuacji jest problem z NAT
Należy sprawdzić, czy adres publiczny jest dostępny z Internetu lub czy adres domenowy jest poprawnie rozwiązywany
Należy dodać informację dotyczącą NAT w GUI FreePBX w zakładce Settings - Asterisk SIP Settings:
Należy zwrócić również uwagę na zakres portów na których następuje przesyłanie RTP
Jeżeli używamy sterownika chan_sip sprawdzamy również zakładkę SIP Legacy settings
Jeżeli to nie usunie problemu, należy sprawdzić ustawienia naszego routera, ponieważ to on kieruje pakiety do centrali i należy przeanalizować dlaczego nie następuje kierowanie RTP do FreePBX.
Na problemy komunikacyjne mogą wpływać ustawienia zabezpieczeń - firewall, może być to również działanie mechanizmów ALG (Application Layer Gateway).
W założeniu SIP ALG ma na celu pomóc użytkownikom central i telefonów VoIP znajdujących się za NAT i wykorzystujących adresy z zakresów prywatnych:
192.168. 0.0/16: 192.168. 0.0 – 192.168. 255.255.
10.0. 0.0/8: 10.0. 0.0 – 10.255. 255.255.
172.16. 0.0/12: 172.16. 0.0 – 172.31. 255.255.
Niestety bardzo często, szczególnie w routerach konsumenckich, implementacja ALG nie jest zbyt dobra i modyfikacje pakietów, które są wykonywane przez router robią więcej szkody niż pożytku, uszkadzając je lub powodując że nie mogą zostać prawidłowo odczytane. Powoduje to niezgodne z oczekiwaniami zachowania centrali FreePBX lub telefonów VoIP. W przypadku problemów z połączeniami przychodzącymi zdecydowanie zalecamy wyłączenie ALG.
Przykłady problemów:
Połączenia przychodzące nie dochodzą do skutku z powodu modyfikacji żądania REGISTER. Centrala po włączeniu lub po uruchomieniu usługi SIP Trunk do operatora telekomunikacyjnego wysyła żądanie REGISTER, ale mechanizm ALG modyfikuje to żądanie podmieniając adres prywatny serwera freePBX na adres proxy i w rezultacie komunikacja zostaje zaburzona.
Połączenia przychodzące nie dochodzą do skutku ponieważ ALG nieprawidłowo modyfikuje nagłówki SIP lub treść SDP co powoduje przerwanie komunikacji pomiędzy serwerem FreePBX a serwerem operatora telekomunikacyjnego. Niektóre ALG podmieniają wszystkie adresy prywatne na adresy w komunikacji SIP co prowadzi do tego, że operator adresuje odpowiedzi do routera zamiast do centrali i komunikacja z oczywistych względów zamiera. Zdarzają się błędy w postaci zapisywania nieprawidłowych wartości portów lub pominięcie średnika w parametrach nagłówka.
W przypadku wykorzystania innego rozwiązania niwelującego problemy z NAT np. SIP Proxy, jeżeli nie wyłączymy ALG to router będzie podmieniał adres serwera SIP Proxy na swój własny adres publiczny i rozmowy telefoniczne nie będą realizowane.
NIE ZNALAZŁEŚ ODPOWIEDZI NA NURTUJĄCE CIĘ PYTANIE? ZADAJ JE W KOMENTARZU PONIŻEJ
