registrations started failing because the registrar was "stopped" or in a "failed" state. There were no alarms, and the failure could be observed with sipxproc or in the sipxconfig ui 9services), but no details were provided in sipxconfig as to why. When registrations expired, they could not renew...
On Tue, Jun 14, 2011 at 7:03 AM, Joegen Baclor <[email protected]> wrote: > The crash is easily reproducible. the first attempt of the registrar to > route an INVITE makes it crash. As far as what you have experienced with > TLS enabling is concerned, there was not much information as what was meant > by "registrations started failing". If there are still problems after the > patch are all in, I think a jira is in order. > > > On 06/14/2011 06:55 PM, Tony Graziano wrote: >> >> It's OK with me. >> >> I mentioned I had briefly tested to see the records were added, but >> since my test was brief, I didn't run into the same issues as the >> registrar failure until much later. >> >> If a separate RPM can be provided, it might be easier to test as a >> filed patch. Can someone indicate what the "undesired" result in the >> registrar would be (from a logging standpoint) so it can be observed >> that it no longer occurs? >> >> >> >> On Tue, Jun 14, 2011 at 6:26 AM, George Niculae<[email protected]> wrote: >>> >>> On Tue, May 31, 2011 at 4:11 PM, Tony Graziano >>> <[email protected]> wrote: >>>> >>>> I took just the three RPM's. I did a test migration talking all the >>>> rpm's one time briefly, but was having other issues so I rolled back >>>> to 4.4.0 stable and then took just the three. There were no details >>>> why regitrar failed, though I have seen this on another production >>>> system (registrar fails silently, kicking no alarms). Unfortunately I >>>> can see nothing in logs that indicates why. As a matter of fact you >>>> have to view the registrar from the sipxconfig UI to see the failure >>>> and can restart it. The details link says "no details" though. Over a >>>> period of time the registrations are expiring on the phones though. >>>> >>>> That was also in a larger environment where I thought it was related >>>> to the RLS patch being needed. >>>> >>>> So my real question is, does the RLS patch have anything to do with >>>> whether or not the registrar works properly or not in this case? >>>> Somehow I am leading myself to this conclusion, but am not sure if it >>>> makes sense. >>>> >>>> I did not notice the A record issue within the sipxproxy logs and did >>>> notice the tls record was now populated in the dns zone though. >>>> >>> There were some issues with enabling only _sip._tls SRV record for SIP >>> domain that causes sipxregistrar crash, see >>> http://track.sipfoundry.org/browse/XX-9656. Joegen pushed in a fix for >>> and I merged back the TLS SRV sipXconfig work done in >>> http://track.sipfoundry.org/browse/XX-9639. Tony, is it OK with you if >>> we'll spin new 4.4 RPMs and use the same procedure for test? >>> >>> Thanks, >>> George >>> _______________________________________________ >>> sipx-dev mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>> >> >> > > -- ====================== 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-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
