[Asterisk-Dev] Re: Creating An Asterisk Data Model

[Peter Nixon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 29 May 2004 01:04, Steven Sokol wrote:
> Sorry for the long message - brain dump time:
>
> I've spent the past few days working on a comprehensive data model for a
> client.  The client is a carrier and wants to be able to provide both
> retail and wholesale service using a cluster of Asterisk systems.  To
> further complicate the configuration, they want to provide both basic
> services (dial tone + voicemail + Class5 features) and Virutal PBX/IP
> Centrex services.
>
> While this is somewhat complex, it's nothing new.  Many providers have
> similar offerings.  The clustering is a challenge but not a show stopper.
> For what it's worth, I currently have about 15 tables defined.  I figure I
> am 1/4 to 1/5 of the way done.
>
> The reason I bring all of this up is that it might be cool to work together
> to come up with an advanced, flexible data model that can become a starting
> point if not a standard for Asterisk implementations.
>
> The model should support the most common types of implementations:
>
> - Asterisk as SOHO PBX
> - Asterisk as Enterprise PBX
> - Asterisk as ACD (Call Center)
> - Asterisk as IVR Server
> - Asterisk as Voicemail Server
> - Asterisk as Hosted IP Centrex Platform
> - Asterisk as PSTN Media Gateway (service provider)
> - Asterisk as VoIP Gateway (enterprise)
> - Others that I missed here... (Suggestions?)
>
> This seems to be a good place to start working towards a number of topics
> that have been discussed on IRC and this list:
>
> - A single point of authentication
> - Common VoIP configuration (single account works for IAX, SIP, MGCP, H323)
> - A user-centric dial plan or at least an expansion of the concept of users
> - A central registry that allows for easy, scalable clustering
> - Enhanced billing, routing, and rating features
>
> All of these things are good steps forward.  All of these will help make
> Asterisk a "safe" solution (thus easier to sell to management).
>
> I realize that this may be heresy/flame-bait, but with ast_data moving
> closer to implementation, now is a good time to work out a common model for
> providing these services.

I also have been working on a similar setup, with a combination of 
sip/iax-friends, AGI, app_prepaid etc.

I have only just started playing with ast_data but it appears to only go part 
of the way towards any of these goals currently.
My plan at the moment is to base everything around Postgresql stored 
procedures and views (this obviously leaves out MySQL users as it doesn't 
have either of these features) and basically merge the ast_data functionality 
with app_prepaid. This will provide the features that I need, namely:
* Multiprotocol VoIP softswitch
* Centralised user management including voicemailboxes.
* Prepaid calling cards with pin/password
* Virtual calling cards with pin/password AND CID authentication.
* IVR
* User configurable call forwarding hunt list.

Basing this around Postgres is the cleanest way to impliment it as we can do 
all the data integrity checks inside the stored procedures. (Asterisk should 
never be allowed to touch a "raw" table with the exception of the CDR table)
This solution could easily be ported to Oracle and (less easily) to MSSQL but 
MySQL would be out in the cold until they get around to making a real RDBMS. 
(Several versions away by the look of their roadmap)

I know that until now, for whatever reason, most of the DB development has 
been done based around MySQL, but unfortunately this basically only gives us 
a more flexible flatfile. If we start to use the power of real RDBMS systems 
it will alow us much more flexibility without having to code huge amounts of 
logic into Asterisk. It also easily allows web services to manage the whole 
system simply by triggering stored procedures.

I know this is going to be a controversial suggestion, and will bring cries 
from all the TheirSQL zealots, but I beg those people to think about the huge 
advantages of using the very powerfull (and opensource) systems we already 
have at our disposal rather than trying to reimplement the wheel inside of 
asterisk.

In anycase, and am implimenting this system for my own systems, and people who 
wish to are welcome to join in. I just thought I would "pipe up" and discuss 
it here so other people people can join in with constructive comment..

Note: Prepaid app CVS can be found at 
http://sourceforge.net/projects/asteriskbilling/ Other code will follow soon 
in the same CVS tree.

Cheers

- -- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAwaX4AcdsUt9pJjwRAkEfAKDpJd84mEaWBJmooeu2tJU6nvjOlwCeI4sK
Lc29h4EePEvALWI8tD7r28I=
=0o8b
-----END PGP SIGNATURE-----