Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model

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

In the context of SIP and H.323 calls, three distinct stages of a policy are applied in a sequence to the policy events. The stages are:

• Inbound number analysis
• Routing
• Outbound number analysis
• Admission control

Some of these policy stages are skipped for particular types of events. Figure 7-2 shows the sequence of the policy stages for each event type.

Figure 7-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 7-2 .

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 or source number represents a valid telephone number. This is achieved by configuring one or more tables of valid source number and dialed digit strings using a limited-form regular-expression syntax, then matching the actual source number or 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 source numbers or 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 source number and 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 updat e 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.

A new policy set can either 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.

From Cisco IOS XE Release 3.2S, the administrative domain allows a user to create separate groups of start indexes for number analysis, route analysis, and a CAC policy that can point to different policy sets. The administrative domain is then attached to the adjacencies for both incoming and outgoing analysis stages.

You can designate an inactive call policy set as the active call policy set at any time. However, you cannot directly modify an active call policy set. To modify an active call policy set, perform the copy-and-swap procedure.

You can designate an inactive CAC policy set as the active CAC policy set at any time. You can also modify an active CAC policy set by adding a new table in the CAC policy set. Note that you can create an entry in an existing table of an active CAC policy set only if the table type is limit all or policy-set . To perform a modification of this type, you must perform the copy-and-swap procedure.

You can define multiple policy sets that are active and select policy sets that can be used at each call analysis stage based on the adjacency setting. To modify a policy that may be referenced by multiple administrative domains, perform the copy-and-swap procedure.

Modifying Active CAC Policy Sets

The procedure to modify an active CAC policy set is the same as the procedure to create a CAC policy set. This procedure is described in the “Configuring Call Admission Control Policy Sets, CAC Tables, and Global CAC Policy Sets” section. The difference lies in the checks the system performs at the end of each of these procedures. The newly modified CAC policy set is activated only after it is determined that the following conditions are met by all the CAC policy tables that are reachable from the modified CAC policy table. A failure message is displayed if any of the CAC policy tables do not meet any of these conditions.

• The table is active.
• All table lookup actions in the table point to valid tables.
• None of the table lookup actions result in a CAC configuration loop.
• All table entry values are valid. For example, the scope name or match prefix length must meet the specified criteria.

Note that the modified CAC policy set is applied only to new incoming calls. Calls that were in progress before the modified CAC policy set is made active are not affected when the modified CAC policy set is made active.

Copy-and-Swap Procedure

To perform a copy and swap procedure, specify the source policy to be copied, and the destination policy to which the source policy is to be copied. The source policy must be an existing policy set, but the destination policy must not be an existing policy set. To protect policies from being overwritten, an error is generated if an attempt is made to copy to an existing policy set.

The old policy can be referenced by different administrative domains, and have multiple indexes within one administrative domain. When the policies are swapped, all the references pertaining to the source policy are replaced with the destination policy. The swap function replaces the default policy and global policy sets, including any policy set referenced in an administrative domain.

The new policy should be set to complete using the complete command before all the references to the old policy are replaced.

We recommend that the new policy is exercised globally before all the references to the old policy are replaced.

Note An error is generated if the old policy either does not exist or is in an incomplete state.

The following configuration example describes the steps involved in copying and swapping call policy set 2:

Step 1 Copy the existing call-policy-set 2 to a new call-policy-set 20:

Step 2 Modify the new call-policy-set with the necessary changes:

Router(config-sbc-sbe-rtgpolicy)# first-inbound-na-table InTable

Router(config-sbc-sbe-rtgpolicy)# first-outbound-na-table OutTable

Step 3 Set the new call-policy-set 20 to complete:

Step 4 Swap the policies so that references to policy set 2 are replaced with policy set 20. The swap function replaces the default and global policy sets, including any policy set referenced in an administrative domain:

The following configuration example describes the steps involved in copying and swapping an existing CAC policy set 12:

Step 1 Copy the existing cac-policy-set 12 to a new cac-policy-set 22:

Step 2 Modify the new cac-policy-set with the necessary changes:

Step 3 Set the new cac-policy-set 22 to complete:

Step 4 Swap the policies so that references to policy set 12 are replaced with policy set 22:

Router(config-sbc-sbe)# cac-policy-set swap source 12 destination 22

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 Selection
• 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 Selection

From Cisco IOS Release 3.2S, the SBC can have multiple active configuration sets. However, by using administrative domains, you can select different policy sets for inbound number analysis, routing, CAC, and outbound number analysis for messages based on their source and destination adjacencies. Figure 7-3 explains the call processing flow using the policy sets.

The policy set that is to be used for a given administrative domain is defined in the admin-domain mode. Call policy sets specified in the admin-domain mode is given a priority. The priority is required because more than one administrative domain can be specified on an adjacency. The SBC will use the policy-set with the highest priority.

The policy sets must be in a complete state before they are assigned to an administrative domain. A default call-policy-set must be configured before the administrative domain mode is entered. If an inbound NA set, a routing set, or an outbound NA set is undefined, the administrative domain uses the values defined within the default call-policy-set. For more information on administrative domains, see the Administrative Domains section.

