[asterisk-dev] enhanced 'hint' functionality

[Tilghman Lesher]

On Saturday 09 December 2006 05:12, Thomas Andrews wrote:
> Tilghman Lesher wrote:
> > On Wednesday 06 December 2006 22:11, Thomas Andrews wrote:
> >>> 6 dec 2006 kl. 20.02 skrev Thomas Andrews:
> >>>> I want to implement hints such as this:
> >>>>
> >>>>    exten => _2XXX,hint,agi,agi_script|${EXTEN}
> >>>>
> >>>> As I understand it, only global varibles may be used in hints
> >>>> currently.
> >>>>
> >>>> Does anyone know how much effort this would require for me to
> >>>> implement?
> >>>> I'm not familiar with that part of the asterisk code, so I don't
> >>>> know if
> >>>> I'm biting off more than I can chew. What I mean is, would this change
> >>>> fit in reasonably well with the existing architecture?
> >>
> >> In other words I want to avoid having any hints hard-coded in the
> >> dialplan, and would instead like variables and/or calls.
> >>
> >> I am using agi scripts currently to look up the relationship between the
> >> extension and the device from a sqlite db. So for example I can get
> >> Zap/17 from the entry for 200 in the db. I now want to extend this
> >> functionality to hints.
> >
> > http://bugs.digium.com/view.php?id=7767
> >
> > It's far from complete, and I haven't had to work on it recently. 
> > However, the basic blueprint is there and it works.  It just doesn't work
> > yet across reloads.
>
> Tilghman, I'm afraid I can't understand this patch. It dynamically
> creates a new extension if the exten line begins with '_' Without this
> patch however, my dialplan already accepts hints of the form:
>
> 	exten => _2XX,hint,Zap/1

Do they work?

> Why would one want this patch ? Sorry if I'm being dumb :p

You have to understand how hints work.  Each hint in the dialplan creates
one memory structure tracking the devicestate of exactly one device.  So
if you create a pattern match, it will track the devicestate of exactly one
device.  That's not one device per matching extension; that's one device,
period.  So yes, while the example you gave above would work, extensions
matching _2XX would all track the devicestate for "Zap/1", which is probably
of very limited usefulness.  What you probably want to do is to replace Zap/1
with an expression, which might match multiple channels, depending upon the
arguments.  That doesn't work currently, because, as I said, each hint relates
to exactly one devicestate.  So for example, if you did:

exten => _2XX,hint,SIP/${EXTEN}

and then two devices subscribed to this hint, one to 201, the other to 202,
each time EITHER SIP/201 OR SIP/202 changed state, BOTH subscribers
would be notified of the new devicestate.  That means a subscriber to SIP/201
would see the devicestate of SIP/202 when SIP/202 changed state and a
subscriber to SIP/202 would see the devicestate of SIP/201 when SIP/201
changed state.

That is why when dealing with pattern matches, you MUST create a new hint
for each matching extension or else things just don't work correctly.

-- 
Tilghman