How does a Cisco trunk stop completing calls without an alarm?
In a Cisco environment, a call crosses the carrier, CUBE, and CUCM or Webex Calling. Each leg has its own status, and each one can be up while the call fails between them. A dial-peer that no longer matches the number, an expired certificate or a codec with no match takes service down without any alarm.
The most common silent failures:
- Dial-peer or route pattern. A change to the dial plan sends the inbound number to the wrong dial-peer, or to none.
- Registration. Trunks with SIP registration at the carrier lose their registration and inbound calls stop arriving.
- Certificates. TLS trunks, such as the Local Gateway trunk to Webex Calling, depend on valid certificates and a trusted chain; an expired certificate takes signaling down.
- Codec and transcoding. With no codec in common and no transcoder available, the call is rejected with a 488.
- Capacity. The contract’s channel limit or CUBE’s session limit shows up as a 503.
Where do you look at each layer?
Each layer has its own commands and dashboards. On CUBE, IOS XE commands show registration, active calls and SIP messages. On CUCM, the real-time monitoring tools and traces show the trunk. On Webex Calling, Control Hub shows the status of the Local Gateway or of the carrier connection.
| Symptom | SIP code or cause | Where to look |
|---|---|---|
| Inbound stopped | Expired registration, or no dial-peer matches the number | show sip-ua register status, show dial-peer voice summary |
| Outbound rejected | 403 Forbidden or 404 Not Found | debug ccsip messages on CUBE |
| Rejected right after the INVITE | 488 Not Acceptable Here: no matching codec | Dial-peer codec list, transcoders on CUCM |
| TLS signaling went down | Expired certificate or untrusted chain | CUBE certificates and trustpool |
| Rejected at peak times | 503 with cause 34 | show call active voice brief against the contracted limit |
| One-way audio | NAT, firewall or media resource | show voip rtp connections, RTP ports on the firewall |
What does a real test call catch that Cisco dashboards do not show?
The dashboards show each device from the inside. They do not see a call the carrier failed to deliver, and they do not know whether the service number reaches the right queue or IVR. A call placed from the outside, like a customer’s, crosses every layer and shows the result with the SIP code the route returned.
It also checks what comes after the answer: whether the right greeting played, whether audio flowed both ways and whether the measured voice quality, MOS-LQO, stayed above the agreed threshold.
What changes on Webex Calling?
On Webex Calling, the PBX is in the cloud, but the call still reaches the public network by some path: a Local Gateway with CUBE on your network, or a carrier connected to the cloud. When the path is the Local Gateway, the same CUBE failures apply, including the TLS trunk certificate.
When the carrier connects straight to the cloud, the equipment is not yours, and the test call’s evidence is what you take to the ticket.
How does Monitor monitor a Cisco environment?
Monitor does not integrate with CUBE, CUCM or Webex Calling; it calls the numbers, so it works with any of them. 2N5 places real test calls at the agreed pace, retries each failure before alerting and delivers the incident with the SIP code and the Q.850 cause.
See the details in SIP trunk monitoring and, for service numbers, in 0800 and IVR monitoring.
Frequently asked questions
Does Monitor connect to CUCM or Control Hub?
No. Monitor does not integrate with CUBE, CUCM or Webex Calling. 2N5 calls the numbers you choose, from its own platform, the way a customer does. That is why it works with any Cisco version and architecture, and with any carrier.
Isn't CUBE's OPTIONS keepalive enough?
The SIP OPTIONS keepalive takes a dial-peer out of service when the other side stops responding, which is useful for routing. It does not prove that an INVITE completes, that the inbound number reaches the right destination, or that audio flows both ways. Those cases only show up on a real call.
Where does one-way audio usually start in a Cisco environment?
In NAT, in a firewall between CUBE and the carrier, or in media resources. When the two sides share no codec, CUCM needs a transcoder; without one, the call can be rejected or connect with no audio. Also check the RTP ports open on the firewall.
Does it work with Webex Calling and a local carrier?
Yes. Whatever the path to the public network, through a Local Gateway with CUBE or through a carrier connected to the cloud, the test call dials the number like a customer. The result carries the SIP code and the Q.850 cause the route returned.