The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Unified Border Element (SP Edition) supports Inherit Profiles for adjacencies that are not part of an IP Multimedia Subsystem (IMS) network. This feature allows Cisco Unified Border Element (SP Edition) to operate in non-IMS networks using any of three non-IMS profiles that define an adjacency as Access, Core, or Peering. Cisco Unified Border Element (SP Edition) uses this definition to process packets properly and add the correct information in the outgoing packets.
By configuring each of these different types of adjacency with a profile, you can make efficiency and occupancy gains. For example, Cisco Unified Border Element (SP Edition) does not store registration information from messages received from Peering adjacencies. When a subscriber successfully registers from an Access adjacency, Cisco Unified Border Element (SP Edition) remembers the subscriber's registration details for later use and only stores this information on Access adjacencies.
Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).
For a complete description of the commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at:
http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html.
For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
Note For Cisco IOS XE Release 2.4, this feature is supported in the unified model only.
Feature History for Inherit Profiles for Non-IMS Adjacencies
|
|
The following prerequisites are required to implement Inherit Profiles for Non-IMS Adjacencies:
Cisco Unified Border Element (SP Edition) can be deployed in various network topologies and plays different roles depending on its location in the network. Each of the deployed roles usually has a specific set of requirements associated with it. These requirements control which headers need to be added, checked, updated, or removed, and which headers, methods, and options are permitted to be passed through.
Cisco Unified Border Element (SP Edition) can be deployed in non-IMS networks and thus takes on different roles in non-IMS networks. For example, Cisco Unified Border Element (SP Edition) can face a registrar network or end user client devices that will attempt to register through the SBC. Alternatively, you can position it on the Network-Network Interface (NNI).
To deploy in non-IMS networks, Cisco Unified Border Element (SP Edition) uses easily-configured inherit profiles that comprise a collection of related configuration appropriate to a particular network role. Inherit profiles may be configured for an application on a per-adjacency basis or at a global level as a default.
The following are the non-IMS inherit profiles that can be configured for an adjacency:
The following are examples of behaviors that are affected by the non-IMS inherit profiles:
When you configure the SBC with a certain non-IMS profile, calls may be handled differently. For example, when a call is received on a Core adjacency, the SBC checks to see if the endpoint is registered. If the subscriber is registered and is known to be behind a Network Address Translation (NAT), the SBC configures the call to traverse the NAT. If the endpoint is not registered, the SBC applies a routing policy and routes the call to the appropriate adjacency.
Use of a non-IMS inherit profile dynamically assigns the following sets of profiles (method profile, header profile, and option profile) to a call based on the non-IMS inherit-profile selected. Table 21-1 shows which non-IMS inherit profile has an effect on which specific method profile, header profile, and option profile.
The effect is not visible in the adjacency configuration for header-profile, method-profile or option profiles, and can be overridden by explicit configuration of header, method, option profiles as needed.
The inherit profile command has the following three keywords that allow you to configure a preset-access, preset-core, or preset-peer profile for an adjacency that is not part of an IMS network:
preset-access—Specifies a preset access profile for an adjacency that faces an access device on a User-Network Interface (UNI) location.
preset-core—Specifies a preset core profile for an adjacency that faces a core device on a UNI location. This is the default.
preset-peering—Specifies a preset peering profile for an adjacency that faces a peer device on a Network-Network Interface (NNI) location.
The adjacency-specific command configuration overrides any global configuration of the adjacency that was configured using the sip inherit profile command.
The following example shows all the profiles available with the inherit profile command:
The following example displays detailed output for adjacency client, including the “Inherit profile:” field that shows that the adjacency has been configured with the non-IMS preset-access profile: