Таймеры: недоступность транка и донабор в IVR

[gaspaarr]

1) Подскажите, можно ли в IVR (желательно средствами freebpx custom.conf) задать короткий таймер (~1,5 сек) перед тем, как система начнет реагировать на донабор со стороны абонента? Иногда поступают звонки, у которых перед соединением идут некие тональные сигналы, которые иногда ошибочно трактуются как DTMF.

2) При исходящих звонках, на исходящем маршруте заявлено несколько транков, первый транк недоступен (вообще ничего не отвечает, грубо говоря даже не пингуется):

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

[2015-03-05 17:31:04] VERBOSE[7428][C-000003bb] chan_sip.c: Reliably Transmitting (NAT) to 1.2.3.4:5060
...................................
14 попыток INVITE
...................................
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] app_dial.c:     -- SIP/PROV-1234567-0000069a is circuit-busy
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] app_dial.c:     -- SIP/PROV-1234567-0000069a is circuit-busy
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] app_dial.c:   == Everyone is busy/congested at this time (1:0/1/0)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] app_dial.c:   == Everyone is busy/congested at this time (1:0/1/0)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s@macro-dialout-trunk:23] NoOp("SIP/1993-00000698", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 18") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s@macro-dialout-trunk:23] NoOp("SIP/1993-00000698", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 18") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s@macro-dialout-trunk:24] GotoIf("SIP/1993-00000698", "0?continue,1:s-CONGESTION,1") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s@macro-dialout-trunk:24] GotoIf("SIP/1993-00000698", "0?continue,1:s-CONGESTION,1") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Goto (macro-dialout-trunk,s-CONGESTION,1)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Goto (macro-dialout-trunk,s-CONGESTION,1)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-CONGESTION@macro-dialout-trunk:1] Set("SIP/1993-00000698", "RC=18") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-CONGESTION@macro-dialout-trunk:1] Set("SIP/1993-00000698", "RC=18") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-CONGESTION@macro-dialout-trunk:2] Goto("SIP/1993-00000698", "18,1") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-CONGESTION@macro-dialout-trunk:2] Goto("SIP/1993-00000698", "18,1") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Goto (macro-dialout-trunk,18,1)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Goto (macro-dialout-trunk,18,1)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [18@macro-dialout-trunk:1] Goto("SIP/1993-00000698", "s-NOANSWER,1") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [18@macro-dialout-trunk:1] Goto("SIP/1993-00000698", "s-NOANSWER,1") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Goto (macro-dialout-trunk,s-NOANSWER,1)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Goto (macro-dialout-trunk,s-NOANSWER,1)
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-NOANSWER@macro-dialout-trunk:1] NoOp("SIP/1993-00000698", "Dial failed due to trunk reporting NOANSWER - giving up") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-NOANSWER@macro-dialout-trunk:1] NoOp("SIP/1993-00000698", "Dial failed due to trunk reporting NOANSWER - giving up") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-NOANSWER@macro-dialout-trunk:2] Progress("SIP/1993-00000698", "") in new stack
[2015-03-05 17:31:36] VERBOSE[7428][C-000003bb] pbx.c:     -- Executing [s-NOANSWER@macro-dialout-trunk:2] Progress("SIP/1993-00000698", "") in new stack

Соответственно, прежде, чем попробовать 2 транк проходит 14 безуспешных инвайтов и ~30 секунд времени. И часто бывает так, что до второго транка дело не доходит, т.к. система по каким-то критериям ошибочно решает, что там NOANSWER, но иногда звонок таки перекидывается на следующий транк.

Какой из таймеров отвечает за это? Нашел вот такие:

Asterisk: cc_offer_timer. How many seconds after dialing an extenion a user has to make a call completion request.
Default Value: 30
Internal Name: CC_OFFER_TIMER_DEFAULT

и

Asterisk: rtptimeout = 30. Terminate call if rtptimeout seconds of no RTP or RTCP activity on the audio channel when we're not on hold. This is to be able to hangup a call in the case of a phone disappearing from the net, like a powerloss or someone tripping over a cable.
Asterisk: rtpholdtimeout = 300. Terminate call if rtpholdtimeout seconds of no RTP or RTCP activity on the audio channel when we're on hold (must be > rtptimeout).

Может быть есть еще какой-то, который отвечает за кол-во инвайтов?

[SolarW]

1) Подскажите, можно ли в IVR (желательно средствами freebpx custom.conf) задать короткий таймер (~1,5 сек) перед тем, как система начнет реагировать на донабор со стороны абонента? Иногда поступают звонки, у которых перед соединением идут некие тональные сигналы, которые иногда ошибочно трактуются как DTMF.

Создайте аудиофайлик с 1.5 сек тишины.
Создайте в FreePBX Announcement с этим файликом.
В Destination after playback укажите ваш IVR.
Смаршрутизируйте входящие звонки вместо IVR на этот Announcement.

Вы получили искомую паузу в полторы секунды перед началом работы IVR и обошлись без custom файлов.

[ded]

Можно ещё учесть, что уже есть
/var/lib/asterisk/sounds/en/pls-hold-silent30.wav

[gaspaarr]

Спасибо друзья, этот вариант пришел первым на ум, но думал есть "более лучшие" решения...

А по поводу таймера на транки ничего не подскажите?

[gaspaarr]

По поводу 2 вопроса, проблему решает qualify=yes в настройках транка, только если транк помечен как UNREACHABLE, тогда даже не пытается на него отправлять звонок. А если (ну мало ли) транк отвалился незадолго до звонка, и qualify еще не успел отловить этот факт, то все, безуспешные попытки invite и отвал звонка с ошибкой...