Есть сеть из двух кораллов(центр-вынос), соединеных по UGW. Выход в город через поток. Нумерация общая с городской. На "центре" кроме потока имеется также плата аналоговых ЦО (8ТС). Необходимо подать на 8ТС группу городских номеров, а на выносе их забрать, т.е. коралы работают просто как голосовые IP-шлюзы, как это сделать оптимальнее? Если аналоговые транки, я могу тупо прописать для входящих на SLT в network, то для исходящих звонков транки не принимают тип-network...Вот сижу туплю, поможите....

Для исходящих на удалённой стороне тебе надо через LCR прописать. У тебя есть элемент для network (см. node, 1). Сделай похожий элемент и диалсервис. Придумай какой нить префикс (например 8495), добавь к существующему ROUTING ACCESS в LCR,5 строку с указанием на новый элемент (строка содержит 8495x, где x номер набираемый через 8TC, укажи кол-во цифр в номере с учётом префикса). В новом DialService в качестве DIAL_FILTER добавь правило для обрезки префикса и добавления номера транк группы для 8ТС прописанной на удалённой стороне (например 89), в итоге вида [8495]89.
Теперь, если у тебя д.Гадюкино ROUTING ACCESS 9, хочешь набрать номер 1234567 в Моске, где установлена 8TC
через IP->8TC:
Набираешь 9 8495 1234567, в IP уйдет 89 1234567
Для межгорода придётся создавать ещё пары из диалсервисов и элементов, только чтоб паузы добавить в DIAL_FILTER.
Примерно так, думаю. Пробуйте.
Если LCR не описан, то начинайте сразу с DIALSERVICE, разрешите в COS прямой набор DIALSERVICE DIRECT_DIALING_ON_DIAL_SERVICE-Y, для удобства переименуйте свободный DIALSERVICE в 8495
Либо, можно добавить новый network номер совпадающий с номером транк группы 8TC на удалённой стороне. На удалённой стороне можно продублировать номер транк группы в что нить более удобное не конфликтующие с NPL на обеих АТС.

Префиксы сильно не желательны, да и с диалсервисами проблемка, маловато их у меня.... Станции работают в структуре ГТС, с городской нумерацией, а вот серия номеров(которую надо загнать) не соответствует узлу, совсем из другой оперы. Еще очень важно, что бы каждый номер SLT выноса, соответствовал и был жестко привязан к транку на 8ТС, входящие и исходящие, только через свой аналоговый транк. Вот при входящих проблемы быть не должно. Думаю как реализовать прямой набор номера транка в сети, сразу после поднятия трубки на SLT, но здесь опять будет минус, при наборе внутреннего(внутри сети) номера, получается нерациональное использование ресурсов потока и UGWканалов.

Ну так ДРУГАЯ ОПЕРА и подразумевает префикс. Или опишите подробнее цель задачи. Привязка абонента к номеру линии наводит на мысль, предоставления номера АТС находящейся не в вашем ведоме. Так хотят номер с другой АТС, будут тогда соседу через "Китай" звонить. Ставьте абоненту HOT_ST_IMM на транк центральной АТС. Этот номер транка можно описать как network или LIB, если dialservice неудобен. В любом случае придёться изыскать в NPL допустимое свободное сочетание цифр. абононент не заметит ничего, так как автонабор при поднятии трубки. На центральной АТС, на приёме можете фильтр поставить во входящем dialserv или искать такое же сочетание цифр для транка.
Если обучить абонента, то можно и HOT_ST_DELAY
использовать, т.е. пока таймер не вышел можешь успеть локального набрать, чуть промедлил, считай ты уже абонент другой АТС. Желательно чтоб на слух ответ станци отличался.
Либо цифровик поставить и prefer использовать вместо HOT_ST_IMM. :)
Пишите пример в цифрах, иначе будем долго челночить форум, пока поймём идею сего.

Предварительно решил вопрос при помощи HOT_ST_IMM, не очень рационально, но позволяет съэмитировать работу обычного голосового шлюза, что на предварительном этапе пока достаточно. Далее думаю изыскать способ, приписать как то транкам возможность работать с network slt как с исходящими(в режиме обычных SLT), если это еще как то возможно.

geg пишет
. Далее думаю изыскать способ, приписать как то транкам возможность работать с network slt как с исходящими(в режиме обычных SLT), если это еще как то возможно.
Понять бы только, что это значит? )

Что именно не работает если используется номер network абонента, а не физический slt порт? Какую функцию надо реализовать для исходящей связи абонента network?

Есть сеть из двух Нод 390 и 391. 391 центральная, на ней установлены платы аналоговых транков 8ТС, на 390 установлены платы SLT. Номера SLT в NPL 391ой прописаны как Network 390 ноды. На каждом транке 8ТС резервация для входящих прописана для соответствующего в NPL network номера. А вот при прописке в транке для исходящих, тип network неподходит, матерится на тип...

geg пишет
На каждом транке 8ТС резервация для входящих прописана для соответствующего в NPL network номера. А вот при прописке в транке для исходящих, тип network неподходит, матерится на тип...
Где это резарвация для входящих? D.I.L. что ли вы имели ввиду?
А зачем вам для исходящих RSRVD_TO заполнять? Если у Вас эксклюзивное занятие по HOT_ST_IMM. Для ограничения доступа другим абонентам: Выделите на 391 транк в отделную транк группу оставьте к ней доступ только для cos10(cos транков по дефолту). Так из абонентов 391 его никто не сможет занять. Ну а для защиты от хитрых абонентов 390 придеться номер транка набирать не как network, а как PRIV_LIB (номер транка+транкгруппаIP). И уже эту личную (для разрешенного абонента) библиотеку в параметре HOT_ST_IMM этого абонента. Тем более через библиотеку не придёться изыскивать свободные номера в NPL.
Как защитить от набора конкретные номера network сразу не могу придумать.

Выявилась новая проблема, после прокидки по HOT_ST_IMM, на аналоговый транк, на транк попадаем, вроде все нормально, но при наборе городского номера(хоть через тон, хоть через Импульс), правильно дозвониться получается только с третьего - четвертого раза, постоянно лезут ошибки набора, как правило последняя цифра. Например, попав на транк набираем номер 220-345, а ГТС проключает на 220-349, либо вообще до конца номер набрать непозволяет, еще в процессе набора дает отбой.... Сначало подумал на ДТМФ передатчик, но переключив транк на Импульс, ситуацию не улучшил.... При этом, с виртуальными(потоковыми транками проблем нет).

Я предполагаю, что СЛ ГТС воспринимает как тоновый, так и импульсный набор. Тоновый набор от аппарата идёт тут же, в паузах между импульсами. При тоновом наборе то же самое: сигналы идут как с АТС (начало) так и с аппарата. Попробуй разрешить набор по СЛ в тоне, а "Горячую линию" сделай на ячейку библиотеки, где ничего не прописывай для набора а только поставь в нужном месте транк или транкгруппу. В этом случае набранная цифра или весь номер (если быстро набирать) сначала "буферизуется", а потом по истечении межцифрового таймера выдаётся в линию

А можно без библиотек, забуферизировать на самом транке?
Например создать группу линий, и для этой группы установить Дайлингметод - енблок?

Про такое не слышал. Попробуй как я написал и сообщи. А что, проблема с библиотеками?

Например создать группу линий, и для этой группы установить Дайлингметод - енблок?

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

Спасибо! Остаются толькл библиотеки, блин не удобно, хотел удалено попробывать, но придется ехать....

Хрень получается какая то, вообщем что через библиотеку, что просто через горячую линию, на транк попадаю, а дальше ни тон ни импульс не проходит(проходит очень редко), постоянный ответ ГТС идет. Причем набор не проходит именно между моими узлами. Узлы работают через UGW.

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

Если предположить, что набор DTMF выполняется для MGCP в голосовом спектре, будет недурно оставить для cos аппаратов только G711 (фрэйм 10мс). Если ширина канала IP позволяет (это займет порядка 90кБит/с на одно соединение в одном направлении). В результате гарантия на DTMF, гарантия на факс, максимально хорошее качество голоса, максимальное количество IP->АТС соединений (больше чем для G729/723 в 2-4 раза).
В самом крайнем случае Root 0 1 4 (усиление на dtmf)

Чтоб проверить поможет ли буферизация номера, пробуй фиксированный номер набирать запрограммированный как PUB_LIB

Вообщем ни буфер, ни подъем уровня DTMF,ни переключка исключительно на G711 не решили задачи. Помогло включение во Фьючерсах HOT_TK_IMM на транке, при этом транк включается только с довольно приличной паузой, т.е. снимаю трубку и тишина на несколько секунд, потом только ответ станции, номер вроде стал набираться стабильно. Как уменьшить эту паузу? Еще не могу поднять усиление голоса, пытался поканально и сразу для всех, что то неменяется, кстати какие каналы я должен выбрать, если у меня на одной стороне SLT, на другой аналоговый транк, а между ними UGW. Менял на канале SLT-IP_Keyset(просто UGW нет) на одной стороне и LS/GS_TRK-UGW на другой. Заметил что передача голосо тоже слабовата, нужно усилисть....

Несколько соображений.
UGW у вас работают енблоком, а вы хотите набирать оверлапом по 8Т, это не выйдет (только тоналиником внутри голосового канала, а ГТС уже его распознаёт - это у вас и происходит). Если вы уж вышли на двухпроводку, то всё, никакие цифры UGW не пошлёт.
Делайте енблок на двухпроводках (применимо!), убирайте хоты, желательно сделать нормальную схему через LCR. Если ГТС понимает тон, то будет достаточно быстро.
Доступ к группе этих двухпроводок ограничивайте через COSы на центральной и TOLL на выносе, зарезервировать транки в TRK,0 возможно только за локальными портами.

На каком транке то вы HOT_TK_IMM поставили? Что прописали туда?
Может E0 добавить в конце номера. Хотя пока не пойму, про какой транк идёт речь. Ведь надо набирать через транкгруппу UGW номер CO транка на головной АТС. Сомнительно, что на IP транк можно функцию HOT_TK_IMM поставить.
Имейте ввиду, понятия RCV и TRX употребляются всегда относительно абонета, а не относительно порта станции. Поднимая RCV на СО вы увеличиваете усиление в сторону абонента ГАТС. Поднимая RCV на порту SLT вы поднимаете усиление в сторону порта SLT.

valeryk пишет
Для двухпроводок не применимо.
Прошу прощения, проверял не совсем правильно: в созданной для проверки транкгруппе был выставлен параметр qsig=y, поэтому не разрешался enblock , когда прописывал в эту группу двухпроводку.