[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