Outgoing dial prefixes in Route Patterns not working

[dudecrush]

I've got Call Manager 9.1, and we're porting a number of our offices to a SIP Gateway/CUBE router that transfers the call to AT&T. I've encountered 1 particular problem that baffles me...

AT&T told us that 7 digit local calling now requires dialing 11 digits. I thought I'd work around that problem by creating route patterns that prefix with the area code. Problem is, they aren't prefixing and it's pushing out the internal DN as the calling number.

Some particulars:
> We have 40+ locations. To keep them straight, each location is assigned a 3-digit number. Example: 070 or 008
> All our internal DN's are 4 digits with a 3-digit prefix (the location number) to prevent number overlap
> We have translation patterns for those prefixes so we can inter-office call without LD calling

Here are my route patterns:

Local: 9.[2-9]XXXXXX
Nearly all settings default, except Route Partition and Gateway.
Called Party Transformation:
>Discard digits: PreDot
>Prefix digits - Outgoing calls: 1414

Global: 9.1[2-9]XX[2-9]XXXXXX
Identical settings to Local, but no outgoing prefix.

Global works like a champ, but local dies on the vine. For Example, this is the SIP debug output to 414-427-1206

GLOBAL:
Jan 21 15:17:32: //355174/5B97B9000000/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D92DDF0
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 4142907231 <--- [highlight #FCE94F]Number I called from[/highlight]
Called Number : 14144271206 <--- [highlight #729FCF]Number I called[/highlight]
Source IP Address (Sig ): 32.252.222.18
Destn SIP Req Addrort : 12.194.124.117:5060
Destn SIP Resp Addrort : 12.194.124.117:5060
Destination Name : 12.194.124.117


LOCAL:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D91BF28
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 0707231 <--- [highlight #FCE94F]This is the internal number we use in call manager[/highlight]
Called Number : 4271206 <--- [highlight #729FCF]Number I called; it didn't prefix a thing[/highlight]
Source IP Address (Sig ): 32.252.222.18
Destn SIP Req Addrort : 12.194.124.117:5060
Destn SIP Resp Addrort : 12.194.124.117:5060
Destination Name : 12.194.124.117

So two questions:
a) Why does the SIP GW know the full DID of the calling number when it goes out the global pattern, but uses the internal DN when making a local call?
b) Why does the local route pattern not prefix?

A theory on a): Since local calling is 7-digits, and the internal DN is 7-digits with the location prefix, I think the dialed number analyzer pushing the internal DN out the GW.

Any help is appreciated

 

[HmmG3]

I'm in the same process of migrating to AT&T IP Flex. As for your situation, are both route patterns going to the same route list? It's possible the route list for the global dialing pattern is doing the appropriate calling number modification (maybe using phone mask) while the local 7 digit dialing pattern does not. What I like to do is not bother with a 7 digit route pattern. Instead create a translation pattern. Have it match 9.[2-9]XXXXXX, do a pre-dot delete and prefix 91 followed by the area code for that location. This will then convert it into a long distance call and use the 9.1[2-9]XX[2-9]XXXXXX pattern. I'm not sure how your CSS and partitions are configured though, so you need to be careful in that the local translation pattern doesn't send the call to a wrong partition.

 

[dudecrush]

Yes - both route patterns are going out the same Route List. Since the call goes List > Hunt > Group, I just changed the route group. I added the SIP trunks as primary and secondary, then set the distribution algorithm to Top Down.

I have 2 translation patterns for each converted location to handle the inbound calls and internal calls, In the case of the location above, that translation patterns are:
Inbound calls from SIP trunk: 41429072[0-9]X.
Internal calls: 070#.

So what you're saying is create a new translation pattern for local dialing, or should I just modify the internal translation pattern?

Also - and I always seem to flip this around in my head - does the 91XXX dial prefix go in the Calling Party transformation or the Called Party transformation? I keep thinking I'm the Calling Party, so it would go there. However, I've had others tell me the Calling Party is who called us, so it's the Called Party fields that must be modified.

 

[HmmG3]

I'm still trying to wrap my head around how you may have some of the routing. Do you have dedicated partitions and calling search spaces for each office location? Regardless, the routing you have between offices should be kept completely alone as that works and is not involved with this part of the routing to AT&T. So I would delete the 9.[2-9]XXXXXX route pattern and create the translation pattern. The pre-dot delete and prefix of 91 plus area code is done under the called party transformation. Leave the calling party settings blank. This is for modifying the number shown who the call is from to AT&T. Since the global route pattern of 9 plus 11 digits is working and modifying the calling number correct, we'll utilize that.

Remember, called party modifies the destination number and could affect routing. Calling party is the CallerID and simply changes the way the other end of the call sees your number when you call them. I hope that helps explain the two.

 

[dudecrush]

No dedicated partitions. All of our DN's are in the NULL partition. That said, each location has it's own Calling Search Space.

Thanks for the explanation on called vs. calling.