[Serusers] Proposal for new features

Sun Feb 26 21:49:36 CET 2006

Hello,

Let me clarify my yesterday's proposal for new features.

1) New modules:
a) auth_ldap
b) group_ldap
c) uri_ldap
d) avp_ldap

It would be desirable for these modules to re-use existing dbase abstraction
layer in SER.
So to treat Ldap as just one more backend. So far the Ldap support was
created in an ad-hoc manner, without regard for global dbase approach.

Jiri Kuthan kas proposed to do "one module, which would act as a single LDAP
driver for all
DB-based modules". I think that this is something similar - having a common
way (a driver) to access LDAP and then having all standard modules to just
reuse this new ldap backend.

2) "soap_ipdr" module versus "sermanager" idea
I proposed to embed IPDR reporting tool for billing in a new SER module. But
after some discussion I think maybe the better option is to create this as
an external C application. It would be a stand-alone application using gSOAP
library, containing built-in simple Web server. Application could be called
"sermanager" and could provide SOAP interfaces for user at the one side and
connect to SER subsystem on the other. To connect to SER it would use sql,
fifo, ldap or other technologies that are applicable for particular SER
installation - it would be configurable by administrator. It would serve as
a middlelayer (mediation software), providing vast set of functionalities
for user,and freeing SER core from any additional work. SER will just serve
for call routing/reporting.

I observed that the same idea happening in Asterisk. They will have external
application called 'manager' that provides easy-to-use XML-RPC and SOAP
interfaces to the world, at the same time speaking with Asterisk using AGI
or simple file operations. Their reason was also to free Asterisk from
additional work and create separate application entity to handle broad set
of user-friendly functions.

"Sermanager" could contain functions divided in different areas of interest.
They could be added as modules, so for example when user does not wish to
use billing, he just unloads relevant module. I propose to split
functionalities into following separate Web services (called "engines"). Of
course every engine and every function will be accessible by different
classes of users. Access information will be stored in small accompanying
sql database or ldap backend, according to administrator wish.

a) "call_register" engine - call reporting (calls made, received, missed),
without call costs. It will be in proprietary format, to be agreed. In
addition calls made will be exported in standard IPDR format, VoIP profile.

b) "billing_management" engine - call costs reporting in proprietary format.
This element will depend on external Web Services (BSS systems, SAP and
others). On request from user, "sermanager" will send list of calls to this
external service and retrieve calculated costs of calls.
Then it will send this list to user.

c) "users_management" engine - adding, deleting, modifying users (either
single users or batches of users)

d) "domain_management" engine - adding, deleting, modifying SIP domains.
Optional - we have many domains on every single server, so we have tools to
add dbase entries and eventually DNS entries. Not everybody will need that.

e) "registrar_management" - functions to export list of registered users per
domain/per server.

f) "system_management" - reporting of SER statistics, export of SER log
messages, current transactions, memory utilization, etc.

g) "terminal_management" - adding,deleting,modifying user agents, storage of
device data and configuration files, etc.

h) "voicemail_management" - retrieving/deleting/modifying remote voicemail
files on voicemail servers, such as Asterisk or SEMS. Voicemail messages
will be returned in SOAP Body or as MIME attachment. Engine will require
external Web service to run on Asterisk or SEMS machines. Unless we will
have Web services from Asterisk that will provide access to voicemail
functions - it may happen soon. Until then I can provide set of Web services
to handle voicemail on Asterisk.

i) "phonebook_management" - adding/modifying/deleting phonebook entries in
both: private and public phonebook, retrieving entries, searching for
entries

j) "service_management" - initiating calls with REFER, initiating calls
directly at User Agent (like Asterisk call-out), or other services,
depending on needs. It may serve in future to add services like: automatic
call-out campaigns, integration with SMS gateways and others

Other functions may include: Instant Messaging and Presence capabilities,
like: sending Instant Message or SMS, getting list of messages, getting
buddy status and/or location, etc. It is to be discussed as most of those
functionalities are also provided by SIP itself.

Imagine the possibilities of having a SIP software phone with build-in SOAP
client. Then you can easily integrate a server-stored public or private
phonebook, create a buddy list that will reporting their online status and
so on.

When the "sermanager" application is ready, I can to provide associated Web
interface as well. It will be called "serwebmanager" and it can be placed on
the same server as "sermanager" or remote dedicated Web server. It will
speak with "sermanager" with SOAP and will generate viewable Web content
using XSLT. It could be used by both single account users and system
administrators. One advantage of such approach (apart for real simplicity of
"sermanager" PHP scripts) is that the content may be quickly adopted to
different classes of end devices such as: HTML browsers, WAP browsers or
simplified XML browsers. Imagine the possibilities of having a SIP
videophone with simplified HTML 4.0 Web browser build in and being able to
login to your personal SER profile Web page and manage your calls, diverts
and voicemail messages.

3) The "SIP-SOAP gateway" functionality.
Ideology behind that proposal was to add new option to SER routing, to ask
external application about what to do with incoming SIP request. So how to
route it, in example:
a) discard
b) rewrite URI
c) forward as is
It is basically the same idea as in SIP CGI RFC3050, but done with SOAP
instead of CGI interface.

I have chosen Parlay X Web Services 2.0, because they provide a complete
model for Web service definition and message exchanges. We just need to
create one or two functions in SER routing to be able to ask external Web
service. And to perform some action upon receiving an answer.

Here, the concern may be a possible decrease of SER perfomance when
connecting with SOAP or parsing XML. But I propose to use gSOAP library and
as seen on its Web page http://gsoap2.sourceforge.net/ in Perfomance area,
the well written gSOAP application is capable of handling approx.3000
roundtrip message exchanges per second. My rough estimate is that single
system would not be saturated for system with up to 50k-60k subscribers. Of
course provided that processing time of the actual application behind gSOAP
is relatively small.

To facilitate discussion I attach the drawing of target architecture.
Please tell me what you think.

--
Regards,
Arek Bekiersz

----- Original Message ----- 
From: "Jiri Kuthan" <jiri at iptel.org>
To: <sip at perceval.net>; "Serusers" <serusers at lists.iptel.org>
Sent: Sunday, February 26, 2006 7:47 PM
Subject: Re: [Serusers] Proposal for new features

> I would actually like one module, which would act as a single LDAP driver
for all
> DB-based modules, as opposed to rewrite every single module outthere using
LDAP.
> May be a bit tricky with the LDAP hierarchical module, but still doable.
>
> jiri
>
> --
> Jiri Kuthan            http://iptel.org/~jiri/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sermanager_proposal.jpg
Type: image/jpeg
Size: 24638 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060226/e577ae4b/attachment.jpg>