cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3488
Views
10
Helpful
10
Replies

H323 gateway registration

yixiu0317
Level 1
Level 1

Hi     There,

We have a 3945 gateway configured as h323 gateway, and have 2 call managers, 1 is version 8.6, another is 7.

The gateway registered to CUCM8.6 first and works fine,   later on we registered the gateway to the CUCM 7.

When we try to make call from CUCM 7 using the gateway, the call could not go through, the call did not hit the gateway, it looks like something wrong between the CUCM and gateway.

I am wondering if it is because the gateway registered to the CUCM 8.6 first and there is some update for the h323 protocol that prevent the gateway register to the CUCM 7 which may use old version.

Any help is welcome.


              

10 Replies 10

ronpatel
Level 8
Level 8

Hi

I dont think regestering to one CUCM version will stop it working with another CUCM version because it is not a client server model it is peer to peer model.

We will have to check the debug for the same.

You may stop the h.323 server and start it again to see if it works again.

regards

Ronak Patel

Rate helpful posts.

Regards Ronak Patel Rate all helpful post by clicking stars below the answer.

The H323 stack is backwards compatible, either you have a configuration problem or you might be hitting a bug.

Have you changed the binding for the H323 signaling??

Exactly how did you find out the call was not hitting the GW?

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

HTH

java

if this helps, please rate

As my colleagues indicated (+5 to RP and Java), H323 is peer to peer protocol and really does not register to anything. Is the GW on the CUCM configuration showing the IP address, did you hit reset on CUCM for it?

When you do a debug on the GW do you see a call hitting the GW? Did you try "debug voice dialpeer"?

I have had single H323 shared between multiple clusters before without any issues.

HTH,

Chris

Hi  There,

Yes, I reset the gateway in CUCM couple of times but no luck.

Also I can see the ip address of the gateway in CUCM7

I created a route pattern that force the call to go to the gateway and used CUCM called number analyser to check and it showed that the call went to the gateway only.

Then I made testing calls and run debug isdn q931 on the gateway but nothing hit the gateway, I just heard disconnect tone.

Because the gateway has registered to the CUCM8.6 and function properly, I think there is something wrong between the gateway and CUCM7. I have confirmed that I can ping between the CUCM7 and gateway without problem.

I am not sure which is the next step I should take, any advice?

Hi

Post up your configuration.

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Please post "debug voice dialpeer".

Chris

Hi       Chris,

Here is the output for "debug voice dialpeer" and the configuration for the dialpeer

Dec 21 09:54:13.885 AEDT: //-1/001E132B5000/DPM/dpAssociateIncomingPeerCore:
   Calling Number=43892, Called Number=00249264999, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
Dec 21 09:54:13.885 AEDT: //-1/001E132B5000/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=38000
Dec 21 09:54:13.885 AEDT: //-1/001E132B5000/DPM/dpMatchSafModulePlugin:
   dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0
Dec 21 09:54:13.885 AEDT: //-1/001E132B5000/DPM/dpAssociateIncomingPeerCore:

Calling Number=43892, Called Number=00249264999, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
Dec 21 09:54:13.885 AEDT: //-1/001E132B5000/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=38000
Dec 21 09:54:13.885 AEDT: //-1/001E132B5000/DPM/dpMatchSafModulePlugin:
   dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0


dial-peer voice 38000 voip
description **Inbound to UCMET011**
preference 1
destination-pattern 38...
progress_ind setup enable 3
progress_ind progress enable 8
progress_ind connect enable 8
session target ipv4:10.199.70.145
incoming called-number .
voice-class codec 10
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad


dial-peer voice 100 pots
destination-pattern 0T
progress_ind setup enable 3
progress_ind progress enable 8
progress_ind connect enable 8
direct-inward-dial
port 0/0/0:15

Hi,

From the debugs, the call is certainly hitting the gateway. In the future before running debug q931, always ensure you run atleast debug voip ccapi inout. This is because the VOIP leg of the call needs to work beefore the call is sent to the ISDN/TDM leg which is what the debug isdn q931 will show..

So here is what we see from the debugs...There is no outbound dial-peer matched.

We see inbound dial-peer 38000 matched (because of incoming called number.)

Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=38000

Can you send the "debug voip ccapi inout"

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

Please rate all useful posts

Thanks for everyone's help.

I found out that it is because the 3945 router and IOS version is 15.2, I have to add the CUCM7 ip address in the trust list under voice service voip, after that everything works fine.

Great to hear it is working for you.

Please rate all useful posts!

Chris