На 11-12 CO-line подключен 2-канальный GSM-VoIP шлюз (addpack), без регистрации, только IP шлюза прописан в 133-й.
Шлюз "звонит" на станцию на номера 7013 и 7014, в 145-й выбрано Modify Using Flexible DID, а в 231, соответственно, рулится всё на дизу.

Проблема в том, что входящий gsm (на любой канал шлюза) занимает всегда 12 CO-line (при условии, что 11-12 свободны) и это как бы не проблема, если в шлюзе установлены карты одного оператора. В SIP Trunk Status Overview транк на шлюз одной строкой, COL Range 11-12.

А вот если операторы разные, и 11-я, 12-я линии разнесены в разные CO Line Group (и на них "рассчитывает" LCR - LDT/DMT), то получается ситуация, когда, например, звонок "как бы должен" прийти на 11-ю CO-Line (потому что он поступил на gsm-порт шлюза, который подразумевается на 11-й CO Line), но он приходит на 12-ю... И если в этот момент кто-то из внутренних абонентов решит сделать звонок, который LCR должен провести через 12-ю линию, то абонент получит "занято", хотя по факту порт на шлюзе (через который должны уходить звонки по 12-й линии) свободен...

Вопрос. Как в такой ситуации привязать входящий со шлюза на 7013 к 11-й CO Line, а на 7014 - 12-й CO Line ???

PS: сорри, может не очень в терминах объясняю, я вообще не АТС-ник... так, разобрался сам, вот для своей конторы и кручу...

PSPS: пока обхожусь тем, что в таких ситуациях объединяю 11-12 лини в одну группу, и уже внутри шлюза по маскам направляю на нужные порты, но это ж не серьёзно... ибо может быть кейс, кода в DMT будет альтернативная группа и до неё просто не дойдёт дело, т.к. споткнётся на первой, уйдёт в шлюз, а тот даст отбой и привет...
да и чисто академически заело - можно ли такое сделать ))

Организуйте линии СО в разные группы. Например, 11 линию СО в 01 группу, а 12 линию в группу 02. И дайте (к сожалению я не работаю с этими АТС, номера программ не знаю.в LDK-300 это прг.117) соответствующим абонентам доступ к каждой группе.

И как мне это поможет решить задачу? То что вы описываете я, в общем, и сделал. Но столкнулся с проблемой, которую описал выше... Вы пишите о том, что и так ясно/понятно...

Здесь вопрос шире... И что-то мне кажется, что решения может не быть, ибо вся идея цифровой телефонии в том, что место линий теперь надо мыслить потоками, из которых звонки приземляются на один из доступных портов, причем выбор порта из доступных происходит где-то на очень низком уровне...
Я смотрел трассировку - единственное чем отличаются звонки приходящие со шлюза, это номер адресата (7013, 7014), и о номере этом начинает идти речь, когда CO-порт уже выбран. Соответственно, выбрать порт в зависимости от номера получается что нельзя. Как если, например, в доме две лифта одинаковых с виду, а мы хотим, чтобы нас пустили в какой-то определенный, в зависимости от номера этажа, который мы назовём только после того как в этот лифт пропадём....

Речь о SIP? См. SIP Trunk Group в 133 программе. И надо прописать Registration User ID в 126, чтобы обозначить поля To 7013 и 7014.

Простите, а можно подробнее? Не совсем понял, что с чем связать нужно...

SIP User ID Attributes(126): Index 1 --> Registration User ID 1 = 7013, Registration User ID 2 = 7014.
SIP CO Attributes(133): CO11 --> SIP Trunk Group = 1, CO12 --> SIP Trunk Group = 2.
Как то так...

Получилось! Спасибо огромное!
...а я тут уже начал теории строить, всё оказалось так просто ))) Ну в смысле, что я не до конца как произошло, то что произошло, но хорошо хоть понял - что произошло )))

Добрый день!

Утекло конечно воды с тех пор, но опять возник вопрос, в той же конфигурации...
Почему-то перестал предложенный вами метод работать... Так и не понял почему...
Перестало работать (хотя работало, сам же писал, что "ДААА") вот в такой конфигурации:







где 192.168.100.195 - двухканальный GSM шлюз, от которого звонки приходят с ToHedaer 7013 и 7014 для каждой из линий. В такой конфигурации звонок всегда приходит на CO11.

Вот из лога шлюза, там точно видно, что меняется хидер:



Нашёл обходной манёвр, следующий:







Причём, Ring Route Type в 126-й пришлось поменять на MSN-DID CONVERSION(PGM145), чтобы звонок шёл куда надо (на DISA в моём случае), ибо именно в такой конфигурации, на сколько я понял, настройки из 126-й программы подтянулись и начали работать. До того, Ring Route Type находился в положении ID ASSIGNED STATION и никому этим не мешал, звонки и так прекрасно ходили на DISA, согласно 145-й и далее 231-й.

Совсем запутался... В принципе понял - почему оно работает сейчас. Но почему оно работало раньше и почему перестало работать - понять не могу... Каким образом SIP Trunk Group в 133-й (который может изменяться от 0 до 71, судя по подсказкам) связан с SIP User Index из 126-й (который от 1 до 140)? Если это одни и те же индексы, у них по идее и диапазон должен быть одним... Как оно вообще могло работать? Хотя справедливости ради надо сказать, что если ставить SIP Trunk Group в 0, то новая конфигурация тоже перестаёт работать. Видимо оно таки нужно...

