Finding out what happened to this call
You have one number and maybe a time. You need to know where the call died and whose fault it was. This is the single most common thing anyone asks Butler.
Somebody complained first. That is almost always how this starts, whether it came from an end user, a reseller or a colleague in another channel, and what reaches you is a single identifier: a dialled number, sometimes a time, occasionally nothing more than “just now”.
Answering it today means opening a trace tool, knowing which session border controller to look at, finding the call, reading a SIP ladder, and knowing what a 480 means in that context. Butler collapses all of that into a sentence typed into the chat window you already have open.
Pick a question, read the whole exchange
Both of these come from one afternoon, unedited, with identifiers masked. Read the second one for what Butler does when it does not have the data you asked for.
- The call was answered at 10:16:10 UTC
- Duration 87 seconds, with connected audio both ways
- Normal clearing by the calling party, and both legs report release_source ConnectedLeg, so the carrier side was up and connected when it ended
A carrier denied receiving a call and quoted a Call-ID to prove it. Butler found the call, then noticed the thing that settles the argument: the Call-ID they quoted belongs to the hop between two of our own SBCs, so they could not have seen it. It handed back the one they should be looking for, and confirmed the call answered and ran for 87 seconds. That is twenty minutes in a packet capture, and the output is a sentence you can send straight to the carrier.
- release_source on every outbound leg is LocalLeg with sip_final_response 503
- original_cause is 503_SERVICE_UNAVAIL(503)
- Your SBC sent the INVITE and the carrier returned 503 Service Unavailable
The first message is the one worth reading. Asked about “a call that failed with a 503 this morning”, Butler did not pick a call and hope. It asked for a number, a rough time and an SBC, then found it with a server-side filter on the response code rather than paging through rows. The answer names the evidence it used before it draws the conclusion, which is what makes the last line something you can actually forward.
- The 180 Ringing was sent by the terminating switch, not by the end user’s device
- The ringing in the ladder is signalling only, the far end indicating it was attempting to alert the destination
- The 486 came back 20 ms later, so the handset almost certainly never had time to physically ring
Both parties were right, which is why this argument was going nowhere. The network did attempt delivery and the phone did not ring, and twenty milliseconds is the whole explanation. Notice that Butler did not pick a side and defend it. It read what the signalling actually said, which turned out to be more precise than either party had been.
One number that means nothing, split into two that mean something. Of nearly three seconds to connect, 295 milliseconds was post-dial delay, which is routing and the destination’s own processing, and the other 2.9 seconds was the called party not picking up. The first is a platform question and the second is not, and conflating them is how an afternoon gets spent troubleshooting the wrong system.
The usual objection to putting an assistant in front of a support desk is that it will bury the team in detail. This is the counter-example. Underneath that answer it walked a chain of three hops and six legs, and then threw nearly all of it away: no response codes, no NAP names, no topology. Three plain sentences that the person who opened the ticket can actually read.
The engineer said the calls failed. The evidence said they did not, and Butler said so with the ladder to prove it. Notice also that nobody restated anything: by the third message the question is just “in Call 1”, and Butler still has both calls in hand. An answer worth trusting is one that will disagree with you.
The prompts, and where each one leads
Copy one, swap in your own numbers. The follow-ups matter more than the opener.
Someone complained and all you have is the number. No time, no direction, no SBC.
The call, the disconnect cause, and which leg raised it.
You are about to open a ticket with an upstream carrier and need it to be unarguable.
Ingress NAP, egress NAP, release source and the disconnect cause, which turns “the call failed” into “it left by this trunk and that carrier declined it”.
The status code is not the answer. You want the reason header text, verbatim.
The reason phrase, plus any Reason or Warning header carried with it, which is the part a dashboard cannot show you.
Audio complaint, and the SDP offer lists five codecs that tell you nothing.
The negotiated codec per leg, read from the leg records rather than the offer.
How to read what comes back
What happened to this call?
One number and maybe a time. Butler finds the call and says whose side ended it.
Counts, groupings, thresholds and KPIs across a population of calls.
Routing tables, regex and SDP profiles in plain English.
Ask in French, Spanish or Portuguese, get the answer from the English documentation.
Changes, reports, files and email, each one waiting for your yes.
Paste the complaint in the customer’s own words and let Butler find the call.
Ask Butler about your own failed call
Deployed in 48 hours, month to month, in the chat app your team already has open.
By submitting this form, your information will be processed in accordance with our Privacy Policy.