Asterisk
  1. Asterisk
  2. ASTERISK-67

[request] Make * Codes Into Applications (DND,*69,*8# etc)

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/General
    • Labels:
      None
    • Mantis ID:
      71
    • Regression:
      No

      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.

                • ADDITIONAL INFORMATION ******

      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.

        Activity

        Hide
        Tilghman Lesher added a comment -

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

        http://www.nanpa.com/number_resource_info/vsc_assignments.html

        Show
        Tilghman Lesher added a comment - The codes are known as Vertical Service Codes. Here's one source for them: http://www.nanpa.com/number_resource_info/vsc_assignments.html
        Hide
        florian added a comment -

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

        Show
        florian added a comment - Ah yes, thank you. These are the US-standards. Now my hunt will need to focus on the EU-standards )
        Hide
        shabanip added a comment -

        Reminder sent to jtodd

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

        Show
        shabanip added a comment - Reminder sent to jtodd hi, i was wondering how long do you predict it would take for this feature to be actually added to asterisk (making * codes into applications)?
        Hide
        John Todd added a comment -

        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.

        Show
        John Todd added a comment - 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.
        Hide
        Brian West added a comment -

        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.

        Show
        Brian West added a comment - 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.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development