[cisco-voip] H245Interface & Related Processes

[Wes Sisk (wsisk)]

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/20141202/d3dc1152/attachment.html>