[asterisk-users] Asterisk 1.4 & Polycom buddy status

[James Fromm]

Olle E Johansson wrote:
> 
> 24 jan 2007 kl. 18.10 skrev Eric "ManxPower" Wieling:
> 
>> James Fromm wrote:
>>
>>> The behavior we see is that the SIP interface in the queue will 
>>> sometimes not release from the in-use state.  Connecting to the 
>>> interface from another SIP device and immediately hanging up will 
>>> clear the state.
>>> The phones in question are configured with one line that will except 
>>> only one call.  The device itself does not think it is in-use because 
>>> it will accept another call.  Something in the SIP channel driver is 
>>> not clearing the state when a call is completed.
>>> There is definitely no correlation between this and Asterisk 
>>> restarting.  In fact, if a device is 'stuck' on in-use, restarting 
>>> Asterisk will clear the state.
>>> I've been working on this for a week now.  It only started for us 
>>> because I just implemented the call-limit option in the sip.conf in 
>>> Asterisk for the devices.  See my posts with subject 'Queue and 
>>> Interface time out'.
>>
>> I believe there is/was a bug relating to call-limit.  Buddy Watch 
>> doesn't work if you use call-limit and if a call from a queue is 
>> transfered, the call-limit is not released until the original call is 
>> terminated.  I do not know if these issues have been fixed or not.
> 
> Again, a relation to call transfer. I think the bug is that we don't 
> handle call-limits properly during a call transfer. That needs
> to be verified and fixed.
> 

There may be, but transfers are not the cause of the issue I describe. 
SIP interfaces that are members of a Queue, will erratically not be 
released from 'in-use' when a call is completed.  I have tested with 
both caller terminated and agent terminated calls and both will cause 
this behavior.  It happens on approximately 20% of all calls the queue 
members receive.  Dialing the SIP device with another device will 
immediately free the status.

I wonder if this only happens on calls sent to the SIP device by the 
Queue application.  I will test that today.