[asterisk-dev] Realtime behavior questions ...

[Mauro Sergio Ferreira Brasil]

Thanks a lot for you good will on answering with such detail each and 
every question (and moreover, per SQL statement).
I'll have a new, and more carefull, look at "extensions.conf.sample" file.

Best regards,
Mauro.


Tilghman Lesher escreveu:
> Forum note:  in the future, please turn off HTML email to this list.  It's
> unnecessary and bloats the amount of bandwidth this list uses.
>
> On Monday 17 August 2009 08:59:42 am Mauro Sergio Ferreira Brasil wrote:
>   
>> In order to create a new realtime driver, I thought it would be
>> important to analyse its behavior using an existent driver.
>> So, I configured an Asterisk instance to get SIP peers/users, voicemail
>> boxes and extensions from a mysql database (no "global"/"general"
>> configuration of any king by now), and put a monitor to map the queries
>> executed on normal operation.
>>
>> SIP peer/users and voicemail boxes operation was clear as water to me
>> (the database queries are quite straighforward), but some queries
>> regarding dialplan extensions are getting me lost.
>>
>> 1- Same query is performed more than once:
>>
>> For example: the query below regarding the priority "3" from extension
>> "102" of context "sip" gets performed 3 times... and the same happens
>> with prior steps(priorities).
>>
>> SELECT * FROM extensions WHERE exten = '102' AND context = 'sip' AND
>> priority = '3'
>>     
>
> Yes, that's correct.  It's not optimal, but due to the dialplan architecture,
> it's somewhat unavoidable.  A possible optimization would be to cache the
> results of queries for some short period of time.
>
>   
>> 2- After getting the final step to voicemail, some weird extension
>> queries are performed like shown below:
>>
>> SELECT * FROM extensions WHERE exten = 'a' AND context = 'sip' AND
>> priority = '1'
>>     
>
> This extension is queried when somebody presses '*' in voicemail, as
> documented in extensions.conf.sample.
>
>   
>> SELECT * FROM extensions WHERE exten LIKE '\\_%' AND context = 'sip' AND
>> priority = '1' ORDER BY exten
>>     
>
> This is an extensions pattern.  Since the database cannot itself compare the
> custom patterns, Asterisk must load all patterns and compare them manually.
> It's not very efficient, but it's done this way to avoid using different
> pattern systems for different dialplan backends.  This is the original pattern
> system, so its use is for legacy compatibility.
>
>   
>> SELECT * FROM extensions WHERE exten = 'h' AND context = 'sip' AND
>> priority = '1'
>>     
>
> The "h" extension, if it exists, will be executed at channel hangup.
>
>   
>> Right after these 4 unexpected queries (at least, unexpected for me
>> :-)), the final steps of storing the CDR (on mysql too) and update of
>> SIP peer/user are performed normally.
>>     
>
> You should probably familiarize yourself with extensions.conf.sample.  These
> are all very typical dialplan lookups.
>
>   
>> I have another situation here where the query for priority "1",
>> extension "102" and context "sip" was performed 4 times. Right after a
>> new query on which the priority was "-1" was perfomed and this priority
>> was used on second query of (4 strange queries above), followed by the
>> final 2 strange queries above (the query with "exten = 'a'" was not
>> performed on this case.
>>     
>
> Priority -1 is also known as the "hint" extension and is used to associate a
> given extension with the state of a given device.
>
>   

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