10-30-2013 09:11 PM - edited 03-16-2019 08:10 PM
I have an odd issue. When my CCM Group has only my Sub in it, inbound PRI calls through the H323 PRI gateway work fine. If I remove the Sub and only put the Pub in the CCM group and reset everything, all of my phones register to the Pub, etc but inbound PRI calls are dropped. According to the debugs on the gateway, they are dropped with a reason code 38 "network out of order". Typically this means that you have a network issue between your GW and CUCM server. But the Pub and Sub are 1 IP off from each other in the same subnet, same VLAN, and same switch blade. The gateway is in the same subnet, VLAN, and switch blade as the Call Managers. So when they communicate, it's not leaving the blade and it's not even really routing. Pings from the GW to the Pub look good. Database replication between the Pub and Sub check out so it's not a weird database issue.
If I move everything back to the Sub the gateway starts working again. I have H323 bound to the interface on the gateway (and again, it works every time if the sub is the CUCM server listed in the CUCM group).
Unlike with MGCP, there aren't really any H323 commands that I can think of that would bind the GW to one CUCM but not another the way MGCP would.
Anyone have any ideas?
Solved! Go to Solution.
10-31-2013 06:27 AM
I would make sure the pub is in your Call Manager group that the Device Pool is using. I also noticed in your config the following -
interface GigabitEthernet0/0
description TO LAN
ip address
duplex auto
speed auto
h323-gateway voip bind srcaddr
Is you Gig interface matching the IP of the CUCM sub?
Thanks,
Tony
Please rate helpful posts!
10-30-2013 09:19 PM
On your H323 gateway, do you have dial-peers that point to both call managers, but with different preferences?
also, your H323 gateway configuration on the call manager, does it have a device pool, that has a call manager group with both servers?
=============================
Please remember to rate useful posts, by clicking on the stars below.
=============================
10-30-2013 09:44 PM
On the gateway, the Dialpeer to the Sub has no preference configured but the dialpeer to the Pub is preference 1
On the CUCM, normally the device pool that is being used by the gateway has Sub then Pub, but since I noticed this issue and have been troubleshooting I've only been placing either the Sub OR the Pub in the CCM Group used by the gateway's device pool (and then resetting everything to make the CCM Group changes take effect).
10-31-2013 03:21 AM
Have you tried doing a shut on the dialpeer to the sub and route inbound calls only to your pub?
Sent from Cisco Technical Support Android App
10-31-2013 05:20 AM
I just gave that a shot both ways and calls were dropped regardless of whether only the pub dialpeer was up or only the sub dialpeer was up.
10-31-2013 05:25 AM
Here is a copy of the router config:
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PRI-GW
!
boot-start-marker
boot-end-marker
!
!
card type t1 0 0
logging buffered 51200 warnings
!
no aaa new-model
network-clock-participate wic 0
network-clock-select 1 T1 0/0/0
network-clock-select 2 T1 0/0/1
!
ip cef
!
!
!
!
!
ip domain name yourdomain.com
no ipv6 cef
multilink bundle-name authenticated
!
!
!
!
isdn switch-type primary-ni
!
!
voice-card 0
!
!
!
voice service voip
no ip address trusted authenticate
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
voice class h323 1
h225 timeout tcp establish 3
!
!
!
!
voice translation-rule 1
rule 1 /55555\(.....\)/ /\1/
!
!
voice translation-profile STRIP
translate called 1
!
!
!
hw-module pvdm 0/0
!
!
!
!
redundancy
!
!
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24
!
controller T1 0/0/1
cablelength long 0db
pri-group timeslots 1-24
!
!
!
!
!
interface Embedded-Service-Engine0/0
no ip address
shutdown
!
interface GigabitEthernet0/0
description TO LAN
ip address
duplex auto
speed auto
h323-gateway voip bind srcaddr
!
interface GigabitEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface GigabitEthernet0/2
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn outgoing display-ie
no cdp enable
!
interface Serial0/0/1:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn outgoing display-ie
no cdp enable
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0
!
!
!
!
control-plane
!
!
voice-port 0/0/0:23
translation-profile incoming STRIP
!
voice-port 0/1/0
!
voice-port 0/1/1
!
voice-port 0/0/1:23
translation-profile incoming STRIP
!
!
!
!
!
!
mgcp profile default
!
!
dial-peer voice 1 pots
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 2 pots
incoming called-number .
direct-inward-dial
port 0/0/1:23
!
dial-peer voice 3 pots
destination-pattern 911
no digit-strip
port 0/0/0:23
!
dial-peer voice 4 pots
destination-pattern 9911
port 0/0/0:23
prefix 911
!
dial-peer voice 7 pots
destination-pattern 9[2-9]......
port 0/0/0:23
!
dial-peer voice 8 pots
destination-pattern 9[2-9]......
port 0/0/1:23
!
dial-peer voice 9 pots
destination-pattern 9405[2-9]......
port 0/0/0:23
prefix 405
!
dial-peer voice 10 pots
destination-pattern 9405[2-9]......
port 0/0/1:23
prefix 405
!
dial-peer voice 11 pots
destination-pattern 91[2-9]..[2-9]......
port 0/0/0:23
prefix 1
!
dial-peer voice 12 pots
destination-pattern 91[2-9]..[2-9]......
port 0/0/1:23
prefix 1
!
dial-peer voice 13 pots
destination-pattern 9011T
port 0/0/0:23
prefix 011
!
dial-peer voice 14 pots
destination-pattern 9011T
port 0/0/1:23
prefix 011
!
dial-peer voice 100 voip
preference 1
destination-pattern ....
session target ipv4:
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad
!
dial-peer voice 101 voip
destination-pattern ....
session target ipv4:
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad
!
dial-peer voice 5 pots
destination-pattern 911
no digit-strip
port 0/0/1:23
!
dial-peer voice 6 pots
destination-pattern 9911
port 0/0/1:23
prefix 911
!
!
!
!
gatekeeper
shutdown
!
!
!
line con 0
login local
line aux 0
line 2
no activation-character
no exec
transport preferred none
transport input all
transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
stopbits 1
line vty 0 4
privilege level 15
login local
transport input telnet ssh
line vty 5 15
privilege level 15
login local
transport input telnet ssh
!
scheduler allocate 20000 1000
!
end
10-31-2013 06:27 AM
I would make sure the pub is in your Call Manager group that the Device Pool is using. I also noticed in your config the following -
interface GigabitEthernet0/0
description TO LAN
ip address
duplex auto
speed auto
h323-gateway voip bind srcaddr
Is you Gig interface matching the IP of the CUCM sub?
Thanks,
Tony
Please rate helpful posts!
10-31-2013 06:37 AM
At the moment, the Pub isn't in the CUCM Group used by the device pool that is assigned to the GW because of the possiblity of something accidentally registering to it while it's having issues. The Sub is the only device in the CCM Group since the gateway works when that is the case.
However, when I've been doing my call testing I make the Pub the only call manager in the CCM Group (and reset the GW in CUCM).
On the question above, the config is:
interface GigabitEthernet0/0
description TO LAN
ip address 10.200.24.2 255.255.248.0
duplex auto
speed auto
h323-gateway voip bind srcaddr 10.200.24.2
The IP of the Pub and Sub are 10.200.24.10 /21 and 10.200.24.11 /21 respectively.
10-31-2013 06:45 AM
Just to rule everything out, I would create a test CM group containing just the pub. Then a test device pool using the Test CM group and assign it to your phone, resetting your phone so it registers with the Pub. Then make a coupe of test calls to your phone via the PSTN--H.323 Gateway and H.323 Gateway---PSTN to see if the call continues to fail both ways or not.
Thanks,
Tony
Please rate helpful posts!
10-31-2013 06:49 AM
I can give that a shot tonight. I can't take down their PRI during the day.
That's basically what I've been doing to test it, though I've only been testing inbound calling from the PSTN to the gateway. If the Sub is the only CUCM in the group, everything works great. If the Pub is the only CUCM in the group, inbound calling fails with a code 38. The database issues are most likely the cause, but I would normally expect the Pub to be good and the Sub to be bad in those cases, not the other way around.
10-31-2013 06:54 AM
That wont take down thier PRI. To check your DB status as someone previously stated I would go into the CM Unified Reporting and generate a new Unified CM database status and make sure the database count is the same across the board and the replicate state is "2" (good) across all servers in your cluster. Let us Know!!
Thanks,
Tony
Please rate helpful posts!
10-31-2013 06:56 AM
Sorry, just re-read that. I thought you wanted the GW in that group as well. I will test this and get back with you.
10-31-2013 05:51 AM
I can see the call come into the GW and it looks good until it decides to hand off the call to CUCM. It's almost as if, when the Pub is the CUCM that the GW is registered to in the CUCM config, the Pub doesn't have the GW in its database and thus refuses the H323 connections but that, when the Sub is the CUCM the GW registers to (in CUCM), the Sub has it in its database and accepts the TCP connections.
I've double-checked though and CUCM database replication is all good. Plus a database problem would most likely have the reversed effect where the Pub is good and the Sub is bad.
I still think the problem lies with CUCM somewhere.
Also, while it really doesn't matter with this, I thought I'd point out that everything is in the default region since we have no need to use anything but G711.
10-31-2013 06:08 AM
Hi ,
what is CUCM version u are using?
can us still output of command utils dbreplication runtimestate or from Cisco unified reporting?
regds,
aman
10-31-2013 06:24 AM
I'm running 9.1.1.20000-5
I had simply been using "utils dbreplication status" to check replication. When I ran the runtimestate command you recommended I saw some errors such as the one below.
---------- Suspect Replication Summary ----------
For table: ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_9_certificate
replication is suspect for node(s):
g_cucm_sub_ccm9_1_1_20000_5
For table: ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_104_certificateservicecertificatemap
replication is suspect for node(s):
g_cucm_sub_ccm9_1_1_20000_5
For table: ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_176_certificatehashmap
options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 - 20 of 6274) :
replication is suspect for node(s):
g_cucm_sub_ccm9_1_1_20000_5
For table: ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_403_certificatetrustrolemap
replication is suspect for node(s):
g_cucm_sub_ccm9_1_1_20000_5
For table: ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_232_certificateprocessnodemap
replication is suspect for node(s):
g_cucm_sub_ccm9_1_1_20000_5
For table: ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_243_replicationdynamic
replication is suspect for node(s):
g_cucm_sub_ccm9_1_1_20000_5
------------------------------------
I also saw errors like this:
Oct 30 2013 22:35:52 ------ Table scan for ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_403_certificatetrustrolemap start --------
row missing on
key:pkid:084184d3-1877-4f1d-9e33-9748f883bd8f
------------------------------------------------------------------
extra row on target
key:pkid:09af75ea-7ced-45a7-a427-c6ac0a3b6e31
options: q=quit, n=next, p=prev, b=begin, e=end (lines 3101 - 3120 of 6274) :
------------------------------------------------------------------
row missing on
key:pkid:4f89a54c-e889-4335-bb5a-e1c7511392b5
------------------------------------------------------------------
row missing on
key:pkid:5d5a8e7c-f8e6-46db-8781-31a5ca91c947
------------------------------------------------------------------
extra row on target
key:pkid:792ef466-2c9c-45ff-a0fc-aab3b24b134c
------------------------------------------------------------------
row missing on
key:pkid:92f316ee-c6dc-484d-9469-c8a4b5f07fbc
------------------------------------------------------------------
row missing on
key:pkid:9e4ae133-51c8-42cd-8436-9f696797f981
------------------------------------------------------------------
extra row on target
key:pkid:a1d8e318-9b14-454b-8390-1a047fc10973
------------------------------------------------------------------
row missing on
options: q=quit, n=next, p=prev, b=begin, e=end (lines 3121 - 3140 of 6274) :
key:pkid:a3874505-c3c4-4033-8657-fd7bbe110a63
------------------------------------------------------------------
extra row on target
key:pkid:cdf3ed09-350c-4e6c-b215-220c0060e0db
------------------------------------------------------------------
extra row on target
key:pkid:e1b50179-a5c7-4493-bcaa-69bea20df5d6
------------------------------------------------------------------
extra row on target
key:pkid:ea6b0da0-815d-4244-9e3a-4386fe788db3
------------------------------------------------------------------
Node Rows Extra Missing Mismatch Processed
---------------- --------- --------- --------- --------- ---------
g_cucm_pub_ccm9_1_1_20000_5 13 0 0 0 0
g_cucm_sub_ccm9_1_1_20000_5 13 6 6 0 0
WARNING: replicate is not in sync
Oct 30 2013 22:35:53 ------ Table scan for ccmdbtemplate_g_cucm_pub_ccm9_1_1_20000_5_1_403_certificatetrustrolemap end ---------
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide