[asterisk-dev] devicestate

[Mark Michelson]

Johansson Olle E wrote:
> 16 jan 2008 kl. 15.56 skrev Atis Lezdins:
> 
>> On 1/16/08, Leif Madsen <leif.madsen at asteriskdocs.org> wrote:
>>>> I agree for real devices. However i wonder - why i can't change  
>>>> state
>>>> for Local channels.
>>>>
>>>>
>>> Funny enough, I had this same issue today within Queue(). I'm using
>>> queue_member in extconfig.conf (realtime members) which delivers  
>>> calls
>>> to a Local channel which then finds the physical location in the  
>>> cluster
>>> and delivers the call there. The problem I was having was that when  
>>> the
>>> Local channel would be ringing a device, the device status was set to
>>> (Unknown), which would cause that same device to be called multiple
>>> times when there were multiple people waiting in the Queue().
>>>
>>> Once the call was answered the status changed to In Use, and then
>>> everything worked as expected. I had a patch made that caused  
>>> Queue() to
>>> not deliver calls to members with a status of Unknown -or- In Use,  
>>> and
>>> that solved my problem for now, but not entirely sure what issues  
>>> I'll
>>> run into in the future because of it :)
>> This probably starts getting -user'ish..
>>
>> I'm working on this for last month already - how do you get Local
>> channel to get state INUSE? All i got - that it's in state RINGING
>> when it executes Dial(). Otherwise - NOT_INUSE.
> I would guess that the local channel is gone at answer time
> because of the way this proxy channel works. That's why it
> never reports INUSE for you.
> 
> I think there's a switch you can add to the local/ dialstring
> to force the local channel to stay in the call - "/n"
> or something similar.
> 
> /O

You are absolutely correct in your analysis. The problem is that this isn't the 
be-all end-all solution because of silliness that happens when transfers occur. 
The most commonly seen problem is that when a member defined as a local channel 
with the /n on the end transfers a call, that member cannot receive any new 
calls until the transferred call completes.

The solution for this is what Kevin pointed out earlier in this thread which is 
implemented in Asterisk trunk.