[Serusers] Proposal for new features

[Arek Bekiersz]

Hi,


As my current work may be interesting
for the rest, I wonder if you will find those new features useful.
Every opinion is appreciated.

Some time ago I commited a small 'ldap' module, all-in-one.
As there was some (small :-) ) feedback from people using this module, I 
propose to split it into following modules:

1) auth_ldap: set of authentication routines, working with standard or
user-defined Ldap schemas

2) group_ldap: group membership module based on Ldap backend

3) uri_ldap: uri mangling module, based on ldap backend

4) avp_ldap: (new) module for operating on AV-pairs from Ldap, working
with both user-defined or standard dbase schemas




Later, it is possible to write small SER 'soap' modules, using one of
freely available C/C++ soap libraries. Those modules will perform
various tasks:

5) soap_ipdr: module for reporting service usage information (billing) 
in XML, to be used by external billing systems. Information will include 
all call attempts (also failed ones like CC,CAD,UCN,UCI and possibly CID
completion codes from IPDR's VoIP service definition). It will return
following XML documents (using SOAP as transport):
* IPDRDoc - usage for specific user (user at domain)
* IPDRSettlementDoc - usage for domain

NOTE: that using IPDRSettlementDoc for domain is based on model where
our cooperants have one virtual SIP domain. it is then easiest way to
make settlement using IPDRSettlementDoc for one domain.



6) soap_parlayx: Such module would act as a gateway between SER and
external Parlay X Web Services software. When called, this module will
analyze SIP request and forward it to external Parlay X software. That
software will fulfill request and return ReturnValue, with specific
Action. Then SER soap_parlayx module will perform desired action on SIP
request.
More on Parlay X Web services v.2.0 can be found at:
http://www.parlay.org/en/specifications/

NOTE: This behaviour mimics a hypothetic SIP-CGI gateway, but this time
it is a SIP-SOAP gateway.

EXAMPLE: could be the HandleBusy operation from "Part 3: Call
Notification" of Parlay X Web services:

1. SIP encounters "486 Busy" situation
2. SER Script writer calls parlayx_handle(HandleBusy) function from
soap_parlayx module
3. soap_parlayx module calls external software, sending
handleBusyRequest, containing CallingParty, CalledParty
4. external software returns handleBusyResponse with Action structure,
containing ActionToPerform (like 'route' on not route), RoutingAddress,
Charging (charge for using of service)
5. SER soap_parlayx module modifies SIP request and forwards it to
voicemail_SIP location. In addition it stores relevant info in IPDR data
recorder for later use.

External Parlay X software will be basically a SOAP engine, it can be
written in any language. Unlike a soap_parlayx module itself, that
engine will not be a part of SER.





7) SIP SOAP initiative
Seems that IP world is slowly evolving in direction of service
enabled architecture, usually based on SOAP/UDDI standards. For this
reason maybe it is worth to initiate work on SIP SOAP draft standard?

It would basically mimic existing IETF SIP CGI draft standard, but with
far greater opportunities for creating new services, that SOAP standard
brings.
It will beautifuly fulfil current work in progress in my company and an
European project, codename VISP (Virtual Internet Service Provider),
that we are coordinator of. Project is focusing on enabling smooth
company-to-company interoperability in mutual creation of new services 
in fast changing IP world. Including VoIP. More information can be found 
on Web site:
http://www.visp-project.org/



-- 
Regards,
Arek Bekiersz