No Custom Parameters
Accepts an incoming call, indicating to the remote endpoint that the called party is present and may subsequently answer.
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, 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
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.
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.
|Parameter Name||.NET Type||Default||Description|
|CallId *||Indicates the call to accept with |
|Parameter Name||.NET Type||Description|
|CallId||Indicates the call that was accepted. This is always the same value passed in as the |
|MmsId||Unique identifier used to identify the media engine in control of this connection.
A common use for this ID is to ensure that other connections which will ultimately be conferenced with this connection are all created on the same media engine.
This correlation is necessary because all connections in a single conference must all reside on the same media engine. This field will only be populated if the partition of the script instance is configured to |
|ConnectionId||Unique identifier used to identify this connection in all subsequent Media Control API operations. Before using with most Media Control actions, this connection must still be fully connected with |
|MediaRxIP||The IP address that the Rx RTP stream must be sent to for this connection. This field will only be populated if the partition of the script instance is configured to |
|MediaRxPort||The IP address that the Rx RTP stream must be sent to for this connection. This field will only be populated if the partition of the script instance is configured to |