I tried but could not get it to happen yesterday. The only change I've made was putting the sip domain back into automatic mode (hence I did not have the A record) as a result of taking in updates. I will have to look back into this. It's on a vlan and separate subdomain. It IS connected via an ipsec tunnel though. I'll have to spend a few hours trying and tracking to find the instance where I can make it happen again and again to see if adding an A record makes a difference or more information can be provided.
On Fri, Jun 24, 2011 at 7:53 AM, Michael Picher <[email protected]> wrote: > Additionally, I've run into instances where, even with the phones on their > own VLAN, I had to put a firewall between the Data VLan and the Phone VLan. > I never tracked down the exact culprit but that eliminated the reboots. > > On Thu, Jun 23, 2011 at 6:20 AM, Douglas Hubler <[email protected]> wrote: >> >> Tony, >> >> I'm not sure if this is the same, but... >> >> There was a customer that had an issue where 50 percent of about 100 >> polycoms would randomly lockup. They were not on calls at the time, >> just out of the blue lock-ups. I never tracked down the ultimate >> problem, but did come up with a workaround. I removed all SRV records >> and used just a single A record avoided the lockups. In this case, >> customer didn't need HA so we could do this. >> >> I discovered this because the last log message in polycom phone log >> was a SRV record lookup. >> >> >> On Thu, Jun 23, 2011 at 5:56 AM, Tony Graziano (JIRA) >> <[email protected]> wrote: >> > Polycom phone rebots after 10-14 minutes on a call >> > -------------------------------------------------- >> > >> > Key: XX-9724 >> > URL: http://track.sipfoundry.org/browse/XX-9724 >> > Project: sipXecs >> > Issue Type: Bug >> > Components: Polycom, sipXbridge, sipXproxy >> > Affects Versions: 4.4 >> > Environment: 4.4 installed from ISO all patched up, polycom >> > firmware 3.1.3, 3.2.4, 3.2.5 >> > Reporter: Tony Graziano >> > >> > >> > I am finding my polycom 650 reboots if i am on a call "more than" ten >> > minutes. I have gone back to CDR data and looked at the failed calls (which >> > only show COMPLETED) and find they are 10, 12 or 14 minutes long thus far. >> > The phone is not remote in this case either. It is using a sip trunk, but >> > have tried several POPS. Calls through analog ATA's stay up and do not >> > reboot. >> > >> > The phone does have several "external lines on it". >> > >> > I will grab sip traces and log files and post after I verify it happens >> > without external lines on it or not. >> > >> > If you are also having the same type of issue details would also be >> > appreciated. >> > >> > -- >> > This message is automatically generated by JIRA. >> > - >> > If you think it was sent incorrectly contact one of the administrators: >> > http://track.sipfoundry.org/secure/Administrators.jspa >> > - >> > For more information on JIRA, see: >> > http://www.atlassian.com/software/jira >> > >> > >> > >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > -- > Michael Picher > eZuce > Director of Technical Services > O.978-296-1005 X2015 > M.207-956-0262 > @mpicher <http://twitter.com/mpicher> > www.ezuce.com > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.326.5325 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
