sbc trunking · published

CUBE dial-peer matching and voice class URI and translation profiles

Verified 2026-09-24 · 51 sources · tier 2

Also known as Cisco Unified Border Element dial peers.

Cisco Unified Border Element (CUBE) uses ordered criteria lists to bind incoming and outgoing SIP call legs to dial peers 2027. Dial-peer selection governs parameter application, URI-based routing, digit transformation, and destination selection across VoIP calls 494133.

Inbound dial-peer matching

For inbound SIP call legs, CUBE prefers inbound dial-peer match criteria in the following sequence: incoming uri via, incoming uri request, incoming uri to, incoming uri from, incoming called-number, and answer-address 20. The Cisco call-routing technote's inbound SIP table ranks eight criteria: URI via, URI request, URI to, URI from, called number (incoming called-number or incoming called e164-pattern-map), calling number (incoming calling e164-pattern-map or answer-address), destination-pattern matched against ANI, then carrier-id source 21.

The gateway searches all dial peers against the first inbound match criterion and only moves to the next criterion if no dial peer matched the previous one 19. On an inbound SIP leg, destination-pattern is evaluated against the calling number (ANI), not the called number, and only at preference 7 after URI, called-number, and calling-number criteria 4. WarmTransfer's reading of the sources is that an outbound dial peer that has a destination-pattern but no incoming criteria can inadvertently be selected as the inbound dial peer if the calling number happens to match that pattern, meaning inbound dial peers should carry explicit incoming uri or incoming called-number criteria 5.

When no inbound dial peer matches any criterion, the gateway selects default dial-peer 0 6. Dial-peer 0 operates with direct-inward-dial enabled and voice activity detection (VAD) enabled, advertises all voice codecs for VoIP, and contains no DTMF-relay mechanism 6. WarmTransfer's reading of the sources is that calls landing on dial-peer 0 are likely to encounter DTMF or codec negotiation failures because no dtmf-relay is defined and every codec is offered, making an inbound leg reporting pid:0 an initial troubleshooting checkpoint 7.

H.323 matching behavior documented in older materials applies only to earlier releases, as the CUBE 17.6+ configuration guide notes that H.323 is deprecated as of Cisco IOS XE Bengaluru 17.6.1a 15.

Matching inbound dial peers by voice class URI

Inbound matching by URI functions only for SIP (voip session protocol sipv2), and each dial peer can carry only 1 incoming uri match 49. A voice class uri can match on host (IPv4, IPv6, DNS, or hostname pattern), user-id, or pattern (the full URI string) 47. These patterns are case-sensitive, and the pattern, user-id, and hostname strings are limited to 32 characters 45. A voice class uri can define at most 10 host entries across IPv4, IPv6, and DNS, and only 1 host hostname-pattern entry 46.

When multiple dial peers match by URI, the longest match wins; because a URI pattern match has no match length, it is the least preferred 48. The incoming uri via criterion matches the topmost Via header to identify the last hop, which Cisco recommends for calls traversing multiple SIP hops 50.

In Webex Calling Local Gateway environments, inbound calls from Webex are matched using a voice class uri containing the pattern dtg= followed by the trunk OTG/DTG value from Control Hub, applied to the dial peer via incoming uri request 24. The same Local Gateway documentation matches calls from an IP PSTN provider using a voice class uri host ipv4 entry, and calls from Cisco Unified Communications Manager (Unified CM) using a voice class uri pattern matching the SIP port (such as :5065) 25.

Outbound dial-peer matching and hunting

The CUBE 17.6+ configuration guide lists outbound dial-peer match preference as: destination route-string; destination uri with target carrier-id; destination-pattern with target carrier-id; destination uri; destination-pattern; target carrier-id 27.

The Cisco call-routing technote ranks outbound selection as: dial-peer group (destination dpg), dial-peer provision policy, ILS route string, URI with carrier-id, called number with carrier-id, destination uri, called number (destination-pattern, e164-pattern-map, dnis-map), then calling number (destination calling e164-pattern-map) 29.

A dial peer must be in an UP operational state to be eligible for outbound routing 26. For an outbound VoIP dial peer, this requires a valid outbound matching mechanism and a valid session target 26. When multiple peers match equally, a lower preference value is selected first, where preference 0 is tried before preferences 1 through 10 30.

The global dial-peer hunt configuration accepts values from 0 through 7 17. Hunt scheme 0 is the default: longest match in phone number, then explicit preference, followed by random selection 16. Scheme 2 evaluates explicit preference, then longest match, then random selection; scheme 6 evaluates random selection only; and scheme 7 evaluates least recent use only 17. If huntstop is configured on a dial peer that fails, the gateway terminates dial-peer hunting immediately rather than trying the next candidate peer 18.

