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

[Arek Bekiersz]

Hi Jiri,

Please see inline:


----- Original Message ----- 
From: "Jiri Kuthan" <jiri at iptel.org>
To: "Arek Bekiersz" <sip at perceval.net>; "Greger V. Teigre"
<greger at teigre.com>
Cc: "Serusers" <serusers at iptel.org>; "David R. Kompel" <drk at drkngs.net>;
"Weiter Leiter" <bp4mls at 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/