Even at 50 users the current RLS implementation has problems when 
changing/adding any user attribute. This encompasses everything from setting a 
call forward to changing an email address to adding a new user. Each time one 
of these actions occurs the RLS server completely tears down the active RLS 
list in memory and reloads it from scratch (very inefficient, very 
not-scalable). While this is happening the RLS server "pauses" any new BLF 
events which can cause the park monitors to appear locked because the signal to 
terminate the BLF ringing is never sent.

Hoa, one of our programmers here at Brazos County, recently took on the 
challenge of rewriting the offending code in order to make it more efficient 
and scalable and I think he's done it. I am running the RLS fix he wrote on our 
production system (currently at 270 registered endpoints) and have yet to see 
any of the behaviors that the old RLS implementation exhibited. I can now make 
changes, add users, change user settings, etc. without locking up the RLS 
server (with the current implementation once I got to about 200 or so users the 
RLS server would lock up every time I made a change or added a user). I have 
this fix available as a 64 bit RPM for 4.2.x. If anyone is desperate for it I 
can email it to you. The patch will be put in the tracker shortly.

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Matthew Kitchin 
(Public)
Sent: Wednesday, August 25, 2010 9:54 PM
To: Jim Canfield; Martin Steinmann
Cc: [email protected]
Subject: Re: [sipx-users] Continued park issues.

Have you noticed a particular polycom firmware that is better or worse in this 
scenario? My one site that uses park heavily is 3.1.3C split. I would put them 
in the category of failing once or twice a month. 
-----Original Message-----
From: Jim Canfield <[email protected]>
Sender: [email protected]
Date: Wed, 25 Aug 2010 21:23:05 
To: Martin Steinmann<[email protected]>
Cc: <[email protected]>
Subject: Re: [sipx-users] Continued park issues.

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

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

Reply via email to