Имеются две АТС: LDK-300, в которой две платы потока (одна для входящего города, вторая для соединения со второй АТС). Вторая АТС LDK-100 имеет одну плату потока (для соединения с первой АТС).
В ПГМ 320 NET Enabled, в ПГМ231 Net transfer Mode тип Reroute.
Становятся ли общими ресурсы голосовой платы VMIB, которая находится в LDK-300 (выход в город через эту АТС).

Проблема c VMIB.
Город по потоку попадает на сообщение №1 VMIB (первой транзитной АТС LDK-300), после чего если номер не набран попадает REROUTом на группу 621 (группа уже из второй АТС LDK-100). Это все работает.
Но у нас задача нетривиальная: если все телефоны группы заняты, надо чтоб звучало другое сообщение №2. Тестировали, выставляя необходимые параметры группы. Не работает. Если же группа является группой той же самой АТС (LDK-300), то все работает.
Примечательно, что если ставить в параметрах группы (это группа UCD) внутреннюю музыку на удержании (MOH), она работает, только если звонить на группу со своей станции (которой эта группа принадлежит). Это наводит на мысль, что покупка второй платы VMIB для LDK-100, не исправит ситуацию: сообщениие, заданное в пгм191 в параметрах UCD, будет работать только при вызове этой группы с той же самой АТС (с LDK-100), а если на эту АТС попали транзитом с первой (LDK-300), то ничего не нудет работать.


Город (ISDN)-->LDK-300 (VMIB, сообщение)-->при ненаборе внутреннего номера транзит на LDK-100 (UCD группа 621)--> при занятости группы VMIB LDK-100 (другое сообщение).

Вот так нам надо. А еще лучше с одной платой VMIB:
Город (ISDN)-->LDK-300 (VMIB, сообщение 1)-->при ненаборе внутреннего номера транзит на LDK-100 (UCD группа 621)--> при занятости группы VMIB LDK-300 ( сообщение 2).

Выходит, кроме номеров, никакие другие ресурсы первой АТС не становятся общими??? Или что-то можно изменить в параметрах?

Кто-нибудь на практике тестировал подобный случай?
В файле презентации о QSIG написано только про Centralized VMS. Но это голосовая почта. А как быть с сообщениями?

Проблема с Redial.
Не работает Redial по транзиту, т.е. на LDK-300 работает, а на LDK-100 - нет.
Если бы было неправильно прописано, вызовы в город вообще бы не проходили. Правильно ведь.
Я вот только думаю:
стоит галочка Digit Repeat. Похоже она служит для повторения 9-ки, т.к. эта LDK-100 соединена с городом через другую LDK-300. Может этот пункт некорректно отрабатывается именно при redial?

Номера пролистываются на экране, но при попытке нажатия Hold пищит системник, картинка не меняется, вызова не происходит, короткие гудки.
На аналоговом телефоне (в том числе и трубках DECT) или системнике при попытке набора кода доступа к этой функции короткие гудки.

Подробнее здесь http://bestann.livejournal.com/9017.html

Пока никто не может дать никакого ответа. Посылала письмо в Корею- тоже ноль реакции.
Может кто-то из гуру что-нибудь подскажет?

неужели никто не знает? Хотя бы насчет Redial:confused:

1. Объединение станций подразумевает создание единого плана нумерации, но вовсе не полное объдинение ресурсов этих станций. Для вашей задачи нужно использовать платы VMIB в каждой станции. Т.е. поддержка речевыми сообщениями должна выполняться непосредственно в той станции, где этот вызов в данный момент обрабатывается.
Речевые сообщения внутри группы воспроизводятся вне зависимости от того, какой вызов принимается: внешний или внутренний.
2. Функция Redial действительно работает некорректно (проще говоря - не работает) при организации исходящей связи через сетевые таблицы или LCR. Разработчики давным-давно поставлены в известность о наличие этой проблемы, но пока ничего не изменилось - ссылаются на трудности в реализации фунции Redial для случаев Networking и LCR.
Придется ждать...

Ну, надеюсь, я успокоил... :)

Ладно, пусть ресурсы VMIB не становятся общими. Тогда подошел бы вариант с музыкой на удержании. Но вот незадача: для UCD-группы она тоже не работает, если эта группа находится в другой АТСке. Проще говоря, музыка на удержании не передается по транзиту (QSIG). Мы слишим музыку только если звоним на группу с той же АТС :( Это тоже некорректная работа Лыж?

И еще плохо, что в группу нельзя добавить номера с другой АТС (или как в НЭКе например выкрутиться с виртуальными)- я пробовала, но не получалось. Тогда бы можно было с одной VMIB.

Повторяю: объединение станций подразумевает создание единого плана нумерации, но вовсе не полное объдинение ресурсов этих станций.
Это касается и музыки на удержании (MOH) - это ресурс только отдельной АТС, а не сетевой. И потом, а зачем нужно MOH передавать по QSIG в другую станцию???? Зачем канал держать все время занятым под MOH??? Чтоб только была экономия на муз. источнике??? Или я что-то не так понял?
К чему здесь упреки в некорректной работе станции LG??? А LG разве где-то обещали реализацию такой функции???
Да, нельзя в HUNT-группу прописывать абонентов другой станции. Если бы LDK могла выполнять это (и многое другое), то она, наверное, и стоила как NEC...

>>Объединение станций подразумевает создание единого плана нумерации, но вовсе не полное объдинение ресурсов этих станций. Для вашей задачи нужно использовать платы VMIB в каждой станции. Т.е. поддержка речевыми сообщениями должна выполняться непосредственно в той станции, где этот вызов в данный момент обрабатывается.

т.е. чтоб это полноценно работало, нужно докупить вторую плату VMIB (или AIIB), и на обоих платах записать одинаковые сообщения ?

>> Функция Redial действительно работает некорректно (проще говоря - не работает) при организации исходящей связи через сетевые таблицы или LCR.
Придется ждать...

А ориентировочно как долго ждать ? Месяц, полгода, год, два ?

KAPACb пишет
>>т.е. чтоб это полноценно работало, нужно докупить вторую плату VMIB (или AIIB), и на обоих платах записать одинаковые сообщения ?

>> А ориентировочно как долго ждать ? Месяц, полгода, год, два ?

1. Да, каждая станция в данном случае должна быть обеспечена собственной речевой поддержкой (платой VMIB/AAIB) и собственными системными сообщениями...
2. Насчет ожидания - это вопрос не ко мне (я на тему Redial писал в Корею давно тому назад), задайте его представительству LG. Или пишите запросы своему своему поставщику (дистрибьютеру). Чем больше будет запросов, тем больше надежды на результат...:)