Release 3.0 H323 trunk issue

[khaman]

I am running 3 systems in one town all Release 3.0 Option 11 systems. One site has a Callpilot system which the other 2 network over to for voicemail and menu services. I have users complaining that when they call over to voicemail, sometimes all they will get is a busy signal, try again in 30-60 minutes and it will start working again.

I started looking around at the systems and at the site where Callpilot is at, I found these errors in the signaling server OM report logs.

[1164] 06/02/12 13:45:18 LOG0003 NPM: npmSendOLCAck: no rx channel found
[1163] 06/02/12 13:40:43 LOG0004 NPM: cmEvNewCall: Request for idle channel from VTRK failed

I have checked over the configuration of Element Manager and the trunk members in the switch and everything looks ok. Any suggestions out there?

 

[bdmcdonald99]

Looks like your H323 channels are all busy. See if all of your licensed trunks are programed. You may need to purchase some H323 trunks and add them.

It's a phone system, NOT a clock!

 

[khaman]

I do have all available licensed trunks built, I believe that it is 20 trunks. I turned on traffic monitoring on the site and ran a report against the errors that I am seeing in the signaling server and it shows that I should have trunks available, one time the report only showed 6 trunks busy. Has anyone seeing this issue due to a network switch having high traffic? The times that the trunks are busy are very random.

 

[lgjc]

The other thing you might want to look at are DSP's and how the codec's are programmed.

 

[khaman]

So I finally was able to figure out what caused the issue. I have 3 IP phones off site, if I call one of the DNs and make that line busy and call back to the same DN, when the call is forwarded to voice mail all my virtual trunks fill up. Now I have other IP phones in the same location and I can call them and get re-directed to voice mail and the trunks don't fill up. I called the network tech to see if there would be anything different about these 3 phones and the routing and of course they said "this wouldn't be anything caused by the network switch". Wondering if anyone has ran into this before or give me some direction as to where to look next.

Thanks!

 

[khaman]

Figured out that it was an issue with the LDID on the SPN. The 3 IP phone numbers were not listed as LDIDs and it would keep trying to route the call back and forth until my trunks were tied up. Added those 3 numbers to the LDID on the SPN and no more tied up trunks.

 

[Triton101]

and if you have Vacant number routing with NRS, and CDP codes it does something similar,

If there is an NRS entry but no DN programmed at the Vacant number routing location, the call bounces back and forth till it eats up all the channels also.....



__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius