[cisco-voip] H245Interface & Related Processes

[Brian Meade]

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) <rratliff at 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 <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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> 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/20141201/b63e1625/attachment.html>