cisco.uc.cuae.legacy
Class BaseJTapiServer

java.lang.Object
  cisco.uc.cuae.legacy.BaseJTapiServer

All Implemented Interfaces:

CuaeCommon, CuaeCommonServer, JTapi, JTapiServer, etch.bindings.java.support.ObjSession

public class BaseJTapiServer
extends java.lang.Object
implements JTapiServer, etch.bindings.java.support.ObjSession

Base implementation of JTapiServer, with default method implementations which throw UnsupportedOperationException. Extend this class to provide implementations of messages from the client.

See Also:

ImplJTapiServer

Nested Class Summary

Nested classes/interfaces inherited from interface cisco.uc.cuae.legacy.JTapi

JTapi.DeviceType, JTapi.JTapiAnswerCallOptions, JTapi.JTapiAnswerCallResult, JTapi.JTapiBlindTransferOptions, JTapi.JTapiBlindTransferResult, JTapi.JTapiCallActiveOptions, JTapi.JTapiCallEstablishedOptions, JTapi.JTapiCallInactiveOptions, JTapi.JTapiCallInitiatedOptions, JTapi.JTapiConferenceOptions, JTapi.JTapiConferenceResult, JTapi.JTapiGetCallForwardStatusOptions, JTapi.JTapiGetCallForwardStatusResult, JTapi.JTapiGetDeviceStatusOptions, JTapi.JTapiGetDeviceStatusResult, JTapi.JTapiGotDigitsOptions, JTapi.JTapiHangupCallOptions, JTapi.JTapiHangupOptions, JTapi.JTapiHangupResult, JTapi.JTapiHoldOptions, JTapi.JTapiHoldResult, JTapi.JTapiIncomingCallOptions, JTapi.JTapiMakeCallOptions, JTapi.JTapiMakeCallResult, JTapi.JTapiNonTriggeringSubscribeOptions, JTapi.JTapiNonTriggeringSubscribeResult, JTapi.JTapiRedirectOptions, JTapi.JTapiRedirectResult, JTapi.JTapiRejectCallOptions, JTapi.JTapiRejectCallResult, JTapi.JTapiResumeOptions, JTapi.JTapiResumeResult, JTapi.JTapiSendXSIDataOptions, JTapi.JTapiSendXSIDataResult, JTapi.JTapiStartMonitoringOptions, JTapi.JTapiStartMonitoringResult, JTapi.JTapiUnsubscribeOptions, JTapi.JTapiUnsubscribeResult, JTapi.PlayToneDirection

Nested classes/interfaces inherited from interface cisco.uc.cuae.legacy.CuaeCommon

CuaeCommon.CuaeResult

Nested classes/interfaces inherited from interface cisco.uc.cuae.legacy.CuaeCommon

CuaeCommon.CuaeResult

Constructor Summary

BaseJTapiServer()

Method Summary

void	_sessionControl(java.lang.Object control, java.lang.Object value)
void	_sessionNotify(java.lang.Object event)
java.lang.Object	_sessionQuery(java.lang.Object query)
JTapi.JTapiAnswerCallResult	jTapiAnswerCall(java.lang.String sessionId, java.lang.Long callId, JTapi.JTapiAnswerCallOptions options) Answers a call currently ringing on a monitored device.
JTapi.JTapiBlindTransferResult	jTapiBlindTransfer(java.lang.String sessionId, java.lang.Long callId, java.lang.String to, JTapi.JTapiBlindTransferOptions options) Transfers an established call on a monitored device to a new destination.
JTapi.JTapiConferenceResult	jTapiConference(java.lang.String sessionId, java.lang.Long callId, java.lang.Long volatileCallId, JTapi.JTapiConferenceOptions options) Conferences two established calls that exist on the same line and device.
JTapi.JTapiGetCallForwardStatusResult	jTapiGetCallForwardStatus(java.lang.String sessionId, java.lang.String deviceName, java.lang.String directoryNumber, JTapi.JTapiGetCallForwardStatusOptions options) Gets the call forward status of a line on a monitored device.
JTapi.JTapiGetDeviceStatusResult	jTapiGetDeviceStatus(java.lang.String sessionId, java.lang.String deviceName, JTapi.JTapiGetDeviceStatusOptions options) Gets the device status of a phone using JTAPI.
JTapi.JTapiHangupResult	jTapiHangup(java.lang.String sessionId, java.lang.Long callId, JTapi.JTapiHangupOptions options) Hangs up a call currently active on a monitored device.
JTapi.JTapiHoldResult	jTapiHold(java.lang.String sessionId, java.lang.Long callId, JTapi.JTapiHoldOptions options) Puts an active call on a monitored device on hold.
JTapi.JTapiMakeCallResult	jTapiMakeCall(java.lang.String sessionId, java.lang.String to, java.lang.String deviceName, java.lang.String from, JTapi.JTapiMakeCallOptions options) Causes a monitored device to place a call from a specific line.
JTapi.JTapiNonTriggeringSubscribeResult	jTapiNonTriggeringSubscribe(java.lang.String sessionId, java.lang.String deviceName, java.lang.String devicePoolName, JTapi.DeviceType deviceType, JTapi.JTapiNonTriggeringSubscribeOptions options) Registers a device with JTAPI.
JTapi.JTapiRedirectResult	jTapiRedirect(java.lang.String sessionId, java.lang.Long callId, java.lang.String to, java.lang.String prefferedOriginalCalledParty, JTapi.JTapiRedirectOptions options) Redirects a call currently ringing on a monitored device to a new destination.
JTapi.JTapiRejectCallResult	jTapiRejectCall(java.lang.String sessionId, java.lang.Long callId, JTapi.JTapiRejectCallOptions options) Rejects a call currently ringing on a monitored device, ending it.
JTapi.JTapiResumeResult	jTapiResume(java.lang.String sessionId, java.lang.Long callId, java.lang.String rxIP, java.lang.Long rxPort, JTapi.JTapiResumeOptions options) Resume a held call on a monitored device.
JTapi.JTapiSendXSIDataResult	jTapiSendXSIData(java.lang.String sessionId, java.lang.String deviceName, java.lang.String xSIData, JTapi.JTapiSendXSIDataOptions options) Send XSI data to a monitored phone.
JTapi.JTapiStartMonitoringResult	jTapiStartMonitoring(java.lang.String sessionId, java.lang.String targetCallId, java.lang.String targetDeviceName, java.lang.String targetLineDN, java.lang.String listenerLineDN, JTapi.JTapiStartMonitoringOptions options) Starts monitoring the audio stream of an active call on a monitored device.
JTapi.JTapiUnsubscribeResult	jTapiUnsubscribe(java.lang.String sessionId, java.lang.String deviceName, JTapi.JTapiUnsubscribeOptions options) Unregisters a device with JTAPI.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

BaseJTapiServer

public BaseJTapiServer()

Method Detail

_sessionQuery

public java.lang.Object _sessionQuery(java.lang.Object query)
                               throws java.lang.Exception

Specified by:

_sessionQuery in interface etch.bindings.java.support.ObjSession

Throws:

java.lang.Exception

_sessionControl

public void _sessionControl(java.lang.Object control,
                            java.lang.Object value)
                     throws java.lang.Exception

Specified by:

_sessionControl in interface etch.bindings.java.support.ObjSession

Throws:

java.lang.Exception

_sessionNotify

public void _sessionNotify(java.lang.Object event)
                    throws java.lang.Exception

Specified by:

_sessionNotify in interface etch.bindings.java.support.ObjSession

Throws:

java.lang.Exception

jTapiAnswerCall

public JTapi.JTapiAnswerCallResult jTapiAnswerCall(java.lang.String sessionId,
                                                   java.lang.Long callId,
                                                   JTapi.JTapiAnswerCallOptions options)

Description copied from interface: JTapiServer

Answers a call currently ringing on a monitored device. None. JTapiAnswer answers an incoming call that is ringing on a phone device currently being monitored by the application server. Once the action has successfully completed, the device being monitored will answer the ringing call. The application would have already received notification of the incoming call via the triggering JTapiIncomingCall event. The CallId present as an event parameter in the JTapiIncomingCall event would then be used as the CallId action parameter for the JTapiAnswer action. You can not successfully use JTapiAnswer after the ringing device has been answered (most likely cause is the user answering the phone, but another JTAPI-based application could be the cause of the answer as well). You can know in your application that the call has already been answered if the JTapiCallActive fires before you have used the JTapiAnswer action. If the calling party hangs up their end of the call before the call is answered, then it is no longer valid to use JTapiAnswer. You can know in your application that the call has already been hung up if the JTapiHangup event fires after the JTapiIncomingCall event instead of JTapiCallActive. If call is rejected with JTapiReject, then it is no longer valid to use JTapiAnswer.

Specified by:

jTapiAnswerCall in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to answer with JTapiAnswer. The CallId must have originated from a JTapiIncomingCall event.

options - An object holding all the optional parameters

jTapiHold

public JTapi.JTapiHoldResult jTapiHold(java.lang.String sessionId,
                                       java.lang.Long callId,
                                       JTapi.JTapiHoldOptions options)

Description copied from interface: JTapiServer

Puts an active call on a monitored device on hold. The JTapiCallInactive will fire as a result of using this action successfully. JTapiHold puts an active call on hold. For this action to succeed, the script must have already received notification of the call entering the active state with the nontriggering JTapiCallActive event.

Specified by:

jTapiHold in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to be put on hold with JTapiHold.

options - An object holding all the optional parameters

jTapiResume

public JTapi.JTapiResumeResult jTapiResume(java.lang.String sessionId,
                                           java.lang.Long callId,
                                           java.lang.String rxIP,
                                           java.lang.Long rxPort,
                                           JTapi.JTapiResumeOptions options)

Description copied from interface: JTapiServer

Resume a held call on a monitored device. The JTapiCallActive will fire as a result of using this action successfully. JTapiResume resumes a held call. For this action to succeed, at a minimum, the script must have already received notification of the call entering the inactive state with the nontriggering JTapiCallInactive event. However, the JTapiCallInactive event does not necessarily always correspond to a call being held.

Specified by:

jTapiResume in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to be resumed with JTapiResume.

rxIP - The IP address that the resumed audio should be sent to, from the monitored device. If this field is not specified, then the audio will resume sending to where it would have, if this parameter were not specified. In other words, not specifying this parameter generally causes the monitored device to begin streaming to the device it was previously streaming to before the call was held. This field has only rare use and should almost always be left specified.

rxPort - The port that the resumed audio should be sent to, from the monitored device. If this field is not specified, then the audio will resume sending to where it would have, if this parameter were not specified. In other words, not specifying this parameter generally causes the monitored device to begin streaming to the device it was previously streaming to before the call was held. This field has only rare use and should almost always be left unspecified.

options - An object holding all the optional parameters

jTapiRejectCall

public JTapi.JTapiRejectCallResult jTapiRejectCall(java.lang.String sessionId,
                                                   java.lang.Long callId,
                                                   JTapi.JTapiRejectCallOptions options)

Description copied from interface: JTapiServer

Rejects a call currently ringing on a monitored device, ending it. None. JTapiReject rejects a call inbound to a phone device, causing the call to end immediately. You can not successfully use JTapiReject after the ringing device has been answered (most likely cause is the user answering the phone, but another JTAPI-based application could be the cause of the answer as well). You can know in your application that the call has already been answered if the JTapiCallActive fires before you have used the JTapiReject action.

Specified by:

jTapiRejectCall in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to reject with JTapiReject. The CallId must have originated from a JTapiIncomingCall event.

options - An object holding all the optional parameters

jTapiHangup

public JTapi.JTapiHangupResult jTapiHangup(java.lang.String sessionId,
                                           java.lang.Long callId,
                                           JTapi.JTapiHangupOptions options)

Description copied from interface: JTapiServer

Hangs up a call currently active on a monitored device. The JTapiHangup event will still fire when one uses this action. JTapiHangup hangs a call currently active on a phone device, causing the call to end immediately. If the other party hangs up their end of the call before this action is used, then there is no need to use JTapiHangup, since the call is over. You can know that the call has been hung up by anything other than the script if the JTapiHangup event fires.

Specified by:

jTapiHangup in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to hangup with JTapiHangup.

options - An object holding all the optional parameters

jTapiMakeCall

public JTapi.JTapiMakeCallResult jTapiMakeCall(java.lang.String sessionId,
                                               java.lang.String to,
                                               java.lang.String deviceName,
                                               java.lang.String from,
                                               JTapi.JTapiMakeCallOptions options)

Description copied from interface: JTapiServer

Causes a monitored device to place a call from a specific line. None. JTapiMakeCall will cause a line on a monitored device to place a call. The JTapiCallActive event will fire to the same script that issued the JTapiMakeCall, if the remote party specified by the To action parameter answers the call. If the remote party specified by the To action parameter answers the call, then the call is bound to this script, meaning JTapiCallActive, JTapiCallInactive, JTapiGotDigits, and JTapiHangup event will fire to the same script that issued the JTapiMakeCall. If the outbound call from the monitored phone is cancelled before the remote party answers, then a JTapiHangup event is sent to the same script that issued the JTapiMakeCall. A device in Cisco Unified Communications Manager does not make or receive calls; the line(s) on that device do. Therefore it is necessary to specify a real line number found on the device as the value of the From action parameter.

Specified by:

jTapiMakeCall in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

to - The destination number for this call. In practice, this number must be routable according to the dial plan of the Cisco Unified Communications Manager cluster that the call is sent to.

deviceName - The name of a controlled device from which to place the call. The From action parameter must be a valid line number on this device.

from - The line on the controlled device from which to originate the call leg.

options - An object holding all the optional parameters

jTapiConference

public JTapi.JTapiConferenceResult jTapiConference(java.lang.String sessionId,
                                                   java.lang.Long callId,
                                                   java.lang.Long volatileCallId,
                                                   JTapi.JTapiConferenceOptions options)

Description copied from interface: JTapiServer

Conferences two established calls that exist on the same line and device. There must be conferencing resources available in the Cisco Unified Communications Manager deployment for the phone that has both calls. JTapiConference will conference, or 'join', two calls together that have been established on the same line for a given device. Both calls must have been answered already, and both calls must exist on the same line.

Specified by:

jTapiConference in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - One of the two calls that have been established on the same line.

volatileCallId - One of the two calls that have been established on the same line. This call ID will be destroyed afterwards, because 2 calls are being joined into one. All future call events will be sent up with the ID specified by the CallId action parameter.

options - An object holding all the optional parameters

jTapiRedirect

public JTapi.JTapiRedirectResult jTapiRedirect(java.lang.String sessionId,
                                               java.lang.Long callId,
                                               java.lang.String to,
                                               java.lang.String prefferedOriginalCalledParty,
                                               JTapi.JTapiRedirectOptions options)

Description copied from interface: JTapiServer

Redirects a call currently ringing on a monitored device to a new destination. None. JTapiRedirect redirects a call inbound to a phone device, causing the call to be sent to a new destination elsewhere. You can not successfully use JTapiRedirect after the ringing device has been answered (most likely cause is the user answering the phone, but another JTAPI-based application could be the cause of the answer as well). You can know in your application that the call has already been answered if the JTapiCallActive fires before you have used the JTapiAnswer action.

Specified by:

jTapiRedirect in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to redirect with JTapiRedirect.

to - The destination number for the redirected call. In practice, this number must be routable according to the dial plan of the Cisco Unified Communications Manager cluster that the call is sent to.

prefferedOriginalCalledParty - The called party information that would appear in the redirect request.

options - An object holding all the optional parameters

jTapiBlindTransfer

public JTapi.JTapiBlindTransferResult jTapiBlindTransfer(java.lang.String sessionId,
                                                         java.lang.Long callId,
                                                         java.lang.String to,
                                                         JTapi.JTapiBlindTransferOptions options)

Description copied from interface: JTapiServer

Transfers an established call on a monitored device to a new destination. None. JTapiBlindTransfer transfers an answered call, causing the call to be sent to a new destination elsewhere. Once the transfer has completed, the call is completely removed from the control of the application server. You can successfully use JTapiBlindTransfer only after the device has been answered. You can know in your application that the call has already been answered if the JTapiCallActive fires before you have used the JTapiBlindTransfer action.

Specified by:

jTapiBlindTransfer in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to redirect with JTapiBlindTransfer.

to - The destination number for the transferred call. In practice, this number must be routable according to the dial plan of the Cisco Unified Communications Manager cluster that the call is sent to.

options - An object holding all the optional parameters

jTapiGetCallForwardStatus

public JTapi.JTapiGetCallForwardStatusResult jTapiGetCallForwardStatus(java.lang.String sessionId,
                                                                       java.lang.String deviceName,
                                                                       java.lang.String directoryNumber,
                                                                       JTapi.JTapiGetCallForwardStatusOptions options)

Description copied from interface: JTapiServer

Gets the call forward status of a line on a monitored device. JTapiGetCallForwardStatus gets the call forward status of a line on a monitored phone. If the action is successful, the CallForwardType result data parameter should be used to determine the status of the call forwarding status. If the CallForwardType indicates that the line has the forward condition Unconditional, then the Digits parameter can be used to determine which destination the line is currently forwarded to.

Specified by:

jTapiGetCallForwardStatus in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

deviceName - The name of a controlled device from whose call forward status is queried. The DirectoryNumber action parameter must be a valid line number on this device.

directoryNumber - The line number on the device whose call forward status needs to be determined.

options - An object holding all the optional parameters

jTapiStartMonitoring

public JTapi.JTapiStartMonitoringResult jTapiStartMonitoring(java.lang.String sessionId,
                                                             java.lang.String targetCallId,
                                                             java.lang.String targetDeviceName,
                                                             java.lang.String targetLineDN,
                                                             java.lang.String listenerLineDN,
                                                             JTapi.JTapiStartMonitoringOptions options)

Description copied from interface: JTapiServer

Starts monitoring the audio stream of an active call on a monitored device. JTapiStartMonitoring is supported only on Cisco Unified Communications Manager 6.0 and above. The monitoring target phone has to be a 3rd-generation phone, such as the 7911G, 7931G, 7941G, 7941G-GE, 7961G, 7961G-GE, 7970G, and 7971G-GE phone models. The built-in bridge must be turned 'ON' in the device configuration of the monitored target phone. JTapiStartMonitoring requires that the line indicated by TargetLineDN has the 'Monitoring Calling Search Space' configuration in Cisco Unified Communications Manager set to a value such that it can call the 'Route Partition' of the ListenerLineDN line. JTapiStartMonitoring will start monitoring a call on the specified destination specified by the combination of TargetDeviceName, TargetLineDN, and TargetCallId. The JTapiStartMonitoring action has two fundamentally different modes of operation. One mode causes the monitored audio stream to be sent to a physical device for human observation. If this is the desired behavior for the application, then one should specify ListenerDeviceName and ListenerLineDN to indicate which line on which device should be called. The ListenerDevicePool has no use and should be left unspecified in this mode of operation. The other mode causes the audio stream to be sent to a destination of the choosing of the application, as specified by RxIP and RxPort. If instead this is the desired behavior for the application, then one must set ListenerDevicePool to indicate to the application server which pool of CTI ports should be used to control the destination of the audio stream. With the second mode, the stream could be sent to a recording server, a Cisco IP Phone that's been told to listen on a specific port using XSI commands, or a previously provisioned media engine connection. Finally, one should not set ListenerDeviceName and ListenerLineDN if using the second mode. If specifying ListenerDevicePool so that the audio stream destination can be controlled, then this device pool should have as many CTI Ports configured within it as the maximum concurrent amount of monitors expected with JTapiStartMonitoring. In other words, one CTI Port will be used during the lifetime of a monitor. Note that the device pool described here is configured within the mceadmin web interface; this is not the device pool configured within Cisco Unified Communications Manager. The CallId result data parameter is the unique identifier for this call. All Call Control API actions and events use CallId, so practically the application developers almost always stores this CallId value in a variable for the use in subsequent Call Control operations. This CallId should not be considered unique across multiple application servers. The monitor will be stopped permanently if the JTapiCallInactive or JTapiHangup event occurs.

