Анамнез...
Был поток в город, 9ка из плана нумерации была удалена и забита в нетплан. Для выхода на м/г абоненты набирают 98-кодстраны-кодгорода. Конвертация делалась в LCR под требования необходимые прову.
Теперь появился VOIB, соответственно м/г хочется отправлять по IP.
Прописал в нетплане префикс 5 PSTN и IP для выхода на прова IP-телефонии.
По 5ке выхожу - все хорошо работает.
Задача как теперь выход на м/г сделать прозрачным для абонентов, чтоб колхоз в 150 абонентов не переучивать набирать на м/г по другому.
Пробовал через LCR, но вылазит 2 косяка:
1) Если напрямую задать в LCR CO-группу VOIB, то как задать IP-addr направления.
2) Если делать в LCR обработку INT и прописать подмену 98 на 5 как префикс набора и прицепить к нему набранный номер, то набор уходит на ip-провайдера, только 5 все равно остается в впереди. Настройка в нетплане Digit Repeat на это не влияет.

NetCO на VOIB прописаны как PSTN.

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

День добрый!

LCR для того и нужен, чтобы делать манипуляции с цифрами, т.е. в данном случае вы решаете проблему с вашим "колхозом" - какаие-то цифры добавляете, какие-то убираете и указываете на группу VOIB, что задана в 141 ПГМ, максимально уменьшая косяки в вашу сторону (естественно) со стороны "колхозников".

В ПГМ 324 вы указываете IP-шник направления для выбранного префикса (не более 4 цифр).
И в зависимости от требований на оконечом оборудовании уже выбирать NET или PSTN.
Не забудьте в 140 линии VOIB-а сделать ISDN и в 143 поставить на Overlap.

Конкретно можно расписать, если знать какие манипуляции с какими цифрами вам необходимо проделать.

Ага, идея понятна: 150-ти членам "колхоза" лениво запомнить, что для м\г нужно набрать 5 вместо 98, а форум пускай себе "мозги ломает"...
Вариант 1 не получится априори. Используя 2-ой вариант нужно в LCR DMT подменить 98 на 5, но поле CO Group (ПГМ222/5) оставить ПУСТЫМ (5-ка будет обработана как PSTN код для входа в Net Plan)... Попробуйте.

Попробовал, но счастья это сильно не дало..
Набираем префикс 98, слышим LCRовскую эмуляцию dialtone... После этого станция на набор не реагирует вообще...
Тип LCR попробовал и 12 и 13, тип CO-линий Enblock или Overlap тоже результата не дает.
Как только в DMT указываем CO-группу все начинает уходить, но с 5кой впереди.

Да, сразу забыл сказать прошивка 3.6Df.

Я проверял на версии 3.7 + ISDN (у меня сейчас нет возможности проверить для VOIB).
Пришлите мне файл конфигурации вашей станции - я "поковыряюсь" и попробую проверить более детально на версии 3.6Df...

Проверили совместными усилиями - это работает

