26 Sep
2006
26 Sep
'06
1:49 a.m.
...
At 23:58 24/09/2006, Arek Bekiersz wrote:
Believe me, I couldn't have done what I have done
without SOAP. I will keep developing SOAP
related stuff for SER. First because I have to (for the project) and second because I
believe this is the best way to achieve seamless integration of SER into corporate
workflow based OSS systems. I will try to publish results of that work, if possible.
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:
--------
Read, agreed.
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:
-------
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 :-))
Other curiosity question: is this something we are discussing within the roadmap
debate, or do people have some running code to share?
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/