Растолкуйте пожалуйста - где я что неправильно понял ???

Так прописаны в 126 программе Registration User ID 13 и Registration User ID 14?

В 126 Registration User ID 13 и 14 прописаны соответственнов виде 7013@192.168.100.195 и 7014@192.168.100.195?

В варианте, который перестал в работать в 126-й Registration User ID прописаны 7013 и 7014, соответственно:



В 133-й только SIP Trunk Group, соответственно 13 и 14. Registration UID Range в 133-й оставлял пустым, по крайней мере в прошлом году, когда совет получал, речь о нём не шла и как-то оно работало )

А надо 7013@192.168.100.195 и 7014@192.168.100.195!

Неа, так не работает, звонки с обоих линий шлюза на CO11 приходят.

Ни в какую не получается по-прошлогоднему сделать.
Только новый вариант, когда Registration UID Range в 133 прописываю, соответственно 13-13 и 14-14

В 133-й SIP Trunk Group?
Версия та же, что и в прошлом году была?

Да, в прошлом году так работало. вроде) Переписка выше - вы сказали SIP Trunk Group прописать, я прописал... )))
Теперь не работает...

добавляю в 133-й Registration UID Range (13-13 и 14-14) + фиктивные UserID и UserPassword в 126-й - работает )

А если для обоих линий 13-14?

Что значит фиктивные?

Версию не менял, только в другой VLAN перенёс шлюзы и станцию, но это ничего не меняет, ибо от старой сети в 102-й ничего не сталось...

Фиктивный в смысле что шлюз и станция напрямую без регистрации общаются. Где-то вычитал, что эти поля надо хоть чем-то заполнять... Но эт я сегодня заполнил, в прошлом году и сегодня (до использования Registration UID Range) они пустые были

Да нет, достаточно только Registration UID. Если Provision.

А так нельзя, в шлюзе карточки разных операторов. Соответственно CO-шки в разных CO-group, надо их застолбить жёстко, исходя из того какой ToHeader приходит.

А причем тут карточки разных операторов, шлюз то один и адрес у него один? Попробуйте 13-14! SIP Trunk Group как раз и столбят ToHeader.

Значит перебдел. В любом случае, когда вот так, то не работает:

Извините, 13-14 это в смысле в Registration UID Range ? Оно ж прекрасно работает, когда 13-13 и 14-14, работает как надо, каждый звонок на свою линию приходит.

Вопрос был в том, что вот в этом посте год назад ничего такого не было и всё было замечательно. Сегодня я уже добился нужного результата (как раз с помощью использования Registration UID Range), просто не могу въехать - как оно тогда работало.... Я тогда Registration UID Range не трогал вообще, он пустой был... Каждый звонок приходил на правильную CO-шку

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

"Так и должно" - это в смысле даже с пустыми Registration UID Range должно по 126-й находить index, потом его находить в SIP Trunk Group 133-й и приземляться на нужную CO?


Согласен что просто так не бывает, теперь буду ночь не спать - думать...
Что было... в шлюзе карточку одну заменил на другого оператора, соответственно одну CO-ку группу поменял... Но, что так, что так, до того СО-шки были в разных группах, и теперь в разных... Разве что раньше каждая СО-шка была единственным членом своей группы, а теперь одна CO-шка входит в группу, в которой есть другие СО, тоже шлюзы, но другой IP там... Ума не приложу - как это может быть связано...

CO11,13,14 - теперь в одной группе, но это, по идее, ничего не должно было изменить, вроде как... Только для исходящих, я так понимаю, но никак не для приземления входящего на нужную CO
13,14,15,16 - были в прошлом году, ничего нового...

А может 7013 и 7014 стали перехватываться кем-то и просто не доходить до 126-й чтобы "найти себя". Где-то ToHeader ему "отпиливают" и дальше уже как получится оно работает... Просто ещё странно то, что в прошлом году я жаловался на то что все звонки на СО12 валятся и "надо что-то делать"... А тут они теперь все на CO11 приходят... Точно что-то случилось )))

По-умолчанию DID-звонок в 145-ю приходит или куда?

Я был бы не я, если бы так просто сдался)))

Интерес - "почему работало, а теперь нет" не покидает...

Нашёл бекап, судя по дате - как раз через пару дней после моего поста "Спасибо, всё получилось, в прошлом году".

Развернул на Offline Web Admin, перелазит всё что мог - сравнивал...
В бекапе в 126-й в в 13-м и 14-м индексе в Registration User ID записаны, соответственно, 7013 и 7014, без @192.168...
В 133-й для CO11 и CO12 - Sip Trunk Group, соответственно, 13 и 14.

Всё, больше ничего... и работало ведь...
Кроме как перебросить АТС и шлюзы в другую сеть (в VLAN) больше ничего не делал существенного.

Может, настройки шлюзов?

Да нет, там тоже (кроме смены LAN) ничего не делал )
Не, ну очевидно, что причина есть какая-то... В общем, время сделало свое дело, я уже остыл - работает как надо с помощью указания Registration UID Range в 133-й и чёрт с ним)