asterisk.ru

Имеется телефон GXP1628, прошит последней прошивкой (1.0.2.27). Настройки по-дефолту: Register Expiration = 60, Reregister before Expiration = 0, SIP Registration Failure Retry Wait Time = 20. Телефон подключен к Астериск 13 по одноранговой локальной сети через свитч (на астериск 11 была та же фигня). После включения телефона всё ок, регистрация на месте. Через некоторое время (через полчаса или несколько часов) телефон перестаёт звонить при входящем звонке (хотя звонок можно перехватить и говорить). Смотрим в астериск, видим:
CLI> sip show peers
660/660 (Unspecified) D Auto (No) No 0 UNKNOWN
Всё понятно - регистрация отвалилась.
Смотрим в телефон - Status -> SIP Registration = YES. То-есть, телефон думает, что он зарегистрирован. Через некоторое время (полчаса-час) регистрация может самопроизвольно восстановиться. Также можно перезагрузить телефон - регистрация сразу появляется. Что за лажа, не пойму. При чём проблем со связью нету: разговоры происходят без перебоев. Была такая же проблема на телефонах GXP1625, но решилась тупым отключением регистрации и установкой static-подключения. В случае с GXP1628 так сделать нельзя, потому что без регистрации не работает BLF.
С настройками "Reregister before Expiration", "Enable OPTIONS Keep Alive" игрался, уменьшал "Register Expiration" - всё бестолку.
Никто не сталкивался?
Как отловить события потери регистрации?
Какие волшебные настройки могут помочь?

Register Expiration = 60 - 60 минут - скрутите до 2

Htwor
Проблема не совсем такая, однако очень похожа... В наличии GXP1450 стоящий за микротиком, который впном подключён к основному шлюзу конторы (выделенная точка с сотрудником). Так вот у сотрудника работает подключение к файлопомойке конторы и прочим сетевым ресурсам. Телефон имеет статический адрес (сеть такая же как у ПК и прочих устройств этого сегмента сети). Через некоторое время телефон теряет регистрацию: АТС его не видит (сообщение как у вас), телефон пишет что регистрации нет. Любопытно что от него на АТС ровным счётом ничего, т.е ни одного пакета. Но какова методика лечения! Мы берём и меняем адрес телефона. Меняем буквально на одну цифру, т.е 192.168.1.120 на 192.168.1.121 И всё, телефон начинает работать.
Пока не увидели чёткой связи, но вероятнее всего такое происходит при пропадании света в удалённой точке. Далее всё автоматом подключается, но с телефоном всё не просто. Куда копать непонятно, но грешу на микротик. Одмин конечно же отмахиваеся: мол всё остальное то работает...

Что за лажа, не пойму.

Может прошивка спасёт его? Мы наш также не шили ещё.

на микротике выключить sip alg
так же тут несколько раз выкладывали скрипт сброса зависших сессий на микротике

Obi Van писал(а):В наличии GXP1450 стоящий за микротиком, который впном подключён к основному шлюзу конторы

Подтверждаю наличие проблемы.
SIP ALG тут никаким боком.
При падении VPN телефон пытается уйти на сервер через NAT и этот коннект "застревая" более никуда не пускает айпишник телефона по нормальному.

Мой текущий пример

192.168.50.х - локалка с телефонами
192.168.250.100 - астериск, находящийся в другом месте.
Обе локации связаны туннелем на микротиках.

http://forum.mikrotik.com/viewtopic.php?p=519220 - как раз сегодня задавал вопросы микротиковцам по поводу команды которой можно было бы сносить такие неправильные коннекты

P.S. Что-то в последний год в микротиках все больше и больше глюков...

awsswa писал(а):на микротике выключить sip alg
так же тут несколько раз выкладывали скрипт сброса зависших сессий на микротике

Кстати взаимоисключающие рекомендации
В скрипте который тут пробегал удаляются коннекты типа SIP.
А этот признак им как раз активный ALG приклеивает.

Obi Van писал(а):вероятнее всего такое происходит при пропадании света в удалённой точке.

Возможно маршрутизация дает сбой. Попробуйте в момент очередного инцидента пинговать телефон со стороны АТС (или любого другого пира, который находится в одной сети с АТС). Когда-то это помогало восстановить связь с удаленным компьютером через впн после разрыва последнего.

Удаляются просто по совпадению порта 5060
Мне с нестандартным портом пришлось править на 5080

Всю жизнь считал что SIP ALG нечего кроме вмешивания в пакеты SIP и тупой подмены локального адреса клиента на адрес WAN нечего не делает

Меня на микротиках подводили только криво настроенные PPTP и OpenVPN
когда маршрут прописывают ручками в настройках маршрутизации - вместо того чтобы он поднялся автоматом после коннекта клиента

awsswa писал(а):Меня на микротиках подводили только криво настроенные PPTP и OpenVPN
когда маршрут прописывают ручками в настройках маршрутизации - вместо того чтобы он поднялся автоматом после коннекта клиента

