Also should be fairly easy to capture via a packet capture on Cluster 1 if this is easily reproducible for the call flow.
Brian On Mon, Dec 1, 2014 at 5:32 PM, Ryan Ratliff (rratliff) <rratl...@cisco.com> wrote: > 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 <dpa...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip