Avaya

SIP and E1 trunk monitoring in Avaya environments

In an Avaya environment, a call can pass through the carrier, an SBC, session routing and the call server before reaching an extension or an IVR. Each layer has its own status, and all of them can be up while the number does not connect. This page shows where to look and what only an outside call proves.

How does a trunk in an Avaya environment fail without an alarm?

In a large Avaya environment, a call from the carrier can cross an SBC, session routing and the call server before reaching the extension, the vector or the IVR. Each element can pass internal tests while the real call fails between them, because of routing, codecs, certificates or capacity.

The most common silent failures:

  • Routing. A change to the dial plan or the routing rules sends the inbound number to the wrong destination, or to none.
  • Codec. A codec set changed on one of the elements, with no match on the other side, ends in a 488 or in one-way audio.
  • Certificates. SIP links over TLS between the elements, or between the SBC and the carrier, depend on valid certificates; an expired one takes signaling down.
  • Capacity. The channel limit of the trunk, of trunk group members or of licensed sessions shows up as rejections at peak times.
  • E1. On an E1 trunk, a physical-layer alarm or blocked channels reduce capacity without stopping the whole trunk.

Where do you look for each symptom?

Each layer has its own tool: the SBC’s traces and link status, session routing’s SIP link monitoring, the call server’s trunk status commands and, on smaller systems, the system’s own status monitor. The table links each symptom to the code and the point to check.

Symptom SIP code or cause Where to look
Inbound stopped The carrier is not delivering, or the SIP link went down SBC trace, SIP link status
Outbound rejected 403 Forbidden or 404 Not Found SBC trace, routing rules
Rejected right after the INVITE 488 Not Acceptable Here Codec sets on each element
TLS signaling went down Expired or untrusted certificate SBC and link certificates
Rejected at peak times 503 with cause 34 Trunk group status, licensed sessions
E1 carrying fewer calls than usual Cause 34 or cause 38 E1 alarms and channels on the media gateway

What does a real test call catch that Avaya dashboards do not show?

The dashboards show each element and the links between them. They do not see a call the carrier failed to deliver, and they do not know whether the IVR played the right greeting. A call placed from the outside, like a customer’s, crosses the whole chain and shows the result with the route’s SIP code or Q.850 cause.

It also checks whether audio flowed both ways and whether the measured voice quality, MOS-LQO, stayed above the agreed threshold.

How does Monitor monitor an Avaya environment?

Monitor does not integrate with Avaya; it calls the numbers, so it works with any platform. 2N5 places real test calls at the agreed pace, retries each failure before alerting and delivers the incident with the SIP code and Q.850 cause of each call, ready for the ticket.

See the details in SIP trunk monitoring and, for service numbers, in 0800 and IVR monitoring.

Frequently asked questions

Does Monitor connect to Avaya?

No. Monitor does not integrate with any Avaya product. 2N5 calls the numbers you choose, from its own platform, the way a customer does. That is why it works with any version, with SIP or E1 trunks, with or without an SBC, and with any carrier.

Isn't Avaya's SIP link monitoring enough?

Link monitoring between SIP elements uses messages such as SIP OPTIONS to find out whether each element responds. It proves that signaling gets through, but not that an INVITE completes, that the inbound number reaches the right vector or IVR, or that audio flows both ways.

What about the E1 trunks still on the Avaya?

Each inbound number on an E1 is a voice circuit like any other. The test call dials the number and judges the result, so an E1 is monitored the same way as a SIP trunk, with the Q.850 cause the route returned when the call fails.

How do I tell an Avaya failure from a carrier failure?

Compare what the environment logged with what the test call received. If the outside call does not appear in any SBC or call server trace, the failure is upstream of them, at the carrier. If it appears and is rejected, the SIP response tells you which element rejected it.

See it on your own circuits

2N5 prepares the demo with the numbers you choose. Three questions, about a minute.