<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=windows-1252"

 http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Olle E. Johansson wrote:

<blockquote cite="mid4344BE28.8090908@edvina.net" type="cite">

  <pre wrap=""><!---->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.

  </pre>

</blockquote>

Olle,<br>

<br>

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.<br>

<br>

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.<br>

<br>

-Chris<br>

</body>

</html>