CDRs Statistics
In the CDRs app, you can review call detail records.
Viewing overall call statistics
On the overall page, you can view the call statistics for the entire account for any date range or timezone that you choose. For example, you can view inbound reports for all numbers in your VoIP account. You can also download the results as a .csv file.
- Number of calls: includes all calls incoming, outgoing, internal transfers and so on.
- Inbound versus outbound: every interaction appears in the CDR; a call from a mobile into the queue displays initially as
INBOUND. After that it shows multipleOUTBOUNDinteractions because calls from the hosted pbx to agents show as OUTBOUND in the CDR. For more information on interpreting inbound versus outbound, see Interpreting call direction.
| IMPORTANT |
|---|
The call details report represents the timezone that is configured in your UI. However, the timestamp in the .csv file is expressed in UTC (Coordinated Universal Time). Depending on your timezone, there might be a difference between the call times that are displayed online and those that are in the downloaded file for the same call. You can figure out the time difference by offsetting UTC to your timezone and incorporating daylight savings as necessary. |
Viewing graphs
-
Click on Dashboard to view graphical representations of:
- Inbound vs Outbound Calls- percentage of calls that were inbound versus outbound
NOTE: "Inbound" indicates that the phone/carrier has initiated a call to the hosted PBX. "Outbound" indicates that the hosted PBX is sending a call invite to the phone/carrier.
- Hangup Causes - reasons for the call ending, see Hangup cause codes
- Call Statistics - averages across all calls
Viewing tables
-
Click on Call Logs to view the call logs in a table with the following data:
-
Direction - whether the call was inbound or outbound - for more information about interpreting direction see Interpreting call direction.
-
Date - date of the call
- From - number that initiated the call
- To - number that received the call
- Duration - number of minutes the call lasted
- Hangup Cause - reason the call was ended
- Actions - call related tasks (for example, listen to the call or email the call details to support)
-
Viewing per-user call statistics
On the per-user page, you can view the call statistics for a specific user for any date range or timezone that you choose. You can also download the results as a .csv file.
- Click on Per User.
- From the dropdown list of users, select the user whose call log you want to review.
- The Dashbboard and Logs display the same information as the overall CDR but on a per-user basis.
Interpreting call direction
Call direction is a CDR field that indicates where the call initiated. In a traditional phone network, PSTN -> phone is considered "inbound" and phone -> PSTN is "outbound".
However, in a hosted PBX system:
- Inbound - indicates that the PSTN (phone/carrier) is calling the hosted PBX (inbound to hosted PBX).
- Outbound - indicates that the hosted PBX is calling the PSTN (phone/carrier) (outbound from hosted PBX).
When calls involve two phones there are multiple call legs:
PHONE A -> hosted PBX -> PHONE B
- PHONE A -> hosted PBX - is the inbound call
- hosted PBX -> PHONE B - is the outbound leg
Therefore, the call_direction field of a CDR might not indicate the direction of the call as we typically understand it.
When call recording is configured, the "leg" being recorded includes the recording information in its CDR. If a leg is coming in from or going out to the PSTN, it includes a resource_type field which tells you if the call originated/terminated from within the network (internal) or externally (external). By fetching all legs involved (using the interaction_id), you can determine the direction of a call from the end user's perspective.
For example:
| Type | Call Direction (A leg) | Resource Type (A leg) | Call Direction (B leg) | Resource Type (B leg) | End User's Direction |
|---|---|---|---|---|---|
| A call comes in from the PSTN to a registered device on the hosted PBX. | inbound (from PSTN) | external-origination | outbound (from hosted PBX to the device) | undefined | inbound |
| A call goes from a registered device to the PSTN | inbound (from a device) | undefined | outbound (to the PSTN) | external-termination | outbound |
NOTE: The call legs between the hosted PBX and device do not have a resource type.
These scenarios can become complicated in the following examples:
- A call comes in from the PSTN and is then sent to a device with call-forwarding enabled (using PSTN). Both legs have
resource_typeset. - When a device calls another device, no
resource_typeexists on either leg. - When a call is transferred or parked/picked up (sometimes multiple times).
NOTE: The leg where call recording is started has
media_recording_idset (among others) in the leg's CDR under thecustom_channel_varsobject.
For more information about call recording specifically, see Call Recording.
Hangup cause codes
| Cause Code | Type | Description |
|---|---|---|
| 0 | UNSPECIFIED | This is usually given by the router when none of the other codes apply. This cause usually occurs in the same type of situations as cause 1, cause 88, and cause 100. |
| 1 | UNALLOCATED_NUMBER | This cause indicates that the called party cannot be reached because, although the called party number is in a valid format, it is not currently allocated (assigned). |
| 2 | NO_ROUTE_TRANSIT_NET | This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network, which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network, while it does exist, does not serve the equipment which is sending this cause. |
| 3 | NO_ROUTE_DESTINATION | This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network dependent basis. |
| 6 | CHANNEL_UNACCEPTABLE | This cause indicates that the channel most recently identified is not acceptable to the sending entity for use in this call. |
| 7 | CALL_AWARDED_DELIVERED | This cause indicates that the user has been awarded the incoming call, and that the incoming call is being connected to a channel already established to that user for similar calls (e.g. packet-mode x.25 virtual calls). |
| 16 | NORMAL_CLEARING | This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal situations, the source of this cause is not the network. |
| 17 | USER_BUSY | This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call. |
| 18 | NO_USER_RESPONSE | This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated. |
| 19 | NO_ANSWER | This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. Note - This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers. |
| 20 | SUBSCRIBER_ABSENT | This cause value is used when a mobile station has logged off, radio contact is not obtained with a mobile station or if a personal telecommunication user is temporarily not addressable at any user-network interface. Sofia SIP will normally raise USER_NOT_REGISTERED in such situations. |
| 21 | CALL_REJECTED | This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. The network may also generate this cause, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection. |
| 22 | NUMBER_CHANGED | This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned, The new called party number may optionally be included in the diagnostic field. If a network does not support this cause, cause no: 1, unallocated (unassigned) number shall be used. |
| 23 | REDIRECTION_TO_NEW_DESTINATION | This cause is used by a general ISUP protocol mechanism that can be invoked by an exchange that decides that the call should be set-up to a different called number. Such an exchange can invoke a redirection mechanism, by use of this cause value, to request a preceding exchange involved in the call to route the call to the new number. |
| 25 | EXCHANGE_ROUTING_ERROR | This cause indicates that the destination indicated by the user cannot be reached, because an intermediate exchange has released the call due to reaching a limit in executing the hop counter procedure. This cause is generated by an intermediate node, which when decrementing the hop counter value, gives the result 0. |
| 27 | DESTINATION_OUT_OF_ORDER | This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signal message was unable to be delivered to the remote party; e.g. a physical layer or data link layer failure at the remote party, or user equipment off-line. |
| 28 | INVALID_NUMBER_FORMAT | This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete. |
| 29 | FACILITY_REJECTED | This cause is returned when a supplementary service requested by the user cannot be provide by the network. |
| 30 | RESPONSE_TO_STATUS_ENQUIRY | This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS INQUIRY. |
| 31 | NORMAL_UNSPECIFIED | This cause is used to report a normal event only when no other cause in the normal class applies. |
| 34 | NORMAL_CIRCUIT_CONGESTION | This cause indicates that there is no appropriate circuit/channel presently available to handle the call. |
| 38 | NETWORK_OUT_OF_ORDER | This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time e.g. immediately re-attempting the call is not likely to be successful. |
| 41 | NORMAL_TEMPORARY_FAILURE | This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user may wish to try another call attempt almost immediately. |
| 42 | SWITCH_CONGESTION | This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic. |
| 43 | ACCESS_INFO_DISCARDED | This cause indicates that the network could not deliver access information to the remote user as requested, i.e. user-to-user information, low layer compatibility, high layer compatibility or sub-address as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic. |
| 44 | REQUESTED_CHAN_UNAVAIL | This cause is returned when the other side of the interface cannot provide the circuit or channel indicated by the requesting entity. |
| 45 | PRE_EMPTED | |
| 47 | This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies. | |
| 50 | FACILITY_NOT_SUBSCRIBED | This cause indicates that the user has requested a supplementary service, which is available, but the user is not authorized to use. |
| 52 | OUTGOING_CALL_BARRED | This cause indicates that although the calling party is a member of the CUG for the outgoing CUG call, outgoing calls are not allowed for this member of the CUG. |
| 54 | INCOMING_CALL_BARRED | This cause indicates that although the called party is a member of the CUG for the incoming CUG call, incoming calls are not allowed to this member of the CUG. |
| 57 | BEARERCAPABILITY_NOTAUTH | This cause indicates that the user has requested a bearer capability that is implemented by the equipment which generated this cause but the user is not authorized to use. |
| 58 | BEARERCAPABILITY_NOTAVAIL | This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time. |
| 63 | SERVICE_UNAVAILABLE | This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies. |
| 65 | BEARERCAPABILITY_NOTIMPL | This cause indicates that the equipment sending this cause does not support the bearer capability requested. |
| 66 | CHAN_NOT_IMPLEMENTED | This cause indicates that the equipment sending this cause does not support the channel type requested |
| 69 | ACILITY_NOT_IMPLEMENTED | This cause indicates that the equipment sending this cause does not support the requested supplementary services. |
| 79 | SERVICE_NOT_IMPLEMENTED | This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies. |
| 81 | INVALID_CALL_REFERENCE | This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface. |
| 88 | INCOMPATIBLE_DESTINATION | This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility or other compatibility attributes (e.g. data rate) which cannot be accommodated. |
| 95 | INVALID_MSG_UNSPECIFIED | This cause is used to report an invalid message event only when no other cause in the invalid message class applies. |
| 96 | MANDATORY_IE_MISSING | This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be processed. |
| 97 | MESSAGE_TYPE_NONEXIST | This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined of defined but not implemented by the equipment sending this cause. |
| 98 | WRONG_MESSAGE | This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state. |
| 99 | IE_NONEXIST | This cause indicates that the equipment sending this cause has received a message which includes information element(s)/parameter(s) not recognized because the information element(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the information element(s)/parameter(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message. |
| 100 | INVALID_IE_CONTENTS | This cause indicates that the equipment sending this cause has received and information element which it has implemented; however, one or more fields in the I.E. are coded in such a way which has not been implemented by the equipment sending this cause. |
| 101 | WRONG_CALL_STATE | This cause indicates that a message has been received which is incompatible with the call state. |
| 102 | RECOVERY_ON_TIMER_EXPIRE | This cause indicates that a procedure has been initiated by the expiration of a timer in association with error handling procedures. This is often associated with NAT problems. Ensure that "NAT Mapping Enable" is turned on in your ATA. If it is not NAT related it can sometimes be provider related, make sure to ensure another outbound provider does not solve the problem. This is also returned when the remote party sends a 408 for call expired. |
| 103 | MANDATORY_IE_LENGTH_ERROR | This cause indicates that the equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending this cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameter(s) were passed unchanged. |
| 111 | PROTOCOL_ERROR | This cause is used to report a protocol error event only when no other cause in the protocol error class applies. |
| 127 | INTERWORKING | This cause indicates that an interworking call (usually a call to SW56 service) has ended. |
| 487 | ORIGINATOR_CANCEL | |
| 500 | CRASH | |
| 501 | SYSTEM_SHUTDOWN | |
| 502 | LOSE_RACE | |
| 503 | MANAGER_REQUEST | This cause is used when you send an api command to make it hangup. For example uuid_kill |
| 600 | BLIND_TRANSFER | |
| 601 | ATTENDED_TRANSFER | |
| 602 | ALLOTTED_TIMEOUT | This cause means that the server canceled the call because the destination channel took too long to answer. |
| 603 | USER_CHALLENGE | |
| 604 | MEDIA_TIMEOUT | |
| 605 | PICKED_OFF | This cause means the call was picked up by intercepting it from another extension (i.e. dialing **ext_number from another extension). |
| 606 | USER_NOT_REGISTERED | This means you tried to originate a call to a SIP user who forgot to register. |
| 607 | PROGRESS_TIMEOUT | See: progress_timeout |
| 609 | GATEWAY_DOWN |
Frequently asked questions
Q: What does lose_race mean?
A: This means the call wasn't answered, if the call was answered it ends usually in normal_clearing.
Q: Why does my call sometimes show a different time duration and direction in Summary versus Interactions?
A: The interactions shows the total duration of the call to the number, sometimes there is an inbound virtual receptionist or a greeting that takes up some of the call, then it is might be directed to a ring group. In the sample below, you can see the original inbound call being split out to four different endpoints. The direction of these calls from hosted PBX to the phones are the outbound legs of the interaction. You can that three of the attempts weren't answered and one went through.
Q: What does anonymous mean when it is displayed in the "from" column?
A: This usually indicates an application, such as call center, sending a call to a device.
Q: Are the call logs in the Smart PBX different to the CDRs?
A: Both contain the same data presented differently.
Q: How do CDRs work for if a user is part of a group?
A: Each interaction is available for every call that reaches the user.
Q: What does No Route Destination mean?
A: This indicates either a non-existent number or, more likely, you are reaching a rate limit and the calls are being retried.