Summary: | ASTERISK-18350: meetme join causes spontaneous Polycom phone reboot | ||
Reporter: | David Brillert (aragon) | Labels: | |
Date Opened: | 2011-08-26 13:03:25 | Date Closed: | 2011-09-21 08:25:28 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Applications/app_meetme |
Versions: | 1.8.5.0 | Frequency of Occurrence | Frequent |
Related Issues: | |||
Environment: | User-Agent: PolycomSoundPointIP-SPIP_550-UA/3.2.5.0508 | Attachments: | ( 0) debug_4149_meetme_trace_g711_no_reboot.log ( 1) debug_4149_meetme_trace_g722_with_reboot.log ( 2) debug_4149_meetme_trace_no_audiohook_g722_reboot1.log ( 3) polycom_reboot_during_meetme.txt |
Description: | Extension 4149 dials *800 in dial plan to join meetme conference and immediately after joining bridge Polycom phone reboots. SIP trace attached | ||
Comments: | By: David Brillert (aragon) 2011-08-26 14:09:22.848-0500 phone reboot occurs after caller records name and presses 1 to accept when Allison says "thank you". Strangely reproducible almost 100% of the time. Only seems to be a problem when using g722 codec. By: David Brillert (aragon) 2011-08-26 14:11:31.262-0500 Using dahdi timing module By: David Brillert (aragon) 2011-08-26 14:16:58.882-0500 And if I enabled debug in logger I get a huge amount of CLI spamming (hundreds or thousands per second) after dialing meetme. [2011-08-26 12:13:38] DEBUG[2140]: audiohook.c:227 audiohook_read_frame_both: Read factory 0x9411c60 and write factory 0x9412688 both fail to provide 160 samples By: David Brillert (aragon) 2011-08-26 14:25:41.668-0500 uploading two logs where same phone is used to cause a Polycom reboot by dialing meetme. g711u does not cause a reboot but g722 is very easy to reproduce. Full SIP and debug output in each file. By: David Brillert (aragon) 2011-08-26 14:26:32.100-0500 Always reboots at end of thank you prompt By: David Brillert (aragon) 2011-08-26 14:33:53.256-0500 and the CLI continues to spam audiohook debug even after then phone is reboots. Until I restart asterisk. By: David Brillert (aragon) 2011-08-26 14:35:11.729-0500 disabling audiohook options gets rid of the spam but not the reboot problem. By: David Brillert (aragon) 2011-08-26 14:39:50.690-0500 new g722 debug trace uploaded without any audiohook options. By: David Brillert (aragon) 2011-08-26 14:41:11.557-0500 audiohook spam occurs because after the phone reboots Asterisk does not realize the SIP peer has gone away. This is not related to the bug report regarding the Polycom reboots so can be ignored. By: David Brillert (aragon) 2011-08-26 14:43:02.795-0500 marshall please delete attachment debug 4149 meetme trace no audiohook g722 reboot.log since it contains confidential IP's. I will upload a new trace. By: David Brillert (aragon) 2011-08-26 14:48:07.365-0500 scrubbed trace upload By: Richard Mudgett (rmudgett) 2011-08-26 14:56:39.176-0500 Deleted "debug 4149 meetme trace no audiohook g722 reboot.log" per request By: Leif Madsen (lmadsen) 2011-09-14 15:33:22.341-0500 Some dialplan that shows what you're doing so I can try to reproduce this would be helpful. By: David Brillert (aragon) 2011-09-16 07:55:45.782-0500 Hi Leif Typical conference bridge setup. To reproduce you must set your codec priority to g722. The reboot only occurs when the phone negotiates g722. The reboot occurs exactly when users enters PIN and Allison says "thank you". By: David Brillert (aragon) 2011-09-16 08:06:02.448-0500 meetme.conf [rooms] conf => 1,12341234 dialplan /etc/asterisk/default/extensions-apps.conf Meetme exten => *800,4,Meetme(1,TMi) By: Leif Madsen (lmadsen) 2011-09-19 15:23:44.613-0500 I can't reproduce this with my Polycom IP335 using version 3.3.1.0933. I looked at your trace and tried to reproduce exactly the same way, and everything works exactly like it should. By: David Brillert (aragon) 2011-09-19 15:30:03.718-0500 This is remarkably easy to reproduce on customer site but I have had no success reproducing in my lab. I removed the G722 codec from the customer site and all is working fine with G711. I don't know how to debug this any further so might as well close this bug report out... By: David Brillert (aragon) 2011-09-21 08:25:28.508-0500 Cannot reproduce in lab environment. Unable to debug further at production site. Nothing in the trace appears to explain what is going on. |