|
|
uOne adheres to E.164 standards for International numbers. International numbers require varying telephone number lengths that may include city code, country code, differing prefix rules, and a multiplicity of dialing rules that vary by country.
uOne provides two sets of Numbering Plan prompts. One supports the North American Numbering Plan (NANP) and the other set is generic. The NANP prompt set references 4, 5, 7, and 10-digit dialing. Although these prompts will be used, uOne will not put limits on the input.
The uOne, FaxPrint, and AMIS-A applications, and the SMSI interface use the Addressing and Dialing Rules for address expansion, conversion to dial string, and for dialing constraints. The DialMap.ini file defines the Addressing and Dialing Rules.
The easiest way to explain how Addressing and Dialing Rules work is to provide some examples.
A subscriber, Sue, calls in to get her messages in a Call Forwarded Access Model. Let's say the phone she calls from is 804-555-5629 (ANI) and the Access Number she is dialing is 804-555-5696 (DNIS). The uOne application first checks whether the ANI is a valid mailbox in the Directory Server. If it is, then uOne will allow Sue to enter a pound key to accept the ANI as the mailbox ID. If it isn't, then uOne will require her to enter a mailbox ID. After she enters a four digit mailbox ID, uOne checks the UM.ini file to see if the LoginExpandSection attribute has a value. If it does, uOne checks the DialMap.ini file to obtain the Addressing and Dialing Rules for expanding the DTMF values for login based on the LoginExpandSection attribute value. (The LoginExpandSection attribute allows subscribers to enter values that need to be expanded). If LoginExpandSection does not exist, then uOne will use the DialPlan section rules for expansion. If the expanded number is not a unique Mailbox ID, then uOne will request the caller to supply a fully qualified telephone number. The unique expanded MailboxID is passed to uOne to be validated against the PIN for login authentication.
After Sue is logged in, uOnewill use DialMap.ini for—
Examples of addressing include forward a message, create distribution lists, record and send a message. Examples of making a call include transfer, make a call, and return call. For expansion, the phone number expansion COS attribute is used (or LoginExpandSection or DialPlan if the attribute is undefined). Let's say she decides to make a call and dials *T 5612. uOne first checks in the Class of Service to see if transfers are allowed. If they are, then uOne accesses the DialMap.ini file to determine how to convert the number to a dial string. uOne uses the Class of Service attribute PhoneNumberDialingSection to determine which set of rules to use in DialMap.ini. If the attribute is undefined, the system uses the [USDOMESTIC] section
If Sue is trying to make a call to someone, uOne will pass the telephone number she entered along with the DialMap.ini format dialing section for the dialing rules to the CMA agent. The CMA agent will validate the number against any constraints that might be defined in DialMap.ini before the call is made. For example, she may not be able to make international and 900 number calls. After the number has been validated against constraints, it is converted using the dialing rules for the dialing section defined in the DialMap.ini, and the call is made. The rules that might apply in this case refer to dialing a 9 and pause to get an outside line, or prepending a 1 at the beginning of a 10-digit number, or possibly removing the area code. If no rules apply, then the number is not dialed. uOne will use the Class of Service attribute PhoneNumberDialingSection (or DialPlan if the attribute is undefined) to determine which set of rules to use in the Addressing and Dialing Rules.
Sue's husband, John, decides to call Sue at 804-555-5629. Sue is not at her desk and the call forwards to Leave a Message. The incoming call RDNIS will be used to determine the Mailbox ID for leaving the message. If the number needs to be expanded, uOne checks the UM.ini file to see if the LoginExpandSection attribute has a value. If it does, uOne checks the DialMap.ini file to obtain the Addressing and Dialing Rules for expanding the DTMF values for login based on the LoginExpandSection attribute value. (The LoginExpandSection attribute allows callers to enter values that need to be expanded. If LoginExpandSection is undefined, then uOne will use the DialPlan section for expansion. If no unique Mailbox ID is determined, then the caller will be provided the Shared Access Model. This is a failover scenario when inadequate call data is provided for the call. The caller will be prompted to select an option to either leave a message, login as a subscriber to get messages, or send a fax. After selecting 1 for Leave a Message, John will be asked to enter a telephone number.
If during Leave a Message, the caller enters a *8 to make another call, the telephone number entered will be converted to a dialable number (dial string). Security is provided by the Class of Service attribute CallerAccessDialingSection to determine which set of rules to use in DialMap.ini. If this section is blank, then the CALLERACCESS section will be used.
When a subscriber wishes to print a fax, the fax is delivered by the FaxPrint application. The fax number where the fax is to be printed has already been expanded by the uOne (according to the Subscriber Access expansion mechanism described above) before it was placed in the subject field of the fax message. FaxPrint uses this number to determine where the fax should be sent. It uses the FAXDialingSection of DialMap.ini to convert the number to a dial string and for security rules.
The SmsiMap rules allow the CMA agent to process out-of-band call information, specifically ANI and RDNIS, from an SMSI interface before that information is made available to uOne. For example, you can create a SmsiMap rule to receive and convert phantom (undialable) numbers. Let's suppose User A in Building 1 is at extension (804) 555-1000 and User B in Building 2 is at extension (804) 762-1000. The phantom phone number for User A is 804 010-1000 and the one for User B is 804 020-1000. Through the use of these phantom phone numbers, User A calls User B by dialing 1000. User B is busy and the call is redirected to the Telecom Object. The Telecom receives the ANI and RDNIS from the SMSI interface and uses the DialMap.ini file to determine how to manipulate the numbers. It checks the SmsiMap rules section in DialMap.ini and finds a rule that applies to each number. The phantom number (804) 010-1000 is converted to (804) 555-1000, and (804) 555-1000 is used as the ANI. This ANI becomes the "Remote Number" Telecom attribute used by uOne. The phantom number (804) 020-1000 is converted to (804) 762-1000, and (804) 762-1000 is used as the RDNIS. This RDNIS becomes the "Redirected Number".
The amisain application uses the DialMap.ini file for address expansion. For example, if a remote voice messaging system passes 7-digit addressing for uOne recipients where the recipient addressing required a 10 digit number, amisain uses the AMIS-A rules in DialMap.ini to expand the address to the required 10-digit number.
Before you start administering the Addressing and Dialing Rules, ensure that the following tasks have been completed.
You perform the following tasks to administer the Address and Dialing Rules
Within the sample UM.ini file, the LoginExpandSection attribute is set to DialPlan for backward compatibility purposes. Therefore, if the DialPlan section of the DialMap.ini file does not exist or is configured improperly, the user will be unable to login on the first two attempts if fewer than 10 digits are entered. On the third attempt, the user will be required to enter 10 digits as the subscriber ID.
You need to complete this section if you want to allow subscribers to dial a number that needs to be expanded to match their mailbox ID during login. This task is not required if your users will always enter a fully qualified telephone number.
1. Go to the Gateserver where the call will be arriving.
2. Go to the UM directory. Type:
cd $PARMLIB/apps/UM
3. Edit the following attribute in the UM .ini file:
4. LoginExpandSection=<PhoneFormat section>
5. Edit the DialMap.ini file and create a format for <PhoneFormat label section> with the login expansion rules. See "Setting Up the DialMap.ini File".
| Attribute | Description | Valid Values |
This value needs to match the PhoneFormat section label that defines the login expansion rules in DialMap.ini file. | This can be any name you choose. |
You need to complete this section if you want to set up constraint and dialing rules for a Class of Service.
1. Access Unified Messaging System Administration (UMSA).
2. Click on the COS Administration button.
3. Click on Add a COS (or Modify a COS).
4. Enter the PhoneFormat section label for the Phone Number Dialing Section field. This value should match the FormatPhoneFormat section label used in the DialMap.ini file to define outdialing rules. See "Setting Up the DialMap.ini File".
5. Enter the CallerAccessDialingSection label for the Caller Access Dialing Section field. This value should match the CallerAccessDialingSection label used in the DialMap.ini file to define caller outdialing rules. See "Setting Up the DialMap.ini File" on page 149.
6. Click on Submit (or Modify).
Assigning Address Expansion Rules for the Class of Service
You need to complete this section if you want to allow members of a COS to use abbreviated addressing for a Class of Service.
1. Access UMSA.
2. Click on the COS Administration button.
4. Enter the search criteria in the input fields.
5. Click on Search.
6. Click on the appropriate class of service definition, if necessary.
7. Enter the PhoneFormat section label for the Phone Number Expansion Section. This value should match the PhoneFormat section label used in the DialMap.ini file to define address expansion rules. See "Setting Up the DialMap.ini File".
8. Click on Modify.
You need to complete this section if you have any of the following:
Set up the DialMap.ini files as follows:
Step 1 Go to the Gateserver where the Telecom Object resides for which you would like to setup Addressing and Dialing Rules.
Step 2 Type: cd $PARMLIB/TNT/parms
Step 3 Edit the DialMap.ini file
Step 4 You can create many sections in the Addressing and Dialing Rules. The following provides the general format:
[PhoneFormat]
Format1
Format2
[Format1]
Rule1
[Format1:Rule1]
FromRegExp=
ToRegExp=
Constraint=
Return=
[Format2] Rule2 [Format2:Rule2]
FromRegExp=
ToRegExp=
Constraint=
Return=
Because the Addressing and Dialing Rules seem complex, a detailed example is included at the end of this chapter (Example 11-1).
| Attribute | Description | Valid Values |
[PhoneFormat] | This is a label for the PhoneFormat section. | It should not be edited. |
Immediately below the [PhoneFormat] label is a listing of all the format section labels that will be defined within the Addressing and Dialing Rules. | Some format section labels require specific names:
Other format names can be any unique name. The major types are:
| |
[Format] | This is a section label for the rules of a specific Format. This should be listed at the beginning of the specific Format section. | |
Immediately below the [Format] label is a listing of all the rules that will be defined for a given Format. | Any name. | |
[Format:Rule] | This is a section label that defines a specific rule for a given format. | For example: [USDOMESTIC:Rule1] |
A regular expression corresponding to the phone number of a phone line from which a number would be dialed. Same as the Token DNIS in the DlgAttrib.<hostname> file. | Regular Expression See the regex UNIX man page for detailed information about what is valid for this attribute. Maximum length is 63 characters. | |
DNIS or dialed number; a regular expression corresponding to the phone number to be converted.
Can also use MinMax to define the minimum and maximum number of digits allowable in a dialed number (address or telephone number). | Regular Expression or MinMax. See the regex UNIX man page for detailed information about what is valid for this attribute. Maximum length is 63 characters. Note SmsiMap rules do not use ToRegExp | |
Specifies a constraint for the rule, that is, the rule will not apply unless the expression evaluates to non-zero, or is None. The common relational operators include: < less than <= less than or equal to == equal to (true) > greater than >= greater than or equal to != not equal to && and || or ! not | Follows the syntax of the Tcl expr command, or may be 'None', if no constraint should be applied. Maximum length is 127 characters. | |
Return | Contains the syntax for building the converted string from matched FromRegExp and ToRegExp substrings, and other literal changes. Also provides minimum and maximum number of digits allowable in a dialed number (address or telephone number). Also provides ability to block certain calls. |
"*,#,a,b,c,d" (DTMF digits) Maximum length is 63 characters. |
The phone number mapping involves three steps:
1. Check to see if the passed "from" and "to" strings match one of the Format:Rule sections (FromRegExp and ToRegExp) within the Addressing and Dialing Rules. The format section to use is specified in the lookup along with the "from" and "to" strings.
2. For the Format:Rule section match, check whether there are is a constraint for the number. If there is, the constraining rule is applied. If the constraint is nonzero (true) or is None, the constraint is satisfied, so the rule is used, otherwise the rule is not used.
3. The system builds a number to return by concatenating the pieces of the numbers broken down in step 1, along with any defined strings.
We strongly recommend that you use the TestDialMap command to test your Addressing and Dialing Rules configuration.
1. On the Gateserver on which you defined your rules, type:
cd $PARMLIB/bin
2. Execute the TestDialMap command. Use the following format.
TestDialMap <FileName> <PhoneFormat> <FROM> <TO>
Example:
TestDialMap DialMap.ini USDOMESTIC 8005556363 8047625600
The TestDialMap command finds the first rule under the specified label that accepts the input. The output of this test displays the Return value of the rule that was applied to the input.
| Argument | Valid Values |
FileName | A DialMap.ini file. |
A PhoneFormat section label from the DialMap.ini file. | |
FROM | Number that will test the rule. |
TO | Number that will test the rule. |
[PhoneFormat]
USDOMESTIC
CALLERACCESS
DialPlan
H225CALLINGPARTY
H225CALLEDPARTY
GWHOSTS
[USDOMESTIC]
MinMax
Block
OfficePBX
[USDOMESTIC:MinMax]
FromRegExp=.*
ToRegExp=MinMax
Constraint=None
Return=4,10
[USDOMESTIC:Block]
FromRegExp=.*
ToRegExp=^(900)$0([0-9]{7})$1$
Constraint=None
Return=BLOCK
[USDOMESTIC:OfficePBX]
FromRegExp=^(804)$0(762)$1([0-9]{4})$2$
ToRegExp=^(804)$0(762)$1([0-9]{4})$2$
Constraint=( 5500 < $t2 ) && ( $t2 < 5699 )
Return=$t2
[CALLERACCESS]
MinMaxRule
FourDigitRule
SevenDigitRule
[CALLERACCESS:MinMaxRule]
FromRegExp=.*
ToRegExp=MinMax
Constraint=None
Return=4,7
[CALLERACCESS:FourDigitRule]
FromRegExp=^(804)$0(762)$1([0-9]{4})$2$
ToRegExp=^([0-9]{4})$0$
Constraint=None
Return=$t0
[CALLERACCESS:SevenDigitRule]
FromRegExp=^(804)$0(762)$1([0-9]{4})$2$
ToRegExp=^([0-9]{3})$0([0-9]{4})$1$
Constraint=None
Return=$t1
[DialPlan]
Rule1
Rule2
[DialPlan:Rule1]
FromRegExp=^(804)$0(762)$1([0-9]{4})$2$
ToRegExp=^([1-2]{1})$0([0-9]{4})$1$
Constraint=( $t0 == 1 ) ( $t1 < 4999 )
Return=80476$t0$t1
[DialPlan:Rule2]
FromRegExp=^(804)$0(762)$1([0-9]{4})$2$
ToRegExp=^([1-2]{1})$0([0-9]{4})$1$
Constraint=None
Return=80468$t0$t1
[H225CALLEDPARTY]
4Digits
10Digits
[H225CALLEDPARTY:4Digits]
FromRegExp=^([A-Za-z0-9:.]*,)$0([0-9]{4})$1$
ToRegExp=None
Constraint=None
Return=$f1
[H225CALLEDPARTY:10Digits]
FromRegExp=^([A-Za-z0-9:.]*,)$0([0-9]{10})$1$
ToRegExp=None
Constraint=None
Return=$f1
[H225CALLINGPARTY]
4Digits
10Digits
[H225CALLINGPARTY:4Digits]
FromRegExp=^([A-Za-z0-9:.]*,)$0([0-9]{4})$1$
ToRegExp=None
Constraint=None
Return=$f1
[H225CALLINGPARTY:10Digits]
FromRegExp=^([A-Za-z0-9:.]*,)$0([0-9]{10})$1$
ToRegExp=None
Constraint=None
Return=$f1
[GWHOSTS]
Rule1
[GWHOSTS:Rule1]
FromRegExp=.*
ToRegExp=^(999)$0(762)$1([0-9]{4})$2$
Constraint=( 5500 < $t2 ) && ( $t2 < 5699 )
Return=gw1z4.cisco.com
| Section | Description |
|---|---|
[PhoneFormat] | The six Phone Formats to be defined are: USDOMESTIC, CALLERACCESS, DialPlan, H225CALLEDPARTY, H225CALLINGPARTY, GWHOSTS. |
[USDOMESTIC] | The format, USDOMESTIC, will have three rules: MinMax, Block, and OfficePBX. |
[USDOMESTIC:MinMax] | The first rule for USDOMESTIC is MinMax and is defined as follows: FROM variable is any number. TO variable is the MinMax value There are no constraints. The system should allow a four or 10-digit number to be dialed. |
[USDOMESTIC:Block] | The second rule for USDOMESTIC is Block and is defined by: FROM variable is any number. TO variable is $0=900, $1=seven digit number. There are no constraints. The system should block any 900 call. |
[USDOMESTIC:OfficePBX] | The third rule for USDOMESTIC is OfficePBX and is defined by: FROM variable is $0=804, $1=762, $2=four digit number TO variable is $0=804, $1=762, $2=four digit number The constraint is $2 must be between 5500 and 5699, then ... The system should dial the four digit extension. |
[CALLERACCESS] | The format, CALLERACCESS, will have 3 rules: MinMaxRule, FourDigitRule, and SevenDigitRule. |
[CALLERACCESS:MinMaxRule] | The first rule for CALLERACCESS is the MinMaxRule and is defined by: FROM variable is any number. TO variable is the MinMax value. There are no constraints. The system should allow a four or seven digit number to be dialed to access the system. |
[CALLERACCESS:FourDigitRule] | The second rule for CALLERACCESS is the FourDigitRule and is defined by: FROM variable is $0=804, $1=762, $2=four digit number TO variable is $0=four digit number There are no constraints. The system should allow a four digit number to be dialed to access the system. |
[CALLERACCESS:SevenDigitRule] | The third rule for CALLERACCESS is the SevenDigitRule and is defined by: FROM variable is $0=804, $1=762, $2=four digit number TO variable is $0=three digit number, $1=four digit number There are no constraints. The system should allow a seven digit number to be dialed to access the system. |
[DialPlan] | The format, DialPlan, will have two rules: Rule1 and Rule2. |
[DialPlan:Rule1] | The first rule for DialPlan is Rule1 and is defined by: FROM variable is $0=804, $1=762, $2=four digit number TO variable $0=first digit is a 1 or 2, $1=four digit number The constraints are if the first digit of the ToRegExp is 1 and it is between 2001 and 4998 then... The system should outdial 80476 and the five-digit number. |
[DialPlan:Rule2] | The second rule for DialPlan is Rule2 and is defined as defined by: FROM variable $0= 804, $1=762, $2=four digit number TO variable $0=first digit is a 1 or 2, $1=four digit number The constraints are if the first digit of the ToRegExp is 1 and it is between 5001 and 5998 then... The system should outdial 80468 and the five-digit number. |
[H225CALLEDPARTY] | The format, H225CALLEDPARTY, will have two rules: 4Digits and 10Digits. |
[H225CALLEDPARTY:4Digits] | The first rule for H225CALLEDPARTY is 4Digits and is defined by: FROM variable TO variable is none. There are no constraints.
|
[H225CALLEDPARTY:10Digits] | The first rule for H225CALLEDPARTY is 10Digits and is defined by: FROM variable TO variable There are no constraints. The system should |
[H225CALLINGPARY] | The format, H225CALLINGPARTY, will have two rules: 4Digits and 10Digits. |
[H225CALLINGPARTY:4Digits] | The first rule for H225CALLINGPARTY is 4Digits and is defined by: FROM variable TO variable There are no constraints. The system should |
[H225CALLINGPARTY:10Digits] | The first rule for H225CALLINGPARTY is 10Digits and is defined by: FROM variable TO variable There are no constraints. The system should |
[GWHOSTS] | The format, GWHOSTS, will have one rule: Rule1. |
[GWHOSTS:Rule1] | The only rule for GWHOSTS is Rule1 and is defined by: FROM variable is any number. TO variable is $0=999 $1=762 $2=four digit number The constraint is $2 must be between 5500 and 5699, then ... The system should access gw1z4.cisco.com to provide faxing capabilities. |
Posted: Mon Sep 25 19:13:06 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.