06-02-2014 04:16 AM - edited 03-16-2019 10:57 PM
The senarios is:
A(22222) ---hvic3-4fxs--- c2921 - c7206---isdn---Tel station---B(11111)
C (33333)---vic-2fxs--- c2620 - c7206---isdn---Tel station---B(11111)
This problem begins after changing c2620 to c2921, in several of our communication centers, with the same config. The inbound call from B to A drops after 15 seconds everytime.When I'm calling from telephone B to C (the same communication center with c2620 router) - everything is allright. This situation repeats everytime I'm calling to diferent comm.centers with new c2925 routers. As I understand - c2925 somehow sents disconect request after 15 seconds of normal call.
Could you share your opinion, why it happens?
or advice me some diagnostic commands to solve this problem.
Solved! Go to Solution.
06-02-2014 01:38 PM
Get the following from both sides:
debug cch323 all
debug h245 asn1
debug h225 asn1
debug h225 q931
debug voice ccapi inout
I think 15 seconds is probably the default H.245 timeout. It might be one side is never sending a TerminalCapabilitySet or might be the H.245 socket fails to open at all. A packet capture between the 2 may also be helpful.
06-02-2014 04:32 AM
You should start by looking at your isdn logs to see why the call is dropping..
debug isdn q931
06-02-2014 08:01 AM
06-02-2014 08:03 AM
debug cch323 h245 + debug ccH323 error on c2921:
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/run_h245_iwf_sm: received IWF_EV_FASTSTART while at state IWF_IDLE
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/h245_iwf_set_new_state: changing from IWF_OLC_IDLE state to IWF_OLC_DONE state
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/fastStartIdle: H245_EV_OLC_IN/OUT_DONE sent to olc
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/h245_olc_in_sm: Received H245_EV_OLC_IN_DONE while at state H245_OLC_IN_STATE_IDLE
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/h245_olc_in_set_new_state: Changing from H245_OLC_IN_STATE_IDLE state to H245_OLC_IN_STATE_ESTABLISHED state
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/h245_olc_out_sm: Received H245_EV_OLC_OUT_DONE while at state H245_OLC_OUT_STATE_IDLE
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/h245_olc_out_set_new_state: Changing from H245_OLC_OUT_STATE_IDLE state to H245_OLC_OUT_STATE_ESTABLISHED state
Jun 2 18:13:50.218: //443/F428E0BA8AFC/H323/run_h245_iwf_sm: received IWF_EV_BCF while at state IWF_OLC_DONE
Jun 2 18:13:55.153: //443/F428E0BA8AFC/H323/cch323_send_event_to_h245_connection_sm: Changing to new event H245_LISTEN_REQ_EVENT
Jun 2 18:13:55.153: //443/F428E0BA8AFC/H323/cch323_h245_connection_sm: H245_LISTEN: Received event H245_LISTEN_REQ_EVENT while at H245_NONE state
Jun 2 18:13:55.153: //443/F428E0BA8AFC/H323/cch323_h245_set_new_state: Changing from H245_NONE state to H245_WAITING state
Jun 2 18:13:55.153: //443/F428E0BA8AFC/H323/run_h245_iwf_sm: received IWF_EV_BCF while at state IWF_OLC_DONE
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/cch323_h245_channel_established_ind: Using fd=5 to send msgs
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/cch323_send_event_to_h245_connection_sm: Changing to new event H245_ESTABLISHED_EVENT
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/cch323_h245_connection_sm: H245_LISTEN: Received event H245_ESTABLISHED_EVENT while at H245_WAITING state
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/cch323_h245_set_new_state: Changing from H245_WAITING state to H245_CONNECTED state
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/run_h245_iwf_sm: received IWF_EV_H245_CONNECTED while at state IWF_IDLE
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/h245_iwf_set_new_state: changing from IWF_IDLE state to IWF_AWAIT_CAP_MSD_RESP state
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/cch323_run_h245_cap_out_sm: Received H245_EVENT_CAP_REQ while at state IDLE
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/h245_cap_out_set_new_state: changing from IDLE state to AWAITING_RESPONSE state
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/cch323_run_h245_ms_sm: Received event H245_EVENT_MSD while at state H245_MS_NONE
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/cch323_run_h245_ms_sm: Sent MSD Request
Jun 2 18:13:55.161: //443/F428E0BA8AFC/H323/h245_ms_set_new_state: Changing from H245_MS_NONE state to H245_MS_OUTGOING_WAIT state --------- connection moment
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/cch323_run_h245_cap_out_sm: Received H245_EVENT_CAP_TIMER_EXPIRY while at state AWAITING_RESPONSE---------- disconnection moment after 15 sec
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/h245_cap_out_set_new_state: changing from AWAITING_RESPONSE state to IDLE state
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/run_h245_iwf_sm: received IWF_EV_CAP_REJ while at state IWF_AWAIT_CAP_MSD_RESP
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/h245_iwf_set_new_state: changing from IWF_AWAIT_CAP_MSD_RESP state to IWF_IDLE state
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/cch323_run_h245_ms_sm: Received event H245_EVENT_MS_TIMER_EXPIRY while at state H245_MS_OUTGOING_WAIT
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/cch323_run_h245_ms_sm: Error A, no response from remote endpoint
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/h245_ms_set_new_state: Changing from H245_MS_OUTGOING_WAIT state to H245_MS_NONE state
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/run_h245_iwf_sm: received IWF_EV_MSD_REJ while at state IWF_IDLE
Jun 2 18:14:10.161: //443/F428E0BA8AFC/H323/errHdlr: ERROR: Received Unexpected IWF_EV_MSD_REJ in state IWF_IDLE
Jun 2 18:14:10.173: //443/F428E0BA8AFC/H323/run_h245_iwf_sm: received IWF_EV_H245_DISCONN while at state IWF_IDLE
Jun 2 18:14:10.173: //443/F428E0BA8AFC/H323/defaultHdlr: DEFAULT: Received IWF_EV_H245_DISCONN in state IWF_IDLE
06-02-2014 01:38 PM
Get the following from both sides:
debug cch323 all
debug h245 asn1
debug h225 asn1
debug h225 q931
debug voice ccapi inout
I think 15 seconds is probably the default H.245 timeout. It might be one side is never sending a TerminalCapabilitySet or might be the H.245 socket fails to open at all. A packet capture between the 2 may also be helpful.
06-04-2014 04:53 AM
In c7206 debug I found the reason of disconnection:
Jun 3 13:19:14.124: changing from H245_MS_NONE state to H245_MS_OUTGOING_WAIT state
Jun 3 13:19:14.124: timer (0x63AC4B40)starts - delay (15000)cch323_run_h245_ms_sm: Sent MSD Request
changing from H245_WAITING state to H245_CONNECTED state
and after 15 sec:
Jun 3 13:19:29.124: Timer[CCH323_H245_CAP_TIMER] expired
Set new event H245_EVENT_CAP_TIMER_EXPIRY, for callID 71816
but I don't understand from what side TCS not sends, could you, please, look at the debug files.
06-04-2014 09:02 AM
It looks like term mon didn't get all of the debugs as some lines such as the incoming TCS were cut off. This is fairly normal for these intensive debugs so we'll need to use a logging buffer instead. Use this config:
no logging console
no logging monitor
logging buffered 5000000
service sequence-numbers
then run "clear log" from privilege exec and use "term len 0" and "show log" in order to view the logging buffer we set up. That should prevent the messages from getting cut off
06-05-2014 01:53 AM
06-18-2014 02:39 PM
These logs definitely have more information.
I can see that after the 7206 receives the connect, it then sends a terminalCapabilitySet:
1529065: Jun 5 11:18:41.126: H225.0 INCOMING PDU ::=
R
value H323_UserInformation ::=
{
h323-uu-pdu
{
h323-message-body connect :
{
protocolIdentifier { 0 0 8 2250 0 4 }
destinationInfo
{
vendor
{
vendor
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
}
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
}
}, h323 :
{
supportedPrefixes
{
}
}
}
}
mc FALSE
undefinedNode FALSE
}
conferenceID '6C80510AEBB811E39CE0837E4C6979E6'H
callIdentifier
{
guid '6C80510AEBB811E39CE1837E4C6979E6'H
}
}
h245Tunneling FALSE
nonStandardControl
{
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data 'C0010018800006000400000002'H
}
}
}
}
1529147: Jun 5 11:18:41.150: H245 MSC OUTGOING PDU ::=
RR
value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :
{
sequenceNumber 1
protocolIdentifier { 0 0 8 245 0 3 }
multiplexCapability h2250Capability :
{
maximumAudioDelayJitter 20
receiveMultipointCapability
{
multicastCapability FALSE
multiUniCastConference FALSE
mediaDistributionCapability
{
{
centralizedControl FALSE
distributedControl FALSE
centralizedAudio FALSE
distributedAudio FALSE
centralizedVideo FALSE
distributedVideo FALSE
}
}
}
transmitMultipointCapability
{
multicastCapability FALSE
multiUniCastConference FALSE
mediaDistributionCapability
{
{
centralizedControl FALSE
distributedControl FALSE
centralizedAudio FALSE
distributedAudio FALSE
centralizedVideo FALSE
distributedVideo FALSE
}
}
}
receiveAndTransmitMultipointCapability
{
multicastCapability FALSE
multiUniCastConference FALSE
mediaDistributionCapability
{
{
centralizedControl FALSE
distributedControl FALSE
centralizedAudio FALSE
distributedAudio FALSE
centralizedVideo FALSE
distributedVideo FALSE
}
}
}
mcCapability
{
centralizedConferenceMC FALSE
decentralizedConferenceMC FALSE
}
rtcpVideoControlCapability FALSE
mediaPacketizationCapability
{
h261aVideoPacketization FALSE
}
logicalChannelSwitchingCapability FALSE
t120DynamicPortCapability FALSE
}
capabilityTable
{
{
capabilityTableEntryNumber 17
capability receiveAndTransmitDataApplicationCapability :
{
application nonStandard :
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '52747044746D6652656C6179'H
}
maxBitRate 0
}
},
{
capabilityTableEntryNumber 23
capability receiveUserInputCapability : hookflash : NULL
},
{
capabilityTableEntryNumber 22
capability receiveUserInputCapability : dtmf : NULL
},
{
capabilityTableEntryNumber 19
capability receiveUserInputCapability : basicString : NULL
},
{
capabilityTableEntryNumber 4
capability receiveAudioCapability : g729AnnexA : 8
},
{
capabilityTableEntryNumber 3
capability receiveAudioCapability : g729 : 8
},
{
capabilityTableEntryNumber 9
capability receiveAudioCapability : g7231 :
{
maxAl-sduAudioFrames 3
silenceSuppression FALSE
}
},
{
capabilityTableEntryNumber 2
capability receiveAudioCapability : g711Alaw64k : 20
},
{
capabilityTableEntryNumber 8
capability receiveAudioCapability : g728 : 16
},
{
capabilityTableEntryNumber 7
capability receiveAudioCapability : nonStandard :
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '47373236723332'H
}
}
}
capabilityDescriptors
{
{
capabilityDescriptorNumber 1
simultaneousCapabilities
{
{
23
},
{
22,
19,
17
},
{
4,
3,
9,
2,
8,
7
}
}
}
}
}
However, we do not see that TCS received on the 2921 side. All we see is the 2921 sending its terminalCapabilitySet then waiting 15 seconds before timing out waiting to receive one from the 7206 and then sending the release complete:
008752: Jun 5 11:18:41.148: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :
{
sequenceNumber 1
protocolIdentifier { 0 0 8 245 0 7 }
multiplexCapability h2250Capability :
{
maximumAudioDelayJitter 20
receiveMultipointCapability
{
multicastCapability FALSE
multiUniCastConference FALSE
mediaDistributionCapability
{
{
centralizedControl FALSE
distributedControl FALSE
centralizedAudio FALSE
distributedAudio FALSE
centralizedVideo FALSE
distributedVideo FALSE
}
}
}
transmitMultipointCapability
{
multicastCapability FALSE
multiUniCastConference FALSE
mediaDistributionCapability
{
{
centralizedControl FALSE
distributedControl FALSE
centralizedAudio FALSE
distributedAudio FALSE
centralizedVideo FALSE
distributedVideo FALSE
}
}
}
receiveAndTransmitMultipointCapability
{
multicastCapability FALSE
multiUniCastConference FALSE
mediaDistributionCapability
{
{
centralizedControl FALSE
distributedControl FALSE
centralizedAudio FALSE
distributedAudio FALSE
centralizedVideo FALSE
distributedVideo FALSE
}
}
}
mcCapability
{
centralizedConferenceMC FALSE
decentralizedConferenceMC FALSE
}
rtcpVideoControlCapability FALSE
mediaPacketizationCapability
{
h261aVideoPacketization FALSE
}
logicalChannelSwitchingCapability FALSE
t120DynamicPortCapability FALSE
}
capabilityTable
{
{
capabilityTableEntryNumber 32
capability receiveAndTransmitDataApplicationCapability :
{
application t38fax :
{
t38FaxProtocol udp : NULL
t38FaxProfile
{
fillBitRemoval FALSE
transcodingJBIG FALSE
transcodingMMR FALSE
version 0
t38FaxRateManagement transferredTCF : NULL
t38FaxUdpOptions
{
t38FaxMaxBuffer 200
t38FaxMaxDatagram 320
t38FaxUdpEC t38UDPRedundancy : NULL
}
}
}
maxBitRate 144
}
},
{
capabilityTableEntryNumber 6
capability receiveAudioCapability : g729AnnexA : 8
},
{
capabilityTableEntryNumber 5
capability receiveAudioCapability : g729 : 8
},
{
capabilityTableEntryNumber 11
capability receiveAudioCapability : g7231 :
{
maxAl-sduAudioFrames 3
silenceSuppression FALSE
}
},
{
capabilityTableEntryNumber 4
capability receiveAudioCapability : g711Alaw64k : 20
},
{
capabilityTableEntryNumber 10
capability receiveAudioCapability : g728 : 16
},
{
capabilityTableEntryNumber 9
capability receiveAudioCapability : nonStandard :
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '47373236723332'H
}
}
}
capabilityDescriptors
{
{
capabilityDescriptorNumber 1
simultaneousCapabilities
{
{
32,
4,
9,
10,
5,
6,
11
}
}
}
}
}
008863: Jun 5 11:18:56.156: //115/6C80510A9CE0/H323/run_h225_sm: Received event H225_EV_H245_FAILED while at state H225_WAIT_FOR_H245
008875: Jun 5 11:18:56.156: H225.0 OUTGOING PDU ::=
value H323_UserInformation ::=
{
h323-uu-pdu
{
h323-message-body releaseComplete :
{
protocolIdentifier { 0 0 8 2250 0 4 }
callIdentifier
{
guid '6C80510AEBB811E39CE1837E4C6979E6'H
}
}
h245Tunneling FALSE
}
}
It looks like the H245 messaging sent from the 7206 to the 2921 is getting dropped somewhere. What's the network topology between these devices? You may want to try packet captures on both sides.
06-19-2014 12:39 AM
Hello Brian,
Thank you for answer, c2921 is connected directly to c7206 via E1 channel and I can't imagine where the h245 masseges could be dropped.
c7206 is the center of star-topology with lots of c2620 and one c2921 on another sides which are all connected via similar E1 channels. Also we made testing calls from some of c2620s on c2921 and everything was normal.
I've never tested E1 channels by packet captures - is it possible?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: