Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Outgoing dial prefixes in Route Patterns not working

Outgoing dial prefixes in Route Patterns not working

Outgoing dial prefixes in Route Patterns not working

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

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 <--- Number I called from
Called Number : 14144271206 <--- Number I called
Source IP Address (Sig ):
Destn SIP Req Addr:Port :
Destn SIP Resp Addr:Port :
Destination Name :

The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D91BF28
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 0707231 <--- This is the internal number we use in call manager
Called Number : 4271206 <--- Number I called; it didn't prefix a thing
Source IP Address (Sig ):
Destn SIP Req Addr:Port :
Destn SIP Resp Addr:Port :
Destination Name :

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

RE: Outgoing dial prefixes in Route Patterns not working

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.

RE: Outgoing dial prefixes in Route Patterns not working

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.

RE: Outgoing dial prefixes in Route Patterns not working

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.

RE: Outgoing dial prefixes in Route Patterns not working

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close