SOAP/XML-RPC experience, etc. (was RE: [Serusers] What do you have against SOAP? (was Carrier-grade framework for SER)

[Greger V. Teigre]

>> 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-)