# CUBE dial-peer matching and voice class URI and translation profiles Canonical: https://warmtransfer.net/knowledge/cube-dial-peers Last verified: 2026-09-24 Cisco Unified Border Element (CUBE) uses ordered criteria lists to bind incoming and outgoing SIP call legs to dial peers[^20][^27]. Dial-peer selection governs parameter application, URI-based routing, digit transformation, and destination selection across VoIP calls[^49][^41][^33]. ## 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]. ## See also - [Unified CM translation and transformation patterns](https://warmtransfer.net/knowledge/cucm-translation-patterns) - [SIP OPTIONS pings and trunk keepalives](https://warmtransfer.net/knowledge/sip-options-keepalive) - [SIP capture and analysis with Wireshark and sngrep and HOMER](https://warmtransfer.net/knowledge/sip-capture-analysis) - [Unified CM and Webex Calling coexistence during a migration](https://warmtransfer.net/knowledge/cucm-webex-calling-coexistence) - [Local Gateway design and configuration](https://warmtransfer.net/knowledge/webex-calling-local-gateway) - [Cisco Unified Border Element configuration and licensing](https://warmtransfer.net/knowledge/cube-configuration) - [Enterprise dial plan design and normalization](https://warmtransfer.net/knowledge/dial-plan-design) - [Unified CM SIP trunk to CUBE configuration](https://warmtransfer.net/knowledge/cucm-config-sip-trunk-to-cube) - [SIP 503 and trunk out-of-service failures](https://warmtransfer.net/knowledge/sip-503-trunk-failures) - [CUBE high availability](https://warmtransfer.net/knowledge/cube-high-availability) ## 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. ## Sources [^1]: On some IOS XE releases (reported from 16.12.6 / 17.3.5 / 17.6.1), an outbound dial peer configured with both session server-group and sip options-keepalive is busied out and CUBE answers the caller with 503 instead of sending an INVITE; Cisco tracks this as CSCvx92872. Source: [Troubleshoot Busyout Dial Peers on CUBE or IOS Voice Gateway](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/217860-troubleshooting-busyout-dial-peers-on-cu.html), Problem; Root Cause; Workaround sections. Checked 2026-09-24. [^2]: Cisco's basic debug set for SIP calls on CUBE is debug ccsip messages and debug ccsip error, with debug ccsip non-call optional, and debug voip ccapi inout recommended alongside because it usually has minimal CPU impact. Source: [Configure Debug Collection for CUBE and TDM Gateways](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/215208-configure-debug-collection-for-unified-b.html), SIP Call Flow Debugs; CCAPI debugs. Checked 2026-09-24. [^3]: Before debugging, Cisco recommends logging to a 10 MB buffer (logging buffered 10000000), disabling console and monitor logging, and millisecond timestamps; debugs should be stopped (undebug all) if CPU exceeds 80%. Source: [Configure Debug Collection for CUBE and TDM Gateways](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/215208-configure-debug-collection-for-unified-b.html), Configure > baseline logging configuration; CPU caution. Checked 2026-09-24. [^4]: 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. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Inbound Dial-Peer Matching > Table 1 (SIP), preference 7 'Destination-pattern (ANI)'. Checked 2026-09-24. [^5]: An outbound dial peer that has destination-pattern but no incoming criteria can be selected as the inbound dial peer for a call whose calling number happens to match that pattern, so inbound peers should carry explicit incoming uri or incoming called-number criteria (inferred). Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Inbound Dial-Peer Matching > Table 1 (SIP), preference 7. Checked 2026-09-24. [^6]: When no inbound dial peer matches, the gateway uses default dial-peer 0, which has no DTMF-relay mechanism, advertises all voice codecs for VoIP, has VAD enabled and has direct-inward-dial enabled. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), When No Matches Exist / Default Dial-Peer 0. Checked 2026-09-24. [^7]: A call that lands on dial-peer 0 is likely to show DTMF or codec-negotiation problems because dial-peer 0 carries no dtmf-relay and offers every codec, so seeing pid:0 on the inbound leg is a first thing to check (inferred). Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), When No Matches Exist / Default Dial-Peer 0. Checked 2026-09-24. [^8]: Up to 20 outbound SIP dial peers can be grouped into one dial-peer group (voice class dpg), which an inbound dial peer references with destination dpg. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Outbound Dial Peer Group as an Inbound Dial-Peer Destination](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_multiple-outbound-dial-peer.html), Information About Outbound Dial Peer Group; configuration task (destination dpg). Checked 2026-09-24. [^9]: If every dial peer in an active dial-peer group is unavailable, the call is disconnected rather than falling back to the regular outbound dial-peer search. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Outbound Dial Peer Group as an Inbound Dial-Peer Destination](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_multiple-outbound-dial-peer.html), Restrictions for Outbound Dial Peer Group. Checked 2026-09-24. [^10]: A dial peer used in a dial-peer group still needs a destination-pattern configured, even though the group does not match calls on it. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Outbound Dial Peer Group as an Inbound Dial-Peer Destination](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_multiple-outbound-dial-peer.html), Restrictions for Outbound Dial Peer Group. Checked 2026-09-24. [^11]: Dial-peer groups work only with valid E.164 patterns and, for POTS peers, do not support two-stage dialing, overlap dialing or digit stripping. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Outbound Dial Peer Group as an Inbound Dial-Peer Destination](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_multiple-outbound-dial-peer.html), Restrictions for Outbound Dial Peer Group. Checked 2026-09-24. [^12]: Each member of a dial-peer group can carry a preference that sets the order in which the group's dial peers are tried for the outgoing call. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Outbound Dial Peer Group as an Inbound Dial-Peer Destination](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_multiple-outbound-dial-peer.html), Information About Outbound Dial Peer Group. Checked 2026-09-24. [^13]: If the dial-peer group itself is shut down, the regular outbound dial-peer search is used instead. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Outbound Dial Peer Group as an Inbound Dial-Peer Destination](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_multiple-outbound-dial-peer.html), Restrictions for Outbound Dial Peer Group. Checked 2026-09-24. [^14]: An e164-pattern-map can be configured in the CLI or loaded from a .cfg file, can use the normal dial-peer wildcards, and the .cfg file can hold 5000 entries. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Advanced Call Routing Techniques > E164-Pattern-Maps. Checked 2026-09-24. [^15]: The CUBE 17.6+ configuration guide notes that H.323 is deprecated as of IOS XE Bengaluru 17.6.1a, so the H.323 inbound matching table in older material applies only to earlier releases. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Dial Peers](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_cube-dp.html), Configure Dial Peers (H.323 deprecation note). Checked 2026-09-24. [^16]: The default dial-peer hunt scheme is 0: longest match in phone number, then explicit preference, then random selection. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Number String Dial-Peer Hunting (dial-peer hunt values). Checked 2026-09-24. [^17]: The global dial-peer hunt command accepts values 0 through 7; for example 2 is explicit preference then longest match then random, 6 is random selection only and 7 is least recent use only. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Number String Dial-Peer Hunting (dial-peer hunt 0-7). Checked 2026-09-24. [^18]: When huntstop is configured on a dial peer and that peer fails, the gateway stops dial-peer hunting instead of trying the next matching dial peer. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Number String Dial-Peer Hunting (huntstop example). Checked 2026-09-24. [^19]: 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. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Inbound Dial-Peer Matching (text preceding Table 1). Checked 2026-09-24. [^20]: For inbound SIP call legs, CUBE prefers inbound dial-peer match criteria in this order: incoming uri via, incoming uri request, incoming uri to, incoming uri from, incoming called-number, answer-address. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Dial Peers](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_cube-dp.html), Configure Dial Peers > Preferences (inbound dial-peer matching list). Checked 2026-09-24. [^21]: 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. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Inbound Dial-Peer Matching > Table 1 (SIP), preferences 1-8. Checked 2026-09-24. [^22]: The incoming translation applied on the inbound dial peer changes the number that the outbound dial-peer search sees, so outbound destination-pattern must be written against the post-translation number (inferred). Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), URI and Digit Manipulation > Translation-Profile Selection Preference. Checked 2026-09-24. [^23]: With OPTIONS keepalive, a SIP dial peer is busied out only when all of its destinations (for example every server-group member) fail to respond. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), SIP Trunk Monitoring > Information About SIP Out-of-Dialog OPTIONS Ping Group. Checked 2026-09-24. [^24]: The Webex Calling Local Gateway guide matches inbound calls from Webex with a voice class uri containing pattern dtg= followed by the trunk OTG/DTG value from Control Hub, applied with incoming uri request. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Configure Local Gateway on Cisco IOS XE for Webex Calling > voice class uri 100 sip / dial-peer voice 100 voip. Checked 2026-09-24. [^25]: The same Local Gateway guide identifies calls from an IP PSTN provider with a voice class uri host ipv4 entry and calls from Unified CM with a voice class uri pattern on the SIP port (for example :5065). Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), voice class uri 200 sip (host ipv4) and voice class uri 300 sip (pattern :5065) examples. Checked 2026-09-24. [^26]: A dial peer must be in the UP operational state to be eligible for call routing; an outbound VoIP dial peer needs a valid outbound matching mechanism and a valid session target to be UP. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Dial-Peer States. Checked 2026-09-24. [^27]: 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. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Dial Peers](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_cube-dp.html), Configure Dial Peers > Preferences (outbound dial-peer matching list). Checked 2026-09-24. [^28]: The guide's six-item outbound list and the technote's eight-item list are consistent once destination dpg and provision policy are treated as mechanisms that bypass the regular outbound search; the guide list describes the regular search only (inferred). Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Outbound Dial-Peer Matching preference table vs CUBE guide Configure Dial Peers > Preferences. Checked 2026-09-24. [^29]: 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). Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Outbound Dial-Peer Matching preference table, rows 1-8. Checked 2026-09-24. [^30]: Among otherwise equal dial peers, a dial peer with preference 0 is matched before one with preference 1 through 10; lower preference value is tried first. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Number String Dial-Peer Hunting (preference). Checked 2026-09-24. [^31]: A voice class dial-peer provision-policy applied to an inbound dial peer with destination provision-policy lets CUBE choose the outbound dial peer from inbound-leg attributes such as Via, From, To, Diversion, Referred-By, called number, calling number and carrier ID. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Inbound Leg Headers for Outbound Dial-Peer Matching](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/multiple-outbound-dial-peer.html), Information About Inbound Leg Headers for Outbound Dial-Peer Matching. Checked 2026-09-24. [^32]: Provision policy uses only the topmost Via and topmost Diversion header, cannot use headers modified by a TCL application, and an empty provision policy disconnects calls with cause unassigned number (1). Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Inbound Leg Headers for Outbound Dial-Peer Matching](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/multiple-outbound-dial-peer.html), Restrictions for Inbound Leg Headers for Outbound Dial-Peer Matching. Checked 2026-09-24. [^33]: A voice class server-group holds up to five IPv4 or IPv6 target addresses, is usable only from SIP dial peers, and is referenced from an outbound dial peer with session server-group. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Server Groups](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/multiple-server-groups.html), Server Groups > Overview; Restrictions. Checked 2026-09-24. [^34]: A server group hunts to the next address on SIP 404, 500 or 503 responses, but does not hunt on 480, 486 or 600. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Server Groups](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/multiple-server-groups.html), Server Groups > Overview. Checked 2026-09-24. [^35]: Without a hunt-scheme a server group picks the available address with the highest preference; with neither round-robin nor preferences configured, server selection is random. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Server Groups](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/multiple-server-groups.html), Server Groups > Overview. Checked 2026-09-24. [^36]: When a server group is shut down, every dial peer that uses it as its destination is out of service. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Server Groups](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/multiple-server-groups.html), Server Groups > Restrictions. Checked 2026-09-24. [^37]: show call active voice brief shows, per call leg, pid: (the dial-peer tag used for that leg) and the direction Answer or Originate, which is how the matched inbound and outbound dial peers are confirmed for a live call. Source: [Cisco IOS Voice Command Reference - S commands - show aal2 profile through show call filter match-list](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s3.html), show call active voice > brief output format and field descriptions (Dial-Peer, CallOrigin). Checked 2026-09-24. [^38]: Useful verification commands for this configuration include show dial-peer voice summary (operational status and keepalive), show voice class uri, show voice class dpg, show voice class server-group and show dialplan incall sip. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), verification examples (show dial-peer voice summary; show voice class uri). Checked 2026-09-24. [^39]: Translation rules can be tested offline with test voice translation-rule and traced live with debug voice translation. Source: [Configure Number Translation with Voice Translation Profiles](https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html), Verify / Troubleshoot. Checked 2026-09-24. [^40]: Translation profiles can be applied on a dial peer, on a voice port (incoming POTS), on a trunk group, and globally to all incoming VoIP calls (voip-incoming). Source: [Configure Number Translation with Voice Translation Profiles](https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html), Configure (profile application points). Checked 2026-09-24. [^41]: A dial peer can carry one incoming and one outgoing voice translation-profile, applied with translation-profile incoming or translation-profile outgoing. Source: [Configure Number Translation with Voice Translation Profiles](https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html), Configure > Voice Translation Profile / apply to dial peer. Checked 2026-09-24. [^42]: A voice translation-profile references translation rules separately for the called, calling and redirect-called numbers. Source: [Configure Number Translation with Voice Translation Profiles](https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html), voice translation-profile command options (translate called / calling / redirect-called). Checked 2026-09-24. [^43]: Cisco's translation-profile technote states up to 15 rules per translation-rule table, up to 128 translation-rule tables and up to 1000 translation profiles, without scoping these limits to a release. Source: [Configure Number Translation with Voice Translation Profiles](https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html), Background Information / limits paragraph. Checked 2026-09-24. [^44]: 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. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), URI and Digit Manipulation > Translation-Profile Selection Preference, items 1-9. Checked 2026-09-24. [^45]: voice class uri patterns are case-sensitive and the pattern, user-id and hostname are limited to 32 characters. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Matching Inbound Dial Peers by URI of Incoming SIP Calls](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-inbnd-dp-match-uri.html), Restrictions for Matching Inbound Dial Peers by URI. Checked 2026-09-24. [^46]: A voice class uri can contain at most 10 host ipv4/ipv6/dns entries in total and only one host hostname-pattern entry. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Matching Inbound Dial Peers by URI of Incoming SIP Calls](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-inbnd-dp-match-uri.html), Restrictions for Matching Inbound Dial Peers by URI. Checked 2026-09-24. [^47]: A voice class uri can match on host (hostname pattern, IPv4, IPv6 or DNS), user-id, or pattern (the entire URI string). Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Matching Inbound Dial Peers by URI of Incoming SIP Calls](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-inbnd-dp-match-uri.html), Information About Matching Inbound Dial Peers by URI; configuration task. Checked 2026-09-24. [^48]: When several dial peers match by URI, the longest match wins, and a URI pattern match has no match length so it is the least preferred. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Matching Inbound Dial Peers by URI of Incoming SIP Calls](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-inbnd-dp-match-uri.html), Restrictions for Matching Inbound Dial Peers by URI. Checked 2026-09-24. [^49]: Inbound dial-peer matching by URI works only for SIP (voip session protocol sipv2) and a dial peer can carry only one incoming uri match. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Matching Inbound Dial Peers by URI of Incoming SIP Calls](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-inbnd-dp-match-uri.html), Restrictions for Matching Inbound Dial Peers by URI. Checked 2026-09-24. [^50]: incoming uri via matches against the topmost Via header, which identifies the last hop, and Cisco recommends it when the call traverses multiple SIP hops. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Matching Inbound Dial Peers by URI of Incoming SIP Calls](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-inbnd-dp-match-uri.html), Information About Matching Inbound Dial Peers by URI (incoming uri via). Checked 2026-09-24. [^51]: In dial-peer number patterns, '.' matches any single 0-9, A-F, *, # or +; 'T' is a variable-length match of up to 32 digits; brackets define a range for one position; a leading '+' is a literal plus; '^' anchors the start of the string. Source: [Understand IOS and IOS XE Call Routing](https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html), Dial-Peer Wildcards table. Checked 2026-09-24.