matching dial-peers with e164 patterns

[tato386]

On my CUBE I have two outbound dial peers configured with different SIP session targets and using different e164 destination patterns. One dial-peer e164 is setup to match all 10 and 11 digit North American PSTN numbers and I would like the second to be used for specific numbers but it is acting kind of strange. As a test I added both 10 and 11 digit versions of a single PSTN number. My tests show that when I dial 10 digits it does not match the desired peer and the call goes out the generic peer. However, when I use 11 digits then it does match the number specific peer and pattern. Examples are below.

Any ideas?

voice class e164-pattern-map 400
description generic PSTN
e164 011T
e164 911
e164 1[2-9]..[2-9]......
e164 [4-5]11
e164 [2-9]..[2-9]......
!
voice class e164-pattern-map 450
description specific PSTN numbers
e164 15556667777 (calls using 11 digits match dial peer 450)
e164  5556667777 (calls using 10 digits match dial peer 400)

dial-peer voice 400 voip
description generic PSTN
session target ipv4:1.1.1.1
destination e164-pattern-map 400

dial-peer voice 450 voip
description specific PSTN numbers
session target ipv4:2.2.2.2
destination e164-pattern-map 450

[Celso Silva]

How is/are your incoming dial-peer(s) configured? Based on your test description you are hitting the dial-peer 0 (generic dial peer).

[tato386]

I also have this peer but I am not following your logic.  My issue is with outbound matching.  When I make calls and look at the activity I never see peer 999.  I see 400 and 450

dial-peer voice 999 voip
description catch-all incoming to CUBE
call-block translation-profile incoming Block-Incoming
call-block disconnect-cause incoming call-reject
session protocol sipv2
incoming called-number .%
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
no voice-class sip early-offer forced
dtmf-relay rtp-nte
no vad

[b.winter · Accepted solution]

Maybe you should post the output of both calls, one with 10 and one with 11 digits
e.g
debug voice ccapi ind 1
debug voice ccapi ind 2
debug voice ccapi ind 74

Are there any translation happening beforehand, so that the dial-peer maybe is not matching?

[tato386]

There aren't any translations, but the debugs gave some interesting results.  It looks like both the 10 and 11 digit called number match the correct dial peer (450) but in the case of 10 digit called number the call fails and the CUBE then tries the other matching dial peer (400).  Since the dial peers are configured to use different providers I am guessing the provider on the other end of dial-peer 450 is rejecting 10 digit calls.  I will contact them to investigate this possibility.

CUBE#
May 4 08:17:14.351: //-1/9921C6800001/CCAPI/cc_api_call_setup_ind_common:
Interface=0x7F5E29B31118, Call Info(
Calling Number=sip:3334445555@192.168.1.82,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=sip:5556667777@192.168.1.81:5060(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=999, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=1516865
May 4 08:17:14.353: //1516865/9921C6800001/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x7F5E29B31118, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=3334445555,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=5556667777(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=450, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
May 4 08:17:14.468: //1516865/9921C6800001/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x7F5E29B31118, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=3334445555,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=5556667777(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=400, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)

CUBE#
May 4 08:18:20.820: //-1/C07893800001/CCAPI/cc_api_call_setup_ind_common:
Interface=0x7F5E29B31118, Call Info(
Calling Number=sip:3334445555@192.168.1.82,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=sip:15556667777@192.168.1.81:5060(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=999, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=1516870
May 4 08:18:20.821: //1516870/C07893800001/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x7F5E29B31118, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=3334445555,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=15556667777(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=450, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)

[b.winter]

That's why you always need to check the logs ':)'
Maybe you can now check the call when "debug ccsip messages" is turned on. Maybe you see any error messages coming back from the first provider.

And you should also configure "huntstop" in your dial-peers, to prevent the call from being sent over a different dial-peer, if the call fails (of course only if you don't want this to happen).

[tato386]

I confirmed that the voice provider requires numbers to have country code prefix.  I am leaning towards adding this on the dial-peer vs CUCM.  Thoughts?

[Celso Silva]

I would add that on the CUBE.

[Roger Kallberg]

I would vote for in the gateway.

[b.winter]

Adding to the comments of @Roger Kallberg and @Celso Silva: My approach is doing it as close to the "source" as possible.
E.g. if a phone dials out, the globalization is already done on the first TP (or RP) that the dial pattern matches. Every decisions afterwards are done based on a globalized dialplan, and not based on a "user dialed" dialplan.

[Celso Silva]

Case Study: Understand Inbound Matching and Default Dial-Peer 0
https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/14074-in-dial-peer-match.html#anc36

“Every dial plan needs an outgoing and an inbound dial peer.”

before you try this config below (different approach for what you have) you can enable “debug ccsip messages”, test again and share the logs here… we may see dial-peer 0 match for your attempt to call using 10 digits… 

Attached below you will find a config example with a different approach… match incoming called numbers with inbound dial-peers and redirect using dial-peer groups to outbound dial-peers.