[asterisk-users] Local channel scenario flushes CDR before dialplan end
Grigoriy Puzankin
gpuzankin at gmail.com
Fri Apr 29 09:51:39 CDT 2011
Hi,
There's a quite complex dialplan scenario and I found out that CDR of
main channel is flushed right after hangup on Local channel. I will try
to simplify my scenario:
[incoming]
exten => 555,1,Noop(do something before using local channel, fill some
variables, play IVR menus and so on)
same => n,Dial(Local/555 at office/n,,g)
same => n,Noop(Notice the option "/n" and flag "g", which allows to
continue the dialplan after a destination channel hangs up, even it was
transfered by a connected peer - it is very important for me)
same => n,Noop(process some data, ask caller to value quality of service
- another IVR, record some messages)
same => n,Hangup()
exten => h,1,Noop(I'm using func_odbc to save quiz results into DB,
process recorded files, etc.)
same => n,Noop(I'm using cdr_adaptive to store custom fields in table
columns)
same => n,CDR(my_custom_field_a)=my_value
same => n,CDR(my_custom_field_z)=my_value
[office]
exten => 555,1,Dial(SIP/555)
same => n,Hangup()
A call comes from a SIP trunk directly to 555 at incoming. It forks new
pair of Local channels, bridging other leg to SIP/555. SIP peer answers
the call, then hangs up. Dialplan continues right after Dial(Local/...).
Also it goes to h extension after reaching Hangup in 555 at incoming.
Everything looks good, but CDR custom fields are empty, regardless that
verbose shows that they were set in dialplan. After a short
investigation I found out that CDR is written to DB in the same time
when dialplan exits Dial application. It produces to records: SIP trunk
to Local and Local to SIP/555, which is correct.
If I use SIP channel instead of Local, then CDR is written after
dialplan ends and all fields are set. But in this case I loose call
processing after it was transfered to another party (I have a lot of
contexts - catching a call-end is a pain).
Is it a bug or intended behavior?
Best regard,
Grigoriy.
More information about the asterisk-users
mailing list