Outbound calls not routing on H.323 Gateway (POTS) - Dial Peer issue?

[dudecrush]

Call Manager 9.1. Gateway = H.323 (Cisco 2911); with 8 POTS lines

I'm reverting calls back to their original gateway, which I SWEAR I have not modified since January. The calls hit the GW, but then I get a busy signal. What's worse, is that the only dial-peer match that I see is for an INCOMING call - which makes no sense. Why would an outbound call match an incoming dial peer?

I ran the "debug voice ccapi inout" command on the GW, and this is my output. The calling number is 0737926, the called number is: 1XXX2352022. What am I not seeing?


073-Glendale#debug voice ccapi inout
voip ccapi inout debugging is on
073-Glendale#debug vpm signal
Voice Port Module signaling debugging is enabled
073-Glendale#term mon
073-Glendale#
Apr 11 16:02:04: //-1/803349A31A00/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=0737926
----- ccCallInfo IE subfields -----
cisco-ani=0737926
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=1XXX2352022
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

Apr 11 16:02:04: //-1/803349A31A00/CCAPI/cc_api_call_setup_ind_common:
Interface=0x226AF5BC, Call Info(
Calling Number=0737926,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=1XXX2352022(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=131, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=7281
Apr 11 16:02:04: //-1/803349A31A00/CCAPI/ccCheckClipClir:
In: Calling Number=0737926(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
Apr 11 16:02:04: //-1/803349A31A00/CCAPI/ccCheckClipClir:
Out: Calling Number=0737926(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 11 16:02:04: :cc_get_feature_vsa malloc success
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 11 16:02:04: cc_get_feature_vsa count is 1
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 11 16:02:04: :FEATURE_VSA attributes are: feature_name:0,feature_time:611628216,feature_id:7281
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/cc_api_call_setup_ind_common:
Set Up Event Sent;
Call Info(Calling Number=0737926(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=1XXX2352022(TON=Unknown, NPI=Unknown))
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/cc_process_call_setup_ind:
Event=0x3D730330
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 1XXX2352022
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/ccCallSetContext:
Context=0x3F2C05CC
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 7281 with tag 131 to app "_ManagedAppProcess_Default"
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:

Apr 11 16:02:04: : updating existing feature vsa
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:

Apr 11 16:02:04: feature call basic
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/ccCallDisconnect:
Cause Value=3, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/ccCallDisconnect:
Cause Value=3, Call Entry(Responsed=TRUE, Cause Value=3)
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/cc_api_get_transfer_info:
Transfer Number=NULL
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x226AF5BC, Tag=0x0, Call Id=7281,
Call Entry(Disconnect Cause=3, Voice Class Cause Code=0, Retry Count=0)
Apr 11 16:02:04: //7281/803349A31A00/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr 11 16:02:04: :cc_free_feature_vsa freeing 2474B4B0
Apr 11 16:02:04: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr 11 16:02:04: vsacount in free is 0
073-Glendale#no debug all
All possible debugging has been turned off

 

[gnrslash4life]

Is it connected to a PRI? If so run a debug q931 isdn.


Also, dont think of dial-peers in relation to the type of call. Think of them as how the direction of the call is going. For example: internal phone -> gw -> pstn. The first dial-peer it is going to hit is your "incoming" dial peer since its incoming to the gateway from the phone. Doesnt matter if that phone is the PSTN or internal. Unless you specify dial-peers more granular, a "generic" dial peer can be matched for any type of call.



Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

 

[dudecrush]

gnrslash4life

No - It's not connected to a PRI; it's simply 8 POTS lines.

I thought perhaps that the PSTN didn't like the fact that the out-calling number was 0737926. On the DN, I changed the mask on the phone to the full number. The outgoing number changed in the logs, but the call still didn't go.

I like what you said about dial-peers - the first dial-peer is "incoming" since it's incoming from the GW. As an old TDM-system admin, nothing underscores my frustrations with VoIP systems than a statement like that. In TDM, incoming and outgoing were exactly what you thought. I'm finding it quite difficult to unlearn TDM concepts and re-learn VoIP ones - they can be so dissimilar and quite often counter-intuitive - like telling me that up is now down. I make troubleshooting assumptions based on the logs, only to find out that I was wrong and they are saying something else. Even when I have training - even when I read Cisco docs - I still get it wrong. Grrr. Sorry - I'm whining....

So how should I look at the "call flow" DN > GW > Incoming Dial Peer > Outgoing Dial Peer > PSTN? Is that what I should be looking for in the logs? I was going to run a "show dialplan number" command and type in a 10-digit number to see what dial-peer it would hit.

 

[gnrslash4life]

Same debug command should work with POTS. Not 100% on that though. I also would do a sh voice port sum during the call just to see what port its hitting. I would also do a sh active voice call brief. That will show you your call legs and you can see what dial peers are being used.

My guess is the number isnt matching an outbound dial peer though.




Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

 

[dudecrush]

Digging into this further, I see that part of my problem is inconsistent GW configurations and implementations from previous admins. Each location was done in slightly different way.

I did a “stare and compare” outbound call output on a known, working H.323 GW and compared it to the non-working output. One thing I noticed:
a) The destination pattern on the working call was prefixed with a “9” on the GW
Working:
Calling Number=0076074,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=[highlight #FCE94F]9[/highlight]2352022(TON=Unknown, NPI=Unknown),

Not working:
Calling Number=0737926,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=16082352022(TON=Unknown, NPI=Unknown),

b) Some – but not all – of the outbound dial-peers on the working gateway contain the entry, “Prefix 9”. Example

Working GW:
Dial-peer voice 11 pots
Destination pattern 9T
Port 0/1/1
Prefix 9

Not working GW:
Dial-peer voice 11 pots
Destination pattern 19T
Port 0/1/1

Might the addition of “prefix 9” fix the issue?

 

[gnrslash4life]

Seems like it. Though the non working one is also looking for a 1 before the 9 which is interesting. Your working one says I expect to see a 9 followed by anything else. Strip the 9 before sending out.

Your non working one says I expect 19 and anything else before sending out. More than likely your telco does not want that.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

 

[dudecrush]

Glad you caught that, because that was my next question. In all the H.323 locations of this company, you'll see different destination patterns for the outbound dial peers. For example:

Dial-peer voice 12 pots
destination-pattern 9T
port 0/1/2
!
dial-peer voice 13 pots
destination-pattern 19T
port 0/1/3
!
dial-peer voice 20 pots
destination-pattern 29T
port 0/2/0
!
dial-peer voice 21 pots
destination-pattern 39T
port 0/2/1
!
dial-peer voice 22 pots
destination-pattern 49T
port 0/2/2
!
dial-peer voice 23 pots
destination-pattern 59T
port 0/2/3

And so on. I don't understand why you would have a destination pattern of "39T" or "49T". Why would you increment the "T" patterns by 10 like that? To me, all of those should say "destination-pattern 9T" UNLESS you didn't want calls going out those voice ports.

Also - I'm not understanding the way they've matched voice-translation rules to profiles:
voice translation-rule 13
rule 1 /^9/ /19/
!
voice translation-rule 20
rule 1 /^9/ /29/
!
voice translation-rule 21
rule 1 /^9/ /39/

voice translation-profile 13
translate called 13
!
voice translation-profile 20
translate called 20
!
voice translation-profile 21
translate called 21

The way I understand translation rules, you have a match string and a replace string. Why would you want to match anything beginning with /^9/ and replace with /19/, for example? If I have an outbound call to 9,4145551212, I'll get 194145551212. That makes no sense.

 

[gnrslash4life]

Honestly, without seeing the whole thing its really hard to say.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

 

[dudecrush]

Well - I had to cry "uncle" on this one and call a Cisco TAC. The problem was the GW's inability to match inbound dial-peers with outbound ones. We fixed it by doing the following:

a) Modified the POTS dial peers. At first, I modified the POTS dial peers with destination pattern [0,1-9]T. This fixed outbound calling but broke inbound(calls were looping). Later, the TAC told me that using a "T" in your dial peers is bad practice unless they are international calls. For each of my POTS ports, we re-wrote the destination patterns to reflect local, LD and 911 calls. I did not know that you could write more than one destination pattern per dial-peer.

dial-peer voice 11 pots
destination-pattern 1[2-9]..[2-9]......
port 0/1/1

dial-peer voice 12 pots
destination-pattern [2-9]......
port 0/1/1

dial-peer voice 13 pots
destination-pattern 911
port 0/1/1

I did run into the fact that the POTS dial peers cannot have the same number as a VoIP dial-peer. Something to think about in the future.

b) To fix 911 calling, the TAC had written this generic dial-peer:
dial-peer voice 911 voip
incoming called-number 911
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad

It's amazing to me how an identical GW config works on one router but not another.

 

[gnrslash4life]

In my experience I see a lot of 9T patterns. I personally never use them and do what Cisco told you to do. As far as the one GW working and the other not. I bet there is a difference that you just arent seeing.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS