Хочу попросить объяснить мне момент с временными задержками в астериске.
Собственно вот сам вопрос:
Построена телефония с Asterisk 13.11.2, базой Panasonic TGP600 + 4 трубки Panasonic TA60.
В админке TGP600 каждой трубке указан Asterisk сервер и прописаны свой логин/пароль. Соответственно трубки имеют номера 100-103.
План дозвона простейший:
extensions.conf
| Код: |
| [call-in] exten => 1234567,1,Answer exten => 1234567,2,Queue(managers,15,,,15) exten => 1234567,3,Dial(SIP/100) exten => 1234567,4,Hangup |
queues.conf
| Код: |
| [managers] musicclass = default announce = managers strategy = rrmemory member => SIP/101 member => SIP/102 timeout = 7 retry = 0 timeoutpriority = app ringinuse = no memberdelay = 0 |
И собственно лог вызова по этому плану:
| Код: |
| [2016-09-24 21:00:07.532] Asterisk Ready. [2016-09-24 21:00:15.470] -- Executing [1234567@call-in:1] Answer("SIP/mcn-00000000", "") in new stack [2016-09-24 21:00:15.552] > 0x811c87000 -- Probation passed - setting RTP source address to 12.34.56.78:29170 [2016-09-24 21:00:15.552] -- Executing [1234567@call-in:2] Queue("SIP/mcn-00000000", "managers,15,,,15") in new stack [2016-09-24 21:00:15.552] -- Started music on hold, class 'default', on channel 'SIP/mcn-00000000' [2016-09-24 21:00:15.554] -- Called SIP/101 [2016-09-24 21:00:18.028] -- SIP/101-00000001 is ringing [2016-09-24 21:00:22.555] -- Nobody picked up in 7000 ms [2016-09-24 21:00:27.559] -- Called SIP/102 [2016-09-24 21:00:30.244] -- SIP/102-00000002 is ringing [2016-09-24 21:00:30.559] -- Nobody picked up in 3000 ms [2016-09-24 21:00:30.560] -- Stopped music on hold on SIP/mcn-00000000 [2016-09-24 21:00:30.561] -- Executing [1234567@call-in:3] Dial("SIP/mcn-00000000", "SIP/100") in new stack [2016-09-24 21:00:30.563] -- Called SIP/100 [2016-09-24 21:00:33.439] -- SIP/100-00000003 is ringing [2016-09-24 21:00:35.748] == Spawn extension (call-in, 1234567, 3) exited non-zero on 'SIP/mcn-00000000' ^C[2016-09-24 21:03:46.711] Asterisk cleanly ending (0). [2016-09-24 21:03:46.711] Executing last minute cleanups [2016-09-24 21:03:46.711] == Destroying musiconhold processes [2016-09-24 21:03:46.711] == Manager unregistered action DBGet [2016-09-24 21:03:46.711] == Manager unregistered action DBPut [2016-09-24 21:03:46.711] == Manager unregistered action DBDel [2016-09-24 21:03:46.711] == Manager unregistered action DBDelTree |
Так вот собственно в чём вопрос:
Мои соображения по временным таймаутам всей этой схемы:
1. Поступает звонок, ответ
2. Звонок помещается в очередь, длительность нахождения в которой устанавливается (и в описании очереди выбирается приоритетной) в 15 секунд.
3. Каждому члену очереди выдаётся на снятие трубки 7 секунд, затем переходит следующему следующему.
4. Если по истечении 15 секунд в очередт никто звонок не принял, он идёт 100-му.
Так вот, на практике из лога видно что всё отрабатывало так:
* 21:00:15.470 звонок был принят астериском
* 21:00:15.554 был помещён в очередь и вызван 101-ый
* 21:00:18.028 101-ый начал звонить (3 секунды в очереди)
* 21:00:22.555 Система поняла, что в течение отведённых 7-ми секунд вызов не был принят (7 секунд в очереди)
* 21:00:27.559 Только начал вызываться 102-ой (12 секунд в очереди)
* 21:00:30.244 102-ой только начал звонить (15 секунд в очереди)
* 21:00:30.559 Вышли отведённые на очередь 15 секунд и звонок перешёл на 100-го (15 секунд в очереди)
Откуда разница почти в 3 секунды между этапами вызова трубки и началом её звонка? Это связано с конкретным оборудованием (базой и трубками), что они так медленно соображают или где-то в конфигах это настраивается?
Потому что получается что на практике это выглядит так:
- я звоню, через 3 секунды звонит 101-ый. Звонит оставшиеся из отведённых ему 7-ми секунд, 4-ре и затем 3 секундная тишина. Не звонит ни 101-ый, ни 102-ой. Затем соответственно 1 секунду отзванивается 102-ой и всё уходит на 100-ый.
Я так думаю что эта задержка в 3 секунды что-то ненормальное, и от неё надо бы избавиться. Как это сделать?
_________________
платный суппорт по мере возможностей
| Цитата: |
| поменяйте стратегию allring и выставьте приоритеты 1,2 на номера |
Приоритеты выставить, это где? Просмотрел весь конфиг queues.conf, не понял где там приоритеты. Если это имеется в виду параметр penalty, то прочитал описание что тогда вызов всегда будет идти в очереди сперва участнику с меньшим приоритетом, и если только он занят, то будет переводиться на следующего по приоритетности участника. Мне надо чтобы в очередь звонки ставились участникам поровну. Т.е. то одному, то второму.
Стратегию поменял, только мне не надо чтобы все участники очереди звонили одновременно. Мне надо чтобы позвонил 7 сек. один, если не ответил то звонок перешёл на 2-го, если из них никто в течение 15 сек. не ответил, то выходит из очереди на 3-го.
И основной вопрос с задержкой в 3 секунды между событиями передачи звонка и началом сигнала аппарата так и остался нерешённым.
Added after 13 minutes:
Уважаемые, мне бы просто понять откуда задержки между вот этими этапами из лога:
| Цитата: |
| [2016-09-25 20:23:37.358] -- Executing [1234567@call-in:1] Answer("SIP/mcn-00000000", "") in new stack [2016-09-25 20:23:37.442] > 0x811c8a000 -- Probation passed - setting RTP source address to 12.34.56.78:27112 [2016-09-25 20:23:37.442] -- Executing [1234567@call-in:2] Queue("SIP/mcn-00000000", "managers,tT,,,26") in new stack [2016-09-25 20:23:37.442] -- Started music on hold, class 'default', on channel 'SIP/mcn-00000000' [2016-09-25 20:23:37.444] -- Called SIP/101 * Эта задержка в 3 секунды [2016-09-25 20:23:39.809] -- SIP/101-00000001 is ringing [2016-09-25 20:23:47.445] -- Nobody picked up in 10000 ms * Эта задержка в 5 секунд [2016-09-25 20:23:52.448] -- Called SIP/102 * Эта задержка в 3 секунды [2016-09-25 20:23:55.135] -- SIP/102-00000002 is ringing [2016-09-25 20:24:02.449] -- Nobody picked up in 10000 ms * Эта задержка в 5 секунд [2016-09-25 20:24:07.452] -- Stopped music on hold on SIP/mcn-00000000 [2016-09-25 20:24:07.452] -- Executing [1234567@call-in:3] Dial("SIP/mcn-00000000", "SIP/100") in new stack [2016-09-25 20:24:07.455] -- Called SIP/100 * Эта задержка в 3 секунды [2016-09-25 20:24:09.823] -- SIP/100-00000003 is ringing |
Это с конфигами такими:
extensions.conf
| Код: |
| ... exten => 1234567,2,Queue(managers,tT,,,26) ... |
queues.conf
| Код: |
| [general] persistentmembers = yes monitor-type = MixMonitor [managers] announce = managers strategy = rrmemory member => SIP/101 member => SIP/102 timeout = 10 retry = 0 timeoutpriority = app joinempty = paused,inuse,invalid ringinuse = no memberdelay = 0 |
ps - я что то вообще не понимаю зачем вам очередь ?
_________________
платный суппорт по мере возможностей
И между менеджерами чтобы эти звонки равномерно распределялись. Вроде очередь же для этого и нужна.
Я прошу вопрос не переводить на другую тему. Вроде бы сформулировал я свой вопрос достаточно четко, с нормальным описанием и приложил все логи, которые прошу объяснить и спорные моменты помочь решить, перевод темы вида "надо вообще по другому" не подходит как минимум просто потому, что я хотел бы узнать ответ на именно свой вопрос хотя бы в целях лучшего понимания работы астериска.
Такой в итоге диалплан:
| Код: |
| exten => 3021010,1,ChanIsAvail(SIP/101&SIP/102&/SIP/103,as) exten => 3021010,3,Dial(SIP/101&SIP/102,12) exten => 3021010,4,Dial(SIP/100,10) exten => 3021010,5,Goto(1) |
_________________
Кто такой Тайлер Дёрден?