On Wed, 12 Jan 2005, Kai-Uwe Jensen wrote: > On Wed, 12 Jan 2005, Paul Rodan wrote: > > >> Yeah, it's a way for numbers to get sent faster, so you don't have to > wait > >> for the 3 second timeout before it gets transmitted to Asterisk. It's > >> similar to the dial-plan in the Sipura devices. > >> > >> I don't know where it's mentioned in their documentation, maybe it's on > >> their cd somewhere. I was just thrown a phone and told to figure it out, > >> thanks to searching through the forum and a little help on the irc > channel, > >> I figured it out after a little bit of time. It's extremely customizable > (so > >> are the Sipura's). > > > > Any idea on docs? I found the following message from the mailing list that > > > I'm going to work with tonight.. > > > > http://lists.digium.com/pipermail/asterisk-users/2004-May/045721.html > > My Polycom admin guide (pg. 115, 4.6.2.1.4.1) says the dialplan digitmap > is "compatible with the digit map feature of MGCP described in 2.1.5 of RFC > 3435". The RFC can be found in many places, for example here: > http://www.faqs.org/rfcs/rfc3435.html
For archival/search purposes, I'll re-post the relevant portion of the RFC that deals with Digit maps. This looks like it will solve the problem! 2.1.5 Digit Maps 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. -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users