I see.  So the registrar crash issue might be the same thing you are 
encountering.  Lets see where the new build would bring us.

On 06/14/2011 07:07 PM, Tony Graziano wrote:
> 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/
>>>>
>>>
>>
>
>

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/

Reply via email to