[asterisk-dev] Retrieve current channel from inside ARA driver method ...

[Tilghman Lesher]

On Monday 17 August 2009 08:33:36 am Mauro Sergio Ferreira Brasil wrote:
> Tilghman Lesher escreveu:
> > On Thursday 13 August 2009 13:10:01 Mauro Sergio Ferreira Brasil wrote:
> >> Hi Tilghman, and thanks for the reply.
> >>
> >> I'm trying to figure out the better approach to handle a very dynamic
> >> dialplan that depends on legacy systems information.
> >> For now I was considering two approaches:
> >>
> >> Option 1:
> >>
> >> Have all extensions persisted on Mysql database and retrieved through
> >> ARA mysql driver. All these extensions will call an application
> >> ("AuthorizeCall", for example) that will contact legacy systems and set
> >> some variables that I'll test right after to decide: if I can proceed
> >> with the call; if I should return a busy status; if I can proceed with
> >> the call but through an specific telco gateway; etc.
> >>
> >> This approach takes two steps that are: 1- the database dialplan
> >> retrieval; and 2- the legacy system routing and authorization query.
> >> For this approach each extension retrieved from database would seem like
> >> example below:
> >>
> >> exten=>1001,1,AuthorizeCall(${CONTEXT},${CALLERID(num)},${EXTEN})
> >> exten=>1001,n,GotoIf($[${CALLAUTHORIZATION} = ACCEPTED]?proceed)
> >> exten=>1001,n,Playtones(congestion)
> >> exten=>1001,n,Congestion()
> >> exten=>1001,n(proceed),Dial(SIP/${EXTEN},20,RtT)
> >> exten=>1001,n,GotoIf($[${DIALSTATUS} = BUSY]?busy)
> >> exten=>1001,n,Voicemail(${EXTEN}@${VOICEMAILSRV},u)
> >> exten=>1001,n,Hangup()
> >> exten=>1001,n(busy),Voicemail(${EXTEN}@${VOICEMAILSRV},b)
> >> exten=>1001,n,Hangup()
> >>
> >> Option 2:
> >>
> >> Create an ARA driver that will contact legacy systems and generate the
> >> dialplan for the queried extension on demand.
> >> In just one step we will contact the legacy systems and build the
> >> dialplan we need to complete the call.
> >>
> >> The problem here is that, as long as I could see, the ARA driver methods
> >> don't receive the channel as a parameter, and I could see any way to
> >> retrieve this channel either.
> >> Until now, I believe that I need the current channel (the channel that
> >> issued the ARA query) so I can get the necessary information (like the
> >> context, the caller number and the extension) - that are channel
> >> variables - to calculate the extension steps.
> >> Am I right ?
> >> Do I realy need the channel ? Is there other way to retrive this
> >> information from inside ARA driver methods ?
> >>
> >> I would prefer to build our solution using this approach, but I'm not
> >> certain if is there solutions to the problems I've noticed until now.
> >>
> >> Do you have any ideias to make second approach a viable solution ?
> >> If you don't... do you see any problems on first approach ?
> >
> > Well, most of the information you're looking for is actually passed back
> > to the realtime driver already, as parameters to the query.  That's true
> > for both context and extension.  The only part that isn't passed back is
> > callerid number.  That could be added without too much trouble to the
> > pbx_realtime module, although it would not be backwards compatible with
> > most
> > implementations.  In addition, I'd suggest using something like the
> > res_config_curl driver to make your extra evaluation on the backend
> > easy.
>
> I'm not completely sure whether your suggestion is to add the additional
> CALLERID information to the list of parameters that are already being
> passed to realtime procedures, because on that case it will get
> automatically added to SQL query statement, won't it ?

Only if your backend goes directly to an SQL query statement.  As I detailed
above, it's certainly possible to substitute a middleware piece in between
the realtime backend and your database, and as I've indicated, there's already
a driver that lets you do exactly that.

> Anyway, I would like to place a question that will be more profitable:
> It would be acceptable to asterisk staff a change on realtime so the
> channel parameter gets forwarded to all realtime configuration routines
> ("config_load_func", "realtime_var_get", "realtime_multi_get" and
> "realtime_update") declared at "main/config.h" ? (I know that this will
> demand changes on some methods from "pbx/pbx_realtime.c" so the channel
> can indeed be forwarded, and on all implemented drivers as well. But a
> controlled change, I think.)

No, we're not going to do that.  The callerid is the only extra information
that you need, the channel is not necessary, and in some cases, the channel
does not even exist when realtime is called.  It is therefore inappropriate to
demand that a channel parameter be passed.

-- 
Tilghman