[OpenSIPS-Users] Database and other high-level functionality (was: Re: Sqlops in opensips ?)

[Alex Balashov]

Bogdan,

Bogdan-Andrei Iancu wrote:

> When comes to none-SIP related stuff, there is a logical limit of what 
> should be in or not - after all we do a SIP server and not a DB wrapper, 
> neither a XMLRPC server, not an advanced language interpreter (and so one).

I can certainly appreciate that.  In principle, I agree that at the end
of the day, underneath it all, OpenSIPS is a SIP proxy, along with some
lightweight UAS features (registrar, presence user agent, etc.).

It's still much more a piece of service delivery *infrastructure* - it
is low-level relative to some other network elements that frequently
make their appearance in the open-source VoIP ecosystem.  No argument
there.

But I think this does have to be balanced with the reality that a great 
deal of the OpenSER technology stack's usefulness does come from the 
fact that it can be deployed in application-aware configurations, the 
extensibility of the route script, and so on.  This ability to add 
intelligence and integration paths is precisely where it has an edge 
over the expensive commercial proxies and, in certain situations, SBCs.

> To give you an example of how I see this delimitation of what should be 
> in OpenSIPS and what not. Let's take the DB case (anyhow the discussion 
> started from there): the current DB support in script is a very decent 
> one (via the avpsops functions) - you can do mostly all types of queries 
> and DB interaction. If you need something more complex (from DB), I 
> think you must work on the DB side and do the enhancements there. Make 
> no sense to invest effort in doing super DB stuff in a SIP server, when 
> the DB engine itself may already offer this support.

Sure, but taking advantage of some of the more sophisticated DB 
capabilities on the back side also requires adequate interfaces on the 
front side.  For example, how does one deal efficiently and easily with 
multiple rows returned by a DB query?  At present the only way is to 
iterate through AVP arrays in a rather obfuscated manner that is hard to 
understand and not particularly terse.

All this benefits from improvements to language syntax and semantics as 
well as the DB layer.

> Again, an example - couple of weeks ago I had to interface OpenSIPS with 
> some really complex data structures in a postgres DB - the solution was 
> simple - some postgres procedures were created to hide the DB complexity 
> and also to incorporate some logic. Form OpenSIPS point of view, the 
> problem was reduced to running a select over the procedures.

I completely agree.  In fact, this is exactly how I have been doing my 
work (I almost exclusively use Postgres) for years precisely because of 
the fact that the route script does not have the capabilities of a 
general-purpose programming languages, including native support for 
nontrivial primitives and other semantics that are needed to do that 
kind of logic programmatically.  I rely very heavily on stored 
procedures and triggers.

Nevertheless, the interface could use some enhancements to make this 
coupling easier.  It's just little things.  Like, for example, right 
now, if you issue a DB query that returns no rows, you need to use 
is_avp_set() to check whether the corresponding AVP(s) are set.

> So, the effort is better focused on SIP part rather is peripheral 
> interaction, where we can use the already existing and specific tools 
> and mechanism.

Nevertheless, a lot of the peripheral tools hold the key to a great deal 
of the value.  I invite you to remember why OpenSER grew to such 
popularity after the fork with SER in 2005:  it is the mass of 
community-contributed modules and novel functionality.  SER may have 
focused on a good core, but OpenSER could be said to have won precisely 
because of the additional baked-in capabilities.

Whatever your opinion of bells & whistles modules, I think it is very 
important to preserve the inherent benefit offered by most open-source 
software compared to proprietary alternatives:  the integration paths. 
Asterisk for example has AGI and the Manager interface, which both allow 
outside processes and outboard logic controllers to touch and manipulate 
the engine.  MI[_DATAGRAM], XML-RPC, and a relatively flexible route 
script are all very important for that reason.  The capability to 
integrate is paramount above all else, and is a governing factor in the 
technology choice.

> About the place of the DB related stuff - well, originally they were 
> operating only with AVP and this is why they were put in the avpops. 
> Now, indeed, there is no dependency for this, but the questions is what 
> will be the advantage for a  users of moving  some functionality in a 
> separate module ? I fail to see any...

Expanded database-centric functionality, especially free from the 
constraints of unrelated AVP constructs, such as the need to define an 
avp_table as a modparam even if one is not going to use it.

-- Alex

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775