Потеря регистрации voip

[anonymous]

Добрый день!
Существует следущая проблема, примерно пару раз в день отваливается регистрация провайдера, в логах пишет следующее:

11:03:43.543 TLS connection failed ok=-1 err=5 error:00000005:lib(0):func(0)H lib

11:03:43.543 (SSL Error want syscall)
11:03:43.543 Error may be because trying ssl connection to tls server

11:03:43.543 Couldn't TLS connect
11:03:44.544 [CM504005]: Registration failed for: 10008@Avelakom; Cause: 503 Service Unavailable; warning: ; internal
11:03:44.544 [CM504007]: Next attempt to register 10008@Avelakom is scheduled in 10 minutes

При этом входящие вызовы на этот аккаунт приходят, исходящие не идут. Делаем обновление регистрации руками и все становиться нормально, регистрация проходит. Провайдер утверждает что с его стороны все хорошо. никаких падений и разрывов нет. Канал соединения при этом не падает, т.е. sip-сервер всегда доступен. Вопроса два:
1. Почему это происходит? в какую сторону копать?
2. МОжно ли изменить вот это: "Next attempt to register 10008@Avelakom is scheduled in 10 minutes"? В настройках voip операттора время перегистрации равно 100 секундам.

 

[anonymous]

Когда был зафиксирован первый инцидент?

Спасибо

 

[anonymous]

Примерно месяц назад. Причем это началось после того как 3сх переставили с WimXP на Win2k3. Искал по форумам, максимум что советовали это отключить авт.обновление на сервере и включить поддержку соединения в 3cx. Но это не помогло.

 

[anonymous]

PBX самовольно на TLS не переключается. С OS это тоже не связано.

Если будет желание поискать "курок", напишите после Нового Года, с наступлением которого я, пользуясь случаем, Вас поздравляю

 

[anonymous]

Да пробллему буду пытаться решать после НГ. Эмпирическим путем вот еще выяснил что перед падением почему не проходят rtp пакеты, т.е. появляется запись что не прошел ни один rtp-пакет на порт который прокинут и до этого стабильно работал. Ну это вссе после каникул!
Вас также с Новым Годом!

 

[anonymous]

Проблема остается. Примерно два раза в день теряется регистрация.
вот выдержки из логов:
I.
14:48:31.011|.StunClient.cpp(354)|Log2|STUN|StunClient:nInitTests:[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 96.9.132.83:3478 over Transport 192.168.1.11:5060
14:49:33.825|.Call.cpp(774)|Log2||Call::Terminate:[CM503008]: Call(3038): Call is terminated
14:49:33.840|.Call.cpp(774)|Log2||Call::Terminate:[CM503008]: Call(3038): Call is terminated
14:49:47.450|.CallCtrl.cpp(155)|Log2||CallCtrl:nIncomingCall:[CM503001]: Call(3040): Incoming call from Ext.40 to
14:49:47.450|.Extension.cpp(982)|Log3||Extension:rintEndpointInfo:[CM505001]: Ext.40: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [KIRK Wireless Server 6000 r24360] Transport: [sip:10.3.0.130:5060]
14:49:47.465|.CallCtrl.cpp(325)|Log3||CallCtrl:nSelectRouteReq:[CM503010]: Making route(s) to
14:49:47.465|.CallCtrl.cpp(434)|Log2||CallCtrl:nSelectRouteReq:[CM503004]: Call(3040): Route 1: Ext:Ext.75@[Dev:sip:[email protected]:5060]
14:49:47.465|.Target.cpp(407)|Log2||Target::makeOneInvite:[CM503024]: Call(3040): Calling Ext:Ext.75@[Dev:sip:[email protected]:5060]
14:49:47.559|.Extension.cpp(352)|Log2||ExtnCfg::updateContact:[CM504001]: Ext.23: new contact is registered. Contact(s): [sip:[email protected]:5060/23]
14:49:49.419|.CallLeg.cpp(227)|Log3||CallLeg:nAnswer:[CM503002]: Call(3040): Alerting sip:[email protected]:5060
14:49:49.434|.Extension.cpp(982)|Log3||Extension:rintEndpointInfo:[CM505001]: Ext.75: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [KIRK Wireless Server 6000 r24360] Transport: [sip:10.3.0.130:5060]
14:50:04.825|.Call.cpp(774)|Log2||Call::Terminate:[CM503008]: Call(3040): Call is terminated
14:50:20.872|.Registrar.cpp(456)|Log2|Registrar|ClientRegs:nFailure:[CM504005]: Registration failed for: 10008@Avelakom; Cause: 503 Service Unavailable; warning: ; internal
14:50:20.872|.Registrar.cpp(465)|Log2|Registrar|ClientRegs:nFailure:[CM504007]: Next attempt to register 10008@Avelakom is scheduled in 10 minutes
14:50:31.107|.StunClient.cpp(354)|Log2|STUN|StunClient:nInitTests:[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 96.9.132.83:3478 over Transport 192.168.1.11:5060

II.
20:04:44.956|.StunClient.cpp(354)|Log2|STUN|StunClient:nInitTests:[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 96.9.132.83:3478 over Transport 192.168.1.11:5060
20:05:02.034|.SLServer.cpp(832)|Error1|MediaServer|MediaServerReporting::RTPReceiver:[MS105000] C:3217.1: No RTP packets were received:remoteAddr=95.143.0.36:19748,extAddr=95.143.7.30:9002,localAddr=95.143.7.30:9002
20:05:30.425|.Registrar.cpp(456)|Log2|Registrar|ClientRegs:nFailure:[CM504005]: Registration failed for: 10008@Avelakom; Cause: 503 Service Unavailable; warning: ; internal
20:05:30.425|.Registrar.cpp(465)|Log2|Registrar|ClientRegs:nFailure:[CM504007]: Next attempt to register 10008@Avelakom is scheduled in 10 minutes
20:06:45.098|.VExtMgr.cpp(78)|Log2|DataBase|FaxCfg::updateContact:[CM504008]: Fax Service: registered as sip:[email protected]:5060 with contact sip:[email protected]:5100;user=phone
20:06:45.161|.StunClient.cpp(354)|Log2|STUN|StunClient:nInitTests:[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 96.9.132.83:3478 over Transport 192.168.1.11:5060
20:08:45.257|.StunClient.cpp(354)|Log2|STUN|StunClient:nInitTests:[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 96.9.132.83:3478 over Transport 192.168.1.11:5060

 

[anonymous]

Если не форсировать перерегистрацию, то через 10 мин она восстанавливается или нет?

P.S. Я Вам PM выслал с описанием того, как лучше собрать информацию о сложившейся ситуации.

 

[anonymous]

Да востанавливается. У меня настроено оповещение при падении регистрации, и как мне прилетает алерт, я руками обновляю регистрацию и она проходит. Инструкция есь, соберу логи и приложу сегодня вечером.

 

[anonymous]

Наблюдаю примерно такую же картину,
если исходящих звонков нет, то соединение отваливается примерно через 10 минут. и снаружи позвонить нельзя. Как только изнутри набирают номер, сразу можно звонить снаружи и звонок проходит.
Подскажите где копать?
Регистрация на сервере провайдера не требуется.

 

[anonymous]

@kaktus wrote:Наблюдаю примерно такую же картину,
если исходящих звонков нет, то соединение отваливается примерно через 10 минут. и снаружи позвонить нельзя. Как только изнутри набирают номер, сразу можно звонить снаружи и звонок проходит.
Подскажите где копать?
Регистрация на сервере провайдера не требуется.

На хост PBX ничего не приходит, или он в логе пишет о нежелании звонки принимать? (если первое, то смотрите настройки NAT/Firewall контролирующие условия получения входящего трафика)
А если снаружи звонки регулярно приходят (не реже чем раз в 10 мин) то тоже пропадает?

 

[anonymous]

Еще раз более детально протестировал и пришел вот к каким "условиям" работы:

- входящие звонки перестают приниматься ровно через 60 секунд после последнего звонка (любого внешнего или внутреннего, достаточно префикс линии набрать с внутреннего номера).

- в этот момент в логах сервера ничего нет кроме
11:25:46.250 Currently active calls [none]
11:25:14.248 Currently active calls [none]
11:24:44.246 Currently active calls [none]
11:24:12.244 Currently active calls [none]
11:23:40.243 Currently active calls [none]
11:23:10.241 Currently active calls [none]

- подключено 2 учетных записи внешних линий (SIP) достаточно поднять изнутри любую из 2-х линий и звонки будут поступать с обоих линий, но не дольше чем 60 секунд после последнего звонка.

 

[anonymous]

У Вас PBX пользуется STUN для получения внешнего адреса, или внешний адрес статически указан в конфигурации?
Такое поведение говорит о том, что на NAT порт открывает на приём только после того, как PBX что-то выслал, и закрывает его после 60-ти секунд отсутствия исходящего (от PBX) трафика.
Мне кажется, что там есть и такая ситуация.
Если звонок длится более 60 секунд, то PBX даже не получает извещение о том, что на удалённом конце прервали звонок, и он завершается только после того, как внутренний номер положит трубку. Я прав?

 

[anonymous]

1. Внешний адрес статически указан в конфигурации...
2. вы правы
Что делать?

 

[anonymous]

Отключил фаервол,.. тестирую... По результатам отпришусь.

 

[anonymous]

@kaktus wrote:Отключил фаервол,.. тестирую... По результатам отпришусь.
я бы не рекомендовал отключать файрвол. Лучше объяснить ему, чтобы он не блокировал входящий трафик от провайдеров.

 

[anonymous]

Уже восстановил фаервол и обучил его не реагировать на входящий трафик по нужным портам.
Огромное спасибо за нужные наводящие вопросы и ответы.

 

[anonymous]

К исходной проблеме данной темы:
Что предпринималось: удаление создание voip-провайдера, возврат на ХР, обновление драйверов и прочие мелочи типа настройки времени регистрации, пробование разных параметров и сочетаний. В итоге ничего не помогало, могло два дня не отваливаться регистрация, а потом 6 раз за день.

У провайдера случилась авария на одном из узле и мы стали испытывать переодические проблемы со слышимостью, нас слышали, мы плохо с пропаданиями. Совместно с провайдерами поменяли используемый кодек на G729, провайдер поменял несколько вариантов декодеривания.

В итоге со слышимостью все в порядке. И уже 10 дней ни одного падения регистрации...

 

[anonymous]

Спасибо за обновление информации.
Если честно, то очень странно, что использование G729 решает проблемы регистрации...
Неужели там были проблемы с перегрузкой линий подключения к интернету (шлюзов?)?

 

[anonymous]

С нашей стороны не было. постараюсь уточнить у провайдера. Если востанавливать хронологию то и проблемы начались вскоре после одной из аварий у провайдера, но тогда не было идеи о связаности событий т.к. это совпало с переходом на w2k3/

Касательно текущей ситуации. Одно изменение используемого кодека на g729 не помогло. После него продолжились проблемы со слышимостью и только изменения способа декодирования со стороны оборудования провайдера исправило.
На разных форумах 3сх я встречал записи о таких же проблемах но ни одного по сути решения. Если это может помочь могу запросить информацию что именно сделал провайдер и разместить.