Alcatel PBX connecting with 2911 using H.323 Call Disconnects.

hassanalirazi · ‎02-06-2013

Hi All,

I need some assistance. We are connecting to a client PBX( Alcatel ) which is sitting behind a firewall using h323. Now the outgoing and incoming call connects fine, path of both outgoing and incoming are different. During the call each and every call disconnects after a random amount of time varying from 20 to 35 seconds both for incoming and outgoing.

I am attaching some debugs along with this . debug voip ccapi inout and debug voip dial-peer.

Can anyone please guide me can this be a firewall issue?

Regards

Hassan

islam.kamal · ‎02-07-2013

I think this is the problem , you have to enable H323 and the acl lists between the two sites.

hassanalirazi · ‎02-07-2013

Hi Guys i have removed the firewall but still no luck. Any help would be great

islam.kamal · ‎02-07-2013

please can you share the configuration and debug after you remove the firewall

hassanalirazi · ‎02-07-2013

The debugs remain the same i am getting a disconnect 16. The call just disconnects after like 30 seconds.

ex representation of the SETUP TPKT received: 08028029627E000F052810010006C00180050103090001
h225ParseData: Q.931 FACILITY received for fd=3
Feb 7 11:33:36.001: h323chan_chn_process_read_socket: fd=3 of type CONNECTED has data

Hex representation of the SETUP TPKT received: 08028029627E000F052810010006C00180050103090002
h225ParseData: Q.931 FACILITY received for fd=3
Feb 7 11:33:45.805: h323chan_chn_process_read_socket: fd=3 of type CONNECTED has data

Hex representation of the SETUP TPKT received: 08028029627E000F052810010006C00180050103090003
h225ParseData: Q.931 FACILITY received for fd=3
Feb 7 11:33:55.817: h323chan_chn_process_read_socket: fd=3 of type CONNECTED has data

Hex representation of the SETUP TPKT received: 08028029627E000F052810010006C00180050103090004
h225ParseData: Q.931 FACILITY received for fd=3
Feb 7 11:34:05.825: h323chan_chn_process_read_socket: fd=3 of type CONNECTED has data

Hex representation of the SETUP TPKT received: 08028029627E000F052810010006C00180050103090005
h225ParseData: Q.931 FACILITY received for fd=3
Feb 7 11:34:13.849: h323chan_chn_process_read_socket: fd=3 of type CONNECTED has data

Hex representation of the SETUP TPKT received: 08028029627E000E052810010006C001800401024A40
h225ParseData: Q.931 FACILITY received for fd=3
Feb 7 11:34:13.849: compose_TunnelledSignallingMessage_ciscoNo tunnelled content.
Hex representation of the FACILITY TPKT to send.: 08020029621C002813636973636F2053797374656D732C20496E632E7E003F052690060008914A000469096758705011E2ADBC001E13CD88A08601001F01801100690A0380705011E28506BDAFC5945DF80100010010C001800401024A40
h225FacilityRequest: Q.931 FACILITY sent from fd=3
Feb 7 11:34:13.849: h323chan_chn_process_read_socket: fd=3 of type CONNECTED has data

Hex representation of the SETUP TPKT received: 080280295A080281907E0021052580060008914A0002011100690A0380705011E28506BDAFC5945DF806800180
h225ParseData: Q.931 RELEASE COMPLETE received on fd=3
Feb 7 11:34:13.849: //92/69096758ADBC/CCAPI/cc_api_call_disconnected:
Cause Value=16, Interface=0x2B216960, Call Id=92
Feb 7 11:34:13.849: //92/69096758ADBC/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
Feb 7 11:34:13.849: h323chan_chn_process_read_socket: fd=3 of type CONNECTED has data

Feb 7 11:34:13.849: h323chan_recvdata: Connection lost fd=3h323chan_chn_close: Calls[1] Exist on socketfd=3 Owner[2]

Feb 7 11:34:13.849: h323chan_close: TCP connection from fd=3 closed
Feb 7 11:34:13.849: //91/69096758ADBC/CCAPI/ccConferenceDestroy:
   Conference Id=0xD, Tag=0x0
Feb 7 11:34:13.849: //91/69096758ADBC/CCAPI/cc_api_bridge_drop_done:
   Conference Id=0xD, Source Interface=0x2B216960, Source Call Id=91,
   Destination Call Id=92, Disposition=0x0, Tag=0x0
Feb 7 11:34:13.849: //92/69096758ADBC/CCAPI/cc_api_bridge_drop_done:
   Conference Id=0xD, Source Interface=0x2B216960, Source Call Id=92,
   Destination Call Id=91, Disposition=0x0, Tag=0x0
