cisco.uc.cuae.legacy
Class BaseCallControlServer

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

All Implemented Interfaces:

CallControl, CallControlServer, CuaeCommon, CuaeCommonServer, etch.bindings.java.support.ObjSession

public class BaseCallControlServer
extends java.lang.Object
implements CallControlServer, etch.bindings.java.support.ObjSession

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

See Also:

ImplCallControlServer

Nested Class Summary

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

CallControl.AcceptCallEarlyMediaOptions, CallControl.AcceptCallEarlyMediaResult, CallControl.AcceptCallOptions, CallControl.AcceptCallResult, CallControl.AnswerCallOptions, CallControl.AnswerCallResult, CallControl.BargeOptions, CallControl.BargeResult, CallControl.BlindTransferOptions, CallControl.BlindTransferResult, CallControl.BridgeCallsOptions, CallControl.BridgeCallsResult, CallControl.CallChangedOptions, CallControl.GetRemoteMediaOptions, CallControl.GetRemoteMediaResult, CallControl.GotDigitsOptions, CallControl.HangupOptions, CallControl.HangupResult, CallControl.IncomingCallOptions, CallControl.MakeCallOptions, CallControl.MakeCallResult, CallControl.RedirectOptions, CallControl.RedirectResult, CallControl.RejectCallOptions, CallControl.RejectCallResult, CallControl.RemoteHangupOptions, CallControl.SendUserInputOptions, CallControl.SendUserInputResult, CallControl.StartRxOptions, CallControl.StartTxOptions, CallControl.StopTxOptions, CallControl.UnbridgeCallsOptions, CallControl.UnbridgeCallsResult, CallControl.WaitForMedia

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

CuaeCommon.CuaeResult

Constructor Summary

BaseCallControlServer()

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)
CallControl.AcceptCallResult	acceptCall(java.lang.String sessionId, java.lang.String callId, CallControl.AcceptCallOptions options) Accepts an incoming call, indicating to the remote endpoint that the called party is present and may subsequently answer.
CallControl.AcceptCallEarlyMediaResult	acceptCallEarlyMedia(java.lang.String sessionId, java.lang.String callId, CallControl.AcceptCallEarlyMediaOptions options) Accepts an incoming call, indicating to the remote endpoint that the called party is present and may subsequently answer.
CallControl.AnswerCallResult	answerCall(java.lang.String sessionId, java.lang.String callId, java.lang.String displayName, CallControl.AnswerCallOptions options) Answers an incoming call, indicating to the remote endpoint that the called party is willing to participate in the call.
CallControl.BargeResult	barge(java.lang.String sessionId, java.lang.String from, java.lang.String mediaRxIP, java.lang.Long mediaRxPort, CallControl.BargeOptions options) Requests to be in an impromptu conference with an active call that has been established on a shared line.
CallControl.MakeCallResult	beginMakeCall(java.lang.String sessionId, java.lang.String to, java.lang.String from, java.lang.String displayName, CallControl.MakeCallOptions options, java.lang.Object state)
CallControl.BlindTransferResult	blindTransfer(java.lang.String sessionId, java.lang.String callId, java.lang.String to, CallControl.BlindTransferOptions options) Transfers the application server's side of an established call to the specified destination.
CallControl.BridgeCallsResult	bridgeCalls(java.lang.String sessionId, java.lang.String callId, CallControl.BridgeCallsOptions options) BridgeCalls will cause both call legs in a peer-to-peer relationship to renegotiate their audio streams to instead transmit and receive audio to a media engine; in the process creating two new media engine connections.
CallControl.GetRemoteMediaResult	getRemoteMedia(java.lang.String sessionId, java.lang.String callId, CallControl.GetRemoteMediaOptions options) Retrieves the remote party's media informations such as RTP IP address, port number, codec, etc.
CallControl.HangupResult	hangup(java.lang.String sessionId, java.lang.String callId, CallControl.HangupOptions options) Ends a call.
CallControl.MakeCallResult	makeCall(java.lang.String sessionId, java.lang.String to, java.lang.String from, java.lang.String displayName, CallControl.MakeCallOptions options) Places an outbound call from the application server to a specified destination.
CallControl.RedirectResult	redirect(java.lang.String sessionId, java.lang.String callId, java.lang.String to, CallControl.RedirectOptions options) Redirects the application server's side of a pending call to the specified destination.
CallControl.RejectCallResult	rejectCall(java.lang.String sessionId, java.lang.String callId, CallControl.RejectCallOptions options) Rejects an incoming call, indicating to the remote endpoint that the called party is not able to receive this call.
CallControl.SendUserInputResult	sendUserInput(java.lang.String sessionId, java.lang.String callId, java.lang.String digits, CallControl.SendUserInputOptions options) Sends the specified digits to a call leg.
CallControl.UnbridgeCallsResult	unbridgeCalls(java.lang.String sessionId, java.lang.String callId, java.lang.String peerCallId, CallControl.UnbridgeCallsOptions options) UnbridgeCalls will cause the two call legs specified to form a peer-to-peer relationship, in the process renegotiating their audio streams to receive and transmit to each other, bypassing the media engine.

