[cisco-voip] H245Interface & Related Processes

[Daniel Pagan]

Wrapping up on this one after revising the call flow in a lab environment -


LAB: I have an ICT between Cluster_A and Cluster_B. There's an ACL between the two allowing H.225 traffic on port 1720 and blocking everything else. Cluster_A calling Cluster_B results in Cluster_A receiving the H245 address information in a Progress message. Cluster_A creates related H245 SDL processes, fails to establish a second TCP session for H245 communication (confirmed in pcap), and throws multiple errors including:

a.       "Cannot get remote address for connector socket"

b.      "SdlConnectorBase::connectionError"

c.       "H245 signaling connection aborted!!!"



So to answer my previous question, I would say that H245 SDL processes are created before a successful second TCP session is setup for H245 communication, but unfortunately this finding didn't help us move forward as I was hoping... that is, aside from confirming TCP connectivity issues for H.245 won't result in H245 SDL processes failing to being created.



Now... digging a bit deeper... In a lab, looking at a successful call shows there's an AuConnectRequest handled by MediaManager BEFORE the H245 SDL processes were created. For the customer, looking at the failed scenario showed AuConnectRequest wasn't being initiated at all by MediaManager. Since the AuConnectRequest appears to be a prerequisite to creating H245Interface, this brings me to the Progress Indicator IE.



Looking at the customer's SDI traces for a non-working call shows no Progress Ind IE - for successful calls we have a Progress Indicator IE. I'm seeing this is pretty consistent for all call examples provided by the customer.


So it seems to be more straight-forward of a root cause, but what I didn't understand was the difference in H245 behavior between the clusters:

In the customer environment they have three clusters with ICTs between them. Cluster_A >ict> Cluster_B >ict> Cluster_C >mgcp> PRI. During a failure, Cluster_B receives a H225 Alert message with no Progress Indicator from Cluster_C, yet it still initiates an AuConnectRequest, creates H245 processes, etc. On the other hand, Cluster_A receives the H225 Alert message without Progress Indicator but, unlike Cluster_B, it doesn't initiate an AuConnectRequest. The difference in H245 and audio cut-through between the originating and intermediate clusters is what threw us off and made us question H.245 TCP connectivity.

Well, I wasn't aware there's a service parameter for H323 that determines whether the presence of a Progress Indicator value in a H.225 Alert message is required to initiate AuConnect. Looking at the customer's Cluster_A today shows the default was modified from FALSE to TRUE. So while Cluster_A received the H245 address information from Cluster_B, media establishment wasn't initiated since Cluster_A checked for a Progress Indicator and found none in H.225 Alert, which then means no H245 SDL processes were created at Cluster_A and no H245 communication. Cluster_B and Cluster_C established H245 communication and Cluster_C sent its TCS to Cluster_B, but without H.245 communication between Cluster_A and Cluster_B, Cluster_C never receives a TCS response. This resulted in a TCS timeout between Cluster_C and Cluster_B which then dropped the call.

H323 Service Parameter: Check Progress Indicator Before Establishing Media

Thanks!

- Dan


From: Wes Sisk (wsisk) [mailto:wsisk at cisco.com]
Sent: Tuesday, December 02, 2014 11:29 AM
To: Daniel Pagan
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] H245Interface & Related Processes

Hmm,

These should help:
CSCsm26337    need clear messages for h225 tcp session failure

In versions with fix h225 session setup is clearly indicated in cm sdi traces
with one of these messages:
H225Cdpc(%07d)::requestConnect_TcpStartSessionErr: H225 Tcp Start Session
request failed

H225 Call is aborted as no response received for H225 Tcp Start Session Request
within configured H225TcpTimer value

h225 session abort due to RST or FIN is clearly indicated in cm sdi traces with:
H225 Tcp session terminated abnormally


With fix for this defect TCP session aborts will be reported by one of the following statements in CallManager SDI trace:
requestConnect_TcpStartSessionErr: H225 Tcp Start Session request failed
requestConnect_H225TcpTimer: H225 Call is aborted as no response received for H225 Tcp Start Session Request within configured H225TcpTimer value
call_initiated1_TcpStopSessionInd: H225 Tcp session terminated abnormally
overlap_sending2_TcpStopSessionInd: H225 Tcp session terminated abnormally
outgoing_call_proceeding3_TcpStopSessionInd: H225 Tcp session terminated abnormally
call_delivered4_TcpStopSessionInd: H225 Tcp session terminated abnormally
call_present6_TcpStopSessionInd: H225 Tcp session terminated abnormally
incoming_call_proceeding9_TcpStopSessionInd: H225 Tcp session terminated abnormally
active10_TcpStopSessionInd: H225 Tcp session terminated abnormally
await_ann_complete_TcpStopSessionInd: H225 Tcp session terminated abnormally
active10a_TcpStopSessionInd: H225 Tcp session terminated abnormally
active10b_TcpStopSessionInd: H225 Tcp session terminated abnormally
GKRasARQH225Setup_TcpStopSessionInd: H225 Tcp session terminated abnormally
GKRasCcSetupRequestConnect_TcpStartSessionErr(%d, %d): TcpStartSessionErr from IP=%s
GKRasCcSetupRequestConnect_TcpStartSessionErr: H225 Tcp Start Session request failed
GKRasCcSetupRequestConnect_H225TcpTimer: H225 Call is aborted as no response received for H225 Tcp Start Session Request within configured H225TcpTimer value
overlap_receiving25_TcpStopSessionInd: H225 Tcp session terminated abnormally
wait_for_disconn_kluge_TcpStopSessionInd: H225 Tcp session terminated abnormally
paused_TcpStopSessionInd: H225 Tcp session terminated abnormally



CSCsm26355    need clear messages for h245 tcp session failure
h.245 tcp session setup failure:
TCP ERROR: H245ListenReq or H245ConnectReq failure, or received SdlCloseInd
from H245Handler, Perform cleanup of H245 Session

established h.245 session experiences TCP keepalive timeout:
TranslateAndTransport(%d)::wait_SdlCloseInd - ERROR: H245 signaling connection
aborted

established h.245 session receives unexpected TCP FIN or RST:
TranslateAndTransport(%d)::wait_SdlCloseInd - ERROR: H245 signaling connection
aborted




Otherwise, consider enabling additional SDL trace flags like "enable network *" and "enable SDL TCP event trace".  However, these will cause significant additional trace lines (one or more SDL signal per TCP segment received).


I believe one of the additional traces above will get you insight to socket requests down to the network layer in UCM.

-Wes



On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:

Folks:

Hoping to get some insight on SDL process creation for H245...

Scenario is three CUCM clusters communicating over ICTs. Call is routed from Cluster-1 to Cluster-2... then Cluster-2 to Cluster-3. Cluster-3 sends the H245 address & port info via H225 ALERTING to Cluster-2, which then sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245 session with Cluster-2. The H245 address and port is received on Cluster-1 but no H245 processes are being created for the MSD/TCS exchange. According to SDL traces on Cluster-2, the latest state of H245 on the node *sending* the ALERTING message is "waitForTransportEstablishment". On Cluster-1, the H245Interface process is never created according to SDL traces, so we never even reach the opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is... For a node receiving an H245 address & port info via H225 (the calling cluster...), is creation of the H245Interface and/or related H245 process dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, is H245Interface created only after the 2nd TCP session is successfully established at the transport level for H245 TCP communication? Knowing this would help me assess the likelihood of the issue being related to issues at the TCP level.

Thanks!

- Dan
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141216/5b797930/attachment.html>