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

[C F]

Grey,
Just tested with 1.2.13
Asterisk always (blind or attd xfer) creates 2 records.
A few points, NEVER rely on source as the billable number.
Always use account codes.
Match the lastdata field against dst fields to figure out that it was
an xfer when doing the rating. The lastdata field will have the right
number.


On Jan 29, 2008 2:28 PM, Matt <mhoppes at gmail.com> wrote:
> 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
> >
>
>
> _______________________________________________
> -- 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
>