Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-26 Thread 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.

___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-26 Thread Olle E Johansson


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.


/O
___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-26 Thread 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.


___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-26 Thread 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



___
--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


Re: Polycom Firmware -- Was: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-25 Thread Eric Bishop

I second that request

On 1/25/07, Kenneth Padgett [EMAIL PROTECTED] wrote:


 I ran into this problem with an early batch of IP650s.  Polycom's
firmware
 version 2.0.3b made this issue go away.

Speaking of Polycom firmware, anyone have an up to date source for the
stuff? The site I ordered from took down their FTP site that had it.
:(

-Kenneth
___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-25 Thread Olle E Johansson


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.

/O
___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-24 Thread Bryan M. Johns
I ran into this problem with an early batch of IP650s.  Polycom's  
firmware version 2.0.3b made this issue go away.


Thanks,

Bryan M. Johns
Partner
Shelton | Johns Technology Group
office: 678:248:2637 x:1500
direct: 678:229:1809
mobile: 404.259.9216
iaxtel: 700:248:2637 x:1500
http://www.sheltonjohns.com


On Jan 23, 2007, at 10:09 AM, Chris Bullock wrote:

I'm running into an issue w/ Buddy status on Polycom IP650 phones  
using
buddy status (with SIP Hints) on Asterisk 1.4.  Sometimes the  
status on the
phones will stick in the busy status.  I have noticed that I can  
call that
extension  the status will reset (sometimes).  Anyone else  
encountered this

or anything similar.

-Chris

___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-24 Thread James Fromm
We also use Polycom IP650 phones.  They are assigned to our customer 
service department.  Each SIP interface is a member of our customer 
service Queue in Asterisk.


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.


When this happens there is no SIP channel and the SIP peer appears 
normal.  I have been unable to isolate a procedure to duplicate the 
problem.  It happens erratically to all member interfaces throughout the 
day.  I know that removing the call-limit option from the device's 
config will stop the problem.  This will also remove the ability for the 
SIP channel driver to track the device's state so we can't remove it 
permanently.


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'.



James Andrewartha wrote:

Olle E Johansson wrote:

23 jan 2007 kl. 16.09 skrev Chris Bullock:


I'm running into an issue w/ Buddy status on Polycom IP650 phones using
 buddy status (with SIP Hints) on Asterisk 1.4.  Sometimes the status 
on the phones will stick in the busy status.  I have noticed that I

can call that extension  the status will reset (sometimes).  Anyone
else encountered this or anything similar.

I've seen reports on it, but haven't been able to repeat this. I need to 
know a way to force this to happen, repeatably. If I can get that, I can 
propably trace it and fix it.


It can also happen if you have packet loss in the network, of course.


I've seen it happen when asterisk restarts (or possibly even just reloads
SIP) without the phone being restarted - it's generally accompanied by
-- Incoming call: Got SIP response 500 Internal Server Error back from
10.0.0.51
on the console. I think the status gets stuck as available most of the
time, but you don't notice it because that's the default.



___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-24 Thread James Fromm
Our 650s are running 2.0.3b.  The problem still exists for us.  We see 
the devices as members of our customer service queue stick on 'in-use' 
in the Queue application while the device has no active SIP channel and 
will accept calls.  Removing 'call-limit' from the sip.conf in Asterisk 
for the device will fix the issue.  This however will also keep the SIP 
channel driver in Asterisk from tracking the state of the device.


Bryan M. Johns wrote:
I ran into this problem with an early batch of IP650s.  Polycom's 
firmware version 2.0.3b made this issue go away.


Thanks,

Bryan M. Johns
Partner
*Shelton | Johns Technology Group*
office: 678:248:2637 x:1500
direct: 678:229:1809
mobile: 404.259.9216
iaxtel: 700:248:2637 x:1500
*http://www.sheltonjohns.com* http://www.sheltonjohns.com/


On Jan 23, 2007, at 10:09 AM, Chris Bullock wrote:


I'm running into an issue w/ Buddy status on Polycom IP650 phones using
buddy status (with SIP Hints) on Asterisk 1.4.  Sometimes the status 
on the
phones will stick in the busy status.  I have noticed that I can 
call that
extension  the status will reset (sometimes).  Anyone else 
encountered this

or anything similar.

-Chris

___
--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


___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-24 Thread 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.

___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-24 Thread James Fromm
Yeah, we don't use Buddy Watch.  We don't use call-limit because we want 
call-limit.  We use it because it's the only way, that I'm aware of, to 
get the SIP channel driver to monitor the state of the member SIP 
interface.  We use autopause=yes and ringinuse=no in our customer 
service queue configuration.  Without specifying call-limit, the Queue 
application continues to send new calls to member interfaces that are 
in-use or busy.  The SIP device replies to Asterisk saying it's busy and 
the Queue application pauses the member because of autopause.  With 
call-limit enabled and set to any number, the Queue application knows 
that the member interface is busy and will not send new calls.


I replied to this post describing our findings with the Queue 
application because it sounds like the same behavior occurs with hints 
and buddy watch.  The state detection in the SIP channel driver appears 
suspect to me.


Eric ManxPower Wieling wrote:

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.

___
--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


Polycom Firmware -- Was: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-24 Thread Kenneth Padgett

I ran into this problem with an early batch of IP650s.  Polycom's firmware
version 2.0.3b made this issue go away.


Speaking of Polycom firmware, anyone have an up to date source for the
stuff? The site I ordered from took down their FTP site that had it.
:(

-Kenneth
___
--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


[asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-23 Thread Chris Bullock
I'm running into an issue w/ Buddy status on Polycom IP650 phones using
buddy status (with SIP Hints) on Asterisk 1.4.  Sometimes the status on the
phones will stick in the busy status.  I have noticed that I can call that
extension  the status will reset (sometimes).  Anyone else encountered this
or anything similar.

-Chris

___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-23 Thread Olle E Johansson


23 jan 2007 kl. 16.09 skrev Chris Bullock:

I'm running into an issue w/ Buddy status on Polycom IP650 phones  
using
buddy status (with SIP Hints) on Asterisk 1.4.  Sometimes the  
status on the
phones will stick in the busy status.  I have noticed that I can  
call that
extension  the status will reset (sometimes).  Anyone else  
encountered this

or anything similar.

I've seen reports on it, but haven't been able to repeat this. I need  
to know
a way to force this to happen, repeatably. If I can get that, I can  
propably

trace it and fix it.

It can also happen if you have packet loss in the network, of course.

/O
___
--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


Re: [asterisk-users] Asterisk 1.4 Polycom buddy status

2007-01-23 Thread James Andrewartha
Olle E Johansson wrote:
 
 23 jan 2007 kl. 16.09 skrev Chris Bullock:
 
 I'm running into an issue w/ Buddy status on Polycom IP650 phones using
  buddy status (with SIP Hints) on Asterisk 1.4.  Sometimes the status 
 on the phones will stick in the busy status.  I have noticed that I
 can call that extension  the status will reset (sometimes).  Anyone
 else encountered this or anything similar.
 
 I've seen reports on it, but haven't been able to repeat this. I need to 
 know a way to force this to happen, repeatably. If I can get that, I can 
 propably trace it and fix it.
 
 It can also happen if you have packet loss in the network, of course.

I've seen it happen when asterisk restarts (or possibly even just reloads
SIP) without the phone being restarted - it's generally accompanied by
-- Incoming call: Got SIP response 500 Internal Server Error back from
10.0.0.51
on the console. I think the status gets stuck as available most of the
time, but you don't notice it because that's the default.

-- 
James Andrewartha
Systems Administrator
Data Analysis Australia Pty Ltd
___
--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