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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
