The inclusion of the state_interface option in queues allows a queue member to be associated with a specific device state and was introduced to get around several issues particularly when using Local/nnn type queue members. However, it does not solve all issues since some queue members can not be associated with a single device state and to further complicate things, the desired association can be dynamic in nature.
One example might be a queue member Local/2000 who's hint state is represented as:
exten => 2000,hint,SIP/2000&Custom:DND2000
where the Custom:DND2000 is a custom device state used by a server side Do Not Disturb feature code. This can be further complicated if this same user can dynamically log into alternate phones (hot desk-ing). So that same hint, upon logging out of one phone and logging into a different phone might now become:
Given this situation, which is how FreePBX works and manages hot desk-ing as well as enhancing hints with server side feature codes, the current state_interface implementation is not adequate to solve all situations.
I have submitted the above patch for the Queue application that enhances the state_interface option in both queues.conf and AddQueueMember() so that an Asterisk hint can be supplied instead of a single device. The patch recognizes the following syntax:
HINT:nnn[@context] (defaults to "@default" if no context is supplied)
such that the above scenario for a queue member could be written as:
and with that, the hint status will be used for that queue memeber solving all the above problems. I would be very interested in feedback wrt to this patch Not being a seasoned Asterisk coder as well as many years rusty with C programming, I'm sure it can use some work. However, I believe this capability is a needed addition to really solve the full set of problems that were initially tackled with the inclusion of the state_interface capability and I would also hope that once introduced and tested, the same logic that had state_interface back-ported to 1.4 as solving a very real bug (e.g. added a new feature to solve a series of bugs) will be considered to back port this since the current implentation still does not solve all the issues that it set out to address, as described above.
The patch can be found in this ticket, I will note though that this patch is against 1.4 svn head and not trunk, as the system I am currently testing on is 1.4 and not 1.6 based. (Though I suspect it is probably a fairly straight forward port to trunk).
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum