[asterisk-users] Asterisk's DANGEROUS Transfer CDR's

Matt mhoppes at gmail.com
Tue Jan 29 13:28:32 CST 2008


Grey,
I don't think you understand how transfers work.   Let's take for example:

USER-1 dials LOCATION A and then LOCATION B (referred to as 1,A,B).

1 Dials A and transfers the call to B.
The call data is now NO LONGER in the asterisk path, therefore asterisk has
nothing to do with the CDR.  However, the call legs are still going out of
the providers trunking.   This is not a problem with asterisk, but a logic
problem with you/providers dial-plan.

Asterisk is doing exactly as it should.. when it steps out of the media
path, the CDR is also dropped, as asterisk is no longer responsible for that
call.

On Jan 29, 2008 12:48 PM, Grey Man <greyvoip at yahoo.com.au> wrote:

> ----- Original Message ----
> > From: Richard Revels <rrevels at bandwidth.com>
> > To: Asterisk Users Mailing List - Non-Commercial Discussion <
> asterisk-users at lists.digium.com>
> > Sent: Tuesday, 29 January, 2008 12:21:16 PM
> > Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's
> >
> > It's not Asterisk, it's SIP.  Transfer takes the signaling off the
> > Asterisk box.
> >
> > In features.conf, replace blind transfer with a call to a macro.
> > Then
> >
>
> > redo your dialplan with the 'g' option on inward dial commands. When
> > the called party uses the transfer command, your macro should read
> > the
> >
>
> > digits to call and then store them in the db, a unique global, or
> > GROUP
> >
>
> > () variable. Then it should hang up. This will cause the calling leg
> > to exit the dial command to the next priority which should be a check
> > of the variable. If digits are present, use the dial command to call
> > them at your provider. No fuss, no muss.
> >
> > You should make sure the peer entry for the outbound side includes
> > canreinvite=yes so only the signaling remains on your box and the
> > media is invited off.
> >
> > You should also ignore calls to your macro that hit from the inbound
> > call leg. Just return immediately and neither side will ever know the
> > inbound call leg left for a moment.
> >
> > Sent from my iPhone
>
>
> Hi Richard,
>
> I'm not actually sure we're talking about the same thing here. It's not
> transfers I have a problem with it's the CDRs the transferred calls end up
> generating. In this case I am the provider and transfers through our
> Asterisk servers work fine it's just that we can't properly bill for them.
>
> Regards,
>
> Greyman.
>
>
>
>      Make the switch to the world's best email. Get the new Yahoo!7 Mail
> now. www.yahoo7.com.au/worldsbestemail
>
>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080129/189e89c7/attachment.htm 


More information about the asterisk-users mailing list