Digit Maps used to Define the Dial Plan

Owned by Former user (Deleted)
Last updated: Feb 10, 2011 by Former user (Deleted)Version comment

The following digit map syntax definition is used by Polycom to define phone specific dialing behavior. A phone dial plan is important for the phone to know when an entered number is complete and therefore the call should be initiated. If the phone does not know that dialing needs to be manually initiated by pressing the Dial softkey. If the phone digit map is define wrong, the phone might start to dial before you were actually able to enter all the digits you wanted to.

The Polycom phones allow the specification of a phone dial plan applicable to all the lines as well as a line specific setting that overriedes the general setting. This can all be configured using the plug & play management interface in the sipX configuration server.

Configuring Polycom Phone Dial Plans

Impossible Match Handling: This setting relates to how digits entered match the dial plan string defined for the phone. A match can be either a "perfect match," exactly matching one of the specified alternatives, or an impossible match, which occurs when the dial string does not match any of the alternatives. In most cases a more graceful error handling would be a setting of "2", which allows the user to continue enter digits.

Digit Map: The dial plan string for the phone as discussed below

Timeout: This parameter defines the length in seconds of parameter "T" used in dial plan pattern definitions

Polycom Phone Default Dial Plan

The following string represents the default dial plan for 3-digit internal extensions used by the sipX configuration server release 3.0 for Polycom phones:

[2-9]11|0T|011xxx.T|91[2-9]xxxxxxxxx|[1-8]xx

It means the following:
*[2-9]11: 911 rule: x11 are dialled immediately (111 is covered below by [1-8]xx
*0T: Local operator rule: After dialing "0" the phone waits T seconds and then completes the call automatically
*011xxx.T: International rule without prefix
*91[2-9]xxxxxxxxx: LD rule with prefix
*[1-8]xx: A regular 3 digit extension is dialed immediately ("9" excluded as a prefix)

Note: The sipX server uses SIP methods for feature invocation and not star codes. However, there are a few rare occasions where a DTMF star code is needed. Star codes are not automatically dialled with the above default dial plan and require the user to press Send. Also, international calls do not require a "9" prefix, but LD calls do, which seems somewhat inconsistent.

Note: Should the phone refuse to let you dial a number do the following: Do not pick up the handset and do not press a line key. Instead dial the number first and once done press the line key you want to use. The phone now dials the digits entered disregarding its dial plan settings.

{{Box Important| The default sipX internal dialplan is setup for 3 digit extensions. You can change this by going to Dial Plan, Internal. If changed to e.g. 4 digits, all the phone default dial plan strings need to be manually modified to reflect that change. This is best done using a phone group, so that this setting only needs to be changed once and applies to all the phones in the group. In the above default string replace [1-8]xx by [1-8]xxx|}

Revised Default Dial Plan String

As an alternative (improvement) to the above default you might want to consider the following dial plan strings. Dial plan strings are best modified by creating a phone group and then change the dial plan string setting for the group.

This string allows three digit extensions including the range of 1xx. However, for LD calls a "9" prefix is required:

[2-9]11|0T|011xxx.T|9011xxx.T|91[2-9]xxxxxxxxx|9[2-9]xxxxxx|*xx|[8]xxx|[1-7]xx

This string (my favorite) allows three digit extension excluding the range of 1xx (with the exception of 100 and 101). It further allows LD calls to be dialed with or without the "9" prefix:

[2-9]11|0T|100|101|011xxx.T|9011xxx.T|1[2-9]xxxxxxxxx|91[2-9]xxxxxxxxx|9[2-9]xxxxxx|*xx|[8]xxx|[2-7]xx

This string allows four digits extensions, excluding the range of 1xxx and allows LD calls with or without the "9" prefix:

[2-9]11|0T|100|101|011xxx.T|9011xxx.T|1[2-9]xxxxxxxxx|91[2-9]xxxxxxxxx|9[2-9]xxxxxx|*xx|[8]xxxx|[2-7]xxx

It means the following:
*[2-9]11: 911 rule: 211, 311, 411, 511, 611, 711, 811, 911 are dialled immediately
*0T: Local operator rule: After dialing "0" the phone waits T seconds and then completes the call automatically
*100: Auto-attendant default extension
*101: Voicemail default extension
*011xxx.T: International rule without prefix
*9011xxx.T: International rule with prefix
*1[2-9]xxxxxxxxx: LD rule without prefix
*91[2-9]xxxxxxxxx: LD rule with prefix
*9[2-9]xxxxxx: Local call with prefix
**xx: 2-digit star codes
*[1-7]xx: A regular 3 digit extension that does not start with 9 or 8 is dialed immediately
*[2-7]xx: A regular 3 digit extension that does not start with 9 or 8 or 1 is dialed immediately
*[2-7]xxx: A regular 4 digit extension that does not start with 9 or 8 or 1 is dialed immediately
*[8]xxx: A 3 digit extension prefixed with an 8 (routes calls directly to voicemail of extension xxx)
*[8]xxxx: A 4 digit extension prefixed with an 8 (routes calls directly to voicemail of extension xxxx)

Digit Maps Syntax Definition

The following is an excerpt (Section 2.1.5) from RFC 3435 on the definition of the digit map syntax. Polycom used this definition in their line of phones.

   The Call Agent can ask the gateway to collect digits dialed by the
   user.  This facility is intended to be used with residential gateways
   to collect the numbers that a user dials; it can also be used with
   trunking gateways and access gateways alike, to collect access codes,
   credit card numbers and other numbers requested by call control
   services.

   One procedure is for the gateway to notify the Call Agent of each
   individual dialed digit, as soon as they are dialed.  However, such a
   procedure generates a large number of interactions.  It is preferable
   to accumulate the dialed numbers in a buffer, and to transmit them in
   a single message.

   The problem with this accumulation approach, however, is that it is
   hard for the gateway to predict how many numbers it needs to
   accumulate before transmission.  For example, using the phone on our
   desk, we can dial the following numbers:

        ------------------------------------------------------
       |  0                     |  Local operator             |
       |  00                    |  Long distance operator     |
       |  xxxx                  |  Local extension number     |
       |  8xxxxxxx              |  Local number               |
       |  #xxxxxxx              |  Shortcut to local number at|
       |                        |  other corporate sites      |
       |  *xx                   |  Star services              |
       |  91xxxxxxxxxx          |  Long distance number       |
       |  9011 + up to 15 digits|  International number       |
        ------------------------------------------------------

   The solution to this problem is to have the Call Agent load the
   gateway with a digit map that may correspond to the dial plan.  This
   digit map is expressed using a syntax derived from the Unix system
   command, egrep.  For example, the dial plan described above results
   in the following digit map:

      (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)

   The formal syntax of the digit map is described by the DigitMap rule
   in the formal syntax description of the protocol (see Appendix A) -
   support for basic digit map letters is REQUIRED while support for
   extension digit map letters is OPTIONAL.  A gateway receiving a digit
   map with an extension digit map letter not supported SHOULD return
   error code 537 (unknown digit map extension).

   A digit map, according to this syntax, is defined either by a (case
   insensitive) "string" or by a list of strings.  Each string in the
   list is an alternative numbering scheme, specified either as a set of
   digits or timers, or as an expression over which the gateway will
   attempt to find a shortest possible match.  The following constructs
   can be used in each numbering scheme:

   * Digit:    A digit from "0" to "9".
   * Timer:    The symbol "T" matching a timer expiry.
   * DTMF:     A digit, a timer, or one of the symbols "A", "B", "C",
               "D", "#", or "*".  Extensions may be defined.
   * Wildcard: The symbol "x" which matches any digit ("0" to "9").
   * Range:    One or more DTMF symbols enclosed between square brackets
               ("\[" and "]").
   * Subrange: Two digits separated by hyphen ("-") which matches any
               digit between and including the two.  The subrange
               construct can only be used inside a range construct,
               i.e., between "\[" and "]".
   * Position: A period (".") which matches an arbitrary number,
               including zero, of occurrences of the preceding
               construct.

   A gateway that detects events to be matched against a digit map MUST
   do the following:

   1) Add the event code as a token to the end of an internal state
      variable for the endpoint called the "current dial string".

   2) Apply the current dial string to the digit map table, attempting a
      match to each expression in the digit map.

   3) If the result is under-qualified (partially matches at least one
      entry in the digit map and doesn't completely match another
      entry), do nothing further.

   If the result matches an entry, or is over-qualified (i.e., no
   further digits could possibly produce a match), send the list of
   accumulated events to the Call Agent.  A match, in this
   specification, can be either a "perfect match," exactly matching one
   of the specified alternatives, or an impossible match, which occurs
   when the dial string does not match any of the alternatives.
   Unexpected timers, for example, can cause "impossible matches".  Both
   perfect matches and impossible matches trigger notification of the
   accumulated digits (which may include other events - see Section
   2.3.3).

   The following example illustrates the above.  Assume we have the
   digit map:

      (xxxxxxx|x11)

   and a current dial string of "41".  Given the input "1" the current
   dial string becomes "411".  We have a partial match with "xxxxxxx",
   but a complete match with "x11", and hence we send "411" to the Call
   Agent.

   The following digit map example is more subtle:

     (0[12].|00|1[12].1|2x.#)

   Given the input "0", a match will occur immediately since position
   (".") allows for zero occurrences of the preceding construct.  The
   input "00" can thus never be produced in this digit map.

   Given the input "1", only a partial match exists.  The input "12" is
   also only a partial match, however both "11" and "121" are a match.

   Given the input "2", a partial match exists.  A partial match also
   exists for the input "23", "234", "2345", etc.  A full match does not
   occur here until a "#" is generated, e.g., "2345#".  The input "2#"
   would also have been a match.

   Note that digit maps simply define a way of matching sequences of
   event codes against a grammar.  Although digit maps as defined here
   are for DTMF input, extension packages can also be defined so that
   digit maps can be used for other types of input represented by event
   codes that adhere to the digit map syntax already defined for these
   event codes (e.g., "1" or "T").  Where such usage is envisioned, the
   definition of the particular event(s) SHOULD explicitly state that in
   the package definition.

   Since digit maps are not bounded in size, it is RECOMMENDED that
   gateways support digit maps up to at least 2048 bytes per endpoint.