Parlay X Interface

The ParlayX Third-Party Call Control interface allows a client application:

• to initiate a call between 2 parties
• to read the initiated call status
• to cancel the initiated call
• to end the initiated call

When an "initiate call" request is received, CommuniGate Pro starts the parlayMakeCall Real-Time application on behalf of the authenticated user.

The application parameters are the request parameters: the calling party and called party addresses, and, optionally, the charging parameter.

The callIdentifier returned is the Task ID of the started application.

The "cancel call" and "end call" requests are sent to the started application as cancelCall and endCall events.

The "read status" request returns the contents of the "application status" dictionary set with the started application.

The "add participant" and "delete participant" requests are sent to the started application as addCallPeer and delCallPeer events; the event parameter contains the participant URI specified in the request.

The "transfer participant" requests are sent to the started application as two events.
First, the transferTarget event is sent. Its parameter contains the destination session Task ID.
Then the transferCallPeer event is sent. Its parameter contains the participant URI specified in the request.

The application does not quit immediately after the call fails or is terminated. The application continues to run for some period of time (30 seconds by default), processing the "read status" requests for the completed call/session.

The ParlayX Call Handling interface allows a client application to set Signal Rules for an Account. These Rules include special Parlay Actions that implement the "CallDirection" and "CallNotification" Parlay Interfaces.

The authenticated users can modify their own Account Signal Rules if they have a proper Account setting value.
The authenticated users can read and modify Signal Rules for other Accounts if they are granted Domain Administrator rights.

Note: the stopCallNotification and stopCallDirectionNotification requests must contain the addresses and criteria parts, while the correlator part value is ignored.
This is required since Rules are set individually for each Account, and the correlator data does not allow the Server to direct the Rule deletion request to the proper Account.

Note: the handleXxxxResponse messages can specify the Fork action instead of the Route action. The address(es) specified with the routingAddress part are added to the Signal AOR set, while the current AOR set remains active.

The ParlayX Payment interface allows a client application to access the CommuniGate Pro Billing Manager.

Note: CommuniGate Pro Accounts can maintain several Balances. All ParlayX Payment requests can include an xsd:string-type balanceType element to specify the Account Balance name.

The ParlayX Account Management interface allows a client application to access the CommuniGate Pro Billing Manager.

The ParlayX Call Handling interface allows a client application:

• to set Signal Rules for an Account
• to read Signal Rules set for an Account

The authenticated users can modify their own Account Signal Rules if they have a proper Account setting value.
The authenticated users can read and modify Signal Rules for other Accounts if they are granted Domain Administrator rights.

All acceptList Parlay X elements are converted into one Signal Rule.
All blockList Parlay X elements are converted into one Signal Rule.
The forward element and each forwardList Parlay X elements are converted into three Signal Rules.