VoIP Mailing List Archives

[regs at kinetix.gr]

Hi,

I saw in the wiki that the mod_cdr module is now unsupported. There
is also a note
about a revival of the module. I would like to ask the following :

What is the current state of the revival process? (should we expect
something in the near future?)

Will it have the same functionality as before (DB support for instance)?

Are there any plans for a brand new database specific event handler module?

It would be great if there was one so that developers (especially those
who develop
billing applications) would not have to create their own hacks (cron
scripts etc.)

Thank you for your time,

--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com Support Center

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[mike at jerris.com]

Unsure at this time. There has been some work on mod_cdr_odbc. We
generally advise against direct to db cdr methods without a very
robust backup method for when the db is down.

On Oct 29, 2008, at 9:57 AM, "regs@kinetix.gr" <regs@kinetix.gr> wrote:

[regs at kinetix.gr]

Yes, I agree. But one could use the two methods combined (csv or xml +
db) for redundancy.

Is there any consideration regarding automatic log rotation (e.g.
hourly, or user specified)
without the need of a HUP? Now, that could make things a lot easier for
the development of
an external csv to db aggregation script because the script would read
from a closed (not used by freeswitch
at the time) CDRs file. And the developer could be sure that the cdrs
contained in that file would
have a hangup timestamp that could be described by the filename (e.g.
20080101_010000.csv).

Michael Jerris wrote:

[regs at kinetix.gr]

Yes, I agree. But one could use the two methods combined (csv or xml +
db) for redundancy.

Is there any consideration regarding automatic log rotation (e.g.
hourly, or user specified)
without the need of a HUP? Now, that could make things a lot easier for
the development of
an external csv to db aggregation script because the script would read
from a closed (not used by freeswitch
at the time) CDRs file. And the developer could be sure that the cdrs
contained in that file would
have a hangup timestamp that could be described by the filename (e.g.
20080101_010000.csv).

Michael Jerris wrote:

[mcollins at fcnetwork.com]

[regs at kinetix.gr]

Yes, the xml files give you tons of info... but isn't it a little
insufficient - performance wise -
to open and close so many files in such a little time. In a PBX
environment that wouldn't be an
issue but if we get to the small-voip-carrier level (some thousand cdrs
per hour)
that could slow things down considerably, wouldn't it?

Thanks again for your prompt replies,

Michael Collins wrote:

[shawnl at waterwheelne...]

In regards to auto log rotation - YES YES

ANTHM just completed that item for me, where by you can set the time in
minutes i believe it was.

I have not tested it yet, hope to this week.

Shawn


Michael Collins wrote:

[regs at kinetix.gr]

That's very good news.

Shawn Lewis wrote:

[mcollins at fcnetwork.com]

[regs at kinetix.gr]

Good point. I have got this kind of behavior (cdrs push model) in my current system (using radius servers).
The only drawback of this method is that if you want to be absolutely sure that all the cdrs were handled by
the web server (or radius server) you have to check at certain intervals every cdr one by one (and handle those left
unhandled for various reasons (network, excessive web server load etc.))

But for my next project I am somewhat forced to use a "cdrs-pull" method where a process will "pull" cdrs
from the server at its own pace making this extra check unnecessary.

I will wait for an automatic log rotation as Shawn Lewis wrote. I think that will do the job.

Michael Collins wrote:

[dave at 3c.co.uk]

regs@kinetix.gr wrote:

[regs at kinetix.gr]

[dave at 3c.co.uk]

The sleep's done each time the directory's empty, not each time a file's written. File open and close
are trivial (it's probably still cached), and the contents are going to have to be parsed wherever you
process it.

We've used exactly this to process deliver CDRs on boxes handling in excess of 500K mins/day
without issue. And, looking at one now, the CDR processor's used about 4% of the CPU time
of FreeSWITCH, and about half that of the MySQL database which it writes the records to, also
on the local machine, from which they're simply copied to the main CDR processor.

It performance simply isn't worth worrying about.

--Dave

[regs at kinetix.gr]

I'll try some tests with various combinations first and then decide what's best.

I have to say that I was astonished to find out that freeswitch had so many event handlers from the very beginning.
However it would be great if freeswitch had the options for extra functionality (auto log rotation, db cdrs etc)
so that it meets the peculiarities of every different project. That would make a big difference compared to
other softswitch solutions where the lack of such features prohibits people from using them (especially in
the carrier grade level). User feedback (and wish lists) is the key for the success of an open source (or not)
project...

Thank you all for your replies. You' ve been very helpful.

David Knell wrote:

[anthony.minessale at g...]

Actually,

The goal is to not limit the functionality by over thinking how things will be used but to provide building blocks to make much
more possible. Our analogy for this is that if you take the common lego reference, If you have something cool built out of legos but they are super glued together it limits what you *could* have done had then not been.

The system that David described is indeed ideal. I have mentioned it more than once and its no coincidence that FreeSWITCH plays into that model to a tee. I do not mention it very often because I think understanding that concept alone is valuable advice that I'd prefer not to waste on deaf ears so I recommend you heed his suggestion.

Logging direct to DB is not a sin or anything but it's just not very reliable. We have so many ways to process call records as it is.
you can use the cdr_csv if you want legacy support from asterisk that you can eventually tweak with templatable output, you can even make a template that generates the log as ready to roll sql statements you can just cat into mysql.

We have event_socket + channel_hangup event which has all the same info that the cdr_csv uses to generate the file.
We have the XML cdr that is a 3 dimensional view of the call with an account of nearly everything that happend including
each application executed, branching records when the call is transferred complete with a timestamp for each occurance.

--"However it would be great if freeswitch had the options for extra functionality (auto log rotation, db cdrs etc)
so that it meets the peculiarities of every different project."

A single cron entry that does kill -HUP `cat freeswitch.pid` and you have automatic rotation in unix.
In windows there are several cron equivs and instead of kill you can use an xml-rpc script to call the FSAPI call "fsctl send_sighup"
also you can schedule it to happen automaticly with the FSAPI

sched_api @300 mygroup fsctl send_sighup

A script connected to event socket subscribed to channel_hangup can act as your DB cdr engine and has the bonus that it could
connect to N boxes at once as well as be able to tell if the system was in trouble by listening for system heartbeat events and or socket disconnect.

Moral of the story, there is more already there than first appears. I've always hated the M$ paper clip so I strive not to bring him back.
"It looks like you are trying to run a VoIP termination company! Shall I assume how you want your call details?"



On Thu, Oct 30, 2008 at 7:43 AM, regs@kinetix.gr (regs@kinetix.gr) <regs@kinetix.gr (regs@kinetix.gr)> wrote: