Есть М11, необходимо сделать распределение вызовов по занятости.
Хотим реализовать схему : входящий вызов попадает в PLDN -- далее GHT(scl), в списке SCL будут внешние номера.

Будет ли работать перебор по занятости с перебором этих внешних номеров?

Есть М11, необходимо сделать распределение вызовов по занятости.
Хотим реализовать схему : входящий вызов попадает в PLDN -- далее GHT(scl), в списке SCL будут внешние номера.

Будет ли работать перебор по занятости с перебором этих внешних номеров?

а что мешает запрограммировать и посмотреть как оно работает?

а что мешает запрограммировать и посмотреть как оно работает?


Еще бы знать как это сделать...

Есть М11, необходимо сделать распределение вызовов по занятости.
Хотим реализовать схему : входящий вызов попадает в PLDN -- далее GHT(scl), в списке SCL будут внешние номера.

Будет ли работать перебор по занятости с перебором этих внешних номеров?

Скорее всего не будет. По крайней мере пару лет назад (решая подобную задачу подобным же способом) столкнулся с тем что поиск прекращается сразу же после первого "внешнего" номера в списке.

у меня работает если по ACOD рута, но беда в том что если из потока приходит USER BUSY то ничего дальше не происходит.. или мы об одном и том же?...

Угу. Я ж говорю - столкнулся с тем, что поиск прекращается... Ну т.е. бизи станция видит, но дальше по списку не ищет.

Будет ли работать перебор по занятости с перебором этих внешних номеров?

Не будет!

Не будет!
Гы...
Пару месяцев назад проверял на уровне тестового примера. Все сработало. Этот тестовый GHT до сих пор сидит в станции. Только что проверил снова.
В списке номеров структура <AC1><SPN>.
Транки IPTI (H323). T.e. рут SL1.

Задача была поднять серию на номерах софтсвича (который, увы сам серии не поддерживает). Поэтому пришлось список создать на CS1000, а номера в серии были IP-шные.

В общем работает. Скажите, что я сделал неправильно:D

В общем работает. Скажите, что я сделал неправильно:D

На EuroISDN релиза 25.40 не работало.

Завтра (главное не забыть) проверю данный функционал на 5.5 по SIP с FXS шлюзом. Самому интересно стало :)

На EuroISDN релиза 25.40 не работало.

Завтра (главное не забыть) проверю данный функционал на 5.5 по SIP с FXS шлюзом. Самому интересно стало :)
Но софтсвитч у нас стороннего производителя (Altertex). На v4.50 SIP был весьма оригинальным;), поэтому SIP абоненты у нас на стороннем сервере, прицепленном по H323.

надо попробовать через AC1 тоже может прокатит хотя... схема такая...
M11->M81->BCM50 везде SL1 GHT прописываю на M11(чрез ACOD не работает)

Гы...
...
В общем работает. Скажите, что я сделал неправильно:D
Не верю :)

тоже не работает...

Не верю :)
Прочитал ветку более внимательно. Дошло. Проблема с прекращением поиска после встречи с занятым номером.
Если в свойствах PLDN кода стоит HTYP RRB (выбор по кольцу), то набираешь снова и при следующем наборе попадаешь уже на другую линию, не застревая навсегда на занятой, как при HTYP LIN.
В общем серия "полуавтомат" получается.:confused:
Но кому сейчас легко...
Все равно абонент дозвонится.

Прочитал ветку более внимательно. Дошло. Проблема с прекращением поиска после встречи с занятым номером.
Если в свойствах PLDN кода стоит HTYP RRB (выбор по кольцу), то набираешь снова и при следующем наборе попадаешь уже на другую линию, не застревая навсегда на занятой, как при HTYP LIN.
В общем серия "полуавтомат" получается.:confused:
Но кому сейчас легко...
Все равно абонент дозвонится.

Да, это я так еще делал и на 25.40.

А я то уж обрадовался (слегка :) ), что данную фичу реализовали.... дезинформатор :)

Да, это я так еще делал и на 25.40.

А я то уж обрадовался (слегка :) ), что данную фичу реализовали.... дезинформатор :)
Здесь 2 момента:
1.Я всегда изничтожал опцию выбора каналов LIN, если можно было настроить выбор по кольцу (привычка еще с Panasonic`ов). Поэтому здесь тупо обошел засаду (в PLDN умолчание LIN).
2.В классическом Call Processing`е избегают процедуру автоответа/автооотбоя. Вспомните вечный вопрос, почему на CO`шках нет занятости даже при адресации вызова к занятому private абоненту. Т.е. здесь пришлось бы реализовывать занятие CЛ->BUSY->RELEASE->занятие другой СЛ и т.д. Разработчик не напрягся на этот геморрой и сделал "полуавтомат". Если бы было по умолчанию "RRB", вопросов меньше было бы.

....Разработчик не напрягся на этот геморрой и сделал "полуавтомат"....

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

Так что, что там думает разработчик... сложно представить. :D