Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Mindaugas Kezys]

>From our experience it is not enough. We had to rewrite CDR generation to
suite our billing needs. That was on 1.4.xx, we are not using 1.6+

Regards,
Mindaugas Kezys

Kolmisoft UAB 
VoIP Billing Solutions
e-mail: i...@kolmisoft.com
URL: http://www.kolmisoft.com
Find us on Facebook


-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Nikhil
Sent: Monday, November 22, 2010 7:20 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] Is existing CDR in Asterisk is enough for complete
billing

Hi everyone,
 I am facing lots for problem with CDRs in 1.6 and above versions,its
shows wrong records when I do transfer(caller side and calee
side),callforward,call parking.Is the present CDRs in 1.6 is enough for
Complete billing.?What I need to do to make it proper.Please help me on
this.

Thanks
Nikhil

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Nikhil]

anyone have a idea on this..

On 11/22/2010 10:50 AM, Nikhil wrote:
> Hi everyone,
> I am facing lots for problem with CDRs in 1.6 and above 
> versions,its shows wrong records when I do transfer(caller side and 
> calee side),callforward,call parking.Is the present CDRs in 1.6 is 
> enough for Complete billing.?What I need to do to make it 
> proper.Please help me on this.
>
> Thanks
> Nikhil


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Sherwood McGowan]

On Wed, Dec 1, 2010 at 6:56 AM, Nikhil  wrote:
> anyone have a idea on this..
>
> On 11/22/2010 10:50 AM, Nikhil wrote:
>> Hi everyone,
>>     I am facing lots for problem with CDRs in 1.6 and above
>> versions,its shows wrong records when I do transfer(caller side and
>> calee side),callforward,call parking.Is the present CDRs in 1.6 is
>> enough for Complete billing.?What I need to do to make it
>> proper.Please help me on this.
>>
>> Thanks
>> Nikhil
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

I can tell you that back in 2005 I set up a complete
residential/business VOIP ITSP that was using just the Asterisk CDRs
to track billing. As long as you setup your billing, I see now reason
wh

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Steve Murphy]

On Wed, Dec 1, 2010 at 5:56 AM, Nikhil  wrote:

> anyone have a idea on this..
>
> On 11/22/2010 10:50 AM, Nikhil wrote:
> > Hi everyone,
> > I am facing lots for problem with CDRs in 1.6 and above
> > versions,its shows wrong records when I do transfer(caller side and
> > calee side),callforward,call parking.Is the present CDRs in 1.6 is
> > enough for Complete billing.?What I need to do to make it
> > proper.Please help me on this.
> >
> > Thanks
> > Nikhil
>

Nikhil--

Yes, there is a problem with CDR's in asterisk. There is a bug filed
against the problem, but no practical solution for it.

The cure: use the CEL interface instead, and generate your own
CDR's (or whatever else you could bill from [it doesn't *have* to be
CDRs])

The cause of the problem: An interesting combination of 3 operations
being performed on channels, namely masquerading, and
forming local channels; add to that the hardwired 'roles' that channels
are given (channel, and peer), and the final knockout: CDRs are stored
on channels.

The above 3 operations affect CDR's because parking and transfers
can change the role that a channel plays (chan to peer or vice-versa);
Transfers and parking involve the masquerading, and sometimes local
channels--
both these operations involve duplicating a channel.  CDR's are meant for
the
channel playing the "channel" role, and CDRs on channels playing the "peer"
role are tossed out.

Transfers turn the above into a complex mush in which the results vary
depending
on who transfers who, who is calling, and who is called, etc. Because the
CDR's
are stored on the channels themselves, they pass thru many filters and
operations
that vary based on the roles they play and the operations performed, which
can change
in subtle ways from release to release, from one bugfix to another, even.

So, the best way to get around all this is to get the CDRs out of the
channels,
And to do that, you either use CEL, or you build your own event tracking
mechanism, using
whatever means available (I've seen folks use the manager event reports with
their
own logic in perl, or php, or whatever to do the parsing and storage). Then,
you either
turn the events into your own billing mechanism, or you generate CDR's to
fit into your
currently existing billing mechanism.  Doing this right
and making it dependable is not an overnight sort of thing.

I proposed a CDR generating backend for CEL (which I haven't completed yet).
I even started it, but got layed off before I could finish it. I've
generated a spec
for CEL->CDR generation, involving something I call "simple CDRs".This doc
has
been evolving with time, and needs to be updated. I  previously described
"complex"
CDR's in the spec that provided more fine-grained event logging in CDR
format, but I've convinced
myself that the complex stuff can also be done via the "simple" method, and
so I'm
about half way thru the spec, expunging the "complex" stuff. All my examples
have to be
changed -- If you are interested in looking at my spec, you can:

svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs

and look at the pdf there in that directory.

murf



Steve Murphy

ParseTree Corp.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Steve Murphy]

