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
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
----- 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 iPhoneHi 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
> ----- Original Message ----> From: Matt <mhoppes at gmail.com>> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>> Sent: Tuesday, 29 January, 2008 7:28:32 PM> Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's> > 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.Hi Matt, Sadly I understand all to well how transfers work. I've had to go over and over this for the last 12 months trying to find different ways of handling it. I'm talking about blind and attended call transfers here not IAX or any other kind. We are not taking Asterisk out of the media path and even if we were you wouldn't want to be losing CDR's from a provider's point of view, whoever set the call up is still paying for it regardless of where the media has been re-invited to. Out of the 8 Asterisk based providers I have tested 3 have this issue and the other 5 don't support transfers. It's dead simple for anyone to test. Find an Asterisk provider that supports transfers, connect with the xten, do a blind or attended transfer and check the CDR's. Call a free or cheap destination as the first leg of your transfer and the expensive destination second. You'll be pleasantly suprised at the bill! Regards, Greyman. Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail
----- Original Message ----> From: C F <shmaltz at gmail.com> > To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> > Sent: Tuesday, 29 January, 2008 8:05:00 PM > Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's > > 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. >That will work for blind transfers but not attended and even in the blind transfer case the CDR's still aren't correct you're relying on an informational field. Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail
----- Original Message ----> From: Matt <mhoppes at gmail.com>> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>> Sent: Tuesday, 29 January, 2008 8:39:25 PM> Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's> > Grey... I'm not debating that this is how it works. We provide wholesale VoIP and retail VoIP. Transfers are disabled on both > of those. That was one of the first things we did... all media and calls stay in our system. If the company doesn't have > transfers disabled, that is their own fault, and their loss. I know exactly what you are referring to, and technically I'd sayDisbaling transfers is an attractive option from my point of view but not from my customer's. Being able to transfer an incoming call from the receptionist to the required person is something businesses will consider changing provider for in my experience. There is no way Asterisk is correct with regards the CDR's produced by a transfer. That's what I'm hoping to get people to agree on and think about a change for.> Asterisk is still correct, because the leg of the call that billing was happening on (the sip client) is no longer there.Correct? There are still two other calls that were initiated by the user why should they be dismissed because the first call hungup? In any case they are not dismissed entirely they are just combined and recorded inaccurately. Regards, Greyman Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail
----- Original Message ----> From: Kevin P. Fleming <kpfleming at digium.com> > To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> > Sent: Tuesday, 29 January, 2008 9:34:23 PM > Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's > > Grey Man wrote: > > > That will work for blind transfers but not attended and even in > the >blind transfer case the CDR's still aren't correct you're relying on> an >informational field.> > I think there is an important point being missed here; Asterisk did not > originate the concept of CDRs, nor did it specify what they contain or > how they are to be collected and generated. > > CDRs have existed for decades before Asterisk was created, and they are > a fairly well understood concept throughout the telephony switching > industry. They were designed for billing, and in many > telephony >networks> are still used for billing.Hi Kevin, Thanks for responding. I'd actually prefer to use some form of real-time call control for billing within Asterisk but that's another story. For the half a dozen or so integrations we have done with PSTN carriers the CDRs are integral to the whole process. Arguably the biggest step in the whole interconnect process is matching up the CDRs for agreement.> However, CDRs were created before the users of those services had the > ability to transfer calls, make three-way calls, make conference calls, > and do other magical things. As such, there is no way in a CDR to > represent this activity in any *complete* manner.I understand there are likely to always remain certain things that CDR's cannot cope with but I don't think transfers fall into that category. Would there be anything wrong with recording a CDR for each end of a bridge instead of one CDR per bridge? If one end of the bridge changes, as in the case of a transfer, you get one CDR. When the bridge hangs up you get two CDR's which in fact does make sense as a bridge is two calls/channels. I'd be more than happy to produce call flows for: transfers, 3 way call, whatever else; with the exact CDRs if that would help to clarify things.> Doing so will require a redesign of the CDR system, which Steve Murphy has already begun for > Asterisk 1.6.Yes and thanks must go to Steve for delving into this very unglamorous area it's certainly not up there with video conferencing. The worrying thing though is the CDR's for attended transfers in 1.4 are now worse than they were in 1.2. I've read through Steve's blog posting on the new design and I think there are still some problems with the CDR scenarios. Using overlapping CDRs to determine if a transfer was in progress is fragile (what happens if simultaneous calls are supported) and apart from that the new CDRs will still don't provide enough information to bill all the call legs involved in a transfer.> As far as I am aware, everyone who builds a complete billing system for > Asterisk and expects it to be accurate and reliable uses other means in > addition to CDRs for collecting the information, or they restrict their > users to not performing actions that will break the billing process.That's fair enough I guess but there are quite a few people using Asterisk that have been relying exclusively on its CDRs that weren't aware of the inaccuracies. Certainly the 3 providers I found in the last two days weren't (I've emailed them now). I don't think it would be insurmountable to improve the CDR design in Asterisk. Maybe it won't get to a stage where it's perfect but if a new design was produced it would pave the way for those of us that this is a big deal for to assist in the implementation. Regards, Greyman. Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail
> ----- Original Message ----> From: Matt <mhoppes at gmail.com>> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>> Sent: Tuesday, 29 January, 2008 9:24:14 PM> Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's>> The provider can disable transfers (which is what we do), but why can a PBX not still allow it? Our PBX customers all can do > transferring... but that's because billing isn't needed THERE. The billing, if any, is done on our end, or their providers end. > This really seems like a very small and moot point that is being blown up.Depends how much it could cost you I guess :). If you're not supporting transfers it's a moot point if you are it's a bit more interesting.> If the receptionist needs to transfer the call, then she should be able to do that within the confines of her PBX... the transfer of > her call should NEVER go back out her PBX back to the supplier, for if it does, her PBX now loses control of that call.Our customer base is residential and small business. They don't want to either pay for or support another a PBX thats what they've come to us for in the first place a lot of the time. Regards, Greyman. Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail
----- Original Message ----> From: Mindaugas Kezys <mkezys at gmail.com> > To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> > Sent: Friday, 1 February, 2008 4:04:30 PM > Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's > >Forsuch cases we usually suggest to put 2 boxes in your infrastructure:> > 1.Main billing gateway - where all PBX'es are connected (all client's remote PBX'es and your Local PBX)> 2.Local PBX - where user's without PBX'es are connected> > Thenuser connects in following way:> > User-> Local PBX -> Main GTW -> PSTN> > Thatway you will be save from transfer issue and all your clients will be able to transfer their calls on Local PBX. Hi Mindaugas, That's a good tip, thanks for that. My concerns would be that the call path is now running through two Asterisk servers and that could add some quality problems, probably negligible though. The other concern would be that for fault tolerance we'd now need double the number of servers. If we currently require 3 Asterisk load balanced servers then now we are going to need 6. It's an idea worth toying around with though. Maybe we could specify that all customers that required the ability to transfer had to use server x and then from the SIP Proxy only allow REFER requests to that server. Regards, Greyman. Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail