[Asterisk-Dev] "register" statement: why can't it reference an account?

[Olle E. Johansson]

Chris A. Icide wrote:
> Olle E. Johansson wrote:
> 
>>Only in static mode. Since it's realtime, we do not load the peers at
>>load time and unless we force Asterisk to check *every* peer in the
>>database and register, I fail to see how this would work. Registrations
>>are not really realtime in nature, they are static - either on or off,
>>but does not change every hour... So for a realtime architecture,
>>realtime static as it is now is propably the best and only choice for
>>outbound registrations.
>>
>>A compromise would be to store registrations in a separate table and
>>implement commands for reloading registrations without reloading the
>>channel configuration.
>>
>>  
>>
> Olle,
> 
> While I understand your point, I disagree with your conclusion.  In
> *some* cases, yes, registration is a static configuration, however when
> using realtime as a way to create a realtime GUI management system where
> you don't want to reload the system(s) every time a change is made,
> registration begins to look like a dynamic statement.  However, I don't
> have a good solution to the issue of how to handle the fact that some
> outside system has changed the value of the register field in the peer
> database.  Either asterisk would need to frequently poll the db table
> (yuck), or asterisk would need a signal from the outside system to let
> it know it needs to re-process all it's peers to see if the value of
> register has changed.

You disagree first, but then you agree that having Asterisk going through
all of the peers to check if we have a registration does not work...

At some point, we'll say Eureka and solve this. Registration belongs in
the [peer] section.

> So I guess moving register= into the dynamic part of realtime isn't
> nearly as simple as it sounds.  However for the flat file
> implementation, it seems a cleaner solution.
A separat table for registrations and a manager command to re-read the
database and check for new items would be a cleaner solution. Or maybe a
selective query... Hmmm.

Well, anyway, that's after 1.2 and Astricon. Busy now.

/O