Summary:	ASTERISK-14447: [patch] [regression] iaxclient (tested with Zoiper) registered to asterisk shows devicestate Unavailable instead Not-InUse
Reporter:	nenadr (nenadr)	Labels:	patch
Date Opened:	2010-01-10 14:58:29.000-0600	Date Closed:
Priority:	Minor	Regression?	Yes
Status:	Open/New	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) devicestate.c.diff
Description:	Testing some queue configurations showed that IAX client which is correctly registered and reachable by asterisk, and "hinted" with exten => 123,hint,IAX2/123 is incorrectly shown as Unavailable (instead Idle) with 'core chow hints' when it is not in a call (rest of states are shown correctly (Ringing, InUse)). ****** ADDITIONAL INFORMATION ****** Looking at ast_device_state() it calls channels devicestate handler iax2_devicestate() and it returns decision weather peer is in use, to ast_parse_device_state() which determins that iax peer is not in a active channels list, but still returns status of Unavailable, which is IMHO wrong. Small patch provided to fix this issue. Tested with Zoiper and works fine.
Comments:	By: Sebastian Gutierrez (sum) 2010-02-13 13:18:02.000-0600 16822 related as you said, the patch works perfect. how can we help to move this issue forward so it gets 1.6.2.3? tested with iaxlite By: Leif Madsen (lmadsen) 2010-03-02 15:55:41.000-0600 Russell isn't entirely sure this is really an issue, and that this is likely expected behavior: "After looking through this, it's not clear if there is actually a problem here. This appears to be exactly what we would expect, and we also do not expect any problems with using IAX2 queue members, even though it will say "Unknown"." Can you clarify if there is a problem here? By: Sebastian Gutierrez (sum) 2010-03-03 05:55:14.000-0600 expected beheavior is that the peer is in unknown state while is not in use?? I have qualify yes, sip peers and previous versions show the state correct. Then if this not a problem when am I going to see an iax peer not in use? (using queue show) By: Sebastian Gutierrez (sum) 2010-03-05 07:31:16.000-0600 any comment on this issue? By: Leif Madsen (lmadsen) 2010-03-08 12:51:54.000-0600 No comments on this issue. If this was working in a previous version, then I'll mark this as a regression. I'm not sure that IAX2 really supports channel device states like chan_sip does though. By: Leif Madsen (lmadsen) 2010-03-08 12:53:10.000-0600 Actually ya, it appears that implementing device states for chan_iax2 is what would really be required to fix this issue properly, so I'm not sure how this was working before (luck?) Because we don't have proper device state handling in chan_iax2, then even if this was to be implemented, this would only be done in trunk. By: nenadr (nenadr) 2010-03-09 00:03:29.000-0600 As far as I can read devicestate.c and chan_iax.c source, there are device state callbacks in chan_iax, and reading code commnets in devicestate.c just a few lines above the proposed patch in this issue gave me an idea for the patch itself (see additional information section). It has been tested in many many call scenarios to/form iax and other technologies while I was makinig new set of dialplan scripts for company pbx, and I didn't saw it breaking anything regarding device states for any technologies. By: Russell Bryant (russell) 2010-03-09 12:52:25.000-0600 While the text says "unknown", app_queue should continue to work properly.  If that is not the case, please clarify the call scenarios that are not working properly.  As indicated in previous updates, this is a side effect of the device state handling for IAX2, but will not cause problems as far as I know. The patch to the devicestate core is not something we can do as it will change behavior in many cases. By: nenadr (nenadr) 2010-03-09 14:29:24.000-0600 Russel, sorry for reopening this but you didn't give me a chance to answer your question: I was testing it with zoiper IAX softphone added as queue member with state_interface set IAX2/123 and there is a 123,hint,IAX2/123 (I need to use state_interface with all my SIP client based agents as well as IAX based ones), and in that case state of iax agent is set to "Unavailible" (notice: Unavailible NOT Unknown) when it is registered and free (not in a call) and queue doesn't send calls to that softphone. Other states (ringing, InUse are shown OK).... I thought it was clear enough in Description and Additional Information sections :). Meybe devicestate core is not the right place to fix this, but I realy didn't noticed any regressions regarding devicestates with this patch on SIP, DAHDI and IAX2 tech based calls in last, almost, 2 months. Never the less, problem with iax clients and queue is "somewere out there", and it is confirmed in separate bug reported by other user (bug 16822). By: Marc Jauvin (mjauvin) 2010-10-24 08:13:56 I confirm that when IAX2 devices are listed as 'Unknown', app_queue won't ring the device as it should. This patch resolves the problem for me. Also note that the code for devicestate.c in 1.4.xx was doing exactly the same as this patch: i.e.   res = ast_parse_device_state(device);   /* at this point we know the device exists, but the channel driver      could not give us a state; if there is no channel state available,      it must be 'not in use'   */   if (res == AST_DEVICE_UNKNOWN)      res = AST_DEVICE_NOT_INUSE; By: Marc Jauvin (mjauvin) 2010-10-24 11:35:24 This is also present in release 1.8.0, so the issue's version should be changed to reflect this. By: David Brillert (aragon) 2016-04-21 11:05:42.266-0500 Just ran into this problem in Asterisk 11.16 Will someone update the patch and put it into gerrit for review?