[asterisk-users] SIP-Realtime and sip reload

Torbjörn Abrahamsson torbjorn.abrahamsson at gmail.com
Thu Dec 6 14:06:44 CST 2007


> > Yes, that was my workaround which might be a solution 
> unless you do a 
> > reload on the busiest time of the day ;-) Thanks for the 
> > clarification.
> >   
> The lesson to be learned there is that maintenance during the 
> busiest time of the day is perhaps a bad idea. ;)
> 

Of course that depends on what you define as maintenance work.. :) My
opinion is that you should be able to modify user information at any time.
Modifying the dialplan is more in the line of maintenance. 

We used to have rtcachefriends set to off, as this would provide the
dynamics we needed for user modification without the need for a reload. I
had read about MWI not working, but decided that loosing that feature was OK
(OK, as in we do not need it, although we think it should work)... 

But then we encountered the fact that NAT/qualify didnot work. So we turned
rtcachefriends on and then the OPTIONS started to be sent as they should. So
we thought, OK rtcachefriends it is, we can live with the reloads. But
realising that the registrations were cleaned out when this was done made us
rethink, as this was unacceptable...

Our current approach is to use the #exec directive, and call a script which
creates static friends by reading information from the DB. We still use the
remote ITSP peers with realtime, as they do not need the OPTIONS. This way
when we call a reload the users registration is still there, and we have the
flexibility of using a DB as the user database.

Conclusion... Realtime is nice, if you don't need it to be dynamic in any
real way... Loosing all registrations because you want to change password
for a user is not good. I can see the use of having a cache, but I think it
should syncronize with the backend DB periodically. I also think that things
should work with cache turned of, of course with the penalty that comes with
always reading from the DB.

// Tobbe







More information about the asterisk-users mailing list