[Asterisk-Users] Class features in dialplan ?

[Tilghman Lesher]

On Friday 16 January 2004 20:58, Lance Arbuckle wrote:
> hey guys
> I thought I was making progress on my dialplan when I realized that
> the class features that are available for zap channels aren't
> available for SIP channels.  I see references in the archives to
> adding pattern matches in the dialplan for CLASS features which has
> raised a couple questions.
>
> 1.  Is implementing CLASS like features via the dialplan the
> currently recommended way to do this ?
>
> 2.  In general, are there any problems using non numeric characters
> in a pattern match with SIP phones (i.e. _*67) ?
>
> So far I'm planning to do Call Forward Unconditional, Call Forward
> Busy, Call Forward No-Answer, and Do not disturb and maybe some speed
> dials but I haven't thought that one through yet.
>
> 3.  Anyone willing to share some of their cool features that they've
> come up with ???  I'd be most appreciative  :)

Here's how Mark wants it done:

In the channel_pvt structure, we have a pointer to a new structure:

struct ast_common_features {
        char fwd[AST_MAX_EXTENSION];
	char fwd_off[AST_MAX_EXTENSION];
        .
        .
        .
};

This allows the codes to be redefined per installation (for those who
don't like the NANPA assignments) or even per channel.  In addition,
those who want to handle the codes in the dialplan can turn off various
featuresets by setting their codes to "".

Then, when we're processing extensions in the channel driver, we do
the following:

if (ast_feature_match(&p->common_features, exten, ...)) {
        /* Make channel if it doesn't already exist */
        ast_feature_handle(chan, &p->common_features, exten, ...);
}

and in the config, the features would be configured with another common
routine:

else if (!ast_feature_config(&p->common_features, v->var, v->value)) {
        ast_log(LOG_WARNING, "Unknown keyword '%s'\n", v->var);
}

All these common features could then be handled either in a device
independent way (such as forward, where the end number is entered into
a database for later lookup) or in a device-specific way, as
appropriate.


I've looked at implementing this, but it is quite complex and extensive,
and I haven't had the time to complete it.  Add to that all the
negativity of people who don't like this plan and have vociferously
expressed their distaste (intending to implement these in the dialplan
instead), and you see why this code is even more difficult to write.

-Tilghman