Чтобы маршрут подымался автоматом надо:
- со стороны VPN-сервера создать Server Binding под каждого конкретного VPN юзера
- в Policy поставить "Only one" в позицию Yes чтобы под одним логином только один коннект одновременно мог быть (иначе при повторном логине клиент может мимо своего биндинга пролететь)
- прописать маршрут на соотвествующий Server Binding (который виден в виде интерфейса и на который можно в качестве Destination в маршрутах применять)

Отловил в логах события, связанные с таймаутом регистрации. Но они мне ничем не помогли, разве что теперь я знаю, что потеря регистрации связана с каким-то таймаутом (пока не понятно каким). При чём специально провел эксперимент: запустил софтфон с регистрацией. За два часа GXP1628 отваливался дважды, а софтфон - ниразу. Заподозрил отсутсвие фактической регистрации в момент рестарта телефона (т.к. старая регистрация ещё действует), поставил галку "Unregister on Reboot = All". Ноль по фазе. Что за хрень, ума не приложу. Беплатный софтфон с настройками по-умолчанию регистрацию держит, а телефон за $85 отваливается.
Вот логи в момент потери регистрации:

[Feb 2 20:31:39] VERBOSE[100731] chan_sip.c: set_destination: Parsing <sip:660@10.1.1.160:5060> for address/port to send to
[Feb 2 20:31:39] VERBOSE[100731] chan_sip.c: set_destination: set destination to 10.1.1.160:5060
[Feb 2 20:31:39] VERBOSE[100731] chan_sip.c: Reliably Transmitting (no NAT) to 10.1.1.160:5060:
NOTIFY sip:660@10.1.1.160:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.120:5060;branch=z9hG4bK75b7fbfe;rport
Max-Forwards: 70
From: <sip:661@10.1.1.120>;tag=as654ea89b
To: <sip:660@10.1.1.120>;tag=113628648
Contact: <sip:661@10.1.1.120:5060>
Call-ID: 1554482010-5060-2@BA.B.B.BGA
CSeq: 105 NOTIFY
User-Agent: Asterisk PBX 13.6.0
Subscription-State: terminated;reason=timeout
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 201

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="full" entity="sip:661@10.1.1.120">
<dialog id="661">
<state>terminated</state>
</dialog>
</dialog-info>

---
[Feb 2 20:31:39] VERBOSE[100731] chan_sip.c:
<--- SIP read from UDP:10.1.1.160:5060 --->
SIP/2.0 481 Subscription Does Not Exist
Via: SIP/2.0/UDP 10.1.1.120:5060;branch=z9hG4bK75b7fbfe;rport=5060
From: <sip:661@10.1.1.120>;tag=as654ea89b
To: <sip:660@10.1.1.120>;tag=113628648
Call-ID: 1554482010-5060-2@BA.B.B.BGA
CSeq: 105 NOTIFY
Supported: replaces, path, timer
User-Agent: Grandstream GXP1628 1.0.2.27
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
[Feb 2 20:31:39] VERBOSE[100731] chan_sip.c: --- (10 headers 0 lines) ---
[Feb 2 20:31:39] VERBOSE[100731] chan_sip.c: Really destroying SIP dialog '1554482010-5060-2@BA.B.B.BGA' Method: SUBSCRIBE
[Feb 2 20:31:40] VERBOSE[100731] chan_sip.c: set_destination: Parsing <sip:660@10.1.1.160:5060> for address/port to send to
[Feb 2 20:31:40] VERBOSE[100731] chan_sip.c: set_destination: set destination to 10.1.1.160:5060
[Feb 2 20:31:40] VERBOSE[100731] chan_sip.c: Reliably Transmitting (no NAT) to 10.1.1.160:5060:
NOTIFY sip:660@10.1.1.160:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.120:5060;branch=z9hG4bK79bbd13f;rport
Max-Forwards: 70
From: <sip:662@10.1.1.120>;tag=as51a35485
To: <sip:660@10.1.1.120>;tag=298925962
Contact: <sip:662@10.1.1.120:5060>
Call-ID: 538233515-5060-3@BA.B.B.BGA
CSeq: 105 NOTIFY
User-Agent: Asterisk PBX 13.6.0
Subscription-State: terminated;reason=timeout
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 201

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="full" entity="sip:662@10.1.1.120">
<dialog id="662">
<state>terminated</state>
</dialog>
</dialog-info>

---
[Feb 2 20:31:40] VERBOSE[100731] chan_sip.c:
<--- SIP read from UDP:10.1.1.160:5060 --->
SIP/2.0 481 Subscription Does Not Exist
Via: SIP/2.0/UDP 10.1.1.120:5060;branch=z9hG4bK79bbd13f;rport=5060
From: <sip:662@10.1.1.120>;tag=as51a35485
To: <sip:660@10.1.1.120>;tag=298925962
Call-ID: 538233515-5060-3@BA.B.B.BGA
CSeq: 105 NOTIFY
Supported: replaces, path, timer
User-Agent: Grandstream GXP1628 1.0.2.27
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0
<------------->
[Feb 2 20:31:40] VERBOSE[100731] chan_sip.c: --- (10 headers 0 lines) ---
[Feb 2 20:31:40] VERBOSE[100731] chan_sip.c: Really destroying SIP dialog '538233515-5060-3@BA.B.B.BGA' Method: SUBSCRIBE