[asterisk-users] Asterisk's DANGEROUS Transfer CDR's
Atis Lezdins
atis at iq-labs.net
Tue Jan 29 06:38:47 CST 2008
On 1/29/08, Richard Revels <rrevels at bandwidth.com> wrote:
> 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.
Isn't this what's accountcode is for? You just need to set it in
beginning (or have it automatically set from SIP users) and all CDR
records will have the same accountcode - so correct user will get
billed.
Regards,
Atis
--
Atis Lezdins
VoIP Developer,
IQ Labs Inc.
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835
More information about the asterisk-users
mailing list