'ccs' capability for WebSocket Token API

The dialog is forcibly broken by sending a BYE to both parties. If the dialog is in the Forking state, performs a forced termination of the dialog by sending CANCEL to all callers and a failed response to the call initiator.

Makes an intercom call to the initiator device specified in the owner field on behalf of the CallManager involving an IVR script. After picking up the handset, makes a transfer to the number specified in the number field.

If the initiator device does not support or prohibits intercom calling, the first service call is made until the initiator picks up the handset. If the initiator device supports and allows intercom calls, the call being made is answered immediately by the device.

In case the initiator device is already in some dialog at the time of command execution, it either makes a second call or interrupts the current dialog by placing it on hold, depending on the device settings. In this case, if the device supports and allows intrusion via intercom call, the current dialog is put on hold and a new initiated dialog is received and automatically answered by the device. Otherwise, if intrusion is not supported or denied, the device receives and displays a second call waiting for the initiator to pick up the handset.

The case of limiting the number of incoming calls for an account. If the initiator account is configured to limit the number of simultaneous calls, and there are no free trunks at the time the initiated new call arrives, the incoming intercom call cannot go through and the command returns a rejection "rejected".

Case of multiple devices. If the initiator has several devices registered to support and allow intercom calls, the call can be answered automatically on any of them. In this case, the choice of a particular device is effectively random.

Optional Parameters:

The alternative invite method has a default value for the parameter 'use_intercom' = false.

NOTE! For intercom mode to work correctly, a featurecode with the intercom type must be configured in the system and available by routes to call the initiator itself on its own behalf.

Optionally the idseance key can be specified. Its value will be included in the binding label for the current call. Later it will be automatically transferred to all subsequent dialogs of the current session created as a result of transfers.

Allows the characters ' and , to be specified in the number. The first such character allocates the remaining sequence as a DTMF pre-dial after a response is received, and each subsequent such character provides a 1-second pause in the set DTMF.

Response Parameters:

Makes the call specified in the number field on behalf of callerid and connects it to the IVR script whose code is specified in the field scriptcode. If no script is specified, the built-in ext_api_management script is started with the transfer of control to the external system. The key field passes the value to the corresponding property of the "External Management" component".

The use_intercom field allows you to initiate an intercom call to a subscriber.

Optional Parameters:

NOTE! For intercom mode to work correctly, a featurecode with the intercom type must be configured in the system and available by routes to call the initiator itself on its own behalf.

Optionally the idseance key can be specified. Its value will be included in the binding label for the current call. Later it will be automatically transferred to all subsequent dialogs of the current session created as a result of transfers.

Allows the characters ' and , to be specified in the number. The first such character allocates the remaining sequence as a DTMF pre-dial after a response is received, and each subsequent such character provides a 1-second pause in the set DTMF.

Response Parameters: * ivrcallid - is the ID of the service CALL from the IVR to the Call Initiator.

Produces a call to the request initiator’s device followed by a transfer to a call intercept number.

Optional Parameters:

NOTE! If no "number" is specified, a group intercept will be attempted.

NOTE! For intercom mode to work correctly, a featurecode with the intercom type must be configured in the system and available by routes to call the initiator itself on its own behalf.

NOTE! For the interception to work correctly, a featurecode with the pickup type must be configured in the system and available by routes to call on behalf of the initiator to the specified number (or to a group in case of group interception).

Makes a call with the specified dialog shoulder swap (idconn), then initiates a REFER command to transfer it to the specified number. The dialog shoulder defined by the idcall parameter is a REFER initiator. The shoulder opposing it is substituted and translated. The dialog (idconn) and its shoulder (idcall) must exist. The call must be active, and cannot be in a call state, or in a state waiting for a response to a sent request.

The idconn value comes as part of events of the ccsevents class, or can be taken from events of the callevents class either from the connectionid field, or constructed as a concatenation of the cid and its..

Optional Parameters:

The idseance key can be optionally specified. Its value will be included in the binding label to the call initiating the interception by an INVITE request with the Replaces header. Thereafter, it will be automatically transferred to all subsequent dialogs of the current session created as a result of transfers.

Allows the characters ' and , to be specified in the number. The first such character allocates the remaining sequence as a DTMF pre-dial after a response is received, and each subsequent such character provides a 1-second pause in the set DTMF.

Response Parameters:

Makes a call with a swapped arm of the specified dialog, after which it initiates the REFER command in order to transfer it by swapping it to another dialog. As a result, subscribers of two different dialogs are connected, and requests are sent to their opponents BYE. The dialog (idconn) and the specified arm (idcall) must exist. The call must be active, and cannot be in a call state, or in a state waiting for a response to a sent request. In case the second call does not exist or is in an inappropriate state, the command will result in both callers of the first dialog being disconnected.

The dialog shoulder defined by the idcall parameter is the initiator of the REFER. The dialog shoulder opposite to it is substituted and translated idconn. Similarly, the target arm of the second idconn2 dialog swap is the arm in opposition to the one specified by the parameter idcall2.

The idconn and idconn2 values come as part of events of the ccsevents class, or can be taken from events of the callevents class or from the connectionid field, or constructed as a concatenation of the cid and its.

Typically, this command points both shoulders of the same caller - the initiator of the request - in order to connect opponents from two conversations involving him.

The idseance key can be optionally specified. Its value will be included in the binding label to the call initiating the interception by an INVITE request with the Replaces header. Thereafter, it will be automatically transferred to all subsequent dialogs of the current session created as a result of transfers.

Emulates a subscriber pressing the HOLD button (putting his/her opponent in the current call on hold).

The dialog (idconn) and the specified arm (idcall) must exist. The call must be active, and cannot be in a call state or waiting for a response to a sent request. The idconn value comes as part of events of the ccsevents class, or can be taken from events of the callevents class either from the connectionid field, or constructed as a concatenation of the cid and its..

NOTE! Expansion device support required broadsoft.

NOTE! Applies only if the Allowed-Events header received from the device during connection establishment contains the value hold. If the Allowed-Events header is not present in all requests and responses from the device, a trial NOTIFY request is also sent according to the broadsoft protocol.

Response Parameters:

Used to automatically hang up the handset on the device to answer an incoming call, as well as to cancel HOLD mode and take the caller off hold.

The dialog (idconn) and the specified arm (idcall) must exist. The call must be active, and cannot be in a call state or waiting for a response to a sent request. The idconn value comes as part of events of the ccsevents class, or can be taken from events of the callevents class either from the connectionid field, or constructed as a concatenation of the cid and its..

NOTE! Expansion device support required broadsoft.

NOTE! Applies only if the Allowed-Events header received from the device during connection establishment contains the talk value. If the Allowed-Events header is not present in all requests and responses from the device, a trial NOTIFY request is also sent according to the broadsoft protocol.

Returns a list of dialogs in the current domain. Used for periodic synchronization of data. It is assumed that the external system receives and event-based data.

Returns brief information about the dialog in the current domain.

Returns a list of calls/shoulders of the current domain. Used for periodic synchronization of data. It is assumed that the external system receives and event-based data.

It is used for the organization of confrenecion, including for the purpose of connecting a prompter.

The dialog (idconn) and the specified arm (idcall) must exist. The call must be active, and cannot be in a call state or waiting for a response to a sent request.

Ends the conference and bounces all participants, discovering it by its identifier 'idconf'. The identifier can be obtained also by dialog with the conference method get_conference

Returns information about a conference, discovering it by its identifier (idconf), or by the dialog of which the conference is one of the subscribers.

or

Returns a list of the current participants of the active conference, locating it by its identifier (idconf). The conference identifier can be retrieved also by dialog with the conference method get_conference.

An identifier ('participantid') and call ID will be returned for each participant ('callid').

Returns information about the specified participant of the active conference, locating it by its identifier (idconf). The conference identifier can be retrieved also by dialog with the conference method get_conference.

Returns the current conference topology, discovering it by its identifier (idconf). The conference identifier can be retrieved also by dialog with the conference method get_conference.

By default, a conference always has an "everyone hears everyone" topology. This rule is always placed first in the output. Next are all the exceptions: who, whom, and the shutdown flag.

Applies a modifier to the current conference topology, detecting it by its identifier (idconf). The conference identifier can be retrieved also by dialog with the conference method get_conference.

By default, a conference always has an "everyone hears everyone" topology. This rule is always placed first in the output. Next are all the exceptions: who, whom, and the shutdown flag.

Implements sending DTMF characters to the specified shoulder of the specified dialog. Sending single characters and sequences of characters is supported. The response to the request is received immediately, but there is a queue in the shoulder to send individual characters. The same queue is used when multiple requests are received.

Allows you to specify a sequence of DTMF characters including ' and ,. Each such character provides a 1 second pause in the set DTMF.

Sending can be done in SIP-INFO or RFC2833.

Dialogue must exist.

By default, sending is done towards the specified shoulder. If opposite = true, the sending is done in the opposite direction to that specified.

Analog of REST-API method SEND_DTMF /rest/v1/uc/calls/:id

Possible parameter values proto:

Searches for a dialog, determines the shoulder, and sends a command to start the recording and streaming stenography process. The topology of the conversation is arranged in such a way that only the speech of the target shoulder of the dialog is recorded.

Dialogue must exist and be in a state of conversation. By default, the specified shoulder is stenographed. If opposite = true, the shoulder selection is inverted.

The layer parameter is optional. Provides the possibility to create different layers in the same dialog. Such layers are written and recognized independently of each other. It is also possible to stop the previous recognition and immediately start a new one while the previous one is still in progress - in order to divide events, for example, when transcribing data filling in various fields of a conversation card. If the same value is specified, the previous session will automatically end and a new session will start instead.

The mode works when the speech steno subsystem (master domain) is installed and configured, settings.record_asr_options)

Analog of REST-API method SETUP_ASR /rest/v1/uc/calls/:id

The notify parameter indicates whether to send events. The default is true - send events as changes occur in the transcript. If false - partial recognition events will not be sent. The result in this case can be taken in the response when disabling recognition with the parameter result_text=true.

For recognition purposes, recording of the specified arm is activated and preliminary results are sent with a lag of about 2 seconds. Sending events with preliminary results occurs on the same connection.

The answer returns:

If you select the mode with notification (notify=true), events with the results will be sent as speech recognition results occur.

Stop streaming recognition with the same layer specified at startup.

Allows you to pinpoint the conversation recording in the specified layer. Regardless of whether conversation recording is enabled according to the rules, whether there is a parallel recording process - by specifying a unique name for a layer it is possible to get a separate recording of the specified time interval.

Dialog labels are string values tied to specific conversations/dialogs, set via API or scripts. Tags are available at any point in the lifecycle of a conversation right up to the end of the conversation. The tags are saved when the call is transferred and transferred to the newly transferred conversation.

Tagging is based on the binding to service sessions in the CC, as well as the mechanism of post call survey.

Post Call Survey - rebound transfer function. If one dialog caller hangs up, and a Post Call Survey is assigned to the other, their shoulder receives a REFER to the assigned number instead of a rebound. This is typically the number of the service level assessment scenario.

Places a dialog label of a special format. Based on the label, the logic of the B2B role serving the dialog works.

Dialogue must exist.

By default, binding is performed to the specified shoulder. That is, the transfer function is activated with respect to it if the opponent hangs up. If opposite = true, the binding is done to the opposite arm.

Additional information: