cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1526
Views
0
Helpful
2
Replies

10 digit dialing not working as expected

Wayne Ficklin
Level 1
Level 1

Below you'll find the simplest form I can come up with for representing my Calling Search Space & Route/Translation Patterns.  My thought process for this is as follows.  If a call comes in to a phone registered to CUCM, we want to match that (All-IP-Phones).  We're transitioning from 7 digit numbers to 10-digit numbers, so there's a translation pattern that takes a call placed to 7 digit number and tries it w/ the area code pre-pended ...and check for that number registered to CUCM (10-digit-864-translate-864-SIP).  We check for int'l calls (SIP864-Intl), and 911 (SIP864-911)*.  I have partitions in place I'm not using (SIP864-1803 & SIP864-1864) ...and probably should remove.  Our voicemail (currently Asterisk) pilot number begins with 555 so we funnel all those calls down the appropriate SIP trunk (SIP864-555).  For Long distance calls (1.@) they're matched in SIP864-LD. 

The problem comes in here.  I've specified a route pattern that should match 10 digit calls w/ XXXXXXXXXX in the SIP864-10-Digits** partition.  (These last two partitions/route patterns direct calls out our sip trunk un-molested.)

The final route patterns are in the SIP864 partition.  We allow per-call caller-id blocking with the *67 route patterns.  I also have a pattern that should match 7 digits (XXXXXXX) and @ ...which should match anything else, though I've tried to build the CSS so that the @ won't be used.  On these last two patterns, we prepend the area code (864) so that we can direct calls out our SIP trunk (which requires 10 digits).

 

What is happening is a user calls a number w/ 10 digits, it hits the @ pattern in SIP864 (instead of the XXXXXXXXXX in SIP864-10-Digits) and strips off the intended area code and replaces it with 864 ...and the call fails. 

I get that @ is a list of patterns, ...and apparently one of them is more specific than my 10 xes pattern above.  How can I make it so that users are able to dial 10 digits or 11 digits for long distance, while maintaining the ability to dial 7 digits in-area-code?

 

 

Route Partitions in order, with route patterns (except the translation pattern specified):

All-IP-Phones
    -- all phones registered to CUCM
10-digit-864-translate-864-SIP
    (translation pattern)656XXXX ---> 864656XXXX
SIP864-Intl
    0114[0-469]!
    011.XXXXXXXXXXXX
SIP864-911
    9.911
    911
SIP864-1803
SIP864-1864
SIP864-555
    555XXXX
SIP864-LD
    1.@
SIP864-10-Digits
    XXXXXXXXXX
SIP864
    864.XXXXXXX
    *67.1XXXXXXXXXX
    XXXXXXX
    *67.XXXXXXX
    *67.XXXXXXXXXX
    @

 

 

*Should probably be bumped up ...at least above the Int'l calls.

**This pattern can probably be placed in the SIP864-LD partition, but its broken out now.

2 Replies 2

Wayne Ficklin
Level 1
Level 1

In diving a little deeper into the @ route pattern wild card, I came to a discussion on route filters.  My testing indicates this isn't the solution, but to report my "progress", I'll include it.

 

I've created a route filter whose clause states:

AREA-CODE DOES-NOT-EXIST AND OFFICE-CODE EXISTS AND SUBSCRIBER EXISTS

 

My thinking is that I apply THAT route filter to the @ route pattern, whichever actual pattern WAS being matched for 10-digit calls will no longer be allowed.

 

In practice, this doesn't work, as the @ pattern is still matched.

Just for giggles, I wanted to see if removing the @ would make it work as expected (since I DO have a 7xes route pattern ...which is all I'd intended to use the @ for anyway).  I also tweaked the 7 & 10 digit patterns to [2-9]XXXXXX and [2-9]XX[2-9]XXXXXX.

 

It works like I want it to.  I'm a bit nervous to remove the @ permanently from my CSS, but I've set up a copy of this CSS for testing to see if I run into problems without it.