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

Mon Aug 17 08:33:36 CDT 2009

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 ?
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.)

The reason is quite simple.
With the channel in hand I'm pretty sure that we'll have all necessary 
means to get the driver running with anything it demands (in terms of 
information, I mean).

I had a look on "res_config_curl" and it's quite similar with what we've 
proposed here.
Use REST combined with already defined legacy protocol to avoid new 
protocol definition and associated code/decode procedures.

Thank's a lot for your "res_config_curl" indication.
I'll be waiting some return of you about the "channel parameter thing" :-)

Best regards,
Mauro.

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

-- 
__At.,                                                                                                                             
   _

*Technology and Quality on Information*
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ mauro.brasil at tqi.com.br <mailto:@tqi.com.br>
: www.tqi.com.br <http://www.tqi.com.br>
( + 55 (34)3291-1700
( + 55 (34)9971-2572

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090817/c21f6057/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMMI_2.jpg
Type: image/jpeg
Size: 1705 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20090817/c21f6057/attachment-0001.jpg 