VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
greyvoip at yahoo.com.au
Guest
|
 Posted: Mon Jan 28, 2008 11:56 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
 |
|
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 |
|
| Back to top |
|
 |
rrevels at bandwidth.com
Guest
|
| Posted: Tue Jan 29, 2008 7:21 am Post subject: [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
On Jan 28, 2008, at 11:56 PM, Grey Man <greyvoip at yahoo.com.au> wrote:
| Quote: | 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 |
|
|
| Back to top |
|
|
atis at iq-labs.net
Guest
|
| Posted: Tue Jan 29, 2008 7:38 am Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
On 1/29/08, Richard Revels <rrevels at bandwidth.com> wrote:
| Quote: | 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:
| Quote: | 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 |
|
| Back to top |
|
|
greyvoip at yahoo.com.au
Guest
|
| Posted: Tue Jan 29, 2008 12:48 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
----- Original Message ----
| Quote: | 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
|
| Quote: | redo your dialplan with the 'g' option on inward dial commands. When
the called party uses the transfer command, your macro should read
the
|
| Quote: | digits to call and then store them in the db, a unique global, or
GROUP
|
| Quote: | () 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 |
|
| Back to top |
|
|
shmaltz at gmail.com
Guest
|
| Posted: Tue Jan 29, 2008 3:05 pm Post subject: [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.
On Jan 29, 2008 2:28 PM, Matt <mhoppes at gmail.com> wrote:
| Quote: | 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.
On Jan 29, 2008 12:48 PM, Grey Man <greyvoip at yahoo.com.au> wrote:
| Quote: |
----- Original Message ----
| Quote: | From: Richard Revels <rrevels at bandwidth.com>
To: Asterisk Users Mailing List - Non-Commercial Discussion
|
|
<asterisk-users at lists.digium.com>
| Quote: | | Quote: | 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
|
| Quote: | redo your dialplan with the 'g' option on inward dial commands. When
the called party uses the transfer command, your macro should read
the
|
| Quote: | digits to call and then store them in the db, a unique global, or
GROUP
|
| Quote: | () 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.
| Quote: |
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
|
|
|
| Back to top |
|
|
greyvoip at yahoo.com.au
Guest
|
| Posted: Tue Jan 29, 2008 3:20 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
| Quote: | ----- Original Message ----
|
| Quote: | From: Matt <mhoppes at gmail.com>
|
| Quote: | To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
|
| Quote: | Sent: Tuesday, 29 January, 2008 7:28:32 PM
|
| Quote: | Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's
Grey,
|
| Quote: | I don't think you understand how transfers work. Let's take for example:
|
| Quote: |
USER-1 dials LOCATION A and then LOCATION B (referred to as 1,A,B).
|
| Quote: |
1 Dials A and transfers the call to B.
|
| Quote: | 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.
|
| Quote: |
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 |
|
| Back to top |
|
|
greyvoip at yahoo.com.au
Guest
|
| Posted: Tue Jan 29, 2008 3:54 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
----- Original Message ----
| Quote: | 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 |
|
| Back to top |
|
|
greyvoip at yahoo.com.au
Guest
|
| Posted: Tue Jan 29, 2008 4:05 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
----- Original Message ----
| Quote: | From: Matt <mhoppes at gmail.com>
|
| Quote: | To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
|
| Quote: | Sent: Tuesday, 29 January, 2008 8:39:25 PM
|
| Quote: | 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 say
|
Disbaling 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.
| Quote: | 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 |
|
| Back to top |
|
|
benny+usenet at amorse...
Guest
|
| Posted: Tue Jan 29, 2008 4:33 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
Matt <mhoppes at gmail.com> writes:
| Quote: | 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.
|
Even if Asterisk stays in the media path, the CDR's are dropped.
It is an annoying problem. Hopefully the new CDR system provides a way
to avoid it. It doesn't affect us so much because customers don't get
to send transfer requests to our billing PBX's, but it's still silly.
/Benny |
|
| Back to top |
|
|
kpfleming at digium.com
Guest
|
| Posted: Tue Jan 29, 2008 4:34 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
Grey Man wrote:
| Quote: | 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.
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. Doing so will require
a redesign of the CDR system, which Steve Murphy has already begun for
Asterisk 1.6.
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.
--
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM) |
|
| Back to top |
|
|
greyvoip at yahoo.com.au
Guest
|
| Posted: Tue Jan 29, 2008 5:29 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
----- Original Message ----
| Quote: | 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:
| Quote: | 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
informational field.
| Quote: |
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
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
greyvoip at yahoo.com.au
Guest
|
| Posted: Tue Jan 29, 2008 5:34 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
| Quote: | ----- Original Message ----
|
| Quote: | From: Matt <mhoppes at gmail.com>
|
| Quote: | To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
|
| Quote: | Sent: Tuesday, 29 January, 2008 9:24:14 PM
|
| Quote: | Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's
|
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
shmaltz at gmail.com
Guest
|
| Posted: Tue Jan 29, 2008 5:44 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
On Jan 29, 2008 3:54 PM, Grey Man <greyvoip at yahoo.com.au> wrote:
| Quote: | ----- Original Message ----
| Quote: | 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.
|
I tested it. It does so for both attended and blind. However, I only
tested it with SIP xfers and not with Tt.
|
|
| Back to top |
|
|
mkezys at gmail.com
Guest
|
| Posted: Fri Feb 01, 2008 11:04 am Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
Hello,
For such 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
Then user connects in following way:
User -> Local PBX -> Main GTW -> PSTN
That way you will be save from transfer issue and all your clients will be able to transfer their calls on Local PBX.
Regards,
Mindaugas Kezys
http://www.kolmisoft.com
MOR - Advanced Billing for Asterisk PBX
-----Original Message-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Grey Man
Sent: Wednesday, January 30, 2008 12:35 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's
| Quote: | ----- Original Message ----
|
| Quote: | From: Matt <mhoppes at gmail.com>
|
| Quote: | To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
|
| Quote: | Sent: Tuesday, 29 January, 2008 9:24:14 PM
|
| Quote: | Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's
|
| Quote: | 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.
| Quote: | 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
_______________________________________________
-- 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 |
|
| Back to top |
|
|
greyvoip at yahoo.com.au
Guest
|
| Posted: Fri Feb 01, 2008 4:19 pm Post subject: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's |
|
|
----- Original Message ----
| Quote: | 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
For
|
such
cases
we
usually
suggest
to
put
2
boxes
in
your
infrastructure:
Main
billing
gateway
-
where
all
PBX'es
are
connected
(all
client's
remote
PBX'es
and
your
Local
PBX)
Local
PBX
-
where
user's
without
PBX'es
are
connected
user
connects
in
following
way:
->
Local
PBX
->
Main
GTW
->
PSTN
way
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 |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
