no dice..shown below is the DNA result

Calling Party Information
Calling Party = 1001
Partition =
Device CSS =
Line CSS = Test CSS
AAR Group Name =
AAR CSS =
Dialed Digits = 911112223333
Match Result = BlockThisPattern
Route Block Cause = Unallocated Number
Called Party Number =
Matched Pattern Information
Pattern =
Partition =
Pattern Type =
Time Zone =
Outside Dial Tone = NO
Call Flow
TranslationPattern :Pattern=
Partition =
Positional Match List =
Calling Party Number = 1001
PreTransform Calling Party Number =
PreTransform Called Party Number =
Calling Party Transformations
External Phone Number Mask = NO
Calling Party Mask =
Prefix =
CallingLineId Presentation =
CallingName Presentation =
Calling Party Number = 1001
ConnectedParty Transformations
ConnectedLineId Presentation =
ConnectedName Presentation =
Called Party Transformations
Called Party Mask =
Discard Digits Instruction =
Prefix =
Called Number =
Alternate Matches
Note: Information Not Available

The call is not even routed, so we need to fix why is it being blocked. Check this line:

Match Result = BlockThisPattern

It seems like you are calling from an IP Phone, but there is no such route pattern
911112223333, or you dialed it incorrectly:

Route Block Cause = Unallocated Number

Or the Calling Search Space assigned to the line doesn't contain the partition where the route pattern is:

Line CSS = Test CSS

Could you please verify what is the calling device?

will do...I'll provide feedback soon

The calling device is an IP phone with ext 1001. DNA is now showing the correct CSS and the correct calling number 001 222 333 4444. The call however is not hitting the voice gateway. debug isdn q931 is not showing the call coming through.

I don't know if this helps but the CUCM server is in europe and we are trying to make life easier for users calling the US i.e. instead of dialing 9001 222 333 4444 they can just dial the local US number. i.e. 222 333 4444...a route pattern should handle the number manipulation....discarding the 9 and prefixing the 00

Yes your commitment towards the end users sounds correct, however last time the call was being blocked right within CUCM. Could you please run another DNA analysis attach it?

One more thing, how many servers are there in the cluster?

Calling Party Information
Calling Party = 1111
Partition =
Device CSS =
Line CSS = Phone VPN CSS
AAR Group Name =
AAR CSS =
Dialed Digits = 912223334444
Match Result = RouteThisPattern
Matched Pattern Information
Pattern = 9.1XXXXXXXXXX
Partition = Phone_VPN
Time Schedule = All the time
Called Party Number = 0012223334444
Time Zone = America/New_York
End Device = RL_PSTN
Call Classification = OffNet
InterDigit Timeout = NO
Device Override = Disabled
Outside Dial Tone = NO
Call Flow
TranslationPattern :Pattern=
Partition =
Positional Match List = 12223334444
Calling Party Number = 1111
PreTransform Calling Party Number =
PreTransform Called Party Number =
Calling Party Transformations
External Phone Number Mask = NO
Calling Party Mask =
Prefix =
CallingLineId Presentation =
CallingName Presentation =
Calling Party Number = 1111
ConnectedParty Transformations
ConnectedLineId Presentation =
ConnectedName Presentation =
Called Party Transformations
Called Party Mask =
Discard Digits Instruction =
Prefix =
Called Number =
Route Pattern :Pattern= 9.1XXXXXXXXXX
Positional Match List = 12223334444
DialPlan =
Route Filter
Filter Name =
Filter Clause =
Require Forced Authorization Code = No
Authorization Level = 0
Require Client Matter Code = No
Call Classification =
PreTransform Calling Party Number = 1111
PreTransform Called Party Number = 912223334444
Calling Party Transformations
External Phone Number Mask = NO
Calling Party Mask =
Prefix =
CallingLineId Presentation = Allowed
CallingName Presentation = Allowed
Calling Party Number = 1111
ConnectedParty Transformations
ConnectedLineId Presentation = Default
ConnectedName Presentation = Default
Called Party Transformations
Called Party Mask =
Discard Digits Instruction = PreDot
Prefix = 00
Called Number = 0012223334444
Route List :Route List Name= RL_PSTN
RouteGroup :RouteGroup Name= RG_PSTN
PreTransform Calling Party Number = 1111
PreTransform Called Party Number = 912223334444
Calling Party Transformations
External Phone Number Mask = Default
Calling Party Mask =
Prefix =
Calling Party Number = 1111
Called Party Transformations
Called Party Mask =
Discard Digits Instructions =
Prefix =
Called Number = 912223334444
Device :Type= H323Gateway
End Device Name = 10.10.10.5
PortNumber = 0
Device Status = UnKnown
AAR Group Name =
AAR Calling Search Space =
AAR Prefix Digits =
Inbound Fast Start = Disabled
Outbound Fast Start = Disabled
Call Classification = Use System Default
Tunneled Protocol = None
Calling Party Transformations
PreTransform Calling Party Number = 1111
Calling Party Selection = Originator
Calling Party Presentation = Default
CallerID DN =
Calling Party Number = 1111
Alternate Matches
Note: Information Not Available

