Table Of Contents
Implementing Cisco Unified Border Element (SP Edition) Policies
Contents
Prerequisites for Implementing Policies
Restrictions
Information About Implementing Policies
Cisco Unified Border Element (SP Edition) Policies
Policy Events
Policy Stages
Policy Sets
Modifying the Active Policy Set
Policy Tables
Number Analysis Policies
Number Validation
Number Categorization
Digit Manipulation
Routing
Routing Tables and Adjacencies
Number Manipulation
Hunting
Regular Expression Based Routing
H.323 Call Routing Features
H.323 Hunting
Picking a Next Hop in Routing Policy
Support for H.323 addressing
DNS Name Resolution
Number Validation and Editing
Load Balancing
Inter-VPN Calling
Call Admission Control
Call Admission Control Overview
Compound Scopes
Policy scopes
Policy Set tables and Limit tables
Limit Tables
CAC Table Entry Configuration Commands
Non-limiting CAC Options
Media Line Removal
Media Bypass in Call Admission Control
CAC Rate Limiting
Subscriber Policy
How to Implement Policies
Configuring Number Analysis Tables
Configuring Number Validation
Configuring Number Categorization
Configuring Routing Tables
Configuring a Destination Address Table
Configuring the Destination, Source Domain, and Carrier ID Tables
Configuring the Category Table
Configuring the Least Cost Table
Configuring Time-Based Tables
Configuring Trunk-Group ID Tables
Configuring Number Manipulation
Configuring Hunting
Activating a Routing Policy Set
Configuring H.323 MultiARQ Hunting
Configuring Call Admission Control Policy Sets and CAC Tables
Activating a CAC Policy Set
Configuration Example of Implementing Number Analysis
Configuration Examples of Implementing Call Routing
Routing with No Load Balancing: Example
Least Cost Routing: Example
Weighted Routing: Example
Time-Based Routing: Example
Regular Expression Based Routing: Example
Trunk-Group ID Routing: Example
Configuration Example of Implementing Call Admission Control Policy Sets and CAC Tables
Implementing Cisco Unified Border Element (SP Edition) Policies
A Cisco Unified Border Element (SP Edition) policy is a set of rules that define how the Cisco Unified Border Element (SP Edition) treats different kinds of voice over IP (VoIP) events. A Cisco Unified Border Element (SP Edition) policy allows you to control the VoIP signaling and media that passes through the Cisco Unified Border Element (SP Edition) at an application level.
Note 
For Cisco IOS XE Release 2.4 and later, this feature is supported in the unified model.
Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).
For a complete description of commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html.
For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
Feature History for Implementing Cisco Unified Border Element (SP Edition) Policies
Release
|
Modification
|
Cisco IOS XE Release 2.4
|
This feature was introduced on the Cisco ASR 1000 Series Aggregation Services Routers along with support for the unified model.
|
Cisco IOS XE Release 2.5
|
Subscriber Policy support, Regular expression based routing support, SIP trunk-group ID routing support, and the SIP media line removal feature were added on the Cisco ASR 1000 Series Routers.
Support for H.323 call routing features: H.323 Hunting and multiARQ hunting, Picking a next Hop in Routing Policy, Support for H.323 Addressing, DNS Name Resolution, Number Validation and Editing, Load Balancing, and Inter-VPN Calling were added on the Cisco ASR 1000 Series Routers.
|
Contents
This chapter contains the following sections:
•Prerequisites for Implementing Policies
•Restrictions
•Information About Implementing Policies
•How to Implement Policies
•Configuration Example of Implementing Number Analysis
•Configuration Examples of Implementing Call Routing
•Configuration Example of Implementing Call Admission Control Policy Sets and CAC Tables
Prerequisites for Implementing Policies
The following prerequisites are required to implement Cisco Unified Border Element (SP Edition) policies:
•Before implementing policies, Cisco Unified Border Element (SP Edition) must already be configured. See the procedures described in Chapter 2, "Configuring Cisco Unified Border Element (SP Edition)."
Restrictions
The following restrictions apply when you implement routing policies on the Cisco Unified Border Element (SP Edition):
•H.323 protocols are not supported in Cisco IOS XE Release 2.4 and earlier.
•Regular expression matching is only supported for text user names and domain names in source or destination URIs for SIP calls. Regular expression matching for telephone numbers used in H.323 calls is not supported.
•SBC does not allow addition, modification, or removal of trunk-group ID (TGID) information before call routing occurs.
•SBC does not allow regular expression matching when performing TGID routing.
Information About Implementing Policies
A policy is a set of rules that define how the Cisco Unified Border Element (SP Edition) treats different kinds of VoIP events. A Cisco Unified Border Element (SP Edition) policy allows you to control the VoIP signaling and media that passes through Cisco Unified Border Element (SP Edition) at an application level. Figure 12-1 shows an overview of policy control flow.
Figure 12-1 Policy Control Overview
Number analysis and routing are configured in one type of configuration set, admission control is configured in another.
Number analysis (NA) determines whether a set of dialed digits represents a valid telephone number (based on number validation, number categorization, or digit manipulation). Call routing determines the VoIP signaling entity to which a signaling request should be sent. A destination adjacency is chosen for the signaling message based on various attributes of the message (for example, based on source account or adjacency). Routing policy is applied to new call events and to subscriber registration events.
Call Admission Control (CAC) limits the number of concurrent calls and registrations, and restricts the media bandwidth dedicated to active calls. It allows for load control on other network elements by rate limiting. Certain events can be completely blocked (using a blacklist) or freely allowed (using a whitelist), based on certain attributes.
Not all policies are mandatory:
•To call between subscribers, only endpoint routing policy is required.
•To call between telephone numbers, only call routing policy is required.
•Number analysis and admission control are optional, although they are likely to be required by the user.
Policies refer to accounts and adjacencies by name. Therefore, you may find it useful to configure and name adjacencies before configuring policies although this is not required.
The following sections describe the many concepts critical to understanding how to implement Cisco Unified Border Element (SP Edition) policies:
•Cisco Unified Border Element (SP Edition) Policies
•Number Analysis Policies
•Routing
•H.323 Call Routing Features
•Call Admission Control
Cisco Unified Border Element (SP Edition) Policies
This section describes the following Cisco Unified Border Element (SP Edition) policies:
•Policy Events
•Policy Stages
•Policy Sets
•Policy Tables
Policy Events
Policies are applied to the following events:
•New calls—When new SIP or H.323 calls are signaled to the Cisco Unified Border Element (SP Edition), Cisco Unified Border Element (SP Edition) applies a policy to determine what happens to the new call request and what constraints the call must satisfy during its lifetime.
•Call updates—If one of the endpoints in a call attempts to renegotiate new media parameters, Cisco Unified Border Element (SP Edition) applies policy to ratify the attempt.
•Subscriber registrations—If a subscriber attempts to register through Cisco Unified Border Element (SP Edition), Cisco Unified Border Element (SP Edition) applies policy to determine what happens to the registration request.
Policy Stages
There are three distinct stages of a policy, which are applied in strict order to the policy events for SIP and H.323 calls. The stages in which policy is applied are as follows:
•Number analysis
•Routing
•Admission control
Some of these policy stages are skipped for particular types of events. Figure 12-2 shows the sequence of the policy stages for each event type.
Figure 12-2 Policy Stages for Event Types
If the policy stages fail, the call is rejected and the failure is propagated back to the calling device (using either session initiation protocol (SIP) or H.323 signaling, as appropriate) with the error codes in Table 12-1.
Table 12-1 Policy Stage Errors
Component
|
Resulting SIP Error Code
|
Resulting H.323 Error
|
Number analysis
|
604 "Does not exist anywhere"
|
ITU-T Q.931 Release Complete UUIE with H.225 Reason field unreachableDestination
|
Routing
|
604 "Does not exist anywhere"
|
ITU-T Q.931 Release Complete UUIE with H.225 Reason field unreachableDestination
|
Call Admission Control
|
503 "Service Unavailable"
|
ITU-T Q.931 Release Complete UUIE with H.225 Reason field noPermission
|
Note If the call fails at the routing or Call Admission Control phase, it is released. There is no attempt to retry. Whether or not to retry is left to the upstream (calling) device to decide.
The following sections describe policy stages in more detail:
•Number Analysis
•Routing
•Admission Control
Number Analysis
Number Analysis (NA) determines whether a set of dialed digits represents a valid telephone number. This is achieved by configuring one or more tables of valid dialed digit strings using a limited-form regular-expression syntax, then matching the actual dialed digits against the different strings in the tables.
NA policy is applied only to new call events. If NA determines that a new call does not contain a valid set of dialed digits, Cisco Unified Border Element (SP Edition) rejects the call, using the error code described in the "Policy Stages" section.
NA rules are sensitive to the source account and source adjacency of a call, which allows different dial plans to be configured for different customer organizations, or even for different endpoints.
In addition to validating a dialed number, NA policy can also:
•Reformat the dialed digits into canonical form; for example, E.164 format.
•Label the call with a category, which is used by the later stages of policy.
Routing
Routing determines the next-hop VoIP signaling entity to which a signaling request should be sent. Routing of VoIP signaling messages occurs in two stages:
•Policy-based routing—The first stage of routing. In policy-based routing, a destination adjacency is chosen for the signaling message, based on various attributes of the message, discussed later.
•Protocol-based routing—Takes place after policy-based routing. Protocol-based routing uses a VoIP protocol-specific mechanism to deduce a next-hop IP address from the signaling peer configured for the destination adjacency chosen by policy-based routing.
For example, if the destination adjacency is a SIP adjacency and the signaling peer is uk.globalisp.com, Cisco Unified Border Element (SP Edition) uses domain name server (DNS) or IP lookup to determine the IP address and port of the SIP server for the domain uk.globalisp.com, and forwards the appropriate signaling message to that IP address and port.
Routing policy is applied to new call events and to subscriber registration events.
If a new call event matches an existing subscription, the call is routed automatically to the source IP address and port of the original subscriber registration. No configured policy is required to achieve this, and no configured policy can influence the routing of such calls.
Routing policy is not applied to call update events; call update signaling messages are routed automatically to the destination adjacency that was chosen for the new call event that originated the call.
It is possible that an event cannot be routed, if its attributes do not match a suitable configured routing rule. In such cases, Cisco Unified Border Element (SP Edition) rejects the event using a suitable error code.
Regular expression based routing feature allows the user to configure routing rules that use regular expressions to match the user name or domain part of a source or destination SIP URI.
SBC supports SIP trunk-group ID routing which provides call routing based on the value of the source or destination TGID parameters in the received SIP INVITE message.
Note A trunk in a network is a communication path connecting two switching systems used in the establishment of an end-to-end connection. A trunk-group is a set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable. TGID is a string that identifies a trunk-group uniquely within a given context.
Admission Control
Call admission control determines whether an event should be granted or refused based on configured limits for network resource utilization. There are two reasons for performing admission control.
•To defend load-sensitive network elements, such as softswitches, against potentially harmful levels of load precipitated by singular events, such as DoS attacks, natural or man-made disasters, or mass-media phone-ins.
•To police the Service Level Agreements (SLAs) between organizations, to ensure that the levels of network utilization defined in the SLA are not exceeded.
Call admission control policy is applied to all event types. If an event is not granted by admission control policy, then Cisco Unified Border Element (SP Edition) rejects it with a suitable error code.
Policy Sets
A policy set is a group of policies that can be active on Cisco Unified Border Element (SP Edition) at any one time. If a policy set is active, then Cisco Unified Border Element (SP Edition) uses the rules defined within it to apply policy to events. You can create multiple policy sets on a single Cisco Unified Border Element (SP Edition).
A policy set has two potential uses:
•It enables you to atomically modify the configured policy by creating a copy of the currently active policy set, making all necessary changes, reviewing the modified policy, and then switching the active policy set. If a problem is discovered with the new policy set after it is activated, Cisco Unified Border Element (SP Edition) can be switched back to using the previous policy set with a single command.
•It enables you to create different policy sets for use at different times and to switch between them at the appropriate times.
Number analysis and routing are configured in a call policy set. Admission control is configured in a CAC policy set.
Only one policy set of each type can be active at any given time. You can switch the active policy set at any time. You cannot modify the currently active policy set, but can modify policy sets that are not active.
A new policy set either can be created empty (that is, without any configured policies), or created as a copy of another policy set. A policy set can be deleted, provided that it is not the active policy set.
When the Cisco Unified Border Element (SP Edition) is initialized, there are no active policy sets. At any time after initialization, the active policy set can be undefined. While there is no active routing policy, each event that requires routing is rejected.
Modifying the Active Policy Set
If you need to modify the active policy set for either a CAC policy or call policy, you need to perform the following procedure:
1. Create a new policy-set.
2. Copy the active policy-set configuration to the new policy-set.
3. "no complete" on the new policy-set.
4. Make changes to the new policy-set.
5. "complete" on the new policy-set.
6. Verify changes to the new policy-set.
7. Make the new policy-set active using `active-cac-policy-set num' or `active-call-policy-set num'.
Examples of modifying an active cac-policy-set
The following configuration examples describe the steps involved in each of the procedures for modifying the active policy set. The active policy set in these examples is the following existing CAC policy set, cac-policy-set 30:
Router#show run | b cac-policy-set 30
max-num-calls-per-scope 10
Step 1 Create a new "cac-policy-set 31" and
Step 2 Copy the "cac-policy-set 30" subcommands:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config-sbc-sbe)# cac-policy-set 31
Router(config-sbc-sbe-cacpolicy)# first-cac-table TAB1
Router(config-sbc-sbe-cacpolicy)# cac-table TAB1
Router(config-sbc-sbe-cacpolicy-cactable)# table-type limit all
Router(config-sbc-sbe-cacpolicy-cactable)# entry 1
Router(config-sbc-sbe-cacpolicy-cactable-entry)# max-num-calls-per-scope 10
Router(config-sbc-sbe-cacpolicy-cactable-entry)# action cac-complete
Router(config-sbc-sbe-cacpolicy-cactable-entry)# complete
Router(config-sbc-sbe-cacpolicy) #do sho run | b cac-policy-set 31
max-num-calls-per-scope 10
Step 3 Perform a "no complete" on the new cac-policy-set:
Router(config-sbc-sbe-cacpolicy)# no complete
Step 4 Modify the new cac-policy-set with necessary changes:
Router(config-sbc-sbe-cacpolicy)# cac-table TAB1
Router(config-sbc-sbe-cacpolicy-cactable)# entry 1
Router(config-sbc-sbe-cacpolicy-cactable-entry)# $max-call-rate-per-scope 100
Step 5 Perform a "complete" on the new cac-policy-set:
Router(config-sbc-sbe-cacpolicy-cactable-entry)# complete
Step 6 Verify the new cac-policy-set:
Router(config-sbc-sbe-cacpolicy)# do sho run | b cac-policy-set 31
max-call-rate-per-scope 100
max-num-calls-per-scope 10
Step 7 Activate the new cac-policy-set.
Router(config-sbc-sbe-cacpolicy)# active-cac-policy-set 31
Router(config-sbc-sbe)# end
Router# show run | b cac-policy-set 30
max-num-calls-per-scope 10
max-call-rate-per-scope 100
max-num-calls-per-scope 10
Policy Tables
All policies on the SBE is configured in a set of tables. This section describes the overall structure of the policy tables, as described in the following sections:
•Nomenclature
•Application of Policy
•Policy Table Example
Nomenclature
This section defines some terms that we later use when discussing policy tables.
A policy table has the following properties:
•A name that uniquely identifies the table within the scope of a single policy set. Tables in different policy sets may have the same name.
•A type, which defines the criterion that is used to select an entry from the table.
•A collection of table entries.
A policy table entry is a member of a policy table. It has the following properties:
•A value to match on (the match value). The semantics of this value are determined by the table type. No two entries in the same table may have identical match values.
•An optional action to perform on the event, if it matches this entry.
•An optional name of the next table to search for policy, if the event matches this entry.
Application of Policy
The policy tables are searched whenever an event occurs. The policy to be applied to the event is built up as the tables are searched.
The policy sets contains the following properties, which define which policy tables are searched at each stage of the policy calculation. The call policy set contains:
•First NA policy table to process
•First routing policy table to process for calls
•First routing policy table to process for endpoint registrations
The CAC policy set contains the first admission control policy table.
When an event occurs, the policy tables are searched as follows. This procedure is followed once for every stage of policy to which an event is subjected.
•The first table for the particular stage of the policy calculation is obtained from the active configuration set.
•The type of the table defines which of the event's attributes (for example, the destination number or the source adjacency) is being examined by this table.
•This attribute is compared against the match value of every entry in the table. This results in either exactly one entry matching the event, or no entries matching the event.
•If an entry matches the event, then the action associated with that entry is performed. After the action is performed, if the entry contains the name of a next table, that table is processed. If there is no next table, then the policy calculation is complete and processing for this stage of policy ends.
•If no entry matches the event, then the policy calculation is complete and processing for this stage of policy ends.
Policy Table Example
The following example illustrates the flow of control as policy tables are parsed at a particular stage of policy for a particular event. The event in this example is a new call, received from source account with destination number 129. The stage of policy considered here is routing.
This example is provided for illustrative purposes only; routing tables are described in detail in the "Routing" section.
Figure 12-3 shows the relevant routing tables.
Figure 12-3 Policy Table Example
The policy calculation begins by looking up the first policy table to be used by the routing stage. This is the table with name RtgAnalyzeSourceAccount. This table is processed as follows:
•The table type of the table is src-account, so the source account of the new call event is compared with each of the entries in this table.
•The table entry that matches on csi provides a match for this new call event. There is no action associated with this entry, but the entry points to a next table with name RtgAnalyzeDestCSINumber.
The flow of control then passes to the table with name RtgAnalyzeDestCSINumber. This table is processed as follows:
•The cac-scope of the table is dst-number, so the destination number of the new call event is compared with each of the entries in this table.
•The table entry that matches on 1xx provides a match for this new call event. The action associated with this entry is performed; that is, the destination adjacency for the new call event is set to csi-chester.
•This entry does not point to a next table, so the policy calculation for the routing stage ends.
This example shows successful routing of the new call. The outcome is successful because the destination adjacency of the new call is selected before the policy calculation finishes. It is entirely possible for the outcome of routing to be unsuccessful for a new call if the routing policy tables do not assign a destination adjacency to the call before the routing policy calculation ends. For example, the routing policy illustrated above does not successfully route a new call whose source account is csi and whose destination number is 911.
In this example, a single entry is selected from each table that is traversed during the calculation. In general, at most one entry in any policy table matches an event to which policy is being applied. In cases in which more than one entry would match an event, the best matching entry is selected.
Number Analysis Policies
Three different types of Number Analysis (NA) policies are configured within NA tables. These types of NA policies are applied simultaneously to new calls and are described in the following sections:
•Number Validation
•Number Categorization
•Digit Manipulation
Number Validation
Number validation is fundamental to the process of traversing number analysis policy tables. A number is validated if the NA tables are traversed and the final entry examined contains an action of accept. A number is not valid if the NA tables are traversed, and the final entry examined contains an action of reject. A number also is not valid if, at any stage of processing the NA tables, a table with no matching entries is encountered.
Number analysis tables can be one of the following types:
•dst-number—Tables of this type contain entries whose match values represent complete numbers. In such tables, an entry matches an event if the entire dialed digit string exactly matches the match value of the entry.
•dst-prefix—Tables of this type contain entries whose match values represent number prefixes. In such tables, an entry matches an event if there exists a subset of the dialed digit string, consisting of consecutive digits taken from the front of the dialed digit string, that exactly matches the match value of the entry.
•src-account—Tables of this type contain entries whose match values are the names of accounts. In such tables, an entry matches an event if the name of the source account of the event exactly matches the match value of the entry.
•src-adjacency—Tables of this type contain entries whose match values are the names of adjacencies. In such tables, an entry matches an event if the name of the source adjacency of the event exactly matches the match value of the entry.
•carrier-id—Tables of this type contain entries matching the carrier ID.
Digit-matching NA Tables
The format of the match values of entries in NA tables that match on the destination number or destination number prefix is a limited-form, regular expression string representing a string of dialed digits. The syntax used is described in Table 12-2.
Table 12-2 Syntax of Match Values for Entries in Digit-matching NA Tables
X
|
Any numerical digit 0 - 9.
|
( )
|
The digit within the parentheses is optional. For example, (0)XXXX represents 0XXXX and XXXX.
|
[ ]
|
One of the digits within the square brackets is used. For example, [01]XXX represents 0XXX and 1XXX. A range of values can be represented within the square brackets. For example, [013-5]XXX represents 0XXX, 1XXX, 3XXX, 4XXX and 5XXX.
|
*
|
The * key on the telephone.
|
#
|
The # key on the telephone.
|
-
|
Digit delimiter
|
,
|
Digit delimiter
|
a-f/A-F
|
Hexadecimal digits
|
In such tables, it is always possible that more than one entry in the table may match a particular digit string. For example, entries that match 1xx and 12x both match a digit string 129. However, a single entry must be chosen from each table, so the Cisco Unified Border Element (SP Edition) chooses the best matching entry by applying the following rules in the order given.
Step 1 Choose the longest explicit match.
If the NA table is a dst-prefix type, it is possible that more than one entry specifies an explicit number (that is, one that contains no X characters or [ ] constructs) and matches the dialed number of the event. In this situation, the entry with the longest number has priority.
For example, the dialed number begins 011, the number validation table is a dst-prefix type, and there are two matching entries with numbers 01 and 011. The entry with the number 011 takes priority, because it is a longer number.
Step 2 If there is no explicit match, choose the longest wildcard match.
If the table does not contain an explicit entry to match the dialed number of the event, the longest wildcard entry that matches takes priority.
Step 3 If there are multiple wildcard matches of the same length, choose the most explicit where possible.
For example, the dialed number is 01234567890, the NA table is a dst-number type, and there are two matching entries with match values 0123XXXXXXX and 0123456XXXX. In the first entry, the fifth digit is a wildcard; in the second entry, the eighth digit is a wildcard, so the second entry takes priority.
If the same number is dialed, and a different NA table has matching entries [01]234XXXXXXX and 0XXXXXXXXXX, the second entry takes priority, because in the first entry the first digit is a wildcard.
Number Categorization
Events can be placed into user-defined categories during NA processing. This is achieved by specifying a categorization action in an entry of an NA table. Categories are useful, because they may be referred to later during the admission control policy stage.
At most, one category may be associated with an event. If, during processing of the NA tables, categories are assigned to an event multiple times, then the last category to be assigned is used. When a category is assigned to an event, it cannot be deleted, only replaced with another category.
Digit Manipulation
During number analysis (NA), it is often a requirement to normalize numbers—in other words, convert them from the internal format used by a particular organization or service provider to a canonical format understood globally in the Internet and PSTN.
This is achieved by specifying one or more of the following actions in an entry of an NA table:
•del-prefix N—This action removes the leading n digits from the dialed digit string, or deletes the entire string if it is n or fewer digits long.
•del-suffix n—This action removes the final n digits from the dialed digit string, or deletes the entire string if it is n or fewer digits long.
•add-prefix digit string—This action adds the given digit string to the front of the dialed digit string.
•replace digit string—This action replaces the entire dialed digit string with the given digit string.
Routing
This section describes the following routing policies:
•Routing Tables and Adjacencies
•Number Manipulation
•Hunting
•Regular Expression Based Routing
Routing Tables and Adjacencies
This section explains how routing tables are configured on the Cisco Unified Border Element (SP Edition).
The inputs to the policy-based routing stage are as follows:
•The destination number of the event, which is the post-NA dialed digit string (that is, it may have been modified from the original dialed digit string)—This input is present only if the event is a new call.
•The source number of the event—This input is present only if the event is a new call.
•The source adjacency of the event.
•The source account of the event.
The routing policy tables examine some or all of these inputs, and produce one of the following outputs:
•A single destination adjacency.
•A group of adjacencies used for load balancing. One of these is chosen, depending on the load previously sent to the adjacencies in this group.
Routing tables represent one of the following types:
•dst-address—Tables of this type contain entries matching the dialed number (after number analysis). These values are either complete numbers or number prefixes (depending on whether the prefix parameter is given). Without the prefix parameter, an entry matches an event if the dialed digit string exactly matches the match value of the entry. With the prefix parameter, an entry matches an event if there exists a subset of the dialed digit string, consisting of consecutive digits taken from the front of the dialed digit string that exactly matches the match value of the entry.
Routing actions also match text user name using a regular expression rather than a literal text string. Routing actions are considered to match if the regular expression matches at least one part of the address.
•src-address—Tables of this type contain entries matching the dialer's number or SIP user name. These values are either complete numbers or number prefixes (depending on whether the prefix parameter is given). Without the prefix parameter, an entry matches an event if the entire digit string representing the calling number exactly matches the match value of the entry. With the prefix parameter, an entry matches an event if there exists a subset of the digit string that represents the calling number, consisting of consecutive digits taken from the front of this string that exactly match the match value of the entry.
Routing actions also match text user name using a regular expression rather than a literal text string. Routing actions are considered to match if the regular expression matches at least one part of the address.
•src-account—Tables of this type contain entries matching the names of accounts. In such tables, an entry matches an event if the name of the source account of the event exactly matches the match value of the entry.
•src-adjacency—Tables of this type contain entries matching the names of adjacencies. In such tables, an entry matches an event if the name of the source adjacency of the event exactly matches the match value of the entry.
•src-domain—Tables of this type contain entries matching the source domain names.
Routing actions also match domain names using full regular expressions rather than the limited range of regular expression matching. Routing actions are considered to match if the regular expression matches at least one part of the domain.
•dst-domain—Tables of this type contain entries matching the destination domain names.
Routing actions also match domain names using full regular expressions rather than the limited range of regular expression matching. Routing actions are considered to match if the regular expression matches at least one part of the domain.
•carrier-id—Tables of this type contain entries matching the carrier ID.
•round-robin-table—A group of adjacencies are chosen for an event if an entry in a routing table matches that event and points to a round-robin adjacency table in the next-table action. A round-robin adjacency table is a special type of policy table, whose events do not have any match-value parameters, nor next-table actions. Its actions are restricted to setting the destination adjacency and performing digit manipulation.
•category—Tables of this type contain entries matching on the category that was assigned to the call during number analysis. You assign the category during number analysis.
•time—Tables of this type contain entries matching on a user-configured time. The entries can have overlapping match periods. Time periods can be specified by year, month, date, day of the week, hour, or minute.
•least-cost—Tables of this type contain entries matching on the user-configured precedence (cost) of the entries. If more than one entry has an equal cost, an entry is selected based on a user-configured weight or an entry is selected based on the number of active calls on each route. If routing fails, then the adjacency with the next lowest cost is selected.
•src-trunk-group-id—Tables of this type contain entries matching the source TGID or TGID context parameters and action type to perform the call routing.
•dst-trunk-group-id—Tables of this type contain entries matching the destination TGID or TGID context parameters and action type to perform the call routing.
The rules specified in the "Digit-matching NA Tables" section govern the format and matching rules of the match-values of the entries in routing tables of type dst-number, dst-prefix, src-number and src-prefix.
Number Manipulation
The number manipulation feature enables you to specify various number manipulations that can be performed on a dialed number after a destination adjacency has been selected. Number manipulation can be configured as a routing policy.
This enhancement affects the billing functionality as it allows the Cisco Unified Border Element (SP Edition) to display both the original and the edited dialed number for a call. For example:
<party ty"e="o"ig" pho"e="01234567890"/>
<party ty"e="t"rm" pho"e="23456789"31" editphone="1111111111111"/>
Note The phone numbers in the above example are not real.
The number manipulation feature requires that the edit action be allowed in the routing policy entries. The edit action takes the same parameters as the edit action for the number analysis tables, enabling you to delete a number of characters from the beginning or end of the dialed string, add digits to the start of the string, or replace the entire string with another. For example, if the following table were matched:
rtg-src-adjacency-table table1
then the dialed string would have the first three of its digits deleted.
In the number analysis stage you can specify categories as shown below.
first-number-analysis-table check-accounts
na-src-account-table check_accounts
action next-table hotel_dialing_plan
action next-table hotel_dialing_plan
na-dst-prefix-table hotel_dialing_plan
Later during routing, the calls are routed based on assigned categories.
first-call-routing-table start_routing
rtg-category-table start_routing
action next-table internal_routing
action next-table external_routing
rtg-src-adjacency-table internal_routing
match-adjacency sip_from_foo
match-adjacency sip_from_bar
rt-dst-address-table external_routing
dst-adjacency sip_to_softswitch
Note The category of a call cannot be changed in a routing table. Categories are only assigned during number analysis.
You can also specify various number manipulations to be performed on a dialing or dialed number after a destination adjacency is selected.
The following example adds a prefix of "123" to the source number, for all calls coming in on "SipAdj1" adjacency and destined to "SipAdj2".
rtg-src-adjacency-table table1
Hunting
Cisco Unified Border Element (SP Edition) can hunt for other routes or destination adjacencies in case of a failure. Hunting means the route is retried. Cisco Unified Border Element (SP Edition) supports hunting of SIP and H.323 calls. Hunting can be configured as a routing policy.
There are several ways in which failures can occur, including the following:
•CAC policy refusing to admit a call
If a CAC policy rejects a call, the SBC automatically attempts to reroute the call using the Routing Policy Service (RPS). RPS decides where to route onward signaling requests by using the configured policy in the RPS. The call is then tested against CAC policy again.
•Routing Policy Services being unable to route a call
•Call setup failure being received from SIP or H.323.
When the SBC receives a call setup failure notification from H.323 or SIP, it is notified whether or not it should attempt to reroute the call, depending upon the error code.
If an SIP or H.323 adjacency attempts to route a call, and the attempt fails, it receives an error code. You can configure which error codes trigger hunting or rerouting.
•If the error code received by the adjacency matches an entry on this list, RPS is signalled to reroute the call. Rerouting then occurs unless the number of attempts exceeds the limit set as the maximum number of routing attempts that SBC makes. The default is three attempts.
•If the error code received by the adjacency does not match an entry on this list, RPS is signalled not to reroute the call.
For both SIP and H.323 call, you can configure a list of error codes or failure return codes to trigger hunting or rerouting for a particular adjacency by using the
sip hunting-trigger error-codes or
hunting-trigger error-codes commands
You can also configure a list of H.323 error codes at a global level, by using the hunting-trigger command in the global H.323 configuration mode.
SIP error codes are numeric error codes. H.323 error codes are textual. See the "Configurable Error Codes to Trigger Hunting" table.
Hunting finishes when one of the following conditions is met:
•The call is successfully routed.
•The SBC receives a call setup failure notification with the instruction not to continue hunting, in which case the call fails.
•The SBC has made the number of specified routing attempts and the call has not been successfully routed, in which case the call fails.
•The SBC has tried all available adjacencies, and the call has not been successfully routed, in which case the call fails.
H.323 hunting has the additional hunting modes of alternate endpoints and multiARQ hunting. See the "H.323 Call Routing Features" section.
For information on configuring SIP and H.323 hunting, see the "Configuring Hunting" section.
The following table lists the supported error codes that you can configure to trigger hunting of SIP or H.323 calls.
Table 12-3 Configurable Error Codes to Trigger Hunting
Supported SIP Error Codes
|
Supported H.323 Error Codes
|
400 - Bad Request
|
unreachableDestination
|
401 - Unauthorized
|
noPermission
|
402 - Payment Required
|
noBandwidth
|
403 - Forbidden
|
destinationRejection
|
404 - Not Found
|
gatewayResources
|
405 - Method Not Allowed
|
badFormatAddress
|
406 - Not Acceptable
|
securityDenied
|
407 - Proxy Authentication Required
|
the internally-defined value "connectFailed"
|
408 - Request Timeout
|
|
409 - Conflict
|
|
410 - Gone
|
|
411 - Length Required
|
|
413 - Request Entity Too Large
|
|
414 - Request URI Too Long
|
|
415 - Unsupported Media Type
|
|
416 - Unsupported URI Scheme
|
|
420 - Bad Extension
|
|
421 - Extension Required
|
|
423 - Interval Too Brief
|
|
480 - Temporarily Unavailable
|
|
481 - Call/Transaction Does Not Exist
|
|
482 - Loop Detected
|
|
483 - Too Many Hops
|
|
484 - Address Incomplete
|
|
485 - Ambiguous
|
|
486 - Busy Here
|
|
487 - Request Terminated
|
|
488 - Not Acceptable Here
|
|
491 - Request Pending
|
|
493 - Undecipherable
|
|
500 - Server Internal Error
|
|
501 - Not Implemented
|
|
502 - Bad Gateway
|
|
503 - Service Unavailable
|
|
504 - Server Time-Out
|
|
505 - Version Not Supported
|
|
513 - Message Too Large
|
|
600 - Busy Everywhere
|
|
603 - Declined
|
|
604 - Does Not Exist Anywhere
|
|
605 - Not Acceptable
|
|
Regular Expression Based Routing
Regular expression based routing allows the user to configure routing rules that use regular expressions to match the user name or domain part of a source or destination SIP URI.
Routing actions match text user name using a regular expression rather than a literal text string when "regex" keyword is used. Routing actions are considered to match if the regular expression matches at least one part of the address.
Table 12-4 shows the basic regular expression (BRE) implementation for the supported regex characters.
Table 12-4 BRE Implementation
Metacharacter
|
Description
|
.
|
Matches any single character .Within POSIX bracket expressions, the dot character matches a literal dot. For example, a.c matches "abc", etc., but [a.c] matches only "a", ".", or "c".
|
[ ]
|
A bracket expression. Matches a single character that is contained within the brackets. For example, [abc] matches "a", "b", or "c". [a-z] specifies a range which matches any lowercase letter from "a" to "z". The - character is treated as a literal character if it is the last or the first character within the brackets, or if it is escaped with a backslash: [abc-], [-abc], or [a\-bc].
|
[^ ]
|
Matches a single character that is not contained within the brackets. For example, [^abc] matches any character other than "a", "b", or "c". [^a-z] matches any single character that is not a lowercase letter from "a" to "z". As above, literal characters and ranges can be mixed.
|
^
|
Matches the starting position of the string.
|
$
|
Matches the ending position of the string.
|
\( \)
|
Defines a marked subexpression. The string matched within the parentheses can be recalled later (see the next entry, \n).
|
\n
|
Matches what the nth marked subexpression matched, where n is a digit from 1 to 9. This construct is theoretically irregular and was not adopted in the POSIX ERE syntax. Some tools allow referencing more than nine capturing groups.
|
*
|
Matches the preceding element zero or more times.
|
\{m,n\}
|
Matches the preceding element at least m and not more than n times. For example, a\{3,5\} matches only "aaa", "aaaa", and "aaaaa".
|
The rtg-src-address and rtg-dst-address tables contain entries matching the dialed number (after number analysis). At run-time, when the Request-URI is processed, the username is parsed to determine if the username is considered to be "textual" or "dialed-digits". It is initially assumed that the username is a dialed-digit string, and the username will considered to be textual only if non-dialed digit characters are encountered. Having determined this type, only policy entries matching this type are evaluated.
When configuring policy entries which match on rtg-src-address or rtg-dst-address table, it is important to configure the match-address correctly to ensure the policy entry is evaluated. In order to assist in configuration, the type of match address will be assessed and configured automatically if not specifically configured.
You can configure one of the following three choices explicitly:
match-address address [digits] (limited digit string regex)
match-address address [string] (string (textual) comparison on textual username only)
match-address address [regex] (regular expression on string (textual) usernames only)
Example:
Valid entries:
match-address (0)1234[56] digits
match-address username string
match-address [Uu]sername regex
Invalid entries:
match-address 1234 string (cannot perform a string match on dialed digits)
match-address 1234 regex (cannot perform a regex match on dialed-digits)
match-address [abc] regex (abc are valid dialed digits and #, * and d are also valid
dialed digits)
In this case the entry is evaluated at configuration time and error responses generated if there is a perceived mismatch in the type and match-address.
H.323 Call Routing Features
In addition to the features described in the "Routing" section that also apply to H.323 calls, Cisco Unified Border Element (SP Edition) supports various H.323-specific call routing features.
The H.323 call routing features are:
•H.323 Hunting
•Picking a Next Hop in Routing Policy
•Support for H.323 addressing
•DNS Name Resolution
•Number Validation and Editing
•Load Balancing
•Inter-VPN Calling
H.323 Hunting
Cisco Unified Border Element (SP Edition) supports hunting of H.323 calls. Cisco Unified Border Element (SP Edition) hunts for other routes or destination adjacencies in the event of a failure. Hunting re-routes the call in response to a specific user-configured event or error code.
H.323 hunting or re-routing operates in the following ways based on whether the adjacency is a gatekeeper or non-gatekeeper adjacency:
•For a gatekeeper adjacency, the SBC can cycle through a list of potential signaling next hops based on input from the gatekeeper. Alternate Endpoints and MultiARQ are two methods that allow the gatekeeper to provide the SBC with this list.
If H.323 has a list of alternate endpoints for a call, H.323 tries each of these in turn before reporting a routing failure to the RPS.
MultiARQ is described in the "MultiARQ Hunting" section.
•For a non-gatekeeper adjacency, or where all the next hops on a gatekeeper adjacency have been exhausted, the SBC can re-route the call to a different adjacency in the "hunt group" (specifically, the round-robin-table or least-cost routing table). For more information on routing tables, see the "Routing Tables and Adjacencies" section.
MultiARQ Hunting
Cisco Unified Border Element (SP Edition) supports a non-standard H.323 mechanism for hunting for other routes or destination adjacencies. This is based on issuing multiple Admission Requests (ARQs) to a Gatekeeper for a single call.
The SBC sends an ARQ (Admission Request) when an incoming call is received on a gatekeeper adjacency, or an outgoing call needs to be made on a gatekeeper adjacency. For an outgoing call, the gatekeeper returns the signaling address of the endpoint that the SBC should contact.
MultiARQ hunting occurs under the following circumstances:
•The H.323 endpoint sends an ARQ to a Gatekeeper as part of establishing an outbound call leg.
•The Gatekeeper contacts other network entities and identifies one or more potential endpoints.
•The Gatekeeper returns an admissionConfirm (ACF) containing a single destinationInfo and no alternateEndpoints.
•The H.323 endpoint attempts to contact the endpoint identified in the ACF. The endpoint either rejects the call or is unreachable.
The MultiARQ hunting continues until one of the following conditions is met.
•An endpoint is contacted and the call completes.
•A Gatekeeper ARQ retry is required, but the hard-coded limit on the number of permitted retry ARQs has been reached. This number is a customizable constant in h323cust.h, and is currently set to 32.
•The Gatekeeper returns an admissionReject, indicating that there are no further suitable endpoint identifiers.
•An endpoint returns a rejectReason which is not configured as a hunting trigger.
•An endpoint cannot be contacted, and connectFailed is not configured as a hunting trigger.
For information on configuring MultiARQ Hunting, see the "Configuring H.323 MultiARQ Hunting" section.
Picking a Next Hop in Routing Policy
When receiving an incoming H.323 call, Cisco Unified Border Element (SP Edition) carries out routing to determine the next hop for the call.
SBC policy allows calls to be routed to one of the following:
•signaling peer (such as a gateway)
•outgoing gatekeeper
When a gatekeeper is used, the gatekeeper is responsible for resolving the called party number to a next hop address.
In a SBC configuration, a routing next hop is identified by an adjacency name. The adjacency is configured with the address of the next hop gateway or gatekeeper.
Support for H.323 addressing
All H.323 calls through Cisco Unified Border Element (SP Edition) need to specify a called party number. A called party number may optionally be supplied in the Q.931 calledPartyNumber or the H.225 destinationAddress, with the former taking priority. If a called party number is not present in either of these fields, then the SBC rejects the call.
Finally, the connected number may also optionally be supplied in the Q.931 connectedNumber or the H.225 connectedAddress, with the former taking priority. The connected number indicates the party the call ends up connecting with because during call setup, the call might be redirected or the called number might be edited along the way.
When an H.323 endpoint sends out a Q.931/H.225 message, the called and calling numbers are always placed in the Q.931 fields, not the H.225 fields.
DNS Name Resolution
Domain name server (DNS) name resolution enables you to use the domain name instead of the IP address in an adjacency configuration. You can configure both gatekeeper and non-gatekeeper adjacencies with DNS names.
If you use a DNS name in an adjacency configuration, the name is resolved each time a call is routed out over that adjacency. This process allows DNS-based load-balancing.
Number Validation and Editing
Cisco Unified Border Element (SP Edition) allows validation, editing and categorization of the called and calling party number through a Number Validation configuration.
This can be used for adding or stripping number prefixes. This process is called Number Analysis (NA). Number Analysis (NA) determines whether a set of dialed digits represents a valid telephone number (based on number validation, number categorization, or digit manipulation). This is achieved by configuring one or more tables of valid dialed digit strings using a limited-form regular-expression syntax, then matching the actual dialed digits against the different strings in the tables.
NA is optionally configured in a call policy set. Three different types of NA policies are configured within NA tables—number validation, number categorization, and digit manipulation.
For more information, see the "Number Analysis Policies" section section and the "Number Analysis" section in the Implementing Cisco Unified Border Element (SP Edition) Policies chapter.
Load Balancing
Cisco Unified Border Element (SP Edition) can load balance between H.323 adjacencies using Round Robin or Least Cost Routing configurations.
Round Robin load balancing distributes calls evenly between adjacencies. Least Cost load balancing assigns a priority to each adjacency.
For example, routing might route two consecutive calls onto two different adjacencies.
•For gatekeeper adjacencies, the calls will be admitted on two different gatekeepers. It is up to the gatekeeper routing configuration to determine whether the signaling next hop for each call is the same.
•For non-gatekeeper adjacencies, the signaling next hop will be set to two different gateways (or terminals).
If a gatekeeper adjacency loses contact with the gatekeeper, it is temporarily taken out of service - meaning that the SBC will not attempt to route new calls through it. If there is an alternative route, call setup will continue on the alternative route. You can also manually deactivate an adjacency, which has the same effect.
Inter-VPN Calling
Cisco Unified Border Element (SP Edition) can peer with H.323 devices in different VPNs simultaneously.
You configure VPNs on a per-adjacency basis. Therefore, inter-VPN calling is simply a matter of your configuring a routing policy that routes calls between adjacencies in different VPNs.
Call Admission Control
This section describes the following:
•Call Admission Control Overview
•Compound Scopes
•Policy scopes
•Policy Set tables and Limit tables
•Limit Tables
•CAC Table Entry Configuration Commands
•Media Line Removal
•Media Bypass in Call Admission Control
•CAC Rate Limiting
•Subscriber Policy
Call Admission Control Overview
Call Admission Control (CAC) allows you to configure policy for accepting or rejecting calls. It allows you to apply detailed policies to certain call options to limit the number of concurrent calls and registrations. CAC can restrict the media bandwidth dedicated to active calls. It allows for load control on other network elements by rate limiting. Certain events can be completely blocked (using a blacklist) or freely allowed (using a whitelist), based on certain attributes.
CAC determines whether an event should be granted or refused based on configured limits for network resource utilization. There are two reasons for performing call admission control.
•To defend load-sensitive network elements, such as softswitches, against potentially harmful levels of load precipitated by singular events, such as DoS attacks, natural or man-made disasters, or mass-media phone-ins.
•To police the Service Level Agreements (SLAs) between organizations, to ensure that the levels of network utilization defined in the SLA are not exceeded.
Call admission control is the final stage of the call policy, so it is applied after number analysis and routing policy. CAC policy is applied to all event types, such as new calls, subscriber registrations, and call updates. If an event is not granted by the CAC policy, then Cisco Unified Border Element (SP Edition) rejects it with a suitable error code.
A CAC policy consists of the following.
•A limit or limits that must not be exceeded.
Limits, for example, can be set on the maximum number of concurrent calls, the maximum rate of calls, or the maximum bandwidth consumed by calls.
•A scope at which the limits are applied.
This can be global, per-account, per-adjacency, or any of the scopes defined in Policy scopes. Combinations of scopes can also be used, such as "per account, per number category." Scope is part of the policy itself. For example, in the policy "maximum 20Kb per call," the scope is "per call."
To define an admission control policy, you must define the limit and the scope at which it is applied. For example, you can define a policy such that not more than 10 concurrent calls (limit) could ever be made from a single account (scope).
Although the scope and limits define the policy, they do not determine when the policy is applied. For example, you cannot name a particular account, such as "account1," as the scope for your policy. Instead, the table-type and match value are used to determine when a policy is applied. Setting "account" as the table-type and "account1" as the match value matches call events from account1.
Compound Scopes
Compound scopes provide a more elaborate set of options for configuring policy. Certain policy scopes can be combined to create compound scopes. To combine scopes, configure each scope using a separate first-cac-scope or cac-scope command.
The following are examples of compound scopes:
•If you want to restrict the number of calls between any pair of adjacencies to 20, you could create a policy with MaxCalls = 20 and a scope of "src_adjacency, dst_adjacency." This policy would restrict the number of calls between any pair of adjacencies to 20. However, it would not limit the total number of calls out of any adjacency, nor the total number of calls into any adjacency.
•You can define an admission control policy at a compound scope of "source adjacency and category," and set the maximum concurrent calls at this scope to 10. This policy would restrict the number of concurrent calls of the same category that each adjacency could make to 10. The scope field value is src-adjacency, category.
Policy scopes
Table 12-5 defines the scopes at which call admission policies can be applied and whether the scope can be combined with other scopes.
Table 12-5 Policy Scope Definitions
List of Scope Options or Value of Scope Field
|
Scope
|
Description
|
Can Scope Be Combined?
|
adj-group
|
per adjacency group
|
The limits specified at this scope apply to all events sent to or received from the same adjacency group. For example, you can restrict the total number of concurrent calls that can be sent to or received from the adjacencies in a single adjacency group by configuring limits at this scope.
|
Yes, except for src-adj-group and dst-adj-group scopes
|
call
|
per call
|
The limits specified at this scope apply to any single call. For example, you can restrict the per-call bandwidth or the allowed call update rate by configuring limits at this scope. Note that some limits are invalid at this scope.
|
No
|
category
|
per category
|
The limits specified at this scope apply to all events that have been placed in the same category by the number analysis policy tables. For example, you can restrict the total number of concurrent calls in any single category by configuring limits at this scope.
|
Yes
|
dst-account
|
per destination account
|
The limits specified at this scope apply to all events sent to the same account. For example, you can restrict the total number of concurrent calls that can be sent to any single account by configuring limits at this scope.
|
Yes, except for account scope
|
dst-adj-group
|
per destination adjacency group
|
The limits specified at this scope apply to all events sent to the same adjacency group. For example, you can restrict the total number of concurrent calls that can be sent to the adjacencies in a single adjacency group by configuring limits at this scope.
|
Yes, except for adj-group scope
|
dst-adjacency
|
per destination adjacency
|
The limits specified at this scope apply to all events sent to the same adjacency. For example, you can restrict the total number of concurrent calls that can be sent to any single adjacency by configuring limits at this scope.
|
Yes, except for adjacency scope
|
dst-number
|
per dialed number
|
The limits specified at this scope apply to all events that that have the same destination number. For example, you can restrict the total number of concurrent calls to any single valid number by configuring limits at this scope.
|
Yes
|
global
|
global
|
The limits specified at this scope apply to SBC as a whole.
|
No
|
src-account
|
per source account
|
The limits specified at this scope apply to all events received from the same account. For example, you can restrict the total number of concurrent calls that can be initiated from any single account by configuring limits at this scope.
|
Yes, except for account scope
|
src-adj-group
|
per source adjacency group
|
The limits specified at this scope apply to all events received from the same adjacency group. For example, you can restrict the total number of concurrent calls that can be initiated from the adjacencies in a single adjacency group by configuring limits at this scope.
|
Yes, except for adj-group scope
|
src-adjacency
|
per source adjacency
|
The limits specified at this scope apply to all events received from the same adjacency. For example, you can restrict the total number of concurrent calls that can be initiated from any single adjacency by configuring limits at this scope.
|
Yes, except for adjacency scope
|
src-number
|
per dialing number
|
The limits specified at this scope apply to all events that that have the same source number. For example, you can restrict the total number of concurrent calls from every single source number by configuring limits at this scope.
|
Yes
|
sub-category
|
per subscriber category
|
Note This is not supported in Cisco IOS XE Release 2.4.
The limits specified at this scope apply to all events sent to or received from members of the same subscriber category. For example, you can restrict the total number of concurrent calls that can be sent to or received from the subscribers in a single subscriber category by configuring limits at this scope.
|
Yes, except for sub-category-pfx and subscriber scopes
|
sub-category-pfx
|
per subscriber category prefix
|
Note This is not supported in Cisco IOS XE Release 2.4.
The limits specified at this scope apply to all events sent to or received from members of the same subscriber category prefix. For example, you can restrict the total number of concurrent calls that can be sent to or received from the subscribers in a single subscriber category prefix by configuring limits at this scope.
|
Yes, except for sub-category-pfx and subscriber scopes
|
subscriber
|
per subscriber
|
Note This is not supported in Cisco IOS XE Release 2.4.
The limits specified at this scope apply to all events sent to or received from individual subscribers. A subscriber is any device in the network that has registered with a Registrar server via SBC, or with an S-CSCF in an IMS network.
This does not allow you to match on a specific subscriber.
|
Yes, except for sub-category-pfx and subscriber scopes
|
Note If you are supporting Aggregate Registrations in a non-IMS network, all of the phones behind a device (such as a PBX) are counted as the same subscriber if you are using a per-subscriber scope.
Non-subscriber Group
When a subscriber scope is enabled, the SBC includes an additional group of ALL "non-subscribers." The non-subscribers are counted within a special group of the sbscriber scope. The non-subscriber group is matched if the call is from a non-subscriber. Limits set in the subscriber scope apply to this non-subscriber group.
Note A "subscriber" is identified using the Address-of-Record that is registered with the registrar. A "subscriber category" is based on the source IP address of the SIP message. When some subscribers sit behind a NAT device and share the same IP address, they are in the same subscriber category. However, they differ among each other by their AOR.
Policy Set tables and Limit tables
Call admission control policies are configured using a combination of Policy Set and Limit tables.
A Policy Set table type is applied to all entries defined within the CAC table. Each entry within the table configures its own scope. Every entry in a Policy Set table automatically matches every event that reaches that table. Policy Set tables create multiple policies for each event.
A Limit table type selects the single best matching match value defined in a CAC entry. The scope for the limit table type is inherited from the limit table's parent table. The entries in a Limit table specify the values to match against and the limits to apply if a match is achieved.
The major difference between a Policy Set table and a Limit table is that the Policy Set table creates multiple policies for a given event, while a Limit table only defines one policy for a given event.
For information on table-types, match values, and when an event matches an entry for Limit Table, see Table 12-6. For information on scope name, scope definition, and whether a scope can be combined, see Table 12-5.
Limit Tables
Table 12-6 lists the types of Limit tables. For each table type, the corresponding Match value is listed, with the conditions under which a match is achieved. If a match is achieved, the corresponding policy is applied to the event.
Table 12-6 Table Types for Limit Table
Table Type
|
Match Value
|
Conditions Where an Event Matches an Entry
|
account
|
account name
|
Match value is the source and/or destination account name.
|
adj-group
|
adjacency group name
|
Match value is the source and/or destination adjacency group name.
|
adjacency
|
adjacency name
|
Match value is the source and/or destination adjacency name.
|
all
|
NA
|
All events match entry
|
call-priority
|
SBC priority
|
SBC priority is the event call-priority.
|
category
|
category name (assigned during number analysis)
|
Event has been assigned a category, and match value is the name of the category assigned.
|
dst-account
|
account name
|
Match value is the destination account name.
|
dst-adj-group
|
adjacency group name
|
Match value is the destination adjacency group name.
|
dst-adjacency
|
adjacency name
|
Match value is the destination adjacency name.
|
dst-prefix
|
number prefix
|
Match value is the first digits of the number being called.
|
event-type
|
Type of event to which CAC policy is applied (new-call, call-update or endpoint-reg)
|
Match value is the event type.
|
src-account
|
account name
|
Match value is the source account name.
|
src-adj-group
|
adjacency group name
|
Match value is the source adjacency group name.
|
src-adjacency
|
adjacency name
|
Match value is the source adjacency name.
|
src-prefix
|
number prefix
|
Match value is the first digits of the calling number
|
sub-category
|
ipv4 {ip-address} [vrf vrf]
|
Match value is the IPv4 address.
When the "sub-category" table type is defined for a CAC table, you must define the match-value within the entry. As an example, you would use the command: match-value ipv4 {ip-address} [vrf vrf]
|
sub-category-pfx pfx-len
|
ipv4 {ip-address} {prefix-len} [vrf vrf]
|
Match value is the IPv4 address.
When the "sub-category-pfx pfx-len" table type is defined for a CAC table, you must define the match-value and match-prefix-len within the entry. As an example, you would use the command: match-value ipv4 {ip-address} {prefix-len} [vrf vrf].
|
CAC Table Entry Configuration Commands
Each CAC table consists of a collection of table entries, defined within the CAC table submode. For Policy Set table types, the CAC scope is defined within each entry. If unspecified, the scope defaults to global for that entry.
For Limit table types, the CAC entry specifies a value to match against. The semantics of this match-value are determined by the type of Limit table.
For both table types, the limits defined within the entry are calculated using per scope values. Some limits are not applicable at all scopes. Policy Set table types define the scope within the entry, thus both the limit and the scope are per entry. If you want per entry limits for a Limit table type, then configure the Limit table type to match the scope.
See the "Configuring Call Admission Control Policy Sets and CAC Tables" section for detailed configuration step information.
Table 12-7 shows a list of various limits and options that can be configured on an entry in a CAC policy-set table. These configurable command options can be displayed with the following commands:
Router(config-sbc-sbe-cacpolicy-cactable-entry)# cac-table 4
Router(config-sbc-sbe-cacpolicy-cactable)# table-type policy-set
Router(config-sbc-sbe-cacpolicy-cactable)# entry 1
Router(config-sbc-sbe-cacpolicy-cactable-entry)# ?
Note The cac-scope command option is only displayed for Policy Set table types. The match-value command option is only displayed for Limit table types.
Table 12-7 CAC Table Entry Configurable Command Options
Configurable Command Option
|
Description
|
cac-scope
|
Scope at which CAC limits are applied within each entry in a Policy Set table.
|
callee
|
Callee settings
|
callee-codec-list
|
List of codecs which the callee leg of a call is allowed to use
|
callee-hold-setting
|
The callee hold setting supported
|
callee-inbound-policy
|
Set callee inbound sdp policy table
|
callee-outbound-policy
|
Set callee outbound sdp policy table
|
callee-privacy
|
The level of privacy processing
|
callee-sig-qos-profile
|
QoS profile to use for callee signalling
|
callee-video-qos-profile
|
QoS profile to use for callee video media
|
callee-voice-qos-profile
|
QoS profile to use for callee voice media
|
caller
|
Caller settings
|
caller-codec-list
|
List of codecs which the caller leg of a call is allowed to use
|
caller-hold-setting
|
The caller hold setting supported
|
caller-inbound-policy
|
Set caller inbound sdp policy table
|
caller-outbound-policy
|
Set caller outbound sdp policy table
|
caller-privacy
|
the level of privacy processing
|
caller-sig-qos-profile
|
QoS profile to use for caller signalling
|
caller-video-qos-profile
|
QoS profile to use for caller video media
|
caller-voice-qos-profile
|
QoS profile to use for caller voice media
|
codec-restrict-to-list
|
Restrict to using codecs from a configured codec list
|
early-media-deny
|
Do not allow early-media
|
early-media-timeout
|
Duration for which to allow early media
|
early-media-type
|
Directions in which to allow early media
|
match-value
|
Match-value of an enty in a CAC Limit table
|
max-bandwidth
|
Maximum bandwidth
|
max-call-rate
|
Maximum call rate
|
max-channels
|
Maximum number of channels
|
max-in-call-rate
|
Configure maximum rate of in-call messages. See description of in-call messages in the "CAC Rate Limiting" section.
|
max-num-calls
|
Maximum number of calls
|
max-out-call-rate
|
Configure maximum rate of out-of-call messages
|
max-regs
|
Maximum subscriber registrations
|
max-regs-rate
|
Maximum subscriber registrations rate
|
max-updates
|
Maximum updates to call media
|
media
|
Media Flag
|
media-bypass-forbid
|
Do not allow media bypass
|
transcode-deny
|
Sets transcoding to forbidden for the admission control entry
|
transport
|
Transport Protocol Parameters
|
Non-limiting CAC Options
CAC allows you to configure policy for accepting or rejecting calls based on limit options such as max-num-calls and max-bandwidth. The CAC scope is used when policing limit options. CAC also allows you to apply a property to a call (rather than a limitation) with non-limiting options, such as caller-inbound-policy. Scopes have no meaning for non-limiting options.
You can configure multiple CAC policies that all apply to a given event (using a Policy Set table type). A non-limiting option can be given contradictory values in each of these policies. CAC determines what its behavior towards that event is by examining the setting of the option in each applicable policy and applying a rule to produce a "derived value" for the field. If the option is not defined in any policy, then a default behavior is defined. When the SBC is deriving a value for a non-limiting field, it should disregard all policies in which that field has not been defined by the user. The SBC derives that value based on the assigned behavior for the specific non-limiting option. The behavior for the non-limiting options takes one of the following values:
•Last non-default value used. Options of this type take the last non-default value as the derived value. For example, caller-inbound-policy uses the last found non-zero length sdp policy name as the derived value.
•Most restrictive value used. Options of this type take as the derived value the Policy Value that most restricts the behavior of the SBC.
•First non-default value used. Options of this type use the first non-default value as the derived value. For example, caller-voice-qos-profile uses the first non-zero length voice QoS profile name as the derived value.
•All found values combined. Options of this type perform a bitwise-OR to obtain a cumulative value as the derived value.
Table 12-8 Non-limiting Options in CAC Entry
Non-Limiting Options in CAC Entry
|
Behavior for Derived Value
|
callee-bandwidth-field
|
Last non-default value used
|
callee-codec-list
|
Last non-default value used
|
callee-hold-setting
|
Last non-default value used
|
callee-inbound-policy
|
Last non-default value used.
|
callee media-description, callee secure media
|
All found values combined
|
callee media-type
|
Last non-default value used
|
callee-outbound-policy
|
Last non-default value used
|
callee-privacy
|
Most restrictive value used
|
callee-sig-qos-profile
|
First non-default value used
|
callee tel-event
|
Last non-default value used
|
callee-video-qos-profile
|
First non-default value used
|
callee-voice-qos-profile
|
First non-default value used
|
caller-bandwidth-field
|
Last non-default value used
|
caller-codec-list
|
Last non-default value used
|
caller-hold-setting
|
Last non-default value used
|
caller-inbound-policy
|
Last non-default value used
|
caller media-description, caller secure media
|
All found values combined
|
caller media-type
|
Last non-default value used
|
caller-outbound-policy
|
Last non-default value used
|
caller-privacy
|
Most restrictive value used
|
caller-sig-qos-profile
|
First non-default value used
|
caller tel-event
|
Last non-default value used
|
caller-video-qos-profile
|
First non-default value used
|
caller-voice-qos-profile
|
First non-default value used
|
codec-restrict-to-list
|
Last non-default value used
|
early-media-deny
|
Most restrictive value used
|
early-media-timeout
|
Most restrictive value used
|
early-media-type
|
Most restrictive value used
|
media address preserve, media bandwidth-field ignore, media tel-event interworking
|
All found values combined
|
media-bypass-forbid
|
Most restrictive value used
|
sdp-media-profile
|
Last non-default value used
|
transcode-deny
|
Most restrictive value used
|
transport srtp
|
Most restrictive value used
|
Media Line Removal
Media line removal feature provides the ability to strip or pad disabled media descriptions (m-lines with zero port) when sending an offer or answer to interoperate with various non-compliant devices.
Where the SDP being forwarded represents an answer, the media line which was removed from the forwarded offer is identified and a dummy media line is inserted into the same location. This is required for the compliant partner to match appropriate media line requests and responses.
Where the SDP being forwarded is a future offer, it uses offer modification to effectively shuffle-up media lines allowing the "padding" dummy media lines to be added to the end of the forwarded SDP.
SBC's transmit behavior is independently configured for the caller and callee sides of the call using the following options:
•strip new on offer—removes disabled media streams in forwarded offers which are new or unknown to the recipient of the offer.
•strip all on offer—removes all disabled media streams from forwarded offers, whether known to the recipient of the offer or not.
•strip on answer—removes all disabled media streams from forwarded answers.
•do not pad on offer—stops SBC from padding forwarded offers with disabled media streams. This means that a forwarded offer may not comply because it may contain less media lines than previous offers.
Note The "strip new on offer" and "strip all on offer" result in removal of m-lines from the forwarded offer. The missing lines are not "padded in" and there is no need to set the "do not pad on offer" option to achieve this. The "do not pad on offer" option only affects media lines that were missing from the received offer.
On selecting the appropriate option, the SDP to be forwarded is created with disabled media portions deleted, rather than the existing behavior of setting the port to zero.
Media Bypass in Call Admission Control
The media bypass feature allows the media packets to bypass the Cisco Unified Border Element (SP Edition), enabling the endpoints to communicate directly to each other. Media packets flow directly without going through the DBE component of the Cisco Unified Border Element (SP Edition) after the call signaling is performed. Signaling packets still flow through the Cisco Unified Border Element (SP Edition) as usual. The configuration is set per adjacency, and allows media bypass across different adjacencies.
CAC can control whether media-bypass is on or off. The media bypass is configured both per adjacency and in CAC. However, the default is still to perform media bypass if the adjacencies are on the same VPN. In addition, CAC can turn media bypass off based on destination or source prefix and account.
The requirements for this new feature are the following:
•The media-bypass-forbid option must be set in a CAC table.
•The CAC configuration takes priority over the configuration set on the adjacency.
•To perform media bypass between two adjacencies, the following precedence rules take effect:
–Both adjacencies must be on the same VPN.
–Both adjacencies must be allowed to perform media bypass by CAC.
–Both adjacencies must have their per-adjacency media bypass on.
CAC Rate Limiting
You can limit the number or the rate of new calls accepted and the number of media renegotiations within a call. However, limits are not placed on the following:
•Media renegotiations which do not actually change the characteristics of the call.
•Any other in-call messages.
In-call messages include any message within the context of a call, including provisional responses during call setup and call renegotiation messages, but not including call setup or tear-down messages.
•Internally-generated messages
Note You cannot specify limits at the granularity of a specific SIP or H.323 message.
You can also limit the rate and number of registrations passing through the Cisco Unified Border Element (SP Edition). However, limits are not placed on any other out-of-call messages. (An out-of-call message is any messages which is not following within the context of a call and which does not form part of registration processing. These are always classified as either a request or a response.)
You can rate limit all in-call and out-of-call messages.
This includes in-call messages at all scopes, as normal. For example:
•Configuration at the "per-call" scope allows you to limit the rate at which an endpoint sends messages within a call.
•Configuration at the "dst-adjacency" scope allows you to limit the total rate of in-call messages sent out of an adjacency within all of the calls using that adjacency. (This could ensure that the load out of an adjacency never exceeds that which the attached network entity can cope with.)
The following messages are not rate-limited:
•SIP INVITE requests: 200 responses and ACK messages
•SIP PRACK messages and response
•SIP BYE messages and responses
•Any SIP message with non-duplicate SDP on
•For H.323 calls: Q.931 SETUP, Q.931 CONNECT and Q.931 RELEASE messages.
You can place restrictions on the rate at which out-of-call messages are processed. Configuration is permitted at all scopes except per-call scope (because this scope does not exist for out-of-call messages).
The Cisco Unified Border Element (SP Edition) will gracefully reject in-call messages when the rate exceeds that specified in the CAC. When an in-call message is not processed, the Cisco Unified Border Element (SP Edition) does the following:
•For SIP messages, Cisco Unified Border Element (SP Edition) rejects the message gracefully wherever possible. The rejection is sent back to the sending endpoint, so the call is likely to survive.
•For H.323 messages, Cisco Unified Border Element (SP Edition) drops the message because they usually cannot be gracefully rejected. This is likely to be disruptive for the call.
The Cisco Unified Border Element (SP Edition) gracefully rejects out-of-call messages when the rate exceeds that specified in CAC.
All rate limits must be protocol stack independent; limits must police SIP and H323 messages.
In addition to configuring blacklists based on a number of CAC policy failures, you can now allow blacklists to be applied to endpoints that send in-call or out-of-call messages at a high rate.
Subscriber Policy
A user can subscribe multiple endpoints to the network to allow them to make calls. A subscriber is one of those endpoints. In a particular network, you might want to limit each subscriber to no more than a specific number of simultaneous calls. The Subscriber Policy feature allows you to limit each subscriber to a specific number of simultaneous calls.
This feature provides the ability to configure the CAC limits. For example, you can configure the maximum number of concurrent calls, the maximum number of registrations, or the maximum call rate at different scopes, such as subcriber, subscriber category, and subscriber category prefix.
You can configure CAC tables:
•To associate a subscriber with a subscriber category. Call events between that subscriber and the core network are also associated with that same subscriber category.
•To match on a subscriber category or on a subscriber category prefix (the first n bits of the subscriber category), and then set limits when matched. The subscriber category prefix specifies the length of prefix to match. If specified, then only the first n bits of each of the call's subscriber categories is checked for a match.
•To set limits per subscriber category.
•To set limits per subscriber.
Note that when a subscriber scope is enabled, the SBC tracks an additional group of ALL "non-subscribers." The non-subscriber group is matched if the call is from a non-subscriber. Limits set in the subscriber scope apply to this non-subscriber group.
How to Implement Policies
Cisco Unified Border Element (SP Edition) policies are configured and activated as described in the following sections:
•Configuring Number Analysis Tables
•Configuring Routing Tables
•Configuring Number Manipulation
•Configuring Hunting
•Configuring H.323 MultiARQ Hunting
•Configuring Call Admission Control Policy Sets and CAC Tables
•Activating a CAC Policy Set
Configuring Number Analysis Tables
This task configures a number analysis table. The types of number analysis configuration are described in the following sections:
•Configuring Number Validation
•Configuring Number Categorization
Configuring Number Validation
This task configures number validation for a number analysis table.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. first-number-analysis-table table-name
6. na-dst-prefix-table table-name
7. entry entry-id
8. match-prefix key
9. action [next-table goto-table-name | accept | reject]
10. category category-name
11. entry entry-id
12. edit [del-prefix pd] | [del-suffix sd] | [add-prefix pa] | [replace ds]
13. edit-cic [del-prefix pd] | [del-suffix sd] | [add-prefix pa] | [replace ds]
14. match-prefix key
15. action [next-table goto-table-name | accept | reject]
16. category category-name
17. entry entry-id
18. match-prefix key
19. action [next-table goto-table-name | accept | reject]
20. category category-name
21. exit
22. exit
23. end
24. show
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mySbc
Router(config-sbc)#
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
Router(config-sbc-sbe)#
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
Router(config-sbc-sbe-rtgpolicy)#
|
Enters the mode of routing policy set configuration within an SBE entitiy, creating a new policy set, if necessary.
|
Step 5
|
first-number-analysis-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
first-number-analysis-table hotel_table
|
Configures the name of the first policy table to process when performing the number analysis stage of policy.
|
Step 6
|
na-dst-prefix-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
na-dst-prefix-table hotel_table
|
Enters the mode for configuring a number analysis table whose entries match the prefix (the first several digits) of the dialed number within the context of an SBE policy set.
Commands for other number analysis tables:
•na-carrier-id-table—This table requires additional commands match-cic and edit-cic (see below)
•na-dst-number-table
•na-src-account-table
•na-src-adjacency-table
|
Step 7
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-natable)# entry
1
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 8
|
match-prefix key | match-cic cic
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
match-prefix XXX
|
Configures the match value of an entry in the number analysis table.
•The match-prefix key argument is a string used to match the prefix (the starting part) of the dialed number.
•The match-cic cic argument is used with the na-carrier-id-table command and configures the match carrier ID code in a table whose entries match a carrier ID.
|
Step 9
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
action accept
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 10
|
category category-name
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
category external
|
Configures the category of an entry in the number analysis table.
|
Step 11
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
entry 2
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 12
|
edit [del-prefix pd] | [del-suffix sd] |
[add-prefix pa] | [replace ds]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
edit del-prefix 1
|
Configures a dial-string manipulation action in a number analysis table. You are not allowed to do this if the table is part of the active policy set.
The no version of the command deletes the edit action of the given entry in the routing table.
The edit command can be set to the following values:
•del-prefix pd—Delete prefix pd, where pd is a positive integer specifying a number of digits to delete from the front of the dialed string.
•del-suffix sd—Delete suffix sd, where sd is a positive integer specifying a number of digits to delete from the end of the dialed string.
•add-prefix pa—Add prefix pa, where pa is a string of digits to add to the front of the dialed string.
•replace ds—Replace ds, where ds is a string of digits that replaces the dialed string.
In the example to the left, the edit command sets entry 2 to delete 1 digit from the beginning of the dialed string in the number analysis table.
|
Step 13
|
edit-cic [del-prefix pd] | [del-suffix sd] |
[add-prefix pa] | [replace ds]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
edit-cic del-prefix 1
|
Configures a carrier identification code (CIC) manipulation action in a number analysis table.
You are not allowed to do this if the table is part of the active policy set.
•del-prefix pd: A positive integer specifying a number of digits to delete from the front of the carrier ID string.
•del-suffix sd: A positive integer specifying a number of digits to delete from the end of the carrier ID string.
•add-prefix pa: A string of digits to add to the front of the carrier ID string.
•replace ds: A string of digits to replace the carrier ID string with.
The "edit-cic del-prefix 1" command sets entry 2 to delete the first digit of the carrier ID in the current number analysis table.
You can remove the CIC or carrier ID from outbound messages by specifying a replacement string of 0000 or by specifying a prefix deletion length of 4.
For example:
|
Step 14
|
match-prefix key
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
match-prefix 9XXX
|
Configures the match value of an entry in the number analysis table. The key argument is a string used to match the start of the dialed number.
The no version of the command destroys the match value.
|
Step 15
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
action accept
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 16
|
category category-name
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
category external
|
Configures the category of an entry in the number analysis table.
|
Step 17
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
entry 3
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 18
|
match-prefix key
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
match-prefix 8XXX
|
Configures the match value of an entry in the number analysis table. The key argument is a string used to match the start of the dialed number.
|
Step 19
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
action accept
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 20
|
category category-name
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
category bar
|
Configures the category of an entry in the number analysis table.
|
Step 21
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
exit
|
Exits from the entry mode to the natable mode.
|
Step 22
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-natable)# exit
|
Exits from the natable mode to the callpolicy mode.
|
Step 23
|
end
Example:
Router(config-sbc-sbe-rtgpolicy-natable)# end
|
Exits the callpolicy mode to Privileged EXEC mode.
|
Step 24
|
show
Example:
Router(config-sbc-sbe-rtgpolicy)# show
|
Displays the current configuration information.
|
Configuring Number Categorization
This task configures number categorization for a number analysis table.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. first-number-analysis-table table-name
6. na-src-account-table table-name
7. entry entry-id
8. match-account key
9. action [next-table goto-table-name | accept | reject]
10. entry entry-id
11. match-account key
12. action [next-table goto-table-name | accept | reject]
13. entry entry-id
14. match-account key
15. action [next-table goto-table-name | accept | reject]
16. na-dst-prefix-table table-name
17. entry entry-id
18. match-prefix key
19. category category-name
20. action [next-table goto-table-name | accept | reject]
21. entry entry-id
22. match-prefix key
23. category category-name
24. action [next-table goto-table-name | accept | reject]
25. end
26. show
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mySbc
Router(config-sbc)#
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
Router(config-sbc-sbe)#
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
Router(config-sbc-sbe-rtgpolicy)#
|
Enters the mode of routing policy set configuration within an SBE entitiy, creating a new policy set if necessary.
|
Step 5
|
first-number-analysis-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
first-number-analysis-table check_account
|
Configures the name of the first policy table to process when performing the number analysis stage of policy.
|
Step 6
|
na-src-account-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
na-src-account-table check_account
Router(config-sbc-sbe-rtgpolicy-
natable)#
|
Enters the mode for configuring a number analysis table within the context of an SBE policy set with the entries of the table matching the source account.
|
Step 7
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-
natable)# entry 1
Router(config-sbc-sbe-rtgpolicy-
natable-entry)#
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 8
|
match-account key
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# match-account hotel_foo
|
Configures the match value of an entry in the number analysis table. The key argument is a string used to match the source account.
|
Step 9
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# action next-table
hotel_dialing_plan
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 10
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# entry 2
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 11
|
match-account key
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# match-account hotel_bar
|
Configures the match value of an entry in the number analysis table. The key argument is a string used to match the source account.
|
Step 12
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# action next-table
hotel_dialing_plan
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 13
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# entry 3
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 14
|
match-account key
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# match-account internal
|
Configures the match value of an entry in the number analysis table. The key argument is a string used to match the source account.
|
Step 15
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# action accept
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 16
|
na-dst-prefix-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
na-dst-prefix-table hotel_dialing_plan
|
Enters the mode for configuring a number analysis table within the context of an SBE policy set with the entries of the table matching the start of the dialed number.
|
Step 17
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
entry 1
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 18
|
match-prefix key
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
match-prefix XXX
|
Configures the match value of an entry in the number analysis table. The key argument is a string used to match the start of the dialed number.
|
Step 19
|
category category-name
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
category internal_call
|
Specifies the category of an entry in a number analysis table.
|
Step 20
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
action accept
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 21
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
entry 2
|
Enters the mode for configuring an entry in a number analysis table, creating the entry, if necessary.
|
Step 22
|
match-prefix key
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
match-prefix 9XXX
|
Configures the match value of an entry in the number analysis table. The key argument is a string used to match the start of the dialed number.
|
Step 23
|
category category-name
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
category external_call
|
Specifies the category of an entry in a number analysis table.
|
Step 24
|
action [next-table goto-table-name | accept |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
action accept
|
Configures the action of an entry in a number analysis table. Possible actions are:
•Configure the name of the next number analysis table to process if the event matches this entry using the next-table keyword and the goto-table-name argument.
•Configure the call to be accepted if it matches the entry in the table using the accept keyword.
•Configure the call to be rejected if it matches the entry in the table using the reject keyword.
|
Step 25
|
end
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
end
|
Exits from the entry mode and returns to Privileged EXEC mode.
|
Step 26
|
show
Example:
Router(config-sbc-sbe-rtgpolicy)# show
|
Displays the current configuration information.
|
Configuring Routing Tables
See the following sections:
•Configuring a Destination Address Table
•Configuring the Destination, Source Domain, and Carrier ID Tables
•Configuring Number Manipulation
•Configuring the Least Cost Table
•Configuring Time-Based Tables
•Configuring Trunk-Group ID Tables
Configuring a Destination Address Table
This task configures a dst-address routing table.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. first-call-routing-table table-name
6. rtg-dst-address-table table-name
7. entry entry-id
8. match-address key [regex | string | digits]
9. prefix
10. dst-adjacency target-adjacency
11. action [next-table goto-table-name | complete | reject]
12. exit
13. entry entry-id
14. match-address key [regex | string | digits]
15. prefix
16. dst-adjacency target-adjacency
17. action [next-table goto-table-name | complete | reject]
18. exit
19. entry entry-id
20. match-address key [regex | string | digits]
21. prefix
22. dst-adjacency target-adjacency
23. action [next-table goto-table-name | complete | reject]
24. exit
25. entry entry-id
26. match-address key [regex | string | digits]
27. prefix
28. dst-adjacency target-adjacency
29. action [next-table goto-table-name | complete | reject]
30. exit
31. complete name
32. end
33. show
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
|
Enters the mode of routing policy set configuration within an SBE entity.
|
Step 5
|
first-call-routing-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
first-call-routing-table ROUTE-ON-DEST-NUM
|
Configures the name of the first policy table to process when performing the routing stage of policy for new-call events.
|
Step 6
|
rtg-dst-address-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-dst-address-table MyRtgTable
|
Enters the configuration mode of a routing table within the context of an SBE policy set with the entries of the table matching the dialed number (after number analysis).
|
Step 7
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable)# entry 1
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
|
Step 8
|
match-address key [regex | string | digits]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
match-address 334
|
Configures the match value of an entry in a routing table.
To create a routing table that routes on user name, use the existing rtg-dst-address-table or rtg-src-address-table and put a textual value in the match-address field.
The SBC skips number analysis and performs only routing when the SIP message contains a user name. The SBC decides that an address is a user name (as opposed to a phone number) if it contains any character other than: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, plus, hyphen, period, open-round-bracket, and close-round-bracket.
When the SBC has decided that an address is a user name, the "X" in the routing tables is treated not as a wildcard character, but as a literal "X". For example, the match value of "X" matches the username "X", but not "A".
|
Step 9
|
prefix
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
prefix
|
Configures the match-address of this entry to match the start of the destination address.
|
Step 10
|
dst-adjacency target-adjacency
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
dst-adjacency SIP-AS540-PSTN-GW2
|
Configures the destination adjacency of an entry in a routing table.
|
Step 11
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
action complete
|
Configures the action to take if this routing entry is chosen. Possible actions are:
•Set the name of the next routing table to process if the event matches this entry. This is done using the next-table keyword and the goto-table-name argument.
•Complete the action using the complete keyword.
•Reject the indicated action using the reject keyword.
|
Step 12
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
exit
|
Exits the entry mode to the rtgtable mode.
|
Step 13
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable)# entry 2
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
|
Step 14
|
match-address key [regex | string | digits]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
match-address 434
|
Configures the match value of an entry in a routing table.
To create a routing table that routes on user name, use the existing rtg-dst-address-table or rtg-src-address-table and put a textual value in the match-address field.
The SBC skips number analysis and performs only routing when the SIP message contains a user name. The SBC decides that an address is a user name (as opposed to a phone number) if it contains any character other than: 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, plus, hyphen, period, open-round-bracket, and close-round-bracket.
When the SBC has decided that an address is a user name, the "X" in the routing tables is treated not as a wildcard character, but as a literal "X". For example, the match value of "X" matches the username "X", but not "A".
|
Step 15
|
prefix
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
prefix
|
Configures the match-address of this entry to match the start of the destination address.
|
Step 16
|
dst-adjacency target-adjacency
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
dst-adjacency SIP-AS540-PSTN-GW1
|
Configures the destination adjacency of an entry in a routing table.
|
Step 17
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
action complete
|
Configures the action to take if this routing entry is chosen. Possible actions are:
•Set the name of the next routing table to process if the event matches this entry. This is done using the next-table keyword and the goto-table-name argument.
•Complete the action using the complete keyword.
•Reject the indicated action using the reject keyword.
|
Step 18
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
exit
|
Exits the entry mode to the rtgtable mode.
|
Step 19
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable)# entry 3
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
|
Step 20
|
match-address key [regex | string | digits]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
match-address 354
|
Configures the match value of an entry in a routing table.
To create a routing table that routes on user name, use the existing rtg-dst-address-table or rtg-src-address-table and put a textual value in the match-address field.
The SBC skips number analysis and performs only routing when the SIP message contains a user name. The SBC decides that an address is a user name (as opposed to a phone number) if it contains any character other than: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, plus, hyphen, period, open-round-bracket, and close-round-bracket.
When the SBC has decided that an address is a user name, the "X" in the routing tables is treated not as a wildcard character, but as a literal "X". For example, the match value of "X" matches the username "X", but not "A".
|
Step 21
|
prefix
Example:
Router(config-sbc-sbe-rtgpolicy-rtgpolicy-rtgtable
-entry)# prefix
|
Configures the match-address of this entry to match the start of the destination address.
|
Step 22
|
dst-adjacency target-adjacency
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
dst-adjacency H323-AS540-PSTN-GW2
|
Configures the destination adjacency of an entry in a routing table.
|
Step 23
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
action complete
|
Configures the action to take if this routing entry is chosen. Possible actions are:
•Set the name of the next routing table to process if the event matches this entry. This is done using the next-table keyword and the goto-table-name argument.
•Complete the action using the complete keyword.
•Reject the indicated action using the reject keyword.
|
Step 24
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
exit
|
Exits the entry mode to the rtgtable mode.
|
Step 25
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable)# entry 4
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
|
Step 26
|
match-address key [regex | string | digits]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
match-address 454
|
Configures the match value of an entry in a routing table.
To create a routing table that routes on user name, use the existing rtg-dst-address-table or rtg-src-address-table and put a textual value in the match-address field.
The SBC skips number analysis and performs only routing when the SIP message contains a user name. The SBC decides that an address is a user name (as opposed to a phone number) if it contains any character other than: 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, plus, hyphen, period, open-round-bracket, and close-round-bracket.
When the SBC has decided that an address is a user name, the "X" in the routing tables is treated not as a wildcard character, but as a literal "X". For example, the match value of "X" matches the username "X", but not "A".
|
Step 27
|
prefix
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
prefix
|
Configures the match-address of this entry to match the start of the destination address.
|
Step 28
|
dst-adjacency target-adjacency
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
dst-adjacency H323-AS540-PSTN-GW1
|
Configures the destination adjacency of an entry in a routing table.
|
Step 29
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
action complete
|
Configures the action to take if this routing entry is chosen. Possible actions are:
•Set the name of the next routing table to process if the event matches this entry. This is done using the next-table keyword and the goto-table-name argument.
•Complete the action using the complete keyword.
•Reject the indicated action using the reject keyword.
|
Step 30
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
exit
|
Exits the entry mode to the rtgtable mode.
|
Step 31
|
complete name
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable)#
complete
|
Completes the full routing policy set when you have committed the full set.
|
Step 32
|
end
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)#
end
|
Exits rtgtable mode and enters Privileged Exec mode.
|
Step 33
|
show
Example:
Router# show
|
Displays the current configuration information.
|
Configuring the Destination, Source Domain, and Carrier ID Tables
This task configures dst-domain and src-domain and carrier ID routing tables.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. rtg-src-domain-table table-name | rtg-dst-domain-table table-name | rtg-carrier-id-table table-name
6. entry entry-id
7. match-domain key [regex] | match-cic cic
8. edit action
9. edit-cic [del-prefix pd] | [del-suffix sd] | [add-prefix pa] | [replace ds]
10. action [next-table goto-table-name | complete | reject]
11. dst-adjacency target-adjacency
12. exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
|
Enters the mode of routing policy set configuration within an SBE entity.
|
Step 5
|
rtg-src-domain-table table-name |
rtg-dst-domain-table table-name |
rtg-carrier-id-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-src-domain-table MyRtgTable
|
Enters the configuration mode of a routing table (creating a new table if necessary) whose entries match the source or destination domains, or carrier ID respectively.
You are not allowed to enter the submode of routing table configuration in the context of the active policy set.
The no version of the command destroys the routing table. A routing table may not be destroyed if it is in the context of the active policy set.
|
Step 6
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable)# entry 1
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
entry-id is a number that uniquely identifies an entry in the newly created routing table.
|
Step 7
|
match-domain key [regex] | match-cic cic
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# match-domain ^cisco.com$
|
Creates or modifies the matching domain or carrier id code (CIC) of an entry in a routing table.
•key is regular expression, not just a string.
•cic is the carrier ID that matches the entry in a routing table.
|
Step 8
|
edit action
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# edit del-prefix 1
|
Configures a dial-string manipulation action in the routing table. You are not allowed to do this if the table is part of the active policy set.
The no version of the command deletes the edit action of the given entry in the routing table.
The edit command can be set to the following values:
•del-prefix pd—Delete prefix pd, where pd is a positive integer specifying a number of digits to delete from the front of the dialed digit string.
•del-suffix sd—Delete suffix sd, where sd is a positive integer specifying a number of digits to delete from the end of the dialed digit string.
•add-prefix pa—Add prefix pa, where pa is a string of digits to add to the front of the dialed string.
•replace ds—Replace ds, where ds is a string of digits that replaces the dialed string.
In the example to the left, the edit command sets entry 1 to delete 1 digit from the beginning of the dialed string in the routing table "MyRtgTable".
|
Step 9
|
edit-cic [del-prefix pd] | [del-suffix sd] |
[add-prefix pa] | [replace ds]
Example:
Router(config-sbc-sbe-rtgpolicy-
natable-entry)# edit-cic del-prefix 1
|
Configures a carrier identification code (CIC) manipulation action in any routing table.
You are not allowed to do this if the table is part of the active policy set.
•del-prefix pd: A positive integer specifying a number of digits to delete from the front of the carrier ID string.
•del-suffix sd: A positive integer specifying a number of digits to delete from the end of the carrier ID string.
•add-prefix pa: A string of digits to add to the front of the carrier ID string.
•replace ds: A string of digits to replace the carrier ID string with.
The following command sets entry 2 to delete the first digit of the carrier ID in the current routing table.
If you wish to remove the carrier ID entirely from outgoing messages, you should specify a replacement string of 0000 or a prefix deletion length of 4. For example,
|
Step 10
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# action complete
|
Configures the action to take if this routing entry is chosen. Possible actions are:
•Set the name of the next routing table to process if the event matches this entry. This is done using the next-table keyword and the goto-table-name argument.
•Complete the action using the complete keyword.
•Reject the indicated action using the reject keyword.
|
Step 11
|
dst-adjacency target-adjacency
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# dst-adjacency
SIP-AS540-PSTN-GW2
|
Configures the destination adjacency of an entry in a routing table.
|
Step 12
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# exit
|
Exits the current mode of the configuration.
|
Configuring the Category Table
This task configures dst-domain and src-domain and carrier ID routing tables.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. rtg-category-table table-name
6. entry entry-id
7. match-category word
8. action [next-table goto-table-name | complete | reject]
9. exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
|
Enters the mode of routing policy set configuration within an SBE entity.
|
Step 5
|
rtg-category-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-category-table MyRtgTable
|
Enters the submode of configuration of a routing table whose entries match on the category within the context of an SBE policy set.
|
Step 6
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable)# entry 1
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
entry-id is a number that uniquely identifies an entry in the newly created routing table.
|
Step 7
|
match-category word
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# match-category emergency$
|
Configures the match value of an entry in a routing table matching on the category.
|
Step 8
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# action reject
|
If any calls match the criterion, they are rejected.
|
Step 9
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# exit
|
Exits the current mode of the configuration.
|
Configuring the Least Cost Table
This task configures a Least Cost routing table.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. rtg-least-cost-table table-name
6. entry entry-id
7. cost cost
8. dst-adjacency
9. action complete
10. exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
|
Enters the mode of routing policy set configuration within an SBE entity.
|
Step 5
|
rtg-least-cost-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-least-cost-table MyRtgTable
|
Enters the submode of configuration of a routing table whose entries match on the least cost within the context of an SBE policy set.
|
Step 6
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable)# entry 1
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
entry-id is a number that uniquely identifies an entry in the newly created routing table.
|
Step 7
|
cost cost
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# cost 50$
|
Assigns a cost to the route.
|
Step 8
|
dst-adjacency target-adjacency
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# dst-adjacency
SIP-AS540-PSTN-GW2
|
Configures the destination adjacency of an entry in a routing table.
|
Step 9
|
action complete
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# action complete
|
Specifies that routing is complete when an entry matches this policy
|
Step 10
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# exit
|
Exits the current mode of the configuration.
|
Configuring Time-Based Tables
This task configures dst-domain and src-domain and carrier ID routing tables.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. rtg-time-table table-name
6. entry entry-id
7. match-time {[date yr year_low year_high mon month_low month_high day date_low date_high] [dow DoW_low DoW_high] [tod hr hour_low hour_high min minute_low minute_high]}
8. precedence precedence
9. dst-adjacency dst_adj
10. action [next-table goto-table-name | complete | reject ]
11. exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
|
Enters the mode of routing policy set configuration within an SBE entity.
|
Step 5
|
rtg-time-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-time-table MyRtgTable
|
Enters the submode of configuration of a routing table whose entries match on the time within the context of an SBE policy set.
|
Step 6
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable)# entry 1
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
entry-id is a number that uniquely identifies an entry in the newly created routing table.
|
Step 7
|
match-time {[date yr year_low year_high mon
month_low month_high day date_low date_high]
[dow DoW_low DoW_high] [tod hr hour_low
hour_high min minute_low minute_high]}
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# match-time date yr 2006 2020 mon 1 12 day 1
31$
|
Configures the match time of an entry. A string used to match the time and can include one or more of the following specifiers:
•date_low - date_high—the inclusive range of dates (1-31).
•date—date
•day—date
•DoW_low - DoW_high—the inclusive range of days (Sun-Mon).
•dow—day of the week
•hr—hour
•hour_low - hour_high—the inclusive range of hours (0-23).
•minute_low - minute_high—the inclusive range of minutes (0-59).
•min—minute
•mon—month
•month_low - month_high—the inclusive range of months (1-12).
•tod—time of day
•yr—year
•year_low - year_high—the inclusive range of years.
The high values are optional and if unspecified are set equal to the low values.
|
Step 8
|
precedence precedence
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# precedence 0
|
Configures the precedence of the routing entry.
|
Step 9
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# action complete
|
Configures the action to take if this routing entry is chosen. Possible actions are:
•Set the name of the next routing table to process if the event matches this entry. This is done using the next-table keyword and the goto-table-name argument.
•Complete the action using the complete keyword.
•Reject the indicated action using the reject keyword.
|
Step 10
|
dst-adjacency dst_adj
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# dst-adjacency
SIP-AS540-PSTN-GW2
|
Configures the destination adjacency of an entry in a routing table.
|
Step 11
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-
rtgtable-entry)# exit
|
Exits the current mode of the configuration.
|
Configuring Trunk-Group ID Tables
This task configures src-trunk-group-id and dst-trunk-group-id routing tables.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. adjacency sip adjacency-name
5. tgid-routing
6. exit
7. call-policy-set policy-set-id
8. rtg-src-trunk-group-id-table table-name | rtg-dst-trunk-group-id-table table-name
9. entry entry-id
10. action {next-table goto-table-name | complete | reject}
11. dst-adjacency dst_adj
12. match-type {none | any | context | tgid}
13. tgid-context tgid-context-name {tgid tgid-name}
14. exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
Router(config)#
|
Enters global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service. The service-name argument defines the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
Router(config-sbc-sbe)#
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
adjacency sip adjacency-name
Example:
Router(config-sbc-sbe)# adjacency sip adj1
Router(config-sbc-sbe-adj-sip)#
|
Enters adjacency SIP configuration submode.
|
Step 5
|
tgid-routing
Example:
Router(config-sbc-sbe-adj-sip)# tgid-routing
Router(config-sbc-sbe-adj-sip)#
|
Enables parsing the trunk group identifier for call routing.
|
Step 6
|
exit
Example:
Router(config-sbc-sbe-adj-sip)# exit
Router(config-sbc-sbe)#
|
Exit from the adjacency SIP configuration submode.
|
Step 7
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
Router(config-sbc-sbe-rtgpolicy)#
|
Enters the mode of routing policy set configuration within an SBE entity.
|
Step 8
|
rtg-src-trunk-group-id-table table-name
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-src-trunk-group-id-table MyRtgTable
Router(config-sbc-sbe-rtgpolicy-rtgtable)#
|
Enters the submode of configuration of a routing table whose entries match on the TGID or TGID context parameters of an SBE policy set.
|
Step 9
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable)#
entry 1
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
#
|
Enters the mode for configuring an entry in a routing table, creating the entry, if necessary.
entry-id is a number that uniquely identifies an entry in the newly created routing table.
|
Step 10
|
action [next-table goto-table-name | complete |
reject]
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# action complete
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
#
|
Configures the action to take if this routing entry is chosen. Possible actions are:
•Set the name of the next routing table to process if the event matches this entry. This is done using the next-table keyword and the goto-table-name argument.
•Complete the action using the complete keyword.
•Reject the indicated action using the reject keyword.
|
Step 11
|
dst-adjacency dst_adj
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# dst-adjacency SIP-AS540-PSTN-GW2
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
#
|
Configures the destination adjacency of an entry in a routing table.
|
Step 12
|
match-type {none | any | context | tgid}
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# match-type tgid
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
#
|
Matches the entries of the routing table with the source TGID or TGID context parameter. Possible match types are:
•none: Matches an entry if no TGID information is present.
•any: Matches an entry if any TGID information is present.
•context: Matches an entry on the TGID context.
•tgid: Matches an entry on both the TGID and TGID context.
|
Step 13
|
tgid-context tgid-context-name {tgid tgid-name}
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# tgid-context example-domain tgid trunkgroup1
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
#
|
Defines trunk-group ID context and trunk-group ID to match the entries of the routing table.
|
Step 14
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# exit
Router(config-sbc-sbe-rtgpolicy-rtgtable)#
|
Exits the current mode of the configuration.
|
Configuring Number Manipulation
This task enables you to specify various number manipulations that can be performed on a dialed number after a destination adjacency has been selected.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. call-policy-set policy-set-id
5. rtg-src-address-table table-id
6. rtg-src-adjacency-table table-id
7. rtg-src-account-table table-id
8. rtg-round-robin-table table-id
9. rtg-carrier-id-table table-id
10. rtg-dst-address-table table-id
11. entry entry-id
12. edit action
13. edit-cic [del-prefix pd] | [del-suffix sd] | [add-prefix pa] | [replace ds]
14. edit-src [del-prefix pd] | [del-suffix sd] | [add-prefix pa] | [replace ds]
15. exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# call-policy-set 1
|
Enters the mode of the routing policy set configuration in the SBE mode, creating a new policy set if necessary
|
Step 5
|
rtg-src-address-table table-id
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-src-address-table MySrcAddressTable
|
Enters the configuration mode of a routing table (creating one if necessary) whose entries match the dialer's number or SIP user name within the context of an SBE policy set.
You are not allowed to enter the submode of routing table configuration in the context of the active policy set.
The no version of the command destroys the routing table. A routing table may not be destroyed if it is in the context of the active policy set.
|
Step 6
|
rtg-src-adjacency-table table-id
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-src-adjacency-table MySrcAdjTable
|
Enters the configuration mode of a routing table (creating one if necessary) within the context of an SBE policy set whose entries match the source adjacency.
|
Step 7
|
rtg-src-account-table table-id
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-src-account-table MySrcAccTable
|
Enters the configuration mode of a routing table (creating one if necessary) whose entries match the source account within the context of an SBE policy set.
|
Step 8
|
rtg-round-robin-table table-id
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-round-robin-table MyRobinTable
|
Enters the configuration mode of a policy table, whose events do not have any match-value parameters, nor next-table actions. Its actions are restricted to configuring number manipulation, as well as setting the destination adjacency. A group of adjacencies are chosen for an event if an entry in a routing table matches that event and points to a round-robin adjacency table in the next-table action.
|
Step 9
|
rtg-carrier-id-table table-id
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-carrier-id-table MyCarrierIdTable
|
Enters the configuration mode of a routing table (creating one if necessary) within the context of an SBE policy set whose entries match the carrier ID.
You are not allowed to enter the mode of the routing table configuration in the context of the active policy set.
The no version of the command destroys the routing table. A routing table may not be destroyed if it is in the context of the active policy set.
|
Step 10
|
rtg-dst-address-table table-id
Example:
Router(config-sbc-sbe-rtgpolicy)#
rtg-dst-address-table MyRtgTable
|
Enters the configuration mode of a routing table (creating one if necessary) within the context of an SBE policy set whose entries match the dialed number (after number analysis) or SIP user name.
You are not allowed to enter the submode of routing table configuration in the context of the active policy set.
The no version of the command destroys the routing table. A routing table may not be destroyed if it is in the context of the active policy set.
|
Step 11
|
entry entry-id
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable)#
entry 1
|
Enters the mode for configuring an entry in a routing table, creating the entry if necessary.
|
Step 12
|
edit action
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# edit del-prefix 1
|
Configures a dial-string manipulation action in the routing table. You are not allowed to do this if the table is part of the active policy set.
The no version of the command deletes the edit action of the given entry in the routing table.
The edit command can be set to the following values:
•del-prefix pd—Delete prefix pd, where pd is a positive integer specifying a number of digits to delete from the front of the dialed digit string.
•del-suffix sd—Delete suffix sd, where sd is a positive integer specifying a number of digits to delete from the end of the dialed digit string.
•add-prefix pa—Add prefix pa, where pa is a string of digits to add to the front of the dialed string.
•replace ds—Replace ds, where ds is a string of digits that replaces the dialed string.
In the example to the left, the edit command sets entry 1 to delete 1 digit from the beginning of the dialed string in the routing table "MyRtgTable".
|
Step 13
|
edit-cic [del-prefix pd] | [del-suffix sd] |
[add-prefix pa] | [replace ds]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
edit-cic del-prefix 1
|
Configures a CIC manipulation action in any routing table.
You are not allowed to do this if the table is part of the active policy set.
•del-prefix pd: A positive integer specifying a number of digits to delete from the front of the carrier ID string.
•del-suffix sd: A positive integer specifying a number of digits to delete from the end of the carrier ID string.
•add-prefix pa: A string of digits to add to the front of the carrier ID string.
•replace ds: A string of digits to replace the carrier ID string with.
The following command sets entry 2 to delete the first digit of the carrier ID in the current routing table.
If you wish to remove the carrier ID entirely from outgoing messages, you should specify a replacement string of 0000 or a prefix deletion length of 4. For example,
|
Step 14
|
edit-src [del-prefix pd] | [del-suffix sd] |
[add-prefix pa] | [replace ds]
Example:
Router(config-sbc-sbe-rtgpolicy-natable-entry)#
edit-src del-prefix 1
|
Configures a source number manipulation action in the routing table.
You are not allowed to do this if the table is part of the active policy set.
The no version of the command destroys the match value.
•del-prefix pd: A positive integer specifying a number of digits to delete from the front of the carrier ID string.
•del-suffix sd: A positive integer specifying a number of digits to delete from the end of the carrier ID string.
•add-prefix pa: A string of digits to add to the front of the carrier ID string.
•replace ds: A string of digits to replace the carrier ID string with.
|
Step 15
|
exit
Example:
Router(config-sbc-sbe-rtgpolicy-rtgtable-entry)
# exit
|
Exits the entry mode of the configuration.
|
Configuring Hunting
This task enables Cisco Unified Border Element (SP Edition) to hunt for other routes or destination adjacencies in case of a failure.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. adjacency sip adjacency-name or adjacency h323 adjacency-name
5. hunting-trigger error-codes or hunting-trigger error-codes
6. exit
7. h323
8. hunting-mode [altEndps | multiARQ]
9. end
10. show sbc service-name sbe h323 | sip hunting-trigger
11. show sbc service-name sbe h323 | sip hunting-mode
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
adjacency sip adjacency-name
or
adjacency h323 adjacency-name
Example:
Router(config-sbc-sbe)# adjacency sip test
Router(config-sbc-sbe)# adjacency h323 test
|
Configures a destination SIP or H.323 adjacency for the SBC service, and enters into adjacency sip or adjacency h323 configuration mode.
adjacency sip—A destination SIP adjacency where the configured failure return codes cause hunting to occur. This command overrides any globally configured retry error codes.
adjacency h323—A destination H.323 adjacency where the configured failure return codes cause hunting to occur. This command overrides any globally configured retry error codes.
|
Step 5
|
hunting-trigger error-codes
or
hunting-trigger error-codes
Example:
Router(config-sbc-sbe-adj-sip)# hunting-trigger
415 480
(This command configures the hunting trigger for a SIP adjacency in Adjacency SIP configuration mode.)
or
Router(config-sbc-sbe-adj-h323)#
hunting-trigger noBandwidth
Router(config-sbc-sbe-adj-h323)#
hunting-trigger unreachableDestination
(These commands configure the hunting trigger for an H.323 adjacency in Adjacency H.323 configuration mode.)
Note If both adjacency level and SBE level hunting triggers are configured, the adjacency level takes priority.
|
Configures which failure return codes cause hunting to occur, in one of the following four modes:
•sip (global SIP scope)—use the sip hunting-trigger command.
Note Exit (config-sbc-sbe-adj-sip) or (config-sbc-sbe-adj-h323) mode first and enter into (config-sbc-sbe) mode to configure in the global SIP scope level.
•h323 (global H.323 scope)—use the hunting-trigger command
•adjacency sip (destination SIP adjacency)—use the hunting-trigger command
•adjacency h323 (destination H.323 adjacency)—use the hunting-trigger command
error-codes can have the following values:
In the sip and adjacency sip modes, error-codes represent a space-separated list of SIP numeric error codes. The examples to the left configures SIP to retry routing if it receives a "415" (media unsupported) or "480" (temporarily unavailable) error. Both error codes are set as hunting triggers. See Table 12-3 for a list of SIP error codes.
•In the h323 and adjacency h323 modes, error-codes are entered in separate commands. The following is a list of H.323 textual error codes:
–noBandwidth
–unreachableDestination
–destinationRejection
–noPermission
–gatewayResources
–badFormatAddress
–securityDenied
–the internally-defined value "connectFailed"
If you type no sip hunting-trigger or no hunting-trigger, then all error codes are cleared out. If you type no sip hunting-trigger x y, then just the codes x and y are removed from the configured list.
Note In the case of the adjacency h323 mode, enter the noRetry value to specify that routing should never be retried for this adjacency no matter what failure return code is received.
|
Step 6
|
exit
Example:
Router(config-sbc-sbe-adj-h323)# exit
|
Exits the Adjacency H.323 configuration mode and enters into SBE configuration mode.
|
Step 7
|
h323
Example:
Router(config-sbc-sbe)# h323
|
The h323 command enters into the H.323 configuration mode.
|
Step 8
|
hunting-mode [altEndps|multiARQ]
Example:
Router(config-sbc-sbe-h323)# hunting-mode
multiARQ
|
Configures the form of H.323 hunting to perform if H.323 hunting is triggered.
•altEndps—alternateEndpoints
•multiARQ—uses a nonstandard H.323 mechanism based on issuing multiple ARQs to a Gatekeeper for a single call.
The no version of this command restores the hunting mode to the default of alternateEndpoints. It does not disable hunting completely. If the hunting mode is not defined, the default is alternateEndpoints.
|
Step 9
|
end
Example:
Router(config-sbc-sbe-h323)# end
|
Exits the current mode of the configuration and enters into Privileged EXEC mode.
|
Step 10
|
show sbc service-name sbe h323|sip
hunting-trigger
Example:
Router# show sbc mysbc sbe h323 hunting-trigger
|
Shows the H.323 or SIP hunting triggers.
|
Step 11
|
show sbc service-name sbe h323|sip hunting-mode
Example:
Router# show sbc mysbc sbe h323 hunting-mode
|
Shows the H.323 hunting mode.
|
Activating a Routing Policy Set
This task activates a number analysis and routing policy set.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. active-call-policy-set policy-set-id
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
active-call-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# active-call-policy-set
1
|
Sets the active routing policy set within an SBE entity.
|
Configuring H.323 MultiARQ Hunting
This task configures Cisco Unified Border Element (SP Edition) to hunt for other H.323 routes or destination adjacencies in case of a failure.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. adjacency h323 adjacency-name
5. hunting-trigger error-codes
6. hunting-mode mode
7. exit
8. show sbc service-name sbe h323 hunting-mode
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
adjacency h323 adjacency-name
Example:
Router(config-sbc-sbe)# adjacency h323 test
|
Configures a destination H.323 adjacency for the SBC service, and enters into adjacency h323 configuration mode.
A destination H.323 adjacency is where the configured failure return codes cause hunting to occur. This command overrides any globally configured retry error codes.
|
Step 5
|
hunting-trigger error-codes
Example:
Router(config-sbc-sbe-h323)# hunting-trigger
noBandwidth
Router(config-sbc-sbe-h323)# hunting-trigger
securityDenied
|
Configures which failure return codes cause hunting to occur, in one of the following configuration modes:
•h323 (global H.323 scope)
•adjacency h323 (destination H.323 adjacency)
The example to the left configures H.323 to retry routing if it receives a "noBandwidth" or "securityDenied" error codes.
In the h323 and adjacency h323 configuration modes, error-codes are entered in separate commands. The following is a list of H.323 textual error codes:
–noBandwidth
–unreachableDestination
–destinationRejection
–noPermission
–gatewayResources
–badFormatAddress
–securityDenied
–the internally-defined value "connectFailed"
If you type no hunting-trigger, all error codes are cleared out.
Note In the case of the adjacency h323 mode, enter the noRetry value to specify that routing should never be retried for this adjacency no matter what failure return code is received.
|
Step 6
|
hunting-mode [altEndps|multiARQ]
Example:
Router(config-sbc-sbe-h323)# hunting-mode
multiARQ
|
Configures the form of hunting to perform if hunting is triggered.
•altEndps—alternateEndpoints
•multiARQ—uses a nonstandard H.323 mechanism based on issuing multiple ARQs to a Gatekeeper for a single call.
The no version of this command restores the hunting mode to the default of alternateEndpoints. It does not disable hunting completely. If the hunting mode is not defined, the default is alternateEndpoints.
|
Step 7
|
exit
Example:
Router(config-sbc-sbe-h323)# exit
|
Exits the current mode of the configuration and enters into Privileged EXEC mode.
|
Step 8
|
show sbc service-name sbe h323 hunting-mode
Example:
Router# show sbc mysbc sbe h323 hunting-mode
|
Shows the H.323 hunting mode.
|
Configuring Call Admission Control Policy Sets and CAC Tables
This optional task configures Call Admission Control policy sets and CAC tables.
SUMMARY STEPS
1. configure terminal
2. sbc service-name
3. sbe
4. cac-policy-set policy-set-id
5. first-cac-scope scope-name
6. first-cac-table table-name
7. cac-table table-name
8. table-type {policy-set | limit {list of limit tables}}
9. entry entry-id
10. cac-scope {list of scope options}
11. media-bypass-forbid
12. match-value key
13. max-num-calls mnc
14. max-call-rate mcr
15. max-in-call-rate rate
16. max-out-call-rate rate
17. max-bandwidth mbw bwsize
18. callee-privacy callee-priv-setting
19. action [next-table goto-table-name | cac-complete]
20. exit
21. entry entry-id
22. match-value key
23. max-num-calls mnc
24. max-call-rate mcr
25. max-bandwidth mbw bwsize
26. transcode-deny
27. max-regs mr
28. action [next-table goto-table-name | cac-complete]
29. exit
30. exit
31. complete
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure terminal
Example:
Router# configure terminal
|
Enables global configuration mode.
|
Step 2
|
sbc service-name
Example:
Router(config)# sbc mysbc
|
Enters the mode of an SBC service.
•Use the service-name argument to define the name of the service.
|
Step 3
|
sbe
Example:
Router(config-sbc)# sbe
|
Enters the mode of an SBE entity within an SBC service.
|
Step 4
|
cac-policy-set policy-set-id
Example:
Router(config-sbc-sbe)# cac-policy-set 1
|
Enters the mode of CAC policy set configuration within an SBE entity, creating a new policy set if necessary.
|
Step 5
|
first-cac-scope scope-name
Example:
Router(config-sbc-sbe-cacpolicy)#
first-cac-scope global
|
Configures the scope at which to begin defining limits when performing the admission control stage of policy.
Note The first-cac-scope definition is only relevant if the table type configured by the first-cac-table command is a Limit table. In that case, the scope of the first-cac-table is determined by first-cac-scope. If the first-cac-table is a Policy Set table, the first-cac-scope is ignored and defaults to global.
The scope-name argument configures the scope at which limits should be initially defined. Possible values are:
•adj-group
•call
•category
•dst-account
•dst-adj-group
•dst-adjacency
•dst-number
•global
•src-account
•src-adj-group
•src-adjacency
•src-number
Features can be enabled or disabled per adjacency group through CAC configuration the same way this is done per individual adjacencies.
|
Step 6
|
first-cac-table table-name
Example:
Router(config-sbc-sbe-cacpolicy)#
first-cac-table StandardListByAccount
|
Configures the name of the first policy table to process when performing the admission control stage of policy.
|
Step 7
|
cac-table table-name
Example:
Router(config-sbc-sbe-cacpolicy)# cac-table
StandardListByAccount
|
Enters the mode for configuration of an admission control table (creating one if necessary) within the context of an SBE policy set.
|
Step 8
|
table-type {policy-set | limit {list of limit
tables}}
Example:
Router(config-sbc-sbe-cacpolicy-cactable)#
table-type policy-set
|
Configures the table type of a CAC table within the context of an SBE policy set.
The list of limit tables argument controls the syntax of the match-value fields of the entries in the table. Possible available Limit tables are:
•account—Compare the name of the account.
•adj-group—Compare the name of the adjacency group.
•adjacency—Compare the name of the adjacency.
•all—No comparison type. All events match this type.
•call-priority—Compare with call priority.
•category—Compare the number analysis assigned category.
•dst-account—Compare the name of the destination account.
•dst-adj-group—Compare the name of the destination adjacency group.
•dst-adjacency—Compare the name of the destination adjacency.
•dst-prefix—Compare the beginning of the dialed digit string.
•event-type—Compare with CAC policy event types.
•src-account—Compare the name of the source account.
•src-adj-group—Compare the name of the source adjacency group.
•src-adjacency—Compare the name of the source adjacency.
•src-prefix—Compare the beginning of the calling number string.
Note For Limit tables, the event or message or call matches only a single entry.
Features can be enabled or disabled per adjacency group through CAC configuration the same way this is done per individual adjacencies. The adj-group table type matches on either source or destination adjacency group.
When the policy-set keyword is specified, use the cac-scope command to configure the scope within each entry at which limits are applied in a CAC Policy Set table.
Note For Policy Set tables, the event or call or message is applied to all entries in this table.
|
Step 9
|
entry entry-id
Example:
Router(config-sbc-sbe-cacpolicy-
cactable)# entry 1
|
Enters the mode to create or modify an entry in an admission control table.
|
Step 10
|
cac-scope {list of scope options}
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# cac-scope category
|
Configures the scope within each entry at which limits are applied in a Policy Set table.
list of scope options specifies one of the following strings used to match events:
adj-group—Events that are from members of the same adjacency group.
call—Scope limits are per single call.
category—Events that have same category.
dst-account—Events that are sent to the same account.
dst-adj-group—Events that are sent to the same adjacency group.
dst-adjacency—Events that are sent to the same adjacency.
dst-number—Events that have same destination.
global—Scope limits are global
src-account—Events that are from the same account.
src-adj-group—Events that are from the same adjacency group.
src-adjacency—Events that are from the same adjacency.
src-number—Events that have the same source number.
sub-category—The limits specified at this scope apply to all events sent to or received from members of the same subscriber category.
sub-category-pfx—The limits specified at this scope apply to all events sent to or received from members of the same subscriber category prefix.
subscriber—The limits specified at this scope apply to all events sent to or received from individual subscribers (a device that is registered with a Registrar server)
|
Step 11
|
media-bypass-forbid
Example:
Router(config-sbc-sbe-cacpolicy-
cactable-entry)# media-bypass-forbid
|
Configures whether media-bypass is forbidden for this entry in an admission control table. You are not allowed to do this if the table is part of the active policy set.
Not setting this command or issuing the no version of the command allows media bypass for this entry in the admission control table.
|
Step 12
|
match-value key
Example:
Router(config-sbc-sbe-cacpolicy-
cactable-entry)# match-value SIP-CUSTOMER-1
|
Configures the match-value of an entry in a CAC Limit table. It is only relevant for Limit table types.
The key argument is a string or a keyword based on the table type. The format of the key is determined by the Limit table type (for example, Limit event-type tables or Limit call-priority tables).
For Limit event-type tables (table-type limit event-type), the match value string options are the following:
call-update—Compare the beginning of the calling number string.
endpoint-reg—Compare the name of the destination adjacency.
new-call—Compare the beginning of the dialed digit string.
For Limit call-priority tables (table-type limit call-priority), the match value string options are the following:
critical—Match calls with resource priority 'critical'.
flash—Match calls with resource priority 'flash'.
flash-override—Match calls with resource priority 'flash-override'.
immediate—Match calls with resource priority 'immediate'.
priority—Match calls with resource priority 'priority'.
routine—Match calls with resource priority 'routine'.
For all other Limit tables, enter a name or digit string
WORD—Name or digit string to match. (Max Size 255).
|
Step 13
|
max-num-calls mnc
Example:
Router(config-sbc-sbe-cacpolicy-
cactable-entry)# max-num-calls 100
|
Configures the maximum number of calls of an entry in an admission control table.
|
Step 14
|
max-call-rate mcr
Example:
Router(config-sbc-sbe-cacpolicy-
cactable-entry)# max-call-rate 20
|
Configures the maximum number of calls per minute for an entry in an admission control table.
|
Step 15
|
max-in-call-rate rate
Example:
Router(config-sbc-sbe-cacpolicy-
cactable-entry)# max-in-call-rate 20
|
Configures the maximum in call rate for an entry in an admission control table.
|
Step 16
|
max-out-call-rate rate
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# max-out-call-rate 20
|
Configures the maximum out call rate for an entry in an admission control table.
|
Step 17
|
max-bandwidth mbw bwsize
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# max-bandwidth 1000000 bps
|
Configures the maximum bidirectional bandwidth for an entry in an admission control table. For example, if a max-bandwidth value is configured, the SBC allows half of this value in each direction.
The mbw argument is a positive integer specifying the total maximum rate at which call media should be admitted in both directions (in bytes per second).
The bwsize argument specifies the transfer size to which mbw refers. Possible values are:
•bps
•Kbps
•Mbps
•Gbps
|
Step 18
|
callee-privacy [callee-priv-setting]
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# callee-privacy never
|
Configures the level of privacy processing to perform on messages sent from callee to caller.
The callee_priv_setting argument indicates the specific callee privacy setting. Possible values are:
•never—Indicates to never hide identity.
•account-boundary—Indicates to hide identity only if caller is different account from callee.
•always—Indicates to always hide identity.
|
Step 19
|
action [next-table goto-table-name |
cac-complete]
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# action cac-complete
|
Configures the action to perform after this entry in an admission control table. Possible actions are:
•Identify the next CAC table to process using the next-table keyword and the goto-table-name argument.
•Stop processing for this scope using the cac-complete keyword.
|
Step 20
|
exit
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# exit
|
Exits from entry to cactable mode.
|
Step 21
|
entry entry-id
Example:
Router(config-sbc-sbe-cacpolicy-cactable)#
entry 2
|
Enters the mode to create or modify an entry in an admission control table.
|
Step 22
|
match-value key
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# match-value SIP-CUSTOMER-2
|
Configures the match-value of an entry in a CAC Limit table.
The key argument is a string used to match events. The format of the key is determined by the Limit table type (for example, Limit event-type tables or Limit call-priority tables). See the match-value command page for more details.
|
Step 23
|
max-num-calls mnc
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# max-num-calls 110
|
Configures the maximum number of calls of an entry in an admission control table.
|
Step 24
|
max-call-rate mcr
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# max-call-rate 30
|
Configures the maximum call rate for an entry in an admission control table.
|
Step 25
|
max-bandwidth mbw bwsize
Example:
Router(config-sbc-sbe-cacpolicy-cactable-entry)
# max-bandwidth 2000000 bps
|
Configures the maximum bidirectional bandwidth for an entry in an admission control table. For example, if a max-bandwidth value is configured, the SBC allows half |
