Объединение 2 IPECS в одну тел. сеть Опции

[Merlin22]

Есть 2 станции, стоят в разных офисах у каждой есть прямой (публичный) ip адрес.
В основном офисе секретарский телефон lip8012d и несколько дектовских трубок.
Во втором просто несколько дектовских трубок.
Внутри каждой АТС звонки ходят нормально, Каждая имеет сипнетовский аккаунт и вход и выход (через 9) работают. В одном офисе диапазон внутренних номеров 100 - 169 , во втором с 170 - ... .

Задача: сделать чтобы из одного офиса можно было позвонить во второй по коротким номерам.

Как правильно это сделать?
Важно при этом сохранить автономность, то есть при отключении интернета в любом из офисов чтобы во втором работал и вход и выход через сипнет.

[ADv]

Помнится в документации на 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]

И совсем маленький вопрос. Что-то я "накрутил" и при вызове на номер 3ххх (через поток) в трубке зуммер гудит непрерывно, как будто бы ждет донабора, но вызов проходит нормально и трубку снимают. Через SIP звук вызовов нормальный.

Через SIP на станцию поступает 180 Ringing, и LIK сам генерирует КПВ, а с потоком я дела не имел..

[ADv]

Через SIP на станцию поступает 180 Ringing, и LIK сам генерирует КПВ, а с потоком я дела не имел..

С гудком, кажется, разобрались: провайдер, похоже, каким-то хитрым отправляет звонок на свою DISA - то есть если начать набирать цифры, то гудок пропадает.

А транзит звонков через станцию можно настроить без лицензии NET?

[harris]

С гудком, кажется, разобрались: провайдер, похоже, каким-то хитрым отправляет звонок на свою DISA - то есть если начать набирать цифры, то гудок пропадает.

А транзит звонков через станцию можно настроить без лицензии NET?

Можно.

[ADv]

Можно.

Посмотрел красивую блок-схему на странице 15 Руководства по программированию iPLDK. Если обработать транзитный звонок в MSN (PGM202), указав Flexible DID (PGM231), то на внутренний номер его отправить можно. Но в PGM231 указать номер не принадлежащий АТС не получается. Указание NET-номера не срабатывает (отбой по тайауту и настройка PGM322 и PGM324 не помогает). Если не обрабатывать звонок в MSN, то звучит сообщение: "Неправильно набран номер".

harris, можно попросить описать как надо обрабатывать этот вызов?

[harris]

Посмотрел красивую блок-схему на странице 15 Руководства по программированию iPLDK. Если обработать транзитный звонок в MSN (PGM202), указав Flexible DID (PGM231), то на внутренний номер его отправить можно. Но в PGM231 указать номер не принадлежащий АТС не получается. Указание NET-номера не срабатывает (отбой по тайауту и настройка PGM322 и PGM324 не помогает). Если не обрабатывать звонок в MSN, то звучит сообщение: "Неправильно набран номер".

harris, можно попросить описать как надо обрабатывать этот вызов?

MSN вообще-то не предназначен для транзита.

Для транзита нужно либо использовать таблицы Networking (назначать сетевые транки в ПГМ322; в ПГМ324 прописывать транзитные коды - PSTN). При этом DID Conv Type должен быть = 1 (no treatment).
Либо использовать таблицу CO Call Reroute (ПГМ252).
И том и в другом случае есть нюансы, тем более, что идет речь о транзите SIP<->PRI.

хотя в LCR Type (PGM221) стоит BOTH (то есть обрабатывать и внешние вызовы тоже)

Вы не совсем правильно понимаете смысл опции BOTH !!! Прочтите описание LCR в доке на станции ipLDK. Там все подробно написано. (А в станциях LIK все аналогично).
BOTH означает обрабатывать коды, следующие после набора кода доступа к исходящей линии. С внешней линии тоже прийти код доступа к исходящей линии (транзитный код, например).

[harris]

Мдя.... Я пока не нахожу приемлемого решения конкретно для вашей ситуации.
Надо признать, что станция LIK для таких транзитов плохо приспособлена. Увы.

Пока получился только вариант с использованием ПГМ252 (CO Call Rerouting). И то с нюансами.
Продолжим уже на след. неделе.

[ADv]

Мдя.... Я пока не нахожу приемлемого решения конкретно для вашей ситуации.
Надо признать, что станция LIK для таких транзитов плохо приспособлена. Увы.

Пока получился только вариант с использованием ПГМ252 (CO Call Rerouting). И то с нюансами.
Продолжим уже на след. неделе.

Самое обидное, что решение это временное, до момента пока все удаленные офисы не будут переключены напрямую на LIK. Но когда это произойдет - неизвестно.

А если c помощью MSN отлавливать номер и направлять на SPEED ячейку, в которую прописан тот же самый номер и указана нужная CO Group для набора номера?...

Хотя, если использовать CO Call Rerouting, тоже придется вызовы на SPEED ячейки направлять.

Очень похожие варианты получаются.

Отлично! Через SpeedDial сработало! Правда, придется каждый номер вручную прописывать, а я даже не знаю их полного списка (ориентировочно их там штук 200).

[harris]

Самое обидное, что решение это временное, до момента пока все удаленные офисы не будут переключены напрямую на LIK. Но когда это произойдет - неизвестно.


Отлично! Через 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]

Я проверял ваш вариант с использованием ПГМ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ХХХ).

Подождите пару дней, может быть корейцы быстро исправят баг, тогда не придется присылать лишние префиксы.

harris! Все сработало! В моей прошивке 5.5Gt этого бага нет!
Еще раз ОГРОМНОЕ СПАСИБО!