GitHubContribute in GitHub: Edit online

copyright: years: 2017, 2023 lastupdated: "2023-01-06"


Reporting call detail record events from Voice Gateway

IBM® Voice Gateway can generate call detail record (CDR) events, which contain summary information about a single call. These events are sent out of Voice Gateway as HTTP POST requests in a form that can be easily integrated with a Splunk HTTP Event Collector (HEC) or a REST server that stores the events. In Versions 1.0.0.5d and later, you can also configure Voice Gateway to publish CDR events directly to IBM Cloudant.

Configuring Voice Gateway to publish call detail record events

  1. Set up a Splunk HTTP Event Collector (HEC) or a REST server that can store the events, for example in a noSQL database. See Configuring Voice Gateway to publish CDR events in an IBM Cloudant database, if you use one to store your events.

  2. In the Voice Gateway configuration, specify your REST server URL and authorization credentials and enable call detail record events by setting the CDR event index value.

    • Single-tenant environment: Set the following environment variables in your configuration.
    REPORTING_URL=http://myresteventserver.ibm.com/
    REPORTING_USERNAME=myRestAdmin
    REPORTING_PASSWORD=myRestTokenOrPassword
    REPORTING_CDR_EVENT_INDEX=cdr
    REPORTING_CDR_EVENT_SOURCE_TYPE=vgwSessionID
    

    • Multi-tenant JSON configuration: In the multi-tenant JSON configuration file, for each tenant where you want to enable call detail record events, configure a reporting object that contains the following properties. You can configure indexes for other types of events, such as transcription or Watson Assistant turn events, within the same object.
    ...
    "reporting": {
      "url": "http://myresteventserver.ibm.com/",
      "username": "myRestAdmin",
      "password": "myRestTokenOrPassword",
      "cdrEventInd": "cdr",
      "cdrEventSourceType" : "vgwSessionID"
    }
    ...
    

    The CDR event index value is included as the index value in all call detail record events so that the REST server that consumes them can differentiate the type of event. The index field is required for Splunk HEC, but it's also useful for anyone who is building their own REST server to handle these events.

Configuring Voice Gateway to publish CDR events in an IBM Cloudant database

Before configuring Voice Gateway to publish to a database, set up an IBM® Cloudant® for IBM Cloud.

Set the following environment variables in your configuration to publish CDR events in an IBM Cloudant database. You can use both IBM Cloudant and another reporting service simultaneously by adding the IBM Cloudant configuration variables to your configuration. You can configure authentication for IBM Cloudant either with an API key by adding the REPORTING_CDR_CLOUDANT_APIKEY variable or by username and password by adding REPORTING_CDR_CLOUDANT_USERNAME and REPORTING_CDR_CLOUDANT_PASSWORD.

The following examples show the configuration for publishing CDR events to IBM Cloudant.

  • Single-tenant environment: Set the following environment variables in your configuration.

    REPORTING_CDR_CLOUDANT_URL =http://mycdrcloudant.ibm.com/
    REPORTING_CDR_CLOUDANT_APIKEY=a1b2c3d3fgh1jk1mn0
    REPORTING_CDR_CLOUDANT_USERNAME=myCloudantUsername
    REPORTING_CDR_CLOUDANT_PASSWORD=myCloudantPassword
    REPORTING_CDR_CLOUDANT_DB_NAME=myCloudantDB
    REPORTING_CDR_CLOUDANT_EVENT_INDEX=cdr
    

    If you use non-default account configurations to IBM Cloudant, you might need to include additional environment variables. See REPORTING_CDR_CLOUDANT_URL and REPORTING_CDR_CLOUDANT_ACCOUNT in Reporting event configuration.

  • Using multi-tenant JSON configuration: In the multi-tenant JSON configuration file, for each tenant where you want to enable call detail record events, configure a reporting object that contains the following properties. If you use non-default account configurations to IBM Cloudant, you might need to include additional environment variables. See cdrCloudant in Properties for the reporting object.

    ...
    "reporting": {
    "cdrCloudant": {
      "url": "http://mycdrcloudant.ibm.com/",
      "username": "myCloudantUsername",
      "password": "myCloudantPassword",
      "apiKey": "myApiKey",
      "dbName": "myCloudantDB",
      "eventInd": "cdr"
    }
    }
    ...
    