Specified by:

jTapiStartMonitoring in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

targetCallId - The call ID of the call that will be monitored.

targetDeviceName - The device name of a JTAPI-controlled device that has associated with it the TargetLineDN.

targetLineDN - The monitoring target directory number to initiate the monitor on. The RX and TX audio will be mixed by the TargetDeviceName, and will be sent to either the ListenerLineDN, or to RxIP:RxPort, depending on usage of those action parameters.

listenerLineDN - The line number that should receive the monitor call. If specified, also specify ListenerDeviceName, but do not specify ListenerDevicePool. In Cisco Unified Communications Manager, the 'Route Partition' on this line must be callable by the 'Monitoring Calling Search Space' defined on the TargetLineDN line.

options - An object holding all the optional parameters

jTapiSendXSIData

public JTapi.JTapiSendXSIDataResult jTapiSendXSIData(java.lang.String sessionId,
                                                     java.lang.String deviceName,
                                                     java.lang.String xSIData,
                                                     JTapi.JTapiSendXSIDataOptions options)

Description copied from interface: JTapiServer

Send XSI data to a monitored phone. JTapiSendXSIData and SendExecute both allow one to send an XSI command to an IP Phone. To help determine which one is more appropriate, consider the following points: The SendExecute action requires an IP address to send the XML command to using an HTTP POST. However, it is a common problem to not have the IP address of a Cisco IP phone readily available, although often one has the device name (of the form SEPXXXXXXXXXXXX) of the phone. While it is possible that one can use the Cisco DeviceListX cache to determine IP address of a Cisco IP Phone based on this device name, with JTapiSendXSIData only the phone device name is needed. SendExecute sends an HTTP request from the application server directly to the phone; whereas JTapiSendXSIData instructs Cisco Unified Communications Manager to send the command via the phone's transport protocol. Because of this difference, the JTapiSendXSIData command is generally more robust when one considers firewalls and security policies. For instance, because IP Communicator runs on the personal computer of an end user, it is possible that the user has a firewall running on that machine. Also, in some Cisco Unified Communication Manager deployments, it is possible that the internal web server on the IP Phone has been turned off, rendering SendExecute useless. When SendExecute is executed, the IP phone will request from its configured 'Authentication URL' whether the username and password sent to the phone is valid. By default, this request is sent to the Cisco Unified Communications Manager publisher node, which makes this determination by checking that specified credentials match the credentials of a user associated with the phone in the Cisco Unified Communications Manager database. In contrast, with JTapiSendXSIData, super user credentials can be used to send commands to any phone, without having to know the enduser associated with that phone. This action communicates with the Cisco IP Phone using the phone's protocol (SCCP or SIP) as the transport. JTapiSendXSIData will send XSI data to the monitored phone. A maximum of 2000 bytes can be sent to the phone. JTapiSendXSIData is supported in Cisco Unified Communications Manager 5.0 and above. JTapiSendXSIData can send two distinctly different commands to the Cisco IP Phone. One type of command is the Execute XML object, which is used to cause the phone to execute internal commands, such as RTPRx or Dial, or to cause the phone to fetch IP Phone XML from an HTTP server. JTapiSendXSIData can also used to send content-based XML objects, such as a Text or Menu XML object. The Cisco IP Phones have an important limitation in that one can only push 2000 bytes of content to the phone. This effectively means that pushing a Execute XML object to a phone is the more robust way to have the phone render large amounts of data, instead of pushing a potentially large content-based XML object, such as Text or Menu. With an Execute XML object, one can send an HTTP-based URI that will server out the content-based XML, circumventing the 2000 byte 'push' limitation. There is no 2000 byte limitation when the phone makes a request to a HTTP-based URI.

Specified by:

jTapiSendXSIData in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

deviceName - The name of a controlled device which will be sent the XSI command.

xSIData - The XSI object to be pushed to the monitored device. The object can not be directly passed in to this parameter. Instead, one must invoke the ToString() method on the object, and the resulting string must be passed in.

options - An object holding all the optional parameters

jTapiNonTriggeringSubscribe

public JTapi.JTapiNonTriggeringSubscribeResult jTapiNonTriggeringSubscribe(java.lang.String sessionId,
                                                                           java.lang.String deviceName,
                                                                           java.lang.String devicePoolName,
                                                                           JTapi.DeviceType deviceType,
                                                                           JTapi.JTapiNonTriggeringSubscribeOptions options)

Description copied from interface: JTapiServer

Registers a device with JTAPI. The JTapiNonTriggeringSubscribe action is a way for an application to register a device at application run-time. However, one can also specify devices for permanent JTAPI registration via the mceadmin web interface. he following information is meant to help determine if you should use the mceadmin 'static' mechanism, or the JTapiNonTriggeringSubscribe dynamic mechanism: if you know that you need to always monitor a phone in order to catch certain interesting events which occur non-deterministically, then use the static mechanism available via mceadmin. If instead you only need to monitor a phone for a specific, deterministic amount of time, then this dynamic mechanism is probably more ideal because there is a maximum number of concurrent JTAPI registrations possible for a given Cisco Unified Communications Manager cluster. By registering a device only as you need it, an application which does not have extremely high usage patterns could help keep the total number of registrations below this maximum concurrent amount, but still be able to control any device in the deployment as needed. If the application server is restarted, then all registrations created via JTapiNonTriggeringSubscribe will be lost and are not automatically re-created upon startup of the application server. JTapiNonTriggeringSubscribe will register a device dynamically. The specific Cisco Unified Communications Manager node to which the device is registered is decided by the specified DevicePoolName, which is described in mceadmin. Note that the device pool described by DevicePoolName is a Cisco Unified Application Environment configuration; it is completely distinct from device pools as defined by Cisco Unified Communications Manager. If a device has successfully been registered with JTapiNonTriggeringSubscribe, then later that device can be unregistered with JTapiUnsubscribe.

Specified by:

jTapiNonTriggeringSubscribe in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

deviceName - The device name of the device to be registered.

devicePoolName - The device pool to which this device should be placed in. This device pool is configured in the mceadmin web interface, and does not correspond to device pools as defined by Cisco Unified Communications Manager.

deviceType - The device type of the device. This must currently be set to CtiMonitored in all situations.

options - An object holding all the optional parameters

jTapiUnsubscribe

public JTapi.JTapiUnsubscribeResult jTapiUnsubscribe(java.lang.String sessionId,
                                                     java.lang.String deviceName,
                                                     JTapi.JTapiUnsubscribeOptions options)

Description copied from interface: JTapiServer

Unregisters a device with JTAPI. None JTapiUnsubscribe will unregister a device previously successfully registered with JTapiNonTriggeringSubscribe.

Specified by:

jTapiUnsubscribe in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

deviceName - The device name of the device to be unregistered.

options - An object holding all the optional parameters

jTapiGetDeviceStatus

public JTapi.JTapiGetDeviceStatusResult jTapiGetDeviceStatus(java.lang.String sessionId,
                                                             java.lang.String deviceName,
                                                             JTapi.JTapiGetDeviceStatusOptions options)

Description copied from interface: JTapiServer

Gets the device status of a phone using JTAPI. JTapiGetDeviceStatus gets the device status of a monitored phone using JTAPI.

Specified by:

jTapiGetDeviceStatus in interface JTapiServer

Parameters:

sessionId - The session Id for this method call

deviceName - The name of a controlled device to query.

options - An object holding all the optional parameters