Third Party Application Integration

• SipExchange Overview
• SipExchange Basics
• System Administration Howto
• External Call Control
• Feature  Development using SipExchange
• SipExchange Architecture

• Overview
• SipExchange web services
  

Overview

1. 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.
   
2. 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.
   
3. 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.
4. 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.
   
5. 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.
   

SipExchange web services

1. 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.
2. You may need to secure the web services if you are making them accessible via the Internet.
3. 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.
   

1. SubscriberService: supports remote operations on subscribers, domains and roles. This context provides three web services. Namely:
1. 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.
   
2. 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.
3. 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.
2. CdrService: supports remote operations on call detail records. This context provides one web service. Namely:
1. 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.
3. LocationService: supports remote operation on location information (registration and unregistration). his context provides one web service. Namely:
1. 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.

1. An user with the 'admin' role can access all the information.
2. 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.
3. An unauthenticated user can access only a few limited web services methods.
   

Search this website 

Send questions or comments about this web site to webmaster@cafesip.org.
Copyright © 2005, CafeSip.org.
Licensed under the CafeSip License.
The CafeSip.org projects, web site and web facilities have been sponsored by QUIK Computing