To understand this section fully, please make sure that you have read the following topics first:
- SipExchange Overview
- SipExchange Basics
- System Administration Howto
- External Call Control
- Feature Development using SipExchange
- SipExchange Architecture
Table of Content
SipExchange is a soft-switch who primary function is to provide VoIP call services using the SIP protocol. It also provides a portal using which system administrators can administer the system and subscribers to modify their profile, view call data and manage the features they have subscribed to. So, it is a complete system which is ready to use. However, we realize that service providers may need to extend the system for the purpose of offering additional features to the end-users and to integrate SipExchange with external billing and provisioning systems. Therefore, SipExchange comes with a set of interfaces using which external systems and applications can access SipExchange services and extend the functions it provides. SipExchange provides the following interfaces:
- Using the external call control mechanism that SIP provides, service providers can create calling features that they can offer to their subscribers. An example of such feature is – an email is sent to the subscriber when a call from a certain user is received and the subscriber was not available. Read the section on External Call Control for more details on how to develop and deploy such features.
- The SipExchange Portal provides the user interface for administering SipExchange as well as for the end-users. It is built at the top of the Jboss Portal technology. Service providers can easily add additional applications to the portal by adding simply portlets. Such portlets will appear on the portal and service providers have complete control on their appearance, who can access them, etc. The Jboss Portal comes with a set of ready-made portlets for accessing news feeds, weather information, etc which can be customized to the service providers need. For more details on how to add portlets and managing the Jboss Portal, click here.
- SipExchange comes with a comprehensive set of web services using which external billing and provisioning systems can connect to SipExchange, view system and subscriber information and can update them. For example, an external billing application can collect all the call detail records generated by SipExchange and purge old records. Similarly, an external provisioning system can add subscribers, remove subscribers or modify subscriber feature configurations. The web services are described in more details in the next section.
- The SipExchange service layer has been developed using EJB3 specifications. If you need to access these services, you can use the remote interface provided by these services. Alternatively, you can use the web services which provide virtually the same functionality.
- Since the SipExchange user is built using portlets, these portlets can be “aggregated” into an existing portal that the service provider is using for its end users. An existing service provider may already be offering all the user access to the services it provides via a portal. If the portal server is uses the Java portal technology, instead of exposing the entire SipExchange Portal to the end-user, the service provider can expose the selected SipExchange portlets through an existing portal and can also aggregate the functionality with other portlets. The Jboss Portal supports the web services remote portlets (WSRP) specifications. Using this technology, portlets installed on one portal can be consumed by another portal using web services for communications. For more details, read the WSRP Primer. We recommend that you don’t use this feature for now we have not tested this aspect yet.
Before using the web services, please make sure of the following:
- The web services are accessible from the external systems that will consume the web services. By default, the Jboss application server only makes the web services accessible from the localhost.
- You may need to secure the web services if you are making them accessible via the Internet.
- If the web services are to be be accessed from a system inside the company firewall, please make sure that the firewall blocks web services access from the Internet.
SipExchange provides the following web services contexts:
- SubscriberService: supports remote operations on subscribers, domains and roles. This context provides three web services. Namely:
- SubscriberServiceBean: provides remote methods for accessing and managing subscriber information. Check out the WSDL at – http://SERVER:8080/SubscriberService/SubscriberServiceBean?wsdl. Replace SERVER with the actual server name.
- DomainServiceBean: provides remote methods for accessing and managing domain information. Check out the WSDL at – http://SERVER:8080/SubscriberService/DomainServiceBean?wsdl. Replace SERVER with the actual server name.
- RoleServiceBean: provides remote methods for accessing and managing role information. Check out the WSDL at – http://SERVER:8080/SubscriberService/RoleServiceBean?wsdl. Replace SERVER with the actual server name.
- CdrService: supports remote operations on call detail records. This context provides one web service. Namely:
- CdrServiceBean: provides remote methods for accessing and managing call detail record information. Check out the WSDL at – http://SERVER:8080/CdrService/CdrServiceBean?wsdl. Replace SERVER with the actual server name.
- LocationService: supports remote operation on location information (registration and unregistration). his context provides one web service. Namely:
- LocationBean: provides remote methods for accessing and managing location information. Check out the WSDL at – http://SERVER:8080/LocationService/LocationServiceBean?wsdl. Replace SERVER with the actual server name.
All the web services are secure. The web services consumer application will need a SipExchange user account for accessing a majority of the services. The general security rule that the SipExchange service layer (EJBs) and web services follow are:
- An user with the ‘admin’ role can access all the information.
- An user with the role ‘subscriber’ can access only his/her own information. For example an admin user can view the information on all the subscriber users whereas a subscriber user can view his/her own information only.
- An unauthenticated user can access only a few limited web services methods.