[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