Summary:	ASTERISK-21384: Unique ID Call Count Increasing By 2
Reporter:	Ross Beer (rossbeer)	Labels:
Date Opened:	2013-04-05 15:17:07	Date Closed:	2013-04-12 08:20:10
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Channels/General
Versions:	1.8.21.0 11.3.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	The channel count and sequence numbers are increasing by 2 for each call. 'core show channels' shows half the call count of the unique id '.45345' call count. This happens with every single call where as it should only increase by one to give an accurate call count. This variable is needed in our application.
Comments:	By: Matt Jordan (mjordan) 2013-04-05 15:48:24.867-0500 I don't think we have enough information to know what you're referring to exactly. {quote} 'core show channels' shows half the call count of the unique id '.45345' call count. This happens with every single call where as it should only increase by one to give an accurate call count. {quote} What do you mean by "the unique id '.45345'" call count? Regardless, there are few things to note about the call count of 'core show channels'. The current call count/processed call count only take into account the number of times a {{pbx_thread}} was spawned for a channel. That works okay when all you have is inbound <=> outbound channel in two party bridges. That notion, however, is worthless in any sufficiently complex and realistic scenario. If a peer is ejected from a bridge into the dialplan when the caller hangs up (which is a valid option in Dial), your call count is messed up. If you originate two channels and put them in a bridge, that's counted as two calls, and the call count  is wrong. If you blind transfer a peer into the dialplan, your call count is messed up. And so on. The problem is: Asterisk doesn't know what a 'call' is. It never has. It knows what channels are, but defining the concept of a 'call' doesn't make sense in Asterisk, as no two systems agree on what a 'call' is. Even if all PBXs agreed on the concept of a 'call', Asterisk isn't always used as a PBX. Hence, this value is essentially meaningless. The only reason it still exists at all is because it is *old*, and no one bothered to remove it. If you need to know what a call is, particularly for business purposes, Asterisk provides numerous ways of helping you determine what your calls are. But it does not - and should not - attempt to do it for you. By: Ross Beer (rossbeer) 2013-04-05 17:08:58.320-0500 I agree with you, however I have been using the call count which follows the unique id to load balance between PSTN gateways. The code I use does a modal operation using this count to select the PSTN gateway. However the count is always even which means that the same gateway is selected. For example: sip08-1365195942.0 sip08-1365196042.2 sip08-1365196057.4 sip08-1365196073.6 The above calls are 'inbound <=> outbound' bridges, therefore should only increase the call count by one. 'core show channels verbose' show 4 calls as expected. I have substituted 'EPOCH' instead of the call count, however if calls are passed in the same second calls go to the same gateway, instead of being balanced correctly. I can't find any other variable that changes per call. By: Matt Jordan (mjordan) 2013-04-05 17:37:47.261-0500 Yikes. Relying on the unique ID value to be anything other then a unique value is relying on implementation defined behavior. The unique ID happens to be constructed currently from the system name and a time stamp. That scheme could change in a different version of Asterisk and so long as the value is unique across space/time, it would still be valid. On top of that, it has no bearing on the call count, which is an integer that is atomically increased in a completely different section of the code. Channels can be created for all sorts of purposes that you would never see as well (dummy channels, for example, are created for variable substitution) - there is no actual relationship between the unique ID and the call counter in {{pbx}}. This feels a bit brittle - I'd look into finding a different way to perform the load balancing. What is actually doing the calculation to determine the PSTN gateway? Is it an external script (since it's querying for the call count using the CLI), or is it done in dialplan? It feels like this could be done easily in the dialplan using the [GROUP|https://wiki.asterisk.org/wiki/display/AST/Function_GROUP] and [GROUP_COUNT|https://wiki.asterisk.org/wiki/display/AST/Function_GROUP_COUNT] functions. In fact, you could even be a bit more precise as to how many channels are currently directed to a PSTN gateway. If you had two groups of channels - one for each gateway - you could look at the GROUP_COUNT on each group to see which PSTN gateway had more/less channels and direct the channel to the right gateway. That would be a better load balancing situation, as it would keep the distribution of channels balanced even in the presence of long running calls. By: Ross Beer (rossbeer) 2013-04-06 12:17:42.854-0500 The issue with GROUP_COUNT is that it doesn't account for channels correctly if you are process a lot of calls per second. It doesn't seam to lock the variable when updating. By: Joshua C. Colp (jcolp) 2013-04-08 06:39:12.848-0500 The group count functionality doesn't increment or decrement a variable. When you request the count it counts how many instances there are of that group in the system. Between the time that happens and you then act on it it is of course possible for the count to become inaccurate if there is a large number of calls per second and teardowns. To get perfect distribution is incredibly hard. By: Matt Jordan (mjordan) 2013-04-08 06:46:06.097-0500 You can always use the [LOCK|https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Function_LOCK] function to prevent multiple channels from accessing the GROUP_COUNT at the same time. By: Matt Jordan (mjordan) 2013-04-12 08:20:03.517-0500 So, I don't have any additional comments on this issue. There are numerous ways in which the 'call count' in Asterisk will be incremented in ways that someone might not expect: * If the calendaring module is in use * If out of call messages are being processed * If any masquerade do to an asynchronous Goto (Redirect, Transfer, etc.) occurs As such, I don't foresee any attempt being made to change this behavior. Any change made would be brittle and prone to additional breaking. Asterisk should not be in the business of attempting to decide what a 'call' consists of - rather, the existing dialplan functions should be used to make that determination. Since those ways do exist - and can be performed atomically with the appropriate dialplan functions - it feels like there are other, better ways to group channels together to make the business decisions you need to make. As such, I'm closing this out as "Workaround Available". If you'd like to have further discussion about this issue, it might be best to ask the Asterisk community on the mailing lists for either (a) alternate ways to achieve what you're looking to do, or (b) a patch that provides the functionality you desire.