2 servers in the cluster. pub and sub

Ok now it looks like the system will route the call from ANI 1111 to DNIS 912223334444, and will send it to 10.10.10.5. Is that the ip address you would like to talk to?

I asked about the number of servers so you can  try the same DNA analysis from the other server. So if you navigated to http://pubIP/dna, and tested from there, try http://subIP/dna instead and determine if from the subscriber the routing is not working.

The DNA result posted above is from the sub. I tried the same DNA from Pub and got the same result. however...when I try in on the phone i get "the call cannot be completed as dialed". debug isdn q931 does not show the call...

Please log in through SSH to the server where the phone is registered, and generate a packet capture file:

utils network capture eth0 count 100000000000 size all file h323

Then reproduce the call until you get the annunciator message. Cancel the packet capture with CTRL-C and retrieve the file as instructed here:

https://supportforums.cisco.com/docs/DOC-11599

I'll do this tomorrow

capture attached. rename to .rar and extract.cab file
h323.doc

I am sorry, Im getting "Unexpected end of archive" when extracting... Being there many times for some reason EE attachment tool breaks packet captures. Can you post it at www.cloudshark.org please?

http://www.cloudshark.org/captures/95cf399a19a6

Well my friend, you are actually sending this

----> Calling party number: '5597' ---->
----> Called party number: '0011112223333'---->

<---- Cause value: Unallocated (unassigned) number  <----

You can't see the debug isdn because your router is probably not configured to match anything with destination-pattern 0011112223333 to be routed out the PRI.

Now, didn't you configured somewhere to send 912223334444  in CallManager? Where was it exactly?

The number 222-333-4444 was just a sample number I used to post the question here and should still match 9.1XXXXXXXXXX# route pattern. The goal was to at least see the call hit the voice gateway.

The "real" test number I am using is 18882378289...shouldn't this number still match the 9.1XXXXXXXXXX# route pattern?

Your call is hitting the gateway allright. There is a releaseComplete message coming back from IP 172.100.4.5.

As far as I remember you are trying to debug if your call hits the router by means of a debug isdn q931.

This is not going to show the attempt because the router can't even route 0011112223333 (based on your last post). Once you correctly configure a dial peer to route out through a ISDN circuit, then you will be able to see the output in the debug.

Now if you dial 9 18882378289, you should also match the route pattern. Why don't you repeat the packet capture while dialing the real number and upload to cloudshark? We may discover a misconfiguration in the gateway instead.

q:

I assume the route pattern you suggested should match any US and Canadian number. Correct?

will send another packet capture shortly.

any US and Canadian number dialed from another country yes, pretty much.

not sure what happened but 2 captures this time

http://www.cloudshark.org/captures/1327667d0960

http://www.cloudshark.org/captures/995ba1423ad8

Were you going to capture the call to the real number? I only see a H323 call to the test number.

yes. you should see 18882378289 in the capture

http://www.cloudshark.org/captures/1327667d0960 has no h225 packets

http://www.cloudshark.org/captures/1327667d0960 has 2 packets showing a call to 0011112223333

Maybe you want to take a DNA analysis of a call to 18882378289 and make sure its being routed out.

http://www.cloudshark.org/captures/6c83fc81ffd7

http://www.cloudshark.org/captures/e0bcc0b05657

http://www.cloudshark.org/captures/06eb5e80d2f6

