%CALL_CONTROL-6-CALL_LOOP: The incoming call has a global identfier already present in the list of c...

astanislaus · ‎10-26-2010

000049: Oct 26 14:51:04.181: %VOICE_IEC-3-GW: H323: Internal Error (H323 Interwo

rking Error): IEC=1.1.127.5.21.0 on callID 261 GUID=80316352D0FE011E02002302A5CC

B8F9

000050: Oct 26 15:24:50.315: %CALL_CONTROL-6-CALL_LOOP: The incoming call has a

global identfier already present in the list of currently handled calls. It is b

eing refused.

000051: Oct 26 15:24:50.315: %VOICE_IEC-3-GW: CCAPI: Internal Error (Incoming lo

op): IEC=1.1.180.1.28.0 on callID 0

000052: Oct 26 15:24:50.315: %VOICE_IEC-3-GW: H323: Internal Error (H323 Interwo

rking Error): IEC=1.1.127.5.21.0 on callID 363

According to Cisco it says:

It means that the voice gateway has detected a loop in the call route

What debugs can I do to track this problem down.

All dial peers are like this. They are all voip dial peers with different destination-patterns and different session target IP addresses. No PSTN dial peers at all.

dial-peer voice 30000 voip
huntstop
destination-pattern 3[01]...
session target ipv4:192.168.99.4
dtmf-relay h245-signal
ip qos dscp cs5 media

asandborgh · ‎10-27-2010

Hi,

Assuming that there is no CUCM in this mix I would do a debug voip dialpeer and see what dialpeers the call is looping through.

HTH,

Art

dksingh · ‎10-27-2010

This is a call loop prevention mechanism so that

we do not crash the box by running the CPU too high.

Most likley a config issue, very possible a dialplan

or digit manipulation mis config causing the call to

be looped back to the GW itself.

Also, u should not configure allow connection

commands (under voice service voip) if this box is

not a CUBE/IPIPGW.

Can u share you config as well?

astanislaus · ‎10-27-2010

Show tech attached.

This is an IP to IP Gateway

asandborgh · ‎10-27-2010

How often are you seeing this occur?

Is there anything in the logs at approximately the same time that might give a clue?

Please set up the debug voip dialpeer if at all possible as it may give a clue...

HTH,

Art

astanislaus · ‎10-27-2010

show logging - part of it is

in my original post

asandborgh · ‎10-27-2010

Ok, bear with me,

How long has this system been in place - is it a new system, or is this something that just started on a system that has been in place for awhile? If so were ther any changes to the infrastructure, or the dialplan in particular?

Have you seen this occur in the past in the logs? If so how often do you see it?

Have you tried to establish what is causing these: H323: Internal Error (H323 Interworking Error) ?

Art

astanislaus · ‎10-27-2010

Q: How long has this system been in place - is it a new system, or is this something that just started on a system that has been in place for awhile?

A: My customer says to me that this system has been in place for nearly a year and the problem started only a couple of days ago.

Q: If so were there any changes to the infrastructure, or the dialplan in particular?

A: Again this is the first question I asked and he said “NO CHANGES”. But that is what most customer say – right?

Q: Have you seen this occur in the past in the logs? If so how often do you see it?

A: Started on 26^th Oct 2010. Since the problem started the router has been reloaded and the problem is still there. It is very intermittent and I have to do the debug when I get the problem.

Q: Have you tried to establish what is causing these: H323: Internal Error (H323 Interworking Error) ?

A: Not sure how to troubleshoot this. The explanation of this message on CCO is not that great.

asandborgh · ‎10-27-2010

have to say, laughed out loud at this:

A: Again this is the first question I asked and he said “NO CHANGES”. But that is what most customer say – right?

Thanks! I needed that!

I'll drag you back to the debug voip dialpeer - I'm still hoping that will identify the call that starts the loop and we can trace from there.

Cheers!

Art

astanislaus · ‎10-27-2010

Thanks You.

It is going to be hard to catch the problem to do the debug voip dialpeer at the same time.

Can I leave this debug running all the time, so that when the problem occurs we can see what happened in the debug or will that drain CPU cycles.

Also does the debug voip dialpeer have any more parameters or just debug voip dialpeer?

asandborgh · ‎10-27-2010

Excellent questions

Normally I run it with no options which the default (I believe) gives you in-out and errors which is what you really want to see.

As far as the CPU burden, that depends on how many calls are traversing this gateway - the answer is a classic "it depends". Is this box "Busy" during normal production? if so you may want to wait until after hours (or reduced traffic period if it is 7X24X365) when you can do focused testing. That would be running all possible dial string testing (based on your possible dial-peers) to find the offending call string.

As always what you really want is to trigger the event in a repeatable manner - which I think you already fully understand. If you can find the trigger you can usually find the core issue fairly rapidly..

HTH,

Art

asandborgh · ‎10-28-2010

One more ugly little item that occured to me. The problem may not be on this router at all. Suppose there was a flapping IP route "out there somwhere" that periodically creates a route loop (or a spanning tree issue that creates a layer two loop). If your CUBE is working fine, sends a call, and it gets looped it appears the CUBE is the problem because that is where the error is logged, and all the testing and debugging in the world on the CUBE is not going to find it unless you get "lucky" enough to test just when the network failure occurs.

Sorry - could be ugly. Do you have a network group that monitors the IP route infrastucture? Perhaps they saw something in logs in other parts of the network at the same time you are seeing loops....

Good Luck!!

Art

paolo bevilacqua · ‎10-28-2010

asandborgh wrote:

One more ugly little item that occured to me. The problem may not be on this router at all. Suppose there was a flapping IP route "out there somwhere" that periodically creates a route loop (or a spanning tree issue that creates a layer two loop). If your CUBE is working fine, sends a call, and it gets looped it appears the CUBE is the problem because that is where the error is logged, and all the testing and debugging in the world on the CUBE is not going to find it unless you get "lucky" enough to test just when the network failure occurs.

Sorry - could be ugly. Do you have a network group that monitors the IP route infrastucture? Perhaps they saw something in logs in other parts of the network at the same time you are seeing loops....

That cannot happen. Voice gateway only process packets destined to his addresses. When an unicast packet is sent by router for a different address, no L2 or routing loop can cause it to process it for itself like a voice a call.

paolo bevilacqua · ‎10-28-2010

Have you tried reloading router ?

astanislaus · ‎10-28-2010

The router has been reloeaded and the problem still occurs a few days after the reload.

I got some additional but vaque information as follows:

=======================================

The problem could may started after they installed a PSTN router. Still awaiting of what this router and where it is installed. I was also told that this problem has been there for a few months - on and off. After a reload of this Voice Gateway the problem will go away for a few days but come back again.

Please see the log attached in previous entries made by me.

In that log, will the Gigabit interface flapping cause this kind of sympton.