How a Cisco CUBE chooses a dial-peer

CollabPlane engineering notes

Most "the call fails on the gateway" problems come down to which dial-peer matched. A CUBE matches one inbound and one outbound dial-peer for every call, and each match follows a fixed order.

Inbound: first match in this order

For a SIP call arriving at the CUBE, Cisco IOS-XE checks these in order of preference and stops at the first type that matches:

1. incoming uri via
2. incoming uri request
3. incoming uri to
4. incoming uri from
5. incoming called-number
6. answer-address, compared with the calling number
7. destination-pattern, compared with the calling number
8. carrier-id source

Within one type, the longest and most specific match wins. Anything narrower than the type, such as a VRF or tenant binding, filters the candidates first.

When nothing matches: dial-peer 0

If no inbound dial-peer matches, the CUBE uses its built-in default, dial-peer 0. That peer has none of your settings: no SIP profile, no chosen codec list, no DTMF method you configured. The call may still connect and then fail in a way that looks unrelated, such as no audio in one direction or digits that are not recognized. Seeing "0" as the inbound peer is a finding in itself.

Outbound: a different order

For the outgoing leg the order of preference is:

1. A dial-peer group attached to the inbound peer
2. A provision policy URI
3. An ILS route string
4. destination uri together with carrier-id target
5. destination-pattern together with carrier-id target
6. destination uri
7. destination-pattern
8. carrier-id target

Several outbound peers can match. The CUBE orders them by longest match, then by preference, and tries the next one when a peer fails. That hunt is why a failed call can show more than one outbound attempt.

See the match

• show dialplan number <digits> predicts the outbound match for a number.
• debug voip dialpeer shows the inbound and outbound peers chosen for a live call.
• show dial-peer voice summary lists peers with their state. A peer that is down is skipped.

Check the inbound peer first. A wrong inbound match changes everything that follows.

Where Workbench helps

Dial-Peer Lens reads debug voip dialpeer output and shows one card per call: the inbound peer, each outbound peer tried, and why. CCAPI Flow adds the timeline from the call-control debug.