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

Grey Man greyvoip at yahoo.com.au
Tue Jan 29 11:48:30 CST 2008


----- 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





More information about the asterisk-users mailing list