Прописывание Firewall-а не помогло: звонок отбивается станцией сразу (смотрел в трассировке потоковой платы).

С причиной?
АОН?

как раз и хотелось-бы уточнить как снять трассировку с "слота VOIB".
потому как в трассировке PRI звонок есть, правило перенаправления звонка - тоже есть, а вот в трассировке на шлюзе, звонка уже - нет.

Cause Value = 3 No route to destination

Т.е. до платы VOIB дело и не доходит... Поэтому трассировку VOIB ничего не даст. Там ничего и нет.
Покажите хоть трассировку потока и текущий конфиг.

Чего меняли в CO Call Rerouting(252)?

********************************************
* THE 3-RD LAYER EDSS1 MESSAGE IN DETALE *
********************************************
00000101: 0x05: SETUP
--------------:
00000100: 0x04: BEARER CAPABILITY:
00000011: 0x03: Length = 3
10010000: 0x90:
1******* Extension = 1
*00***** Coding Standard = CCITT standardized coding
***10000 Information transfer capability = 3.1 kHz audio
10010000: 0x90:
1******* Extension = 1
*00***** Transfer mode = Circuit mode
***10000 Information transfer rate = 64 kbit/s
10100011: 0xA3:
1******* Extension = 1
*01***** layer 1 identificator = 01
***00011 User information layer 1 protocol = Recommendation G.711 A-law
--------------:
00011000: 0x18: CHANNEL IDENTIFICATION:
00000011: 0x03: Length = 3
10101001: 0xA9:
1******* Extension = 1
*0****** Interface identifier present = implicitly identified
**1***** Interface type = primary rate interface
***0**** Spare = 0
****1*** Preferred/exclusive = exclusive
*****0** D-channel indicator = not D-channel
******01 Information channel selection = PRI:as indicated in following octets, BRI:B1 channel
10000011: 0x83:
1******* Extension = 1
*00***** Coding standard = CCITT standardized coding
***0**** Number/Map = channel is indicated by the number
****0011 Channel type/Map element type = B-channel units
10000010: 0x82:
1******* Extension = 1
*0000010 Channel number/slot map = 2
--------------:
00011110: 0x1E: PROGRESS INDICATOR:
00000010: 0x02: Length = 2
10000001: 0x81:
1******* Extension = 1
*00***** Coding standard = CCITT standardized coding
***0**** Spare = 0
****0001 Location = private network serving the local user
10000011: 0x83:
1******* Extension = 1
*0000011 Progress description = 3. Origination address is non-ISDN
--------------:
01101100: 0x6C: CALLING PARTY NUMBER:
00000101: 0x05: Length = 5
10000000: 0x80:
1******* Extension = 1
*000**** Type of number = unknown
****0000 Numbering plan identification = unknown
IA5 ... Number: 3210
--------------:
01110000: 0x70: CALLED PARTY NUMBER:
00000101: 0x05: Length = 5
10000001: 0x81:
1******* Extension = 1
*000**** Type of number = unknown
****0001 Numbering plan identification = ISDN/Telephony numbering plan (CCITT Rec. E.164/E.163)
IA5 ... Number: 2008
--------------:

********************************************
* THE 3-RD LAYER EDSS1 MESSAGE IN DETALE *
********************************************
00001101: 0x0D: SETUP ACKNOWLEDGE
--------------:
00011000: 0x18: CHANNEL IDENTIFICATION:
00000011: 0x03: Length = 3
10101001: 0xA9:
1******* Extension = 1
*0****** Interface identifier present = implicitly identified
**1***** Interface type = primary rate interface
***0**** Spare = 0
****1*** Preferred/exclusive = exclusive
*****0** D-channel indicator = not D-channel
******01 Information channel selection = PRI:as indicated in following octets, BRI:B1 channel
10000011: 0x83:
1******* Extension = 1
*00***** Coding standard = CCITT standardized coding
***0**** Number/Map = channel is indicated by the number
****0011 Channel type/Map element type = B-channel units
10000010: 0x82:
1******* Extension = 1
*0000010 Channel number/slot map = 2
--------------:

