Voice circuit monitoring: SIP trunks, 0800 and IVR
A registered SIP trunk and a PBX with no alarms don't prove that a call connects with audio. This guide compares the ways to monitor a voice circuit, shows how to confirm an outage without false alarms and says what evidence to keep to hold the carrier accountable.
Summary
- Ping and SIP OPTIONS show that a device responds; only a real test call shows that a customer's call connects, with audio in both directions.
- Passive capture on the PBX only sees the calls that reach it: when the failure is upstream, at the carrier or on the 0800's route, it records nothing.
- At Monitor's default pace, each circuit gets a test call every 15 minutes; after a failure, three retries every 2 minutes, and four failures in a row open an incident.
- Two good calls in a row confirm the circuit's recovery; an isolated failure never becomes an incident.
- When the failure is in the monitoring itself, the test is marked monitoring blind: it doesn't count against the circuit and stays out of the SLA.
- The evidence for each failure is the SIP code, the Q.850 cause, the Call-ID and the exact time of each test call.
What is voice circuit monitoring?
Voice circuit monitoring is the continuous check that every SIP trunk, 0800 (toll-free) number, branch DID and IVR connects calls with audio in both directions and with the right message. A voice circuit, here, is any number or route through which a customer reaches your company by phone.
The definition matters because it changes what gets measured. Most of the tools in a telephony environment look at the equipment: whether the SBC is up, whether the trunk is registered, whether the PBX’s processor has headroom. Those questions are necessary, but they answer something else. A device can be in perfect shape while a customer’s call never reaches it.
This guide deals with the question the customer asks: if I call now, will someone answer? The guides on 0800 and IVR, silent calls, voice quality and SLA go deeper into each part.
Why does the dashboard stay green while the customer hears silence?
The dashboard stays green because it measures the equipment, not the call. The PBX is up, the SIP trunk shows as registered and the link responds, while the failure is on the carrier’s route, in the 0800 translation or on the audio path. None of those points sends an alarm to your team’s dashboard.
Three common situations show the problem:
- The call never arrives. The carrier stopped routing your 0800 or a DID to your trunk. The PBX receives nothing, so it has nothing to complain about.
- The call arrives, but the audio doesn’t. The SIP signaling gets through and the call is answered, but the RTP that carries the voice stops at a NAT, a firewall or a SIP ALG. The result is a silent call or one-way audio, and the PBX logs a completed call.
- The wrong message answers. The IVR was swapped, the holiday recording was left on or the carrier plays the number-does-not-exist announcement. As far as the signaling is concerned, everything worked.
There’s an aggravating factor: in the small hours and on weekends, few calls is normal. The customer who calls at 2:00 a.m. and hears silence gives up, and the failure only surfaces when support opens and the queues are strangely empty.
Ping, SIP OPTIONS, passive capture or a test call: what does each one see?
Each method of monitoring a SIP trunk answers a different question. Ping says whether an address responds; SIP OPTIONS and registration, whether the SIP stack responds; passive capture, how the calls that arrived went. Only a real test call says whether a customer’s call connects right now, with audio.
| Method | What it sees | What it doesn’t see | What it’s for |
|---|---|---|---|
| Ping | That the SBC’s or the PBX’s address responds on the network | The SIP service, the carrier’s route, the audio, the message; many SBCs don’t even answer ping | Knowing whether the device has dropped off the network |
| SIP OPTIONS and registration (keep-alive) | That the SIP stack on the other side responds and that the trunk’s registration is valid | Whether an INVITE to your number is routed to you, whether audio flows, who answers | Keeping the trunk and the NAT alive and noticing a lost registration |
| Passive monitoring (packet capture, RTCP statistics on the PBX) | SIP codes, loss and jitter of the real calls that reached the PBX | The calls that never arrived; nothing at all when there’s no traffic | Diagnosing quality and investigating a specific call |
| Real test call | Whether the call connects, the SIP code and Q.850 cause, who answered, audio in both directions and measured quality | Origins and numbers it doesn’t dial; what happens between two tests | Knowing whether customers can reach you, at any hour |
The methods complement each other: the test call tells you whether it’s working; the others help find out why it isn’t.
Ping
Ping is the cheapest test and the most limited. It confirms that an IP address responds, which helps you know whether an SBC or a link has disappeared. But a device that answers ping can have its SIP service stopped, and many SBCs drop ping on purpose, for security.
SIP OPTIONS and registration
The OPTIONS method, defined in RFC 3261, asks a SIP element what it supports. In practice, SBCs and carriers send OPTIONS at intervals to find out whether the other side is alive and, along with other techniques described in RFC 6314, to keep NAT mappings open. REGISTER, also from RFC 3261, is how the trunk tells the carrier where to deliver calls. See SIP registration.
A trunk that is registered and answering OPTIONS proves that signaling between the two devices works. It doesn’t prove three things: that the carrier routes a specific number to that trunk (an 0800’s translation happens somewhere else in the carrier’s network); that audio flows, since RTP travels on other ports and can be blocked while OPTIONS gets through; and that the right IVR is the one answering.
Passive monitoring on the PBX
Packet capture on the PBX or the SBC records the signaling and audio of real calls. RFC 3550’s RTCP reports carry the packet loss and jitter for each direction, and many devices use them to calculate an estimated MOS score with the ITU-T G.107 E-model, which ITU-T P.800.1 calls MOS-CQE. It’s the right tool for investigating why a specific call sounded bad.
The limit is structural: passive monitoring only sees what arrives. If the carrier stopped delivering the 0800’s calls, there is no packet to capture, and in the small hours, with no traffic, there is no data at all. A drop in call volume is no signal at 3:00 a.m. on a Sunday, when zero calls is what you’d expect.
Real test call
The test call dials the number from outside, the way a customer does, and judges the result. It crosses the carrier, the 0800 translation, the trunk, the SBC, the PBX and the IVR, and so it sees what the customer would see. It’s the only method that works the same at 3:00 a.m. as at 3:00 p.m., because it doesn’t depend on someone calling.
It has limits too. It tests from your origin and only the numbers it dials; a failure that affects only calls from mobile phones, for example, may not show up (see why an 0800 won’t connect from a mobile phone). It doesn’t see what happens between one test and the next. And it holds a channel for a few seconds, like a customer call.
What does a test call need to check?
A test call needs to check four things, in order: whether the call connected, whether whoever should answer did, whether audio flowed in both directions and whether the voice arrived with good quality. A test that only checks the first one lets through the silent 0800, the swapped IVR and the carrier’s announcement.
Did the call connect?
The route’s response to an INVITE says what happened. 1xx responses indicate progress, 200 OK indicates an answer, and 4xx, 5xx and 6xx responses indicate failure. The ones a test runs into most often:
| SIP response | What it usually means | For monitoring |
|---|---|---|
| 180 Ringing | The destination is ringing | Progress, not yet an answer |
| 183 Session Progress | Progress with audio before the answer, early media (RFC 3960) | Could be ringback or a carrier announcement; not an answer |
| 403 Forbidden | The route rejected the call | Failure |
| 404 Not Found | The number doesn’t exist for this route | Failure |
| 408 Request Timeout | No final response in time | Failure |
| 480 Temporarily Unavailable | The destination is unavailable right now | Failure |
| 486 Busy Here | Busy | Failure for an IVR, which should answer every call |
| 487 Request Terminated | The call was canceled before it was answered | When the test gave up waiting, it’s an answer failure |
| 488 Not Acceptable Here | The media offer, such as the codecs, was not accepted (RFC 3264) | Failure |
| 503 Service Unavailable | The service on the other side is unavailable | Failure |
| 603 Decline | The destination declined the call | Failure |
Along with the SIP code, many routes send the telephone network’s Q.850 cause in the Reason header, as RFC 6432 describes. The list of SIP codes, the list of Q.850 causes and the SIP code lookup explain each one.
Did the right party answer?
“Answered” isn’t enough. An 0800 can connect and play the carrier’s recording saying the number doesn’t exist; an IVR can be swapped without notice. That’s why each circuit needs a definition of what should answer, and the test needs to check it.
In Monitor, that choice is made during setup and decides what counts as working:
- A greeting or recorded message, the IVR: passes when the call is answered and the expected greeting is heard. 2N5 records each number’s reference greeting, and each call compares what it heard with it. A carrier’s error announcement doesn’t pass.
- A test tone or echo service: passes when the call is answered and the tones sent come back.
- Other: may ring until timeout or be answered with audio, as agreed. If a person answers, they hear a message saying it’s an automated test.
For an IVR, busy, no answer or ringing until timeout is a failure: it answers every call on its own.
Did audio flow in both directions?
A call can be answered and stay silent, or carry voice in one direction only. SIP signaling and audio take different paths: SIP agrees on the addresses and ports, and RTP carries the voice. A NAT that rewrites only one of the two, a SIP ALG that alters the message or a firewall that blocks the media ports produce a silent call, while the PBX logs a completed call. On a circuit with a test tone or echo, the test checks that the tones sent come back. The guide silent calls and one-way audio covers the causes in detail.
Did the voice arrive with good quality?
A call can connect and sound choppy. Monitor measures listening quality from the audio the call received, compared with the reference recording, using the ViSQOL model in speech mode, and gives a score from 1 to 5: MOS-LQO, in ITU-T P.800.1 terminology. That’s different from the MOS-CQE a PBX estimates from network figures with the G.107 E-model: one measures what arrived, the other calculates what should have arrived.
By default, a circuit is healthy with MOS-LQO from 3.8 up, and a score below 3.0 marks the call as degraded. A degraded call goes through the same retries as any failure. See measured voice quality and the MOS-LQO and ViSQOL guide.
How do I confirm an outage without false alarms?
A voice circuit outage is confirmed by repeating the call before alerting anyone. An isolated failure can be a route that blipped once; four failures in a row, a few minutes apart, are an outage. The same logic applies to recovery: one good call isn’t enough, two in a row confirm it.
At Monitor’s default pace, each circuit gets a test call every 15 minutes. When one fails, the call is repeated three times, every 2 minutes; four failures in a row open an incident, and two good calls in a row confirm recovery. As a timeline, with T as the time of the first failed test:
| Moment | Call | Result | What happens |
|---|---|---|---|
| T − 15 min | Scheduled test | Connects, the IVR answers | Circuit healthy |
| T | Scheduled test | SIP 503 | First failure; retry in 2 minutes; nobody is alerted |
| T + 2 min | Retry | SIP 503 | Second failure in a row; retry in 2 minutes |
| T + 4 min | Retry | SIP 503 | Third failure in a row; retry in 2 minutes |
| T + 6 min | Retry | SIP 503 | Fourth failure in a row: incident opened, with the evidence; tier 1 is alerted by email and SMS |
| After that | Following calls | Fail | The incident stays open; if nobody acknowledges in time, the alert climbs to the next tier |
| On recovery | Call | Connects, the IVR answers | First good call; the incident doesn’t close yet |
| Right after | Next call | Connects, the IVR answers | Second good call in a row: recovery confirmed, incident closed, contacts notified |
If the T + 2 min call connects, the sequence stops there: there was an isolated failure, nobody was woken up and nothing goes into the SLA. That filter is what lets you trust an alert at 2:00 a.m.
How long does it take for an outage to become an alert?
It depends on when the outage starts relative to the test. In the worst case, it starts right after a good test: it takes up to 15 minutes for the next test to see the failure and another 6 minutes for the three retries to confirm it, so 15 + 6 = 21 minutes to the incident. In the best case, it starts just before a test and becomes an incident in about 6 minutes.
Testing more often shortens that time, but each test holds a channel for a few seconds. The math at the default frequency: 24 hours × 4 tests per hour = 96 test calls a day, per circuit, not counting retries.
Why four failures and two good calls?
Four failures in a row, within 6 minutes, separate a blip from an outage without delaying the alert too much. Two good calls in a row prevent the flapping of an unstable circuit, which would otherwise close and reopen the incident on every test. These are Monitor’s default values.
When does the monitoring itself go blind?
Monitoring goes blind when the test can’t run because of a problem on the tester’s side: the call server not responding, the originating account down, the monitoring’s own network out. In that case the test says nothing about the voice circuit, and can’t count as an outage of it.
Counting blindness as an outage does three kinds of damage. The team gets woken at 2:00 a.m. for a problem that isn’t theirs. The circuit’s SLA comes out worse than it really was. And disputes with the carrier get weaker, because all the carrier has to do is show its side was normal at that hour to cast doubt on the other recorded outages. Blindness can’t count as uptime either: if nobody could test, nobody knows what state the circuit was in.
In Monitor, when the failure is on 2N5’s side, for example 2N5’s call server not responding, the test is marked as no visibility:
- it doesn’t count against the circuit and doesn’t open an incident for the customer;
- it stays out of the SLA: the period comes out of the calculation and is shown separately in the report;
- it doesn’t wake the customer’s team; 2N5 is alerted if it lasts more than 30 minutes;
- a periodic heartbeat also alerts 2N5 if the monitoring stops running.
Anyone building their own monitoring needs the same separation. A practical approach is a control destination, a number that should always connect, tested from the same origin. If the circuit and the control fail together, the problem is probably at the test’s origin, not in the circuit.
What evidence should I keep for each failure?
For every failed test call, keep the SIP response code, the Q.850 cause when one is sent, the Call-ID, the exact time with time zone, the number called and the origin. With that, the carrier can find the call in its own records, and “no fault found” becomes hard to sustain.
| Evidence | Where it comes from | Why it matters |
|---|---|---|
| SIP code | The response’s status line (RFC 3261), for example 503 | Says where and how the call was rejected |
| Q.850 cause | The Reason header, when the route sends it (RFC 6432), for example Reason: Q.850;cause=34 |
Carries the telephone network’s cause behind the SIP |
| Call-ID | The call’s Call-ID header (RFC 3261) | Identifies the call in the carrier’s records |
| Time | The tester’s clock, with seconds and time zone | Cross-checks with the carrier’s records and marks the start and end of the outage |
| Number called and origin | The test itself | A failure may apply only to one origin or one number |
| Last healthy call | The test history | Bounds when the outage began |
| What was heard | The call recording, when the IVR or the recording answered | Proves the wrong message or the carrier’s announcement |
Keep the SIP code and the Q.850 cause together, call by call: the same 503 response can come with different causes, and each one points somewhere else.
In Monitor, each incident carries a block ready to paste into the carrier ticket: the circuit, the carrier, the first symptom, the SIP code and Q.850 cause of each call, and the last healthy call. An example, with demo data: SIP 503 Service Unavailable, Q.850 cause 34 (no circuit/channel available), confirmed after 4 failed calls. Audio is kept only when what answers is the recording or the IVR on file, encrypted and deleted after 90 days; a person’s voice is never kept.
What to monitor: SIP trunks, 0800s, branch DIDs or the IVR?
Monitor what the customer dials first, then each path those calls take. In general, that means the support numbers, such as 0800 and 4004, the IVR that answers them, one DID per SIP trunk and per carrier, and one DID at each branch. Each one becomes a voice circuit with its own schedule.
| What | What to dial | What should answer | What the test shows |
|---|---|---|---|
| Support number (0800, 0300, 4004) | The number itself, as the customer dials it | The IVR’s greeting | The carrier’s route, number portability, the IVR platform |
| IVR | The number that lands on it | The greeting recorded as the reference | A swapped message, the platform being down, quality |
| SIP trunk | A DID that comes in through that trunk | A test tone, an echo or a greeting | Carrier rejection, full channels, one-way audio |
| Branch DID | A number at the branch | Tone, echo, greeting, or an extension that may ring | That branch’s trunk, link and PBX |
| Support queue | The queue’s number | The greeting, or it may ring | Whether the queue receives calls |
One trunk, one DID
If you have two SIP trunks from different carriers for redundancy, test each one with a DID that comes in only through it. Testing only the main number hides the first trunk’s outage while the second one carries the calls, and you only find out when both go down together. Redundancy only counts if every path is tested.
Support numbers and the IVR
The support number carries the most weight, because it’s the one customers know. Test the 0800 itself, not just the DID it translates to: the translation lives at the carrier, and that’s where many failures happen. The guide Your 0800 went down and nobody told you covers that case in detail, and the 0800 and IVR monitoring page shows how Monitor judges each number. For branches, one DID per branch, with an extension or a test tone behind it, covers each branch’s trunk, link and PBX; see SIP trunk monitoring.
How often should a voice circuit be tested?
The test frequency sets the resolution of a voice circuit’s SLA. With one call every 15 minutes and retries every 2 minutes after a failure, the start and end of every outage are pinned down to within a few minutes. Testing once an hour can miss entire 40-minute outages.
The math starts from the target. A 99.9% target in a 30-day month allows 43,200 minutes × 0.001 = 43.2 minutes of downtime. If the test runs every 60 minutes, a 40-minute outage can start and end between two tests and never make it into the report: the SLA comes out better than it really was. For the target to mean anything, the interval between tests has to be much shorter than the time it allows. The SLA calculator does the math for any target and period.
Two other decisions weigh as much as the interval:
- The hours when nobody is watching. A 24-hour 0800 needs testing overnight and on weekends, because that’s when nobody on the team will notice on their own. In Monitor, each number has its own schedule, at intervals or at fixed times, including nights and weekends.
- The call limit. Each test holds a channel for a few seconds. With many circuits behind the same trunk, testing has to fit within a call limit so it never competes with customers for a channel.
What about the internet link the voice runs over?
The internet link is the data circuit that voice almost always runs over, and an outage there takes down every voice circuit at the site at once. Measuring the link alongside the test calls answers the first question of every voice outage: was it the line or the connection?
In Monitor, an agent that 2N5 installs at the site measures latency, packet loss, jitter, DNS time and speed. Each voice circuit can be linked to its site’s link; with the wait-for-the-link option, the team gets one alert about the link, not one per voice circuit that runs over it. See data circuits.
Who should be alerted when a voice circuit goes down?
When a voice circuit really goes down, the people who need to know are the ones who can act at that hour, not an inbox nobody opens overnight. A tiered ladder that climbs until someone takes ownership ensures that a confirmed incident’s alert doesn’t go unanswered.
In Monitor, the incident alerts tier 1 by email and SMS. If nobody acknowledges within the set time, the alert climbs to the next tier; a single acknowledgment, one tap on the SMS link, stops the climb and records who took ownership. If no tier acknowledges, the company’s administrators are alerted. The customer’s contacts receive the problem notice and the resolution notice, outside the ladder. Maintenance windows silence the chosen circuits during the scheduled time. See alerts and escalation.
The time to the first acknowledgment goes into the SLA reports alongside availability. Measure the call, confirm the outage, separate out the blindness, keep the evidence and alert the right person: that is what turns monitoring into a response.
Frequently asked questions
Are ping or SIP OPTIONS enough to monitor a SIP trunk?
No. Ping says the SBC's or the PBX's address responds on the network, and SIP OPTIONS says the SIP stack on the other side responds. Neither places a call: they don't show whether the carrier routes your number to you, whether audio flows in both directions or whether the right IVR answers. For that you need a real test call.
How often should a voice circuit be tested?
At an interval well below the downtime the target allows. A 99.9% target in a 30-day month tolerates 43 minutes; testing once an hour can miss an entire outage. At Monitor's default pace, the test call runs every 15 minutes, with retries every 2 minutes after a failure.
Why not alert on the very first failed call?
Because an isolated failure can be a route that blipped once, and a false alarm at 2:00 a.m. teaches the team to ignore the next ones. Repeating the call separates a blip from an outage: in Monitor, four failures in a row, by default (the first one and three retries), open an incident, and only a confirmed incident alerts anyone by email and SMS.
What is a no-visibility test?
It is a test that could not run because of a problem on the tester's side, for example the monitoring's call server not responding. It says nothing about the circuit. In Monitor, that period doesn't count against the circuit, stays out of the SLA and doesn't wake the customer's team; it is 2N5 that gets alerted.
What should I send the carrier when a SIP trunk goes down?
The number called, the origin, the time of each call with seconds and time zone, the SIP response code, the Q.850 cause when one was sent and the Call-ID. With that data the carrier can find each call in its own records. Include the last call that worked as well, to mark when the outage began.