[asterisk-dev] Realtime behavior questions ...

[Tilghman Lesher]

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.

-- 
Tilghman