Billing systems and debugging tools want the same data on different schedules. Most platforms give them separate copies. On Bird one record serves both, and it is readable as soon as the call ends. That changes two things about reconciling against it: what counts as a leg, and when the cost arrives.
What is in a record?
A record carries three groups of fields, answering three different questions.
What happened. The status is the outcome, one of answered, no answer, rejected, failed or unknown. Alongside it, the SIP response is the final SIP code. Where Bird refused the call rather than a carrier, a rejection reason names the check it failed. Those three read together are the diagnosis, and what SIP response codes mean covers how they combine.
When it happened. Started is when Bird received the call. Answered is when it was picked up, or the fact that it was not. Ended is when it was torn down. On an incoming call, Inbound route records what the number that was dialed was set to do, and Trunk names the trunk the call came in on or was delivered to.
What it cost. Billable time, total duration and the call's cost.
Two identifiers sit alongside those, and they are not interchangeable. The call ID (vcl_…) is the record's own identifier. Quote it to support, and correlate against it in your own logs. The session ID (vcs_…) is shared by every leg of one call.
Why does one call show up as two records?
Because a record describes a leg rather than a call, and some calls have more than one.
A forwarded call is one: the inbound leg and the outbound leg are separate records, sharing one session ID. If you count records as calls, you will overcount exactly the calls that were forwarded, and if you sum durations across records you will double-count the time they overlapped.
The session ID is the fix. Group by it when you want calls, and read the records individually when you want legs. Which you want depends on the question: a delivery problem is a leg question, and a customer-experience or volume question is usually a session one.
Why does my cost not match the duration?
Billable time excludes the ringing. The cost is written after the call ends rather than with it.
Billable time is not total duration. Billable time runs from answer to hangup. Total duration includes the time the call spent ringing before anyone picked up. A record carries both. A reconciliation that quietly uses the wrong one drifts by the length of the ringing on every answered call, and by the whole duration on every call that was never answered.
The cost arrives after the call does. A record carries its cost once it has been rated, which is not the instant the call ends. A record fetched immediately can be complete in every other respect and carry no price. If you are computing spend in near real time, read the cost when it is there and never read its absence as zero. That is not a nicety: an absent cost and a cost of zero are different facts here, and treating them alike understates spend.
Waiting is not always the answer, though. An unanswered call has no cost and never will. An answered call that stays without one is not waiting for rating either. The record does not say which of the two you are looking at. Contact support with the call ID rather than continuing to poll it.
Which calls never appear?
A call Bird refuses before it admits it leaves no record, so the log is not a complete account of what reached your account.
A call Bird cannot admit at all is turned away before a record exists, so it never reaches the log. The trunk's IP allow list is one such refusal. A call from an address that is not on it is refused at the SIP layer, and usually produces no record. So an attacker probing your trunk can generate a great deal of traffic that leaves no trace in the place you would naturally go looking. A misconfigured PBX, the business phone system that routes a company's calls, does the same from a new address.
The practical consequence is that "there is nothing in the call log" answers a narrower question than it appears to. It means no call was admitted, not that nothing was attempted. When a phone system reports that its calls are failing and the log is empty, check the allow list first rather than last. Voice troubleshooting covers the rest of that path.
How do I get the records out?
For one call, open it in the call log and read the fields above. The log filters and searches over the list, and shows calls in progress separately from finished ones.
For many, the voice API returns calls as records you can page through. The voice statistics endpoints aggregate them by day, hour, country and response code. A question about a pattern is answered from the statistics rather than by paging the records.
The call log documents every field a record carries and how the list is filtered.
W skrócie
One call can be several records.
Each leg gets its own record, and a shared session id is what groups them. A forwarded call is two records, not one.
Billable time is answer to hangup.
It is not the total duration, which includes the ringing. Both are recorded, so reconcile against the right one.
The cost is not there at first, and sometimes never.
A record carries its cost once it has been rated. An answered call still without one is not waiting for rating, so take the call ID to support.
Some calls never produce a record at all.
A call refused before Bird admits it leaves nothing in the log, so the log is not a complete account of what reached your account.