Summary:ASTERISK-04948: Device state handling is broken
Reporter:Cyril VELTER (velter)Labels:
Date Opened:2005-08-31 14:36:54Date Closed:2008-01-15 15:46:49.000-0600
Versions:Frequency of
Description:when adding a IAX2 member to a queue, its state does not reflect reality. It detect properly the registration but calls are never detected, causing app_queue for example to beleive that the device is free to get a new call.


It seems that ast_parse_device_state in  device.c assume that a channel name follow the naming convention DEVICE-XXX (note the dash at the end). It's not true for IAX Channels wich are named DEVICE@HOST-XXX.
Comments:By: Kevin P. Fleming (kpfleming) 2005-08-31 14:40:12

Not on my systems they are not... the channels are named:


where 'test1' and 'test23' are the device names. Can you post a 'show channels' output from your server showing the channel names you are referring to?

By: Kevin P. Fleming (kpfleming) 2005-08-31 16:19:55

Ahh... this would be true if the IAX2 username is not the same as the name of the 'user' context in iax.conf.

By: Cyril VELTER (velter) 2005-08-31 17:45:31

my IAX2 channels have names like :


the relevant iax.conf part

callerid="XXX" <YYY>

the peer is a iaxclient based softphone

By: Kevin P. Fleming (kpfleming) 2005-08-31 18:13:29

After consultation with Mark, we have decided to remove the 'username@' prefix from the channel names, since it is not providing any real value. This will cause the channels to match the normal device names, and should resolve this issue.

By: Cyril VELTER (velter) 2005-09-01 07:28:10

OK, that was only part of the problem. The devicestate does not get updated.

After digging a bit in the code, I think there is two problem :

* In chan_iax2.c iax2_devicestate return AST_DEVICE_NOT_INUSE if there is a valid registration. But in this case, devicestate.c won't check a channel existance I think we should replace

     if (p->historicms == 0 || p->historicms <= p->maxms)
        res = AST_DEVICE_NOT_INUSE;
        res = AST_DEVICE_UNKNOWN;       /* Not reachable


     if (p->historicms == 0 || p->historicms <= p->maxms)
        res = AST_DEVICE_UNKNOWN;

to let devicestate.c check a channel existance if a valid registration is found

* in devicestate.c, ast_parse_device_state return AST_DEVICE_UNKNOWN when no channel is found for the device. At this point it should return AST_DEVICE_NOT_INUSE (as its called after the tech specific devicestate, we know the device is available. If there is no channel on it, we known it's not in use).

Comments ?

By: Cyril VELTER (velter) 2005-09-01 07:43:24

Another point is that the RINGING->INUSE transition is not handled (a called device will stay in the RINGING state even when answered) because in channel.c, ast_setstate only call ast_device_state_changed if the old state is AST_STATE_DOWN.

I have confirmed that this problem also occur on Zap and SIP channels.

By: Kevin P. Fleming (kpfleming) 2005-09-01 18:27:49

All fixed in CVS HEAD. Nice debugging work!

By: Cyril VELTER (velter) 2005-09-02 14:19:23

It's getting better :=), but there is a little glitch remaining. When the tech doesn't have a specific devicestate function, the current code path doesn't check for res==AST_DEVICE_UNKNOWN and an unused device (Zap for example) will came up as Unknown.

If you don't want to check this case in ast_parse_device_state, you should do it more globaly in ast_device_state :

       /* Does the channel driver support device state notification? Ask for it*/
       if (chan_tech->devicestate)
               res = chan_tech->devicestate(number);
               res = AST_DEVICE_UNKNOWN;

       /* No state given by the channel driver, test for channel existance */
       if (res == AST_DEVICE_UNKNOWN)
               res = ast_parse_device_state(device);

       /* at this point we know the device exists, but the channel driver
          could not give us a state, and there is no live channel state available,
          it must be 'not in use'
       if (res == AST_DEVICE_UNKNOWN)
               res = AST_DEVICE_NOT_INUSE;

       return res;

By: Kevin P. Fleming (kpfleming) 2005-09-02 15:08:57

That's not correct. If there is no chan-specific devicestate function, we cannot know that the requested device exists at all. We can only prove that it does exist by using the presence of active channels; without channels, AST_DEVICE_UNKNOWN is the proper result.

By: Cyril VELTER (velter) 2005-09-02 19:48:50

Yes, you are right that make perfect sense. What we need is a devicesstate function for Zap channels which will check the channel existance and return AST_DEVICE_INVALID if the channel does not exist and AST_DEVICE_UNKNOWN if it exist.
As far as my work on app_queue is concerned (this was the first reason of this issue, IAX channel were not handled correctly at all) by the devicestate machinery, everything is now OK (Unknown devices are treated as available ones), but for complete correctness we need this devicestate function at least for chan_zap. It will also allow app_queue to validate members interface (either by rejecting INVALID ones or emitting a warning).

What do you think ? I will have a look at chan_zap to estimate the complexity of such a function.

By: Michael Jerris (mikej) 2005-09-02 21:28:16

I am going to close this issue out as fixed for now as the issue as reported in IAX has been resolved.  Please open up a new bug for expanding the device state capabilities in zap when you have somthing ready to review.  If you need some assistance as you go, try the -dev mailing list or irc in #asterisk-dev.  Good luck!

By: Digium Subversion (svnbot) 2008-01-15 15:46:33.000-0600

Repository: asterisk
Revision: 6477

U   trunk/channels/chan_iax2.c

r6477 | kpfleming | 2008-01-15 15:46:33 -0600 (Tue, 15 Jan 2008) | 2 lines

stop adding 'username@' to incoming IAX2 channel names, so that they can be properly matched in the device-state system (issue ASTERISK-4948)



By: Digium Subversion (svnbot) 2008-01-15 15:46:49.000-0600

Repository: asterisk
Revision: 6496

U   trunk/channel.c
U   trunk/channels/chan_iax2.c
U   trunk/devicestate.c

r6496 | kpfleming | 2008-01-15 15:46:48 -0600 (Tue, 15 Jan 2008) | 2 lines

various devicestate fixes (issue ASTERISK-4948, take two)