Hi there,
We traced this issue to transfers (see http://bugs.digium.com/
view.php?id=8848). On Monday, I will be attaching the various debugs
to the case as requested.
Regards,
--
Anthony Rodgers
Business Systems Analyst
District of North Vancouver
Web: http://www.dnv.org
RSS Feed: http://www.dnv.org/rss.asp
On 26-Jan-07, at 5:16 PM, James Fromm wrote:
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.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
