[asterisk-dev] app_queue device state tracking of IAX2 interfaces

[Simon Kirby]

We use dynamic queue agents for both local and remote agents.  Local
agents (in the local office) typically use SIP, and are dynamically added
to the queue with an interface string such as "SIP/123".  Remote agents
(in a remote office) are reached via IAX, and are dynamically added to
the queue with an interface string such as "IAX2/chicago/123".

In the past, we depended on the fact that IAX2 device state tracking was
broken and implemented a simple dialplan check to return Busy from the
remote side if the remote SIP device is on a call:

[macro-one-call-only]
exten => s,1,GotoIf($[${SIPPEER(${ARG1}|curcalls)} > 0]?2:3)
exten => s,2,Busy  
exten => s,3,NoOp

This and "ringinuse=no" allowed us to not dial agents already on calls.
However, as of about 1.4.10, IAX2 device state tracking started
"working".  Unfortunately, it is working on the "IAX2/chicago" level, and
not on the "IAX2/chicago/123" level.  The problem is that we are using:

	SIP/123
	IAX2/chicago/123

as agent interface strings.  The device state tracking is seeing:

	SIP/123
	IAX2/chicago

...and all IAX2/chicago queue agents become "in use" as soon as one
IAX2/chicago call is connected.

At the same time, a bug in at least 1.4.11 results in the initialized
device state to be not in use, even if there are IAX2/chicago calls in
use.  The device state tracking "changethread" registered in app_queue.c
is parsing device state changes differently than the ast_device_state()
call made in create_queue_member().  Example: If I add IAX2/chicago/111
while on the horn to IAX2/chicago/999, the queue member state is "Not in
use".  If I hang up and redial the call to IAX2/chicago/999, the queue
member state changes to "In use".

This bug can be fixed by simply making one device state check behave like
the other, but what is the "correct" behaviour?

If the device state were to track the entire interface string, eg.
"IAX2/chicago/123", this would work as we wish.  Right now it is trying
to track just the "peer" part, IAX2/chicago.  We could change our remote
offices to have one IAX peer entry per extension, but that would be
unmaintainable.

What is the problem with tracking the entire interface string?  Is there
ever a case where a device which only has one line is going to have
different extensions specified anyway?

Use of chan_local was suggested.  This would work for us in Asterisk
trunk, but the 1.4 branch does not yet have the device state support
merged.  A combination of chan_local and the GROUP_COUNT function, as
documented in queues-with-callback-members.txt, would work if we specify
"ringinuse=yes" for all queues, but we are then basically reimplementing
the wheel for code that is already there but doesn't quite work.

Cheers,

Simon-