----- Original Message ----
> From: Richard Revels <[EMAIL PROTECTED]>
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> <asterisk-users@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