Figure 7-3 Call Processing Flow Using Policy Sets

Call Policy

A signaling event is assigned to the default call policy set if an admin-domain is not specified on the adjacency.

However, you can use different sets of incoming and outgoing number analysis tables based on the administrative domains configured for the incoming and outgoing adjacencies respectively. You can also configure a different routing policy set on a per-adjacency basis.

If more than one administrative domain is associated with the incoming adjacency, the SBC will use the policy set with the highest priority. You should not configure two routing policy sets with the same priority, two inbound NA policy sets with the same priority, or any two outbound NA policy sets with the same priority. The SBC logs an error but uses the policy with the highest index value.

If the adjacencies list any administrative domains that is not listed in the admin-domain mode, they use the priority in the global policy. The SBC logs a configuration warning if an adjacency references an undefined administrative domain.

CAC Policy

All events are limited by the applicable CAC policies indicated by the source and destination administrative domains and the global CAC policy.

The user can configure a CAC policy using different sets of tables based on the administrative domains configured on both the incoming and outgoing adjacencies. It is not required by the administrative domain to specify a CAC policy-set.

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 7-4 shows the relevant routing tables.

Figure 7-4 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

The following Number Analysis (NA) policies are configured within NA tables and are applied simultaneously to new calls and are described in the following sections:

• Number Validation
• Number Categorization
• Digit Manipulation
• Text Addresses
• Outbound Number Analysis

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 of Destination. 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 of Destination. 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-number —Tables of this type contain entries whose match values represent complete numbers of Source. In such tables, an entry matches an event if the entire source digit string exactly matches the match value of the entry.
• src-prefix —Tables of this type contain entries whose match values represent number prefixes of Source. In such tables, an entry matches an event if there exists a subset of the source digit string, consisting of consecutive digits taken from the front of the source 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 7-1 .

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.

Text Addresses

From Cisco IOS XE Release 3.2S, NA supports both textual username and digit matching. The table name na-src-number-table was changed to na-src-address-table, na-dst-number-table to na-dst-address-table, and na-dst-number-attr-table to na-carrier-id-table.

To match the text addresses, the existing match number is modified to read the match address. The match-address command can include a suffix of digits or regex.

In number analysis, you can define the following matching criteria types:

• Digit matching matches the dialed digit strings using specialized digit regex.
• Regex matching is applicable only to textual usernames, and offers a basic regular expression (BRE) syntax.

Note Comparison of dialed digits and regex is possible. To compare a fixed string, a regex without any regex metacharacters should be used.

Outbound Number Analysis

Outbound Number Analysis allows the configuration of the source and destination numbers from the canonical form to a form that is appropriate for the destination administrative domains. The configuration of Outbound Number Analysis is similar to that of Inbound Number Analysis, which is converted from the source administrative domain form to the canonical form.

Outbound Number Analysis is performed automatically after successful routing. Outbound Number Analysis is processed using the call-policy-set outbound-na command in the destination administrative domain.

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:

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:

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.

Later during routing, the calls are routed based on assigned categories.

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”.

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 —$paratext[TC_TableCap,TCW_TableCapW,TCPr_TableCapPref,TCWPr_TableCapWPref,TCF_TableCapPartFirst,TCN_TableCapPartNext,TCWF_TableCapWPartFirst,TCWN_TableCapWPartNext]>— 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.

Table 7-2 lists the supported error codes that you can configure to trigger hunting of SIP or H.323 calls.

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 7-3 shows the basic regular expression (BRE) implementation for the supported regex characters.

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:

Invalid entries:

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 comparing or editing of source or destination telephone numbers or textual usernames. This process is called Number Analysis (NA). Number Analysis (NA) determines whether a set of source or destination digits, or source or destination textual addresses represents a valid address (based on number validation, number categorization, and/or digit manipulation). This is achieved by configuring one or more tables of valid addresses and editing rules in the tables. Matching for digit strings uses a limited-form of specialized regular-expression syntax and matching for textual addresses is done on the basis of the Basic Regular Expression syntax. In both cases, either the entire address or part of the address can be matched.

