Канальные переменные. Баг или фича?
| Code: |
| exten = XXX,1,Set(VAR="Data1") exten = XXX,n,Dial(SIP/XXX) ... exten = YYY,1,Set(VAR="Data2") exten = YYY,n,Dial(SIP/YYY) ... exten = h,1,NoOp(VAR) ... |
Для понимания, Data1 и Data2 - текущее время, но это не суть.
Все звонки поступают на ХХХ, а потом он их переводит на остальные, допустим YYY. Все звонки идут от шлюза.
В логах соответственно идет:
| Quote: | |||
| Set("SIP/","VAR=Data1") Dial("SIP/","SIP/XXX") .... | |||
| Дык, у нас есть: звонок снаружи (ножка 1, напр. Zap/g1 и ножка 2, напр. SIP/XXX), на Zap/g1 мы бежим диапланом и устанавливаем переменные до Dial. Дальше Dial и бридж. Потом для attended трансфер создается еще точно так же 2 ножки (SIP/xxx2 и SIP/YYY), там опять же пока диалплан бежит по SIP/xxx2 , выставляет переменные, потом Dial и бридж ножек в канал А вот дальше когда происходит собственно перевод получается: имеем 4(или 3) ножки и 2 канала из которых надо сделать 2 ножки и 1 канал. В этот момент (по крайней мере в 1.4) выполняются хитрые финты ушами на тему переименования каналов и прочего, а попутно - обьединяются переменные, висящие на обеих каналах. Может быть, в 1.6 уже не так, но я сомневаюсь. Anyway: если хочется подробую статистику о ходе движения разговора то надо думать либо в сторону func_odbc для записи в базу прямо из диалплана, либо про AMI, где можно мониторить создания/удаления/бриджа каналов, ход диалплана на low level, либо про [Fast]AGI | |||
| Мдяс.... Не все так светло в Датском королевстве... Вот как раз этого объединения и не надо. Ладно, будем думать другим путем. Думаю, через файлы передавать переменные или AstDB... -- Решил проблему через AstDB привязыванием к имени канала. Что-то типа
| |||
| смотрите в сторону astdb, там это всё делается на раз-два | |||