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

[Richard Revels]

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

On Jan 28, 2008, at 11:56 PM, Grey Man <greyvoip at yahoo.com.au> wrote:

> Hi All,
>
> PLEASE READ if you depend on Asterisk CDR's and support transfers.
>
> Apologies for the shout but I'm desperate to get others to agree  
> Asterisk has a
> big problem with the CDR's that are generated for transfers. I can  
> understand
> why not too many people are interested as transfers are complicated  
> and
> messy. However for those of us having to support transfers and  
> depending on
> Asterisk CDR's for our billing we are in a sticky predicament! For  
> anyone
> using Asterisk in a provider environment unaware of any problem I  
> urge you to
> do a simple blind transfer on your system and check your CDR's. Most  
> Asterisk
> based providers I tested are blocking transfers but I did find some  
> other
> providers out there missing billable call legs!
>
> My goal is to try and get acknowledgement that there is a serious  
> problem
> here that warrants a re-think about how Asterisk CDR's are generated.
>
> In an effort to succinctly encapsulate the problem I've produced the  
> call and CDR
> flows below. Hopefully they make sense but if not I'm more than  
> happy to elaborate
> and share my test results (the flows below won't be legibile without  
> a mono spaced
> font, copy and pasting into notepad will make them readable).
>
> Blind Transfer (1.2 and 1.4):
>
> Time           Calls                CDRs
>                             | Dest  | Dur(s) |
>                             |-------|--------|
> T0 -| Alice --> * --> Bob   |       |        |
>     |                       |       |        |
> Tt -| Carol <-- * --> Bob  -|  Bob  |   Tt   |
>     |                       |       |        |
> Te -| End                  -| Carol |   Te   |
>
>
> Attended Transfer (1.2):
>
> Time           Calls                CDRs
>                             | Dest  | Dur(s) |
>                             |-------|--------|
> T0 -| Alice --> * --> Bob   |       |        |
>     |                       |       |        |
> T1 -| Alice --> * --> Carol |       |        |
>     |                       |       |        |
> Tt -| Carol <-- * --> Bob  -| Bob   |   Tt   |
>     |                       | Carol | Tt - T1|
>     |                       |   s   |   Tt   |
>     |                       |       |        |
> Te -| End                  -|   s   |   Te   |
>
>
> Attended Transfer (1.4):
>
> Time           Calls                CDRs
>                             | Dest  | Dur(s) |
>                             |-------|--------|
> T0 -| Alice --> * --> Bob   |       |        |
>     |                       |       |        |
> T1 -| Alice --> * --> Carol |       |        |
>     |                       |       |        |
> Tt -| Carol <-- * --> Bob  -|       |        |
>     |                       |       |        |
> Te -| End                  -|  Bob  |   Te   |
>                             |  Bob  | Te - T1|
>
> To put it another way here are some examples of how Asterisk systems  
> and
> transfers can be exploited.
>
> 1. Place a call to a mobile you plan on having a lengthy call to. As  
> soon as the
> call is establised blind transfer it to a low or free cost  
> destination. You will
> only be billed for the mobile call up to the time it takes you to do  
> the transfer
> the remainder of the call will be billed at the low cost or free  
> destination.
>
> 2. With Asterisk 1.4 place a call to two billable destinations and  
> then transfer
> them together. You'll only be billed for each destination up until  
> the time it takes
> you to transfer.
>
> 3. With Asterisk 1.2 place a call to a low cost or free destination.  
> Then place a
> call to an expensive destination and do an attended transfer. You'll  
> only be
> billed for the expensive destination up unitl the time it takes to  
> do the transfer.
>
> I have opened a bug on the issue but I suspect without input from  
> others having
> the same problem it will fade away.
> http://bugs.digium.com/view.php?id=11849
>
> From my point of view the design solution to this problem would be  
> as simple
> as changing the CDR generation from one CDR per bridge to generating  
> a CDR
> for each end of a bridge. When the end of a bridge changes or the  
> bridge is
> hungup a CDR(s) would be generated.  The implementation would
> undoubtedly be a lot more difficult but if the design could be  
> agreed upon at
> least those of us in between a rock and a hard place on this could  
> decide
> to sponsor development, offer a bounty etc.
>
> 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