http://www.cloudshark.org/captures/6c83fc81ffd7 -> called party number: '159257121'
http://www.cloudshark.org/captures/e0bcc0b05657 -> Called party number: '0011112223333'
http://www.cloudshark.org/captures/06eb5e80d2f6 -> nothing

Am getting "block this pattern" from DNA. can you walk me through the steps from scratch

Sure thing. Lets start with defining the number you would like to call outside of your network. What is that number?

1-888-237-8289

any US or NANP number

Ok so lets start simple. Please create a test Route Pattern as **918882378289, this way we assure nobody else will dial it by mistake. Then associate it with a Route List where your H.323 gateway will be listed. Finally take a DNA from an IP Phone when dialing **918882378289

DNA looks better
3-23-2012-6-32-36-PM.jpg

Ok now, from the DNA, make sure the selected device is indeed the IP address of the H.323 gateway required.

Once that is done, go to your Route Pattern **918882378289, and modify it to this:

**9.18882378289, and then add a discard digit instruction of Predot.

Go to your gateway and created the following dial-peer:

dial-peer voice 99099 pots
  destination-pattern 18882378289
  no digit-strip
  port 0/0/0 => your ISDN voice port

Now try a call while debug voip ccapi inout and debug isdn q931 are enabled with the term mon command.

I get the annunciator when I dial 918882378289 and nothing shows up on the router even with both debug voip ccapi inout & debug isdn q931 enabled.
3-26-2012-8-28-08-PM.jpg
3-26-2012-8-32-37-PM.jpg
3-26-2012-8-33-39-PM.jpg
3-26-2012-8-35-38-PM.jpg

Remember you need to dial the stars in order to hit the route pattern. Please dial the whole string while debugging:

**918882378289

the digits are manipulated as expected...when I dial **918882378289 it shows  0018882378289 on the phone display which is what we expect but I still get the annunciator saying the call cannot be completed as dialed.

does it matter that this CUCM is configured for UKNP (United Kingdom Numbering Plan) and not the NANP (North American Numbering Plan).

No.

 Remember I told you to configure a dialpeer as follows:

dial-peer voice 99099 pots
  destination-pattern 18882378289
  no digit-strip
  port 0/0/0 => your ISDN voice port

Now I realize you did some extra manipulations of your own. No worries, the matching dialpeer should be as follows based on your last posts:

dial-peer voice 99099 pots
  destination-pattern 0018882378289
  no digit-strip
  port 0/0/0 => your ISDN voice port

Please debug isdn q931  a call to **918882378289 once you make the changes in the IOS

that worked. Call hits the router and then exits via the ISDN voice port

Ok now adjust the route pattern to the way your users dial US Numbers from the IPP hones. Something like 9.001[2-9]XX[2-9]XXXXXX and remove any other called party transformation you may have. The idea is to send 001 + 10 digits to the gw and hit the dial peer. The destination pattern may now be:

destination-pattern 001..........

just to make sure am clear:

route pattern should be: 9.001[2-9]XX[2-9]XXXXXX and remove the predot and prefix digits of 00

then the destination pattern on the dial-peer should be destination-pattern 001..........?

finally...I have 2 ISDN voice ports "port 0/0/0:15" & "port 0/0/1:15". does this mean I need 2 dial-peers?

To your first question, why would you prefix 00 if the users already dial 00? Once the route pattern is matched by dialing 00 we wouldn't need another set of ceros rights?

And finally, yes, you would need 2 dial-peers configured with different voice ports. That will make the system load balance between them

Users won't be dialing 00. They will dial 9 + 1 + number i.e 9 + 1 + 8882378289 and cucm should translate 9 + 1 + number to 001 + number or in our case here - 0018882378289.

Then in that case yes, the Route Pattern should be changed to 9.18882378289 and appended with 00 after the predot digit strip

Immediately I change the pattern to 9.1xxxxxxxxxx to call does not complete.

Give me a DNA out of one of those calls please. And also a

debug isdn q931
debug voip ccapi inout
term mon

when you dial the call from an ip phone

It is working now...here is the working configuration :

route pattern:

9.1XXXXXXXXXX

discard predot
prefix 00

Dial peer on gateway:

dial-peer voice 6001 pots
 destination-pattern 001T
 port 0/0/0:15
 forward-digits all

awesome... are you all set then?

yes. thanks for all your help

Glad I could help.