NA can be optionally configured as a step within the call policy set.

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
• Multiple SBC Media Bypass
• Common IP Address Media Bypass
• CAC Rate Limiting
• Multiple CAC Averaging Periods
• Subscriber Policy
• Privacy Service

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 in 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 7-4 defines the scopes in which call admission policies can be applied and specifies whether each of these scopes can be combined with other 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 subscriber 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 Network Address Translation (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 7-5 . For information on scope name, scope definition, and whether a scope can be combined, see Table 7-4 .

Limit Tables

Table 7-5 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.

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, CAC Tables, and Global CAC Policy Sets” section for detailed configuration step information.

Table 7-6 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:

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.

Nonlimiting 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 nonlimiting options, such as caller-inbound-policy. Scopes have no meaning for nonlimiting options.

You can configure multiple CAC policies that all apply to a given event (using a Policy Set table type). A nonlimiting 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 nonlimiting 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 nonlimiting option. The behavior for the nonlimiting 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.

Configuring Directed Nonlimiting CAC Policies

In releases prior to Release 3.5.0, you can use the caller command and the callee command to configure the CAC policy entries that are applied when an adjacency, adjacency group, or account is either a caller or a callee in a call. However, this approach does not permit the configuration of certain directed nonlimiting CAC policy fields on specific adjacencies, adjacency groups, or accounts, in a way that is independent of whether the adjacencies, adjacency groups or accounts are the callees or the callers on the calls. The following example illustrates this limitation.

Suppose the following sequence of commands is part of the configuration of an entry in a CAC table:

If there is a call from the adj1 adjacency to the adj2 adjacency, the settings specified for the caller in this example is applied to adj1. At the same time, the callee settings are applied to adj2 because that adjacency is the callee in this call. In a scenario such as this one, you might not want to apply any configuration to the other adjacency (the adj2 adjacency, in this example) involved in the call. The branch command helps overcome this limitation. This command has been introduced in Release 3.5.0.

In the preceding example, the branch command can be used to replace the caller command and the callee command as follows:

Note The branch command is not a replacement for the caller command and the callee command pair in scenarios in which you want to apply settings to both the caller adjacency and the callee adjacency.

With this configuration, the settings specified in the branch command are applied to the adj1 adjacency. For a call from the adj2 adjacency to the adj1 adjacency, the same settings are applied to the adj1 adjacency. For this call, no settings are applied to adj2 or any other adjacency that calls or is called by adj1.

The following are the features of the branch command:

• If a branch setting (that is, the branch command) and a caller-callee pair setting (that is, the caller and callee command pair) are configured in different policy entries, the setting in the last entry of the configuration takes precedence.
• If two branch settings, each in a different policy entry, are encountered, the setting in the last entry that is encountered takes precedence.
• If a branch setting and a caller-callee setting are in the same policy entry, the branch setting takes precedence over the caller-callee setting.

The following sample configuration illustrates how the branch command works:

In this example, the call goes from phone 1 to phone 2. The following sequence of events takes place during the call:

1. Matching is performed on the source adjacency, phone 1, which matches entry 2. Here, the branch entry refers to the caller side, so the caller entry is overridden. After this first policy match is performed, port-range-tag is set to tagA_cac on side A. In addition, the callee port tag is set to adj-name.

2. Matching is performed on the destination adjacency, phone2, which matches entry 1. Here, the branch entry refers to the callee side, so the callee entry is overridden. This entry sets the caller side port-range-tag to tagB_cac. In other words, adj_name is assigned as the callee side port-range-tag. These settings take precedence over the values assigned in the previously matched entry, entry 2, because these settings are assigned later.

The outcome is that the tagB_CAC port is used on side A, and an adj-name port, phone2, is used on side B.

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.

Multiple SBC Media Bypass

The multiple SBC media bypass feature can send media packets directly from the answerer to the original offerer. When the SBC detects that the media packets are being looped back unnecessarily, as shown in Figure 7-5, the SBC removes itself from the loop so that the media packets can flow directly between the endpoints.

Figure 7-5 Loopback Signaling Across The Same SBC—Two Call Media Bypass

Partial Media Bypass

When at least one SBC from the network has to anchor the media because endpoints cannot communicate directly, the other SBC gets bypassed as shown in Figure 7-6. If the media bypass type is explicitly configured to be partial, only IP realm and VPN configuration on the adjacency can be used to determine whether media bypass is possible. Because media bypass tags are not used, the VPN names must be globally unique across all the SBCs for partial media bypass to work.

Figure 7-6 Partial Media Bypass

Figure 7-7 shows an example of media bypass across two or more SBC devices

Figure 7-7 Multiple SBC Media Bypass

In networks where direct media packets cannot pass, the feature creates an optimized media path through a group of SBCs, to avoid unnecessary media hops through the SBC network.

With the multiple SBC media bypass feature, the SBC can transmit an extra set of media addresses alongside an SDP offer. These are the original media addresses that the SBC itself received from the offerer. The original media addresses are placed in a separate multiple SBC media bypass feature information element. These addresses are associated with information about the media plane connectivity of the offerer. A downstream SBC uses the multiple SBC media bypass feature connectivity information to determine whether it can re-instate the original media addresses by rewriting the SDP offer to include them. This enables the media packets to directly pass between the answerer and the original offerer.

The multiple SBC media bypass feature information can also be used by a group of SBCs to optimize the media path and to avoid unnecessary media hops through the SBC network. The SDP answer is accompanied by an indication of whether the feature was successful or not. The SBC uses this indication to determine whether it has been bypassed or whether it is still in the media path. When many SBCs appear in the media path, they collectively build up a stack of alternative media addresses for each media streams in the offer, where each element of the stack has associated connectivity information.

The SBCs determines which endpoints and intermediate hops are connected to decide which intermediate entities can be bypassed. Such connectivity information is passed on by tags in the multiple SBC media bypass feature information elements. Two remote endpoints on an adjacency can be connected if they have one or more matching tags. Therefore, tags must be globally unique for the multiple SBC media bypass feature protocol to work.

Continuing Media Bypass After a Session Refresh

When a media bypass call is in progress, the SIP registrar does not process the media exchanged by the endpoints. Therefore, the registrar uses signaling to detect failures in the session. The registrar sends a session refresh request to check whether a session is alive. The session refresh request is in the form of an INVITE or UPDATE message containing a copy of the SDP forwarded by the registrar during the original call setup.

When the SBC receives the INVITE message from the SIP registrar, it does not correlate the SDP in the message with the SDP sent earlier in the call. The SBC processes the SDP in the INVITE message as normal and creates an SDP offer to send to either the caller endpoint or callee endpoint. From the perspective of the endpoint, the INVITE message is an attempt to renegotiate the media for the call. The endpoint processes the offer and creates an answer that is consistent with the offer. This answer is returned to the registrar through the SBC.

In the answer, the port number for each media stream in the call is different from the port number of the previous media stream. This mismatch in the port number could cause the registrar to send a late INVITE message to the endpoint. An endpoint that does not support the receipt of a late INVITE message for a renegotiation would reject the message. The call fails because the media is being sent from the endpoint to the SBC, from where the media is dropped. To circumvent this issue, renegotiation is enabled by default so that the same path is used to resume exchange of media packets between the endpoints. This feature ensures that media bypass calls continue to bypass the media after a session refresh.

Note You can disable or enable renegotiation.

Restrictions

The multiple SBC media bypass feature has the following restrictions:

• Media bypass is not supported for H.323 calls.
• Media services, such as provisioned transcoding, transrating, and DTMF Interworking preclude media, are sent directly between endpoints. For a given call, if the administrator has configured media bypass settings and if media bypass is possible, then it takes precedence over other media services. However, if lawful intercept (LI) is provisioned on the SBC, LI would take precedence over the multiple SBC media bypass feature.
• The SBC does not support the feature when one endpoint is IPv4 and the other endpoint is IPv6. Because the endpoints cannot understand the traffic they receive.
• The SBC does not support the feature when one endpoint is SIP and the other endpoint is H.323 if SIP-H.323 interworking is enabled. Because the endpoints cannot understand the traffic they receive.

Performance Impact

When the multiple SBC media bypass feature is enabled, it has the following performance impact on the Cisco ASR 1000 series routers:

• The SBCs signaling performance decreases by a small fraction, due to the increased parsing and message manipulation costs. However there is a corresponding gain on media resources for every call that successfully negotiates the feature.
• The transient occupancy of each call setup increases by a multiple of the size of the multiple SBC media bypass feature information that is encoded in the SIP message, plus a small amount of control information. For SDP sizes of 300 bytes, this is predicted to be around 1500 bytes in total. However, the steady-state occupancy for calls that successfully negotiate the multiple SBC media bypass feature decreases as no media resources are required for those calls. This saves approximately 10000 bytes per call.

For more information on configuring the multiple SBC media bypass feature, see the “Configuring Multiple SBC Media Bypass” section. For configuration examples of the feature, see the “Example: Multiple SBC Media Bypass” section. For video of the example that explains how the SBC Media Bypass feature works, see http://www.cisco.com/en/US/docs/routers/asr1000/configuration/guide/SBCU3.5S/sbc_media_bypass.html.

Common IP Address Media Bypass

This section contains the following topics:

• Restrictions for Common IP Address Media Bypass
• Information About Common IP Address Media Bypass
• Features of Common IP Address Media Bypass

Restrictions for Common IP Address Media Bypass

The following are restrictions for the Common IP Address Media Bypass feature:

• This feature is not supported for H.323 adjacencies.
• This feature is not supported in a scenario in which endpoints are behind the same NAT device but are not registered with the SBC.
• This feature is not supported in a scenario in which the caller endpoint and callee endpoint are behind different NAT devices even when there is connectivity between the networks defined by each NAT device. The SBC always relays media between two such endpoints.
• This feature is not supported in a scenario in which only one of the endpoints is behind a NAT device. The SBC always relays media between two such endpoints.

Information About Common IP Address Media Bypass

When you enable the Multiple SBC Media Bypass feature, the SBC bypasses or relays media between the endpoints of an adjacency depending on the media bypass tags presented by the endpoints. If the tags match, the SBC determines that there is media connectivity between the endpoints and, therefore, bypasses itself from the media flow between the endpoints. In contrast, if the tags do not match, the SBC determines that there is no media connectivity between the endpoints and, therefore, relays media between the endpoints.

Note For detailed information about the Multiple SBC Media Bypass feature, see the “Multiple SBC Media Bypass” section.

An organization can use a hosted PBX solution that is owned and managed by a service provider. Typically, a hosted PBX solution can serve many organizations and, therefore, serve multiple NAT devices. There may be a scenario in which there are multiple NAT devices behind a single adjacency. In such a scenario, the SBC must bypass media for the endpoints behind the same NAT device and relay media for the endpoints that are behind different NAT devices. In releases prior to Release 3.6.0, the only way to achieve this is to configure an adjacency for each NAT device. This approach increases the overhead involved in managing the network.

The Common IP Address Media Bypass feature is an enhancement to the Multiple SBC Media Bypass feature. It offers an alternative to the approach of creating an adjacency for each NAT device.

When you configure the Common IP Address Media Bypass feature, the SBC assigns each endpoint behind a NAT device a media bypass tag that is based on the corresponding endpoint’s external, NAT IP address. These media bypass tags are used by the SBC to determine whether the caller endpoint and callee endpoint belong to the same NAT network. If the media bypass tag of the caller endpoint matches the media bypass tag of the callee endpoint, the SBC bypasses media. If the tags do not match, the SBC relays media.

Note The Common IP Address Media Bypass feature does not introduce any change in the mechanism by which the SBC compares the media bypass tags of the caller endpoint and callee endpoint. In other words, the SBC does not distinguish between the feature or method by which media bypass tags are created. The SBC only compares the tags and bypasses media when the tags match.

When the Common IP Address Media Bypass feature is not configured or is disabled, media-bypass decisions are taken by the SBC on the basis of the media bypass tags configured at the adjacency level. If media bypass tags are not configured, media-bypass decisions are taken on the basis of the autogenerated tags that are based on VPN IDs.

When the Common IP Address Media Bypass feature is configured and enabled:

• If the caller endpoint or callee endpoint is a registered subscriber that has been identified at registration time as being behind a NAT device, the SBC generates a media bypass tag and uses that media bypass tag for the call leg.
• If the caller endpoint or callee endpoint is not a registered subscriber or is not behind a NAT device, the SBC uses the tag that is created by the media bypass tag command, if such a tag is present, for the call leg.
• If the caller endpoint or callee endpoint is not a registered subscriber or is not behind a NAT device and if there are no configured tags, the SBC generates a media bypass tag based on the VPN ID of the endpoint, for the call leg.

During the call, if both the endpoints have media bypass tags that match, the SBC determines that both the endpoints are behind the same NAT device and it bypasses media for that call leg. Conversely, if the media bypass tags do not match, if either endpoint does not have a media bypass tag, or if either endpoint is not a registered subscriber, the SBC relays media for that call leg.

The following is the format of the media bypass tag generated by this feature:

nat- VPN-ID - IP-address

In this format, IP-address is the source IP address of the most recent non-fast-pathed, successful REGISTER request from the endpoint. The IP address can be in IPv4 format or IPv6 format.

The following are sample media bypass tags generated by this feature:

• nat-123-192.0.2.6
• nat-254-192.0.26.18
• nat-2233-2001:DB8::AC10:FE01

Features of Common IP Address Media Bypass

The following are additional points about how the Common IP Address Media Bypass feature works:

• After this feature is configured, the SBC can detect whether an endpoint is behind a NAT device by using the existing adjacency configuration features:

– If the no nat command is configured for an adjacency, an endpoint behind that adjacency is recognized as being behind a NAT if the IP address in the Via header of the SIP messages from that adjacency is different from the IP address from which the request was received.

– If the nat force-on command is configured, all endpoints are assumed to be behind a NAT.

– If the nat force-on command is configured and an endpoint is not behind a NAT, the SBC relays media for calls to and from such an endpoint. Note that if this feature is disabled, the SBC bypasses media. When you enable this feature, the SBC starts relaying media.

• If this feature is configured while an adjacency is active, only new calls that are processed by that adjacency are affected by this feature. Existing calls are not affected.
• This feature is independent of whether the initial INVITE message contains SDP content because the media bypass tag is not added to the SDP content.
• This feature is supported by all forms of media bypass:

– Simple media bypass, in which the caller endpoint and callee endpoint are associated with local adjacencies.

– Two-call media bypass, in which the SBC forwards the call to a softswitch or registrar, which then loops the call request back to the SBC.

– N-call media bypass, in which a call is looped through the SBC multiple times.

– Multi-SBC media bypass, in which a call is looped through multiple SBCs.

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 H323messages.

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.

Multiple CAC Averaging Periods

The user can apply different rate limits over a different averaging period by configuring a second set of rate-limiting CAC criteria. The user is able to do the following:

• Set the averaging period for the secondary rate calculation.
• Set the maximum number of new calls per minute for the secondary rate calculation, if a limit is required.
• Set the maximum number of endpoint registrations per minute for the secondary rate calculation, if a limit is required.
• Set the maximum number of in-call messages to be processed per minute for the secondary rate calculation, if a limit is required.
• Set the maximum number of out-of-call messages to be processed per minute for the secondary rate calculation, if a limit is required.

The user can configure two sets of SBC policies together that have rate-limiting criteria. The CAC rejects an event if it breaks any of the configured limits.

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 subscriber, 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.

Privacy Service

The SBC provides the privacy service to ensure that requests for anonymity, as requested by a user during signaling, can be dynamically acted upon to ensure that the user’s anonymity is maintained when the user leaves a trusted network. A user can request various levels of anonymity, with the privacy service removing the information that a user wants to withhold. The SBC can be configured such that individual adjacencies can be marked as trusted, untrusted, or configured in order to apply the privacy service. The privacy service is applied in a CAC policy set.

In addition to this, the SBC can edit—override or modify—a user’s request for privacy when forwarding the privacy request. For example, a user can request identity of self to be withheld, but by editing the privacy request, the identity can be provided.

A user can also provide indications of anonymity in the display and presentation number. During number analysis, these calls can be detected and different analysis trees be used to progress the call.

The Privacy Service feature provides the following functions:

• Apply a privacy service based on information provided by a user when leaving a trusted domain.
• Edit a privacy service on request from a user and perform functions such as pass, strip, insert, and replace indications.
• Declare configurable trust boundaries.
• Detect calls in number analysis where the source is anonymous.
• Standard SIP header rewriting is performed by the SBC to cover the additional requirements specified in the SIP privacy header:

– The Call ID, Server, and Contact headers are rewritten to hide the endpoint's identity.

– Any Via headers are cached and replaced on the message with a single header identifying the SBC.

Both SIP and H323 adjacencies allow the configuration of the trusted and untrusted statuses.

For information about configuring the Privacy Service feature, see the “Configuring Privacy Service” section.

Session Initiation Protocol

In the context of SIP, a user indicates the levels of privacy that should be applied using the Privacy header. If the SBC cannot recognize any of the tokens present in the header, the message is rejected with a 433 Anonymity Disallowed response. Similarly, a response containing a critical privacy request that cannot be met is converted to a 433 failure response for an in-call message. For an out-of-dialog message, the response is dropped to ensure that no private information gets leaked accidently.

If this is an in-call message that does not contain a privacy header, the privacy requirements are assumed to be the same as those specified in the last privacy header from the side of the call. However, if the SBC reroutes a call locally, for example, a SIP 3xx redirect response, it discards the previously learnt privacy requirements on the side of the call that has been rerouted.

The following events occur when privacy services are applied to a request or response:

• When the privacy service based on a user, Privacy: user , is applied to a request or response, the Reply-To, Call-Info, User-Agent, Organization, Subject, In-Reply-To, Warning, and Server headers are stripped from the message.

Also, when the privacy service based on a user, Privacy: user , is applied to a request, the URI in the From header is rewritten to anonymous@anonymous.invalid. The original URI is stored for replacement on responses. The display name in the From header is removed, and any further header manipulation rules that are configured as part of the user ID privacy are applied to the message.

• When the privacy service based on ID value, Privacy: id , is applied to a request or a response, the P-Preferred-ID, P-Asserted-Identity, and Remote-Party-Id headers are stripped from the message.
• When the privacy service based on session privacy, Privacy: session , is applied to a request or a response, media bypass is disallowed. However, if the session privacy is critical, and it is too late to disable media bypass, the call is torn down.
• When the privacy service based on header privacy, Privacy:header , is applied to a request or response, Record-Route or Route headers, if any, are removed and stored. They are restored on the responses within the dialog. If any further header manipulation rules are configured, they are applied to the message.The SBC strips the Privacy header from the ongoing message and removes the privacy option-tag, if any, from the Proxy-Require header.

Users can dynamically request for privacy service. This service can be applied by inserting Privacy: header based on RFC 3323 and RFC 3325.

Privacy Service on SIP Requests

Table 7-8 lists the behavior of the privacy service when it is applied on SIP requests, and Privacy: header is present to indicate the appropriate level of privacy to be applied.

Privacy Service on SIP Responses

Table 7-9 lists the behavior of the privacy service when it is applied on SIP responses.

Privacy Service on H.323

The SBC treats the following H.323 protocol events as requests for the privacy service:

• On a Q.931 Setup, the caller address presentation restriction is requested if the Q.931 callingPartyNumber is present, and contains a presentationIndicator set to 3, presentation restricted, or, the H.225 presentationIndicator is present and set to presentationRestricted.
• On a Q.931 Connect, callee address presentation restriction is requested if the Q.931 connectedNumber is present, and contains a presentationIndicator set to 3, presentation restricted, or, the H.225 presentationIndicator is present and set to presentationRestricted.

When there is a conflict between the two presentationIndicators, the value in the Q.931 callingPartyNumber, the connectedNumber, takes precedence.

H.323 to SIP

A presentation restriction indication that is received for the callingPartyNumber or connectedNumber elements in an H.323 message is considered a request for header;id;critical privacy when being translated to a SIP privacy request.

If the presentation restriction is requested by the H.323 side, the URI in the From header is rewritten with anonymous@anonymous.invalid whether or not the SBC is acting as a privacy service.

When interworking with the SIP, the privacy service is always applied.

SIP to H.323

A SIP-signaled request for id or header privacy is translated into an H.323 presentation restriction on outgoing addresses, if any. All the other SIP privacy tokens are ignored.

Call Statistics

The call-related statistics have been enhanced to include the following two features:

• Number of calls completed during a period—The summary periods of the call-related statistics includes the total number of calls that have been completed. A call is completed because of a signaling message received from an upstream or a downstream device. For SIP calls, a call is completed when a participating endpoint sends a BYE message. For H.323 calls, a call is completed when a participating endpoint sends a ReleaseComplete message with causeValue of 16, which indicates a normal call clearing.
• Running total for the calls statistics—The summary periods of the call-related statistics includes a current-indefinite time value. This time value provides the call-statistics for a period since the value has been last reset. Initially, the current-indefinite time value displays the statistics for the time period since the router was booted. After the value has been reset, it displays the statistics for the time when the last reset was done. The time is in a UTC format where the year, month, day and time is displayed.

The following commands are used for displaying the call-related statistics and resetting the call-related statistics:

• The show sbc sbc-name sbe call-stats {all | global | per-adjacency adjacency-name | src-account name | dst-account name | src-adjacency name | dst-adjacency name } period command—Lists the statistics pertaining to all the calls on a SBE for a particular period, such as currentindefinite .
• The clear sbc sbc-name sbe call-stats [ all | dst-account account-name | dst-adjacency adjacency-name | global | src-account account-name | src-adjacency adjacency-name | per-adjacency adjacency-name ] [ all | current-indefinite ] command—Clears the call statistics on a SBE by the current-indefinite period.

The following example shows how the show sbc sbe call-stats all adj1 currentindefinite command displays statistic pertaining to all calls on the SBE for the current-indefinite period:

CAC Statistics

The CAC-related statistics have been enhanced to include the rejection counts for the CAC policies that have been implemented but failed.

A limiting field is configured in the CAC policy table entries and the CAC policy fails when there is a breach of that limit.

The following commands are used for displaying and clearing the CAC policy sets:

• The show sbc name sbe cac-policy-set [ id [ table name [ entry id]] | global [ table name [ entry id] ]] [ detail ] command—Lists information pertaining to the rejection counts for the failed CAC policies.
• The clear sbc sbc-name sbe cac-policy-set-stats [ all | policy-set cac-policy-number ] command—Clears all CAC policy statistics or clears statistics pertaining to a specified CAC policy set.

The following example shows how the show sbc sbe cac-policy-set table entry command displays statistic pertaining to the rejection counts for the failed CAC policies:

Subscriber Statistics

Subscriber-related statistics have been introduced to enable you to view and analyze information pertaining to the subscribers who are using the SBC. The show sbc sbe command has been enhanced to display these statistics.

The following are the features of subscriber-related statistics:

• The statistics include the subscribers who are currently registered with the SBC, that is, the subscribers stored in the SBC subscriber database. Therefore, only subscribers registered through a non-IMS Access adjacency, P-CSCF Access adjacency, or IPsec P-CSCF Access adjacency are included.
• The statistics include the individual access-side subscribers who register through the SBC. The significance of this feature is that if the SBC rewrites the register, the address of record forwarded to the registrar may be the same for two different access-side address of records. These two addresses of record are recorded as two subscribers in the statistics even though the registrar may consider this as a single subscriber. For example, if both sip:12345@192.0.2.22 and sip:12345@203.0.113.36 register through the SBC and the SBC rewrites them to sip:12345@example.registrar.com, the registrar treats this entry as a single subscriber. However, the SBC counts this entry as two subscribers.
• The statistics represent the number of registered subscribers and not the number of registered contacts. When a subscriber registers multiple contacts, that subscriber will be counted only against the source adjacency of the first contact who is registered. For example, if a subscriber registers Contact1 on Adjacency1 and then registers Contact2 on Adjacency2, the subscriber is counted only once in the global count of subscribers. The same subscriber is not included in the count of subscribers on Adjacency2. This holds true even if Contact1 expires and Contact2 remains active.
• The statistics include delegate registrations performed by the SBC.
• The statistics are available both globally and per adjacency.
• In the IMS mode, the SBC may store multiple addresses of record for a single subscriber, for example, if the registrar returns P-Associated-URIs on a REGISTER response. In this scenario, only a single subscriber is included in the statistics and not the additional addresses of record.

Restrictions for the Subscriber Statistics Feature

The following are the restrictions for the subscriber statistics feature:

• The statistics are lost in the event of a failover.
• The statistics do not include the number of fast-registered subscribers.
• If subscribers register through the SBC on an Interconnection Border Control Function (IBCF) or non-IMS adjacency, the SBC does not track these subscribers and they are, therefore, not included in the statistics.

The following command displays subscriber-related statistics:

show sbc sbc-name sbe subscriber-stats {all | dst-account name | dst-adjacency name | global | src-account name | src-adjacency name } [current15mins | current5mins | currentday | currenthour | currentindefinite | previous15mins | previous5mins | previousday | previoushour]

The following command resets all call-related statistics:

clear sbc sbc-name sbe call-stats [ all | dst-account name | dst-adjacency name | global | src-account name | src-adjacency name ] [all | currentindefinite]

The following example shows how the show sbc sbe subscriber-stats command displays statistics pertaining to subscribers:

Subscribe count totals:

Active subscribers = 10

Subscriber high water mark = 15

Subscriber low water mark = 3

Stats Reset Timestamp:

Timestamp when stats for this summary period were reset = 2011/01/25 23:26:03

Signaling

This section describes how the Asymmetric payload types feature works in the following scenarios:

• SIP-RFC3264 Offer-Answer
• H323-H245
• H.323-SIP Interworking
• Media Programming

SIP-RFC3264 Offer-Answer

This section provides details on how Asymmetric payload types works in a SIP-RFC3264 Offer-Answer scenario.

Asymmetric Payload Types:

• Communicate payload type reassignment from Answer onwards to the offerer.
• Communicate to the MEDIA asymmetric payload type bindings negotiated by RFC3264.
• Log an event when they detect an answer that changes corresponding payload type in a media relay call.

When signaling originates a codec in an offer—either the telephone-event codec in dual tone multifrequency (DTMF) interworking, or a transcoder codec in transcoding—signaling accepts a change of payload type on the answer.

Refer to RFC3264 for more details on how payload type bindings are assigned by SDP rtpmap line.

H323-H245

For H323 calls, asymmetric payload types support is available only for the telephone-event codec.

The Asymmetric Payload Type feature affects only the processing of H.245 Terminal Capability Set, in particular, the receiveRTPAudioTelephonyEventCapability, which signals the RFC2833 telephone-event payload type. This feature:

• Communicates to MEDIA the asymmetric telephone-event payload type bindings negotiated by the H.245 Terminal Capability Set.
• Generates logs when it detects a different telephone-event payload type in each direction.

H.323-SIP Interworking

For H.323-SIP interworking, asymmetric payload types support is available only for the telephone-event codec. The telephone-event payload type received in an H.245 Terminal Capability Set message is communicated onwards in an RFC3264 Offer or Answer message and vice versa.

Although H.323 does not support Asymmetric payload types for any codec other than telephone-event, the same restriction does not apply to a SIP. Hence, a SIP peer might attempt to change the payload type on a flow as part of a SIP-H.323 interworking call. If the payload type is changed, a high-severity Problem Determination log is created, and the call is discarded.

Media Programming

Signaling uses standard H.248 signaling to program asymmetric payload type streams. During the transitions between a Symmetric and Asymmetric payload type bindings, media addresses or ports are not reallocated.

Billing

The Asymmetric Payload Types feature provides the following information for billing:

• Asymmetric payload types that are in use for a given media relay call.
• Codecs that are bound to each payload type.

SIP-SIP Calls

SIP calls indicate Asymmetric payload types by indicating differing payload types in an answer to the previous offer. the SBC will then act upon these Asymmetric payload types.

See the “Example: Allowing Asymmetric Payload Types” section for examples of SIP/SIP configuration and Offer-Answer messages.

Configuring Asymmetric Payload Types

You can configure the SBC to allow or block Asymmetric payload types for each call. By default, asymmetric payload types are allowed on calls.

Use the [no] payload-type asymmetric {allowed | disallowed} command to specify whether to allow or disallow asymmetric payload types.

Performing ISSU for Asymmetric Payload Types

When performing ISSU to upgrade to Cisco IOS XE Release 3.1.0S, a call requesting Asymmetric payload types from an active SBC with a release prior to Cisco IOS XE Release 3.1.0S is replicated to a standby with Cisco IOS XE Release 3.1.0S that supports Asymmetric payload types as if Symmetric Payload Types are being used. The media may not flow correctly on the primary or the backup after the failover.

If a call is currently using Symmetric payload types on an active SBC that does not support Asymmetric payload types, during attempts to renegotiate using Asymmetric payload types, one of the following occurs:

• If the Media, media forwarding component, or the Media Gateway detect that the active SBC does not support Asymmetric payload types, then the change to the corresponding call may be rejected and the call will remain unchanged.
• If the Media, media forwarding component, or Media Gateway does not detect that the active SBC does not support Asymmetric payload types, the corresponding call may continue as if using Symmetric payload types, and this may result in media not flowing correctly.

If a call changes the payload type from Symmetric to Asymmetric, or vice versa:

• After a gate is defined as Asymmetric, it remains Asymmetric even if it ceases to use Asymmetric payload types as a result of a renegotiation.
• If a Symmetric gate is marked as Asymmetric, and the partner does not support Asymmetric payload types, the gate is no longer replicated. The gate is deleted from the backup partner.

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 Text Address Validation and Source Address Manipulation

Configuring Number Validation

This task configures number validation for a number analysis table.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. call-policy-set policy-set-id

5. first-inbound-na-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

Configuring Number Categorization

This task configures number categorization for a number analysis table.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. call-policy-set policy-set-id

5. first-inbound-na-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

Configuring Text Address Validation and Source Address Manipulation

This task shows how to configure text address validation and source address manipulation for a number analysis table.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. call-policy-set policy-set-id

5. first-inbound-na-table table-name

6. na-dst-address-table table-name

7. entry entry-id

8. action [ next-table goto-table-name | accept | reject ]

9. edit-src [ del-prefix pd ] | [ del-suffix sd ] | [ add-prefix pa ] | [ replace ds ]

10. match-address key [ regex | digits ]

11. entry entry-id

12. action [ next-table goto-table-name | accept | reject ]

13. edit-src [ del-prefix pd ] | [ del-suffix sd ] | [ add-prefix pa ] | [ replace ds ]

14. match-address key [ regex | digits ]

15. exit

16. exit

17. end

DETAILED STEPS