Пауза перед остальным набором или ожидание длинного гудка

[jpbx]

Здравствуйте, ув. Поддержка!
Ситуация следующая.
Есть местное соединение по 3-х проводке.
Набирать надо в таком формате: 2-гудок-21-23456
Хотим сделать так, чтобы при наборе 2XXXX номер преобразовался бы в 2w1223456 и был отправлен в линию.
На Asterisk'e у нас действует такой шаблон:
exten => _2XXXX,1,Dial(DAHDI/2ww21${EXTEN})
и все работает прекрасно, астериск выдает в линию 2-ку, далее ждет 1 сек (w - 0.5 sec), и донабирает номер. В идеале ждать длинный гудок, но пауза также пойдет...

Изучал документацию к МС240, а также пытался сделать это через PbxAdmin - не нашел ничего.

Посоветуйте пожалуйста.
Спасибо.

[Aleksey_ts]

Здравствуйте!

Если я Вас правильно понял, то при наборе любого пятизначного номера, начинающегося на 2, станция должна отправить 2-ку в линию, дождаться ответа станции и отправить 1223456? Вызов при этом приходит со стороны VoIP и направляется в ТфОП?

[jpbx]

Да, все именно так.

[Aleksey_ts]

Добрый день!
Какой протокол сигнализации используется на стороне ТфОП?

[jpbx]

2ВСК R1.5, это MUX E1<->3СЛ

[Aleksey_ts]

Добрый день!
Опишите более детально задачу и причины ее постановки.
т.е. почему возникла потребность делать подобные задержки с набором цифр номера?

[jpbx]

Извините, немного попутал.
В 3-х проводную СЛ пауз давать не надо.
В обычную 2-х проводную АЛ линию.
Итого, схема:
АК24 -> АЛ8.
Номер: 2 пауза/гудок 21 12345
При этом сотрудник набирает только 12345.
Возможно вообще как-то паузу или ожидание длинного гудка зарядить?

[jpbx]

Итак, докладываю о промежуточных результатах.
1. Созвонился с поддержкой Eltex'a (Егор). Сходу решения не дали. Нашли в настройках АЛ параметр "Пауза до набора", но это оказалось не то. Егор обещал поднять у себя демо стенд. Завтра будем снова созваниваться.

2. Удалось сделать следующее. На 8АЛ линия с импульсным набором. После набора 8-ки выдает гудок и ждет остальные цифры. Так вот, если на 24АК поднять трубку, набрать 8, подождать, и донабрать остальные цифры, типа то, что надо. Т.е. она не ждет ввода всех цифр, а по первой цифре находит маршрут и посылает их в линию. При этом не важно, как происходит набор - в пульсе или тоне.

3. Схема такая: Телефон -> FXS -> ТАУ72 -> SIP -> TM.IP -> АЛ8. Пытаемся сделать то же самое, что и в случае с 24АК. Номер не проходит.
Набираем 8, шлюз прокидывает ее на 8 АЛ, происходит соединение, линия выдает длинный гудок. Далее DTMF'ом засылаем остальные цифры. Но набор их в линию не происходит, хотя станция явно их получает, это видно через trace call.
Но почему она в случае с аналогичной ситуацией с 24АК, когда с телефона DTMF'ом идет донабор, транслирует его пульсом в линию, в тот же DTMF с TM.IP не воспринимает?

P.S. Я все же буду настаивать на том, чтобы в правила преобразования номеров (called) был добавлен знак паузы. Тогда можно будет высылать номер в любом формате, и станция сама все преобразует и вдует в линию.

[Aleksey_ts]

Итак, докладываю о промежуточных результатах.
1. Созвонился с поддержкой Eltex'a (Егор). Сходу решения не дали. Нашли в настройках АЛ параметр "Пауза до набора", но это оказалось не то. Егор обещал поднять у себя демо стенд. Завтра будем снова созваниваться.

2. Удалось сделать следующее. На 8АЛ линия с импульсным набором. После набора 8-ки выдает гудок и ждет остальные цифры. Так вот, если на 24АК поднять трубку, набрать 8, подождать, и донабрать остальные цифры, типа то, что надо. Т.е. она не ждет ввода всех цифр, а по первой цифре находит маршрут и посылает их в линию. При этом не важно, как происходит набор - в пульсе или тоне.

