atcomsystems.ca/forum Forums Other TDM Phone Systems Sprint - Tadiran Telephones & Systems Illegal Pool Exhausted

Saw an issue with someone back in 2010 had this issue but did not see a resolution. Here's what I have a Coral 3000 with a QSIG connection to an Aeonix server. (Slowly cutting over) Aeonix has been up and working for a while then all of a sudden not able to pass a call across it. Have rebooted the Aeonix and reset the PUGW card in th Coral yet the same error above. When I turn n on messaging on the Coral all I see is a 2h code. Turn on TCPDUMP on the Aeonix ( tcpdump -I eth0 | grep nothing comes across. (Opened another ssh session and ran ping to th PUGW and then saw traffic on tcpdump so connectivity is good) only about 45 phones on the Aeonix minimal traffic between these 2 switches. Ran into this onc before a very long time ago but for the life of me cannot remember what the solution was. Anyone got any ideas?

Are these systems in the same room or different sites?

They are in the same room. Spoke with support but since the coral is not on version 16 they will not support it, tried to convince them that we are cutting over to Aeonix there is no sense in upgrading at the moment, t's just a slow process for cutting over which looks like will get sped up now.it Just wish I could figure out what was going on. However in speaking with the tech it is a resource issue. So rebooted the PUGW card thinking this may help. It did. The only thing I can think of is this site has a very high call volume right now and transferring a lot of calls out of the system so maybe the time slots are getting hit hard. It is a 4 shelf system with 256 time slots.

Check sizing. I would also check in your ARS for the QSIG trunk group and make sure day/nite1 and nite2 are all going to the same routing number. For whatever reason sometimes the system thinks it's in the wrong time mode.

If its a time slot issue move the PUGW to a better shelf. 256 timeslots is ONLY 128 conversations/shelf. Another thing to look at is if your trunks are "tromboning" vs correct QSIG transferring. I mean if it is you could be also running out of CONF 3/way ports.

Looked at Day/Night set up, this is not being used at this site. Think this is a time slot issue mostly with the CONF 3/way ports. The call center application is hosted in the "Cloud" so calls are delivered to DID's. To transfer a call back to the queue or even the person sitting next to you you grab another Trunk to send the call back. This is not only tying up trunks but also using up a lot of resources. Rebooted the PUGW card and this seemed to resolve the issue for now. Will just work on moving the users faster now (at least ones not in the Call Center) Thanks for all your help and insight