Feb 7 11:34:13.849: //91/69096758ADBC/CCAPI/cc_generic_bridge_done:
   Conference Id=0xD, Source Interface=0x2B216960, Source Call Id=92,
   Destination Call Id=91, Disposition=0x0, Tag=0x0
Feb 7 11:34:13.849: //91/69096758ADBC/CCAPI/ccCallDisconnect:
   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Feb 7 11:34:13.849: //91/69096758ADBC/CCAPI/ccCallDisconnect:
   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Feb 7 11:34:13.849: //91/69096758ADBC/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Feb 7 11:34:13.849: //92/69096758ADBC/CCAPI/ccCallDisconnect:
   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
Feb 7 11:34:13.849: //92/69096758ADBC/CCAPI/ccCallDisconnect:
   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Feb 7 11:34:13.849: //92/69096758ADBC/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Feb 7 11:34:13.853: compose_TunnelledSignallingMessage_ciscoNo tunnelled content.
Hex representation of the RELEASE COMPLETE TPKT to send.: 0802B4C35A080281907E0022052580060008914A000411001100690A0380705011E28506BDAFC5945DF810800180
h225TerminateRequest: Q.931 RELEASE COMPLETE sent from fd=2. Call state changed to [Null].
Feb 7 11:34:13.853: //91/69096758ADBC/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x2B216960, Tag=0x0, Call Id=91,
   Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Feb 7 11:34:13.853: //91/69096758ADBC/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Feb 7 11:34:13.853: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Feb 7 11:34:13.853: :cc_free_feature_vsa freeing 30005430
Feb 7 11:34:13.853: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Feb 7 11:34:13.853: vsacount in free is 1
Feb 7 11:34:13.853: //92/69096758ADBC/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x2B216960, Tag=0x0, Call Id=92,
   Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Feb 7 11:34:13.853: //92/69096758ADBC/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent

islam.kamal · ‎02-07-2013

Dear , please type the below command and test.

Voice class h323 1

h225 timeount tcp establish 3

thanks

hassanalirazi · ‎02-07-2013

Didnt work. Still same issue the call disconnects after 38 seconds.

Any Ideas

islam.kamal · ‎02-07-2013

a decimal value of 16 is disconnect cause "normal call clearing".please check the below link

http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094045.shtml#q931

. I think you have a poblem in codec can you share your configuation.

hassanalirazi · ‎02-07-2013

Hi,

I if there was a codec issue would the call establish ? the call connects for like 40 seconds and then disconnects. Please have a look any help would be appreciated.

voice rtp send-recv

!
voice service voip
ip address trusted list
ipv4 10.64.120.0 255.255.255.0
ipv4 10.116.0.0 255.255.0.0
ipv4 10.8.0.0 255.255.255.0
ipv4 10.116.32.12 255.255.255.255
ipv4 10.101.83.128 255.255.255.240
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
h323
call preserve

voice class codec 10
codec preference 1 g729r8
codec preference 2 g729br8
!
voice class h323 1
h225 timeout tcp establish 3
!

dial-peer voice 8 voip
translation-profile outgoing ANI
destination-pattern 900T
session target ipv4:10.64.120.11
dtmf-relay h245-alphanumeric
no vad
!
dial-peer voice 1 voip
destination-pattern 2310
session target ipv4:10.116.32.12
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad
!
dial-peer voice 2 voip
incoming called-number .
dtmf-relay h245-alphanumeric
no vad
!
dial-peer voice 9 voip
translation-profile outgoing ANI
destination-pattern 00T
session target ipv4:10.64.120.11
dtmf-relay h245-alphanumeric
no vad
!
dial-peer voice 10 voip
destination-pattern 907[4-9]........
session target ipv4:10.64.120.3
dtmf-relay h245-alphanumeric
no vad
!
!
gateway
timer receive-rtp 1200
!
!
!

hassanalirazi · ‎02-07-2013

Anyone? Still facing the issue we are integrating with Alcatel PBX.

islam.kamal · ‎02-07-2013

dial-peer voice 51000 voip

incoming called-number .

destination-pattern ............. (the number which will be dialed).

session target ipv4:

dtmf-relay h245-signal

codec g711alaw

ip qos dscp cs5 media

please type this configuration for one dial-peer VOIP and test , if it works .The problem will be for the codec. Please also describe the solution physically onnection , the call folw.

hassanalirazi · ‎02-09-2013

Islam thanks for all your help in the end it turned out be an issue with the customers handset.