Re: [Asterisk-java-users] OT: Asterisk billing development

[Thameem A. <tha...@ya...>]

Hi Stefan,
 
 Thanks for your valuable inputs. My answers are below. 
 
 I do agree with you that I should go with specifications. To make it understandable I used the technologies built for those specifications. So, the application will not be depending on any particular container (or Tomcat alone) and any particular databases (like postgres alone). 
 
 As I mentioned in my first email here is my plan. 
 
 I would like to list the features needed for a enterprise class billing applications. Here are some which I came up with. Guys, I need your inputs on what kind of billing systems you use currently and what would you expect to be in the new one.

I am planning for two different modules. One is to take care of routing/calling card application and the other module is user provisioning/registration/etc. Here are the things I found missing from other applications. 

1. Simultaneous call handling on one account  - This feature said to be available in many billing apps but they never truely maintain this for a calling card user. So, most of calling card apps are single call on an account at a time. 

2. Caller ID authentication - the modern calling cards should do callerid authentication.. provision of more than one caller id should be provided.

3. Prepaid, postpaid billing and invoice generation for post paid - This is missing in other apps.

4. LCR, Quality and priority routing - this is available in current MORCC but other apps don't have it. 

5. Rate card import from multiple providers (trunks) - This should be automated and destinations dynamically available if certain provider provides that (will detail more during design phase).

6. callback service - most of the platforms currently provide only web click2call functionality. The one I am visioning is, if a registered customer give a missed call to a number (from anywhere in the world), the platform should check the existence of the customer, check balance, and call the customers provided number, after authentication provide him dialtone so that he can dial any destination he wants. He will be billed for both calls (like system making call + he makes a call). This is more attractive feature to implement. 

To start with, I registered this project in sourceforge today and expect to get approved in two days. Please suggest a name and your interest on this project. 

Stefan - Sorry to flood this group with my mails which is not related to your project and hence this mailing list. I will try to avoid more discussions in future. 

Thanks,
Thameem

Stefan Reuter <ste...@re...> wrote: Hi,

nice to hear about more future source projects embrassing Asterisk-Java.

> Sorry for sending mail to this list but I find that the people
> participating in this list would be appropriate to ask.

No problem at all, the list has really low traffic recently any way so
encouraging users to take part in a discussion is always a good idea.

> Here are the technologies i am planning to use... Struts 2.0.1, tomcat 5.5,
> asterisk-java, hibernate, postgres 8.x, Jreports or Jasper Reports,
> sitemesh, quartz and integration with paypal using paypal apis, etc... 

First I would like to distinguish between internal and external
dependencies with internal dependencies being the libraries you us
within you war and external dependencies being the requirements you put
on users of your product.

Internal dependencies will on affect the developers supporting you while
external dependencies are crucial to the success of your project
regarding user adoption.

As far as I can see your external dependencies are:
JDK (or JRE)
Servlet Container
Database

Depending on JDK 5 should be safe these days, especially as you are
starting a new project. Remember though that you already rule out about
90% of the users just by choosing Java though thats another topic ;)

Regarding the servlet container I would rather like to depend on a Java
Servlet specification than on a specific implementation. Depending on
Servlet API >=2.4 allows users of Tomcat 5.x, 6.x, Resin and whatever to
use your product plus it encourages you to follow the spec.

Brett already raised the database issue. Postgres is nice but it will
rule out another 80% of the 10% users willing to use Java. You already
chose Hibernate so why not designing your application to support a broad
range of databases like MySQL, Postgres, Oracle, ...? It shouldn't be
too hard to refuse to use database specific constructs that are not yet
handled by Hibernate.

Regarding your internal dependencies I think you are pretty free to use
whatever you are comfortable with. I would prefer using Spring Framework
as IoC container and Spring Webflow for the page flows but those are
really minor design decisions.

> I have a rough design and plan and need people and inputs...

Would you mind to publish it? :)

> Please let me know your thoughts...we can start this as sourceforge
> project.. Stefan - I need your thoughts on this...

Another last thought is about the license. I am a strong supporter of
the Apache License as it is broadly accepted and allows for inclusion in
commercial application which might be what you intend or not.

=Stefan

-- 
reuter network consulting
Neusser Str. 110
50760 Koeln
Germany
Telefon: +49 221 1305699-0
Telefax: +49 221 1305699-90
E-Mail:  ste...@re...
Jabber:  ste...@re...