Grey,<br>I don't think you understand how transfers work. Let's take for example:<br><br>USER-1 dials LOCATION A and then LOCATION B (referred to as 1,A,B).<br><br>1 Dials A and transfers the call to B.<br>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. <br>
<br>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.<br><br><div class="gmail_quote">On Jan 29, 2008 12:48 PM, Grey Man <<a href="mailto:greyvoip@yahoo.com.au">greyvoip@yahoo.com.au</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">----- Original Message ----<br>> From: Richard Revels <<a href="mailto:rrevels@bandwidth.com">rrevels@bandwidth.com</a>><br>
> To: Asterisk Users Mailing List - Non-Commercial Discussion <<a href="mailto:asterisk-users@lists.digium.com">asterisk-users@lists.digium.com</a>><br>> Sent: Tuesday, 29 January, 2008 12:21:16 PM<br>> Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's<br>
><br>> It's not Asterisk, it's SIP. Transfer takes the signaling off the<br>> Asterisk box.<br>><br>> In features.conf, replace blind transfer with a call to a macro.<br>> Then<br>><br><br>> redo your dialplan with the 'g' option on inward dial commands. When<br>
> the called party uses the transfer command, your macro should read<br>> the<br>><br><br>> digits to call and then store them in the db, a unique global, or<br>> GROUP<br>><br><br>> () variable. Then it should hang up. This will cause the calling leg<br>
> to exit the dial command to the next priority which should be a check<br>> of the variable. If digits are present, use the dial command to call<br>> them at your provider. No fuss, no muss.<br>><br>> You should make sure the peer entry for the outbound side includes<br>
> canreinvite=yes so only the signaling remains on your box and the<br>> media is invited off.<br>><br>> You should also ignore calls to your macro that hit from the inbound<br>> call leg. Just return immediately and neither side will ever know the<br>
> inbound call leg left for a moment.<br>><br>> Sent from my iPhone<br><br><br></div></div>Hi Richard,<br><br>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.<br>
<div class="Ih2E3d"><br>Regards,<br><br>Greyman.<br><br><br><br> Make the switch to the world's best email. Get the new Yahoo!7 Mail now. <a href="http://www.yahoo7.com.au/worldsbestemail" target="_blank">www.yahoo7.com.au/worldsbestemail</a><br>
<br><br><br>_______________________________________________<br></div><div><div></div><div class="Wj3C7c">-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br>