Extension SDK for BEA WebLogic Network Gatekeeper
Call Control
The following sections contain descriptions of plug-ins of call control type:
Network plug-in
Interfaces
All call control interfaces are defined in the package com.incomit.resources.callcontrol.
The call control interfaces are similar to the Parlay 3.2 call control interfaces.
Figure 8-1 Call control interface
Interfaces that should be implemented by the plug-in are listed in the table below.
Table 8-1 Interfaces that shall be implemented by a plug-in for Call control
|
Interface
|
Description
|
|
CallControlResource
|
Initial object obtained from Plug-in Manager.
|
|
IrCallControlManager
|
Deprecated.
|
|
IrCallControlManagerExt
|
The extended resource multi-party call control manager interface provides the management functions to the multi-party call control plug-ins.
|
|
IrCall
|
The logical representation of a call.
|
|
IrCallLeg
|
The logical representation of a call leg.
|
Interfaces that are implemented by the Call Control SC.
Table 8-2 Interfaces that are implemented by the Call Control SC, used by a Call control plug-in.
|
Interface
|
Description
|
|
IrCallControlPlugInListener
|
Call back interface for receiving network initiated calls, overload events and so on.
|
|
IrAppCall
|
Interface that is used by plug-in to receiving events related to calls.
|
|
IrAppCallLeg
|
Interface for receiving events related to a call leg.
|
CallControlResource
CallControlResource inherits from the Resource interface and adds an additional method that is used to obtain the call control manager.
Table 8-3 CallControlResource
|
Method
|
Description
|
|
getCallControlManager
|
Retrieve call control manager.
|
IrCallControlManager - Deprecated -
IrCallControlManager is deprecated.
IrCallControlManagerExt
IrCallControlManagerExt is used to create calls, handle load control, and to register plug-in listeners. Only one instance of this type is required.
Table 8-4 IrCallControlManagerExt
|
Method
|
Description
|
|
createCallCtx
|
Create a new call object.
|
|
disableNotification
|
Disable a call notification.
|
|
enableNotification
|
Enables a call notification for network initiated traffic.
|
|
setCallLoadControlCtx
|
Used for call gapping.
|
IrCall
IrCall interface represents a call. Each active call will have one object instance implementing this interface, or if the plug-in uses the session id only one instance is required.
Table 8-5 IrCall
|
Method
|
Description
|
|
createCallLeg
|
Create a new call leg.
|
|
deassignCall
|
De-assign the call without disconnect.
|
|
getCallLegs
|
Retrieve a list of all call legs belonging to this call.
|
|
getInfoReq
|
Request to receive call information when the call is disconnected.
|
|
release
|
Release this call and disconnect all call legs.
|
|
setAdviceOfCharge
|
Set advice of charge information.
|
|
setCallback
|
Change the call back object used for this call.
|
|
setChargePlan
|
Set the call charge plan.
|
|
superviseReq
|
Supervise a call, that is set granted connect time for this call.
|
IrCallLeg
The IrCallLeg interface represents a call leg. For each leg in a call there must be an instance implementing this interface, or if the plug-in uses the session id only one instance is required.
Table 8-6 IrCallLeg
|
Method
|
Description
|
|
attachMediaReq
|
Attach a detached call leg.
|
|
continueProcessing
|
Resume call processing.
|
|
deassign
|
Release control of leg. The call will remain, but all requested call info and events are disabled.
|
|
detachMediaReq
|
Detach this leg from the call. That is no connection will exist with other call legs.
|
|
eventReportReq
|
Request to event reports.
|
|
getCall
|
Retrieve the call object that this leg belongs to.
|
|
getInfoReq
|
Request to receive call information when the call leg is disconnected.
|
|
release
|
Disconnect this call leg.
|
|
routeReq
|
Route this call leg.
|
|
setAdviceOfCharge
|
Set advice of charge information.
|
|
setCallback
|
Change the call back object used for this call.
|
|
setChargePlan
|
Set the call charge plan for this leg.
|
|
superviseReq
|
Set granted connect time for this call leg.
|
IrCallControlPlugInListener
IrCallControlPlugInListener listens for events originating in the plug-in. There may be several listeners registered for each plug-in.
This interface inherits from the SCS interface. It makes it possible to narrow a SC object retrieved from the SC Manager to an IrCallControlPlugInListener.
Table 8-7 IrCallControlPlugInListener
|
Method
|
Description
|
|
callOverloadCeased
|
Report that overload has ceased.
|
|
callOverloadEncountered
|
Report an overload in the plug-in.
|
|
reportNotification
|
Send notification about a network-triggered call.
|
IrAppCall
IrAppCall is used to receive events related to a specific call.
Table 8-8 IrAppCall
|
Method
|
Description
|
|
callEnded
|
Notification that the call has ended.
|
|
superviseRes
|
Response to a previous call to superviseReq.
|
|
superviseErr
|
Response to a previous call to superviseErr.
|
|
getInfoErr
|
This asynchronous method reports that the original request was erroneous, or resulted in an error condition.
|
|
getInfoRes
|
This asynchronous method reports time information of the finished call or call attempt as well as release cause depending on which information has been requested by getInfoReq.
|
IrAppCallLeg
IrAppCallLeg is used to receive events related to a specific call leg.
Table 8-9 IrAppCallLeg
|
Method
|
Description
|
|
attachMediaRes/Err
|
Response to a previous call to attachMediaReq.
|
|
callLegEnded
|
Inform that call leg has ended.
|
|
detachMediaRes/Err
|
Response to a previous call to detachMediaReq.
|
|
eventReportRes/Err
|
Response to a previous call to eventReportReq.
|
|
getInfoRes/Err
|
Response to a previous call to getInfoReq.
|
|
routeErr
|
Report an error when routing call leg.
|
|
superviseRes/Err
|
Response to a previous call to superviseReq.
|
Use cases
Application-initiated two-party call
The following sequence diagram show a basic two-party call. How the SC obtains the call control manager is not shown here.
Figure 8-2 Application-initiated two-party call
Details about the sequence diagram:
- The client application requests to create a new call and this object is created and returned.
- A call leg is created for the first party.
- Event reports and call information is requested. Charge plan is set and the call is routed. Preferably, the plug-in would buffer these calls and send everything when routeReq is called. getInfoReq and setChargePlan are not mandatory.
- After a while when the call leg is answered the answer event is sent to the application with eventReportRes. Other events could also be sent here, such as busy or no answer.
- The application decides to connect another call leg to this call.
- The same methods may be invoked as when creating the first call leg. The first call leg is in interrupted state, so call processing is on hold until continueProcessing is invoked on this leg.
- attachMediaReq is invoked on the first call leg. Note that all call legs created by an application are detached initially.
- continueProcessing is invoked. At this time, any buffered events in the previous steps should be sent.
- The second leg is answered and eventReportRes is called.
- The leg is attached and continueProcessing invoked.
- The application decides to release the call.
- Call information is sent for each call leg where information was requested.
- The end of the call is notified.
Network-triggered call
This example shows how a basic network-triggered call may be handled. For each new call the plug-in should use the SC Manager to obtain a listener interface or use one of the registered plug-in listeners.
Figure 8-3 Network-triggered call
Details about the sequence diagram:
- The plug-in receives a network triggered call event and creates the call and call leg object that is sent to the plug-in listener. The call is now in interrupted state.
- The application creates the callback interfaces and notifies the plug-in about these.
- The application requests to receive event notification for the first call leg.
- A new call leg is created.
- First event reports are requested for this leg. Then the call leg is routed, but no operations are sent until continueProcessing is invoked.
- The second call leg is answered.
- The second call leg is attached to the call and continueProcessing is invoked.
- The call is de-assigned. This will release all objects related to this call, but the call will remain active in the network.
