[asterisk-users] Asterisk 1.4 & Polycom buddy status

[James Fromm]

Olle E Johansson wrote:
> 
> 26 jan 2007 kl. 16.31 skrev 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.
> 
> If you are using chan_agent as a proxy channel, check if that changes 
> things.
> 

We don't have agents defined so I don't think chan_agent applies.  The 
Queue's members are assigned through the management port from an 
application running on the the agent's PC.  I think the Queue 
application loses sync to the SIP channel driver's information 
containing the state of the SIP interfaces.