[cisco-voip] H245Interface & Related Processes

Daniel Pagan dpagan at fidelus.com
Mon Dec 1 19:51:38 EST 2014


Thanks Ryan - that's what I was hoping to hear. I'll try to set this up in a lab to confirm with some simple ACLs.

- Dan

From: Ryan Ratliff (rratliff) [mailto:rratliff at cisco.com]
Sent: Monday, December 01, 2014 5:33 PM
To: Daniel Pagan
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] H245Interface & Related Processes

Short answer without confirming in the lab is yes, when I send you my H245 address I expect you to start a TCP connection to me on that port so we can start H245.


-Ryan

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/187fa055/attachment.html>


More information about the cisco-voip mailing list