Common Components
The following components of the Cisco Unified Border Element are common to all of the configuration profile examples in this document.
Secure Media
Adjacencies
Call Policies
CAC Policies
SIP Profiles
Secure Media
The secure media segment provides secure transportation of unsignaled, encrypted data streams between two networks.
Secure media is disabled by default. To enable secure media, you configure it at the global level in the the SBC configuration. Once enabled, it applies to all calls.
When secure media is enabled, the Cisco Unified Border Element assumes that all endpoints can handle encrypted data streams regardless of the actual capabilities of the endpoints.
Secure media can apply to any of the following types of addresses:
•Physical address of an interface
•Logical address of an interface
•Service Virtual Interface (SVI) address
The following example shows how to enable secure media:
All connections configured after the secure-media command are secure connections.
Adjacencies
The connection between a Cisco Unified Border Element and a customer, network, business, or service provider is called an adjacency. An adjacency configuration contains the local IP address and the remote IP address for the adjacency that provides the connection between a Cisco Unified Border Element and a customer, network, business, or service provider.
There are two types of adjacencies:
•Session Initiation Protocol (SIP) adjacency, which acts as a back-to-back user agent
•H.323, which acts as an H.323 gateway
Adjacencies can be grouped together in accounts. Accounts enable you define call policies and CAC polices based on customer.
A signaling address must be configured for each adjacency, and each signaling address must be paired with a signaling port. SBC uses the IP-address/port-number pair to receive signaling and control packets.
For a SIP adjacency, the signaling address is specified as an outbound proxy address to a remote device.
A signaling address can be any of the following types of addresses:
•Loopback address configured on the router
•Physical address of an interface
•Logical address of a subinterface
•Static Virtual Address (SVI)
The following examples show the adjacency configurations for Business-to-Business TelePresence Configuration Profile Example:
header-profile inbound PASS-HEADERS
header-profile outbound PASS-HEADERS
method-profile inbound method1
method-profile outbound method1
option-profile ua inbound option1
option-profile ua outbound option1
security trusted-unencrypted
signaling-address ipv4 23.61.1.1
statistics method summary
remote-address ipv4 175.181.0.10 255.255.255.255
signaling-peer 175.181.0.10
header-profile inbound PASS-HEADERS
header-profile outbound PASS-HEADERS
method-profile inbound method1
method-profile outbound method1
option-profile ua inbound option1
option-profile ua outbound option1
security trusted-unencrypted
signaling-address ipv4 23.61.2.1
statistics method summary
remote-address ipv4 175.182.0.12 255.255.255.255
signaling-peer 175.182.0.12
Note For examples of creating VRFs, see the "VRF Examples" section
Call Policies
A call policy is a set of rules that define how SBC responds to new call events. A call policy includes number analysis and routing.
A call policy set contains one or more tables, which contain entries, such as adjacency names, source numbers, and destination numbers. SBC uses these tables to match the fields in incoming and outgoing call packets with the entries in these tables. Based on these matches, SBC can perform the following tasks.
•Jump to another table
•Select the adjacencies
•Complete the call
Call Policy Configuration
This example shows how to configure a call policy with table entries and entry commands that connect 2 CUCM adjacencies: CUCM1 and CUCM2.
first-call-routing-table start-table
rtg-src-adjacency-table start-table
Number Analysis
A number analysis call policy compares incoming and outgoing call numbers with numbers in a Cisco Unified Border Element table of valid telephone numbers.
SBC does number analysis by matching dialed numbers with the configured entries in a call policy entry table. A number analysis call policy is applied only to new call events. If the dialed number does not match any of the entries in the call policy, SBC rejects the call.
A number analysis call policy can perform the following functions:
•Number Validation
•Number Categorization
•Digit Manipulation
Number analysis is done by matching dialed numbers with valid numbers in the following types of call policy tables:
•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.
Note During number analysis, only the destination number can be modified. The source number cannot be modified. The source number can be modified during Routing.
The format of an entry in a call policy table is a limited-form, regular expression representing a string of dialed digits. The format syntax used is described in Table 1.
Table 1 Number Analysis Expressions
|
|
X |
Any numerical digit 0 - 9. |
( ) |
The digit within the parentheses is optional. For example, (0)XXXX represents 0XXXX and XXXX. |
[ ] |
One of the digits within the square brackets is used. For example, [01]XXX represents 0XXX and 1XXX. A range of values can be represented within the square brackets. For example, [013-5]XXX represents 0XXX, 1XXX, 3XXX, 4XXX and 5XXX. |
* |
The * key on the telephone. |
# |
The # key on the telephone. |
- |
Digit delimiter |
, |
Digit delimiter |
a-f/A-F |
Hexadecimal digits |
For more detailed information on number and prefix matching, see Chapter 12, "Implementing Cisco Unified Border Element (SP Edition) Policies" of the Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model.
Number Validation
A number validation call policy verifies whether the dialed number matches a valid telephone number in the call policy table. The following example shows the configuration of a call policy that does number validation:
first-number-analysis-table VALIDATE-DEST-PREFIX
na-dst-prefix-table VALIDATE-DEST-PREFIX
Number Categorization
With number categorization, call events can be placed into user-defined categories during processing. Events that are placed into categories can be referred to during the CAC policy stage. The following example shows the configuration of a call policy that does number categorization:
call-policy-set 3
first-number-analysis-table VALIDATE-DEST-PREFIX
na-dst-prefix-table VALIDATE-DEST-PREFIX
entry 1
match-prefix 8X
category Non-emergency
action accept
exit
category Non-Emergency
action accept
exit
category Emergency
action accept
exit
entry 4
match-prefix X
action reject
exit
Digit Manipulation
Digit manipulation is the process of reformatting a call number into a canonical form, such as the E.164 format. In the following example, the edit-dst del-prefix 1 command in entry 1 removes the leading 1 digit from the dialed number and deletes the entire string.
The following example shows the configuration of a call policy that does digit manipulation:
first-number-analysis-table VALIDATE-DEST-PREFIX
na-dst-prefix-table VALIDATE-DEST-PREFIX
Routing
Routing is also handled in a call policy table. Routing is the process of determining the next-hop and VoIP-signaling entities, to which signaling requests are to be sent.
A routing call policy is applied to new call events and subscriber registration events.
A routing call policy is applied in two stages:
1. Digit manipulation
2. Selection of a destination adjacency (or group of adjacencies for load balancing)
You can configure routing rules using regular expressions to match entities such as:
•User name
•Domain name (that is part of a source or destination SIP URI)
The digits in a call number can be modified or replaced during the routing process.
Note If a new call event matches an existing subscriber registration, the new call is automatically routed to the source IP address and port of the existing subscriber registration. No configured policy is required for this. The configured policy does not effect the routing of such calls.
Note Routing call policies are not applied to call update events, such as update signaling messages. Call update events are automatically routed to the destination adjacency of the call.
The following configuration shows how to configure a routing call policy table for routing calls based on the prefix number of the call:
first-call-routing-table ROUTE-ON-DEST-NUM
rtg-dst-address-table ROUTE-ON-DEST-NUM
CAC Policies
Call Admission Control (CAC) policies determine whether a call event should be allowed or rejected, based on the limits that are configured in the CAC policy for a particular network.
The primary uses of a CAC policy are:
•Preventing DoS attacks
•Implementing service-level agreements (SLAs)
Preventing DoS Attacks
CAC policies are used to defend load-sensitive network elements against potentially harmful levels of load, such as DoS attacks and mass media phone-ins.
Implementing SLAs
CAC policies are used to police the SLAs between organizations and ensure that the network utilization levels are not exceeded.
A CAC policy can be applied to any type of call event. If an event is not granted by a CAC policy, the Cisco Unified Border Element rejects the call event and returns the appropriate error code.
Note Only call admission events are configured in CAC policies. Other call events, such as number analysis and routing are configured in call policies.
The following example shows how to configure a CAC policy to ignore the bandwidth field of media streams. Ignoring the bandwidth field allows the Cisco Unified Border Element to downgrade a media stream from Secure Real-Time Transport Protocol (SRTP) to Real-Time Transport Protocol (RTP).
description Ignore the bandwidth field in SDP
media bandwidth-field ignore
SIP Profiles
A SIP profile can be used to create a whitelist or a blacklist that contains a list headers or methods, and the actions to be performed on them. Whitelists are used to accept requests. Blacklists are used to reject requests.
The following types of SIP profiles are possible for use in whitelists or blacklists:
•Header profile
•Method profile
•Parameter profile
•Option profile
Figure 2 shows the various profiles and how they are attached to a SIP adjacency. Header-profiles can be associated with individual methods also, but in our example, the header-profile is associated directly to the SIP adjacency. Profiles must be associated to an ingress SIP adjacency and to an egress SIP adjacency.
Figure 2
Method, Header, Option Profiles Attached to an Adjacency
Note Parameter-profiles are associated directly to headers, but a parameter-profile is not used in the Telepresence example in this document. Thus, parameters are grayed out in Figure 2.
The Telepresence example in this document uses the following two whitelists and no blacklists:
•Method profile whitelist
•Header profile whitelist
Each header or method entry in the list may optionally be assigned one of the following actions:
•Pass
•Reject
Whitelists use only the pass action. Blacklists use only the reject action.
A header profile is a list of predefined headers that are passed or rejected using a whitelist or blacklist.
A method profile is a list of predefined methods that are passed or rejected using a whitelist or blacklist.
An option-profile is a list of predefined options that can be passed or rejected by placing it in a whitelist or blacklist. In our Telepresence example, the required Telepresence options, TIMER and REPLACES, are passed in the method-profile whitelist.
A whitelist is created using the sip header-profile command, adding the headers or methods as entries, and then assigning the pass action to each entry.
A method profile whitelist applies to an entire SIP message. Method-profile actions override default profile behavior.
A header profile whitelist applies only to single lines in a SIP message. A header-profile can match any part of the header, but it can only replace the entire header.
Profiles must be applied on both the inbound and outbound sides of each adjacency. Figure 3 shows the flow of profiles between adjacencies during a call.
Figure 3
Flow of Profiles During a Call
All headers are passed, stripped, or modified before they are processed by the Bye Reponse(200) on the ingress adjacency. All messages are passed, stripped, or modified after they are processed by the Bye Reponse(200) on the egress adjacency, before they are sent to the line.
Note For the header and method actions to be able to act on messages arriving on the ingress side, the headers and methods must first be passed from the inbound profile on the ingress side.
The following example shows how to attach whitelists to the inbound and outbound profiles.
header-profile inbound PASS-HEADERS
header-profile outbound PASS-HEADERS
method-profile inbound method1
method-profile outbound method1
option-profile ua inbound option1
option-profile ua outbound option1
header-profile inbound PASS-HEADERS
header-profile outbound PASS-HEADERS
method-profile inbound method1
method-profile outbound method1
option-profile ua inbound option1
option-profile ua outbound option1
A profile cannot be deleted while it is attached to any adjacency. You can see which adjacencies are using a profile by entering the following show commands:
•show sbc sbe sip method-profile
•show sbc sbe sip essential-methods
Header Profile
In the following header profile white list, all the listed headers are configured to be passed.
sip header-profile PASS-HEADERS
description "pass non-essential headers"
header Allow-Events entry 1
header Remote-Party-ID entry 1
header Session-Expires entry 1
header session-expiry entry 1
header RESOURCE-PRIORITY entry 1
Table 2 provides a description of three of the PASS-HEADERS white list header entries.
Table 2 Description of Three Entries in the PASS-HEADERS White List
|
|
header SERVER entry |
Contains information about the software used by the user agent server (UAS) to handle the request. |
header DIVERSION entry |
Allows implementation of feature logic based on who diverted the call. |
header RESOURCE-PRIORITY entry |
Helps prioritize access to SIP-signaled resources during periods of emergency-induced resource scarcity. |
Method Profile
In the following method profile white list, the methods are configured with actions and the profile is configured with options:
sip method-profile method1
description "pass default methods"
sip option-profile option1
description "pass default options plus TIMER"