[Serusers] Proposal for new features

[Jan Janak]

Arek Bekiersz wrote:
> 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

  2-3 can be actually merged into 1). Latest SER code retrieves additional
  information during authentication and stores it in attributes, which are
  then accessible in the configuration script. So all you would need to do
  is to retrieve a set of name-value pairs during authentication and all
  operations like group or uri checking can be done in the script.

  This has the advantage of being much more efficient, because you can get
  all the info about the caller from LDAP in a single LDAP query. Furthemore
  it is also easier to implement. RADIUS authentication, for example, works
  exactly this way.

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

  What is the difference between standard and user-defined dbase schemas ?
  I am interested in having good LDAP support, but before implementing
  anything I think we should try to find out whether we could perhaps live
  with single ldap module that would implement the database API, as
  mentioned earlier by Jiri. In the script you would do then:

  modparam("auth_db", "db_url", "ldap://..")

  And then you can use standard auth_db and other modules. Could you perhaps
  try to describe the structure/schema of the LDAP database, so that we
  can see whether something like this would be possible ?

> 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.

  I guess this would be best handled using a standalone daemon. There is
  a special module called flatstore which can be used to implement simple
  accounting spool. All accounting requests are stored on local filesystem
  in form of plain text files. You could then write a daemon which would
  take the files periodically and send them over IPDR/XML/whatever.

  This way you can still keep SER fast, if there is something wrong with
  the SOAP/IPDR service then SER will just continue writing accounting
  requests to flatstore and the external daemon will catch up later once
  the SOAP/IPDR service recovers.

> 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.

  I guess this would be similar to OSP (Open Settlement Protocol) module.
  Take a look at
  http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/osp/

    Jan.

> 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/
> 
> 
>