Hi Jiri,
Please see inline:
----- Original Message ----- From: "Jiri Kuthan" jiri@iptel.org To: "Arek Bekiersz" sip@perceval.net; "Greger V. Teigre" greger@teigre.com Cc: "Serusers" serusers@iptel.org; "David R. Kompel" drk@drkngs.net; "Weiter Leiter" bp4mls@googlemail.com Sent: Tuesday, September 26, 2006 12:49 AM Subject: Re: SOAP/XML-RPC experience, etc. (was RE: [Serusers] What do you have against SOAP? (was Carrier-grade framework for SER)
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 ;-)
For this 'non-disclosing stuff' I mean the SER-outside stuff. If you wish, I can share with you WSDLs of these Web services and a paper manual, on private email. You could poke that material and see if it is of any help?
Anyway, I would love to move the 'outside stuff' inside of SER, to become one or more new modules. Such module(s) would have built-in Web server. Still thinking of gSoap with its small footprint... (www.cs.fsu.edu/~engelen/soap.html).
Years are passing and we still do not have proper IPDR compliant CDR collector. Every poor SER newbie have to write those little scripts to extract those date, time and duration of his calls. Let's give them proper CDR collector (IPDR recorder I mean) in real-time. The rest of IPDR, non-real time stuff - keep inside module as well of throw away from SER - to be decided.
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.
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.
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.
Arek:
And let me enlighten you, Greger ;-) I've mentioned ParlayX Web services, to make it easy for Parlay and Web service geeks to build custom application servers. I found it to be a nice alternative, to have well documented standard interface from SER server towards Application Server. I gave an example of SER receiving a SIP call to a number, then preparing and sending Web service message to Application Server.
Upon receiving answer from Application server, SER servce could act on SIP message. Action taken could be one like: forward here, forward there or send him a '486 Busy Here'. I proposed that because I had a nice application server (with Web service interfaces) in my company and I was looking for some standard way to talk to this server. I though that: writing ParlayX Web service module for SER + modifying Application Server to have ParlayX compliant interfaces would be a really sexy solution to build applications like prepaid, prepaid with flat fee, multimedia services, etc.
Feel free to correct me if I'm wrong.
I am not sure -- some ideas have grown too big for a successful birth and parlay may be one of those, but that's of course my own guess. (Hope I don't sound discouraging, I'm just wondering what people think about that opinion.)
Arek: Well,... I share the same opinion about some heavyweight ideas. But there are people tinkering with Parlay, take Ericpol company, from my home city, as an example: (http://www.ericpol.pl/www/en/).
Arek:
YES it would. I really could send you today an WSDL of such service running at our premises for 2 consequent years. I just cannot do it because of confidentiality reasons. But will try to go with it to open source as soon as possible.
Greger:
- I feel an IPDR module could be a good addition to SER, as long as it
does not try to do something a SIP server is not meant to be
Arek:
I Agree. Believe me, I don't want to make SER a washing machine with dryer either. I just want to give people a compliant CDR recorder, to have a nice basis to build their billing applications.
Greger:
- SNMP would be a good addition
Arek:
Yes it would be. We are ready to work on MIB for that in our company (I got a really good specialist for SNMP here, next to my desk).
Just my 2 cents -- if people are interested in my feedback, the way I would build it is an "agent" which gathers the data from SER using existing interface and exports it to the world using SNMP. (Using your vocabulary, that's generally my favorite approach to avoid embedded washing machines in SER :-))
Arek: I'm generally supporting idea of extending SER itself, in form of modules. It is for people, to make their installation easier. You know - download, make, install and become ISP in one day, no questions asked on mailing lists.
From the other side we cannot put new washing machine inside SER every other
day. Otherwise we would overload it with features so much, that we would have to remove the 'E' (Express) letter from SER name :-) All to be discussed.
Other curiosity question: is this something we are discussing within the roadmap debate, or do people have some running code to share?
Arek: I would say it is rather a roadmap discussion. Sorry for that - it was Greger who began with this thread again ;-)))
-- Regards, Arek Bekiersz
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/