Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

История изменений [назад]

нажмите, чтобы скрыть/показать версии 1
изначальная версия
редактировать

спросил 2012-08-21 09:50:36 +0400

exseos Gravatar exseos

Отсутствие пропущенного вызова при ringall

Астер 1.8.7.1 Проблема: в CDR не отражаются пропущенные вызовы, которые стучатся в очередь. Конфиги такие:

queues.conf

[mega]
strategy = ringall
musicclass=vega
servicelevel = 60
timeout = 0
retry = 1
wrapuptime = 5
autopause = no
maxlen = 0
setinterfacevar=yes
periodic-announce=busy2
periodic-announce-frequency = 60
eventwhencalled = no
eventmemberstatus = no
ringinuse =  no
monitor-format = wav
member => SIP/1298

extensions.conf

[e1-in]
exten => 123456,1,Goto(mega,123456,1)

[mega]
exten => 123456,1,Answer()
same => n,Set(MONITOR_FILENAME=${CALLREC_PREFIX}/${STRFTIME(,,%G)}/${STRFTIME(,,%m)}/${STRFTIME(,,%d)}/IN.mega.${CALLERID(num)}.${STRFTIME(,,%G.%m.%d.%H.%M.%S)}.${UNIQUEID})
same => n,Queue(mega,Tt)

Начал копать, опытным путём установил, что если в очереди со стратегией ringall находятся недоступные юзвери:

 Members:
      SIP/1298 (Not in use) has taken no calls yet
      sip/1234 (dynamic) (Unavailable) has taken no calls yet

И поступает вызов на 123456, который сразу стучится в очередь, затем завершает вызов(без ответа оператора), то в queue-log будет запись, свидетельствующая о поступлении вызова, его статусе неответа, а вот в CDR(mysql) запись вообще будет отсутствовать! И только если я убираю из очереди всех Unavailable или меняю стратегию, например, на rrmemory , только тогда всё корректно - записи все и в CDR и в queue_log

Ваше мнение? Встречались с подобными ситуациями? Может я заблуждаюсь? Как решить ситуацию? Мне для ряда очередей неприемлема логика rrmemory, нужна именно ringall, а контролировать все in\out операторов в очереди - это ж ляснуться можно. 8]

Отсутствие пропущенного вызова при ringall

Астер 1.8.7.1 Проблема: в CDR не отражаются пропущенные вызовы, которые стучатся в очередь. Конфиги такие:

queues.conf

[mega]
strategy = ringall
musicclass=vega
servicelevel = 60
timeout = 0
retry = 1
wrapuptime = 5
autopause = no
maxlen = 0
setinterfacevar=yes
periodic-announce=busy2
periodic-announce-frequency = 60
eventwhencalled = no
eventmemberstatus = no
ringinuse =  no
monitor-format = wav
member => SIP/1298

extensions.conf

[e1-in]
exten => 123456,1,Goto(mega,123456,1)

[mega]
exten => 123456,1,Answer()
same => n,Set(MONITOR_FILENAME=${CALLREC_PREFIX}/${STRFTIME(,,%G)}/${STRFTIME(,,%m)}/${STRFTIME(,,%d)}/IN.mega.${CALLERID(num)}.${STRFTIME(,,%G.%m.%d.%H.%M.%S)}.${UNIQUEID})
n,Set(MONITOR_FILENAME= ${CALLREC_PREFIX}/${STRFTIME(,,%G)}/${STRFTIME(,,%m)}/${STRFTIME(,,%d)}/ IN.mega.${CALLERID(num)}.${STRFTIME(,,%G.%m.%d.%H.%M.%S)}.${UNIQUEID})
same => n,Queue(mega,Tt)

Начал копать, опытным путём установил, что если в очереди со стратегией ringall находятся недоступные юзвери:

 Members:
      SIP/1298 (Not in use) has taken no calls yet
      sip/1234 (dynamic) (Unavailable) has taken no calls yet

И поступает вызов на 123456, который сразу стучится в очередь, затем завершает вызов(без ответа оператора), то в queue-log будет запись, свидетельствующая о поступлении вызова, его статусе неответа, а вот в CDR(mysql) запись вообще будет отсутствовать! И только если я убираю из очереди всех Unavailable или меняю стратегию, например, на rrmemory , только тогда всё корректно - записи все и в CDR и в queue_log

Ваше мнение? Встречались с подобными ситуациями? Может я заблуждаюсь? Как решить ситуацию? Мне для ряда очередей неприемлема логика rrmemory, нужна именно ringall, а контролировать все in\out операторов в очереди - это ж ляснуться можно. 8]

Отсутствие пропущенного вызова при ringall

