No Custom Parameters
Starts monitoring the audio stream of an active call on a monitored device.
JTapiStartMonitoring will start monitoring a call on the specified destination specified by the combination of
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
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
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
ListenerLineDN if using the second mode.
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.
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.
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
|Parameter Name||.NET Type||Default||Description|
|PlayToneDirection||The direction in which a recording indicator tone will be played. If not specified, no tone will be played. Valid values area as follows:
|ListenerDevicePool||The name of the device pool containing application server-controlled devices. If specified, also specify |
|ListenerDeviceName||The device name of a device that should receive the monitor call. If specified, also specify |
|ListenerLineDN *||The line number that should receive the monitor call. If specified, also specify |
|TargetDeviceName *||The device name of a JTAPI-controlled device that has associated with it the |
|TargetCallId *||The call ID of the call that will be monitored.|
|TargetLineDN *||The monitoring target directory number to initiate the monitor on. The RX and TX audio will be mixed by the |
|RxIP||The IP address that the monitored audio should be sent to. If specified, also specify |
|RxPort||The port that the monitored audio should be sent to. If specified, also specify |
|Parameter Name||.NET Type||Description|
|ResultCode||Describes the result of the action. If a failure occured, will indicate the cause of the failure.
The following are possible values:
|CallId||Unique identifier used to identify this call in all subsequent Call Control API operations.|