|Summary:||ASTERISK-06449: Polycom 601 returns Internal Server Error 500 in response to SIP NOTIFY messages|
|Reporter:||Mike Pollitt (mikepollitt)||Labels:|
|Date Opened:||2006-03-01 19:23:46.000-0600||Date Closed:||2006-05-04 10:08:55|
|Environment:||Attachments:||( 0) pcom601-500ise.trace.txt|
( 1) sipdebuglog.txt
|Description:||A Polycom 601 handset is set up with the "buddy watch" (SIP hints) feature, subscribing to 7 extensions (the maximum allowable in the Polycom firmware). When a phone change state and a notify message is sent, the handset responds with an Internal Server Error 500. Thereafter, the buddy watch feature is inoperable on the Polycom handset.|
****** ADDITIONAL INFORMATION ******
I think this is the same bug as 5164. Sorry I didn't know how to re-open that bug and attach more info.
|Comments:||By: Olle Johansson (oej) 2006-03-02 02:10:12.000-0600|
Can you repeat this? Can anyone else repeat this?
There's a lot of missing headers in your SIP debug output...
By: Olle Johansson (oej) 2006-03-07 14:58:20.000-0600
Need a complete report or I will have to close this.
By: Mike Pollitt (mikepollitt) 2006-03-07 16:04:18.000-0600
I've just re-registered the phone and I'm logging everything now with debug turned on. Will post the relevant sections once the problem recurs.
By: John Laur (gork) 2006-03-08 10:38:32.000-0600
I am seeing 500's from Polycom 601's also; I will try to get a relevant trace as well.
My subscriptions all seem to continue to function though. Perhaps this is a problem with Polycom's limiting of this feature to 7 subscriptions?
By: John Laur (gork) 2006-03-08 11:19:03.000-0600
I have added a trace to show the sip chatter when this happens.
In this case, I'm debugging only the peer at .150 which is SIP/2003 though you cans see some verbose messages from asterisk where the problem occurs on other SIP peers. I have included a 'show hints' output as well.
No state change had happened at this point; this will occur periodically. Hope this helps.
By: Olle Johansson (oej) 2006-03-08 13:12:47.000-0600
I guess someone has to ask Polycom why the phone returns this error. I can't see what's going wrong here.
By: John Laur (gork) 2006-03-08 15:12:10.000-0600
I'm fairly positive that the Polycom is having an issue with the XML, but for the life of me I can't see what it is either. I have just made asterisk print SIP 500 errors at a higher verbose level because I'm sick of looking at it :)
This is like the fourth bug dealing with polycoms and the XML presence responses; it's almost assuredly a Polycom problem, but it's doubtful that many people have access to the people at Polycom who need to hear about it. Isn't Digium some kind of partner? :)
By: Olle Johansson (oej) 2006-03-08 15:20:21.000-0600
Will see if I can get hold of someone in Polycom... Hang on.
By: Mike Pollitt (mikepollitt) 2006-03-15 18:26:46.000-0600
After rebooting the Polycom 601, this problem did not recur until Asterisk was restarted. Unfortunately I don't have logs covering that period, but will try to reproduce.
By: John Laur (gork) 2006-03-22 17:00:11.000-0600
This bug is quite possibly *related* to bug http://bugs.digium.com/view.php?id=6047 however I still believe it is a seperate issue. Whenever the phone sends the 500 it seems to bug out and sometimes misses other SIP messages sent to it.. I have had reports of the phone continuing ringing after the caller has hung up and other similar behavior.
By: David Doan (evanrude) 2006-03-22 17:11:57.000-0600
I am seeing this same bug on Polycom IP 500/501 Series Phones as well.
By: Dan Hollis (bani) 2006-03-28 18:01:12.000-0600
i am also seeing this problem on our polycom 601's. asterisk 1.2.6.
By: Olle Johansson (oej) 2006-03-28 18:05:50.000-0600
All of you - can you find a pattern, a way to force this to happen?
We can't repeat this.
By: Dan Hollis (bani) 2006-03-28 18:10:10.000-0600
havent found any way to repeat it 100% on demand.
would a tcpdump of it happening help any?
By: Olle Johansson (oej) 2006-03-28 18:31:19.000-0600
I don't think a tcpdump would help, thank you for offering it. I need to know what causes this to happen if Asterisk in any way causes this to happen if it's not a bug in Polycom firmware.
By: Gerhard Venter (gventer) 2006-03-28 19:08:24.000-0600
I am getting the same on Polycom 501. Here is how I reproduce it and it is actually causing me some headaches because it does not generate AMI unlink events.
Make a call from an outside line to create a Zap channel and then instead of using the # key to transfer the call use the "Transfer button" on the Polycom phone. Either one will work, the "transfer button" or the "soft transfer key". This will create a attended transfer in contrast with the # transfer which is a blind transfer. Enter the extension to transfer to and then when the person on the other side picks up hit the transfer button again (that is the physical transfer button on the phone). Right after that will see the "Got SIP Response 500" on the console.
It is creating big problems for me as it does not generate the Unlink events send via AMI and whenever somebody does a transfer like that my switchboard application is all messed up. Blind transfers seems to work just fine.
By: Olle Johansson (oej) 2006-04-05 11:14:26
Please test with latest version of svn trunk. I added a tag to the NOTIFY that may be the problem.
By: Serge Vecher (serge-v) 2006-05-04 10:08:55
No response from reporter. Presumably fixed by OEJ. Reopen if not the case.