![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() ![]() |
![]() |
![]()
Сообщение
#21
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
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. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#22
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Да, все сработало. Спасибо, harris, за очередную помощь. А этого нет в документации или я просто не смог найти?
|
|
|
![]()
Сообщение
#23
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
Да, все сработало. Спасибо, harris, за очередную помощь. А этого нет в документации или я просто не смог найти? Да, есть. Видимо, не там искали. При переводе доки "Описание и руководство по использованию функций iPECS LIK" я специально отредактировал п.4.15.2, добавил туда соответствующее пояснение и таблицу. См. прикрепленный файл с выдержкой из доки. Возможно, что это получилось не слишком четко.. Ну, что ж, прошу пардону. ![]() Все идентификаторы типа номера, кроме Unknown (т.е International/National/Sudscriber) требуют ссылки на Таблицу префиксов (CLIP Table). Если же ссылка на индекс (CLIP/COLP Table Index) не указана, а прописано = 50 (Station CLI), то тип номера может быть только Uknown. В-общем, у меня есть алиби... ![]()
Прикрепленные файлы
-------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#24
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Помнится в документации на 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 звук вызовов нормальный. |
|
|
![]()
Сообщение
#25
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 6510 Регистрация: 20.4.2009 Из: г. Фрязино Пользователь №: 13158 ![]() |
И совсем маленький вопрос. Что-то я "накрутил" и при вызове на номер 3ххх (через поток) в трубке зуммер гудит непрерывно, как будто бы ждет донабора, но вызов проходит нормально и трубку снимают. Через SIP звук вызовов нормальный. Через SIP на станцию поступает 180 Ringing, и LIK сам генерирует КПВ, а с потоком я дела не имел.. -------------------- "Хотите никогда не работать? Ищите работу по душе!" американская поговорка
Но если любимых работы две - это как большой спорт, увлекшись можно и надорваться.. |
|
|
![]()
Сообщение
#26
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Через SIP на станцию поступает 180 Ringing, и LIK сам генерирует КПВ, а с потоком я дела не имел.. С гудком, кажется, разобрались: провайдер, похоже, каким-то хитрым отправляет звонок на свою DISA - то есть если начать набирать цифры, то гудок пропадает. А транзит звонков через станцию можно настроить без лицензии NET? |
|
|
![]()
Сообщение
#27
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
С гудком, кажется, разобрались: провайдер, похоже, каким-то хитрым отправляет звонок на свою DISA - то есть если начать набирать цифры, то гудок пропадает. А транзит звонков через станцию можно настроить без лицензии NET? Можно. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#28
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Можно. Посмотрел красивую блок-схему на странице 15 Руководства по программированию iPLDK. Если обработать транзитный звонок в MSN (PGM202), указав Flexible DID (PGM231), то на внутренний номер его отправить можно. Но в PGM231 указать номер не принадлежащий АТС не получается. Указание NET-номера не срабатывает (отбой по тайауту и настройка PGM322 и PGM324 не помогает). Если не обрабатывать звонок в MSN, то звучит сообщение: "Неправильно набран номер".harris, можно попросить описать как надо обрабатывать этот вызов? |
|
|
![]()
Сообщение
#29
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
Посмотрел красивую блок-схему на странице 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 означает обрабатывать коды, следующие после набора кода доступа к исходящей линии. С внешней линии тоже прийти код доступа к исходящей линии (транзитный код, например). -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#30
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
Мдя.... Я пока не нахожу приемлемого решения конкретно для вашей ситуации.
Надо признать, что станция LIK для таких транзитов плохо приспособлена. Увы. Пока получился только вариант с использованием ПГМ252 (CO Call Rerouting). И то с нюансами. Продолжим уже на след. неделе. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#31
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 15017 Регистрация: 19.6.2009 Из: г. Тула Пользователь №: 13420 ![]() |
А если c помощью MSN отлавливать номер и направлять на SPEED ячейку, в которую прописан тот же самый номер и указана нужная CO Group для набора номера?...
Хотя, если использовать CO Call Rerouting, тоже придется вызовы на SPEED ячейки направлять. Очень похожие варианты получаются. -------------------- Вот смотрю я на вас и думаю: ещё выпить, или вы мне уже нравитесь? Анекдот
|
|
|
![]()
Сообщение
#32
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Мдя.... Я пока не нахожу приемлемого решения конкретно для вашей ситуации. Надо признать, что станция LIK для таких транзитов плохо приспособлена. Увы. Пока получился только вариант с использованием ПГМ252 (CO Call Rerouting). И то с нюансами. Продолжим уже на след. неделе. Самое обидное, что решение это временное, до момента пока все удаленные офисы не будут переключены напрямую на LIK. Но когда это произойдет - неизвестно. А если c помощью MSN отлавливать номер и направлять на SPEED ячейку, в которую прописан тот же самый номер и указана нужная CO Group для набора номера?... Хотя, если использовать CO Call Rerouting, тоже придется вызовы на SPEED ячейки направлять. Очень похожие варианты получаются. Отлично! Через SpeedDial сработало! Правда, придется каждый номер вручную прописывать, а я даже не знаю их полного списка (ориентировочно их там штук 200). |
|
|
![]()
Сообщение
#33
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 15017 Регистрация: 19.6.2009 Из: г. Тула Пользователь №: 13420 ![]() |
Отлично! Через SpeedDial сработало! Правда, придется каждый номер вручную прописывать, а я даже не знаю их полного списка (ориентировочно их там штук 200). Использовали бы Н.323, не было бы таких проблем! -------------------- Вот смотрю я на вас и думаю: ещё выпить, или вы мне уже нравитесь? Анекдот
|
|
|
![]()
Сообщение
#34
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
Самое обидное, что решение это временное, до момента пока все удаленные офисы не будут переключены напрямую на 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ХХХ). Подождите пару дней, может быть корейцы быстро исправят баг, тогда не придется присылать лишние префиксы. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#35
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Пока получился только вариант с использованием ПГМ252 (CO Call Rerouting). И то с нюансами. Продолжим уже на след. неделе. Через PGM252 тоже заработало (указываю группу линий, вызываемый номер, и 89+группа линий+вызываемый номер, тип NET). Но для каждого внутреннего номера требуется своя запись. В Compare Digits можно прописать групповую маску, например, 3*** или 2***, но CO + Rerouting Number можно указать только конкретный номер. |
|
|
![]()
Сообщение
#36
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Я проверял ваш вариант с использованием ПГМ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 этого бага нет! Еще раз ОГРОМНОЕ СПАСИБО! |
|
|
![]()
Сообщение
#37
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 15017 Регистрация: 19.6.2009 Из: г. Тула Пользователь №: 13420 ![]() |
Через PGM252 тоже заработало (указываю группу линий, вызываемый номер, и 89+группа линий+вызываемый номер, тип NET). Но для каждого внутреннего номера требуется своя запись. В Compare Digits можно прописать групповую маску, например, 3*** или 2***, но CO + Rerouting Number можно указать только конкретный номер. Т.е., все равно все номера прописывать? Как и писал выше, очень схожие варианты получились. -------------------- Вот смотрю я на вас и думаю: ещё выпить, или вы мне уже нравитесь? Анекдот
|
|
|
![]()
Сообщение
#38
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
Т.е., все равно все номера прописывать? Как и писал выше, очень схожие варианты получились. Я не проверял на 5.5Gt (у меня на тестовой станции еще осталась предыдущая - E.5Go). Я не понял, зачем Вы прописываете каждый номер в отдельности?? У Вас должно быть так (только номера транков подправить): Compare CO Group: 1 (откуда поступает вызов) Compare Digits : 2 (префикс (первая цифра номера)) CO + Rerouting Number: 8032 (на какой транк отправить+ тот же самый префикс) -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#39
|
|
![]() Ветеран форума ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 353 Регистрация: 27.2.2009 Из: Москва Пользователь №: 12941 ![]() |
Т.е., все равно все номера прописывать? Как и писал выше, очень схожие варианты получились. В варианте harris-а (PGM252 добавил две записи: 3 3 890013 NET и 1 2 890032 NET) все заработало без прописывания каждого номера. В пятницу просмотрел всю документацию, но эту полезную функцию не увидел. Compare CO Group: 1 (откуда поступает вызов) Compare Digits : 2 (префикс (первая цифра номера)) CO + Rerouting Number: 8032 (на какой транк отправить+ тот же самый префикс) Да-да. Именно так и заработало. ![]() |
|
|
![]()
Сообщение
#40
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
В варианте harris-а (PGM252 добавил две записи: 3 3 890013 NET и 1 2 890032 NET) все заработало без прописывания каждого номера. В пятницу просмотрел всю документацию, но эту полезную функцию не увидел. Да-да. Именно так и заработало. ![]() Ну и славно... И мне легче - не придется писать "телегу" корейцам... ![]() -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]() ![]() |
Текстовая версия | Сейчас: 6.9.2024, 22:41 |