You have chosen to sponsor your bid up to a maximum amount of .
IP telephony system with IP PBX functions
This system will be developed as a standalone, fully functional system that, later on, should be integrated through XML exchange with a Java Application Server.
So, this project comprehends two main phases. The first one is the setup and the development of the system per se, and the second one the design and development of the XML file bits which will enable this system integration with the other modules into the Application Server environment.
Core System components:
By core system components we understand the group of applications and scripts that shall make this IP Telephony system a fully functional, standalone product.
To achieve all the needs specified by our clients, including the deliver of a broad range of IP Centrex/Digital services and the need of core SIP integration with the Brazilian Telcos telephony infrastructure, this system will comprise a upper layer made by an Asterisk IP PBX and a lower, more infrastructural layer constituted by an OpenSER server.
The attached diagrams 1 and 2 explain this concept better, on a visually accessible way.
System needs and interfaces:
Those are the system application units, system interfaces and connections as needed, according the prior shown diagrams:
Core application units:
Asterisk with custom contexts (multi-tenant) will provide digital services, device registration and all other VoIP softswitch services (including NAT bypass, call conference, voicemail, IVRs, DTMF menus, call forwarding, ANI recognition, call transfer, voicemail to e-mail, system access through access number dialing, call parking, etc.). As the Asterisk will be using custom contexts, one Asterisk will be able to hold many corporations (domains), each of those with many individual users. FreePBX interface must be customizable on a per Domain basis, with the ability of each corporation admin to add their own logo, chose their own CSS theme, etc.
To do the call control, authorization and accounting (CDR collection and storage), and also the SIP call routing, the system will have an OpenSER server with freeRADIUS. This RADIUS element will have the ability to read from an external MySQL user database and to authorize services on this per user basis. For instance, if an user tries to forward a call from his IP Phone, and call forwarding is not authorized as a service in his profile on that external user database, the RADIUS will block the call forwarding.
The OpenSER will be also responsible for the LCR routing of the calls to the final termination carriers, based in a cost and quality ratio and with a web interface through where the NOC personnel can interact with the system, for example, disabling or enabling carrier's routes for termination.
Interfaces to be built and/or customized:
The mandatory interfaces to be built are:
a) RADIUS and Billing management
b) Admin user, Domain user, and regular user creation and management
c) CDR and Billing reporting
d) SIP Devices creation and management
e) SIP carrier routing, dial plans, price lists and LCR, creation and management
f) Voicemail account creation and administration
g) IVR and DTMF menu creation and administration with recorded files upload
h) Digital Services administration
i) Live Calls dashboard (similar to Flash Operator panel)
Call Center with Autodialer system:
This Call Center with Autodialer function built-in will rely on the IP Telephony system above on order to call out and to receive incoming calls.
Also, the minute and client usage billing for the calls done through the Call Center system should be controlled, billed and reported through the IP Telephony system.
This system also should have the capability of provide access to Remote agents. Remote agents will connect from their remote computers and will be able to login on the system and perform their functions as if they were at the main office site.
Another fundamental characteristic for this Call Center system is the ability of Local and Remote agents to perform on multiple campaigns. To enable it, calls that come to the answer call queue are identified by calling ANI or DID called. That way, the system will identify that specific customer and relate that customer to the specific campaign her is calling for, playing that specific campaign IVRs, etc. When that customer gets finally redirected to the first available agent, the campaign ID to which that customer belongs to, any information the system databases might already have about that customer, and also any third party screen related to that campaign (such as SABRE or a bank systems, for example), will pop up at the agent's screen.
When that agent finish to answer that customer, and becomes available to answer calls again, the agent can receive calls directed to ANY of the multiple campaigns running on the system, which will display the data by the same way explained above.
The main components of this Call Center system are:
LAMP for the agents interfaces
an active call real time monitoring interface for the administrators (similar to the Flash Operator Panel).