Добрый день, коллеги!
Нужна ваша помощь, очень хочется узнать ответ на вопрос, как такое может быть(ситуация описана ниже)?
Asterisk 11.7.0, диалплан:
[test]
exten => 400,1,Answer
same => n,Set(CDR(mambo)=Mambo)
same => n,Queue(test,,,,,,,subEtt)
same => n,Hangup
[subEtt]
exten => s,1,Set(CDR(userfield)=Field_1)
same => n,NoOP(${CDR(userfield)})
same => n,Set(CDR(userfield2)=Field_2)
same => n,NoOP(${CDR(userfield2)})
same => n,Return()
Результат выполнения диалплана:
testpc*CLI> core set verbose 9
Set remote console verbosity to 9
== Using SIP RTP CoS mark 5
-- Executing [400@test:1] Answer("SIP/333-00000004", "") in new stack
> 0x7f320801cb50 -- Probation passed - setting RTP source address to 192.168.1.49:4008
-- Executing [400@test:2] Set("SIP/333-00000004", "CDR(mambo)=Mambo") in new stack
-- Executing [400@test:3] Queue("SIP/333-00000004", "test,,,,,,,subEtt") in new stack
-- Started music on hold, class 'default', on SIP/333-00000004
== Using SIP RTP CoS mark 5
-- SIP/333-00000005 is ringing
-- SIP/333-00000005 answered SIP/333-00000004
-- Stopped music on hold on SIP/333-00000004
-- SIP/333-00000005 Internal Gosub(subEtt,s,1) start
-- Executing [s@subEtt:1] Set("SIP/333-00000005", "CDR(userfield)=Field_1") in new stack
-- Executing [s@subEtt:2] NoOp("SIP/333-00000005", "Field_1") in new stack
-- Executing [s@subEtt:3] Set("SIP/333-00000005", "CDR(userfield2)=Field_2") in new stack
-- Executing [s@subEtt:4] NoOp("SIP/333-00000005", "Field_2") in new stack
-- Executing [s@subEtt:5] Return("SIP/333-00000005", "") in new stack
== Spawn extension (test, 400, 1) exited non-zero on 'SIP/333-00000005'
-- SIP/333-00000005 Internal Gosub(subEtt,s,1) complete GOSUB_RETVAL=
-- Remotely bridging SIP/333-00000004 and SIP/333-00000005
> [INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,userfield,mambo,uniqueid,linkedid,sequence) VALUES ({ ts '2013-12-18 09:03:50' },'"333" <333>','333','400','test','SIP/333-00000004','SIP/333-00000005','Queue','test,,,,,,,subEtt',1,1,'ANSWERED',3,'Field_1','Mambo','1387343030.4','1387343030.4','6')]
== Spawn extension (test, 400, 3) exited non-zero on 'SIP/333-00000004'
userfield2 и mambo это дополнительные поля в базе. Как так получается, что в CDR заносится значение в поле mambo (контекст test), заносится значение в поле userfield (subEtt), но НЕ заносится значение в поле userfield2 (subEtt)? Точнее, при выполнении subEtt не заносятся данные в любые дополнительные поля CDR кроме стандартного userfield.
Это фича такая, или баг?
Задан: 2013-12-18 09:43:51 +0400
Просмотрен: 1,882 раз
Обновлен: Dec 18 '13
Вопрос про filter в cdr_adaptive_odbc.conf
Как настроить запись CDR (писать только нужные звонки)
Покритикуйте пожалуйста следующий код.
Как работает negative connection cache?
cdr reports перенос данных о звонках
Как сделать выброку CDR через Realtime
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
userfield2 создано в БД?
zzuz ( 2013-12-18 12:16:43 +0400 )редактироватьДа, конечно. Причем оно нормально записывается, если его переместить на место
StuxForce ( 2013-12-18 13:19:50 +0400 )редактироватьЧто подразумевается под "переместить на место" ?
zzuz ( 2013-12-19 01:33:49 +0400 )редактироватьИмеется ввиду, что если изменить диалплан на
То userfield2 запишется в БД, а mambo - нет. То есть при выполнении subEtt не заносятся данные в любые дополнительные поля CDR кроме стандартного userfield.
StuxForce ( 2013-12-19 13:12:30 +0400 )редактироватьВидимо потому что mambo в таблице не создано.
zzuz ( 2013-12-19 15:25:08 +0400 )редактироватьПлюс неплохо бы в алиасы добавить ваше поле.
zzuz ( 2013-12-19 15:26:04 +0400 )редактироватьУважаемы zzuz, перечитайте пожалуйста внимательней мой вопрос и сопутствующую ему информацию в основном посте. Все поля созданы, в обычных условиях в них все заносится без проблем. Под "обычными условиями" я подразумеваю основной контекст (test). Алиасы тут не при чем (хотя пробовал, не помогает).
StuxForce ( 2013-12-19 16:21:24 +0400 )редактироватьНе верю , что созданы поля таблицы. Я вот вчера в шашки с дед морозом играл, но кто мне поверит.
zzuz ( 2013-12-19 18:04:51 +0400 )редактироватьМожно закрывать. Это была бага в *
Исправлено начиная с версий 1.8.27.0, 11.9.0, 12.1.0
StuxForce ( 2014-09-04 09:44:14 +0400 )редактироватьНет такой баги , всё работает и с версии 1.4.
zzuz ( 2014-09-04 10:21:19 +0400 )редактироватьhttps://issues.asterisk.org/jira/browse/ZAP-365?jql= вам в помошь.
StuxForce ( 2014-09-04 11:03:03 +0400 )редактироватьСсылка ведет на тему "CLONE - DAHDI channel gets stuck in 'Pre-rin' state" с Environment: Asterisk 11.4.0 (32 bit) with DAHDI 2.7.0 . А по вашей теме могу сказать , что так как Вам надо работает на промышленных серверах без патчей.
zzuz ( 2014-09-04 14:10:09 +0400 )редактироватьВы правильно поняли, что так как мне надо, это чтобы при поднятии трубки агентом в очереди выполнялся subEtt и вносились данные в дополнительные поля БД?
С сылкой ошибся, вот правильная:https://issues.asterisk.org/jira/browse/ASTERISK-23046
Дабы не разводить дальнейший пустой холивар прошу тему закрыть!
StuxForce ( 2014-09-04 14:43:45 +0400 )редактироватьЯ вполне правильно понял. Потому что в наших случаях мы заполняем по 8-10 произвольных полей CDR при любом событие . Нужно более детально смотреть дебаг.
zzuz ( 2014-09-04 16:08:44 +0400 )редактировать