если после подмены в DMT на код из Net Plan попытаться добавить ещё цифр, возникает ситуация с гудящим LCR`овским dialtone и отсутствием реакции на набор цифр

2 Starter:
В моем случае номера групп линий, используемых в 141 и 322-324 совпадают. Эту закономерность для себя я вывел давно - еще с версии 3.00 - и не задумываясь ею пользуюсь. Причем NET стараюсь запихнуть в 1-ую группу.
Поэтому ссылки префиксов на группы в 222 и 324 по любому совпадают и это все как-то работает (конечно логика в маршрутизации станции просматривается зыбко).

2 Harris:
Это хороший ход вы подсказали, за это сенкс...
Но...
Было бы не плохо, если бы в станции просматривалась маршрутизация более прозрачно, т.е. цепочка NumbPlan - LCR - Networking взаимодействовала и работала по жестким правилам и не только в версии 3.7 .
А сейчас получается есть правила для цепочек NumbPlan - LCR и NumbPlan - Networking, а цепочка LCR - Networking как то не просматривается.
Это не категоричное заявление, это мое пожелание, вызванное требованием задач ...

Но ... если корейцы уже созрели до этого решения и реализуют такую схему только в версии 3.7 - грошь цена всем их стараниям до сего момента. Это уже заявление категоричное и можете им так и передать

2 Alex_Q:
много слов смысл теряется...
пока не найдено отличий в работе LCR на 3.6 и 3.7

А вы еще не поняли, что в задачке спрашивалось - нет взаимодествия между LCR и Networking-ом.
Более того, в данном случае - одно другому мешает ().
А ведь это же таблицы всего-навсего.
И между ними сделать связи.
Что уже проще.



Или вы хотели сказать, что LCR сам по себе, а Networking сам по себе!..

Наверное не получится, ибо и там маршрутизация, и там - она же.



Но LCR опережает Networking по заложенному алгоритму - и как в этом случае быть, если нужно, как в данном случае, и то и другое ...
По каким правилам решать задачку?

задача решена, решение выложено, что не понятно?

Вообще-то я не вам вопрос задавал.

Но раз уж пошла такая возня, то на какой версии ПМУ задача решена?

3.6Df 3.6Am 3.7Aj

Это проверено?

Если это так, то спасибо богу и Harris-у - что какой-то выход найден.

Но вы должны понимать, что в общем проблемы такого характера все равно вернутся, пока не будет реализован алгоритм взаимодействия LCR - Networking.

Я бы объединил эти две таблицы для лучшей понмаемости

Речь не идет о каких-либо цепочках...
Есть определенный порядок приоритетов:
LCR (Internal) -> Numbering Plan -> Networking Codes.
И все.
Каждая функция задумывалась как отдельная часть алгоритма для разных целей.
Изощренных вариантов маршрутизации не предусматривалось.
Напомню, что пратически только в странах СНГ эти станции пытаются использовать "и в хвост, и в гриву" для тех задач, для которых они вообщем-то и не рассчитаны. При такой цене на станции уже имеющийся ее функционал можно принимать как благо...
Вот Вы, например, согласны будите платить в 2 раза больше за расширение возможностей по маршрутизации??? Думаю, что нет...
Изначально выбранная структура софта не позволяет легко и в полной мере внедрить многое из того, к чему сейчас появляется интерес. А глобально менять ПО - это уже разработка новой станции. Ну, это все ИМХО.
Да, постепенно функционал обновляется, накапливается понимание российских задач и требований. Но... Россия- не единственная страна, куда поставляются эти станции. И не имеет смысла упрекать их в отсутствии стараний. Старания-то есть, но не всегда приоритет отдается удовлетворению российских потребностей...ИМХО.

Да, здесь я соглашусь - это больше "переход хода", но как бы там ни было - а взаимосвязь есть, образно я назвал ее цепочкой.



Но ведь это уже треугольник вырисовывается, а внутри ядро. Ну вот и пусть корейцы поднатужатся, и сделают код оптимальнее и меньше по объему - результат превзойдет ожидания.


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



И правильно думаете - потому как в цену изначально закладывается модернизация и улучшение станции...


А я лично согласен на смену структуры софта, лишь бы это не касалось смены железа и улучшило операбельность станциию. Или если смена, то не существенная - на уровне ПМУ. Могу даже на тест пойти...
А насчет нового продукта - AVAYA тоже поменяла платформу. Ну и что имеют теперь? Сбыт увеличился? Хотя не мне судить ... что их подтолкнуло к этому шагу.


Шо вы о корейцах так печетесь - мы их не нагибаем, мы их подганяем...

Да, действительно Россия не единственная страна, куда поставляются эти станции. Но!!! Так уж повелось,что корейцы прислушиваются, harris, именно к твоему мнению, от имени России, так, что не прибедняйся!! Так уж сложилось, что от того, что ты напишешь ТУДА, будет зависеть очень многое!!! На самом деле, то, что для тебя - РАБОТА, для многих - НАДЕЖДА!! Поверь, то, что поставлятся в Европу в их стандарте, довольно слабо подходит для России... И уж я, поверь, достаточно хорошо это знаю! Здесь вопрос не исчерпывается сменой страны в настройках. Приходится потом много думать.... Извени, если что не так... Ты многое для всех нас УЖЕ сделал. Не останавливайся...

Целиком и полностью согласен и присоединяюсь к пожеланию. Работы то еще - не початый край... И хорошо, когда есть обратная связь

Мужики!!! Коллеги!!!
Спасибо, конечно, за добрые слова, но ей-богу не нужно преувеличить ни мои скромные возможности, ни "заслуги перед партией и правительством"... Давайте без дифирамбов.
Уверяю Вас, в действительности же и от меня и от М. Жабина мало что зависит (естественно, если говорить про LDK, а не про CS1000. В отношении CS1000 почти все в руках Михаила). В большей степени все определяется планами самих разработчиков. А мы же чаще всего выступаем в роли "дятлов", долбящих им про одно и то же в течении достаточно долгого времени. Увы, но это так и есть. У меня сложилось мнение, что чем дальше, тем разработчикам сложнее вносить в софт значительные изменения, поскольку метод "заплаток" уже не позволяет добиться нужных результатов. По уму надо менять ПО глобально в части ядра системы (Call Handling - обработчик вызовов), а это нереально. Поэтому и приходится довольствоваться "заплатками", если их еще возможно "вклеить"...
Что касается внедрения новых возможностей, то необходимо периодичеси и настойчиво доводить до разработчиков ваши (вернее наши) требования, предложения и пожелания. Тут как раз очень важно и Ваше активное участие. Требуются совместные усилия российского представительства LGN, дистрибьютеров, дилеров, инсталляторов.
Таковы дела, и с каждым годом они становятся еще таковее...

А что, ARIA SOHO тоже на старом ядре построена?
Call Handling - я так понимаю, лишь часть ядра, но наиболее ответственная, а править надо базу ядра...
Но не в этом суть.
Если ARIA SOHO другое ядро применительно к новому железу, но работающее со старыми базами - то наверное, можно обновить ядро и для систем LDK?

Что касается ARIA SOHO - да, "железо" (элементная база) новое, а в качестве ПО используется адаптированная версия от ipLDK. Так что ядро и все остальное то же. Но как раз в отношении станции Aria SOHO, не имеющей ни ISDN, ни VOIP, ИМХО, данного софта, пожалуй, достаточно (в отношении маршрутизации вызовов)...