[asterisk-users] Realtime on Asterisk 1.2.24

[Tilghman Lesher]

On Saturday 27 October 2007 11:07:32 JR Richardson wrote:
> > I *STRONGLY* recommend that you do NOT use realtime extensions.  If you
> > want a dynamic dialplan, the correct way to do it is to segregate your
> > logic and your data (via something like func_odbc), not to stick all of
> > your logic into a database.
>
> I'm confused by your statement here.  Isn't it the whole idea behind ARA to
> put as much of your dial plan in a database?

No, the point of ARA is to put stuff into a database, so that it can be
configured via a tool other than a text editor.  For some things, notably
channel settings, that goal works very well.  For others, such as the logic
of the dialplan, it reduces the efficiency of Asterisk by a large factor.

> Or are you referring to 
> static extensions.conf settings?  I'm just getting into func_odbc and maybe
> I'm still not completely clear on the benefits over res_mysql with ARA. 
> 95% of my dial plan is in a database and is working fine for me.

The benefit of segregating your logic and your data is to allow extensions to
be created much easier, simply by adding a single row to a database which
contains only the parts of the dialplan which differ.  So, for example, a very
simple table might be composed of the following fields:

channel		SIP/101	SIP/102&SIP/103
extension		101		102
location		cell		office
cell			5551010	5552020
name		Recep	Sales

And your extensions.conf might be built along the lines of:

exten => _XXX,1,Set(ARRAY(channel,location,cell)=${ODBC_LOOKUP(${EXTEN})})
exten => _XXX,n,GotoIf($[${LEN(channel)} = 0]?i,1)
exten => _XXX,n,GotoIf($[${location} = cell]?forward_cell)
exten => _XXX,n,GotoIf($[${location} = away]?voicemail)
exten => _XXX,n,Dial(${channel},30)
exten => _XXX,n(voicemail),Voicemail${EXTEN},${IF($[${DIALSTATUS} = 
BUSY]?b:u)})
exten => _XXX,n,Hangup
exten => _XXX,n(forward_cell),Dial(Zap/g1/${cell},30)
exten => _XXX,n,Goto(voicemail)

That's just a very brief example of segregating your logic and your data, but
it provides a better way to put the stuff which makes the most sense to be
dynamic in a database and lets everything else (i.e. the logic) sit in a
static configuration file.  BTW, I have not included an example
func_odbc.conf, but its contents should be fairly obvious from this example.

-- 
Tilghman