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
- Configuring Voice Gateway to publish CDR events in an IBM Cloudant database
- Configuring Voice Gateway to publish CDR events in a CouchDB
- Call detail record event format
- Injecting custom values into call detail record events
Configuring Voice Gateway to publish call detail record events
-
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.
-
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
andREPORTING_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. SeecdrCloudant
in Properties for thereporting
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. SeecdrCloudant
in Properties for thereporting
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:
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:
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:
|
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:
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:
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:
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 |
toolName |
The name of the application or tool where the stream originated. For Voice Gateway, the default is "IBM Voice Gateway/
|
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:
-
In the repository where you store CDRs, use a query to dump the CDRs for a given month.
-
Calculate the sum of the values in the
callLength
field. -
Divide the sum by 60,000.