Solved: Re: Pub will not accept calls, Sub will

kylebrogers · ‎10-30-2013

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?

tonyperla · ‎10-31-2013

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!

Please rate helpful posts
Thanks,
Tony

View solution in original post

Dennis Mink · ‎10-30-2013

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.

=============================

Please remember to rate useful posts, by clicking on the stars below.

kylebrogers · ‎10-30-2013

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).

Dennis Mink · ‎10-31-2013

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

Please remember to rate useful posts, by clicking on the stars below.

kylebrogers · ‎10-31-2013

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.

kylebrogers · ‎10-31-2013

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

tonyperla · ‎10-31-2013

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!

Please rate helpful posts
Thanks,
Tony

kylebrogers · ‎10-31-2013

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.

tonyperla · ‎10-31-2013

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!

Please rate helpful posts
Thanks,
Tony

kylebrogers · ‎10-31-2013

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.

tonyperla · ‎10-31-2013

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!

Please rate helpful posts
Thanks,
Tony

kylebrogers · ‎10-31-2013

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.

kylebrogers · ‎10-31-2013

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.

Aman Soi · ‎10-31-2013

Hi ,

what is CUCM version u are using?

can us still output of command utils dbreplication runtimestate or from Cisco unified reporting?

regds,

aman

kylebrogers · ‎10-31-2013

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