How do you know the failure is the carrier’s?
By calling, from the outside, a number that comes in over the trunk and reading the response. If the call does not reach your PBX or SBC, the failure is upstream of them. If it arrives and one of your devices rejects it, the failure is yours. The SIP response and Q.850 cause tell you the type of problem, and the headers tell you who responded.
The diagnosis is the same with any carrier, because SIP and Q.850 are standards. What changes is the contract: the ticket channel, deadlines and targets, which you confirm in yours.
Which carriers have a page?
The pages below use the carrier’s name only to identify the contracted service. Each one shows how to know a SIP or E1 trunk went down, the most common failure signatures and the evidence a ticket needs. They make no claims about any carrier’s network, products or support.
- Vivo: Vivo SIP trunks and E1 trunks, how to know one went down and what to put in the ticket.
- Claro: Claro SIP trunks and E1 trunks, how to confirm the outage and build the ticket.
- Embratel: Embratel SIP trunks and E1 trunks, how to identify the outage and prove the failure.
What about other carriers?
The same diagnosis works for any carrier’s trunk, because it is based on the response to each call, not on one company’s network. The steps on the pages above, the table below and the SIP code and Q.850 cause reference pages apply unchanged.
Algar, Oi and TIM
For SIP or E1 trunks from Algar, Oi or TIM, follow the same playbook: call a number on the trunk from the outside, read the SIP response and the Q.850 cause, separate a failure on your side from a failure in the route, and take the data from each attempt to the ticket. Confirm the support channel, deadlines and targets in your contract.
Which failure signature points to the carrier?
Some responses usually originate in the carrier’s route, others on your side. The table is a starting point: always confirm from the response headers which device generated it, because your own PBX or SBC can also respond with a 503 or a 403.
| Symptom | SIP code / Q.850 cause | First place to look |
|---|---|---|
| Rejected at peak times | 503 with cause 34 | Active calls against contracted channels |
| Rejected at any time | 503 with cause 38 or 41 | The carrier’s route |
| Outbound rejected | 403 Forbidden | The trunk’s IP, credentials and caller number |
| Number not found | 404 Not Found or cause 1 | Number activation and routing |
| No response | 408 Request Timeout | Firewall, network and the device on the route |
| Codec rejected | 488 Not Acceptable Here | Codecs on both sides |
What evidence should go in any ticket?
The data that locates each call in the network’s records: date and time with time zone, calling and called numbers, Call-ID, the SIP response with the Reason header, how many attempts failed and the last healthy call. On an E1, the alarms and the affected channels. Also note the reference number of each contact.
Monitor puts that block together in every incident, ready to paste into the ticket. See SIP trunk monitoring.
Frequently asked questions
Does Monitor integrate with any carrier?
No, with none. Monitor calls the numbers you choose, from the 2N5 platform, the way a customer does. That is why the same monitoring works for SIP and E1 trunks from any carrier, with nothing installed on the trunk, the SBC or the PBX.
Do SIP codes change from one carrier to another?
Their meaning does not. SIP codes and Q.850 causes are standardized, so a 503 with cause 34 means no channel available on any network. What can change is which codes each network chooses to send and whether it sends the Q.850 cause in the Reason header. Confirm the technical details of your trunk in your contract.
Do you compare carrier quality?
No. These pages do not rate any carrier's network, prices, products or support. They show how to diagnose a failure on your trunk, whatever the carrier. The SLA report shows the availability of each of your circuits and carriers, measured by your own test calls.