|
|
The following sections describe the environment for developing applications with WebLogic SIP Server:
JSR 116: SIP Servlet API extends the basic concept of the Servlet, originally introduced as a programming model for implementation of applications which handle HTTP and the programmatic generation of HTML. The Servlet model is one of the most widely-known and used programming models in the Java community.
The SIP Servlet API specification describes not only the programming API but also the Servlet container function. The container is the Server (software) that hosts or “contains” applications written using the API. The SIP Servlet container hosts SIP applications. The container performs a number of SIP functions as specified by various RFCs, thus taking the burden off of the applications themselves. At the same time, the container exposes the application to SIP protocol messages through the SIP Servlet API. In this way, the application can perform various actions based on the SIP messages it receives from the container. Different applications can be coded and deployed to the container in order to provide various telecommunication or multimedia services.
The sections that follow describe the primary goals of the SIP Servlet API specification.
The SIP Servlet API enables applications to perform a complete set of SIP Signaling functions. The SIP Protocol specification defines different types of high level SIP roles, namely User Agents (UAs) which include UA Clients, UA Servers, and Back to back user agents (B2BUAs). The SIP protocol also defines the roles of Proxies, Registrars, and Redirect Servers. The SIP Servlet API is a allows any of these roles to be coded as SIP Servlet application.
SIP is an extensible protocol, which is one of its strengths. Applications can extend the base protocol to add new features as necessary. In fact, there are a number of RFCs that define extensions to the base IETF RFC 326 SIP: Session Initiation Protocol. The SIP Servlet API is also designed to allow developers to easily extend functionality. This is accomplished by dividing up the SIP processing between the container functions the applications. Most of the base protocol processing is performed by the container, leaving some of the higher level tasks for the applications to perform. This clever division is what lends a great deal of power and flexibility to the SIP Servlet API.
The SIP Servlet container handles “non-application-specific” complexity outside of the application code itself. Concerns like network connectivity, protocol transactions, dialog management and route processing are required by virtually all applications, and it would be enormously wasteful and error-prone to require each application to implement this support. With the SIP Servlet API, all of these tasks are managed by the container, leaving applications to provide higher level functions.
As an example, consider a SIP Proxy component:
Because the maintenance of transactions and their associated state machine is maintained by the containers, it is the container that actually inserts the via headers to the Request.
via header it inserted in the original request and then processes the response. The application code does not need to manage the Via header at all, which makes the life of application developer much easier. There are many cases in which the SIP Servlet container handles this sort of mundane, but essential, protocol detail.
The SIP Servlet API specification is closely aligned with the Java EE specifications, and it is expected that containers that host SIP Servlet applications also make Java EE features available to developers. The most notable of these features is the HTTP Servlet container. There are a many use cases in which a converged application, using both SIP and HTTP functions, is required, from conferencing and click-to-call applications to Presence and User Agent Configuration Management applications. Converged applications can also combine other protocols such as Diameter to perform advanced functions such as modifying subscriber profile data.
The SIP Servlet API enables multiple applications to execute on the same request or response, independently of one another. This is another very powerful feature of the SIP Servlet API. The promise is that application developers are able to write applications providing features that are independent of each other, but can be deployed to the same host SIP Servlet container. The applications can be “composed” (or sequenced) to provide a service on a call. This composition is facilitated by the container, and is described in more detail in “SIP Servlet API Service Invocation” on page A-1.
Application data stored in container-managed session objects can benefit from replication and failover. Almost all applications that perform some useful functions require some state between different Requests and Responses. Some state information is mandated by the SIP protocol itself, such as the transaction state machine with its Server and Client Transactions, and the Dialog state machine.
The container also has a notion of message context which encapsulates the SIP level state, and the concept of Sessions, which are the SIP Servlet API constructs. Applications can save their own state in the Session objects maintained by the container. A carrier-grade container will replicate this state such that the call becomes fault tolerant of a container instance, as is done in WebLogic SIP Server.
Figure 2-2 shows the logical layers of a WebLogic SIP Server SIP Servlet Container. The five layers shown from the bottom are what are known as the SIP stack, the functionality of which is defined in RFC 3261 and the associated RFCs that extend the base protocol.
SIP, being a transaction-based protocol, has a well-defined transaction layer. SIP requests are always followed by one or more provisional Responses and one final response, with the exception of the ACK which has no response. The transaction machinery is designed to keep track of the provisional and final responses.
A dialog is a point-to-point session between two SIP endpoints that is uniquely identified by a dialog identifier. Not all SIP requests create dialogs. However, the ones that do create dialogs have a well-defined mechanism of establishing and tearing down the dialog (INVITE, SUBSCRIBE/NOTIFY, REFER).
The SIP stack shown in this diagram is not strictly in accordance with RFC 3261. It differs from the specification in that there is a layer called Transaction User (TU) above the Transaction layer, and the dialog management layer is not explicitly a layer in 3261. The “Dialog layer” is a very visible constituent of a SIP Servlet container because the dialogs correspond roughly to the SipSession objects. In Figure 2-2 the TU layer is actually split between the Dialog management layer and the big Container block.
The primary purpose of the Container is to host SIP Servlet applications that are written to the container’s SIP Servlet API implementation. It exposes objects like SipServletRequest, SipServletResponse, different types of Sessions, facilities like Timer, Logging, and so forth.
Although SIP is a human-readable, text-based protocol, and is well-defined in RFC 3261, writing SIP applications can be a challenging task. The SIP Servlet API is designed to make it very easy for application developers to build SIP applications. While the SIP Servlet API allows access to all the headers present in a SIP Request, it does not require applications to understand or modify all of them for correct protocol behavior. Also, there are some headers that are strictly off limits for applications. The SIP Servlet API defines the so-called “system headers” which are to be managed only by the container. These headers include From, To, Call-ID, CSeq, Via, Route (except through pushRoute), Record-Route, and Contact. Applications can add attributes to the Record-Route header and Contact header fields in all request messages, as well as 3xx and 485 responses. Additionally, for containers such as WebLogic SIP Server that implement the reliable provisional responses extension, RAck and RSeq are also considered to be system headers. The system header management performed by the container offloads a tremendous amount of complexity from applications.
The From, To, Call-ID, and CSeq message headers collectively identify a given SIP dialog. The SIP Servlet container keeps track of the dialog state and dialog-related data for the hosted applications. The SIP Servlet API container is responsible for managing Record-Route, Contact, and Via headers because the network listen points, failure management, multi-homing, transport switching, and so forth are also handled by the container. Applications can participate in the routing decisions of a Request emanating from the container by explicitly modifying Request-URI or adding Route headers with pushRoute. As a result, applications have no responsibility for resource management. The SIP Servlet API draws heavily from Java EE standardization and common practices, such as the declarative usage of container features like security, mapping, environment resources, and so forth.
Perhaps the greatest advantage of the SIP Servlet API is the API itself. The SIP Servlet API abstracts a large number of complex SIP tasks behind intuitive constructs. The Proxy interface, representing the proxy functionality in SIP, is an excellent example. A proxy can:
With the SIP Servlet API, all of these options are simple attributes of the Proxy object. The container-managed Proxy deals with all low level details like finding a target set (based on Request-URI or Route headers), applying RFC rules if a strict router is upstream or downstream, creating multiple client transactions, correlating responses, choosing the best response, and so forth.
This section describes additional important interfaces and constructs of the SIP Servlet API, and includes examples.
The SipServlet class extends the GenericServlet class in the servlet base package. The service method dispatches the SIP message to either doRequest() or doResponse(), and in turn the requests are directed to the doXXX methods for Requests such as doInvite, doSubscribe, and so forth, or to doXXX methods for Responses such as doSuccessResponse and doErrorResponse.
The servlet-mapping element defined in the deployment descriptor can define the rule that MUST be satisfied before invoking a particular Servlet. The mapping rules have a well-defined grammar in JSR 116. As an example,
Listing 2-1 shows a mapping that invokes a Servlet only if the Request is an INVITE and the host part of the Request-URI contains the string “bea.com”. Servlet mapping rules are described in more detail in
“SIP Servlet API Service Invocation” on page A-1.
<pattern>
<and>
<equal>
<var>request.method</var>
<value>INVITE</value>
</equal>
<contains ignore-case="true">
<var>request.from.uri.host</var>
<value>bea.com</value>
</contains>
</and>
</pattern>
There is normally only one SipServlet object accessed by concurrent Requests, so it is not a place to define any call- or session- specific data structure. doXXX methods in the application generally implement the business logic for a given request. Consider Listing 2-2.
1: package test;
2: import javax.servlet.sip.SipServlet;
3: import javax.servlet.sip.SipServletRequest;
4: import java.io.IOException;
5: public class SimpleUasServlet extends SipServlet {6: protected void doInvite(SipServletRequest req)
7: throws IOException {8: req.createResponse(180).send();
9: req.createResponse(200).send();
10: }
11: protected void doBye(SipServletRequest req) throws IOException {12: req.createResponse(200).send();
13: req.getApplicationSession().invalidate();
14: }
15: }
Listing 2-2 shows a simple UAS Servlet that is invoked on an incoming INVITE Request (triggered by a rule similar to the one defined in Listing 2-1). The container invokes the application by invoking the doInvite method. The application chooses to send a 180 Response (line 8) followed by a 200 Response (line 9). The application does nothing with the ACK, which would be sent by the UAC. In this case the container receives the ACK and silently ignores it. If it were a stateful proxy it would have proxied it. Applications only do what they need to do and nothing more.
As its name suggests, this class is used to create various SIP Servlet API objects like Request, SipApplicationSession, Addresses, and so forth. An application acting as a UA can use it to create a new Request. Requests created through the factory have a new Call-ID (with the exception of a particular method for B2BUAs in which the application can chose to re-use the existing Call-ID on the upstream leg) and do not have a tag in the To header. The Factory object can be retrieved using the javax.servlet.sip.SipFactory attribute on the ServletContext.
See the findme example installed with WebLogic SIP Server for an example of obtaining a factory object using SipFactory.
There are two classes of SIP messages: SipServletRequest and SipServletResponse. These classes respectively represent SIP Requests (INVITE, ACK, INFO, and so forth) and Responses (1xx, 2xx, and so forth). Messages are delivered to the application through various doXXX methods defined in the SipServlet class.
SIP is an asynchronous protocol and therefore it is not obligatory for an application to respond to a Request when the doRequest(doXXX) method is invoked. The application may respond to the Request at a later stage, because they have access to the original Request object.
Both the SipServletRequest and SipServletResponse objects are derived from the base SipServletMessage object, which provides some common accessor/mutator methods like getHeader(), getContent(), and setContent(). The SipServletRequest defines many useful methods for Request processing:
| Note: | The CANCEL is sent if the UAC decides to not proceed with the call if it has not received a response to the original request. Sending a CANCEL if you have received a 200 response or not received a 100 response would be wrong protocol behavior, luckily the SIP Servlet API steps up to rescue here too. The UAC application can create and send a CANCEL oblivious to these details. The container makes sure that the CANCEL is sent out only if a 1xx class response is received and any response >200 is not received. |
Another method of interest is SipServletRequest.isInitial(). It is important to understand the concept of initial and subsequent requests, because an application may treat each one differently. For example, if an application receives a Re-INVITE request, it is delivered to the Servlet’s doInvite() method, but the isInitial() method returns “false”.
Initial requests are usually requests outside of an established dialog, of which the container has no information. Upon receiving an initial Request, the container determines which application should be invoked; this may involve looking up the Servlet-mapping rules. Some Requests create dialogs, so any Request received after a dialog is established falls into the category of a “subsequent” Request. Closely-linked with the dialog construct in SIP is the SipSession object, described in “SipSession” on page 2-10.
In the SipServletResponse object, one particular method of interest is createAck(). createAck() creates an ACK Request on a 2xx Response received for the INVITE transaction. ACKs for non-2xx responses of the INVITE transaction are created by the container itself.
The SipSession roughly corresponds to a SIP dialog. For UAs the session maintains the dialog state as specified by the RFC, in order to correctly create a subsequent request in a dialog. If an application is acting as a UA (a UAC or a B2BUA), and after having processed an initial request wants to send out a subsequent request in a dialog (such as a Re-INVITE or BYE), it must use SipSession.createRequest() rather than one of SipFactory methods. Using a factory method would result in requests being created “out of dialog”.
The SipSession is also a place for an application to store any session-specific state that it requires. An application can set or unset attributes on the SipSession object, and these attributes are made available to the application over multiple invocations.
SipSession also provides the SipSession.setHandler(String nameOfAServlet) method, which assigns a particular Servlet in the application to receive subsequent Requests for that SipSession.
The SipApplicationSession logically represents an instance of the application itself. An application may have one or more protocol sessions associated with it, and these protocol sessions may be of type SipSession or HttpSession as of JSR 116. Applications can also store application-wide data as an attribute of the SipApplicationSession.
Any attribute set on a SipApplicationSession object or its associated SipSession is visible only to that particular application. The SIP Servlet API defines a mechanism by which more than one application can be invoked on the same call. This feature is known as application composition. SipApplicationSession provides a getSessions() method that returns the protocol sessions associated with the application session. Figure 2-3 shows the containment hierarchy of the different sessions in the SIP Servlet API.
The encodeUri(URI) method in the SipApplicationSession interface is of particular interest. This method encodes the SipApplication identifier with the URI specified in the argument. If the container sees a new request with this encoded URI, even if on a different call, it associates the encoded SipApplicationSession with this Request. This innocuous-looking method has the power to link two disparate calls, and it can be used in variety of other ways. SipApplicationSession is also associated with application session timers, as described in “Application Timers” on page 2-12.
The SIP Servlet API provides a timer service that applications can use. The TimerService interface can be retrieved using a ServletContext attribute, and it defines a createTimer(SipApplicationSession appSession, long delay, boolean isPersistent, java.io.Serializable info) method to start an application-level timer.
The SipApplicationSession is implicitly associated with application-level timers. When a timer fires, the container invokes an application-defined TimerListener and passes it the ServletTimer object. The listener can use the ServletTimer object to retrieve the SipApplicationSession, which provides the correct context for the timer’s expiry.
In terms of the SIP Servlet API, a converged application is one that involves more than one protocol, in this case SIP and HTTP. Listing 2-3 presents an example of a simple JSP page which can be accessed through an HTTP URL.
1: <html>
2: <body>
3: <%
4: if (request.getMethod().equals("POST")) {5: javax.servlet.sip.SipFactory factory =
6: (javax.servlet.sip.SipFactory) application.getAttribute(javax.servlet.sip.SipServlet.SIP_FACTORY);
7: javax.servlet.sip.SipApplicationSession appSession =
8: factory.createApplicationSession();
9: javax.servlet.sip.Address to =
10: factory.createAddress("sip:localhost:5080");11: javax.servlet.sip.Address from =
12: factory.createAddress("sip:localhost:5060");13: javax.servlet.sip.SipServletRequest invite =
14: factory.createRequest(appSession, "INVITE", from, to);
15: javax.servlet.sip.SipSession sess = invite.getSession(true);
16: sess.setHandler(“sipClickToDial");
17: //invite.setContent(content, contentType);
18: invite.send();
19: }
20: %>
21: <p>
22: Message sent ...
23: </body>
24: </html>
The JSP shown in Listing 2-3 would need to be packaged in the same application as a SIP Servlet. The entire application is a skeleton of a click-to-dial application (called “sipClickToDial”), where by clicking on a Web page you initiate a SIP call.
The HTTP Servlet creates a SIP Request from a factory and sends it to a SIP URI. When an HTTP POST Request is sent to the HTTP Servlet it obtains the SipFactory on line 5-6. Next, it creates an application session (line 7-8). The application session is the center piece for all of the application’s SIP and HTTP interactions. The overall purpose is to send out a SIP Request, which is done in lines 13-14, but first the application creates the From and To headers to be used when forming the INVITE request.
On line 16 the application assigns a handler to the SipSession that is associated with the INVITE Request that was created, and this ensures that the Response sent by a UAS that receives the request is dispatched to a SIP Servlet for processing.
WebLogic SIP Server also introduces an extension to the SIP Servlet API specification called the Session API. See “WebLogic SIP Server Session API” on page 2-16, for more detail.
In the example shown in Listing 2-4 below, the application receives a SUBSCRIBE Request and sends out a NOTIFY Request. The application then waits for the notification recipient for three seconds, and if does not receive a success response (a 2xx class response), then it may take some other action (for example, log a message).
1: public class Sample_TimerServlet extends SipServlet
2: implements TimerListener {3: private TimerService timerService;
4: private static String TIMER_ID = "NOTIFY_TIMEOUT_TIMER";
5: public void init() throws ServletException {6: try {7: timerService =
8: (TimerService)getServletContext().getAttribute
9: ("javax.servlet.sip.TimerService");10: }
11: catch(Exception e) {12: log ("Exception initializing the servlet "+ e);13: }
14: }
15: protected void doSubscribe(SipServletRequest req)
16: throws ServletException, IOException {17: req.createResponse(200).send();
18: req.getSession().createRequest("NOTIFY").send();19: ServletTimer notifyTimeoutTimer =
20: timerService.createTimer(req.getApplicationSession(), 3000,
21: false, null);
22: req.getApplicationSession().setAttribute(TIMER_ID,
23: notifyTimeoutTimer);
24: }
25: protected void doSuccessResponse(SipServletResponse res)
26: throws javax.servlet.ServletException, java.io.IOException {27: if (res.getMethod().equals("NOTIFY")) {28: ServletTimer notifyTimeoutTimer =
29: (ServletTimer)(res.getApplicationSession().getAttribute(TIMER_ID));
30: if (notifyTimeoutTimer != null) {31: notifyTimeoutTimer.cancel();
32: res.getApplicationSession().removeAttribute(TIMER_ID);
33: }
34: }
35: }
36: public void timeout(ServletTimer timer) {37: // This indicates that the timer has fired because a 200 to
38: // NOTIFY was not received. Here you can take any timeout
39: // action.
40: // .........
41: timer.getApplicationSession().removeAttribute
("NOTIFY_TIMEOUT_TIMER");42: }
43: }
In Listing 2-4, the Servlet itself implements TimerListener so that it will be notified of the timeout. The example starts by obtaining the TimerService from the ServletContext in lines 7-9. The timer is then set for 3000 ms (3 seconds) upon receiving the SUBSCRIBE request on line 20. Note that the timer could be set at any stage. There is also an option to attach an object to the timer. The object could be used as an identifier or an invokable message at a later stage. This sample simply associates the timer with a literal.
After sending the NOTIFY the application creates the timer and saves its reference in the SipApplicationSession for later use on line 22.
If the application receives a 200 response to the NOTIFY, it can then extract the timer reference and cancel the timer (line 25). However, if no response is received in 3 seconds, then the timer fires and the container calls the timeout() callback method (line 36).
In a converged application, SIP protocol functionality is combined with other protocols (generally HTTP or Diameter) to provide a unified communication service. For example, an online push-to-talk application might enable a customer to initiate a voice call to ask questions about products in their shopping cart. The SIP session initiated for the call is associated with the customer's HTTP session, which enables the employee answering the call to view customer's shopping cart contents or purchasing history.
You assemble converged applications using the basic SIP Servlet directory structure outlined in JSR 116. Converged applications require both a sip.xml and a web.xml deployment descriptor files.
The HTTP and SIP sessions used in a converged application can be accessed programmatically via a common application session object. WebLogic SIP Server provides an extended API to help you associate HTTP sessions with an application session.
JSR 116 fully describes the requirements and restrictions for assembling converged applications. The following statements summarize the information in the SIP Servlet specification:
Use the standard SIP Servlet directory structure for converged applications.
Store all SIP Servlet files under the WEB-INF subdirectory; this ensures that the files are not served up as static files by an HTTP Servlet.
Include deployment descriptors for both the HTPP and SIP components of your application. This means that both sip.xml and web.xml descriptors are required. A weblogic.xml deployment descriptor may also be included to configure Servlet functionality in the WebLogic SIP Server container.
Observe the following restrictions on deployment descriptor elements:
The distributable tag must be present in both sip.xml and web.xml, or it must be omitted entirely.
context-param elements are shared for a given converged application. If you define the same context-param element in sip.xml and in web.xml, the parameter must have the same value in each definition.
If either the display-name or icons element is required, the element must be defined in both sip.xml and web.xml, and it must be configured with the same value in each location.
Each application deployed to the WebLogic SIP Server container has a single SipApplicationSession, which can contain one or more SipSession and HttpSession objects. The basic API provided by javax.servlet.SipApplicationSession enables you to iterate through all available sessions available in a given SipApplicationSession. However, the basic API specified by JSR 116 does not define methods to obtain a given SipApplicationSession or to create or associate HTTP sessions with a SipApplicationSession.
WebLogic SIP Server extends the basic API to provide methods for:
These extended API methods are available in the utility class com.bea.wcp.util.Sessions.
When using a replicated domain, WebLogic SIP Server automatically provides concurrency control when a SIP Servlet modifies a SipApplicationSession object. In other words, when a SIP Servlet modifies the SipApplicationSession object, the SIP container automatically locks other applications from modifying the object at the same time.
Non-SIP applications, such as HTTP Servlets, must themselves ensure that the application call state is locked before modifying it in a replicated environment. To help application developers manage concurrent access to the application session object, WebLogic SIP Server extends the standard SipApplicationSession object with com.bea.wcp.sip.WlssSipApplicationSession, and adds a new interface, com.bea.wcp.sip.WlssAction to encapsulate changes to the session. When these APIs are used, the SIP container ensures that all business logic contained within the WlssAction object is executed on a locked copy of the associated SipApplicationSession instance.
The IMS specification defines the Sh interface as the method of communication between the Application Server (AS) function and the Home Subscriber Server (HSS), or between multiple IMS Application Servers. The AS uses the Sh interface in two basic ways:
The user data available to an AS may be defined by a service running on the AS (repository data), or it may be a subset of the user’s IMS profile data hosted on the HSS. The Sh interface specification, 3GPP TS 29.328 V5.11.0, defines the IMS profile data that can be queried and updated via Sh. All user data accessible via the Sh interface is presented as an XML document with the schema defined in 3GPP TS 29.328.
The IMS Sh interface is implemented as a provider to the base Diameter protocol support in WebLogic SIP Server. The provider transparently generates and responds to the Diameter command codes defined in the Sh application specification. A higher-level Profile Service API enables SIP Servlets to manage user profile data as an XML document using XML Document Object Model (DOM). Subscriptions and notifications for changed profile data are managed by implementing a profile listener interface in a SIP Servlet.
WebLogic SIP Server includes only a single provider for the Sh interface. Future versions of WebLogic SIP Server may include new providers to support additional interfaces defined in the IMS specification. Applications using the profile service API will be able to use additional providers as they are made available.
Servlets that manage profile data can explicitly obtain an Sh XML document from a factory using a key, and then work with the document using DOM.
The document selector key identifies the XML document to be retrieved by a Diameter interface, and uses the format protocol://uri/reference_type[/access_key].
Table 2-2 summarizes the required document selector elements for each type of Sh data reference request.
WebLogic SIP Server provides a helper class, com.bea.wcp.profile.ProfileService, to help you easily retrieve a profile data document. The getDocument() method takes a constructed document key, and returns a read-only org.w3c.dom.Document object. To modify the document, you make and edit a copy, then send the modified document and key as arguments to the putDocument() method.
See Using the Profile Service API (Diameter Sh Interface) in Developing Applications with WebLogic SIP Server for more information.
The IMS Sh interface enables applications to receive automatic notifications when a subscriber’s profile data changes. WebLogic SIP Server provides an easy-to-use API for managing profile data subscriptions. A SIP Servlet registers to receive notifications by implementing the com.bea.wcp.profile.ProfileListener interface, which consists of a single update method that is automatically invoked when a change occurs to profile to which the Servlet is subscribed. Notifications are not sent if that same Servlet modifies the profile information (for example, if a user modifies their own profile data).
| Note: | In a replicated environment, Diameter relay nodes always attempt to push notifications directly to the engine tier server that subscribed for profile updates. If that engine tier server is unavailable, another server in the engine tier cluster is chosen to receive the notification. This model succeeds because session information is stored in the data tier, rather than the engine tier. |
Actual subscriptions are managed using the subscribe method of the com.bea.wcp.profile.ProfileService helper class. The subscribe method requires that you supply the current SipApplicationSession and the key for the profile data document you want to monitor. See
“Using Document Keys for Application-Managed Profile Data” on page 2-20.
Applications can cancel subscriptions by calling ProfileSubscription.cancel(). Also, pending subscriptions for an application are automatically cancelled if the application session is terminated.
Listing 2-5 shows sample code for a Servlet that implements the ProfileListener interface.
package demo;
import com.bea.wcp.profile.*;
import javax.servlet.sip.SipServletRequest;
import javax.servlet.sip.SipServlet;
import org.w3c.dom.Document;
import java.io.IOException;
public class MyServlet extends SipServlet implements ProfileListener {private ProfileService psvc;
public void init() {psvc = (ProfileService) getServletContext().getAttribute(ProfileService.PROFILE_SERVICE);
}
protected void doInvite(SipServletRequest req) throws IOException {String docSel = "sh://" + req.getTo() + "/IMSUserState/";
// Subscribe to profile data.
psvc.subscribe(req.getApplicationSession(), docSel, null);
}
public void update(ProfileSubscription ps, Document document) { System.out.println("IMSUserState updated: " + ps.getDocumentSelector());}
}
The ProfileListener interface is handled similar to the TimerService provided by JSR 116 for application timers. Multiple Servlets in an application may implement the ProfileListener interface, but only one Servlet may act as a listener. The SIP deployment descriptor for the application must designate the profile listener class in the set of listeners as shown in
Listing 2-6.
<listener>
<listener-class>com.foo.MyProfileListener</listener-class>
</listener>
The WebLogic SIP Server SDK consists of the WebLogic SIP Server executable and a selection of example applications available as source code and deployable binaries. The WebLogic SIP Server SDK may be executed on any standard Windows or Linux workstation. When used in conjunction with an IDE, common tasks such as the writing and modification of Java code, setting of break-points, tracing and profiling are easily performed.
It is possible to use WebLogic SIP Server in conjunction with virtually any of the popular development tools commonly used to develop Java and Java EE applications.
|