Using an API key for authentication

As an alternative to using a user name and password combination for your IBM Cloudant credentials, you can use an API key for authentication. You can find or generate your service credentials to IBM Cloudant, then copy the URL and API key values into your Voice Gateway reporting event configuration. See IBM Cloudant: API keys for more information about API keys.

The following API key authentication examples will work for Cloudant. You can't use an API key to authenticate to CouchDB.

* **Single-tenant environment:** Set the following environment variables in your [configuration](https://www.ibm.com/docs/en/voice-gateway?topic=reference-configuration-environment-variables).
```yaml

REPORTING_CDR_CLOUDANT_URL=http://mycdrcloudant.ibm.com/ REPORTING_CDR_CLOUDANT_APIKEY=a1b2c3d3fgh1jk1mn0 REPORTING_CDR_CLOUDANT_DB_NAME=myCloudantDB REPORTING_CDR_CLOUDANT_EVENT_INDEX=cdr

  {:codeblock}

  * **Multi-tenant JSON configuration**: You must configure the `url` and `apikey` configuration variables instead of `username` and `password`.

  ```json
...
"reporting": {
  "cdrCloudant": {
    "url": "http://mycdrcloudant.ibm.com/",
    "apikey": "a1b2c3d3fgh1jk1mn0",
    "dbName": "myCloudantDB",
    "eventInd": "cdr"
  }
}
...
{:codeblock}

Configuring Voice Gateway to publish CDR events in a CouchDB

To set up CouchDB, clone the repository and follow the instructions on GitHub. If you use CouchDB, you can't use an API key to authenticate.

Set the following environment variables in your configuration to publish CDR events in an IBM Cloudant database. You can use both IBM Cloudant and another reporting service simultaneously by adding the IBM Cloudant configuration variables to your configuration.

The following examples show the configuration for publishing CDR events to CouchDB.

  • Single-tenant environment: Set the following environment variables in your configuration.
REPORTING_CDR_CLOUDANT_URL="http://<svc-couchdb>:5984/"
REPORTING_CDR_CLOUDANT_USERNAME=myCouchDBUsername
REPORTING_CDR_CLOUDANT_PASSWORD=myCouchDBPassword
REPORTING_CDR_CLOUDANT_DB_NAME=myCouchDB
REPORTING_CDR_CLOUDANT_EVENT_INDEX=cdr

  • Using multi-tenant JSON configuration: In the multi-tenant JSON configuration file, for each tenant where you want to enable call detail record events, configure a reporting object that contains the following properties. If you use non-default account configurations to IBM Cloudant, you might need to include additional environment variables. See cdrCloudant in Properties for the reporting object.
...
"reporting": {
  "convCloudant": {
    "url": "http://<svc-couchdb>:5984/",
    "username": "myCouchDBUsername",
    "password": "myCouchDBPassword",
    "dbName": "myCouchDB",
    "eventInd": "cdr"
  }
}
...

Call detail record event format

Call detail record events contain summary information about a single call. The event format is based on the Splunk HTTP Event Controller JSON format.

{
"time": 1434567892,
"host": "vgw123.ibm.com",
"source": "18595552498",
"sourcetype": "e164",
"index": "cdr",
"event": {
  "version": "1.0",
  "sipCallID": "b742193386876548a69fe1420c33998b@0.0.0.0",
  "globalSessionID": "b742193386876548a69fe1420c33998b@0.0.0.0",
  "initTime": 1520877996309,
  "startTime": 1520877998461,
  "stopTime": 1520878020781,
  "setupTime": 2152,
  "callLength": 22320,
  "sipToURI": "sip:+18445555174@169.46.147.46",
  "sipFromURI": "sip:+18595553171@vgwdemo.pstn.twilio.com",
  "maxSTTTransaction": 1212,
  "endReason": "failed",
  "failureDetails": "details on why call failed",
  "failureOccurred": true,
  "echoDetected": false,
  "transferTarget": "sip or tel URI",
  "conversations": [
    {
      "id": "1233",
      ...
    }
  ],
  "warnings": [
    {
      ...
    }
   ],
  "rtpNetworkSummary": {
     ...
  }
}
}

Event metadata

All reporting events begin with the following metadata:

Table 1. Keys for event metadata
Key Description
time The time of the event. The default format is epoch time, in the format ..
host Host name of the Voice Gateway instance that generated the event.
source Represents the Voice Gateway tenant that generated the event. Typically, this value is set to the phone number that was called.
sourcetype The source type. Use the REPORTING_CDR_EVENT_SOURCE_TYPE environment variable for a single-tenant deployment or cdrEventSourceType for multitenant deployment for configuring the source type. For more information, see Reporting event configuration.
index The index of the event as defined on the reporting event index configuration environment variables.
event A CDR event, a Watson Assistant turn event, or a transcription event.

Call detail record event object

The event JSON object for a call detail record event contains the following keys:

Table 2. Keys in call detail record event objects
Key Description
version Event format version.
sipCallID SIP Call ID pulled from the SIP INVITE related to the call.
globalSessionID The value of this key depends on how Voice Gateway is configured. By default, the value is identical to the sipCallID value. If the CUSTOM_SIP_SESSION_HEADER environment variable or customSIPSessionHeader JSON property is configured, it maps to that ID. If a session is a SIPREC session, the field is identical to the gcid field in the SIPREC metadata. If the session is a SIPREC session and the CUSTOM_SIPREC_SESSION_FIELD environment variable or customSIPRECSessionField JSON property is configured, it maps to that field.
customSIPInviteHeader The value of the custom SIP INVITE header. For this value to be set, the header field must be defined on the CUSTOM_SIP_INVITE_HEADER environment variable, and the INVITE request must contain the specified header. Version 1.0.0.4c and later.
customSIPInviteHeaders The value of the custom SIP INVITE headers. For this value to be set, the header fields must be defined on the CUSTOM_SIP_INVITE_HEADERS environment variable, and the INVITE request must contain the specified headers. Version 1.0.1 and later.
initTime Time when the initial SIP INVITE request was received to initiate the call, in date/time UTC format. Version 1.0.0.5 and later.
startTime Time when the call started in milliseconds after epoch.
stopTime Time when the call stopped in milliseconds after epoch.
setupTime Time it took to set up the call in milliseconds. Specifically, the key shows the time between when the initial SIP INVITE request was received and when the final SIP ACK request was received.
callLength Length of the call in milliseconds.
sipFromURI SIP URI from the initial SIP INVITE From field.
sipToURI SIP URI from the initial SIP INVITE To field.
endReason One of the following reasons that the conversation ended:
  • Transfer initiated from Watson Assistant: convTransfer
  • Hangup initiated from Watson Assistant: convHangup
  • Caller hangs up: callerHangup
  • Call fails: failed
failureDetails Details about the failure that caused the call to disconnect. Only included if the endReason key is set to failed.
failureOccurred Indicates whether any error, warning, or other failure occurred during the call, regardless of whether the call continued or was disconnected or transferred. The value can be true or false. Version 1.0.0.4 and later.
transferTarget The SIP or tel URI that is associated with the destination of the call transfer. Only included if the call is transferred or fails.
echoDetected Indicates whether an echo was detected during the call. The value can be true or false. Version 1.0.0.4c and later.
numberOfBargeins A count of all the barge-ins that occurred during the call.
conversations Array of conversations that were used within the call. See Watson Assistant details. V1.0.0.1c and later.
warnings Array of certain warnings that were logged during the call. See Warning details. V1.0.0.5 and later.
rtpNetworkSummary A summary of RTP data delivery statistics from the call. Included only if RTCP is enabled. See RTP network summary details. V1.0.0.5 and later.
sttProvidersUsed If configured for multiple service providers, an array that lists the names of the Speech to Text service providers used during the call, in the order that they were used. V1.0.0.6 and later.
conversationProvidersUsed If configured for multiple service providers, an array that lists the names of the Watson Assistant service providers used during the call, in the order that they were used. V1.0.0.6 and later.
ttsProvidersUsed If configured for multiple service providers, an array that lists the names of the Text to Speech service providers used during the call, in the order that they were used. If only the text to speech cache was used, this field might be returned as empty. V1.0.0.6 and later.
maxConvTransaction Maximum round-trip latency in milliseconds, calculated from all Watson Assistant requests related to the call.
maxTTSTransaction Maximum time in milliseconds between when a text utterance is sent to the Text to Speech service and when Voice Gateway receives the first packet of synthesized audio. Calculated from all Text to Speech requests related to this call.
maxSTTTransaction Maximum latency in milliseconds between when silence is detected in the user's speech and a final result from Speech to Text is received. This value is calculated from all the Speech to Text recognition results related to this call. Version 1.0.0.8 and later.
outboundcall Indicates whether the call is an outbound call. The value can be true or false. Version 1.0.2.0 and later.

Watson Assistant details

The conversations object contains all of the Watson Assistant sessions that were used during the call.

{
"time": 1434567892,
"host": "vgw123.ibm.com",
"source": "18885553333",
"sourcetype": "e164",
"index": "cdr",
"event": {
  "version": "1.0",
  "sipCallID": "b742193386876548a69fe1420c33998b@0.0.0.0",
  "globalSessionID": "b742193386876548a69fe1420c33998b@0.0.0.0",
  "initTime": 1520877996309,
  "startTime": 1520877998461,
  "stopTime": 1520878020781,
  "setupTime": 2152,
  "callLength": 22320,
  "sipToURI": "sip:+18445555174@169.46.147.46",
  "sipFromURI": "sip:+18595553171@vgwdemo.pstn.twilio.com",
  "numberOfBargeins": 0,
  "maxConvTransaction": 1447,
  "maxTTSTransaction": 616,
  "endReason": "failed",
  "failureDetails": "details on why call failed",
  "failureOccurred": true,
  "echoDetected": false,
  "transferTarget": "sip or tel URI",
  "customCDRData" :  {
    "key1": "value1",
    "key2": "value2"
  },
  "conversations": [
    {
      "id": "1233",
      ...
    }
  ],
  "warnings": [
    {
      ...
    }
   ],
  "rtpNetworkSummary": {
     ...
  }
}
}

The JSON object for each conversation that was used in the call contains the following keys:

Table 3. Keys for conversation details
Key Description
id The Watson Assistant ID, which is a generated conversation identifier number.
workspaceID The workspace ID of the Watson Assistant dialog that was used.
assistantID Watson Assistant ID. The assistant ID used only by the Watson Assistant version 2 API. Version 1.0.1 and later.
startTime Time when the conversation started in milliseconds after epoch.
stopTime Time when the conversation stopped in milliseconds after epoch.
maxConvTransaction Maximum round-trip latency in milliseconds, calculated from all Watson Assistant requests related to this conversation.
maxTTSTransaction Maximum time in milliseconds between when a text utterance is sent to the Text to Speech service and when Voice Gateway receives the first packet of synthesized audio. Calculated from all Text to Speech requests related to this conversation.
numberOfBargeins A count of all the barge-ins that occurred during the conversation.
numberOfTurns The total number of Watson Assistant transactions that took place during the conversation.
Limitation: The value does not include the initial Watson Assistant turn, so the total count is one less than the actual total.
numberOfTTSTransactions The total number of Text to Speech transactions. Version 1.0.0.3 and later.
numberOfCachedTTSEntries The total number of utterances that were played from the Text to Speech cache. Version 1.0.0.3 and later.
lastIntent The last intent that was handled during the conversation.
allIntents An array of all of the unique intent strings that were handled during the conversation.
customCDRData A list of custom keys and values. Version 1.0.0.8 and later.

Warning details

The warnings object contains warnings that were logged during the call, listed in order of occurrence. Warnings for the following conditions are included:

  • Messages when utterances are filtered out by the confidence score threshold
  • Text to Speech underflows, which is when text-to-speech synthesis can't keep up with the Voice Gateway streaming rate and audio might skip
  • RTP network warnings, such as high packet loss or high average jitter, if RTCP is enabled
"warnings": [
 {
   "timestamp": "2018-02-08T13:03:01Z",
   "message": "CWSMR0032W: A Watson Speech to Text final utterance has a confidence score of 0.1, which does not meet the confidence score threshold of 0.2. The utterance will be ignored.",
   "id": "CWSMR0032W"
 },
 {
   "timestamp": "2018-02-08T13:10:01Z",
   "message": "CWSMR0031W: The synthesis stream from the Watson Text To Speech service can't keep up with the playback rate to the caller, so audio might skip. transaction ID=a1b2c3d4e5",
   "id": "CWSMR0031W"
 }
]

The object for each warning contains the following keys:

Table 4. Keys for network warning details
Key Description
timestamp The date and time when the warning was generated. Version 1.0.0.5 and later.
message The text of the warning message that was logged. Version 1.0.0.5 and later.
id The unique message identifier. For a list of messages, see Voice Gateway system messages. Version 1.0.0.5 and later.

RTP network summary details

When RTCP is enabled, each rtpNetworkSummary object provides statistics for the inbound stream in the inboundStream object and statistics for the outbound stream in the outboundStream object.

"rtpNetworkSummary": {
  "inboundStream": {
      "maxJitter": 5,
      "averageJitter": 1,
      "packetsLost": 0,
      "totalPackets": 1000,
      "canonicalName": "user@example.com",
      "toolName": "User SIP Phone"
   },
  "outboundStream": {
      "maxJitter": 5,
      "averageJitter": 1,
      "packetsLost": 0,
      "totalPackets": 2000,
      "canonicalName": "voice.gateway@127.0.0.1",
      "toolName": "IBM Voice Gateway/1.0.0.5"
   }
}

The objects for each stream contain the following keys:

Table 5. Keys for RTP network summary details
Key Description
maxJitter Maximum jitter during the call. Version 1.0.0.5 and later.
averageJitter Average jitter, calculated over the call duration. Version 1.0.0.5 and later.
packetsLost An estimate of the number of packets that were lost during the call. Version 1.0.0.5 and later.
totalPackets An estimate of the total number of packets that were transmitted during the call. Version 1.0.0.5 and later.
canonicalName A unique identifier for the sender of the stream, typically in @ format. Version 1.0.0.5 and later.
toolName The name of the application or tool where the stream originated. For Voice Gateway, the default is "IBM Voice Gateway/ ". Version 1.0.0.5 and later.

Injecting custom values into call detail record events

By including the vgwActAddCustomCDRData to your Watson Assistant dialog or SOE, you can add custom data to your Call Detail Records. You can record data related to various activities that are happening during a call. This includes ways to identify completion of specific tasks.

{
  "command": "vgwActAddCustomCDRData",
  "parameters": {
    "key1": "value1",
    "key2": "value2"
  }
}

When generating a CDR report, the custom data is included in the customCDRData field. For example, in the following CDR report, the key1 and key2 are added to the customCDRData field.

{
"time": 1434567892,
"host": "vgw123.ibm.com",
"source": "18881112222",
"sourcetype": "e164",
"index": "cdr",
"event": {
  ...
  "customCDRData" :  {
    "key1": "value1",
    "key2": "value2"
  },
  "conversations": [
    {
      "id": "1234",
      ...
    }
  ]
}
}

Merging CDR data

During a call, if the vgwActAddCustomCDRData action is activated multiple times, the data is merged in the customCDRData field.

In the first call, values for key1 and key2 are defined.

{
  "command": "vgwActAddCustomCDRData",
  "parameters": {
    "key1": "value1",
    "key2": "value2"
  }
}

In the second call, values for key1 and key3 are defined.

{
  "command": "vgwActAddCustomCDRData",
  "parameters": {
    "key1": "value11",
    "key3": "value3"
  }
}

After these calls, the following code example shows how the custom CDR data is merged in the customCDRData field, where the value for key1, value11, is from the second call.

{
"time": 1434567892,
"host": "vgw123.ibm.com",
"source": "18595552498",
"sourcetype": "e164",
"index": "cdr",
"event": {
  ...
  "customCDRData" :  {
    "key1": "value11",
    "key2": "value2",
    "key3": "value3"
  },
  "conversations": [
    {
      "id": "1233",
      ...
    }
  ]
}
}

Removing custom CDR data

To remove CDR custom data, the SOE issues the vgwActAddCustomCDRData action with that key set to "".

The following example shows that to remove the key1 field from the custom CDR data, you would overwrite the key1 value with a blank, ""

{
  "command": "vgwActAddCustomCDRData",
  "parameters": {
    "key1": ""
  }
}

Calculating monthly minutes

If you need to calculate monthly usage in minutes, follow these steps:

  1. In the repository where you store CDRs, use a query to dump the CDRs for a given month.

  2. Calculate the sum of the values in the callLength field.

  3. Divide the sum by 60,000.