Methods inherited from class java.lang.Object

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

Constructor Detail

BaseCallControlServer

public BaseCallControlServer()

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

makeCall

public CallControl.MakeCallResult makeCall(java.lang.String sessionId,
                                           java.lang.String to,
                                           java.lang.String from,
                                           java.lang.String displayName,
                                           CallControl.MakeCallOptions options)

Description copied from interface: CallControlServer

Places an outbound call from the application server to a specified destination. An audio connection between the called destination and media engine is created automatically when one uses MakeCall, except for calls that are designated as peer-to-Peer by the PeerCallId action parameter. The application server automatically uses ReserveConnection and CreateConnection while the call is being established with the remote endpoint, with the end result of a valid ConnectionId being made available in the resulting MakeCall_Complete. This ConnectionId can then be used by the Media Control API. When the call is hung up by either party, the ConnectionId is destroyed automatically by the application server. The script does not have direct control over which telephony protocol is when placing the call, or which Cisco Unified Communications Manager is used to send the call to. The protocol used, and the Cisco Unified Communications Manager that is signalled when making the call, is determined by the configured Call Route Group on the current application partition. The script does not have direct control over which media engine is used when placing the call, unless MmsId is specified. In the case that MmsId is not specified, the media engine used to process the audio connection is determined by the current Media Resource Group on the current application partition. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. The Reserve Media Early configuration on the script instance partition specifies whether a media engine connection should be provisioned with ReserveConnection as soon as the call is initiated, or if the application server should wait to until the media negotiation phase of the call ensues before reserving the connection. The media negotiation phase often comes as the call is answered by the remote endpoint, but can also come before the call is answered as well. MakeCall will place a call to the destination specified by To. The resulting call leg, if completed, is a VOIP 'bridge' between the application server and the endpoint which answered the call, which could be a phone, voicemail, or another application. The practical use of MakeCall is to establish a call and media connection with a remote endpoint, essentially bringing a script into a telephony conversation and opening up the ability to utilize the other actions and events in the Call Control and Media Control APIs. The application has little control over where the call is routed beyond the application server. See Call Routing for more information on how the application server interfaces with the outside world for the routing of calls. 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. Once a call is placed with MakeCall, it will either eventually complete with the MakeCall_Complete event, meaning the call is answered and audio is flowing, or the call will fail with the MakeCall_Failed event, meaning the call is over (and the CallId for the call is no longer valid). There are a number of reasons why a call can fail to establish. When a calls fails to complete, the MakeCall_Failed event fires, with an EndReason event parameter indicating why the call failed. As soon as a call is made, a number of unsolicited events can potentially occur, based on activity occurring in the call. These are GotDigits, RemoteHangup, StartTx, StopTx, and StartRx. One can abort a 'ringing' call not yet established (a call is established, or completed, when the MakeCall_Complete event occurs) by using Hangup. To do so, supply to the Hangup action the CallId value returned as result data of the MakeCall action.

Specified by:

makeCall in interface CallControlServer

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. All telephony protocols support this field.

from - The calling number, or 'caller ID', to present for this call. Not all telephony protocols support this field; please consult the Call Control Feature Matrix.

displayName - A free string which describes the initiator of the call. Not all telephony protocols support this field; please consult the Call Control Feature Matrix.

options - An object holding all the optional parameters

beginMakeCall

