cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1602
Views
10
Helpful
4
Replies

Getting Internal Error (Incoming loop) on Cube...any suggestion?

actualabhishek
Level 1
Level 1

Hello Gents,

I'm seeing following error on one of my CUBE. I know this normally happens due to overlapping dialplan or incorrect translation, but I am unable to find at exact issue in my configuration. I have attached Cube config, Please help!

 

047161: Nov 28 03:43:29.578: %VOICE_IEC-3-GW: CCAPI: Internal Error (Incoming loop): IEC=1.1.180.1.28.0 on callID 0
047162: Nov 28 03:43:33.481: %VOICE_IEC-3-GW: SIP: Internal Error (1xx wait timeout): IEC=1.1.129.7.59.0 on callID 39046 GUID=01DC20F711CB9470ADE55818ADE55818
047163: Nov 28 03:43:33.485: %VOICE_IEC-3-GW: CCAPI: Internal Error (Incoming loop): IEC=1.1.180.1.28.0 on callID 0

 

4 Replies 4

TONY SMITH
Spotlight
Spotlight

Just looking at your PSTN to CUCM dial peers, these cover large ranges of numbers (for example +1630.......).   So two thoughts, (1) what happens if you get an incoming call to an unallocated DDI within your range.  (2) what happens if someone makes an outbound call to a number within that overall range, outside your own numbering - could that bounce back to CUCM?

Hello Tony,

Answer below 

1. Incoming call to unallocated DID would play some sort of announcements from UCM.

2. It will not bounce back to UCM, if someone dial outbound call to number withing overall range but outside our DID range, CUBE is setup to route calls to ITSP because (Eg +1630....... )will not matched the DNIS, from UCM we are only sending 10 or 11 digits and on outbound DP to ITSP we're globalizing ANI & DNIS.

How frequently does the error appear?  Just wondering if it would be practical to look at SIP debugs at the time to see what sort of call triggered the error.

Out of interest since your destination patterns look as if they cover much bigger number ranges than your actual DDI ranges, why not just use one destination pattern of +1..........?  On a quick skim through the PSTNtoCUCM dial peers seem to have the same targets for each range.

Thanks for the input.

I was able to resolve this. I removed RP Partition from inbound CSS of SIP tunk.