Входящий trunk привзяка к CO-line Опции

[dtgeorge]

На 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 будет альтернативная группа и до неё просто не дойдёт дело, т.к. споткнётся на первой, уйдёт в шлюз, а тот даст отбой и привет...
да и чисто академически заело - можно ли такое сделать ))

[Dron]

На 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 будет альтернативная группа и до неё просто не дойдёт дело, т.к. споткнётся на первой, уйдёт в шлюз, а тот даст отбой и привет...
да и чисто академически заело - можно ли такое сделать ))

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

[dtgeorge]

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

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

[Dron]

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

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.
Как то так...

[dtgeorge]

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.
Как то так...

Добрый день!

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

PGM126

SIP User ID Index 13
Registration User ID: 7013
Authentication User ID: пусто
Authentication User Password: пусто
User ID Register: Provision
User ID Usage: OFF
Ring Route Type: ID ASSIGNED STATION

SIP User ID Index 14
Registration User ID: 7014
Authentication User ID: пусто
Authentication User Password: пусто
User ID Register: Provision
User ID Usage: OFF
Ring Route Type: ID ASSIGNED STATION

PGM133:
CO11
Registration UID Range: пусто-пусто
SIP Trunk Group: 13
CO12
Registration UID Range: пусто-пусто
SIP Trunk Group: 14

SIP Trunk Status Overview
Index Proxy Address Domain COL Range SIP Group UID Range State UIDSEL
1 192.168.100.195 192.168.100.195 11 - 11 13 0 - 0 Idle UID_Index_1
2 192.168.100.195 192.168.100.195 12 - 12 14 0 - 0 Idle UID_Index_1

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

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

Call TO <sip:7014@192.168.100.251:xxx>

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

PGM126

SIP User ID Index 13
Registration User ID: 7013@192.168.100.195
Authentication User ID: qweqweqwe - от фонаря, ибо без регистрации же ж
Authentication User Password: blalbabla - от фонаря, ибо без регистрации же ж
User ID Register: Provision
User ID Usage: ON
Ring Route Type: MSN-DID CONVERSION(PGM145)

SIP User ID Index 14
Registration User ID: 7014@192.168.100.195
Authentication User ID: qweqweqwe - от фонаря, ибо без регистрации же ж
Authentication User Password: blalbabla - от фонаря, ибо без регистрации же ж
User ID Register: Provision
User ID Usage: ON
Ring Route Type:MSN-DID CONVERSION(PGM145)

PGM133:
CO11
Registration UID Range: 13-13
SIP Trunk Group: 13
CO12
Registration UID Range: 14-14
SIP Trunk Group: 14

SIP Trunk Status Overview
Index Proxy Address Domain COL Range SIP Group UID Range State UIDSEL
1 192.168.100.195 192.168.100.195 11 - 11 13 13 - 13 Idle UID_Index_1
2 192.168.100.195 192.168.100.195 12 - 12 14 14 - 14 Idle UID_Index_1

Причём, 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, то новая конфигурация тоже перестаёт работать. Видимо оно таки нужно...

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

[Dron]

Добрый день!

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







где 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?

И надо прописать Registration User ID в 126, чтобы обозначить поля To 7013 и 7014.

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

[dtgeorge]

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

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

PGM126

SIP User ID Index 13
Registration User ID: 7013
Authentication User ID: пусто
Authentication User Password: пусто
User ID Register: Provision
User ID Usage: OFF
Ring Route Type: ID ASSIGNED STATION

SIP User ID Index 14
Registration User ID: 7014
Authentication User ID: пусто
Authentication User Password: пусто
User ID Register: Provision
User ID Usage: OFF
Ring Route Type: ID ASSIGNED STATION

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