public CallControl.MakeCallResult beginMakeCall(java.lang.String sessionId,
                                                java.lang.String to,
                                                java.lang.String from,
                                                java.lang.String displayName,
                                                CallControl.MakeCallOptions options,
                                                java.lang.Object state)

Specified by:

beginMakeCall in interface CallControlServer

barge

public CallControl.BargeResult barge(java.lang.String sessionId,
                                     java.lang.String from,
                                     java.lang.String mediaRxIP,
                                     java.lang.Long mediaRxPort,
                                     CallControl.BargeOptions options)

Description copied from interface: CallControlServer

Requests to be in an impromptu conference with an active call that has been established on a shared line. A connection is created only if MediaRxIP and MediaRxPort are not specified. In this case, it is also important to consider that the script does not have direct control over which media engine is used to create a connection when barging. The media engine used to process the audio connection is determined by the current Media Resource Group on the current application partition. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. Barge allows one to push an application into the audio streams of an active call previously uncontrolled by the application server, by causing the call to conference in a Media Server connection. The conferencing (mixing of audio) is handled by the phone in this case, not the media engine. If MediaRxIP and MediaRxPort are specified, a connection will not be made on the media server, and instead the phone will send the conferenced audio to that specified Rx location. When the call is ended by either party, the ConnectionId is destroyed automatically by the application server. Barge offers a means to overcome the difficult problem of gaining control of the media streams without having control over the call. However, Barge requires a significant amount of configuration in the deployment. To invoke Barge successfully, one has to have deployed a Cisco Unified Application Environment virtual SCCP phone in a shared-line configuration with an existing phone that needs to be barged into. Also, Barge will only work if the real phone has been configured to use its built-in device bridge. Finally, it is only valid to invoke Barge while the call is active--typically this knowledge is gained by also using JTAPI JTapiCallActive events to know when the real phone has an active call.

Specified by:

barge in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

from - The directory number of the shared line to barge into.

mediaRxIP - The IP address that the conferenced audio should be sent to. If MediaRxIP is not specified along with MediaRxPort, then a connection is created automatically which has Tx and Rx streams bridged appropriately from the conference to the media engine.

mediaRxPort - The port that the conferenced audio should be sent to. If MediaRxPort is not specified along with MediaRxIP, then a connection is created automatically which has Tx and Rx streams bridged appropriately from the conference to the media engine.

options - An object holding all the optional parameters

acceptCall

public CallControl.AcceptCallResult acceptCall(java.lang.String sessionId,
                                               java.lang.String callId,
                                               CallControl.AcceptCallOptions options)

Description copied from interface: CallControlServer

Accepts an incoming call, indicating to the remote endpoint that the called party is present and may subsequently answer. An audio connection between the called destination and media engine is created automatically when one uses Accept call, provided that Reserve Media Early is set to true on the partition of the script instance. The application server automatically uses ReserveConnection, with the end result of a valid ConnectionId being made available in the ConnectionId result data. This ConnectionId can then be used by the Media Control API. When the call is ended by either party, the ConnectionId is destroyed automatically by the application server. The script does not have direct control over which media engine is used when accepting the call. The media engine used to process the audio connection is determined by the current Media Resource Group on the current application partition. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. When a call is inbound to an script via IncomingCall, the call is in a ringing state and a script can choose to do one of 5 things: AcceptCall, AnswerCall, Redirect, RejectCall, or simply do nothing with the call. The practical use of Accept is to extend the amount of time that the call will remain in a ringing state, buying the application more time to perform logic before commiting to answering or rejecting the call. From the perspective of the script instance initiated by the incoming call, the telephony protocol of the call has already been chosen by the time IncomingCall has been fired. However, any call created by the application via MakeCall or Barge will use the protocol configured on the application partition of the script instance. See Call Routing for more information on how the application server interfaces with the outside world for the routing of calls.

Specified by:

acceptCall in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to accept with AcceptCall.

options - An object holding all the optional parameters

acceptCallEarlyMedia

public CallControl.AcceptCallEarlyMediaResult acceptCallEarlyMedia(java.lang.String sessionId,
                                                                   java.lang.String callId,
                                                                   CallControl.AcceptCallEarlyMediaOptions options)

Description copied from interface: CallControlServer

