Refer to the exhibit.
A call is received on a Cisco Unified Border Element gateway. The debug captures this SIP INVITE
message. Which configurations result in 915556781234 as the final called number?
A.
voice class uri 1 sip
host ipv4:10.41.11.10
!
voice class uri 2 sip
host ipv4:10.50.40.30
!
dial-peer voice 1 voip
incoming uri via 1
translation-profile incoming 1
!
dial-peer voice 2 voip
incoming uri via 2
translation-profile incoming 2
!
dial-peer voice 3 voip
incoming called-number +1T
translation-profile incoming 3
B.
voice class uri 1 sip
host dns:customer.com
voice class uri 2 sip
host ipv4:10.50.40.30
dial-peer voice 1 voip
incoming uri via 1
translation-profile incoming 1
dial-peer voice 2 voip
incoming uri via 2
translation-profile incoming 2
dial-peer voice 3 voip
incoming called-number +1T
translation-profile incoming 3
C.
voice class uri 1 sip
host ipv4:10.41.11.10
voice class uri 2 sip
host ipv4:10.50.40.30
dial-peer voice 1 voip
incoming called-number +1[2-9]..[2-9]……
translation-profile incoming 3
dial-peer voice 2 voip
incoming uri via 2
translation-profile incoming 2
dial-peer voice 3 voip
incoming called-number [2-9]..[2-9]……
translation-profile incoming 1
D.
voice class uri 1 sip
host dns:customer.com
voice class uri 2 sip
host ipv4:10.50.40.30
dial-peer voice 1 voip
incoming uri via 1
translation-profile incoming 1
dial-peer voice 2 voip
incoming uri via 2
translation-profile incoming 1
dial-peer voice 3 voip
incoming called-number +1T
translation-profile incoming 3
E.
voice class uri 1 sip
host ipv4:10.41.11.10
voice class uri 2 sip
host ipv4:10.50.40.30
voice class uri 3 sip
host dns:customer.com
dial-peer voice 1 voip
incoming uri via 1
translation-profile incoming 2
dial-peer voice 2 voip
incoming uri via 2
translation-profile incoming 1
dial-peer voice 3 voip
incoming uri via 3
incoming called-number +1T
translation-profile incoming 1
F.
voice class uri 1 sip
host ipv4:10.41.11.10
voice class uri 2 sip
host ipv4:10.50.40.30
voice class uri 3 sip
host dns:customer.com
dial-peer voice 1 voip
incoming uri via 1
translation-profile outgoing 3
dial-peer voice 2 voip
incoming uri via 2
translation-profile incoming 2
dial-peer voice 3 voip
incoming called-number +1T
translation-profile incoming 2
Why? Can anyone explain it?
If we suppose, the number is wrong in the INVITE line or in the question, and we have to replace only the prefix on it, we should use the translation profile no. 3. After that, we have to know the cube’s dial-peer incoming matching order for SIP call-legs:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/cube-dp.html#concept_1ACF9AAF93C24BB988E4A2EE3734C8A6
Preference for Dial-Peer Matching
The following is the order in which inbound dial-peer is matched for SIP call-legs:
voice class uri URI-class-identifier with incoming uri {via} URI-class-identifier
voice class uri URI-class-identifier with incoming uri {request} URI-class-identifier
voice class uri URI-class-identifier with incoming uri {to} URI-class-identifier
voice class uri URI-class-identifier with incoming uri {from} URI-class-identifier
incoming called-number DNIS-string
answer-address ANI-string
I this case, we have got about two options:
– the call matching to a dial-peer based on incoming URI, and apply tr profile 3 as incoming tr profile
– the call matching to a dial-peer based on incoming URI, what doing nothing, and after that matching an outgoing dial-peer, what translates the called party based on outgoing tr profile 3.
There are no other options, because every answer has a matching incoming URI hit.
IMHO it’s a wrong question.