[asterisk-dev] possible lack of CDR data recorded after an attended transfer (atxfer)

Knud Müller k.mueller at portrix.net
Mon Jul 30 05:23:22 CDT 2007


Hi,

I'm not a developer but simply a user, but I read your thread and I 
think my problem might go into the same direction.

We are running asterisk 1.2.16 and need to connect two channels which 
are already established. We are currently using app_meetme to achieve 
that, but we are sometimes unhappy, as app_meetme provides functionality 
that produces load that we do not need in our two party conferences. I 
figured out that there is an alternative called app_changrab. 
(http://www.freeswitch.org/asterisk_stuff/app_changrab.c)
First tests had shown that app_changrab worked well despite CDR logging.
Changrab uses mainly (I have very little understanding of the asterisk 
internals therefore these are just assumptions...) ast_bridge_call to 
connect the channels. But it doesnt connect the actual channel, but 
creates a masqueraded (Zombie?) channel that is handed to the 
ast_bridge_call command. I have seen in the manager interface that the 
Zombie Channel had the same 'uniqueid' and is hungup instantly after 
bridging the call. This leads to an undesired behavior: the CDR Engine 
assumes that the call has ended when the Hungup Zombie channel event has 
to be handled. The 'duration' and 'billsec' fields (which are the most 
important ones for our accounting!) show a duration that end with the 
hungup zombie channel.
Is there any workaround? Can I rearrange app_changrab to use the actual 
channel or fork the CDR in the dialplan (my odbc postgres hates that 
bcs. of a unique constraint on uniqueid that I can remove) or do some 
other magic to get the right billsec which is a must for our application?

Knud

-- 
Knud A. Müller




More information about the asterisk-dev mailing list