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

[Miroslav Nachev]

   Hi,

   What do you think about some management & configuration program
using Java. I mean that we can do the data model using Hibernate which
data model use XML as description and Hibernate supports more than 15
popular databases like MySQL, MS SQL Server, Oracle, Informix, DB2,
PostgreSQL, HSQL and etc. The creation of database, tables, primary
keys, foreign keys, indexes, and population is automaticaly from
Hibernate. If some changes are made in XML description file Hibernate
automaticaly correct the database model.
   If we do in details the user/technical requirements I can start
working for this and other concerning management and configuration.


   Best Regards,
   Miroslav Nachev
   
I'm working on a data model, too. Steve has shared his model with me. I am
doing The ER model right now. 


Paul Mahler 
pmahler at signate.com 	
Signate, LLC
665 Third Street
Suite 100
San Francisco, CA
 94107-1901

 Asterisk Services and Training

 

 

 

 

> -----Original Message-----
> From: asterisk-dev-admin at lists.digium.com 
> [mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of Peter Nixon
> Sent: Saturday, June 05, 2004 2:58 AM
> To: asterisk-dev at lists.digium.com
> Subject: [Asterisk-Dev] Re: Creating An Asterisk Data Model
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 29 May 2004 02:20, Ray Burkholder wrote:
> > I've been working on implementing such a project.  The 
> basics for much 
> > of this stuff is in place.
> >
> > I have the basic double entry accounting tables in place 
> for handling 
> > sales orders, invoicing, shopping cart, AR, AP, GL.
> >
> > Basic telephony tables are in place to handle atomic 
> services such as 
> > origination, termination, did numbers, corporate dial plan, per 
> > extension feature handling, voicemail, etc.  There is a 
> then a 'package'
> > table that allows a mix and match of atomic services to 
> make a service 
> > provider offering.
> >
> > A user self-provisions various services through a web based 
> interface.
> > Services are selected and placed on an order, then invoiced.  In a 
> > prepaid scenario, and deposit has to be applied before provisioning 
> > takes place.  On post paid accounts, provisioning can 
> happen right away.
> >
> > Provisioning is simply a matter of enabling the atomic services 
> > selected via the package.
> >
> > Incoming calls are directed via a double AGI step, the first 
> > identifies the inbound DID and it's generic call processing 
> script.  
> > That specific script is then started to handle the 
> specifics of that 
> > DID's 'character'.
> >
> > Termination is handled in a similar manner.  There are 
> various calling 
> > plans to which one may subscribe.  The context:script handling that 
> > terminating call authorizes the termination if the account 
> is active, 
> > otherwise not if it is suspended or some such.  Then the 
> appropriate 
> > rating table is pulled up to rate and route the call.
> >
> > At call completion, a manager interface pulls out the cdr, 
> figures out 
> > the account and service type, and throws it into a sales order.  
> > Account status is updated at this time to reflect balances 
> available 
> > for further calls and such.
> >
> > The user can review their sales orders and invoices at any time and 
> > apply payments.  On a regular basis, the system post sales 
> orders to 
> > invoices and submits email reminders for payments.
> >
> > Accounting is built in but I've been considering 
> accelerating that by 
> > connecting up with open source accounting such as Compiere.
> >
> > The solution runs on a minimum of 3+n servers.  A base system is 
> > composed of:
> >   * SQL server, currently PostgreSQL
> >   * Apache web server running a bunch of Mason/Perl scripts
> >   * Asterisk server with ip and tdm termination and more Perl call 
> > processing scripts
> >
> > All scripts and configurations are CVS'd to facilitate server 
> > rebuilding and expansion.
> 
> - --snip--
> 
> > Now the question that comes to my mind is that it would be 
> interesting 
> > to share the solution as alpha as it may be in order to accelerate 
> > development and improvement, but still be able to glean 
> some dollars 
> > off it.
> >
> > That is a hard question.
> 
> It is, but as you, Steven and myself all appear to be 
> independently working towards similar goals, it makes sense 
> to chare the code. I think you choices of both Postgres and 
> perl are good ones and Compiere is a good idea, although 
> something that I have currently left out on the grounds that 
> I don't know enough about accounting systems :-)
> 
> 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)
> 
> iD8DBQFAwadQAcdsUt9pJjwRAu0mAKCmIBEp21Cn7YM8/ahX9g6+oXDccwCg9lsE
> SLX/x7KQmWsSk5c/egiQh40=
> =KJSf
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev