Версия для печати темы
Нажмите сюда для просмотра этой темы в обычном формате
АРТКОМ Форум _ Техническая поддержка iPECS-LIK & iPECS-UCP _ Объединение 2 IPECS в одну тел. сеть
Автор: Merlin22 12.1.2010, 10:37
Есть 2 станции, стоят в разных офисах у каждой есть прямой (публичный) ip адрес.
В основном офисе секретарский телефон lip8012d и несколько дектовских трубок.
Во втором просто несколько дектовских трубок.
Внутри каждой АТС звонки ходят нормально, Каждая имеет сипнетовский аккаунт и вход и выход (через 9) работают. В одном офисе диапазон внутренних номеров 100 - 169 , во втором с 170 - ... .
Задача: сделать чтобы из одного офиса можно было позвонить во второй по коротким номерам.
Как правильно это сделать?
Важно при этом сохранить автономность, то есть при отключении интернета в любом из офисов чтобы во втором работал и вход и выход через сипнет.
Автор: harris 12.1.2010, 10:41
В основном офисе секретарский телефон lip8012d и несколько дектовских трубок.
Во втором просто несколько дектовских трубок.
Внутри каждой АТС звонки ходят нормально, Каждая имеет сипнетовский аккаунт и вход и выход (через 9) работают. В одном офисе диапазон внутренних номеров 100 - 169 , во втором с 170 - ... .
Задача: сделать чтобы из одного офиса можно было позвонить во второй по коротким номерам.
Как правильно это сделать?
Важно при этом сохранить автономность, то есть при отключении интернета в любом из офисов чтобы во втором работал и вход и выход через сипнет.
Как сделать??? - Точно так же, как это делается на станциях серии ipLDK, используя сервис Networking (ПГМ320-324).
В доке на станции ipLDK это все достаточно подробно, с картинками, расписано.
На iPECS все это программируется аналогично.
Автор: Merlin22 12.1.2010, 12:11
в ПГМ 320 параметр Net Enable не выставляется в положение On. Точнее сбрасывается в OFF при нажатии Save.
В чём может быть дело?
Автор: Dron 12.1.2010, 12:26
В чём может быть дело?
Чтобы не сбрасывалось, нужно приобрести и ввести ключик лицензии QSIG Networking
А главное, нужно понимание, что и как вы хотите сделать 
Автор: harris 12.1.2010, 12:48
В чём может быть дело?
Поскольку у Вас нет лицензии, то Вам нужно:
- ПГМ320/1 - Net Enable = OFF
- ПГМ321/1 - Net Transfer Mode = JOIN
Остальное программируется так же, как в примерах в доке.
Автор: Merlin22 12.1.2010, 16:42
Спасибо всё получилось.
Только вот теперь хотел уточнить.
у нас 2 MFIM100. У неё 6 внешних линий Voip.
вопросы:
1. Можем ли мы сделать более 6 NET-линий для связи между станциями. Для того чтобы более 6 звонков по внутренней связи между ними прошло одновременно?
2. Допустим запускаем 3 разговора между станциями. Теперь у нас остаётся только 3 Voip линии для связи с внешним миром? Одним словом линии для связи между станциями "откусываются " от 6 Voip линий?
Автор: harris 12.1.2010, 17:08
Только вот теперь хотел уточнить.
у нас 2 MFIM100. У неё 6 внешних линий Voip.
вопросы:
1. Можем ли мы сделать более 6 NET-линий для связи между станциями. Для того чтобы более 6 звонков по внутренней связи между ними прошло одновременно?
2. Допустим запускаем 3 разговора между станциями. Теперь у нас остаётся только 3 Voip линии для связи с внешним миром? Одним словом линии для связи между станциями "откусываются " от 6 Voip линий?
1. Нет. Иначе нужно ставить еще модуль VOIM
2. В общем случае - Да.
Но можно попробовать использовать те же 6 каналов, как для "выхода в город", так и для Networking.
В этом случае:
- в ПГМ322 указать все эти каналы как тип = PSTN (все равно для NET у Вас нет лицензии)
- в ПГМ140-142 указать параметр "CO VoIP Mode" = COMMON.
- в ПГМ324 все оставить без изменений.
Автор: Merlin22 13.1.2010, 14:13
Но можно попробовать использовать те же 6 каналов, как для "выхода в город", так и для Networking.
В этом случае:
- в ПГМ322 указать все эти каналы как тип = PSTN (все равно для NET у Вас нет лицензии)
- в ПГМ140-142 указать параметр "CO VoIP Mode" = COMMON.
- в ПГМ324 все оставить без изменений.
Извините, а можете пояснить что при этом должно получиться, я не совсем понял.
Автор: noox 13.1.2010, 14:34
Каждая из шести линий становится линией двойного назначения, т.е. используется в зависимости от того, что в данный момент времени набрал пользователь, либо для связи с внешним миром, либо для связи с другой станцией.
Автор: ADv 16.5.2012, 8:51
В доке на станции ipLDK это все достаточно подробно, с картинками, расписано.
На iPECS все это программируется аналогично.
MFIM/GS98M-5.5Ed AUG/11
Boot Version-1.0Ab JAN/10
Kernel Version-5.5Dd
H/W issue-1
Пытаемся настроить вызов на внешние SIP-абоненты (подключенные к неизвестной станции). Networkig-лицензии нет.
Внутренние абоненты 1xxx
Внешние абоненты 2ххх
SIP-Шлюз 10.10.10.3
Net Basic Attributes(320) - OFF (не дает поставить ON из-за отсутствия лицензии)
Net CO Line Attributes(322) на всех линиях: VOIM24 GW 31 DID 1 NET
Net Numbering Plan(324) две записи:
0 PSTN 1#*** 0 5588 No No PSTN Off On No No
1 NET 2*** 1 10.10.10.3 5588 No Yes NET Off On No No
При наборе номера 2ххх получаем сообщение "Отбой" и вызов на шлюз не происходит (линия 31 занимается). Вызов со внешних абонентов на внутренние номера 1xxx проходит без проблем.
Принципиально можно настроить такую схему без лицензии (уж больно долго корейцы лицензию выписывают)?
Автор: harris 16.5.2012, 9:35
MFIM/GS98M-5.5Ed AUG/11
Boot Version-1.0Ab JAN/10
Kernel Version-5.5Dd
H/W issue-1
Пытаемся настроить вызов на внешние SIP-абоненты (подключенные к неизвестной станции). Networkig-лицензии нет.
Внутренние абоненты 1xxx
Внешние абоненты 2ххх
SIP-Шлюз 10.10.10.3
Net Basic Attributes(320) - OFF (не дает поставить ON из-за отсутствия лицензии)
Net CO Line Attributes(322) на всех линиях: VOIM24 GW 31 DID 1 NET
Net Numbering Plan(324) две записи:
0 PSTN 1#*** 0 5588 No No PSTN Off On No No
1 NET 2*** 1 10.10.10.3 5588 No Yes NET Off On No No
При наборе номера 2ххх получаем сообщение "Неверный набор" и вызов на шлюз не происходит (линия 31 занимается). Вызов со внешних абонентов на внутренние номера 1xxx проходит без проблем.
Принципиально можно настроить такую схему без лицензии (уж больно долго корейцы лицензию выписывают)?
Причем тут, в вашем случае лицензия??? Вы все путаете!!
Лицензия относится только к функциям Networking, которые сделаны на основе H.323!!!
Cетевые таблицы (ПГМ322, 324) НЕ РАБОТАЮТ по SIP !!! Т.е. нельзя задать нумерацию и IP-адрес SIP-шлюза в ПГМ324.
Нужно отдельно программировать SIP-транк (ПГМ133б 126): с регистрацией или без (Provision Mode). А далее можно исаользовать LCR (прописать там INT код =2) и можно использовать Enblock Prefix Table для того, чтобы при наборе 2-ки длина номера не превышала 4 цифр (2ХХХ).
См. в доке раздел программирования линий SIP.
Автор: ADv 16.5.2012, 10:22
harris, спасибо за оперативный ответ!
Сделал LCR Control Attribute(220): Internal and Loop
LCR LDT(221): INT 2 000000
LCR DMT(222) ничего не менял потому что номер надо передавать в том виде как он набирался.
Линия занимается, но звонок не проходит, потому что станция передает на шлюз
Calling Number : anonymous
В функции ISDN CO Line Attr(143,151) COLP Table Index и CLIP Table Index стоит Station CLI. Как заставить станцию подставлять номер вызывающего абонента?
Это Prefix Dialing Table(206)?
Автор: harris 16.5.2012, 10:42
Сделал LCR Control Attribute(220): Internal and Loop
LCR LDT(221): INT 2 000000
LCR DMT(222) ничего не меняли потому что номер надо передавать в том виде как он набирался.
Линия занимается, но звонок не проходит, потому что станция передает
Calling Number : anonymous
В функции ISDN CO Line Attr(143,151) COLP Table Index и CLIP Table Index стоит Station CLI. Как заставить станцию подставлять номер вызывающего абонента?
Уваж. ADv!!
Я же написал Вам, что требуется запрограммировать SIP-транк по полной программе, в том числе и касательно полей [FROM_ID], [CONTACT_ID].
Если в качестве аккаунта нужно отправлять CLI, то тогда в этих полях указывается = Extension_Outgoing_CLI
Автор: ADv 16.5.2012, 11:01
Я же написал Вам, что требуется запрограммировать SIP-транк по полной программе, в том числе и касательно полей [FROM_ID], [CONTACT_ID].
Если в качестве аккаунта нужно отправлять CLI, то тогда в этих полях указывается = Extension_Outgoing_CLI
Сделал. Все то же самое.
На всякий случай выкладываю все настройки SIP CO Attributes(133)
Авторизации у нас не требуется. SIP-транк для входящих вызовов работает.
http://fastpic.ru/view/36/2012/0516/70818b68908e1dccc0279e9f45e93ea7.jpg.html
P.S. Прошу прощения, что скрины в разных вариантах: форум не дал сделать третье прикрепление.
|
|
Автор: ADv 18.5.2012, 11:38
Так и не удалось победить станцию. Максимум чего добились - заставили ее передавать номер в Remote-Party-ID и уже на шлюзе подставлять его в поле From.
В какой документации можно прочитать описание полей SIP CO Attributes(133) для версии 5.5?
Автор: Dron 18.5.2012, 11:55
В какой документации можно прочитать описание полей SIP CO Attributes(133) для версии 5.5?
Попробуйте не Extension Outgoing-CLI, а Extension SIP-User-ID-Table. Заполните в 126 программе SIP User ID и пропишите для абонентов SIP USER TABLE INDEX в атрибутах абонентов (111-113).
Автор: harris 18.5.2012, 15:03
В какой документации можно прочитать описание полей SIP CO Attributes(133) для версии 5.5?
Покажите сниф (снимите трассировку пакетов).
Автор: ADv 23.5.2012, 11:52
У нас не требуется авторизации на SIP-шлюзе, то есть таблица 126 - пустая. Тем не менее я ее заполнил - результат тот же.
Вот дебаг SIP-обмена со шлюза:
INVITE sip:2081@10.10.10.1 SIP/2.0
From: <sip:anonymous@10.10.10.1>;tag=42bebb78-20a0a0a-13c4-55013-3564-c810e58-3564
To: <sip:2081@10.10.10.1>
Call-ID: 42c06a00-20a0a0a-13c4-55013-3564-41fec91a-3564
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.10.10.2:5060;rport;branch=z9hG4bK-3564-d09158-36452aca
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
Supported: replaces,UPDATE,INFO
P-Asserted-Identity: <sip:@10.10.10.1>
Remote-Party-ID: <sip:1200@10.10.10.2>; party=calling; privacy=off; screen=yes
Privacy: none
User-Agent: LG-Ericsson iPECS-LIK 1200 5.5Gt
Contact: <sip:anonymous@10.10.10.2>
Min-SE: 0
Content-Type: application/sdp
Content-Length: 147
v=0
o=iPECS-LIK 78 78 IN IP4 10.10.10.12
s=iPECS-LIK SIP
c=IN IP4 10.10.10.12
t=0 0
m=audio 9046 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=sendrecv
*Mar 6 01:42:54.762: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.10.2:5060;rport;branch=z9hG4bK-3564-d09158-36452aca
From: <sip:anonymous@10.10.10.1>;tag=42bebb78-20a0a0a-13c4-55013-3564-c810e58-3564
To: <sip:2081@10.10.10.1>
Date: Wed, 06 Mar 2002 01:42:54 GMT
Call-ID: 42c06a00-20a0a0a-13c4-55013-3564-41fec91a-3564
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Далее идет "разговор" с внешним оператором, где уже подставляется пилотный номер.
Автор: harris 23.5.2012, 12:01
Пришлите файл вашего конфига.
Автор: Dron 23.5.2012, 12:54
Вот дебаг SIP-обмена со шлюза:
INVITE sip:2081@10.10.10.1 SIP/2.0
From: <sip:anonymous@10.10.10.1>;tag=42bebb78-20a0a0a-13c4-55013-3564-c810e58-3564
To: <sip:2081@10.10.10.1>
Call-ID: 42c06a00-20a0a0a-13c4-55013-3564-41fec91a-3564
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.10.10.2:5060;rport;branch=z9hG4bK-3564-d09158-36452aca
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
Supported: replaces,UPDATE,INFO
P-Asserted-Identity: <sip:@10.10.10.1>
Remote-Party-ID: <sip:1200@10.10.10.2>; party=calling; privacy=off; screen=yes
Privacy: none
User-Agent: LG-Ericsson iPECS-LIK 1200 5.5Gt
Contact: <sip:anonymous@10.10.10.2>
Min-SE: 0
Content-Type: application/sdp
Content-Length: 147
v=0
o=iPECS-LIK 78 78 IN IP4 10.10.10.12
s=iPECS-LIK SIP
c=IN IP4 10.10.10.12
t=0 0
m=audio 9046 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=sendrecv
*Mar 6 01:42:54.762: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.10.2:5060;rport;branch=z9hG4bK-3564-d09158-36452aca
From: <sip:anonymous@10.10.10.1>;tag=42bebb78-20a0a0a-13c4-55013-3564-c810e58-3564
To: <sip:2081@10.10.10.1>
Date: Wed, 06 Mar 2002 01:42:54 GMT
Call-ID: 42c06a00-20a0a0a-13c4-55013-3564-41fec91a-3564
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Далее идет "разговор" с внешним оператором, где уже подставляется пилотный номер.
А у вас в 114 проге, случайно, не включен у абонентов CLIR Service?
Автор: harris 23.5.2012, 13:01
1) Чтобы в качестве CLI станция посылала внутр. номер абонента нужно в ПГМ143/151 (ISDN CO Attr) указать тип номера = Unknown. А у Вас сейчас стоит = National. Поэтому CLI уходит пустым (подменяется на sip:anonimus).
Т.е. пропишите в ПГМ143/151 для линий СО 31-78 [Type of Number for Calling Party Info] = Unknown и все должно заработать.
2) На версиях 5.5 все-таки желательно не использовать тип линий COMMON, а указывать в ПГМ140-142более конкретно: SIP/H323/RTP Relay или их комбинация.
В вашем случае тип линий СО 31-78: SIP&RTP Relay.
3) ИМХО. Если уж Вы хотите также использовать поля P-Asserted-Id и Remote-Party-Id, то для них тоже, пожалуй, нужно указать в ПГМ133 = Extension-Outgoing-CLI.
Автор: ADv 23.5.2012, 13:27
Да, все сработало. Спасибо, harris, за очередную помощь. А этого нет в документации или я просто не смог найти?
Автор: harris 23.5.2012, 14:28
Да, есть. Видимо, не там искали.
При переводе доки "Описание и руководство по использованию функций iPECS LIK" я специально отредактировал п.4.15.2, добавил туда соответствующее пояснение и таблицу.
См. прикрепленный файл с выдержкой из доки.
Возможно, что это получилось не слишком четко.. Ну, что ж, прошу пардону.
В оригинальной доке (на английском) и этого не было.Все идентификаторы типа номера, кроме Unknown (т.е International/National/Sudscriber) требуют ссылки на Таблицу префиксов (CLIP Table). Если же ссылка на индекс (CLIP/COLP Table Index) не указана, а прописано = 50 (Station CLI), то тип номера может быть только Uknown.
В-общем, у меня есть алиби...
Автор: ADv 24.5.2012, 14:41
Помнится в документации на ipLDK было описание функций (со ссылками на программы) и описание каждой PGM с описанием всех полей (со ссылками на функции). Для iPECS-LIK я второй части (описание полей PGM) не нашел.
harris и все знающие форумчане, есть еще один вопрос о сопряжении станций. Как я уже описывал - у нас есть внутренние номер 1ххх, номера удаленных офисов подключенные через SIP (2ххх) и номера удаленных офисов подключенных через поток (3ххх). Звонки с 2ххх на 1ххх и обратно - проходят, с 3ххх на 1ххх и обратно - проходят. Для адресации, по совету harris-а, используется таблица LCR (221 и 222). Но еще требуется организовать "транзитные" звонки с 2ххх на 3ххх и обратно. Когда я набираю номер типа 3ххх с аппарата 2ххх, то слышу сообщение IPECS: "Неправильно набран номер", хотя в LCR Type (PGM221) стоит BOTH (то есть обрабатывать и внешние вызовы тоже). NET мы не используем. Как сделать возможным такой вызов?
И совсем маленький вопрос. Что-то я "накрутил" и при вызове на номер 3ххх (через поток) в трубке зуммер гудит непрерывно, как будто бы ждет донабора, но вызов проходит нормально и трубку снимают. Через SIP звук вызовов нормальный.
Автор: stasmar 25.5.2012, 7:24
Через SIP на станцию поступает 180 Ringing, и LIK сам генерирует КПВ, а с потоком я дела не имел..
Автор: ADv 25.5.2012, 8:27
С гудком, кажется, разобрались: провайдер, похоже, каким-то хитрым отправляет звонок на свою DISA - то есть если начать набирать цифры, то гудок пропадает.
А транзит звонков через станцию можно настроить без лицензии NET?
Автор: harris 25.5.2012, 9:11
А транзит звонков через станцию можно настроить без лицензии NET?
Можно.
Автор: ADv 25.5.2012, 12:14
harris, можно попросить описать как надо обрабатывать этот вызов?
Автор: harris 25.5.2012, 16:24
harris, можно попросить описать как надо обрабатывать этот вызов?
MSN вообще-то не предназначен для транзита.
Для транзита нужно либо использовать таблицы Networking (назначать сетевые транки в ПГМ322; в ПГМ324 прописывать транзитные коды - PSTN). При этом DID Conv Type должен быть = 1 (no treatment).
Либо использовать таблицу CO Call Reroute (ПГМ252).
И том и в другом случае есть нюансы, тем более, что идет речь о транзите SIP<->PRI.
Вы не совсем правильно понимаете смысл опции BOTH !!! Прочтите описание LCR в доке на станции ipLDK. Там все подробно написано. (А в станциях LIK все аналогично).
BOTH означает обрабатывать коды, следующие после набора кода доступа к исходящей линии. С внешней линии тоже прийти код доступа к исходящей линии (транзитный код, например).
Автор: harris 25.5.2012, 20:02
Мдя.... Я пока не нахожу приемлемого решения конкретно для вашей ситуации.
Надо признать, что станция LIK для таких транзитов плохо приспособлена. Увы.
Пока получился только вариант с использованием ПГМ252 (CO Call Rerouting). И то с нюансами.
Продолжим уже на след. неделе.
Автор: Dron 25.5.2012, 21:59
А если c помощью MSN отлавливать номер и направлять на SPEED ячейку, в которую прописан тот же самый номер и указана нужная CO Group для набора номера?...
Хотя, если использовать CO Call Rerouting, тоже придется вызовы на SPEED ячейки направлять.
Очень похожие варианты получаются.
Автор: ADv 28.5.2012, 9:47
Надо признать, что станция LIK для таких транзитов плохо приспособлена. Увы.
Пока получился только вариант с использованием ПГМ252 (CO Call Rerouting). И то с нюансами.
Продолжим уже на след. неделе.
Самое обидное, что решение это временное, до момента пока все удаленные офисы не будут переключены напрямую на LIK. Но когда это произойдет - неизвестно.
Хотя, если использовать CO Call Rerouting, тоже придется вызовы на SPEED ячейки направлять.
Очень похожие варианты получаются.
Отлично! Через SpeedDial сработало! Правда, придется каждый номер вручную прописывать, а я даже не знаю их полного списка (ориентировочно их там штук 200).
Автор: Dron 28.5.2012, 9:51
Использовали бы Н.323, не было бы таких проблем!
Автор: harris 28.5.2012, 10:00
Отлично! Через SpeedDial сработало! Правда, придется каждый номер вручную прописывать, а я даже не знаю их полного списка (ориентировочно их там штук 200).
Я проверял ваш вариант с использованием ПГМ252 - CRR (CO Call Rerouting). Это работает, но есть одно НО:
там есть (как мне кажется) один баг.
Для транзита первая цифра полученная и отправленная должны отличаться.
Т.е. принято с одного транка 2, а на другой транк нужно также эту 2-ку переправить (например, на 3-ий транк: 8032).
Вот это не получится - ИМХО, это баг. Я сегодня напишу запрос корейцам.
Т.е. в ПГМ252:
Compare CO Group: 1
Compare Digits : 2
CO + Rerouting Number: 8032 Так не пройдет!!
Compare CO Group: 1
Compare Digits : 42
CO + Rerouting Number: 8032 Так пройдет!!
Т.е. для транзита сейчас нужно присылать лишнюю цифру. В вашем случае, например:
42ХХХ (вместо 2ХХХ) и 43XXX (вместо 3ХХХ).
Подождите пару дней, может быть корейцы быстро исправят баг, тогда не придется присылать лишние префиксы.
Автор: ADv 28.5.2012, 10:15
Продолжим уже на след. неделе.
Через PGM252 тоже заработало (указываю группу линий, вызываемый номер, и 89+группа линий+вызываемый номер, тип NET). Но для каждого внутреннего номера требуется своя запись. В Compare Digits можно прописать групповую маску, например, 3*** или 2***, но CO + Rerouting Number можно указать только конкретный номер.
Автор: ADv 28.5.2012, 10:19
там есть (как мне кажется) один баг.
Для транзита первая цифра полученная и отправленная должны отличаться.
Т.е. принято с одного транка 2, а на другой транк нужно также эту 2-ку переправить (например, на 3-ий транк: 8032).
Вот это не получится - ИМХО, это баг. Я сегодня напишу запрос корейцам.
Т.е. в ПГМ252:
Compare CO Group: 1
Compare Digits : 2
CO + Rerouting Number: 8032 Так не пройдет!!
Compare CO Group: 1
Compare Digits : 42
CO + Rerouting Number: 8032 Так пройдет!!
Т.е. для транзита сейчас нужно присылать лишнюю цифру. В вашем случае, например:
42ХХХ (вместо 2ХХХ) и 43XXX (вместо 3ХХХ).
Подождите пару дней, может быть корейцы быстро исправят баг, тогда не придется присылать лишние префиксы.
harris! Все сработало! В моей прошивке 5.5Gt этого бага нет!
Еще раз ОГРОМНОЕ СПАСИБО!
Автор: Dron 28.5.2012, 10:24
Т.е., все равно все номера прописывать?
Как и писал выше, очень схожие варианты получились.
Автор: harris 28.5.2012, 10:35
Как и писал выше, очень схожие варианты получились.
Я не проверял на 5.5Gt (у меня на тестовой станции еще осталась предыдущая - E.5Go).
Я не понял, зачем Вы прописываете каждый номер в отдельности??
У Вас должно быть так (только номера транков подправить):
Compare CO Group: 1 (откуда поступает вызов)
Compare Digits : 2 (префикс (первая цифра номера))
CO + Rerouting Number: 8032 (на какой транк отправить+ тот же самый префикс)
Автор: ADv 28.5.2012, 10:39
Как и писал выше, очень схожие варианты получились.
В варианте harris-а (PGM252 добавил две записи: 3 3 890013 NET и 1 2 890032 NET) все заработало без прописывания каждого номера. В пятницу просмотрел всю документацию, но эту полезную функцию не увидел.
Compare Digits : 2 (префикс (первая цифра номера))
CO + Rerouting Number: 8032 (на какой транк отправить+ тот же самый префикс)
Да-да. Именно так и заработало.
Только у меня префикс выбора группы линий 89, а количество групп до 201, поэтому-то 89001 и 89003 .
Автор: harris 28.5.2012, 10:44
Да-да. Именно так и заработало.
Только у меня префикс выбора группы линий 89, а количество групп до 201, поэтому-то 89001 и 89003 .Ну и славно... И мне легче - не придется писать "телегу" корейцам...
Автор: Dron 28.5.2012, 10:55
Да-да. Именно так и заработало.
Только у меня префикс выбора группы линий 89, а количество групп до 201, поэтому-то 89001 и 89003 .Ок. Значит, так проще.
Автор: ADv 2.9.2013, 13:50
Проработала эта система год и, без каких-либо известных мне изменений в конфигурации, звонки с номеров 3xxx на 2ххх не проходят. Напомню, система такая:
1ххх - внутренние номера iPECS1000
2xxx - номера от SIP-провайдера
3ххх - номера по E1.
Ситуация следующая
1. С 1ххх на 2ххх - проходят (используется LCR)
2. С 1ххх на 3ххх - проходят (используется LCR)
3. С 2ххх на 1ххх - проходят
4. С 2ххх на 3ххх - проходят (используется CO Call Rerouting(252))
5. С 3ххх на 1ххх - проходят
6. С 3ххх на 2ххх - НЕ проходят (используется CO Call Rerouting(252))
Ставил отладчик на поток и на SIP-прокси. При звонке с 3ххх на 2ххх звонок в потоке приходит верно, но на SIP-линию не попадает (застревает где-то в станции). Во всех остальных вариантах отладчик показывает все верно. Сравнивал текущую настройку со старыми бекапами - ключевых изменений не нашел (CO/IP Attributes(140~142), ISDN Attributes(200), MSN Table(202), Prefix Dialing Table(206), LCR LDT(221), LCR DMT(222), Flexible DID Conversion(231), CO Call Rerouting(252)). Станцию перезагружали. Где еще может быть "засада"?
MFIM/GS98M-5.5Gt MAY/12
Автор: harris 2.9.2013, 15:18
1ххх - внутренние номера iPECS1000
2xxx - номера от SIP-провайдера
3ххх - номера по E1.
Ситуация следующая
1. С 1ххх на 2ххх - проходят (используется LCR)
2. С 1ххх на 3ххх - проходят (используется LCR)
3. С 2ххх на 1ххх - проходят
4. С 2ххх на 3ххх - проходят (используется CO Call Rerouting(252))
5. С 3ххх на 1ххх - проходят
6. С 3ххх на 2ххх - НЕ проходят (используется CO Call Rerouting(252))
Ставил отладчик на поток и на SIP-прокси. При звонке с 3ххх на 2ххх звонок в потоке приходит верно, но на SIP-линию не попадает (застревает где-то в станции). Во всех остальных вариантах отладчик показывает все верно. Сравнивал текущую настройку со старыми бекапами - ключевых изменений не нашел (CO/IP Attributes(140~142), ISDN Attributes(200), MSN Table(202), Prefix Dialing Table(206), LCR LDT(221), LCR DMT(222), Flexible DID Conversion(231), CO Call Rerouting(252)). Станцию перезагружали. Где еще может быть "засада"?
MFIM/GS98M-5.5Gt MAY/12
Ну вы же понимаете, что ваш вопрос риторический... Можно только гадать. Ключевых изменений не было, так может повлияло то, что вы не относите к ключевым ???
Автор: ADv 2.9.2013, 15:25
Сам нахожусь в смятении. Все ключевые, с моей точки зрения, программы я перечислил. Возможно, что какие-то еще так выборочно влияют на транзит звонков? Может есть способ отследить путь звонка внутри станции: какие функции сработали и с каким результатом?
Автор: harris 2.9.2013, 15:28
Нет такого способа.
Только трассировка, из которой далеко не все ясно (только для разработчиков).
Автор: ADv 2.9.2013, 15:32
Только трассировка, из которой далеко не все ясно (только для разработчиков).
Трассировка VOIM-овской платы может дать какую-нибудь информацию? Если да, то как ее запустить (почему-то не нашел способа это сделать)?
Автор: harris 2.9.2013, 15:34
У вас же транзит, трассировка нужно смотреть одновременно потока PRI и слота VOIB.
Посмотрите еще раз конфиг станции, может что-то вы все-таки "сломали" ??
Автор: Dron 2.9.2013, 15:38
Не, так не бывает! Что то изменилось!
Автор: ADv 2.9.2013, 15:38
Посмотрите еще раз конфиг станции, может что-то вы все-таки "сломали" ??
Нашел одно отличие: изменился адрес Firewall (сменился провайдер, а в настройках станции этого не отразили). Только если это влияет, то прохождение звонков с 1ххх на 2ххх не должно было работать.
Автор: Dron 2.9.2013, 15:42
Боюсь, не сказать однозначно, как оно и на что влияет! На прохождение звонков вряд ли влияет, а вот на прохождение голоса...
Автор: ADv 2.9.2013, 15:58
Прописывание Firewall-а не помогло: звонок отбивается станцией сразу (смотрел в трассировке потоковой платы).
Автор: Dron 2.9.2013, 16:00
С причиной?
АОН?
Автор: Kr@nk 2.9.2013, 16:01
Посмотрите еще раз конфиг станции, может что-то вы все-таки "сломали" ??
как раз и хотелось-бы уточнить как снять трассировку с "слота VOIB".
потому как в трассировке PRI звонок есть, правило перенаправления звонка - тоже есть, а вот в трассировке на шлюзе, звонка уже - нет.
Автор: Kr@nk 2.9.2013, 16:02
АОН?
Cause Value = 3 No route to destination
Автор: harris 2.9.2013, 16:06
Т.е. до платы VOIB дело и не доходит... Поэтому трассировку VOIB ничего не даст. Там ничего и нет.
Покажите хоть трассировку потока и текущий конфиг.
Автор: Dron 2.9.2013, 16:11
Чего меняли в CO Call Rerouting(252)?
Автор: Kr@nk 2.9.2013, 16:24
********************************************
* 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
--------------:
Автор: Kr@nk 2.9.2013, 16:28
http://yadi.sk/d/X2LMPWXx8b1U4
ссылка на конфиг, он 2,5Мб весит
Автор: harris 2.9.2013, 16:30
Вызов идет 2008 (кстати, а почему нет Sending_Complete ????),
а что прописано в ПГМ252 ??? Там есть роут для набора, начинающегося на 2 ??
Автор: Kr@nk 2.9.2013, 16:37
а что прописано в ПГМ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
всего два правила, и второе из них работать и перестало.
Автор: Dron 2.9.2013, 16:41
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 с направлением куда-нибудь в ....? Конфиг просто не могу сейчас глянуть...
Автор: Kr@nk 2.9.2013, 16:49
в 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я группа.
Автор: harris 2.9.2013, 16:54
Да, там и 2 и 3 в INT LCR.
Но на роут "3" все работает, если я правильно понял.
Автор: Dron 2.9.2013, 16:56
Но на роут "3" все работает, если я правильно понял.
Но для 3 в 252 программе используете группа 1, а в LCR - 2.
Автор: Kr@nk 2.9.2013, 17:01
в LCR для 3, тоже используется 1я группа.
Автор: Dron 2.9.2013, 17:11
Removal Position 1
Number of digits to be removed 0
Add Position 1
CO/IP Group для "2" 3я группа линий, для "3" - 2я группа.
Конфиг то я не вижу, с ваших слов
Автор: harris 2.9.2013, 17:19
1) Еще раз задам вопрос:
на стороне нумерации 3XXX (не знаю, какая там станция стоит) - там ничего не меняли??? Почему оттуда набор приходит псевдо-Enblock'ом (Setup оттуда приходит без Sending_Complete) ?? Это вынуждает LIK послать Setup_Ack !!
2) Не пробовали просто "убить" ПГМ252 (проинициализировать) и заново запрограммировать эти две строчки ??
Автор: ADv 3.9.2013, 8:46
на стороне нумерации 3XXX (не знаю, какая там станция стоит) - там ничего не меняли??? Почему оттуда набор приходит псевдо-Enblock'ом (Setup оттуда приходит без Sending_Complete) ?? Это вынуждает LIK послать Setup_Ack !!
Сразу уточню 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 с последующим воссозданием настроек не помогло.
Автор: harris 3.9.2013, 9:53
Вариант с тем, что что-то поменялось в настройках потока Билайном мне кажется самой правдоподобной, поскольку перестало работать без каких-либо действий с нашей стороны. Как было изначально я, к сожалению, не знаю - не было необходимости снимать и сохранять трассировку пока все работало. Однако обращение в Билайн ситуацию не исправило. Непонятно только почему на 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).
Тип плана нумерации и тип номера не имеют значения в данном случае. ИМХО.
Автор: ADv 3.9.2013, 10:36
А при вызовах на номера 2ХХХ требуются транзит. Вот транзит с PRI на SIP и не работает. (но работает в обратную сторону - с SIP на PRI).
Тип плана нумерации и тип номера не имеют значения в данном случае. ИМХО.
Сравнили трассировки звонков на 2xxx и на 1xxx с номеров 3xxx. Разница только в ответе iPECS.
Автор: harris 3.9.2013, 10:39
Разница в том, что требуется транзит. И транзит не работает, а почему - ХЗ.
Автор: ADv 3.9.2013, 10:56
В лоб задача, похоже, не решается. Вечером попробуем загрузить декабрьскую конфигурацию (на ней все гарантированно работало) и проверим. Сложность только в том, что днем станцией активно пользуются, а вечером не будет возможности проверить звонки с 3ххх - все уйдут домой. О результатах эксперимента отпишусь.
Автор: harris 3.9.2013, 10:56
Попробуйте выключить опцию {Reject Anonymous Incoming Call} для линий PRI (CO 1-30) в ПГМ140-142.
Автор: ADv 3.9.2013, 11:38
Приношу извинения, что неверно описал ситуацию. 
После тщательной перепроверки оказалось, что станция ПРОПУСКАЕТ через себя транзит, а вот вызовы на 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).
Автор: Dron 3.9.2013, 11:52
После тщательной перепроверки оказалось, что станция ПРОПУСКАЕТ через себя транзит, а вот вызовы на 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>
По-моему, это уже где-то обсуждалось, но я не нашел. Уф, прямо гора с плеч свалилась. Теперь хоть понятно что править: каким-то образом передавать на станции транзитный номер.
А что в 324 программе?
Автор: ADv 3.9.2013, 11:55
Там почти все пусто
0 PSTN 5588 Yes Yes PSTN Off On No No 0
Остальные все:
1 NET 5588 No Yes NET Off On No No 0
Автор: harris 3.9.2013, 11:58
После тщательной перепроверки оказалось, что станция ПРОПУСКАЕТ через себя транзит, а вот вызовы на 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).
Мдя... Нет слов. Столько времени убито зазря...
Прав мой шеф... - не хрена по форумам ползать...
См. ПГМ133 для SIP линий (CО 31-78), в разделе {CO to Offnet Direct Call Route} нужно:
прописать опцию [From/Contact ID] = ORI
Тогда пойдет в Invit'е вызов от 3ХХХ...
А у вас сейчас = SYS ATD, а аттендантом никто из абонентов не назначен, поэтому и пусто Invit'е.
Если пропишите аттенданта и оставите SYS_ATD, то для всех транзитных вызовов будет указан этот номер атеенданта.
Автор: ADv 3.9.2013, 12:05
Прав мой шеф... - не хрена по форумам ползать...
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>
Автор: Dron 3.9.2013, 12:08
Нет аттенданта? А как так может быть, чтобы его вообще не было?
Автор: Dron 3.9.2013, 12:09
"Прибивали" полгода назад, а проблему заметили только сейчас??
Автор: harris 3.9.2013, 12:15
Я не про ваше время, а про своё...
Для вас, видимо, не зря... А для меня - впустую. Свою работу из-за этого притормозил.
(Форум - это ж не работа, а хобби...
)Проблема-то на 5 минут, если правильно исходную информацию собрать.
Ок. Проехали..
Автор: Dron 3.9.2013, 12:19
Для вас, видимо, не зря... А для меня - впустую. Свою работу из-за этого притормозил.
(Форум - это ж не работа, а хобби...
)Проблема-то на 5 минут, если правильно исходную информацию собрать.
Ок. Проехали..
Нет, Игорь, ты не прав! А поговорить...
Автор: ADv 3.9.2013, 12:19
Сейчас и не помню как я это сделал. Удалить напрямую его нельзя, и, по-моему, у аттендата очень "удачно" сдох аппарат (они на том объекте почему-то пачками дохнут и мы их регулярно возим в гарантийный ремонт) и я не стал его восстанавливать.
Ага. Видимо, не так им и нужна эта функция.
Игорь, готов компенсировать потраченное время.
И моя вина в том, что изначально сам не проверил логи с прокси, положившись на слова коллеги.
Автор: Dron 3.9.2013, 12:22
Удалили абонента вообще??
Заявления, что, мол, ничего не менялось и вдруг перестало работать всегда уводят в сторону.
Автор: harris 3.9.2013, 12:30
И моя вина в том, что изначально сам не проверил логи с прокси, положившись на слова коллеги.Нет, ничего компенсировать не требуется...
Просто на будущее проверяйте все тщательнее.
Автор: ADv 3.9.2013, 12:30
Ага. Я мог бы назначить себя аттендантом, но я подключен удаленно как SIP-абонент, а его нельзя назначить дежурным.
У меня даже мысли не возникло о том, что изменения полугодовой давности заметили только сейчас. Тем более, что клиент говорил о паре недель.
Автор: harris 3.9.2013, 12:34
А я "повелся" на то, что
Поэтому настройки SIP посмотрел совсем бегло, проверял настройки транзита и PRI...
Ну, ладно, чего это мусолить... Всё бывает, у всех...
2 ADv:
Пожалйста, без обид. Мы просто немного поворчали, выпустили легкий пар досады...
Проехали... До след. "ребуса".
Удачи!
Автор: Dron 3.9.2013, 12:47
АОН?
Жаль, что я так и не смог заглянуть в конфиг...
Автор: ADv 3.9.2013, 13:14
Проехали... До след. "ребуса".
Удачи!
Спасибо еще раз. Обещаю в следующий раз все предварительно проверить сам. Да и какие обиды - мне очень приятно, что у тебя и Андрея нашлось время и желание помочь.
Надеюсь, наш разговор поможет кому-то еще найти причину ошибок в подобной ситуации.
Автор: mishalex 26.2.2014, 15:10
Добрый день.
Подскажите пожалуйста куда "рыть" в данной проблеме:
Две станции: в городе М - 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 где-то остался прописанным.
Автор: harris 26.2.2014, 15:30
Подскажите пожалуйста куда "рыть" в данной проблеме:
Две станции: в городе М - 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.
Автор: mishalex 26.2.2014, 15:43
VOIM модуль проинициализирован, но отключен и не используется. В 132-ой программе что по Sequence VOIM, что по Sequence MFIM значения Router IP Address не заданы.
Автор: harris 26.2.2014, 16:19
Static Route - ПГМ254 ??
Автор: mishalex 26.2.2014, 16:24
В ПГМ254 пусто. Эти таблицы мы не трогали.
Автор: harris 26.2.2014, 16:43
Так может дело совсем не в станции??
Снимите снифер, посмотрите куда станция посылает пакеты.
Автор: mishalex 26.2.2014, 16:57
Снимите снифер, посмотрите куда станция посылает пакеты.
Честно - мы не знаем как снять логи со станции. Пробовали на комп проставить Phontage, проинициализировали его как внутренний номер на станции М, запустили на компе WireShark и вызвали с компа абонента станции Ч. Но маршрута станции толком в логе WireShark так и не увидели.
Автор: harris 26.2.2014, 17:32
Поставить на свитче зеркальный порт на MFIM, и снимать все пакеты от MFIM.
Phontage тут ни при чем. Networking работает через каналы VOIP на MFIM (Или VOIM).
Ну или хотя бы конфиг станции M покажите.
Автор: mishalex 27.2.2014, 8:44
Phontage тут ни при чем. Networking работает через каналы VOIP на MFIM (Или VOIM).
Ну или хотя бы конфиг станции M покажите.
Добрый день. Попробую прикрепить файл конфигурации.
Автор: mishalex 27.2.2014, 9:31
Ссылка на файл конфигурации: http://yadi.sk/d/qJD05lzcJcnGi
Это конфигурация до изменений (до перехода на новый канал связи).
Завтра утром снимем трафик с MFIM после переключения каналов (сегодня получилось снять WireShark-ом по старой схеме подключения)
Автор: harris 27.2.2014, 11:39
Это конфигурация до изменений (до перехода на новый канал связи).
Завтра утром снимем трафик с MFIM после переключения каналов (сегодня получилось снять WireShark-ом по старой схеме подключения)
В станции "М", в ПГМ342 (Net Numbering Plan) для нумерации абонентов станции "Ч" выключите использование адреса Firewall.
Автор: mishalex 27.2.2014, 12:19
В ПГМ Net Numbering Plan(324)[N] - FireWall Routing поставить в значение NO? Попробуем завтра. Спасибо.
Автор: harris 27.2.2014, 12:40
Я не очень понимаю, как у Вас была настроена связь раньше и как стало теперь.
Было:
Стало:
Сейчас станции связаны по VPN ?? Сетки 192.168.0.X и 192.168.3.X связаны прозрачно?? Тогда выключите Firewall в ПГМ324. Т.е. разберитесь с Firewall.
Автор: mishalex 28.2.2014, 8:50
Было:
Стало:
Сейчас станции связаны по VPN ?? Сетки 192.168.0.X и 192.168.3.X связаны прозрачно?? Тогда выключите Firewall в ПГМ324. Т.е. разберитесь с Firewall.
Добрый день. Выключение Firewall в ПГМ324 не помогло. Сняли лог WireShark-ом. Ссылка на лог: http://yadi.sk/d/JG-K3AsZJgDDS. Из этого лога видно, что трафик от станции М (Х.Х.3.100) на станцию Ч (Х.Х.0.100) по прежнему идёт через интерфейс CISCO. Это старый GW (Х.Х.3.1). Хотя должен идти через интерфейс нового GW (Х.Х.3.2) - IntelCor, это видно по вызовам со станции Ч на М, там трафик проходит по новому каналу. Почему станция М по-прежнему заворачивает трафик на старый GW - непонятно.
Автор: harris 28.2.2014, 9:42
После того, как прописали новый адрес шлюза в станции, вы саму станцию перезапустили или нет??
Если нет, то нужно ее перезапустить.
Автор: mishalex 28.2.2014, 10:00
Если нет, то нужно ее перезапустить.
Перезапустили. Она сама при нажатии "Save" сообщает что нужна перезагрузка и при нажатии ОК на 2 минуты уходит в рестарт.
Автор: harris 28.2.2014, 10:27
Ок.
Но в снифере только пакеты H.323 сигнализации.
А где остальное?? Где ARP ?
Где видно, какой адрес запрашивает станция по ARP ??
И запрашивает ли она адрес шлюза. Т.к. у вас указана маска сети 255.255.0.0, а адреса станции М (192.168.3.100) и Ч (192.168.0.100) определены в одной сетке, то станция запрашивает по ARP сразу адрес станции Ч, а не адрес роутера. У вас сейчас оба роутера в сети. Кто из них откликнулся на запрос ARP, на тот MAC адрес станция и шлет пакеты H.323.
Автор: Greahem 28.2.2014, 13:58
Так в посте с вопросом было указано, что маска подсети на обеих станциях 255.255.255.0. Что-то поменялось или изначальные данные неверные были предоставлены?
to mishalex
Станции между собой пингуются вообще?
Автор: harris 28.2.2014, 14:09
to mishalex
Станции между собой пингуются вообще?
Пардон, я не совсем четко выразился выше. У автора топика в конфиге прописано:
MFIM/E IP Address : 192.168.3.100
MFIM/E Sub Net Mask : 255.255.255.0
System IP Range : 192.168.3.101 - 192.168.3.129
System Sub Net Mask : 255.255.0.0
Суть та же.
Автор: Greahem 28.2.2014, 14:58
MFIM/E IP Address : 192.168.3.100
MFIM/E Sub Net Mask : 255.255.255.0
System IP Range : 192.168.3.101 - 192.168.3.129
System Sub Net Mask : 255.255.0.0
Суть та же.
ээ... Раньше не придавал значения этим строчкам. Какой же смысл у System Sub Net Mask? Как-то в моей голове это не укладывается теперь. На интерфейсе MFIM'а мы указываем маску в строке MFIM/E Sub Net Mask. System IP Range задается диапазоном, а не указанием адреса подсети и маски, для чего нужна System Sub Net Mask в этом случае мне непонятно. Тем более непонятно как можно дважды задать маску подсети на одном интерфейсе, если вы говорите, что суть та же?
Автор: harris 28.2.2014, 15:21
Если вы думаете, что у нас есть полное и подробное описание всех алгоритмов работы станции, то вы глубоко ошибаетесь.
Мы так же, как и вы, вынуждены догадываться, додумывать и проверять...В станции может быть указан, второй диапазон адресов и "второй" адрес MFIM. Это не реальный адрес интерфейса. Просто в этом случае станция также считает устройства из этой второй сети тоже локальными.
У автора топика указаны маски:
MFIM/E Sub Net Mask : 255.255.255.0
System Sub Net Mask : 255.255.0.0
Second System Net Mask : 255.255.0.0
Вот я предлагаю ему проверить, какой запрос ARP станция отправляет: с адресом роутера или с адресом станции "Ч" (т.к. ее адрес лежит в диапазоне локальных адресов).
Автор: mishalex 28.2.2014, 15:28
Но в снифере только пакеты H.323 сигнализации.
А где остальное?? Где ARP ?
Где видно, какой адрес запрашивает станция по ARP ??
И запрашивает ли она адрес шлюза. Т.к. у вас указана маска сети 255.255.0.0, а адреса станции М (192.168.3.100) и Ч (192.168.0.100) определены в одной сетке, то станция запрашивает по ARP сразу адрес станции Ч, а не адрес роутера. У вас сейчас оба роутера в сети. Кто из них откликнулся на запрос ARP, на тот MAC адрес станция и шлет пакеты H.323.
Действительно... Спасибо большое за подсказку, похоже на правду. В понедельник утром попробуем перенастроить. По результатам отпишусь. Хороших выходных!
Автор: mishalex 4.3.2014, 8:06
Добрый день. Всё получилось! Спасибо огромнейшее за оказанную помощь и консультации. Повлияли изменения System Sub Net Mask.
Автор: Bazz 1.10.2014, 12:24
Добрый день.
Чтоб не плодить темы, продолжу эту.
У нас два станции LIK-MFIM50A
MFIM/GS92M-6.0Bo DEC/12
Boot Version-2.1Aa NOV/12
Kernel Version-6.0Ap
H/W issue-1
планы нумерации 1хх и 2хх
линии voip тип DID
DID as is
в 320 NET ON лицензии есть
в 321 JOIN
в 322 СО 1-4 в группе 0, СО 5-8 в группе 1
NET нум.планы
на первой
0 - тип NET код 1#хх IP адреса нет Digit Repeat нет PSTN Enblock нет Firewall Routing нет
1 - тип NET код 2хх IP адрес 10.0.1.180 Digit Repeat нет PSTN Enblock нет Firewall Routing нет
на второй
0 - тип NET код 2#хх IP адреса нет Digit Repeat нет PSTN Enblock нет Firewall Routing нет
1 - тип NET код 1хх IP адрес 10.0.1.160 Digit Repeat нет PSTN Enblock нет Firewall Routing нет
не удается позвонить с одной атс на другую, внутри атс звонки ходят.
прикрепил два файла, один трассировка, как сумел, второй конфигурации атсок в .7z формате, но файл переименован в .тхт для прикрепления к сообщению
Помогите чем-нибудь, пожалста, не предлагайте вызвать квалифицированного специалиста, физически не получится, всё придется мне самому освоить. Доку на ЛДК читал и читаю. Подозреваю, что необходимо что-то еще настроить.
Автор: AXEL 1.10.2014, 13:57
ip adress не в той строке прописали в 324 программе.
кстати если есть лицензия, то лучше rerout
Автор: harris 1.10.2014, 14:20
кстати если есть лицензия, то лучше rerout
Угу. Адрес вызываемой станции должен быть прописан в поле [CPN INFORMATION 1].
А поле [MFIM(E) IP Address] - это для других задач, для DECT Mobility.
Автор: Bazz 1.10.2014, 15:26
Вот спасибо, ребята!
Залепил я, так уж залепил)))
Русская версия Invision Power Board (http://nulled.ws)
© Invision Power Services (http://nulled.ws)