CISCO2811 H323 call disconnect after few sec

[md.sakibnaz]

Hello.

I have a CISCO2811 series router & I have enabled H323 Gateway. This 2811 router recieves H323 traffic from its FE0/0 & forward the traffic to

"session target ipv4:10.20.20.20:1720" via its FE0/1. But all the calls are getting disconnect after few sec (around 15 sec) with cause code 16.

If I directly send the call to 10.20.20.20 GW (bypassing the 2811) then it becomes success. The calls are getting disconnect when the calls flows through the 2811.

The dial peer configurations are as follows:

!
voice class h323 2220
  call start fast
  codec bytes preferred local
!

!
!
dial-peer voice 99912 voip
description TestDialPeer
destination-pattern 16633661T
progress_ind setup enable 3
progress_ind progress enable 8
progress_ind connect enable 8
redirect ip2ip
voice-class h323 2220
session target ipv4:10.20.20.20:1720
incoming called-number 16633661T
dtmf-relay rtp-nte h245-signal h245-alphanumeric
codec g723r63 bytes 120
fax rate 9600
!

Is there any issue due to "H225 timeout setup" in the "voice class h323 2220"?

FYI the running configuration is also attached. Need suggestion please.

Thanks in advance. Expecting your reply soon.

Regards.

Skibnaz.

[Steven Holl]

So this gateway is acting as CUBE (h323 on both sides of the call)?

To throw a disconnect of 16, someone is probably sending a h225 release complete with that cause value.

Can you get the following:

debug h225 asn1

debug h245 asn1

debug ip tcp trans

debug voip ccapi inout

Collect debugs as follows:

Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router# term len 0

Router# sh logg

[md.sakibnaz]

Hello.

Regarding the call disconnect issue, I have attached the running config & wireshark traces taken from the Server. Where the call direction is:

Server (64.20.63.126)  >>  CISCO 2811 (94.75.251.123)  >>  CISCO AS5350 (10.20.20.20)

I am very new in CISCO Voice, I'll be glad if anybody suggest suggest me a solution. Help please. Thanks.

Regards.

Sakibnaz.

[Steven Holl]

Sakibnaz,

I responded to your PM regarding this already.  There isn't enough information in that output to diagnose root cause.

The device 94.75.251.123 is  sending a release complete with a cause value of 42 (switching equipment  congestion).  See frame number 12 in that capture.  That disconnect  could be coming from the gateway, or more likely it is coming from the  other side of the 2811.  What is the other leg of the 2811?  Is that a  PRI?  Or is it another VoIP leg?

Grab these debugs and we can know for sure where this disconnect is coming from:

debug h225 asn1

debug h245 asn1

debug ip tcp trans

debug voip ccapi inout

debug vpm sig

debug isdn q931

Collect debugs as follows:

Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router# term len 0

Router# sh logg

Dear Steven.

[md.sakibnaz]

Dear Steven.

The please check attached debug output.

Also at the trace cause value of 42 (switching equipment congestion) is in Frame 12 only, but other maximum release cause value is 16 (normal call clearing).

For your query the overall network is like:

Server  >>  (INTERNET)  >>  CISCO2811  >>  (VPN)  >>  AS5350

So one interface of 2811 is connetced to ISP & other is connect VPN.

Thnaks. Expecting youre reply soon.

Sakibnaz.

[Steven Holl]

Please note the calling/called numbers for the call which had the issue, so that I can be sure that I'm looking at the call which you are reporting for the analysis.

That being said, I see a bunch of calls failing with cause value 42, actually.  That is coming in from H323 peer 94.75.251.67:

000726: *Aug 20 17:39:09.932:
000727: *Aug 20 17:39:10.036: H225.0 INCOMING ENCODE BUFFER::= 0580060008914A0004011100A8693EB1ABB811DF8E04829C9AB1B474
000728: *Aug 20 17:39:10.036:
000729: *Aug 20 17:39:10.036: H225.0 INCOMING PDU ::=
value H323_UserInformation ::=
    {
      h323-uu-pdu
      {
        h323-message-body releaseComplete :
        {
          protocolIdentifier { 0 0 8 2250 0 4 }
          callIdentifier
          {
            guid 'A8693EB1ABB811DF8E04829C9AB1B474'H
          }
        }
      }
    }

You will want to investigate from that node why it is throwing this release complete.  But if you can provide the ANI/DNIS for the call which failed, I can confirm if that is this issue, or something else which needs to be looked at.

-Steve

[md.sakibnaz]

Thanks Steven.

There is a Billing Switch (94.75.251.67) after the 2811 Router. So is that the main reason for releasing the calls woth value:42? I'll test the calls without billing switch soon & update you the result.

There are also some calls released due to cause value:16. Could you please tell me what may the reason for Value:16?

Also the parameter H245 Tunneling is True in the debug log. For a successfull call what should be the value of H245 Tunneling, True or False?

Regards.

Sakibnaz.

[Steven Holl]

H245 tunneling can be true or false, as long as all h323 endpoints in the path support it.  Don't worry about that.

Cause value 16 is normal call clearing, which means the user hung up.  Thats a proper hang up disconnect.  Likely those calls are disconnecting because one of the sides is finished talking and disconnecting the call.  Like any disconnect, if you need to figure out the origin of the disconnect, you run debugs on the router so that you can look at both legs of the call, and you find out what disconnect comes in, and what goes out.

I'm guessing your dropped calls are the ones with cause value 42, though, since that's a non standard disconnect.  However, if you would have noted the calling/called number for the problem call in those debugs, like I requested earlierl, I could have verified for sure for you.

-Steve