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

[harris]

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]

Да, все сработало. Спасибо, harris, за очередную помощь. А этого нет в документации или я просто не смог найти?

[harris]

Да, все сработало. Спасибо, harris, за очередную помощь. А этого нет в документации или я просто не смог найти?

Да, есть. Видимо, не там искали.
При переводе доки "Описание и руководство по использованию функций iPECS LIK" я специально отредактировал п.4.15.2, добавил туда соответствующее пояснение и таблицу.
См. прикрепленный файл с выдержкой из доки.
Возможно, что это получилось не слишком четко.. Ну, что ж, прошу пардону. В оригинальной доке (на английском) и этого не было.
Все идентификаторы типа номера, кроме Unknown (т.е International/National/Sudscriber) требуют ссылки на Таблицу префиксов (CLIP Table). Если же ссылка на индекс (CLIP/COLP Table Index) не указана, а прописано = 50 (Station CLI), то тип номера может быть только Uknown.

В-общем, у меня есть алиби...

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

 From__.4.15.2.doc ( 27,5 килобайт ) Кол-во скачиваний: 61

 

[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). И то с нюансами.
Продолжим уже на след. неделе.

[Dron]

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

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

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

[ADv]

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

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

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

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

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

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

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

[Dron]

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

Использовали бы Н.323, не было бы таких проблем!

[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 (CO Call Rerouting). И то с нюансами.
Продолжим уже на след. неделе.

Через PGM252 тоже заработало (указываю группу линий, вызываемый номер, и 89+группа линий+вызываемый номер, тип NET). Но для каждого внутреннего номера требуется своя запись. В Compare Digits можно прописать групповую маску, например, 3*** или 2***, но CO + Rerouting Number можно указать только конкретный номер.

[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 этого бага нет!
Еще раз ОГРОМНОЕ СПАСИБО!

[Dron]

Через PGM252 тоже заработало (указываю группу линий, вызываемый номер, и 89+группа линий+вызываемый номер, тип NET). Но для каждого внутреннего номера требуется своя запись. В Compare Digits можно прописать групповую маску, например, 3*** или 2***, но CO + Rerouting Number можно указать только конкретный номер.

Т.е., все равно все номера прописывать?
Как и писал выше, очень схожие варианты получились.

[harris]

Т.е., все равно все номера прописывать?
Как и писал выше, очень схожие варианты получились.

Я не проверял на 5.5Gt (у меня на тестовой станции еще осталась предыдущая - E.5Go).
Я не понял, зачем Вы прописываете каждый номер в отдельности??
У Вас должно быть так (только номера транков подправить):

Compare CO Group: 1 (откуда поступает вызов)
Compare Digits : 2 (префикс (первая цифра номера))
CO + Rerouting Number: 8032 (на какой транк отправить+ тот же самый префикс)

[ADv]

Т.е., все равно все номера прописывать?
Как и писал выше, очень схожие варианты получились.

В варианте harris-а (PGM252 добавил две записи: 3 3 890013 NET и 1 2 890032 NET) все заработало без прописывания каждого номера. В пятницу просмотрел всю документацию, но эту полезную функцию не увидел.

Compare CO Group: 1 (откуда поступает вызов)
Compare Digits : 2 (префикс (первая цифра номера))
CO + Rerouting Number: 8032 (на какой транк отправить+ тот же самый префикс)

Да-да. Именно так и заработало. Только у меня префикс выбора группы линий 89, а количество групп до 201, поэтому-то 89001 и 89003 .

[harris]

В варианте harris-а (PGM252 добавил две записи: 3 3 890013 NET и 1 2 890032 NET) все заработало без прописывания каждого номера. В пятницу просмотрел всю документацию, но эту полезную функцию не увидел.


Да-да. Именно так и заработало. Только у меня префикс выбора группы линий 89, а количество групп до 201, поэтому-то 89001 и 89003 .

Ну и славно... И мне легче - не придется писать "телегу" корейцам...