Summary:ASTERISK-00067: [request] Make * Codes Into Applications (DND,*69,*8# etc)
Reporter:jayson (jayson)Labels:
Date Opened:2003-08-08 15:35:45Date Closed:2011-06-07 14:05:26
Versions:Frequency of
Description:Currently, various codes are hard-coded into the chan_zap.c channel driver.  Making these applications that use a new channel API would allow for some of this functionality to live beyond a Zaptel device and also allow sane handling of situations where the features aren't desired under some conditions.


Specifically such things as DND, Call Forwarding, *69, etc. It would be handy to be able to have this separated into applications.  The real win, for me, would be able to express *8# (steal ringing call) as:

exten => *8#,1,PickupGroup()

thereby allowing easy extension.  Eventually I would like to even be able to use something like:

exten => _*1X,1,PickupGroup(${EXTEN:1})

to allow multiple ringgroups to be picked up.

The biggest win of this would be reducing code duplication between modules, removing the double-standard for whether DTMF reaches the extensions system or not, making channel drivers more consistent / able to react with sensible errors when a feature isn't supported, and generally taking the surprises out of "accidentally" encountering one of these features.
Comments:By: John Todd (jtodd) 2003-08-11 21:32:34

I will second this motion.  I am undergoing the pain of adding these features to SIP lines, but I know they're already in place with Zap lines, and I'm going to have to un-do my methods for Zap (comment things out in the code?) when I add them to the Zap channels since I will already have them programmed in the dial logic.  It does seem to me that moving these features out of Zap makes more sense from a re-use standpoint.

By: florian (florian) 2003-09-08 14:53:41

Also, it will allow for better internationalisation: In the Netherlands for instance, these functions are generally associated with different codes (i.e. *21 for call forwarding, <hash>31 for disabling callerid, etc).

Would be cool to allow users a complete 'works just like home' experience..

edited on: 09-08-03 14:33

By: John Todd (jtodd) 2003-10-16 04:25:27

florian: Is there any chance you might be able to put some time into this?  I'll email mark and have him weigh in on this topic as well, since if he thinks it's a bad idea the patches won't get added.  However, I really really don't like having one channel that handles certain events in a "hardcoded" manner that is different than other channels.  The use of the "*xx" values should at least be specifiable via the .conf files per channel instance.

By: florian (florian) 2003-10-16 06:02:03

I agree and am already looking into it from a different angle (dialplan). I'm not sure what the best approach would be, I suppose Mark should have an opinion on that :)

By: jayson (jayson) 2003-10-16 09:04:16

Dialplan?  You mean having them set up as standard extensions?  My suggestion above was to make them apps (thereby putting them in the dialplan).  Is that what you mean?

By: florian (florian) 2003-10-16 09:55:03

that is one way to approach it, yes. My first idea was to emulate the functionality by AGI scripts and the likes.

By the way, does anyone have an all-inclusive list of these 'features' ? I know there are two standard-documents (one for the USA, one for Europe ;) that should list them, but I haven't been able to find those -actual- documents :-)

edited on: 10-16-03 09:54

By: Tilghman Lesher (tilghman) 2003-10-16 10:43:56

The codes are known as Vertical Service Codes.  Here's one source for them:


By: florian (florian) 2003-10-16 10:53:58

Ah yes, thank you. These are the US-standards. Now my hunt will need to focus on the EU-standards :-))

By: shabanip shabanip (shabanip) 2003-10-26 02:40:49.000-0600

Reminder sent to jtodd

i was wondering how long do you predict it would take for this feature to be actually added to asterisk (making * codes into applications)?

By: John Todd (jtodd) 2003-10-26 13:04:48.000-0600

shabianip - If you're willing to take on the task, it can be resolved as quickly as you finish the code.  Otherwise, this is a volunteer effort, so it is possible that without financial incentive or perceived need that this will never be done.

Considering this is a removal of functionality (though inappropriate functionality, IMHO) this may take longer than most bugs, however may be simpler to fix than most with perhaps a flag in the zapata.conf file to activate/deactivate the CLASS-like features on those channels.

Florian - instead of including all of the re-implemented features in the dialplan just yet, would you be able just to write a patch to disable the existing features from Zap on a configurable basis?  At the very minimum, that would allow the administrator the ability to write their own consistent interface instead of stumbling across chan_zap hardcoded values if they were to go forward with building their own dialplan implementation of these features.

By: Brian West (bkw918) 2004-01-26 21:38:23.000-0600

Mark has already outlined the abstraction layer to a few of the developers.  NO ETA on this but I sure hope its in before 1.0.