This application is not intended as full IP PBX application, its only purpose is to show how some pbx features can be achieved with use of Mobicents platform. However it features that are included in this app have been scooped from actuall pbx systems (fully grown bussines products) like:

Tribox
other open source products

Start

Before writing this page I took some time to get myself acquainted with few pbx applications (two of them are listed above). At some point I have relized that Im using pbx term to some group of products while having vague idea to what exactly pbx refers. Quick peek at google results gave me answer:
The Internet Protocol Private Branch eXchange (IP PBX) is telephone switching equipment that resides in a private business instead of the telephone company. An IP PBX delivers employees dial-tone, the ability to conference, transfer, and dial other employees by extension number as well as many other features. Voice transmissions are sent via data packets over a data network instead of the traditional phone network.

Application Requierements
Enviroment requirements
Realization
Iterations
- Phase_1
- Phase_2
- Phase_3
- Phase_4
Roadmap

Application Requierements

Having slight idea what pbx we can craete list of features we would like to cover:

third party call controll - our app should be able to create call between two entities
user administration
- passwords
- forward addresses
- blocked addreses
- voicemail
- settings and triggering conditions
user list along with their status - connected,unavailable, calling, on conference call, ...
ongoing call list
create conferences - ( part of 3pcc ?)
record ongoing call ( so we can record call between even two different users )
voice mail - status, download recorded mails, trigger sending vmails to mailbox as attachemnts?

Enviroment requirements

What will we need from our enviroment/applciation:

persistent storage - to store user data,profiles,vmails
common register that holds all current data about call and user status, this register should be updated on each change (why this will be exaplained later)
entities to test application on
it goes without saying btu we do need implementation and front end.

Realization

Involved technologies:

SLEE - Mobicents as logic enviroment - here will reside
peristent storage technology has not beed decided yet.
GWT application as GUI.

Mobicents platform will be responsible for all logic - proxying,registering users, updating register data (one that holds common data - for isntance call status and all data from persistent storage), it will also epose means to access that register data.

GWT application will be "simple" front end. It will allow to list all users, chceck their status (availability, busy status- on call or on conference), list all ongoing calls and conferences, modify all user data. By user data I understand:

conditions under which certain services (call block, forward, vmail, hold) will be triggered.
user data
vmail settings

I have mentioned that common register - some kind of service that exposes and allows modification of persistent data, and current status of users/calls has to be updated cosntantly by SLEE service. This has to be done like that ( or does not? if there is any suggestion please let me know) because of GWT constraints. While playing with that technology I have looked for means of having uptodate representation of data/state inside SLEE or any other server side data.

Fetching data from server side requires programmer to create a kind of servlet which will respond to RPC calls. All calls made from GWT are async and require use of AsyncCallback method. To keep GUI uptodate we would have to make rpc calls to retrieve state from server atleast on a second bassis. This causes a lot of unneeded network trafic and consumes cpu time - this can be thin bottle neck if we have incresing load (ofourse we can send only differences between last and current rpc call, but still its quite an overhead just to keep GUI uptodate).
However we can block servlet thread (server side) so that it doesnt respond until change is made - this saves a lot of network bandiwth and servers cpu as we can specify moment at which udpate operation will be performed. However this causes (propably) deadlock if more than one rpc call is blocked on server side, atleast this happens in examples that are basis for GUI design.
So it seems that most logical choice is to have register udpate( on client side) in one place, from which all GWT panels can fetch data in non-rpc manner. Ofcourse servlet thread would be blocked in order to save resources.

Here is basic diagram for this application:

Definitions

Packages

JPAEntityManager - util class which will embed most of JPA querries. Its role is to hide as much as possible persistence logic, however it will allow access to JPA-HIberante Entity Manager and EMFactory in case there is a need for it. Example of exposed operations : user activations/deactivation, add/remove blocked user, add/remove specific vmail setting, start call, end call ( when call is somehow created we have to store data regarding it) etc.
GWT RPC Servlets - group of GWT servlets which allow GUI to retrieve informations or issue commands to SLEE
SLEE Connection factory - used to issue commands to SLEE components
Services - various services - "native" like sip proxy/registar/"location"/vmail and created for pbx application - watching over Registry data integrity ( for instance something that watches for calls that werent created by pbx - we have to list them too, and udates registry data )
User register - keeps track of all ogoing calls, their participants, updates persistent data regarding calls - start,end, participants

Iterfaces

Storage proxy and its interface provide:
- methods to create stats regarding usages ( only write opearation that storage proxy is allowed)
- read methods for configuration options - regarding blocked users, vmail settings and forwards - mainly addresses - no write operations should be allowed ( since )
Register interface defines
- read methods for all non persistent data like - ongoing calls, registered users
- for internal use - within SLEE this interface defines methods which are used by other services to update registers information about current state
Command interface - combination of synchronous and async means fo issuing commands to SLEE components in order to:
- create call - conference is call with more than 2 entities
- terminating call

Iterations

This app is quite "big" in comparison with resources we have at the moment. So we decided to split realization into smaller phases/interations. Each iteration will add something to existing code. See roadmap below.