[asterisk-users] Asterisk 1.4 & Polycom buddy status

[Anthony Rodgers]

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
>