Asterisk Dialplan Planning

Dialplan Planning - General Discussion


As a newbie (we all started that way), I found that it was difficult to create a dialplan since I had many new things to learn all at once and I kept discovering more "hidden" gems.

I wanted to create a dialplan that would:
  • work for North America dialing patterns,
  • allow for a multi-location company that would allow users to directly dial an extension in another office location of their own company (extensions at other locations could have more digits than local extensions),
  • allow users to have their own "virtual" extension that would be mapped to a real, physical phone extension or a softphone (to accomodate roaming users, occasional at-home workers, and user managed follow-me type calling systems),
  • use the same user authentication system for voicemail as used for email, shell access, etc - Note: this is not possible as of January 2005 unless you use a sql or ldap based system. The ldap based system can not currently accept password changes from asterisk. PAM would likely be the most widely adopted system for this in the future and it would likely require non-repeating user id numbers for past, current, and future employees to not complicate other PAM based systems (eg file system access permissions) .. SQL and ldap based systems would not carry limitation
  • be able to dial physical (and softphones) directly .. including outgoing lines (useful for debugging multi-line systems)
  • be simple enough in logic that users could remember patterns and while keeping extension numbers short (not have to dial in 99 numbers to reach a person)
  • allow for some system extensions (go to voicemailmain, go to a specific voicemail, join a meetme session, etc)

Here are some of the standard extensions patterns that I wanted to keep:
  • one digit special numbers
    • 0 for operator
  • three digit special numbers
    • 911 for emergency services
    • 411 for information
    • 700-705 for parking and retrieving parked calls (these are asterisk default values and can be changed in features.conf .. refer to parked call pages)
  • seven digit local dialing (_NXXXXXX)
  • eleven digit US/CDN long distance dialing (_1NXXNXXXXXX)
  • eleven digit US/CDN long distance dialing (_1888NXXXXXX, _1877NXXXXXX, _1866NXXXXXX, _1800NXXXXXX)
  • variable length numbers
    • internation dialing (_011.)

Since there is usually overlap between local extensions and local outbound calling, there are basically six options available for doing pattern matching on them:
  1. force users to prepend a '9' to the front of the dialed number and you only use a pattern starting with '9' in the outbound extensions Pro - easy way to avoid waiting for the timeout Con - extra dialing for every local outgoing call
  2. don't worry about it and wait for * to timeout (since it would be waiting for more digits when you dial shorter numbers that are typically used for internal extensions) Pro - no extra digits to dial Con - takes longer than most people want to wait
  3. expect users to type a '#' after the dialed internal number to signify that asterisk shouldn't wait for any more digits Pro - easy way to avoid waiting for the timeout Con - extra dialing for every internal call
  4. use the same number of digits for local extensions and local calls (7 digits in NA) Pro - easy way to avoid waiting for the timeout Con - extra dialing for every internal call
  5. create local outbound pattern matches for each phone number prefix that is local to your area (ie _271XXXX, _272XXXX) and don't have a _NXXXXXX exten. Pro - no timeout needed if your local extensions don't use the same first three digits Con - needs to be maintained and causes extra aggravation to users each time a new local prefix is added by the phone company
  6. create 3 digit local extensions and for outgoing calls feed only the first 3 digits to the dial command and the telco will pick up and recieve the rest directly Pro - fast dialing Cons - can't use cdr to track calling, can't route long distance calls differently than local calls (ie no least cost routing possible)

As discussed elsewhere on this wiki, currently the only real method to control the order of dialplan pattern matching is by defining things in small context and using "include" in one of the main contexts (context naming can be pretty much anything you want without special characters)

For simplicity we will refer to the originating caller the "caller" and the person intended to answer the call the "callee"

A few practical guidelines:
  • since most users would dial the callee virtual extension instead of the physical extension number of the device, the virtual extensions numbers should be rather short but the physical extension numbers could be quite large
  • the total number of possible "virtual" user extensions should provide enough numbers to accomodate all past, present, and future employees (not currently an issue and may not be in the future .. but we should try to plan around possible future problems while we can)
  • probably easiest to append an office location number to the beginning of that location's extensions for users to understand and use the system (rather than just have numerous extensions without any real order) and allows extensions to be reused at numerous locations without conflict (allows the local extensions to have fewer digits). This total number of possible office locations would have to be large enough to handle all current and future office locations.

HERE IS A PROBLEM!

When managing a filesystem with users accessing files from multiple locations, I haven't paid any attention to what userid's the system assigns to a new user .. it doesn't matter since I control file access by groups and the specific userid is only used by the system to find out what groups they belong to.
If we try to reuse the file, email, whatever systems userids for asterisk extensions and authentication, location grouping based on userid as asterisk extension would require a site admin to edit the system created userid. This might lead to conflicts in the future if the system tries to assign a userid already manually created or if the user moves to another location.
We have 3 options to consider:
  • do not use the system userid as the asterisk extension. Users will not know the difference and this will allow duplication of extensions at different office locations. This would likely work with ldap and sql based authentication system since it would only require the addition of another "field". This would cause havoc with file based PAM systems.
  • use enough digits to have non-repeating extensions across all locations. This would not allow shorter sequences for asterisk extensions at a user's local office and would appear to not have any logic to extension layout
  • use the combination of system group and user ids to match up to asterisk extensions. I think this would be the preferred method since it would easily accomodate users moving from one location to another, allow shorter sequences for local extensions, and allow for the greatest variety of authentication and group/user id storage systems (potentially including PAM in the future if asterisk code is written to talk to PAM)

What do you think?



Note: any pattern matching that ends in a "." (meaning any number of any digits) should be in a context that is included. This is only only way to control the order of pattern matching!!

Dialplan Planning - General Discussion


As a newbie (we all started that way), I found that it was difficult to create a dialplan since I had many new things to learn all at once and I kept discovering more "hidden" gems.

I wanted to create a dialplan that would:
  • work for North America dialing patterns,
  • allow for a multi-location company that would allow users to directly dial an extension in another office location of their own company (extensions at other locations could have more digits than local extensions),
  • allow users to have their own "virtual" extension that would be mapped to a real, physical phone extension or a softphone (to accomodate roaming users, occasional at-home workers, and user managed follow-me type calling systems),
  • use the same user authentication system for voicemail as used for email, shell access, etc - Note: this is not possible as of January 2005 unless you use a sql or ldap based system. The ldap based system can not currently accept password changes from asterisk. PAM would likely be the most widely adopted system for this in the future and it would likely require non-repeating user id numbers for past, current, and future employees to not complicate other PAM based systems (eg file system access permissions) .. SQL and ldap based systems would not carry limitation
  • be able to dial physical (and softphones) directly .. including outgoing lines (useful for debugging multi-line systems)
  • be simple enough in logic that users could remember patterns and while keeping extension numbers short (not have to dial in 99 numbers to reach a person)
  • allow for some system extensions (go to voicemailmain, go to a specific voicemail, join a meetme session, etc)

Here are some of the standard extensions patterns that I wanted to keep:
  • one digit special numbers
    • 0 for operator
  • three digit special numbers
    • 911 for emergency services
    • 411 for information
    • 700-705 for parking and retrieving parked calls (these are asterisk default values and can be changed in features.conf .. refer to parked call pages)
  • seven digit local dialing (_NXXXXXX)
  • eleven digit US/CDN long distance dialing (_1NXXNXXXXXX)
  • eleven digit US/CDN long distance dialing (_1888NXXXXXX, _1877NXXXXXX, _1866NXXXXXX, _1800NXXXXXX)
  • variable length numbers
    • internation dialing (_011.)

Since there is usually overlap between local extensions and local outbound calling, there are basically six options available for doing pattern matching on them:
  1. force users to prepend a '9' to the front of the dialed number and you only use a pattern starting with '9' in the outbound extensions Pro - easy way to avoid waiting for the timeout Con - extra dialing for every local outgoing call
  2. don't worry about it and wait for * to timeout (since it would be waiting for more digits when you dial shorter numbers that are typically used for internal extensions) Pro - no extra digits to dial Con - takes longer than most people want to wait
  3. expect users to type a '#' after the dialed internal number to signify that asterisk shouldn't wait for any more digits Pro - easy way to avoid waiting for the timeout Con - extra dialing for every internal call
  4. use the same number of digits for local extensions and local calls (7 digits in NA) Pro - easy way to avoid waiting for the timeout Con - extra dialing for every internal call
  5. create local outbound pattern matches for each phone number prefix that is local to your area (ie _271XXXX, _272XXXX) and don't have a _NXXXXXX exten. Pro - no timeout needed if your local extensions don't use the same first three digits Con - needs to be maintained and causes extra aggravation to users each time a new local prefix is added by the phone company
  6. create 3 digit local extensions and for outgoing calls feed only the first 3 digits to the dial command and the telco will pick up and recieve the rest directly Pro - fast dialing Cons - can't use cdr to track calling, can't route long distance calls differently than local calls (ie no least cost routing possible)

As discussed elsewhere on this wiki, currently the only real method to control the order of dialplan pattern matching is by defining things in small context and using "include" in one of the main contexts (context naming can be pretty much anything you want without special characters)

For simplicity we will refer to the originating caller the "caller" and the person intended to answer the call the "callee"

A few practical guidelines:
  • since most users would dial the callee virtual extension instead of the physical extension number of the device, the virtual extensions numbers should be rather short but the physical extension numbers could be quite large
  • the total number of possible "virtual" user extensions should provide enough numbers to accomodate all past, present, and future employees (not currently an issue and may not be in the future .. but we should try to plan around possible future problems while we can)
  • probably easiest to append an office location number to the beginning of that location's extensions for users to understand and use the system (rather than just have numerous extensions without any real order) and allows extensions to be reused at numerous locations without conflict (allows the local extensions to have fewer digits). This total number of possible office locations would have to be large enough to handle all current and future office locations.

HERE IS A PROBLEM!

When managing a filesystem with users accessing files from multiple locations, I haven't paid any attention to what userid's the system assigns to a new user .. it doesn't matter since I control file access by groups and the specific userid is only used by the system to find out what groups they belong to.
If we try to reuse the file, email, whatever systems userids for asterisk extensions and authentication, location grouping based on userid as asterisk extension would require a site admin to edit the system created userid. This might lead to conflicts in the future if the system tries to assign a userid already manually created or if the user moves to another location.
We have 3 options to consider:
  • do not use the system userid as the asterisk extension. Users will not know the difference and this will allow duplication of extensions at different office locations. This would likely work with ldap and sql based authentication system since it would only require the addition of another "field". This would cause havoc with file based PAM systems.
  • use enough digits to have non-repeating extensions across all locations. This would not allow shorter sequences for asterisk extensions at a user's local office and would appear to not have any logic to extension layout
  • use the combination of system group and user ids to match up to asterisk extensions. I think this would be the preferred method since it would easily accomodate users moving from one location to another, allow shorter sequences for local extensions, and allow for the greatest variety of authentication and group/user id storage systems (potentially including PAM in the future if asterisk code is written to talk to PAM)

What do you think?



Note: any pattern matching that ends in a "." (meaning any number of any digits) should be in a context that is included. This is only only way to control the order of pattern matching!!
Created by: bjohnson, Last modification: Mon 04 of Apr, 2005 (19:25 UTC)
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+