Recently had a case where basically trunks available stats in router kept dropping to a very low value, then turning right around and showing a high number quickly thereafter which would be false considering the number of trunks hit at any given time.
From the case problem description:
Trunk data from ICM keeps showing they are dropping. So for example as per the 3rd party reporting tool dashboard that they have created which directly polls the central controller, we see that the available trunks show 214 and then the next minute it’s at 84 and then flops back to 214 available trunks. Because of this calls are not being able to reach the target
In checking with developers, there was a registry added to the pim which resolved an Avaya defect in the cvlan. Basically:
The registry G3BugTrunkGroupBitShift was introduced into the Avaya PIM to decide whether to shift or not the trunk values reported by the Avaya ACD for instances where the trunks were greater than 7 bits (127). Through this registry and changes in code we have addressed Avaya ACD issue in Avaya PIM where ACD was reporting incorrect trunk count for trunks greater than 7 bits (127). If this registry is set, Avaya PIM will shift the trunk count by 4 bits to correct the wrong value from ACD. The Avaya PIM will not do any shift if the registry value is 0. This registry has default value 4.
This value of 4 has been in place since 2001 (old Avaya document – GED 372 - with registry explanations). Obviously this is an old document and this value has been in place ever since. Most customers won’t experience this if they have less than 127 trunks. However, this issue was brought to light when customer recently added additional trunks to their location.
Apparently there were changes made where Avaya corrected the trunk value. So the Avaya PIM doesn’t need to do further shifting since the Avaya ACD reports the correct trunk value now. So if you run into this, please change the registry value to “0” which in essence disables the need for shifting and reads the correct trunk value. We changed it to “0” and watched the numbers stay at a steady value (dynamic registry so no need to restart PG). Of course as trunks are used for translation routing, those trunks will show less available. Problem is when a drastic drop is reported which affects whether calls will be translation routed to that particular site or not.
