[Serusers] Proposal for new features

[Arek Bekiersz]

Jan Janak wrote:


>>1) auth_ldap
>>2) group_ldap
>>3) uri_ldap
>   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.

Yes. Sounds OK for me.
If user wants to actually modify values of some attributes during 
request handling in ser script, he could use the 4 module, 'avp_ldap'.




>   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://..")

I mentioned that user should be allowed to provide the names of 
objectClasses or attributes that he uses in his database to ldap backend 
. Those names should be passed as module parameters in ser config 
script. I did it more or less this way in my ldap module.

So when user has some custom database schemas (that is: he defined his 
own objectClasses or attributes), he could use them with this module as 
well.


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

I tried in previous email.
Bsically as you see this mail, I added objectClass to hold SIP user 
data. It is auxiliary object class, anc dontains elements like SIP URI 
(userinfo at domain), SIP password, givenName, surname, mail, service allow 
flag, SIP group, default Country Code prefix, default Local Area Code, 
preferredLanguage, list of SIP aliases (like real E.164 numbers), short 
textual description.
It is more or less what people are putting in flat databases plus some 
goodies.



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

Actually I use SER's native acc database. I then run external 
application to collect all necessary information and present it later in 
IPDR format.
For me, having an external application to do it is OK.
I described a concept of external "sermanager" the other day. I think 
such 'sermanager' could be a good place to do billing & reporting stuff.



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

Yes, I know 'osp' module a little. Well, the proposed 'soap_parlayx' 
module could be similar, except is actually uses external Web services, 
not external OSP server as 'osp' module.

Idea was to provide yet another routing alternative to people, willing 
to write Parlay X compliant external routing engines and then just 
calling them from inside of config script, to tewll SER what to do. In 
simpliest form it can just rewrite Request-URI and retirn soem value 
(success,failure, no-op).



-- 
Regards,
Arek Bekiersz