Source record · tier 2 current vendor documentation
Understand IOS and IOS XE Call Routing
- Publisher
- Cisco Systems
- URL
- 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
- Published
- 2026-04-28
- Updated
- unknown
- Accessed
- 2026-09-24
- HTTP status
- 200
- License
- Cisco copyright; all rights reserved; no-redistribution; short excerpts and locators only
Source notes citing this source
- 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. in context
- 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 in context
- 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. in context
- 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 in context
- 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. in context
- The default dial-peer hunt scheme is 0: longest match in phone number, then explicit preference, then random selection. in context
- 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. in context
- 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. in context
- 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. in context
- 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. in context
- 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 in context
- 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. in context
- 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 in context
- 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). in context
- 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. in context
- 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. in context
- 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. in context
- 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. in context
- Binding each CUBE inbound dial-peer to a dial-peer group that excludes the trunk the call arrived on is a way to stop a carrier-to-CUBE call from being routed back out to the same carrier. inferred in context
- On Cisco IOS and IOS XE gateways, dial-peer groups can pin the exact outbound dial-peer according to the inbound dial-peer that matched, which constrains where a call received on a trunk can be sent. in context
- Cisco's IOS/IOS XE call-routing technote uses debug voip ccapi inout and debug ccsip messages to see dial-peer matching and SIP signalling for a call. in context
Cite this source record
APA
WarmTransfer. (2026, April 28). Understand IOS and IOS XE Call Routing. WarmTransfer. https://warmtransfer.net/knowledge/sources/cisco-technote-211306-ios-call-routing
BibTeX
@misc{warmtransfer-cisco-technote-211306-ios-call-routing,
title = {Understand IOS and IOS XE Call Routing},
author = {{WarmTransfer}},
year = {2026},
url = {https://warmtransfer.net/knowledge/sources/cisco-technote-211306-ios-call-routing},
note = {Cisco Systems, accessed 2026-09-24}
}