Receiving transfer status notification

When performing a transfer, VoiceAI Connect can be configured to allow the bot to regain control over the call after a failed transfer attempt. See Transferring the call for more details.

When such handling is configured, VoiceAI Connect sends transfer status notifications to the bot after each transfer attempt, indicating the outcome of the transfer.

VoiceAI Connect Enterprise supports this feature from Version 2.4 and later.

How do I use it?

The notifications to the bot are done using the transferStatus event, which is sent by VoiceAI Connect after each transfer attempt.

The following table lists the fields of the transferStatus event:

Field

Type 

Description

status

String 

Status of call transfer:

  • "answered"

  • "failed"

reasonCode

String 

If a transfer failure occurred, indicates the reason for the failure.

  • "no-answer": The transfer target didn't answer the call (due to a SIP timeout).

  • "busy": The transfer target's number was busy.

  • "declined": The transfer target declined (rejected) the call.

  • "error": An error occurred before the transfer target could answer the call (for example, target number was invalid).

reason

String 

A free text describing the reason of the failure (for example, the SIP Reason header).

The event format and syntax depends on the bot framework. The following table shows the event syntax for each of the bot frameworks.

AudioCodes Bot API

The notification is sent as a transferStatus event activity, with the fields inside the value field.

For example:

{ 
  "type": "event",
  "name": "transferStatus",
  "value": {
    "status": "failed",
    "reasonCode": "declined",
    "reason": "SIP ;cause=603 ;text=\"{603 Decline}\""
  }
}
Microsoft Bot Framework

The notification is sent as a transferStatus event activity, with the fields inside the value field.

For example:

{ 
  "type": "event",
  "name": "transferStatus",
  "value": {
    "status": "failed",
    "reasonCode": "declined",
    "reason": "SIP ;cause=603 ;text=\"{603 Decline}\""
  }
}
Microsoft Copilot Studio

The notification is sent as a transferStatus event activity, with the fields inside the value field.

For example:

{ 
  "type": "event",
  "name": "transferStatus",
  "value": {
    "status": "failed",
    "reasonCode": "declined",
    "reason": "SIP ;cause=603 ;text=\"{603 Decline}\""
  }
}
Microsoft Copilot Studio legacy

The notification is sent as a transferStatus event activity, with the fields inside the value field.

For example:

{ 
  "type": "event",
  "name": "transferStatus",
  "value": {
    "status": "failed",
    "reasonCode": "declined",
    "reason": "SIP ;cause=603 ;text=\"{603 Decline}\""
  }
}
Dialogflow CX

The notification is sent as a transferStatus event, with the fields as the event parameters.

For example:

{
  "queryInput": {
    "event": {
      "name": "transferStatus",
      "parameters": {
        "status": "failed",
        "reasonCode": "declined",
        "reason": "SIP ;cause=603 ;text=\"{603 Decline}\""
      }
    }
  }
}

For Dialogflow CX the fields are also sent inside the event-transferStatus session parameter, and can be accessed using a syntax such as this:

$session.params.event-transferStatus.status
Dialogflow ES

The notification is sent as a transferStatus event, with the fields as the event parameters.

For example:

{
  "queryInput": {
    "event": {
      "name": "transferStatus",
      "parameters": {
        "status": "failed",
        "reasonCode": "declined",
        "reason": "SIP ;cause=603 ;text=\"{603 Decline}\""
      }
    }
  }
}