Сломалась VOIB :(, отваливается связь до sip-сервера и телефонов LIP Опции

[vester]

Случилась беда. Ни с того, ни с сего, перестала работать плата VOIBN. Ничего в настройках АТС не менял в последнее время, сеть тоже не трогали. Но сейчас пропадает соединение между платой и sip-сервером, а также ip-телефонами. Сначала отключалось пару раз в день, помогала перезагрузка АТС, сейчас достаточно позвонить в город через sip-сервер (причём при дозвоне у трубке слышится скрежет, а уже потом длинный гудок ожидания; при поднятии трубки с той стороны не слышно голоса в обе стороны) - сервер и телефоны становятся недоступны. То же самое, если позвонить на номер снаружи. Перезагрузка АТС помогает, но ненадолго. Пробовал заливать более старую, 100%-но рабочую конфигурцию атски - не помогло, всё то же самое.
Сетевое оборудование проверил, всё работает нормально, ошибок на портах нет. Sip-сервер и VOIBN находятся в разных подсетях, работают через NAT. Телефоны находятся в одной подсети с платой.

В логах sip при звонке администратор не находит ничего страшного и необычного. Сделал тарссировку этого момента на атс:

CODE

005790 COL 009:05 01 St:co idle (00) Ev-I:enb sz req P1: 3 P2: 0 EVT: 25 <- 1,01
005790 D>05 01, C1 00 00
005892 COL 009:05 01 St:enblk p_sz(00) Ev-I:mem dial P1: 0 P2:10916B2 EVT:110 <- 1,01
005892 COL 009:05 01 St:enblk p_sz(00) Ev-I:enb sz snd P1: 0 P2: 0 EVT: 26 <- 9,44
[SIP-CMD] INVITE sip:2510589@tel.itax;user=phone
From:<sip:2904000@tel.itax>
To:<sip:2510589@tel.itax;user=phone>
Contact:sip:2904000@192.168.20.2:5060
005893 C>05 01, D5 81 09 16 3C 73 69 70 3A 32 39 30 34 30 30 30 40 74 65 6C 2E 69 74 61 78 3E 0A 21 3C 73 69 70 3A 32
35 31 30 35 38 39 40 74 65 6C 2E 69 74 61 78 3B 75 73 65 72 3D 70 68 6F 6E 65 3E 26 1F 73 69 70
3A 32 35 31 30 35 38 39 40 74 65 6C 2E 69 74 61 78 3B 75 73 65 72 3D 70 68 6F 6E 65 04 1D 73 69
70 3A 32 39 30 34 30 30 30 40 31 39 32 2E 31 36 38 2E 32 30 2E 32 3A 35 30 36 30 02 01 01 2C 01
01
--------------------============================================>>>>>>>>>>
(CO 9) SETUP
Analysis Control Msg Failed: 09 MSG Undeclared

005893 D>05 01, C1 00 00
005894 COL 009:05 01 St:wt sz rsp (00) EVT 8 24 28 03 34 30 37 04 1D 73 69 70 3A 32 39 30 34 30 30 30 40 31 39 32 2E 31 36 38 2E 32 30 2E 32 3A
35 30 36 30 (U0)
<<<<<<<<<<============================================--------------------
(CO 9) RESUME ACK
IE_DISPLAY
IE_BEARER_CAPABILITY

[SIP-EVT] SIP_CALLFAIL_RESP_MSG
IE_SIP_RESPONSE_CODE:407
IE_SIP_CONTACT:sip:2904000@192.168.20.2:5060
005895 COL 009:05 01 St:wt sz rsp (00) VOIP EVT: evt_no=D1 p1=00 p2=00
<<<<<<<<<<============================================--------------------
(CO 9) CALL PROCEEDING

[SIP-EVT] 100_TRYING
005895 COL 009:05 01 St:wt sz rsp (00) Ev-I:pp sz ack P1: 0 P2: 0 EVT: 16 <- 9,44
005895 D>05 01, C0 00 40
005897 COL 009:05 01 St:dialing (00) VOIP EVT: evt_no=D7 p1=00 p2=00
<<<<<<<<<<============================================--------------------
(CO 9) RESUME

[SIP-EVT] SIP_183_SESSION_PROGRESS
005897 D>05 01, C0 00 40
005897 COL 009:05 01 St:dialing (00) Ev-I:dummy acd P1:26D6 P2: 0 EVT: 0 <- 9,44
005897 COL 009:05 01 St:dialing (00) EVT A 03 29 01 11 (U0)
<<<<<<<<<<============================================--------------------
(CO 9) SUSPEND
IE_DATE_TIME

[SIP-EVT] SIP_SDP_CONTROL
IE_SIP_SDP_STATUS:11
<<<<<-----------------------------------
(CO 5) RING START

----------------------------------->>>>>
(CO 5) ANSWER

<<<<<-----------------------------------
(CO 5) SEIZE ACK

006074 COL 009:05 01 St:dialing (00) Ev-I:release P1: 0 P2: 0 EVT: 31 <- 1,01
006074 D>05 01, C5 00 00
006074 D>05 01, C1 00 40
[SIP-CMD] BYE
006074 D>05 01, DF 00 40
--------------------============================================>>>>>>>>>>
(CO 9) RELEASE

006114 COL 009:05 01 St:rls guard (00) Ev-T:rls ack P1: 0 P2: 0 TMR: 3 <- 9,44

АТС LDK-100, прошивка 3.9Ah, прошивка VOIBN - Gs30T11Ca. Настройки - ниже на скриншотах.
Может что-то по логам можно понять? Меня уже на этом форуме скоро ненавидеть будут

Прикрепленные файлы

 CropImage1.gif ( 31,45 килобайт ) Кол-во скачиваний: 26
 CropImage2.gif ( 16,97 килобайт ) Кол-во скачиваний: 23
 CropImage4.gif ( 12 килобайт ) Кол-во скачиваний: 23
 CropImage5.gif ( 24,25 килобайт ) Кол-во скачиваний: 23
 CropImage3.gif ( 22,06 килобайт ) Кол-во скачиваний: 23

 

[AXEL]

У вас очень странный адрес фаервола стоит. Так как сип сервер вроде на внешней сети, а фаервол какой то левый. Это действительно так и должно быть?

[vester]

sip-сервер тоже наш, стоит в той же серверной и имеет такую подсеть, тут всё правильно.

[AXEL]

тогда только смотреть Wireshark ом сниф вызова. Хотя настройки действительно странные немного.

[vester]

А какие настройки вызывают сомнение?

[AXEL]

DNS- белый, причем понимает сип прокси адрес в вашей локальной сети.
фаервол серый
если прокси сип сервер адрес находится в одной подсети с платой, то на фига вообще фаервол?

в общем, чего гадать, нужен сниф звонка

[vester]

DNS- белый, причем понимает сип прокси адрес в вашей локальной сети.
фаервол серый
если прокси сип сервер адрес находится в одной подсети с платой, то на фига вообще фаервол?

в общем, чего гадать, нужен сниф звонка

DNS-сервер, sip-сервер - всё это наше (мы - интернет-провайдер), поэтому DNS понимает наши внутренние адреса. Сейчас АТС и sip-сервер находятся в разных подсетях, поэтому и указывается ip файервола...

Проблему так и не решил, плата ведёт себя так же странно.. Бывает, с утра ещё один звонок нормально проходит, последующий же вешает плату намертво, до следующей перезагрузки атс.

На выходных пробовал полностью сбросить конфигурацию атс и запрограммировать заново, перепрошил плату voibn по-новой, заносил атс в одну сетку с sip-сервером - эффекта ноль

Сделал сниф глючного звонка, файл прилагается...
192.168.20.2 - плата voibn
10.255.0.255 - sip-сервер
10.255.0.251 - внешняя АТС
192.168.20.3-5 - телефоны LIP

Прикрепленные файлы

 wireshark.zip ( 181,03 килобайт ) Кол-во скачиваний: 8

 

[vldmr]

Попробуйте убрать firewall ip из 340 программы и рестартануть


Похоже в сети есть маршрутизация и без NAT

[vester]

Попробуйте убрать firewall ip из 340 программы и рестартануть


Походе в сети есть маршрутизация и без NAT

Этот вариант я проверил, эффекта никакого...

[noox]

.....
192.168.20.2 - плата voibn
10.255.0.255 - sip-сервер
10.255.0.251 - внешняя АТС
192.168.20.3-5 - телефоны LIP

Как может быть такое, что сеть сип-сервера имеет адрес 10.255.0.х, сеть с платой voip имеет адрес 192.168.20.х, а мост (шлюз) между этими сетями имеет адрес 10.255.1.х? Какая-то дикая маршрутизация. Зачем для dns сервера используется внешний интерфейс? Если он ваш и вы провайдер, наверняка он имеет какой-нибудь внутренний интерфейс типа 10.х.х.х? Или же dns сервер находится во внешней сети и совсем не пересекается с этими сетями? Получается ситуация, что dns-запрос на перевод sips.tel.itax в ip-адрес должен быть отправлен в интернет, хотя вроде "все располагается здесь, под боком в локалке".
Посмотрите вместе с сисадмином правильные сетевые настройки для станции.

[noox]

Я имел в виду, что на скринах у вас адрес фаервола 10.255.1.0. Может все таки здесь ошибка и адрес должен быть 10.255.0.1, судя по вашей сети в которой находится sip-сервер?

[vester]

нет, ошибки никакой нет.
DNS у нас так и есть только с внешним интерфейсом, маршрутизация до него есть со всех серых сетей. Сеть 192.168.20.хх натится 1-в-1 в 10.255.1.0 (в обе стороны). Сеть 10.255.1.хх для конечного телефонного оборудования (УАТС, VOIP-шлюзы и т.п.), сеть 10.255.0.хх - для sip-сервера и городской АТС, маршрутизация между этими сетями есть (остальные-то клиенты работают).

[noox]

нет, ошибки никакой нет.
DNS у нас так и есть только с внешним интерфейсом, маршрутизация до него есть со всех серых сетей. Сеть 192.168.20.хх натится 1-в-1 в 10.255.1.0 (в обе стороны). Сеть 10.255.1.хх для конечного телефонного оборудования (УАТС, VOIP-шлюзы и т.п.), сеть 10.255.0.хх - для sip-сервера и городской АТС, маршрутизация между этими сетями есть (остальные-то клиенты работают).

Получается данные идут по такой цепочке: 192.168.20.хх -> 10.255.1.xx -> 10.255.0.xx? А напрямую нельзя? Зачем нам в 10.255.1.хх, там ничего интересного для атс нет
Другие клиенты работают из этой же сети 192.168.20.хх?
Если вообще не подключаться к сип-серверу, то ip-телефоны "живут" и работают сколь угодно долго?

[vester]

Напрямую нельзя.

192.168.20.хх - это сеть для voib и для ip-телефонов. Если voib назначить сразу адрес 10.255.1.0, придётся либо загонять ip-телефоны в эту сеть, либо маршрутизировать из другой, но итог один - весь голосовой трафик с телефонов будет проходить через роутер, что не есть гуд. Поэтому была выделена отдельная подсеть для платы и телефонов, трафик в которой не затрагивает роутер. А сама плата через нат смотрит в сеть 10.255.1.0.

Клиенты сидят в сети 10.255.1.хх и sip-сервер настроен на работу с этой сетью.
Если не обращаться к sip-серверу звонками с АТС, ip-телефоны действительно работают без проблем сколько угодно времени.

[noox]

Напрямую нельзя.

192.168.20.хх - это сеть для voib и для ip-телефонов. Если voib назначить сразу адрес 10.255.1.0, придётся либо загонять ip-телефоны в эту сеть, либо маршрутизировать из другой, но итог один - весь голосовой трафик с телефонов будет проходить через роутер, что не есть гуд. Поэтому была выделена отдельная подсеть для платы и телефонов, трафик в которой не затрагивает роутер. А сама плата через нат смотрит в сеть 10.255.1.0.

Клиенты сидят в сети 10.255.1.хх и sip-сервер настроен на работу с этой сетью.
Если не обращаться к sip-серверу звонками с АТС, ip-телефоны действительно работают без проблем сколько угодно времени.

Ну вот вы сами ответили на все ваши вопросы. Вывод то какой? Нелады с маршрутизацией до сип-сервера. А VPN -туннель нельзя организовать между 192.168.20.хх и 10.255.0.хх?

[noox]

UDP-порты пробросили 192.168.20.хх <-> 10.255.1.хх?

[vester]

Вчера методом жёсткого научного тыка локализовал проблему. Глюки платы не зависят от структуры сети, глюк происходит, когда вызов идёт по первой линии CO (у меня логическая CO9, первые восемь - аналоговые). Неважно, входящий или исходящий вызов.
Просмотрел настройки всех линий - все одинаковые... Пока исключил из исходящих эту линию, благо, их хватает. Как её же можно исключить из входящих, сейчас при свободных линиях первый звонок проходит по CO9.

Ну и ещё один вопросик - кто-нибудь с таким глюком сталкивался?

[noox]

Вчера методом жёсткого научного тыка локализовал проблему. Глюки платы не зависят от структуры сети, глюк происходит, когда вызов идёт по первой линии CO (у меня логическая CO9, первые восемь - аналоговые). Неважно, входящий или исходящий вызов.
Просмотрел настройки всех линий - все одинаковые... Пока исключил из исходящих эту линию, благо, их хватает. Как её же можно исключить из входящих, сейчас при свободных линиях первый звонок проходит по CO9.

Ну и ещё один вопросик - кто-нибудь с таким глюком сталкивался?

Чтобы исключить из входящих необходимо знать как сейчас реализовано, у вас помнится были проблемы с настройкой входящих и звонок валился на оператора. Наверное, можно просто поменять тип линии и включить ее в неиспользуемую группу.
Такой ситуации с платой не было никогда, но на внешних аппаратных шлюзах - было, сгорали отдельные порты. Но в этой ситуации, порт обычно просто молчит и не подвешивает сеть.

[vester]

Входящие у меня реализованы через программу 231, попробовал исключить линию из группы и поменять ей тип на Normal - эффекта пока ноль..

[noox]

Входящие у меня реализованы через программу 231, попробовал исключить линию из группы и поменять ей тип на Normal - эффекта пока ноль..

ПГМ202 CO start CO end у вас там что?

[vester]

ПГМ202 CO start CO end у вас там что?

Index2: CO Start 10 CO End 10 MSN Number 0

[noox]

Index2: CO Start 10 CO End 10 MSN Number 0

Не понял, вам провайдер 0 присылает?
А DID индекс какой указан?
Что в ПГМ143 ПК4 и ПК5 для линий sip?

[harris]

ПГМ202 CO start CO end у вас там что?

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

Если проблемы начинаются после осуществления вызова по данному каналу, то, вероятно, проблема с "железом" (DSP), и, ИМХО, нужно просто менять плату VOIBE или попытаться отремонтировать ее в сервис-центре.

[noox]

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

Ну раз вы так говорите, значит проверено. Как я уже написал, что с такой ситуацией не сталкивался. Пробовал помочь. Это проблема в софте станции, платы?

[vester]

Не понял, вам провайдер 0 присылает?
А DID индекс какой указан?
Что в ПГМ143 ПК4 и ПК5 для линий sip?

в ПГМ202 я ничего и не прописывал... Я думал, в связи с тем, что ПГМ143 ПК4 установлено значение 2, входящими управляет только ПГМ231.
ПГМ143 ПК5 - 0..

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

Если проблемы начинаются после осуществления вызова по данному каналу, то, вероятно, проблема с "железом" (DSP), и, ИМХО, нужно просто менять плату VOIBE или попытаться отремонтировать ее в сервис-центре.

Спасибо за ответ, harris. Печально Перспектива остаться совсем без платы на время замены или ремонта не радует нисколько ip-телефоны вовсю используются...

[noox]

в ПГМ202 я ничего и не прописывал... Я думал, в связи с тем, что ПГМ143 ПК4 установлено значение 2, входящими управляет только ПГМ231.
ПГМ143 ПК5 - 0..

Можно было бы по-разному настроить. Но увы...

[harris]

Ну раз вы так говорите, значит проверено. Как я уже написал, что с такой ситуацией не сталкивался. Пробовал помочь. Это проблема в софте станции, платы?

Нет, не в софте, а в "железе". Мы пока что только предполагаем, что вышла из строя микросхема DSP.
Было бы неплохо, если Вы могли заменить VOIBE и проверить рабоспособность с другой платой. Если все будет нормально, то тогда однозначно будет ясно, что сама плата VOIBE неисправна.
Трудно сказать, в чем именно дело. По-моему таких аналогичных случев не было.

[noox]

Нет, не в софте, а в "железе". Мы пока что только предполагаем, что вышла из строя микросхема DSP.
Было бы неплохо, если Вы могли заменить VOIBE и проверить рабоспособность с другой платой. Если все будет нормально, то тогда однозначно будет ясно, что сама плата VOIBE неисправна.
Трудно сказать, в чем именно дело. По-моему таких аналогичных случев не было.

Изначально ув. vester отмечал какие-то глюки в работе платы. Просто странно, если это DSP почему остальные каналы кроме первого работают?

[harris]

Изначально ув. vester отмечал какие-то глюки в работе платы. Просто странно, если это DSP почему остальные каналы кроме первого работают?

Возможно потому, что у каждого канала свой DSP, но все DSP объединены в одной микросхеме.

[vldmr]

Может удасться заблокировать неисправную линию для входящих по H323 переведя ее в 322 программе в отдельную группу и сделать ее тип SIP
Соответственно перевести VOIB в режим DUAL

[harris]

Может удасться заблокировать неисправную линию для входящих по H323 переведя ее в 322 программе в отдельную группу и сделать ее тип SIP
Соответственно перевести VOIB в режим DUAL

О, вот вариант может быть пройдет.

[vester]

Может удасться заблокировать неисправную линию для входящих по H323 переведя ее в 322 программе в отдельную группу и сделать ее тип SIP
Соответственно перевести VOIB в режим DUAL

не совсем понял, у меня ведь изначально протокол SIP стоит, а не H323. Перевёл линию в отдельную Net CO Group, это не помогло.

[noox]

Может удасться заблокировать неисправную линию для входящих по H323 переведя ее в 322 программе в отдельную группу и сделать ее тип SIP
Соответственно перевести VOIB в режим DUAL

Эта линия уже имеет тип sip, и проблемы с ней возникают как раз при входящем/исходящем звонке по протоколу sip. Можно в принципе поставить H323, но тогда, возможно, заглючат ip-телефоны (хотя у них должен быть свой протокол). Вроде решили, что вывести ее из обслуживания не получится.
P.S. Упс.. sorry, уже написали об этом.

[harris]

Эта линия уже имеет тип sip, и проблемы с ней возникают как раз при входящем/исходящем звонке по протоколу sip. Можно в принципе поставить H323, но тогда, возможно, заглючат ip-телефоны (хотя у них должен быть свой протокол). Вроде решили, что вывести ее из обслуживания не получится.
P.S. Упс.. sorry, уже написали об этом.

Под IP-телефоны отдельно выделяются каналы - в ПГМ380.

[noox]

Под IP-телефоны отдельно выделяются каналы - в ПГМ380.

Ну да, и что, разве можно жестко установить какие каналы (номера) будут использоваться на плате для ip-телефонов? Как "оставить без внимания" глючный канал?

[noox]

To vester
Кстати, что у вас стоит в voip mode пгм322 и пгм340?

[vester]

To vester
Кстати, что у вас стоит в voip mode пгм322 и пгм340?

сейчас в обеих местах SIP, раньше в PGM340 стояло Dual..

[noox]

сейчас в обеих местах SIP, раньше в PGM340 стояло Dual..

Поставьте первую линию для платы voip в ПГМ322 тип H323, а в ПГМ340 оставьте dual.

[vester]

Поставьте первую линию в ПГМ322 в H323, а в340 оставьте dual.

вот-вот, только что попробовал в H323 поставить и в PGM340 Dual выставить - первая линия исключилась из входящих звонков.. Завтра ещё попробую поменять местами платы LCO и VOIB в атс, вдруг глюк пропадёт... Попытка - не пытка..
Спасибо всем за помощь и подсказки!

[noox]

вот-вот, только что попробовал в H323 поставить и в PGM340 Dual выставить - первая линия исключилась из входящих звонков.. Завтра ещё попробую поменять местами платы LCO и VOIB в атс, вдруг глюк пропадёт... Попытка - не пытка..
Спасибо всем за помощь и подсказки!

А на выход по sip уже настроили и все нормально?

[vester]

А на выход по sip уже настроили и все нормально, да?

на выход проще - я из CO исключил эту линию, и, к тому же, выбор линии автоматически происходит с последней, а у нас не такая нагрузка, чтобы все сразу были заняты

[harris]

Ну да, и что, разве можно жестко установить какие каналы (номера) будут использоваться на плате для ip-телефонов? Как "оставить без внимания" глючный канал?

Нет.
Но я имел в виду другое. "Глючный" канал уже приписан к каналам, обслуживающим транк (СО), а не к каналам, обслуживающим IP-телефоны. Так что попытки поменять тип транкового канала (SIP/H.323) не повлияет на работу IP-телефонов.

[noox]

Нет.
Но я имел в виду другое. "Глючный" канал уже приписан к каналам, обслуживающим транк (СО), а не к каналам, обслуживающим IP-телефоны. Так что попытки поменять тип транкового канала (SIP/H.323) не повлияет на работу IP-телефонов.

Ну и отлично. Это и нужно в данной ситуации.

To vester
А в Networking Co line type в ПГМ322 для линий voip у вас что указано?

[vester]

Ну и отлично. Это и нужно в данной ситуации.

To vester
А в Networking Co line type в ПГМ322 для линий voip у вас что указано?

PSTN

Попробовал поменять местами платы - без изменений. Видимо, действительно, надо отдавать плату в ремонт.