Just became
curious -- my favorite question, did you do it as a
standalone
piece of
software which "feeds" SER database, or as a part of SER? Is that the
piece of work
which is falling under your non-disclosable development?
Arek:
The answer is twofold:
a) outside of SER, a stand-alone application+web server that feeds SER
dbase
(mysql and ldap) and remote Asterisks dbs.
b) partially inside of SER (some modifications + ldap module, that by the
way still exists in cvs exp. directory). I've begun moving it to latest
devel version some time ago, but lack of time...I keep the faith ;-)
:-) Good. For
0.10 we will most likely get rid of experimental and move
the modules into the standard tree.
what do you
call "proper CDR collector"? (I intuitivelly guess I
agree but
am not 100% sure we are speaking about the same).
Arek:
Well, it depends. I will say straight: I'm still supporting the idea
of Web
service IPDR inteface towards the acc module, or a new module. On every
request for IPDR data they would do query in SER's native acc dbase, find
matching INVITE-BYE pairs, calculate duration, disconnecting party
etc. and
return the IPDR data in web service response.
This is exactly where I have a problem:
a) SER is a server for SIP messages. Period. Not http, not SOAP over
TCP, nothing. Even the management interface can be invoked through SIP
and the SIP code is used to handle incoming requests even for non-SIP
requests
b) Doing costly DB lookups only drags down SER and why should it?
Advantage: No need to have separate dbase for CDR,
storing complete call
information (time of start, end & duration), as everything is calculated
on-the-fly, per web service request basis.
Disadvantage: Possible slowliness or freezing of SER module, when
there are
tens of thousands of entries in SER acc db.
Exactly.
It might be combined with dialog module, to show calls
in-progress as
well
(establishing, ringing, diverting). It is all all as described in IPDR
VoIP
profile (see callProgressState in
www.ipdr.org/service_specs/VoIP/VoIP3.1-A.0.2.pdf).
But I'm not sure anymore. Maybe it is realy better to keep it outside,
have
separate IPDR db and just run a cron job to update it every minute or
two? I
do it like that now, by the way. To be discussed.
An IPDR provider can easily be
built as a gsoap service (either running
under apache or standalone). An ipdr SER module can communicate with
the IPDR provider using soap.
Benefits:
- Your IPDR provider can real time do queries into one or more SER
accounting databases, locally or over a private management network
- You can do accounting to a mysql cluster from many SER instances
- You only need one IPDR provider for your SER installation
- You get the scalability you want for each SER server
- You can isolate the IPDR soap-based provider on a separate server (as
it has very different security and scalability requirements)
g-)