********************************************
* THE 3-RD LAYER EDSS1 MESSAGE IN DETALE *
********************************************
01000101: 0x45: DISCONNECT
--------------:
00001000: 0x08: CAUSE:
00000010: 0x02: Length = 2
10000000: 0x80:
1******* Extension = 1
*00***** Coding standard = CCITT standardized coding
***0**** Spare = 0
****0000 Location = user
10000011: 0x83:
1******* Extension = 1
*0000011 Cause Value = 3 No route to destination
--------------:
00011110: 0x1E: PROGRESS INDICATOR:
00000010: 0x02: Length = 2
10000001: 0x81:
1******* Extension = 1
*00***** Coding standard = CCITT standardized coding
***0**** Spare = 0
****0001 Location = private network serving the local user
10000011: 0x83:
1******* Extension = 1
*0000011 Progress description = 3. Origination address is non-ISDN
--------------:

http://yadi.sk/d/X2LMPWXx8b1U4
ссылка на конфиг, он 2,5Мб весит

Вызов идет 2008 (кстати, а почему нет Sending_Complete ????),
а что прописано в ПГМ252 ??? Там есть роут для набора, начинающегося на 2 ??

есть
index 0
CO Group 3
Compare Digits 3
CO + Rerouting Number 890013
Rerouting Type Net

index 0
CO Group 1
Compare Digits 2
CO + Rerouting Number 890032
Rerouting Type Net

всего два правила, и второе из них работать и перестало.

А не появилась ли 2 в LCR с направлением куда-нибудь в ....? Конфиг просто не могу сейчас глянуть...

в PGM 221 с цифры "2" и "3" есть по одному правилу
2DDD и 3DDD соответственно

в PGM 222 соответственно
Removal Position 1
Number of digits to be removed 0
Add Position 1
CO/IP Group для "2" 3я группа линий, для "3" - 2я группа.

Да, там и 2 и 3 в INT LCR.
Но на роут "3" все работает, если я правильно понял.

Но для 3 в 252 программе используете группа 1, а в LCR - 2.

в LCR для 3, тоже используется 1я группа.

Конфиг то я не вижу, с ваших слов

1) Еще раз задам вопрос:
на стороне нумерации 3XXX (не знаю, какая там станция стоит) - там ничего не меняли??? Почему оттуда набор приходит псевдо-Enblock'ом (Setup оттуда приходит без Sending_Complete) ?? Это вынуждает LIK послать Setup_Ack !!

2) Не пробовали просто "убить" ПГМ252 (проинициализировать) и заново запрограммировать эти две строчки ??

Сразу уточню Kr@nk мой коллега и мы с ним ведем речь об одной и той же станции.

Вариант с тем, что что-то поменялось в настройках потока Билайном мне кажется самой правдоподобной, поскольку перестало работать без каких-либо действий с нашей стороны. Как было изначально я, к сожалению, не знаю - не было необходимости снимать и сохранять трассировку пока все работало. Однако обращение в Билайн ситуацию не исправило. Непонятно только почему на 1ххх (внутренние номера iPECS) звонки с этого потока проходят.

Может быть вот это причиной того, что iPECS дает отбой: Numbering plan identification = ISDN/Telephony numbering plan (CCITT Rec. E.164/E.163)? Кстати, в сторону потока ПГМ143,151 у нас стоит Type of Number for Calling Party Info: National. А в сторону SIP-провайдера - unknown

Обнуление ПГМ252 с последующим воссозданием настроек не помогло.

На 1ХХХ вызовы потому и проходят, что они направлены непосредственно на абонентов LIK.
А при вызовах на номера 2ХХХ требуются транзит. Вот транзит с PRI на SIP и не работает. (но работает в обратную сторону - с SIP на PRI).
Тип плана нумерации и тип номера не имеют значения в данном случае. ИМХО.

Сравнили трассировки звонков на 2xxx и на 1xxx с номеров 3xxx. Разница только в ответе iPECS.

Разница в том, что требуется транзит. И транзит не работает, а почему - ХЗ.

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

Попробуйте выключить опцию {Reject Anonymous Incoming Call} для линий PRI (CO 1-30) в ПГМ140-142.

Приношу извинения, что неверно описал ситуацию. После тщательной перепроверки оказалось, что станция ПРОПУСКАЕТ через себя транзит, а вот вызовы на SIP-оператора различаются в поле from:

Вызов со внутреннего номера:
INVITE sip:2081@10.10.10.1 SIP/2.0
From: "1200"<sip:1200@10.10.10.1>;tag=42bd1bc0-20a0a0a-13c4-55013-114c4-6e5c2933-114c4
To: <sip:2081@10.10.10.1>

Вызов транзита:
INVITE sip:2081@10.10.10.1 SIP/2.0
From: "????"<sip:????@10.10.10.1>;tag=42bd37e8-20a0a0a-13c4-55013-11591-8f468bc-11591
To: <sip:2081@10.10.10.1>

По-моему, это уже где-то обсуждалось, но я не нашел. Уф, прямо гора с плеч свалилась. Теперь хоть понятно что править: каким-то образом передавать на станции транзитный номер, корректно настроив ISDN CO Line Attr(143,151).

А что в 324 программе?

Там почти все пусто
0 PSTN 5588 Yes Yes PSTN Off On No No 0
Остальные все:
1 NET 5588 No Yes NET Off On No No 0

Мдя... Нет слов. Столько времени убито зазря...
Прав мой шеф... - не хрена по форумам ползать...

См. ПГМ133 для SIP линий (CО 31-78), в разделе {CO to Offnet Direct Call Route} нужно:
прописать опцию [From/Contact ID] = ORI
Тогда пойдет в Invit'е вызов от 3ХХХ...
А у вас сейчас = SYS ATD, а аттендантом никто из абонентов не назначен, поэтому и пусто Invit'е.
Если пропишите аттенданта и оставите SYS_ATD, то для всех транзитных вызовов будет указан этот номер атеенданта.

harris, еще раз приношу свои извинения. И время убито вовсе не зря. Без этой информации мы бы еще неделю ковырялись. А аттенданта я самолично "прибивал" полгода назад по просьбе того самого аттенданта, которому надоело слушать "отзвоны" об ошибках. Спасибо!

Звонок прошел. Номер на экранчике показал 003204 (на sip-прокси я добавляю два нуля впереди по просьбе SIP-провайдера).

INVITE sip:2081@10.10.10.1 SIP/2.0
From: <sip:3204@10.10.10.1>;tag=42beb188-20a0a0a-13c4-55013-12082-1dd71501-12082
To: <sip:2081@10.10.10.1>

Нет аттенданта? А как так может быть, чтобы его вообще не было?

"Прибивали" полгода назад, а проблему заметили только сейчас??

Я не про ваше время, а про своё...
Для вас, видимо, не зря... А для меня - впустую. Свою работу из-за этого притормозил.
(Форум - это ж не работа, а хобби... )
Проблема-то на 5 минут, если правильно исходную информацию собрать.

Ок. Проехали..

Нет, Игорь, ты не прав! А поговорить...

Сейчас и не помню как я это сделал. Удалить напрямую его нельзя, и, по-моему, у аттендата очень "удачно" сдох аппарат (они на том объекте почему-то пачками дохнут и мы их регулярно возим в гарантийный ремонт) и я не стал его восстанавливать.


Ага. Видимо, не так им и нужна эта функция.

Игорь, готов компенсировать потраченное время. И моя вина в том, что изначально сам не проверил логи с прокси, положившись на слова коллеги.

Удалили абонента вообще??


Заявления, что, мол, ничего не менялось и вдруг перестало работать всегда уводят в сторону.

Нет, ничего компенсировать не требуется... Просто на будущее проверяйте все тщательнее.

Ага. Я мог бы назначить себя аттендантом, но я подключен удаленно как SIP-абонент, а его нельзя назначить дежурным.


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

А я "повелся" на то, что

Поэтому настройки SIP посмотрел совсем бегло, проверял настройки транзита и PRI...
Ну, ладно, чего это мусолить... Всё бывает, у всех...

2 ADv:
Пожалйста, без обид. Мы просто немного поворчали, выпустили легкий пар досады...
Проехали... До след. "ребуса".
Удачи!

Жаль, что я так и не смог заглянуть в конфиг...

Спасибо еще раз. Обещаю в следующий раз все предварительно проверить сам. Да и какие обиды - мне очень приятно, что у тебя и Андрея нашлось время и желание помочь.

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

Добрый день.
Подскажите пожалуйста куда "рыть" в данной проблеме:

Две станции: в городе М - MFIM/GS96M-6.0Bo DEC/12 Boot Version-2.1Aa NOV/12 Kernel Version-6.0Ap H/W issue-2
в городе Ч - MFIM/GS96M-5.5Fc OCT/11 Boot Version-1.0Bf MAY/10 Kernel Version-5.5Dd H/W issue-3
Сделано объединение этих станций посредством Networking Data (Программы 320-325).
Связь между станциями обеспечивается через Интернет посредством VPN.
Станция М: MFIM/E IP Address : *.*.3.100
MFIM/E Sub Net Mask : 255.255.255.0
Router IP Address : *.*.3.1
Станция Ч: MFIM/E IP Address : *.*.0.100
MFIM/E Sub Net Mask : 255.255.255.0
Router IP Address : *.*.0.1

Решили переключить связь между станциями в канал точка-точка без выхода станции в Интернет. Соответственно прописали у обеих станций в Router IP Addres новые IP-адреса шлюзов нового канала. Больше НИЧЕГО не трогали. Станции перегрузились и проблема - звонки со станции Ч проходят, слышимость в обе стороны замечательная. Вызовы со станции М на Ч не проходят, после набора номера - тишина в трубке, как с SLT-аппаратов, так и IP-аппаратов. Пинги станциями друг на друга проходят. Может быть ещё где-то что-то нужно донастроить, т.к. создаётся впечатление что частично трафик заворачивается по старому маршруту в VPN-туннель. Это видно по пингам со стороны Ч на М. Пинг уходит через GW нового канала, а ответ со станции М приходит через GW старого канала. Такое ощущение что старый GW где-то остался прописанным.

У Вас в станции M используются только каналы VOIP на MFIM или есть еще модуль VOIM ??
Если VOIM, то см. ПГМ132 (Board Base Attributes) для слота VOIM.

VOIM модуль проинициализирован, но отключен и не используется. В 132-ой программе что по Sequence VOIM, что по Sequence MFIM значения Router IP Address не заданы.

Static Route - ПГМ254 ??

В ПГМ254 пусто. Эти таблицы мы не трогали.

Так может дело совсем не в станции??
Снимите снифер, посмотрите куда станция посылает пакеты.

Честно - мы не знаем как снять логи со станции. Пробовали на комп проставить Phontage, проинициализировали его как внутренний номер на станции М, запустили на компе WireShark и вызвали с компа абонента станции Ч. Но маршрута станции толком в логе WireShark так и не увидели.

Поставить на свитче зеркальный порт на MFIM, и снимать все пакеты от MFIM.
Phontage тут ни при чем. Networking работает через каналы VOIP на MFIM (Или VOIM).

Ну или хотя бы конфиг станции M покажите.

Добрый день. Попробую прикрепить файл конфигурации.

Ссылка на файл конфигурации: http://yadi.sk/d/qJD05lzcJcnGi

Это конфигурация до изменений (до перехода на новый канал связи).
Завтра утром снимем трафик с MFIM после переключения каналов (сегодня получилось снять WireShark-ом по старой схеме подключения)

В станции "М", в ПГМ342 (Net Numbering Plan) для нумерации абонентов станции "Ч" выключите использование адреса Firewall.