Cisco Unified MeetingPlace, Release 6.x -- About Translation Tables

From DocWiki

Revision as of 19:56, 15 July 2009 by Jmcmulle (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Cisco Unified MeetingPlace, Release 6.x > Cisco Unified MeetingPlace Audio Server > Configuring > Translation Tables




A translation table contains rows of expressions that define how a string that is dialed out should be translated. The expressions are made up of characters.


Cisco Unified MeetingPlace supports 16 different translation tables and 32 different port groups. You can assign different translation tables to different users to customize the translations available to specific users.


Contents

Dialing String Characters

Cisco Unified MeetingPlace MeetingTime validates all characters entered into a translation table whenever an outdial is requested. Cisco Unified MeetingPlace does a similar validation of all characters it receives for outdial. Invalid characters in the dialing string abort the outdial process.


Valid Characters

The following table lists valid characters in the dialing string.


Note: The fact that a character is valid does not mean that the system always accepts it. Accepting a character string depends on the translation table and the entries in that table.:

Character Description

0 - 9

Dial a DTMF/rotary digit 0 - 9

A

Dial a DTMF digit A

B

Dial a DTMF digit B

C

Dial a DTMF digit C

D

Dial a DTMF digit D

*

Dial a DTMF digit *

#

Dial a DTMF digit #


Control Characters

The following table lists control characters, which are characters that are not dialed.

Character Description

,

Wait 2 seconds before processing the next character in the string.

R

Wait for answer supervision from the far end. See the About Answer Supervision for more information.



Formatting Characters

The following table lists formatting characters, which are characters that are ignored.

Character Description

(

Open parenthesis

)

Close parentheses

-

Dash

<space>

Space



Regular Expressions

Regular expressions are formal descriptions of text (character) strings that allow for flexible and powerful matching operations. Regular expression matching lets you test whether a string fits into a specific syntactic shape and also lets you search a string for a substring that fits a pattern. Cisco Unified MeetingPlace supports all UNIX regular expression operators, which allows for very powerful matching and string substitutions.


The simplest regular expression describes a particular string, for example "210". The string "210", when considered as a regular expression, matches only the string "210".


Non-trivial regular expressions allow special characters to match more than one string. The operator "\|" describes the "or" operation and the operators "[" and "]" describe a set of characters. For example, the regular expression "210\|212" matches either the string "210" or the string "212". The regular expression "21[0-2]" matches the strings with last digit between 0 and 2; that is, "210", "211", and "212".


The following table lists the most common regular expression operators.

Operator Description

.

Dot, matches any single character.

*

Suffix, match 0 or more occurrences of the previous regular expression.

+

Like *, but matches 1 or more occurrences

?

Like *, but matches 0 or 1 of the preceding character.

[ ... ]

Encloses a character set.

\

Quotes a regular expression operator, or introduces special constructs.

\( ... \)

Grouping construct, lets you match a sub-string for future reference.

\|

Or operator, select either regular expressions.


Grouping of expressions can be done by using "\". For example, "\0" refers to the complete expression, and "\1" refers to the first group construct.


The following examples should help understand how regular expressions are used in Cisco Unified MeetingPlace. Under the "Match" column (which corresponds to the "From" column) are the regular expression strings against which the input string will be matched. If the input string does not match the regular expression string, an attempt is made to match the regular expression string on the next line. If the input string does match, then it will be transformed by the string under the "Substitute for" column (which corresponds to the "To" column).

Match Substitute for Explanation

0

200

Substitute string 0 for 200. That is, when dialing "0" for the operator, dial extension "200"

2..

\0

When dialing any extension in the 200 through 299 range, do no translation.

976.......

0

When dialing any number that starts with 976 and follows with any other 7 digits, dial 0 instead. (This is a type of blocking.)

803111

-

When dialing 803111, go offhook on the port and dial no digits (only seize the port).



The advantage of regular expressions is that they are very flexible and can translate virtually anything into anything.


The disadvantages of regular expressions are that they are complex, hard to understand, not user friendly, and they may require lots of entries to be able to completely cover all cases, especially to guarantee that all calls that should be blocked are actually blocked.


Translation Tables without Regular Expressions

NOTE: This content only applies for Cisco Unified MeetingPlace Release 6.0 Maintenance Release 5 (MR5) and later.


Translation tables that do not use regular expressions are similar to tables with regular expressions. The main difference is in the way that patterns are specified in the From: and To: columns. Translation tables without regular expressions, called NOREGEXP, use more simplified patterns.


Translation tables without regular expressions use two kinds of patterns: blocking and non-blocking.


Blocking Patterns

Blocking patterns are used to block outdials to certain regions while non-blocking patterns allow outdials and can be used for translations of source numbers. Blocking patterns allow only digits and dots and match any string that starts with that pattern. For example, the blocking pattern "800" matches the strings 800, 8001, 800123R and so on. The blocking pattern "800.." matches any five or more digit strings that start with 800.

An entry in the table is considered blocking if the port group is set to “BLOCK”. In this case, we recommend setting the To: column to 0.

Examples:

# From To Group DestType Comment

800

0

BLOCK

GENERIC

Block 800 calls

1800

0

BLOCK

GENERIC

Block 800 calls



Non-Blocking Patterns

Non-blocking patterns allow digits, dots, and the letter "R" for answer supervision (but only at the end of the pattern). Non-blocking patterns require an exact match. For example, the pattern "800" matches only string 800, pattern "800.." matches only five digit strings that start with 800, and the pattern "800..R" matches five digit strings that start with 800 and end with the letter "R".

For non-blocking patterns, the To: column specifies how translations are performed. The rules are basically the same as for regular expression-based tables. The difference is that "\0" is the only escape sequence allowed and is used to specify that the complete source string should be copied.

Examples:


# From To Group DestType Comment

........

\0

3

GENERIC

No translation for 8 digits

........R

\0

3

GENERIC

No translation for 8 digits

44.........

9011\0

3

GENERIC

Add 9011 for 11 digit dialing UK

44.........R

9011\0

3

GENERIC

Add 9011 for 11 digit dialing UK


"ALL" Pattern

There is one special pattern that is used to match any string: "ALL". It should be used only at the end of the list to specify what to do with the source number if it does not match any of the previous patterns.

Examples:

# From To Group DestType Comment

ALL

0

BLOCK

GENERIC

Block all other calls

or

# From To Group DestType Comment

ALL

\0

3

GENERIC

No translation


Order of Table Entries

The general rule for the order of table entries is similar to tables with regular expressions. The search always starts from the first entry in the table until a match is found. You should first specify blocking patterns and then follow with translation patterns. The "ALL" pattern comes at the end.


Users can specify a maximum of 256 entries in one translation table. To specify that a translation table does not use regular expressions, you must add the string "NOREGEXP" as a comment in the first line of the file used to initialize the table, as follows:

# NOREGEXP

Note the space between # and NOREGEXP.


If the xlinit utility recognizes that the file does not use regular expressions, it will print the following:

This translation table does not use regular expressions. 

If this line is not printed, the table uses regular expressions.


Translation tables can use either regular or non-regular expressions, but any one table cannot use both at the same time.




Format of the Translation Table Input File

There are 16 active Cisco Unified MeetingPlace digit translation tables, numbered from 0 to 15, at any time in Cisco Unified MeetingPlace. The default configuration for a translation table is no translation (which means that the converted string is identical to the input string).


Comments

All lines that start with a "#" are considered comments and are skipped. Lines that start with the new line character or a space are also skipped.


Columns

Each entry in a translation table corresponds to a single row, composed of five columns, separated by at least one blank space or tab. The five columns are:


From Column

Corresponds to the expression to be matched. This column contains regular expressions against which the input string is checked for a match. If there is no match, then the next line is checked for a match. If there is a match, then the "To" column is utilized. A maximum of 40 characters can be used in this field.


To Column

Corresponds to what the expression should be translated to. If the input string matches the regular expression in column 1 (the "From" column), the input string is string-substituted based on the entry in this column (the "To" column). The converted string will be a string of DTMF digits and dialing commands that Cisco Unified MeetingPlace outdials when placing the call. To seize a port and dial no digits, enter a "-" in this column. A maximum of 40 characters can be used in this field.


Port Group Column

Corresponds to the port group to which ports must belong in order to be selected when placing the call. The valid port groups are between 0 and 15. For an entry that can be used by ports belonging to any port group, use the string "ANYGROUP".


Destination Type Column

Contains the type of telephony device that is expected to answer the outdial. The valid destination device types are:

  • GENERIC-Typical (Plain Old Telephone Service [POTS]) type of device, where Cisco Unified MeetingPlace will play prompts.
  • AUTOANSWER-Auto answer device, where no user is expected to press digits.
  • MEETINGPLACE-Used for simple networking, where another Cisco Unified MeetingPlace system is expected to answer the outdial. Basically the same as an Auto Answer device, except that a "*" DTMF tone is dialed at the end of the string to get back into the meeting.


Comment Column

Contains a comment describing the purpose of the substitution and is useful for the person modifying or analyzing the digit translation table. A maximum of 40 characters can be used in this field.


Order of Entries and Route Optimization

The ordering of the rows in the translation table file is very important because it specifies which translation will take place first. It allows you to block calls and to do some simple route optimization based on port groups.


Simple Route Optimization

Although in general CBXs (Computer-Controlled Branch Exchanges) and PBXs (Private Branch Exchanges) have sophisticated and flexible route optimization capabilities, the translation tables allow for a simple route optimization mechanism. For example, if the following two lines are in the digit translation file:

From To PortGroup DestType Comment

2..

8247\0

0

GENERIC

Use company-internal tie trunks and port group 0.

2..

94089887\0

1

GENERIC

Use the PSTN and port group 1.


the first entry is always used first. Only if all ports in group 0 are busy would the system use the next entry in the translation table, in this case port group 1. If all the ports in group 1 are busy, the system rejects the outdial request.


In the preceding example, the system first selects what is probably the cheapest route (company internal tie trunks) before placing a call over the public network.


When a number can be dialed using more than one port group, the key to route optimization is to include the digit translation entry for the preferred group first.

Rating: 0.0/5 (0 votes cast)

Personal tools