Voice calls failing

[tenbucker]

So, this is my absolute last resort on this particular issue as I have expended all my ideas.

I have a customer that has Cisco Call manager at one site and they are having issue with calls to another site. The other site has a Zyxel router.

The issue manifests itself whenever a call is hung up and then another call is initiated, which ends up failing with a temporary Failure message.

I have looked into connectivity issues, can't see drops on any interface in the path. Additionally, I can confirm the various flavours of ALG are all disabled.

I have attached a snip which shows some sort of confusion with port numbers.

Any Ideas?

[Maren Mahoney]

I don't think there is confusion with port numbers. The pairing of 51562 and 1720 is the H225 Call Setup process, and the pairing of 50349 and 35315 is the H245 TCS/OLC negotiation. You can see the release of two similar pairs of port numbers in the release exchange at lines around 36-43.

Is the pcap showing the successful/rejected call sequence you described? If so, I need to see past line 64, and may need to see details of a specific message. See if you can capture the full exchange of a failed call.

A temporary Failure message generally indicates a network issue rather than dialplan or signaling, but the network issue can be any number of things.

[tenbucker]

Hi Maren,

Thank you for taking the time to message me back.

I have attached another snip which covers the issue I described. I.e when a call is made in quick succession of finishing one, it fails.

Kind regards

Benjamin Tucker

Benjamin

[Maren Mahoney]

16.1 sends OLC to 89.19 at line 71
89.19 sends OLC to 16.1 at line 73 and
89.19 sends OLCack at line 74
16.1 sends Close Logical Channel at line 79 four seconds after sending initial OLC.

It looks like 16.1 is not receiving the OLC (and/or OLCack) from 89.19 during the second call setup. At lines 76-78 you can see 89.19 continuing to try to keep the TCP connection going while waiting for the OLCack back from 16.1.

Also, take a look at lines 45-46 and 88. It seems 89.19 doesn't know that H245 session from the first call is closed. And we should also (I think) be seeing a final ACK from 55115 to 34188 (16.1 to 89.19) responding to the FIN-ACK on line 42.

Hmmmm......

Are you calling the same number twice in a row or two different numbers for the first and second call? If you are calling the same number twice, what happens if you call two different numbers in rapid succession?

[tenbucker]

So, the example call is to the same number but it also occurs on calls to other numbers.

The supplier that manages the call manager states the issue looks to be 16.1 not recieving the OLC, which is consistent with what you say.

The drama I have is not being able to run a pcap on the remote site (as it's a zyxel) nor on any routers along the path, as I haven't got the priveledges to do so. Any thoughts?

Ben

[Maren Mahoney]

89.19 is most certainly sending its OLC and OLCack to 16.1, so it's not you.

As you are blind on what's going on in the network, I'd say get hold of whomever has rights on the path and get them to help. Bring that second pcap file along with. I wish I had more for you.

[tenbucker]

Thank you anyway. I think my next step will be expediting this case to someone with enough priveledges to conduct captures on the hop before the Zyxel.

Ben