26 Sep
2006
26 Sep
'06
11:42 a.m.
Hi Jiri,
Please see inline:
----- Original Message -----
From: "Jiri Kuthan" <jiri(a)iptel.org>
To: "Arek Bekiersz" <sip(a)perceval.net>et>; "Greger V. Teigre"
<greger(a)teigre.com>
Cc: "Serusers" <serusers(a)iptel.org>rg>; "David R. Kompel"
<drk(a)drkngs.net>et>;
"Weiter Leiter" <bp4mls(a)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)
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:
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/).
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:
-------
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:
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.
-------
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 :-)) 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/