Accepts an incoming call, indicating to the remote endpoint that the called party is present and may subsequently answer. This will also setup a one way media session from CUAE to the caller. If a call is received over SIP with remote media information and Reserve Media Early is set to true on the partition of the script instance instance then if the application calls AcceptCallEarlyMedia API then it will reserves the resources on media engine for the call. The application server automatically uses ReserveConnection, with the end result of a valid ConnectionId being made available in the ConnectionId result data. This ConnectionId can then be used by the Media Control API. AcceptCallEarlyMedia API does not setup the transmit side of the media for the media engine. To setup the transmit side of the media for the media engine the application needs to call GetRemoteMedia> and CreateConnection APIs. When the call is ended by either party, the ConnectionId is destroyed automatically by the application server. The script does not have direct control over which media engine is used when accepting the call. The media engine used to process the audio connection is determined by the current Media Resource Group on the current application partition. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses the Call Control Feature Matrix makes developing such guidelines feasible. When a call is inbound to an script via IncomingCall, the call is in a ringing state and a script can choose to do one of 5 things: AcceptCallEarlyMedia, AcceptCall, AnswerCall, Redirect, RejectCall, or simply do nothing with the call. The practical use of AcceptCallEarlyMedia is to establish a one way media session from media engine to the caller which can be used to play a message. After the call to AcceptCallEarlyMedia the application can decide to answer or reject the call. In case of failure response for the AcceptCallEarlyMedia the application does not need to terminate the call. The application look at the FailReason result parameter and process accordingly. From the perspective of the script instance initiated by the incoming call, the telephony protocol of the call has already been chosen by the time IncomingCall has been fired. However, any call created by the application via MakeCall or Barge will use the protocol configured on the application partition of the script instance. See Call Routing for more information on how the application server interfaces with the outside world for the routing of calls.

Specified by:

acceptCallEarlyMedia in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to accept with AcceptCallEarlyMedia.

options - An object holding all the optional parameters

getRemoteMedia

public CallControl.GetRemoteMediaResult getRemoteMedia(java.lang.String sessionId,
                                                       java.lang.String callId,
                                                       CallControl.GetRemoteMediaOptions options)

Description copied from interface: CallControlServer

Retrieves the remote party's media informations such as RTP IP address, port number, codec, etc. This API can be used for retrieving the media details of the remote party. These media details are then used for the call to CreateConnection to setup the transmit side of the media in the media engine. When in incoming call is received or outgoing call is made at any moment the script can call this API to retrieve the media details of the remote party. These media details can be used in CreateConnection API If no call is active or the remote media information is not yet available for the call then this API call returns an error. An error returned by this API can be a normal behavior and the script may not terminate the call in the error condtions.

Specified by:

getRemoteMedia in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call for which the remote media information need to be retrievedGetRemoteMedia.

options - An object holding all the optional parameters

answerCall

public CallControl.AnswerCallResult answerCall(java.lang.String sessionId,
                                               java.lang.String callId,
                                               java.lang.String displayName,
                                               CallControl.AnswerCallOptions options)

Description copied from interface: CallControlServer

Answers an incoming call, indicating to the remote endpoint that the called party is willing to participate in the call. An audio connection between the called destination and media engine is created automatically when one uses Answer. The application server automatically uses ReserveConnection and CreateConnection while the call is being established with the remote endpoint, with the end result of a valid ConnectionId result data parameter. This ConnectionId can then be used by the Media Control API. When the call is hung up by either party, the ConnectionId is destroyed automatically by the application server. The script does not have direct control over which media engine is used when answering the call, unless MmsId is specified. In the case that MmsId is not specified, the media engine used to process the audio connection is determined by the current Media Resource Group on the current application partition. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. The Reserve Media Early configuration on the script instance partition specifies whether a media engine connection should be provisioned with ReserveConnection as soon as the call is initiated, or if the application server should wait to until the media negotiation phase of the call ensues before reserving the connection. The media negotiation phase often comes as the call is answered by the remote endpoint, but can also come before. Due to the small amount of time AnswerCall usually takes to complete, Reserve Media Early is less important compared to the impact it has on MakeCall. When a call is inbound to an script via IncomingCall, the call is in a ringing state and a script can choose to do one of 5 things: AnswerCall, AcceptCall, Redirect, Reject, or simply do nothing with the call. The practical use of Answer is to establish a call and media connection with a remote endpoint, essentially bringing a script into a telephony conversation and opening up the ability to utilize the other actions and events in the Call Control and Media Control APIs. From the perspective of the script instance initiated by the incoming call, the telephony protocol of the call has already been chosen by the time IncomingCall has been fired. However, any call created by the application via MakeCall or Barge will use the protocol configured on the partition of the script instance. See Call Routing for more information on how the application server interfaces with the outside world for the routing of calls. As soon as a call is answered, a number of unsolicited events can potentially occur. These are GotDigits, RemoteHangup, StartTx, StopTx, and StartRx.

Specified by:

answerCall in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to answer with AnswerCall.

displayName - A free string which describes the initiator of the call. Not all telephony protocols support this field; please consult the Call Control Feature Matrix.

options - An object holding all the optional parameters

rejectCall

public CallControl.RejectCallResult rejectCall(java.lang.String sessionId,
                                               java.lang.String callId,
                                               CallControl.RejectCallOptions options)

Description copied from interface: CallControlServer

Rejects an incoming call, indicating to the remote endpoint that the called party is not able to receive this call. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. When a call is inbound to an script via IncomingCall, the call is in a ringing state and a script can choose to do one of 5 things: RejectCall, AnswerCall, Redirect, AcceptCall, or simply do nothing with the call. The practical use of Reject is to indicate to the calling party that their call could not be completed. From the perspective of the script instance initiated by the incoming call, the telephony protocol of the call has already been chosen by the time IncomingCall has been fired. However, any call created by the application via MakeCall or Barge will use the protocol configured on the partition of the script instance. See Call Routing for more information on how the application server interfaces with the outside world for the routing of calls.

Specified by:

rejectCall in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to reject with RejectCall.

options - An object holding all the optional parameters

hangup

public CallControl.HangupResult hangup(java.lang.String sessionId,
                                       java.lang.String callId,
                                       CallControl.HangupOptions options)

Description copied from interface: CallControlServer

Ends a call. When the call is hung up, a call that is not in a peer-to-peer relationship has the associated ConnectionId destroyed automatically; there is no need to use DeleteConnection with a call that has been hungup. Note that the behavior for a call in a peer-to-peer relationship is significantly different. The other call established as a peer is also hung up. There is no media connection associated with either call in a peer-to-peer relationship so there is no media connection cleanup in that regard. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. Hangup allows one to end a call that was previously created by a successful AnswerCall, MakeCall, or Barge. Hangup can also be used to abort an uncompompleted, ringing outbound call that has been placed with MakeCall.

Specified by:

hangup in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates the call to hangup with Hangup.

options - An object holding all the optional parameters

bridgeCalls

public CallControl.BridgeCallsResult bridgeCalls(java.lang.String sessionId,
                                                 java.lang.String callId,
                                                 CallControl.BridgeCallsOptions options)

Description copied from interface: CallControlServer

BridgeCalls will cause both call legs in a peer-to-peer relationship to renegotiate their audio streams to instead transmit and receive audio to a media engine; in the process creating two new media engine connections. Using BridgeCalls completely removes the peer-to-peer relationship of the call; however, internal to the application server, the peer-to-peer relationship of the two CallId participants is retained, which allows one to specify the callId of just one of these calls in the CallId action parameter in UnbridgeCalls (as opposed to having to specify PeerCallId as well). The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. Calls in a peer-to-peer relationship stream media directly to one another, bypassing the media engine. This is advantageous if there is no reason to perfom Media Control API operations on the calls; however, if at some point during the call media control is needed, then BridgeCalls is a means to cause both calls to renegotiate their audio streams and begin streaming to and from the media engine. Using this action creates two media engine connections, one for each call. Either CallId in the peer-to-peer call can be used as the CallId action parameter of this action.

Specified by:

bridgeCalls in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - Indicates either call leg in the peer-to-peer call.

options - An object holding all the optional parameters

unbridgeCalls

public CallControl.UnbridgeCallsResult unbridgeCalls(java.lang.String sessionId,
                                                     java.lang.String callId,
                                                     java.lang.String peerCallId,
                                                     CallControl.UnbridgeCallsOptions options)

Description copied from interface: CallControlServer

