Skip to content

Call object fields

Calls are represented as JSON objects, which have the following keys:

Field Type Description
call_id UUID Unique call id
parent_call_id UUID

This field is present only for some voip protocols.

For Avaya H.323 Passive recording, when call is put on hold and then resumed, the new call recording instance is created. This new instance links to the original call via parent_call_id field.
interaction_id UUID ID of interaction if this call is a part of multi-call interaction.
tenant_id UUID ID of tenant, which this calls is associated to
is_conference boolean If true, then this cal is a conference with more than 2 participants
recorder_id UUID Unique ID of the server, which recorded this call. In multi-site recording setup, this field allows to distinguish calls between locations
protocol_call_id string

Unique call id as provided by phone system.

For example, for SIP protocol this field is a "Call-Id" header in SIP INVITE message.
protocol_call_direction integer

Call direction as provided by phone system. Possible values:

0 - UNKNOWN - A call direction is not provided by phone system, or not supported for this phone system
1 - OUTBOUND
2 - INBOUND
call_state integer

all state:

  • 1 - INITIATED - The caller sent invitation to the callee (e.g. SIP INVITE is sent)
  • 2 - ACCEPTED - The callee received invitation and confirmed this (e.g. SIP Trying is sent)
  • 3 - ALERTING - The callee started ringing (e.g. SIP 183 Session Progress is sent)
  • 4 - CONNECTED - The call is answered (e.g. SIP 200 OK is sent)
  • 5 - DISCONNECTING - One of parties initiated call disconnect (e.g. SIP BYE is sent)
  • 6 - DISCONNECTED - The call is completed (e.g. SIP BYE is confirmed with 200 OK)
  • 7 - HOLD - The call has been put on hold. For some voip protocols this call state is a final state, meaning that call recording is completed when call is put on hold. When call is resumed, a new call instance is started. For others protocols this state is an intermediate state, meaning that it will switch to CONNECTED state when call is resumed from hold.
  • 8 - TRANSFERRED - The call has been transferred to third party. Note, for some voip protocols even if the call has been transferred, it's call state is stored as DISCONNECTED rather than TRANSFERRED. This occurs because on protocol level the reason of call disconnect is not provided by phone system.
on_demand_state integer

The state of on-demand recording:

  • 0 - DISABLED - On-demand triggers are not allowed for this call (e.g. call is configred as "always record")
  • 1 - KEEP_RECORDING - On-demand trigger was received and call will be kept
  • 2 - WAITING_TRIGGER - Waiting for on-demand trigger. If not received, then call will be deleted automatically upon completion
record_state integer

Recording state:

  • 10 - ACTIVE - Call is in process of normal recording
  • 20 - LICENSE_OVERUSAGE - Call is recorded, but it is not possible to playback it due to license over-usage. In this case, the audio file is encrypted. Contact vendor to decrypt such files. This state is valid for both active calls and diconnected.
  • 30 - FINISHED - Call recording is finished normally
  • 40 - IGNORED - Call is ignored by recording filters. Only call metada is stored in database. The audio file is not created for such calls
voip_protocol integer

Voip signaling protocol of the call:

  • 0 - UNKNOWN (not recognized protocol). Call is recorded from RTP packets only
  • 1 - SIP
  • 2 - H.323
  • 4 - SCCP (Cisco Skinny)
  • 5 - MGCP
  • 6 - Avaya (H.323 protocol with proprietary extensions)
  • 7 - Nortel UNISTIM
  • 8 - TAPI
  • 9 - MGCP PRI Backhaul (it is used between Cisco UCM and Voice Gateway)
  • 10 - Alcatel (proprietary protocol used by Alcatel OmniPCX - partially supported)
  • 11 - Avaya (passive RTP protocol)
  • 12 - Avaya TSAPI + passive RTP
  • 13 - SIPREC
  • 14 - Cisco Built-in-Bridge (active recording)
  • 15 - NEC SIP (proprietary protocol)
  • 16 - SIP ED137 radio (passive recording)
  • 17 - Cisco Built-in-Bridge (passive recording)
setup_time datetime

Date/time when call was initiated.

Format is ISO8601 with timezone, for example 2014-06-10T13:45:51+0800
connect_time datetime

Date/time when call was answered.

Format is ISO8601 with timezone.
disconnect_time datetime

Date/time when call was disconnected.

Format is ISO8601 with timezone.

from_ip

to_ip

 string

Ip-address of caller/called party.

Format is x.x.x.x, for example 192.168.0.10

from_port

to_port

 integer Ip port of caller/called party

from_mac

to_mac

 string

Mac-address of caller/called party.

Format is XX-XX-XX-XX-XX-XX

from_number

to_number

from_name

to_name

from_id

to_id

 string

Number/name/id of caller/called party.

This value is provided by phone system.

For SIP protocol these values are extracted from the "From" and "To" headers of SIP INVITE message.

Example of SIP INVITE mesage:

INVITE sip:102@192.168.0.10 SIP/2.0 From: "John Smith" <sip:100@192.168.0.10> To: "Emy" <sip:102@192.168.0.10>

In this case:

  • from_number = "100"
  • from_name = "John Smith"
  • from_id = "100@192.168.0.10"
  • to_number = "102"
  • to_name = "Emy"
  • to_id = "102@192.168.0.10"

Note, for SIP protocol, the values of these fields may be extracted from SIP headers "Remote-Party-ID" and "P-Asserted-Identity".

Example of SIP message:

INVITE sip:102@192.168.0.10 SIP/2.0 From: "John Smith" <sip:100@192.168.0.10> To: "Emy" <sip:102@192.168.0.10> Remote-Party-ID: "John" <sip:77@ex.com>;party=calling

In this case:

  • from_number = "77"
  • from_name = "John"
  • from_id = "77@ex.com"

transferred_from_number

transferred_from_name

transferred_from_id

 string

Number/name/id of phone, from which the call was transferred.

This value depends on voip signaling protocol.

For example, for Cisco Skinny protocol these fields are the same as "Last Redirecting Party Name/Number"

transferred_to_number

transferred_to_name

transferred_to_id

 string

Number/name/id of phone, to which the call was transferred.

This value depends on voip signaling protocol.

agent_id

agent_name

 string For Avaya TSAPI protocol these fields are id and name of agent.

broadworks_user_id

broadworks_group_id

broadworks_sp_id

 string Broadworks-specifid Ids for SIPREC protocol

metaswitch_user

metaswitch_group

metaswitch_system

 string Metaswitch-specifid Ids for SIPREC protocol

cisco_nearend_guid

cisco_farend_guid

 string Cisco near-end and far-end GUIDs for Cisco Built-in-Bridge recording

cisco_nearend_refci

cisco_farend_refci

 string Cisco near-end and far-end REFCI values for Cisco Built-in-Bridge recording
cisco_phone_ip string IP-address of Cisco phone for Cisco Built-in-Bridge recording

cisco_nearend_partition

cisco_farend_partition

 string Cisco near-end and far-end partition info for Cisco Built-in-Bridge recording
participants list

A list of call participants. See object Participant.

Normally, there are only two participants of each call.

But for a conference call it may be more than 2 participants.
files list

A list of audio files. See object File.

Normally, only one audio file exists per call instance.

But in some cases it may be multiple audio files per call:

  • When MiaRec is configured to detect log silence periods in a call, the recording is split on multiple audio files when silence is detected.
  • When there is license issue (not valid or not enough), then a part of call is encrypted. In this case, the call will have at least two audio files. First one will be relatively short (usually less than 15 seconds) and the second one will contain the remaing part of a conversation. The second file will be encrypted.

\