| Oracle® Communications Converged Application Server Developer's Guide Release 5.1 Part Number E27707-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Converged Application Server Developer's Guide Release 5.1 Part Number E27707-01 |
|
|
PDF · Mobi · ePub |
Service Foundation Toolkit (SFT) is a server-side Java framework built on top of Oracle Communication Converged Application Server's SIP Servlet programming model (SIP Servlet 1.1 as defined by JSR 289). SFT allows for the rapid development of converged communication services using the Java EE programming model, and provides Java APIs that you can use to implement services such as call control, media control, and instant messaging.
This chapter provides an overview of SFT, and how to create SFT applications.
SFT was developed with the understanding that SIP and converged applications are highly asynchronous, and that an event driven programming model is the preferred application development environment. SFT also supports the Java EE component model, and the ease-of-development and ease-of-configuration features introduced by Java EE—improving developer productivity by simplifying application development. Since the Java EE programming model and development concepts are widely recognized within the enterprise application development profession, these concepts are leveraged by SFT. In addition, SFT simplifies the usage of Communication artifacts from the Java EE components.
Normally, an application developer creates a CommunicationBean containing the necessary application logic in their event handling methods. In this way they can control the state of the communication session. Using dependency injection with the CommunicationService and CommunicationSession objects, a developer creates a communication session from Java EE components, or from the CommunicationBean itself. To do this, the developer uses the search API to locate the correct Communication object and modify it as necessary using the Java EE components.
The business logic common to both Java EE components and CommunicationBeans can be coded into Agents. Agents act as bridge between Java EE and Communication.
The parent interface of all communication types within SFT is com.oracle.sft.api.Communication. There are two categories of communication:
UserActivity represent a single Participant within a communication.
Interaction represents multiple Participants within a communication.
Interaction provides the following sub-interfaces that represent different types of communications between multiple Participants.
Two-party communication involves two SIP User Agents, and is represented by the Conversation, IMConversation, and MSRPConversation interfaces.
Multi-party communication contains more than two SIP User Agents, and is represented by the Conference, IMConference, and MSRPConference interfaces.
SFT instantiates a Communication object in response to an incoming SIP message from a UA or application. If the Communication object is created as the result of a SIP message request, SFT treats it as a two-party communication. The SFT application can then use the CommunicationBean's INITIALIZATION event to convert the two-party communication into a multi-party communication.
Table 17-1 lists the sub-classes of the Communication class. Each of these interfaces determines the type of communication the Communication Bean implements. To learn more about the Communication class, its sub-classes, and their usage, refer to the Converged Application Server API Reference.
Table 17-1 Sub-Classes of the Communication Class
| Class | Description |
|---|---|
|
|
Represents a conversation between two parties. Typically this is between two UAs. It can also be between a UA and the |
|
|
Represents a communication involving multiple parties (more than two UAs). |
|
|
Instant messaging between two participants. |
|
|
Instant messaging between multiple participants. Converged Application Server brokers the communication session among the participants. |
|
|
A communication session where more than one participant interacts with another participant. |
|
|
A two-party communication session that uses the Message Session Relay Protocol (MSRP). MSRP is a protocol for transmitting a series of related instant messages in the context of a communications session. In addition to text messaging, this communication object can be used to transfer files among the participants involved in the communication |
|
|
A multi-party communication session that uses the MSRP protocol. This type of communication is brokered by the SFT's MSRP server. As with |
|
|
Queries a message exchange between two UAs via the application server (AS). This allows a client to discover information about the supported methods, content types, extensions, and codec without “calling” the other party. For example, before a client inserts a Require header field into a SIP INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. |
|
|
Encapsulates user activity. You can use this to retrieve information about a participant's activity, and either allow or reject a communication between participants to be established based on the user's activity. |
The SFT APIs use Java ease-of-development features such as Plain Old Java Objects (POJO), annotations, and dependency injection. At the core of SFT is CommunicationBean, a stateless POJO. CommunicationBean functions as an intermediary between the SIP Servlet and incoming SIP messages, simplifying the development of SIP-based applications.
Developers can create applications that contain one or more CommunicationBeans whose logic modifies the default behavior of SFT. This is done by invoking methods on the contextual objects (such as Communications and CommunicationSession) injected into the CommunicationBean rather than the SIP protocol itself. This is done by modifying the behavior of the communication session the bean is handling rather than the SIP protocol itself.
By default CommunicationBean acts as a Back-to-Back User Agent (B2BUA).When an event is generated, the related communication artifact is made available to CommunicationBean. CommunicationBean is a high level Java bean that encapsulates the logic for handling SIP-based communications. It exposes the call flow of a communication by generating events at logical stages of the communication session. CommunicationBean provides the capabilities of regular Java EE components—looking up JDBC data sources, J2EE Connector Architecture (JCA) resources, and Enterprise JavaBeans (EJBs). It also provides the ability to initiate transactions using the Java Transaction API (JTA), and propagates security related context information from SFT to the application server.
You implement CommunicationBeans using the @CommunicationBean annotation, which identifies a Java class as a CommunicationBean. CommunicationBeans act as event listeners for communication events initiated within the network. Methods in CommunicationBean—when annotated with a particular event annotation using the appropriate attributes—act as event listeners for the communication. For example, if SFT receives a SIP INVITE it results in an INITIALIZATION event within the CommunicationBean, which is handled using the method level @CommunicationEvent annotation. Once communication is established, a method annotated with the ESTABLISHED event type is triggered.
Example 17-1 illustrates the use of the INITIALIZATION and ESTABLISHED event types applied using the @CommunicationEvent annotations.
@CommunicationBean
public class MyCommunicationBean {
@Context CommunicationSession sess;
@Context CommunicationContext ctx;
@CommunicationEvent(type=CommunicationEvent.Type.INITIALIZATION)
void handleInit() {
Conversation call = (Conversation) ctx.getCommunication();
String confName = call.getCallee().getUserName();
if (confName.equalsIgnoreCase("conf1@example.com")) {
sess.createConference(confName, call);
}
@CommunicationEvent(type=CommunicationEvent.Type.ESTABLISHED)
void handleESTABLISH() {
...
SIP applications invite participants to scheduled or existing communication sessions. A participant can be a person, an automated service (such as voice mail or an announcement), or a physical device such as a mobile phone (the user equipment, or UE). A participant can also add or remove media to or from a communication. Within SFT, a participant in a communication is represented by the Participant interface. A communication session can have different types of participants.
For example, UserParticipant represents a SIP UA, and a MediaParticipant represents a party involved in media operations such as audio playback and recording. The Player and Recorder classes are sub-classes of MediaParticipant, and represent the ability to play an audio announcement or record a conversation.
Table 17-2 Sub-Classes of the Participant Class
| Class | Description |
|---|---|
|
|
Represents the activity of a |
|
|
Represents the Participant class in a Conference. Applications use the |
|
|
Represents a media participant such as the |
|
|
Represents a MediaPartner, which functions as both a Player and Recorder. The MediaPartner can also attach to a Participant in an established Conversation to play an announcement. |
|
|
Represents a participant that is used to send files (such a JPEG images or documents) from the AS to the other participants in a MSRP communication. |
|
|
A participant that is used to save files sent with MSRPPlayer and/or record the message history of a MSRP communication. |
|
|
Represents a |
|
|
Represents a |
|
|
Represents a participant—a User Agent—using the communication session. |
Participants are added to a communication session either by SFT at runtime, or by an application. For example, when a SIP INVITE for a two-party call reaches Converged Application Server, SFT instantiates a Conversation object, and adds the caller and callee as participants. In cases where an application within Converged Application Server initiates the call, the application instantiates a Conversation object, and adds participants to the object to initiate the conversation. For example, a Third Party Call Control (3PCC) application in which the operator creates a call that connects two participants. Similarly, a conferencing application adds a participant in the form of the Recorder class to the Communication object, and then records the conversation.
Example 17-2 The UserParticipant Interface Getting Caller Information
...
@Context CommunicationContext<Conversation,UserParticipant> ctx
...
Conversation call = ctx.getCommunication();
UserParticipant callee = (UserParticipant) ctx.getCallee();
UserParticipant caller = (UserParticipant) ctx.getCaller();
IdentityInformation ii = ctx.getContextElement(IdentityInformation.class);
if (isRoaming(ii)) {
caller.reject(Reason.DECLINE);
}
PhoneNumber ph = callee.getPhoneNumber();
if (isInternationalCall(ph, caller)) {
caller.reject(Reason.DECLINE);
}
...
SIP signaling—the setting up, modification, and termination of communication sessions—occurs through the exchange of SIP messages. There are two types of SIP messages: requests and responses. Requests are sent to initiate an action; responses are sent as replies to requests, acknowledging receipt of the requests and indicating their status.
Requests and responses share a common message format which consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body.
SIP messages often carry a lot of information. For example, the SIP MESSAGE body may include a text message, and the SIP INFO method communicates additional information about an active session using dual-tone multi-frequency (DTMF) signaling (DTMF). SIP Servlets read the SIP message contents, interpret them, and respond accordingly.
SFT converts SIP request and response messages into Java objects, which are defined by the Java interface Message. When an event is generated, SFT provides these Message objects to the application. Examples of Message objects include TextMessage, DtmfSignal, and MessageIndication.
Example 17-3 illustrates a CommunicationBean using the MessageIndication class within the @CommunicationEvent annotation. Depending on the type of message, applications may modify the message content. For example, an application can alter the text message sent in the SIP message body by adding a warning, or translating the content. Similarly, some messages may be consumed by the application to facilitate communication between the server and user agents. For example, a web-to-SIP phone IM session.
Example 17-3 The MessageIndication Communication Event
@CommunicationBean
public class MyCommunicationBean {
@Context CommunicationContext ctx;
@CommunicationEvent(type=CommunicationEvent.Type.MESSAGEINDICATION)
void handleMessageIndication() {
IMConversation conv = (IMConversation) ctx.getCommunication();
MessageIndication msg = (MessageIndication) ctx.getMessage();
System.out.println("Message State : " + msg.getState());
System.out.println("Next Message Type : " + msg.getNextMessageType());
}
SFT provides three objects that can be injected into the CommunicationBean and other Java application components: CommunicationSession, CommunicationContext, and CommunicationService.
You inject these objects using the @Context annotation, as shown in Example 17-4. As shown below, dependency injection allows one component to reference another by having the container “inject” the component into a method or instance variable.
@CommunicationBean
public class CallBean {
@Context CommunicationSession session;
@Context CommunicationContext<Conversation,UserParticipant,Message> ctx;
@Context CommunicationService service;
...
A communication or participant is always associated with CommunicationSession. For every event generated that pertains to a Communication or Participant object, CommunicationSession is injected into the application. This association is made at the time of creation of the object (by the application or by the SFT runtime). Multiple objects can be created using the same CommunicationSession object.
CommunicationService configures the underlying communication service. Persistent information—such as groups—are created using CommunicationService.
CommunicationContext represents the context in which the current event is generated. SFT injects CommunicationContext into the CommunicationBean for each event. Applications obtain artifacts relevant to the event such as Communication, Participant, and Message from the CommunicationContext object.
Note:
CommunicationContext is only injected into CommunicationBean, and is not into other Java EE artifacts.CommunicationContext is only injected into CommunicationBean, and is not injected into other Java EE artifacts.
To learn more about CommunicationSession, CommunicationContext, and CommunicationService and their usage, refer to the Converged Application Server API Reference.
The CommunicationSession object is injected into HTTP Servlets and the CommunicationBean. Applications can use CommunicationSession to create any kind of communication. Different entities in a communication, such as Communication or Participant objects, have different life cycles, and there may be different events associated with these entities. A converged application may need to execute logic based on such events. For example, in a conferencing application, when the host of the communication joins the conference, audio recording is automatically activated. Events such as this are invoked in the CommunicationBean.
SFT provides the ability to attach agents to different communication session artifacts. An agent is an object defined by the application that contains data and logic specific to the application. Agents can be attached to a Communication object, a Participant object, or to both the Communication and Participant objects. The application invokes the agent to perform application specific logic whenever an event occurs. Given communication session artifacts are accessible both from web applications and CommunicationBean, the agent enables you to develop converged applications in an organized manner.
SFT provides APIs to control media object composition. Media objects are composed together for media processing and functions. Media objects are MediaParticipants, such as a Recorder and Player, that can be added to a Communication object.
A composable media object is referred to as Joinable in the Java Media Control API (JSR 309). When a joiner joins a Communication with a joinee, the media streams are connected between them. You can specify the direction of the joining media streams. Each MediaParticipant encapsulates a Joinable defined by the Media Control API. It is also possible to create a MediaParticipant using a pre-created Joinable. This allows the application to specify advanced Media Control API parameters using SFT. The Media Control API allows you to register an event listener to listen for media events. For example, the media event “Playing Finished,” signaling the end of a media stream's playback. SFT has its own event annotations for common media events. SFT also allows you to annotate a CommunicationBean as a MediaEventListener. This enables all JSR 309 media events to be received by the Communication bean. Since these events occur like any other SFT defined event, the CommunicationContext—and hence the relevant Communication—are also available to the MediaEvent.
Media server configuration can be performed using the JNDI name of the MediaSessionFactory in use by the CommunicationBean interface.
The SFT API exposes the ability to search Communication interfaces, allowing converged applications to locate the correct Communication object. Communication objects can be searched based on the name of the participant(s) or the name of communication itself. For example, an application might want to find a communication session that is already underway.
SFT applications are packaged in the standard WAR file format. When a @CommunicationBean annotation and sft.xml deployment descriptor is present in the WAR file, SFT provisions an internal SIP Servlet to handle SIP requests. For composing multiple applications, a standard JSR 289 application router is used, which treats the SFT application as a SIP application.
See Chapter 18, "Packaging and Deploying SFT Applications," to learn more about packaging and deploying SFT applications.
Annotations are a type of metadata that enable a declarative style of programming. The CommunicationBean uses annotations to encapsulate common functions or roles fulfilled by communication applications. Instead of specifying the code that performs the function, you simply add the annotation to the source file. The SFT framework expands the annotation to the appropriate code.
Annotations take the form of @annotation_name, where annotation_name identifies the annotation. Some annotations take arguments, which you specify alongside the annotation.
Table 17-3 lists the annotations available within SFT.
| Annotation | Description |
|---|---|
|
|
Injects a |
|
|
SFT scans Java classes for this annotation, and, when found, instantiates the Java class and uses them as event listeners. Methods using this annotation are invoked by SFT to listen for the specified event types. |
|
|
Specifies events pertaining to a communication. Any method using this annotation is invoked when a |
|
|
Specifies events pertaining to a participant. Any method using this annotation is invoked when a |
Example 17-5 illustrates the use of the com.oracle.sft.api.bean.CommunicationBean class-level annotation. The type = Conversation.class argument specifies that this CommunicationBean be applied to the Conversation class, which represents a two-party communication. This example creates the Java class MyConversationBean. The @Context annotation injects instances of the CommunicationContext and CommunicationSession objects.
CommunicationContext provides information related to the current communication to the application, and is linked to the event currently being handled by the CommunicationBean. The CommunicationSession object creates Communication related objects from the communication session. When an event—either a CommunicationEvent or ParticipantEvent—is executed, the same CommunicationSession object is injected into the CommunicationBean.
Also shown is this example are two methods declared using the @CommunicationEvent annotation: handleInit() and handleEstablish(). The handleInit() method listens for communication events of Type.INITIALIZATION, which identifies the method as the initializing event in a communication session. The handleEstablish() method listens for communication events of Type.ESTABLISH, signifying events where a media session is established. See "Using the @CommunicationEvent Annotation" to learn more about event types.
Example 17-5 Using The @CommunicationBean Annotation
@CommunicationBean(type = Conversation.class)
public class MyConversationBean {
@Context CommunicationContext ctx;
@Context CommunicationSession session;
@CommunicationEvent(type=CommunicationEvent.Type.INITIALIZATION)
public void handleInit() {
}
@CommunicationEvent(type=CommunicationEvent.Type.ESTABLISHED)
public void handleEstablish() {
}
}
...
As described earlier, SFT provides two method-level annotations by which you can declare and instantiate methods that respond to events:
@ParticipantEvent specifies events pertaining to a participant in the communication.
@CommunicationEvent specifies events pertaining to a communication session.
The @CommunicationEvent and @ParticipantEvent annotations define a number of read-only constants that provide important information about an event. These constants provide an easy way to refer to specific event types. The example below illustrates the CommunicationEvent.Type.INITIALIZATION event, which initializes a communication session.
@CommunicationEvent(type=CommunicationEvent.Type.INITIALIZATION)
The following example illustrates the event handling that occurs in a simple Conversation (a two-party call). Figure 17-1 shows the flow of events as they are triggered by the application.
The caller initiates a call which invokes an INITIALIZATION event in the CommunicationBean. All communication within an SFT application begins with an INITIALIZATION event type—which as the name implies—initializes the communication.
The CommunicationBean responds with SIP ACK messages, acknowledging receipt of a SIP INVITE from the caller. The sending of ACKs is handled by the STARTED communication event. If the application rejects the call, the communication ends.
If the application redirects the call (for example, to voice mail) the Conversation ends, and a ParticipantEvent event type is called by the application to create a communication between the caller and the Recorder interface, which allows the caller to record a voice message.
If ACKs are sent and received by both the caller and callee (the person being called has answered the phone), the CommunicationBean invokes the ESTABLISHED event, indicating that communication is established between the two parties.
If the callee chooses to reject the call (the person being called does not answer the phone) the CommunicationBean invokes the FAILED event, indicating that the communication has been rejected by the callee.
In cases where the CommunicationBean invokes the ESTABLISHED event, the communication continues until one of the parties ends the call by hanging up the phone. This invokes the FINISHED event, signifying that the communication has ended.
The following examples step you through a simple CommunicationBean that handles Conversation events.
All communication begins with an INITIALIZATION event. The handleInit() method processes an incoming SIP INVITE, using the Conversation interface, which represents a two-party call.
@CommunicationEvent(type = CommunicationEvent.Type.INITIALIZATION)
void handleInit() {
Conversation call = (Conversation) ctx.getCommunication();
//Remaining code omitted for brevity
The CommunicationBean acknowledges receipt of the SIP INVITE from the caller, sending an ACK message. The sending of ACKs is handled by the STARTED communication event.
@CommunicationEvent(type = CommunicationEvent.Type.STARTED)
void handleStart() {
//Remaining code omitted for brevity
When the callee (the person being called) answers the phones, ACKs are sent and received by both the caller and callee, and the CommunicationBean invokes the ESTABLISHED event, establishing communication between the two parties.
@CommunicationEvent(type = CommunicationEvent.Type.ESTABLISHED)
void handleEstablish() {
//Remaining code omitted for brevity
The FINISHED event signifies that the communication has ended, and is only invoked in cases where communication was established via the ESTABLISHED event, and the communication continues until one of the parties ends the call by hanging up the phone.
@CommunicationEvent(type = CommunicationEvent.Type.FINISHED)
void handleFinish() {
System.out.println("Call Finished :" + ctx.getCommunication());
}
The @ComunicationEvent method-level annotation identifies events pertaining to a communication. Methods declared with @ComunicationEvent are invoked when a communication event of the specified type occurs.
Example 17-6 illustrates the use of the @CommunicationEvent annotation specifying an Type.INITIALIZATION event type, which declares the handleInit() method as the initializing event in a communication session. The initialization event occurs when a Communication object is created as a result of SFT receiving a SIP message. For example, when a SIP INVITE message reaches SFT, by default it creates a Conversation object, and invokes the method associated with the Type.INITIALIZATION event type so that the application can respond appropriately to the communication session being established. In this example, the createConference() method converts the Conversation object into a Conference object via a method call using the sess object reference variable.
Example 17-6 The @CommunicationEvent Annotation
@CommunicationBean
public class MyCommunicationBean {
@Context CommunicationSession sess;
@Context CommunicationContext ctx;
@CommunicationEvent(type=CommunicationEvent.Type.INITIALIZATION)
void handleInit() {
Conversation call = (Conversation) ctx.getCommunication();
String confName = call.getCallee().getUserName();
if (confName.equalsIgnoreCase("conf1@example.com")) {
sess.createConference(confName, call);
}
}
}
...
SFT applications listen for events that occur in response to SIP messages from the network or a media server. Events mark a logical stage in a communication session. For example, an initial SIP INVITE generates an INITIALIZATION event in the CommunicationBean. From that initial event, the CommunicationBean generates an event at each logical stage of the communication session. An INITIALIZATION event might be followed by STARTED, ESTABLISHED, and FINISHED events.
Events pertaining to a communication are declared using the @CommunicationEvent method level annotation, and those pertaining to a participant are declared using the @ParticipantEvent method level annotation.
Example 17-7 The @CommunicationEvent Annotation
@CommunicationBean
public class MyCommunicationBean {
@Context CommunicationSession sess;
@Context CommunicationContext ctx;
@CommunicationEvent(type=CommunicationEvent.Type.INITIALIZATION)
void handleInit() {
Conversation call = (Conversation) ctx.getCommunication();
String confName = call.getCallee().getUserName();
if (confName.equalsIgnoreCase("conf1@example.com")) {
sess.createConference(confName, call);
}
}
}
Since events are optional, you don't need to include each event type in your application. Instead, you only need to include events relevant to the type of communication session being established. When a particular event type is not implemented in the application, SFT proceeds with the default behavior of that communication session.
For example, in a two-party call, if a callee rejects an INVITE with the 486 Busy Here SIP response code, SFT generates a REJECTED event, allowing the application to remove the rejected callee participant, and add another participant as the callee. In such an instance, SFT adds that party to the call (for example, using INVITE or REINVITE). If the application does not override the default behavior of the REJECTED event, the 486 SIP response code is sent to the caller, and the communication session is terminated.
Since events are optional, the simplest CommunicationBean does not need to have any methods. Such a CommunicationBean acts as a back-to-back user agent (B2BUA) facilitating a two-party call.
Table 17-4 lists the @CommunicationEvent enumeration types. To learn more about @CommunicationEvent, its usage, and the event types it provides, refer to the Converged Application Server API Reference.
Table 17-4 CommunicationEvent Enumeration Types
| Enumeration | Description |
|---|---|
|
ABORTED |
Indicates that the Communication has been aborted by the initiator. |
|
CONFIRMATION_FINISHED |
Indicates that the End User Confirmation message has finished. |
|
CONFIRMATION_MESSAGEARRIVED |
Indicates that an End User Confirmation message arrived during an IMConversation. |
|
CONFIRMATION_RESPONDED |
Indicates that an End User Confirmation response message arrived during an IMConversation. |
|
ERROR |
Indicates that an error occurred in the Communication. |
|
ESTABLISHED |
Indicates that the Communication is established. |
|
FAILED |
Indicates that the Communication has failed. |
|
FINISHED |
Indicates that the Communication is finished. |
|
FINISHING |
Indicates that the Participant is requesting to finish (or end) an established Communication. |
|
FORWARDING |
Indicates that a call is being forwarded. |
|
HELD |
Indicates that a call is in a held state. |
|
HOLDING |
Indicates that a call is being held. |
|
INITIALIZATION |
Indicates that a Communication is being initialized. |
|
MEDIA |
Generic event that act as a capture all for any media event in the media server. |
|
MEDIA_INFO_EARLY_EXCHANGED |
Indicates that end-to-end media information is to be exchanged before the called party answers the call (picks-up the phone). End-to-end refers to information being exchanged between the calling party (the caller) to the called party (the callee). |
|
MEDIA_RESOURCE_RESERVED |
Indicates that a media resource has been reserved. This event is triggered after a media exchange between the calling and called party when the media server finishes streaming content. You can trigger this event by adding a MediaParticipant. |
|
MEDIAENDED |
Indicates that media being streamed from the media server has ended. |
|
MESSAGE_FAILURE_RESPONDED |
A 4xx, 5xx, or 6xx response that an IM message has arrived. |
|
MESSAGE_SUCCESS_RESPONDED |
A 2xx response of IM message arrived. |
|
MESSAGEARRIVED |
Indicates that a message arrived. The message could be an IM sent during an IMConversation, or a DTMF Signal message during a Conversation or Conference. |
|
MESSAGEINDICATION |
A Message Indication arrived during an IMConversation. |
|
NOTIFICATION |
Indicates that a new notification has been created. |
|
PICKUP |
Indicates that the called party has picked-up the phone (answered the call). |
|
QUERIED |
Indicates that the a query has responded. |
|
QUERYING |
Indicates that the process of querying (such as for device capability) has been initiated. |
|
REFER |
Indicates a REFER event. |
|
RESUMED |
Indicates that a call is already resumed. |
|
RESUMING |
Indicates that a call is being resumed. |
|
STARTED |
Indicates that a Communication has started. |
|
SUBSCRIPTION |
Indicates that a new subscription is to be created. |
|
WAITING |
Indicates that call is waiting. |
The @ParticipantEvent method-level annotation identifies events pertaining to a participant in the communication. Methods declared with @ParticipantEvent are invoked when a participant event of the specified type occurs.
Example 17-8 The @ParticipantEvent Annotation
@CommunicationBean
public class MyCommunicationBean {
@Context CommunicationContext<Conversation,UserParticipant> ctx;
@ParticipantEvent(type= ParticipantEvent.Type.JOINING, communicationType =
Conversation.class)
public void hanldeStatedEvent() {
Conversation call = (Conversation) ctx.getCommunication();
Table 17-4 lists the @ParticipantEvent enumeration types. To learn more about @ParticipantEvent, its usage, and the event types it provides, refer to the Converged Application Server API Reference.
Table 17-5 ParticipantEvent Enumeration Types
| Enumeration | Description |
|---|---|
|
BEING_BANNED |
The participant is about to be rejected by the application server (call barring). |
|
ERROR |
An unexpected error happened pertaining to the Participant. |
|
INITIALIZATION |
The first participant event during the entire Participant life-cycle. |
|
JOINED |
The Participant has joined the communication. |
|
JOINING |
Participant is about to join the communication. |
|
LEFT |
The Participant has left the communication. |
|
REJECTED |
The Participant has refused to join the communication. |
The SFT sample application demonstrates the use the SFT APIs to create a telecommunication service application. The example application allows you to build and deploy a simple 411 directory assistance service that demonstrates the following:
Establish an audio conversation with another user.
Establish an audio conference with multiple users.
Play a call announcement and transfer the call to another callee.
Create a Message Session Relay Protocol (MSRP) conversation and conference in which users can exchange Instant Messages (IMs) and share pictures or other files.
All source code, deployment descriptors, and build files for the examples are found in
MiddleWare_Home\occas_Version\samples\s4e
See Readme.htm for descriptions of the example, source code, and build files.
|
 Copyright © 2005, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|