Dial-peer number strings support specific wildcards: '.' matches any single character among 0-9, A-F, *, #, or +; 'T' matches a variable length of up to 32 digits; brackets specify a single-position range; a leading '+' represents a literal plus sign; and '^' anchors to the string start 51. An e164-pattern-map supports these wildcards and can be entered via CLI or loaded from a .cfg file, which supports up to 5000 entries 14.

Outbound dial-peer groups and provision policies

An inbound dial peer can reference an outbound dial-peer group using destination dpg 8. Up to 20 outbound SIP dial peers can be placed in a voice class dpg 8. Group members can each have a configured preference that defines the hunting order within that group 12. Outbound dial peers assigned to a dial-peer group still require a destination-pattern in their configuration, even though the group does not use the pattern to match the call 10. Dial-peer groups require valid E.164 patterns and do not support two-stage dialing, overlap dialing, or digit stripping for POTS peers 11. If every peer in an active dial-peer group is unavailable, the call is disconnected instead of falling back to normal outbound dial-peer selection 9. However, if the dial-peer group itself is shut down, CUBE falls back to the standard outbound dial-peer search 13.

Alternatively, an inbound dial peer can use destination provision-policy to reference a voice class dial-peer provision-policy 31. This allows CUBE to match outbound dial peers using inbound-leg attributes, including Via, From, To, Diversion, Referred-By, called number, calling number, and carrier ID 31. A provision policy only inspects the topmost Via and topmost Diversion headers, cannot inspect headers altered by a TCL application, and disconnects calls with cause unassigned number (1) if the policy is empty 32.

Server groups and trunk monitoring

Outbound SIP dial peers can direct calls to a voice class server-group using session server-group 33. A server group supports up to 5 IPv4 or IPv6 destination addresses 33. If no hunt-scheme is set, the server group routes to the available target with the highest preference; if neither preferences nor round-robin are defined, selection across targets is random 35. When processing responses, the server group hunts to the next member on SIP 404, 500, or 503 responses, but does not hunt on 480, 486, or 600 34. Shutting down a server group places every dial peer that targets it into an out-of-service state 36. When SIP OPTIONS keepalives are configured, a dial peer is busied out only when all of its configured destinations (such as every member in its server group) fail to respond 23.

Voice translation profiles and rules

A dial peer can attach 1 incoming and 1 outgoing voice translation profile via translation-profile incoming and translation-profile outgoing 41. Each voice translation-profile applies translation rules independently to called, calling, and redirect-called numbers 42. Translation profiles can be configured at multiple levels: on a voice port for incoming POTS, on a trunk group, on an individual dial peer, and globally for incoming VoIP traffic using voip-incoming 40.

Cisco lists translation-profile selection preference as: incoming on voice-port, incoming on trunk group, incoming on inbound dial peer, incoming via voice service pots, incoming via global voip-incoming, then outbound via voice service pots, outbound on outbound dial peer, outbound on trunk group, outbound on voice-port 44.

Rules within a profile can be evaluated offline using the command test voice translation-rule and monitored during live calls using debug voice translation 39.

Verification and troubleshooting

Live call legs can be checked using show call active voice brief, which displays the dial-peer ID as pid: alongside CallOrigin values of Answer or Originate to identify which inbound and outbound peers were matched 37. Additional operational verification commands include show dial-peer voice summary, show voice class uri, show voice class dpg, show voice class server-group, and show dialplan incall sip 38.

For diagnostic tracing, Cisco outlines a baseline SIP debug suite consisting of debug ccsip messages and debug ccsip error, with debug ccsip non-call available optionally, and debug voip ccapi inout recommended because it typically produces minimal CPU overhead 2. Before collecting debugs, Cisco recommends allocating a 10 MB logging buffer (logging buffered 10000000), applying millisecond timestamps, and disabling console and monitor logging; debug commands must be halted with undebug all if router CPU utilization exceeds 80% 3.

Applicability

Applies to: Cisco Unified Border Element, Cisco IOS XE voice gateways, and Cisco Webex Calling Local Gateway on IOS XE. Deployments: on-premises and hybrid. Sources checked 2026-09-24. Deprecation of H.323 matching applies to Cisco IOS XE Bengaluru 17.6.1a onwards 15.

What remains uncertain

Whether dial-peer matching behavior differs under specific non-VoIP signaling contexts outside standard SIP and deprecated H.323 is not covered by the sources below. The interaction of voice class URI matching with SIP headers other than Via, Request-URI, To, and From is not covered by the sources below.