Summary:	ASTERISK-09986: 1.2 version of : 0008943: inUse counter not decremented after hanging up a call which is on hold
Reporter:	Dr James Allen (cyber_monk)	Labels:
Date Opened:	2007-07-30 20:39:36	Date Closed:	2007-08-08 08:28:47
Priority:	Blocker	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Issue 0008943 affecting asterisk 1.4 also happens in asterisk 1.2 starting with release 1.2.16. 1.2.15 does not exhibit the block. When a sip call is put on hold the peer inuse count increments and never gets decremented for the peer that placed the call on hold. Subsequently any extensions that place calls on hold very quickly become unuseable ! This was discovered by a site that uses attended transfers heavily. ****** ADDITIONAL INFORMATION ****** Removing the following change cures the issue :- 2007-02-13 18:35 +0000 [r54179]  Olle Johansson <oej@edvina.net>        * channels/chan_sip.c: Make sure that outbound calls are applied to          the peer. This fixes some issues with "hints not working", but          only in 1.2. This issue I believe was fixed in 1.4 using a new variable : SIP_PAGE2_OUTGOING_CALL A similar fix may be required for 1.2.
Comments:	By: Eliel Sardanons (eliel) 2007-07-31 10:08:24 Yes, you are right, I will upload a patch as soon as I can, but if you want a simple solution try this: on chan_sip.c on function update_call_counter() change: - if (!outgoing && (u = find_user(name, 1))) { with: + if (0 && !outgoing && (u = find_user(name, 1))) { With this patch all the limits will be update on the peer structure. By: Dr James Allen (cyber_monk) 2007-07-31 19:04:13 Excellent elial, my hack caused the users structure to be the onlyone updated but your interim patch and just updating the peer structure means that I have regained control over the number of calls being dispatched to the sip phones and without the hang. I have been trying to spend time figuring out what is going on but not there yet. If I figure it out and or come up with  a graceful solution I'll post it. Thanks again. By: Eliel Sardanons (eliel) 2007-07-31 19:18:21 The problem is that there is a flag to know if the call is INBOUND or OUTBOUND, and when an agent (that receives a call [INBOUND]) puts the call on Hold and then returns the call back (unHold), the channel goes from INBOUND to OUTBOUND and the call-limit that was incremented on the peer (because the call was INBOUND) is decremented on the user, so, the peer call-limit stays in 1 (or more). By: Dr James Allen (cyber_monk) 2007-07-31 20:24:21 I was poking in debug to see what was happening and had three possibilites :- 1) double dec causing overrun 2) dec getting missed cause of hold 3) bitwise contamination is flags Thanks thats gets me closer. So The fix for Issue 0008943 affecting asterisk 1.4 would solve this too. If we mark the call as OUTBOUND at initiation and then use that marker to decide which stucture (user/peer) to dec on destruction of the channel we should always get it right. Okay will target that now as I get time but still can't help thinking there must be a more fluid way of tracking the INBOUND/OUTBOUND switch after hold. Also if I understand this correctly does that mean with a call-limit=1 where a user can only take one incoming (and make one outgoing) call simultaneously, that attended transfers are not possible. Maybe the sip protocol doesn't allow this but should we not have the INBOUND and OUTBOUND revent back to as the were after HOLD is recovered ? Anyway lets get call-limit working as per docs again with HOLD fixed. Cheers. By: Joshua C. Colp (jcolp) 2007-08-08 08:28:47 1.2 is now in a security fixes only state, so thus this bug is closed.