On Wed, Dec 1, 2010 at 7:41 AM, Sherwood McGowan  wrote:

> On Wed, Dec 1, 2010 at 6:56 AM, Nikhil  wrote:
> > anyone have a idea on this..
> >
> > On 11/22/2010 10:50 AM, Nikhil wrote:
> >> Hi everyone,
> >> I am facing lots for problem with CDRs in 1.6 and above
> >> versions,its shows wrong records when I do transfer(caller side and
> >> calee side),callforward,call parking.Is the present CDRs in 1.6 is
> >> enough for Complete billing.?What I need to do to make it
> >> proper.Please help me on this.
> >>
> >> Thanks
> >> Nikhil
> >
>
>
> I can tell you that back in 2005 I set up a complete
> residential/business VOIP ITSP that was using just the Asterisk CDRs
> to track billing. As long as you setup your billing, I see now reason
> wh
>
>
Oh, and by the way, Sherwood is correct; you can ignore everything I wrote
previously, IF you
don't do call transfers, and you don't park calls.

And even if you do a small amount of that, as long as no one forwards an
incoming call to some international destination, you'll probably be OK with
CDR's. If you don't mind losing a little chunk of the conversation here or
there,
the current CDR's should be sufficient for you, and you don't have to go
thru
any bother.

Just keep in mind that clever people can/will take advantage of the fact
that everything after an incoming call is transferred is lost to billing (as
an example).

murf



Steve Murphy

ParseTree Corp.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Sherwood McGowan]

On Wed, Dec 1, 2010 at 9:17 AM, Steve Murphy  wrote:

>
>
> On Wed, Dec 1, 2010 at 7:41 AM, Sherwood McGowan <
> sherwood.mcgo...@gmail.com> wrote:
>
>> On Wed, Dec 1, 2010 at 6:56 AM, Nikhil 
>> wrote:
>> > anyone have a idea on this..
>> >
>> > On 11/22/2010 10:50 AM, Nikhil wrote:
>> >> Hi everyone,
>> >> I am facing lots for problem with CDRs in 1.6 and above
>> >> versions,its shows wrong records when I do transfer(caller side and
>> >> calee side),callforward,call parking.Is the present CDRs in 1.6 is
>> >> enough for Complete billing.?What I need to do to make it
>> >> proper.Please help me on this.
>> >>
>> >> Thanks
>> >> Nikhil
>> >
>>
>>
>> I can tell you that back in 2005 I set up a complete
>> residential/business VOIP ITSP that was using just the Asterisk CDRs
>> to track billing. As long as you setup your billing, I see now reason
>> wh
>>
>>
> Oh, and by the way, Sherwood is correct; you can ignore everything I wrote
> previously, IF you
> don't do call transfers, and you don't park calls.
>
> And even if you do a small amount of that, as long as no one forwards an
> incoming call to some international destination, you'll probably be OK with
> CDR's. If you don't mind losing a little chunk of the conversation here or
> there,
> the current CDR's should be sufficient for you, and you don't have to go
> thru
> any bother.
>
> Just keep in mind that clever people can/will take advantage of the fact
> that everything after an incoming call is transferred is lost to billing
> (as an example).
>
> murf
>
>
>
> Steve Murphy
>
> ParseTree Corp.
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

Good call Steve! Your comment is spot on, as you said, transfers screw it
all up. My prior client did not allow transfers, since it was just a simple
VOIP provider service, without transfer capabilities for customers :)

Good to see you around!
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Nikhil]

Thanks,Now I understand the problem,Now I am trying to change CDR to fix 
these issues.


Thanks
Nikhil

On 12/01/2010 08:31 PM, Steve Murphy wrote:



On Wed, Dec 1, 2010 at 5:56 AM, Nikhil > wrote:


anyone have a idea on this..

On 11/22/2010 10:50 AM, Nikhil wrote:
> Hi everyone,
> I am facing lots for problem with CDRs in 1.6 and above
> versions,its shows wrong records when I do transfer(caller side and
> calee side),callforward,call parking.Is the present CDRs in 1.6 is
> enough for Complete billing.?What I need to do to make it
> proper.Please help me on this.
>
> Thanks
> Nikhil


Nikhil--

Yes, there is a problem with CDR's in asterisk. There is a bug filed
against the problem, but no practical solution for it.

The cure: use the CEL interface instead, and generate your own
CDR's (or whatever else you could bill from [it doesn't *have* to be
CDRs])

The cause of the problem: An interesting combination of 3 operations
being performed on channels, namely masquerading, and
forming local channels; add to that the hardwired 'roles' that channels
are given (channel, and peer), and the final knockout: CDRs are stored
on channels.

The above 3 operations affect CDR's because parking and transfers
can change the role that a channel plays (chan to peer or vice-versa);
Transfers and parking involve the masquerading, and sometimes local 
channels--
both these operations involve duplicating a channel.  CDR's are meant 
for the
channel playing the "channel" role, and CDRs on channels playing the 
"peer"

role are tossed out.

Transfers turn the above into a complex mush in which the results vary 
depending
on who transfers who, who is calling, and who is called, etc. Because 
the CDR's
are stored on the channels themselves, they pass thru many filters and 
operations
that vary based on the roles they play and the operations performed, 
which can change

in subtle ways from release to release, from one bugfix to another, even.

So, the best way to get around all this is to get the CDRs out of the 
channels,
And to do that, you either use CEL, or you build your own event 
tracking mechanism, using
whatever means available (I've seen folks use the manager event 
reports with their
own logic in perl, or php, or whatever to do the parsing and storage). 
Then, you either
turn the events into your own billing mechanism, or you generate CDR's 
to fit into your

currently existing billing mechanism.  Doing this right
and making it dependable is not an overnight sort of thing.

I proposed a CDR generating backend for CEL (which I haven't completed 
yet).
I even started it, but got layed off before I could finish it. I've 
generated a spec
for CEL->CDR generation, involving something I call "simple CDRs".This 
doc has
been evolving with time, and needs to be updated. I  previously 
described "complex"
CDR's in the spec that provided more fine-grained event logging in CDR 
format, but I've convinced
myself that the complex stuff can also be done via the "simple" 
method, and so I'm
about half way thru the spec, expunging the "complex" stuff. All my 
examples have to be

changed -- If you are interested in looking at my spec, you can:

svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs

and look at the pdf there in that directory.

murf



Steve Murphy

ParseTree Corp.




-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Nikhil]

Hi
I have small query that if my phone set callerid and anonymous(both 
name and number in from header),and make a call to asterisk,then the CDR 
shows

src: anonymous
dst:
clid:"Anonymous"" "
and etc

.Here the actual name of the src is missing,so how I bill for this 
call?.I planning to change the function that set src by parsing contact 
header instead of from,Is it fine?


Thanks
nikhil

On 12/02/2010 09:31 AM, Nikhil wrote:
Thanks,Now I understand the problem,Now I am trying to change CDR to 
fix these issues.


Thanks
Nikhil

On 12/01/2010 08:31 PM, Steve Murphy wrote:



On Wed, Dec 1, 2010 at 5:56 AM, Nikhil > wrote:


anyone have a idea on this..

On 11/22/2010 10:50 AM, Nikhil wrote:
> Hi everyone,
> I am facing lots for problem with CDRs in 1.6 and above
> versions,its shows wrong records when I do transfer(caller side and
> calee side),callforward,call parking.Is the present CDRs in 1.6 is
> enough for Complete billing.?What I need to do to make it
> proper.Please help me on this.
>
> Thanks
> Nikhil


Nikhil--

Yes, there is a problem with CDR's in asterisk. There is a bug filed
against the problem, but no practical solution for it.

The cure: use the CEL interface instead, and generate your own
CDR's (or whatever else you could bill from [it doesn't *have* to be
CDRs])

The cause of the problem: An interesting combination of 3 operations
being performed on channels, namely masquerading, and
forming local channels; add to that the hardwired 'roles' that channels
are given (channel, and peer), and the final knockout: CDRs are stored
on channels.

The above 3 operations affect CDR's because parking and transfers
can change the role that a channel plays (chan to peer or vice-versa);
Transfers and parking involve the masquerading, and sometimes local 
channels--
both these operations involve duplicating a channel.  CDR's are meant 
for the
channel playing the "channel" role, and CDRs on channels playing the 
"peer"

role are tossed out.

Transfers turn the above into a complex mush in which the results 
vary depending
on who transfers who, who is calling, and who is called, etc. Because 
the CDR's
are stored on the channels themselves, they pass thru many filters 
and operations
that vary based on the roles they play and the operations performed, 
which can change

in subtle ways from release to release, from one bugfix to another, even.

So, the best way to get around all this is to get the CDRs out of the 
channels,
And to do that, you either use CEL, or you build your own event 
tracking mechanism, using
whatever means available (I've seen folks use the manager event 
reports with their
own logic in perl, or php, or whatever to do the parsing and 
storage). Then, you either
turn the events into your own billing mechanism, or you generate 
CDR's to fit into your

currently existing billing mechanism.  Doing this right
and making it dependable is not an overnight sort of thing.

I proposed a CDR generating backend for CEL (which I haven't 
completed yet).
I even started it, but got layed off before I could finish it. I've 
generated a spec
for CEL->CDR generation, involving something I call "simple 
CDRs".This doc has
been evolving with time, and needs to be updated. I  previously 
described "complex"
CDR's in the spec that provided more fine-grained event logging in 
CDR format, but I've convinced
myself that the complex stuff can also be done via the "simple" 
method, and so I'm
about half way thru the spec, expunging the "complex" stuff. All my 
examples have to be

changed -- If you are interested in looking at my spec, you can:

svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs

and look at the pdf there in that directory.

murf



Steve Murphy

ParseTree Corp.






-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing

[Sherwood McGowan]

On Wed, Dec 1, 2010 at 11:42 PM, Nikhil  wrote:
> Hi
>     I have small query that if my phone set callerid and anonymous(both name
> and number in from header),and make a call to asterisk,then the CDR shows
> src: anonymous
> dst:
> clid:"Anonymous"" "
> and etc
>
> .Here the actual name of the src is missing,so how I bill for this call?.I
> planning to change the function that set src by parsing contact header
> instead of from,Is it fine?
>
> Thanks
> nikhil
>
> On 12/02/2010 09:31 AM, Nikhil wrote:
>
> Thanks,Now I understand the problem,Now I am trying to change CDR to fix
> these issues.
>
> Thanks
> Nikhil
>
> On 12/01/2010 08:31 PM, Steve Murphy wrote:
>
> On Wed, Dec 1, 2010 at 5:56 AM, Nikhil  wrote:
>>
>> anyone have a idea on this..
>>
>> On 11/22/2010 10:50 AM, Nikhil wrote:
>> > Hi everyone,
>> >     I am facing lots for problem with CDRs in 1.6 and above
>> > versions,its shows wrong records when I do transfer(caller side and
>> > calee side),callforward,call parking.Is the present CDRs in 1.6 is
>> > enough for Complete billing.?What I need to do to make it
>> > proper.Please help me on this.
>> >
>> > Thanks
>> > Nikhil
>
> Nikhil--
>
> Yes, there is a problem with CDR's in asterisk. There is a bug filed
> against the problem, but no practical solution for it.
>
> The cure: use the CEL interface instead, and generate your own
> CDR's (or whatever else you could bill from [it doesn't *have* to be
> CDRs])
>
> The cause of the problem: An interesting combination of 3 operations
> being performed on channels, namely masquerading, and
> forming local channels; add to that the hardwired 'roles' that channels
> are given (channel, and peer), and the final knockout: CDRs are stored
> on channels.
>
> The above 3 operations affect CDR's because parking and transfers
> can change the role that a channel plays (chan to peer or vice-versa);
> Transfers and parking involve the masquerading, and sometimes local
> channels--
> both these operations involve duplicating a channel.  CDR's are meant for
> the
> channel playing the "channel" role, and CDRs on channels playing the "peer"
> role are tossed out.
>
> Transfers turn the above into a complex mush in which the results vary
> depending
> on who transfers who, who is calling, and who is called, etc. Because the
> CDR's
> are stored on the channels themselves, they pass thru many filters and
> operations
> that vary based on the roles they play and the operations performed, which
> can change
> in subtle ways from release to release, from one bugfix to another, even.
>
> So, the best way to get around all this is to get the CDRs out of the
> channels,
> And to do that, you either use CEL, or you build your own event tracking
> mechanism, using
> whatever means available (I've seen folks use the manager event reports with
> their
> own logic in perl, or php, or whatever to do the parsing and storage). Then,
> you either
> turn the events into your own billing mechanism, or you generate CDR's to
> fit into your
> currently existing billing mechanism.  Doing this right
> and making it dependable is not an overnight sort of thing.
>
> I proposed a CDR generating backend for CEL (which I haven't completed yet).
> I even started it, but got layed off before I could finish it. I've
> generated a spec
> for CEL->CDR generation, involving something I call "simple CDRs".This doc
> has
> been evolving with time, and needs to be updated. I  previously described
> "complex"
> CDR's in the spec that provided more fine-grained event logging in CDR
> format, but I've convinced
> myself that the complex stuff can also be done via the "simple" method, and
> so I'm
> about half way thru the spec, expunging the "complex" stuff. All my examples
> have to be
> changed -- If you are interested in looking at my spec, you can:
>
> svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs
>
> and look at the pdf there in that directory.
>
> murf
>
>
>
> Steve Murphy
>
> ParseTree Corp.
>
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

Well, the first thing that pops into my head is, try setting
accountcode for your sip endpoints, so that you have something that
will identify the "customer" for billing purposes. You can also use
setvar to set a different variable (such as the phone number) which
can then be used in some way to update the CDR with an identifier
specific to the customer.

Proost,
Sherwood

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs: