Call Detail Record (CDR) analysis
Managing Monitoring StarLeafLast updated October 16, 2020
You can view CDRs from the Call detail records page in your Admin Portal.
To download all CDRs from the past 30 days as a CSV file, click Download all CDRs.
On this page:
The unique ID that StarLeaf assigns to each call sequence. Examples of a sequence include all the legs of a scheduled or ad hoc meeting, an initial call and transfer leg, or a fallback to videomail.
Shows the Sequence ID and the unique identifiers of call legs in a point-to-point call or meeting. The Record ID is required by Technical Support to identify a specific call leg.
|initial||A point-to-point call, or the point-to-point call before an ad hoc meeting.|
|consultation||The consultation before forwarding a call, or before adding someone to a meeting.|
|ad hoc participant||A user added to a meeting ad hoc, after an initial point-to-point call.|
|scheduled participant||A user dialing in to a meeting that has been scheduled through the Portal.|
|transferred||The point-to-point call after a transfer has taken place. This is always seen after a CONSULT entry.|
|refer and referred||refer is when a Skype for Business endpoint asks a StarLeaf registered endpoint to join a Skype for Business meeting. referred is the resulting call|
|Answered successfully||The connected to the remote endpoint was established successfully.|
|Not answered||The remote endpoint rung, but was not answered. |
|Not connected||The call was not connected.|
|Answered, but terminated before media negotiation completed||The call connected, but no media was ever established.|
|Moved into meeting||The user dialed into the meeting, and the meeting was active, so they were moved into it successfully. One of these legs appears for each user who successfully joins a StarLeaf scheduled meeting.|
|Ended whilst in waiting room||The user dialed into a meeting, but hung up before any other user joined. The meeting only starts once either the host, or a second participant joins (depending on meeting settings in the StarLeaf Portal).|
|Notified||The callee has StarLeaf app for iPad logged in, but did not answer the call. Their iPad now has a missed call notification.|
|Rejected||The callee pressed the ‘reject’ or ‘send to mailbox’ button on the StarLeaf user interface.|
|Normal completion||The call disconnected after a successful connection.|
|Disconnected||The call ended due to a disconnection. This may have been due to a loss of network connection.|
|No answer||The remote endpoint did not answer the call while it was ringing.|
|Unavailable||The remote endpoint was unavailable. It may not exist, or may be offline.|
|Busy||The remote endpoint returned a busy response. It may have been in another call.|
|Denied||The remote endpoint denied the call. This can only occur if the remote endpoint is a legacy system or PSTN provider.|
|Media error||There was a failure to negotiate appropriate media streams for the call, or a media processing failure in the StarLeaf platform.|
|RMT media error||There was a media negotiation error at one of the endpoints. For example a StarLeaf app client may not have a microphone plugged in.|
|Rejected||The call was rejected by the far end. This may be due to the ‘Ignore call’ button being pressed.|
All StarLeaf calls are encrypted, but sometimes this is not shown in the CDRs.
If a call is unsuccessful, then the encryption status is shown as N/A, because calls that are not connected cannot be encrypted:
If a call is answered, but then immediately disconnected (for example, due to a network outage or client crash), the CDRs may be missing details of the call, and therefore could display the encryption status as unencrypted.