[asterisk-dev] Devloping an end of call hook or trap
Beau Hargis
beauh at bluefrogmobile.com
Wed Feb 15 18:19:45 MST 2006
There has to be a slightly more elegant way to accomplish this. The
channel variables are used to track user state, the information captured
by the caller and the paths through which they have traveled. So,
without a way to hook into the end of call (i.e. at hangup before the
channel and it's variables are destroyed), one has to set the channel
variable for that data as well as the CDR variable every time it
changes.
It doesn't even have to be a C function that gets called. Would others
be interested in something like a hangup context to which every call is
dumped on hangup where all the state of the call, including the channel
variables is available. It can be set in the config file, as well as
have an accompanying function to set and read it?
I can build something like this myself, but if nobody else has a use for
it, I won't format it and structure it for inclusion into asterisk.
On Wed, 2006-02-15 at 16:23 -0600, Tilghman Lesher wrote:
> On Wednesday 15 February 2006 15:20, Beau Hargis wrote:
> > I made a custom cdr module to log what we need at the end of call for
> > the CDRs that we have in our databases, but I am looking for a clean
> > way to hook into the hangup of a channel to do some end of call data
> > gathering and logging. I can do this in my custom cdr loging
> > function, but on SIP channels all the channel variables are destroyed
> > at that point. On local, they are there, but I have yet to try it on
> > a zap channel.
>
> You should not count on the channel variables being there. That is
> precisely why CDR variables exist.
>
> > Is there a point during the hangup of a channel where most everything
> > is done, but the channel variables still exist so the state of the
> > call at the point of hangup can be captured? So far, I have been
> > using the CDR() dial plan function to store the information so it is
> > accessible to the custom cdr logging, but it has to be explicitly
> > set.
>
> That is how you should be doing it.
>
More information about the asterisk-dev
mailing list