I have an odd issue. 10-digit dialing was working fine for a site with a PRI, but I noticed that there was no 10D dial-peer anywhere on the gateway.
I verified that we were sending the 10D DNIS to the gateway both by manually going through the call patch in CUCM step by step and by using DNA to verify.
Next I moved to the gateway where I could see the call come in from the phone with a 10D destination and the call would complete.
Finally, I turned on debugs and this is what is happing. For some reason, even with a 10D destination, it's matching the 7D dial-peer.
Can anyone explain to me why it would be doing this?
I've added the debug and the dial-peer below. The only change I've made are to maskthe IP of the phone and the 10 digits that were being dialed.
*Sep 25 20:44:51.558: //866029/BC5473000002/CCAPI/ccCallSetupRequest:
Calling Number=sip:7888@<phone IP>(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=5556667777(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=7888, Final Destination Flag=TRUE,
Guid=BC547300-0001-0000-0002-67276507630A, Outgoing Dial-peer=9001
dial-peer voice 9001 pots
Asper the dialpeer it matched your first 7 digits.
what’s ur 10 digit dial peer ?
Use more precise dial peer. If number starting 5 is not a part of 7 digit dialling remove it from 7 digit dialpeer. When u mentioned 2-9 it says any number beginning from 2-9. use $ at the end of dial string.
That isn't the way I would have made the dial peer if I had set it up (and I would have had a 10D dial peer in the config as well). It's not a question of how to fix the issue, but a question of "why was 10D getting matched to a 7D dial-peer in the absence of a 10D dial-peer?"
It gets the calls enblock, so it receives all 10 digits at the same time. There should be no way for it to match the 7D dial-peer in that case.
A 7 digit dial peer matches the first 7 digits of the dialed number, not just 7 digit extensions. Since you mention there is no 10 digit dial peer on your gateway, the gateway will look for the best match from the dialed digits to your dial peers. In this case, that is your 7 digit dial peer. If you had an 8 digit dial peer that matched more numbers than your 7 digit then the 8 digit dial peer would be chosen.
I usually do (I didn't set up this gateway) but that still doesn't make sense to me. It's receiving the call via SIP, so it's getting the number enblock, not digit-by-digit once CUCM determines that the dialed number matches the CUCM dial-pattern that sends it to the gateway. So it shouldn't be able to match the first 7 when it's given all 10 at the same time.
As Andrew wrote it will match on the first 7 digits in the number, irrespective of en-block or overlap reception of the number. That’s how the dial string match operate in IOS.
Something else I didn't know. Does this mean if everything in enbloc you don't need a terminating "T" in the destination pattern?
As T mean that you would not know how long the dialled number would be it’s not directly related to this I would say.