Skip to content

Call object attributes

Calls are represented as JSON objects, with the following keys:

call_id (UUID)

Unique ID, assigned by MiaRec application to this call record.

parent_call_id (UUID)

This field has value only for some voip protocols.

For Avaya H.323 Passive recording, when call is put on hold and then resumed, a 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

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: A call direction is not provided by phone system, or not supported for this phone system (Unknown),
  • 1: Outbound
  • 2: Inbound
call_state (integer)

A state of the call.

Possible values:

  • 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 completio
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, Unrecognized 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 of objects Participant)

A list of call participants. See Participant object attributes for details.

Normally, there are only two participants of each call.

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

files (list of objects File)

A list of audio files. See File object attributes for details.

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.