Страница 1 из 1
Пауза перед остальным набором или ожидание длинного гудка
Добавлено: 31 янв 2011 23:54
jpbx
Здравствуйте, ув. Поддержка!
Ситуация следующая.
Есть местное соединение по 3-х проводке.
Набирать надо в таком формате: 2-гудок-21-23456
Хотим сделать так, чтобы при наборе 2XXXX номер преобразовался бы в 2w1223456 и был отправлен в линию.
На Asterisk'e у нас действует такой шаблон:
exten => _2XXXX,1,Dial(DAHDI/2ww21${EXTEN})
и все работает прекрасно, астериск выдает в линию 2-ку, далее ждет 1 сек (w - 0.5 sec), и донабирает номер. В идеале ждать длинный гудок, но пауза также пойдет...
Изучал документацию к МС240, а также пытался сделать это через PbxAdmin - не нашел ничего.
Посоветуйте пожалуйста.
Спасибо.
Добавлено: 01 фев 2011 10:23
Aleksey_ts
Здравствуйте!
Если я Вас правильно понял, то при наборе любого пятизначного номера, начинающегося на 2, станция должна отправить 2-ку в линию, дождаться ответа станции и отправить 1223456? Вызов при этом приходит со стороны VoIP и направляется в ТфОП?
Добавлено: 01 фев 2011 16:15
jpbx
Да, все именно так.
Добавлено: 02 фев 2011 11:45
Aleksey_ts
Добрый день!
Какой протокол сигнализации используется на стороне ТфОП?
Добавлено: 04 фев 2011 08:39
jpbx
2ВСК R1.5, это MUX E1<->3СЛ
Добавлено: 04 фев 2011 13:45
Aleksey_ts
Добрый день!
Опишите более детально задачу и причины ее постановки.
т.е. почему возникла потребность делать подобные задержки с набором цифр номера?
Добавлено: 07 фев 2011 16:24
jpbx
Извините, немного попутал.
В 3-х проводную СЛ пауз давать не надо.
В обычную 2-х проводную АЛ линию.
Итого, схема:
АК24 -> АЛ8.
Номер: 2 пауза/гудок 21 12345
При этом сотрудник набирает только 12345.
Возможно вообще как-то паузу или ожидание длинного гудка зарядить?
Добавлено: 09 фев 2011 01:25
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) был добавлен знак паузы. Тогда можно будет высылать номер в любом формате, и станция сама все преобразует и вдует в линию.
Добавлено: 10 фев 2011 14:41
Aleksey_ts
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) был добавлен знак паузы. Тогда можно будет высылать номер в любом формате, и станция сама все преобразует и вдует в линию.
Добрый день!
Совершаемый вызов, описанный в п.3, возможно не проходит потому, что сигналы тонального набора номера, передаваемые шлюзом, передаются не внутриполосно (в пакетах протокола RTP). Чтобы настроить подобную трансляцию цифр номера, необходимо в закладке SIP (confih--->sip) поставить DTMF Mode: inband.
Добавлено: 14 фев 2011 18:26
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. Но что с ним делать - не знает.
Добавлено: 02 мар 2011 16:34
jpbx
Спасибо, новая прошивка с возможностью в ставки паузы в правила трансляции работает
Проблема решена.
Что касается вышеприведенного дебага, надо еще разбираться. Попробую позвонить на номер дозвона какой-то, и прогнать DTMF по всему пути. Проверю как из TAU.72 в TM.IP и далее в линию все прозрачно проходит.
P.S. Пользуясь случаем хочу выразить респект суппорту Элтекса - 3 дня потребовалось от постановки проблемы до получения прошивки. Круто.