UnbridgeCalls will cause the two call legs specified to form a peer-to-peer relationship, in the process renegotiating their audio streams to receive and transmit to each other, bypassing the media engine. Using UnbridgeCalls is one way to create a peer-to-peer relationship between two calls. Another way is to use the PeerCallId action parameter of MakeCall, which is appropriate for certain scenarios. In either case, once a peer-to-peer relationship has been created between two call legs, those calls thereafter can only be in a peer-to-peer relationship with each other. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. Two calls in a Media Control API-driven conference both stream media to and from the media engine. Each in such a scenario has its own media engine connection. This is advantageous if there is reason to perfom Media Control API operations on the calls or the conference; however, if at some point during the call media control is no longer needed, then UnbridgeCalls is a means to cause both the rcemote endpoints of both calls to renegotiate their audio streams and begin streaming to and from each other. Using this action destroys the two existing media engine connections, minimizing the licensing impact of your application.

Specified by:

unbridgeCalls in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - An established call leg to become one party of the peer-to-peer call.

peerCallId - An established call leg which will be linked to CallId in a peer-to-peer fashion. You do not need to specify this value if a peer relationship has already been established between the two calls previously. Further you cannot use this field to change to a different peer if one has already been established.

options - An object holding all the optional parameters

blindTransfer

public CallControl.BlindTransferResult blindTransfer(java.lang.String sessionId,
                                                     java.lang.String callId,
                                                     java.lang.String to,
                                                     CallControl.BlindTransferOptions options)

Description copied from interface: CallControlServer

Transfers the application server's side of an established call to the specified destination. BlindTransfer is currently not supported for a call currently in a peer-to-peer relationship. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. BlindTransfer allows one to attempt to send an already-established call to the destination specified by the To parameter. The transfer attempt is known as 'blind' because, from the application server's standpoint, the result of the transfer attempt is not known after the transfer is complete. The specified CallId and the corresponding media connection of the call are destroyed after this operation has completed successfully.

Specified by:

blindTransfer in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - The CallId of the call leg to transfer.

to - The number to transfer this call to.

options - An object holding all the optional parameters

redirect

public CallControl.RedirectResult redirect(java.lang.String sessionId,
                                           java.lang.String callId,
                                           java.lang.String to,
                                           CallControl.RedirectOptions options)

Description copied from interface: CallControlServer

Redirects the application server's side of a pending call to the specified destination. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. Redirect allows one to attempt to send a pending incoming call (non-answered) to the destination specified by the To parameter. From the application server's standpoint, the result of the redirect attempt is never known. When a call is inbound to an script via IncomingCall, the call is in a ringing state and a script can choose to do one of 5 things: Redirect, AnswerCall, RejectCall, AcceptCall, or simply do nothing with the call. The practical use of Redirect is to send a call somewhere else other than the original destination. The specified CallId of the call is destroyed after this operation has completed successfully. With an application that is using Redirect, keep in mind that eventually the incoming call attempt will timeout and the opportunity to Redirect will have passed. There is no way to retreive or otherwise restore the incoming call if the call attempt times out.

Specified by:

redirect in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - The CallId of the call to redirect.

to - The number to redirect this call to.

options - An object holding all the optional parameters

sendUserInput

public CallControl.SendUserInputResult sendUserInput(java.lang.String sessionId,
                                                     java.lang.String callId,
                                                     java.lang.String digits,
                                                     CallControl.SendUserInputOptions options)

Description copied from interface: CallControlServer

Sends the specified digits to a call leg. The Call Control API makes every effort to abstract the complexities of the underlying telephony protocol; however, one should consult the Call Control Feature Matrix to understand what Call Control actions and action parameters are valid for each of the four supported protocols. One can set installation and deployment guidelines based on the Call Control actions and action parameters that an application uses; the Call Control Feature Matrix makes developing such guidelines feasible. SendUserInput will simulate the occurrence of digits on a call leg, specific to the underlying call control protocol. As an example, SendUserInput would allow one to dial into a voicemail system with an application and input digits to traverse a touch-tone menu as a user would.

Specified by:

sendUserInput in interface CallControlServer

Parameters:

sessionId - The session Id for this method call

callId - The CallId of the call leg to send digits on.

digits - The digit(s) to send.

options - An object holding all the optional parameters