3. Схема такая: Телефон -> FXS -> ТАУ72 -> SIP -> TM.IP -> АЛ8. Пытаемся сделать то же самое, что и в случае с 24АК. Номер не проходит.
Набираем 8, шлюз прокидывает ее на 8 АЛ, происходит соединение, линия выдает длинный гудок. Далее DTMF'ом засылаем остальные цифры. Но набор их в линию не происходит, хотя станция явно их получает, это видно через trace call.
Но почему она в случае с аналогичной ситуацией с 24АК, когда с телефона DTMF'ом идет донабор, транслирует его пульсом в линию, в тот же DTMF с TM.IP не воспринимает?

P.S. Я все же буду настаивать на том, чтобы в правила преобразования номеров (called) был добавлен знак паузы. Тогда можно будет высылать номер в любом формате, и станция сама все преобразует и вдует в линию.

Добрый день!
Совершаемый вызов, описанный в п.3, возможно не проходит потому, что сигналы тонального набора номера, передаваемые шлюзом, передаются не внутриполосно (в пакетах протокола RTP). Чтобы настроить подобную трансляцию цифр номера, необходимо в закладке SIP (confih--->sip) поставить DTMF Mode: inband.

[jpbx]

Настроил inband сигнализацию.
Установил уровни debug в TM.IP:
- SIP 5
- VAPI 2
- APP 2
На станции trace call l30

Делаю звонок с FXS адаптера на станцию, на 8-ку, после которой поступает длинный гудок.
Жму на телефоне, подключенном к FXS адаптеру, циферки..
В логах станции - ничего.
В логах TM.IP на каждое нажатие кнопки по строке:

Код: Выделить всё

Feb 14 19:33:07 10.0.10.2 tm.ip: (33:07.970) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0001.a7a2.abc0.0082.
Feb 14 19:33:08 10.0.10.2 tm.ip: (33:08.060) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.aac2.abc0.0000.
Feb 14 19:33:13 10.0.10.2 tm.ip: (33:13.010) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0001.4522.abc1.0085.
Feb 14 19:33:13 10.0.10.2 tm.ip: (33:13.190) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.4b62.abc1.0000.
Feb 14 19:33:13 10.0.10.2 tm.ip: (33:13.640) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0002.5922.abc1.0082.
Feb 14 19:33:13 10.0.10.2 tm.ip: (33:13.790) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.5e22.abc1.0000.
Feb 14 19:33:14 10.0.10.2 tm.ip: (33:14.150) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0003.6962.abc1.0082.
Feb 14 19:33:14 10.0.10.2 tm.ip: (33:14.300) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.6dc2.abc1.0000.
Feb 14 19:33:14 10.0.10.2 tm.ip: (33:14.690) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0005.7a42.abc1.0082.
Feb 14 19:33:14 10.0.10.2 tm.ip: (33:14.870) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.7fe2.abc1.0000.
Feb 14 19:33:15 10.0.10.2 tm.ip: (33:15.140) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0006.8802.abc1.0082.
Feb 14 19:33:15 10.0.10.2 tm.ip: (33:15.320) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.8da2.abc1.0000.
Feb 14 19:33:15 10.0.10.2 tm.ip: (33:15.530) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0008.945a.abc1.0083.
Feb 14 19:33:15 10.0.10.2 tm.ip: (33:15.710) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.9a22.abc1.0000.
Feb 14 19:33:16 10.0.10.2 tm.ip: (33:16.040) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0009.a422.abc1.0082.
Feb 14 19:33:16 10.0.10.2 tm.ip: (33:16.190) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.a922.abc1.0000.
Feb 14 19:33:16 10.0.10.2 tm.ip: (33:16.550) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.0000.b3c2.abc1.0082.
Feb 14 19:33:16 10.0.10.2 tm.ip: (33:16.730) [ 728] vapi: Event (Conn 67) Class 2, Type 3. Fn: 9041. Param (05): 0000.00ff.b962.abc1.0000.


Вывод: TM.IP видит DTMF, передаваемый inband. Но что с ним делать - не знает.

[jpbx]

Спасибо, новая прошивка с возможностью в ставки паузы в правила трансляции работает
Проблема решена.

Что касается вышеприведенного дебага, надо еще разбираться. Попробую позвонить на номер дозвона какой-то, и прогнать DTMF по всему пути. Проверю как из TAU.72 в TM.IP и далее в линию все прозрачно проходит.

P.S. Пользуясь случаем хочу выразить респект суппорту Элтекса - 3 дня потребовалось от постановки проблемы до получения прошивки. Круто.