Астер 1.8.7.1 Проблема: в CDR не отражаются пропущенные вызовы, которые стучатся в очередь. Конфиги такие:

queues.conf

[mega]
strategy = ringall
musicclass=vega
servicelevel = 60
timeout = 0
retry = 1
wrapuptime = 5
autopause = no
maxlen = 0
setinterfacevar=yes
periodic-announce=busy2
periodic-announce-frequency = 60
eventwhencalled = no
eventmemberstatus = no
ringinuse =  no
monitor-format = wav
member => SIP/1298

extensions.conf

[e1-in]
exten => 123456,1,Goto(mega,123456,1)

[mega]
exten => 123456,1,Answer()
same => n,Set(MONITOR_FILENAME= ${CALLREC_PREFIX}/${STRFTIME(,,%G)}/${STRFTIME(,,%m)}/${STRFTIME(,,%d)}/ IN.mega.${CALLERID(num)}.${STRFTIME(,,%G.%m.%d.%H.%M.%S)}.${UNIQUEID})
same => n,Queue(mega,Tt)
n,Set(MONITOR_FILENAME=${CALLREC_PREFIX}/${STRFTIME(,,%G)}/

${STRFTIME(,,%m)}/${STRFTIME(,,%d)}/IN.mega.${CALLERID(num)}. ${STRFTIME(,,%G.%m.%d.%H.%M.%S)}.${UNIQUEID}) same => n,Queue(mega,Tt)

Начал копать, опытным путём установил, что если в очереди со стратегией ringall находятся недоступные юзвери:

 Members:
      SIP/1298 (Not in use) has taken no calls yet
      sip/1234 (dynamic) (Unavailable) has taken no calls yet

И поступает вызов на 123456, который сразу стучится в очередь, затем завершает вызов(без ответа оператора), то в queue-log будет запись, свидетельствующая о поступлении вызова, его статусе неответа, а вот в CDR(mysql) запись вообще будет отсутствовать! И только если я убираю из очереди всех Unavailable или меняю стратегию, например, на rrmemory , только тогда всё корректно - записи все и в CDR и в queue_log

Ваше мнение? Встречались с подобными ситуациями? Может я заблуждаюсь? Как решить ситуацию? Мне для ряда очередей неприемлема логика rrmemory, нужна именно ringall, а контролировать все in\out операторов в очереди - это ж ляснуться можно. 8]

Отсутствие пропущенного вызова при ringall

Астер 1.8.7.1 Проблема: в CDR не отражаются пропущенные вызовы, которые стучатся в очередь. Конфиги такие:

queues.conf

[mega]
strategy = ringall
musicclass=vega
servicelevel = 60
timeout = 0
retry = 1
wrapuptime = 5
autopause = no
maxlen = 0
setinterfacevar=yes
periodic-announce=busy2
periodic-announce-frequency = 60
eventwhencalled = no
eventmemberstatus = no
ringinuse =  no
monitor-format = wav
member => SIP/1298

extensions.conf

 [e1-in]
 exten => 123456,1,Goto(mega,123456,1)

 [mega]
 exten => 123456,1,Answer()
 same => n,Set(MONITOR_FILENAME=${CALLREC_PREFIX}/${STRFTIME(,,%G)}/
${STRFTIME(,,%m)}/${STRFTIME(,,%d)}/IN.mega.${CALLERID(num)}.
${STRFTIME(,,%G.%m.%d.%H.%M.%S)}.${UNIQUEID})
    same => n,Queue(mega,Tt)

${STRFTIME(,,%m)}/${STRFTIME(,,%d)}/IN.mega.${CALLERID(num)}. ${STRFTIME(,,%G.%m.%d.%H.%M.%S)}.${UNIQUEID}) same => n,Queue(mega,Tt)

Начал копать, опытным путём установил, что если в очереди со стратегией ringall находятся недоступные юзвери:

 Members:
      SIP/1298 (Not in use) has taken no calls yet
      sip/1234 (dynamic) (Unavailable) has taken no calls yet

И поступает вызов на 123456, который сразу стучится в очередь, затем завершает вызов(без ответа оператора), то в queue-log будет запись, свидетельствующая о поступлении вызова, его статусе неответа, а вот в CDR(mysql) запись вообще будет отсутствовать! И только если я убираю из очереди всех Unavailable или меняю стратегию, например, на rrmemory , только тогда всё корректно - записи все и в CDR и в queue_log

Ваше мнение? Встречались с подобными ситуациями? Может я заблуждаюсь? Как решить ситуацию? Мне для ряда очередей неприемлема логика rrmemory, нужна именно ringall, а контролировать все in\out операторов в очереди - это ж ляснуться можно. 8]

О проекте | Часто задаваемые вопросы | политика конфиденциальности | оставить отзыв

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.