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) offers flexibility in configuring the following features of a Session Initiation Protocol (SIP) adjacency:
Note For Cisco IOS XR Software Release, this feature is supported in the unified model only.
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.
Feature History for SIP Configuration Flexibility
|
|
This feature was introduced on the Cisco IOS XR along with support for the unified model. |
|
The restrictions for implementing SIP configuration flexibility are listed per feature in this chapter.
This section contains the following subsections:
By default, Cisco Unified Border Element (SP Edition) blocks the OPTIONS method from passing through, but users can configure Cisco Unified Border Element (SP Edition) on a per-adjacency basis to pass or block the OPTIONS method by using whitelists and blacklists.
With this feature, users can configure Cisco Unified Border Element (SP Edition) on a per-adjacency basis to control whether it rewrites the hostport section of the From header on Non-Register Requests to the outbound SIP adjacency address or port. If Cisco Unified Border Element (SP Edition) is configured to allow the From header to pass through without it being rewritten, then Cisco Unified Border Element (SP Edition) allows the entire header to pass through without changing it. The only exception occurs with the Tag parameter; Cisco Unified Border Element (SP Edition) assigns a different value to this parameter before passing it through.
The default behavior of Cisco Unified Border Element (SP Edition) is to rewrite the hostport section of the To header on Non-Register Requests to be the outbound SIP adjacency address and port. It also removes any associated parameters. With this feature, users can configure the SBC on a per-adjacency basis to pass the To header through unchanged.
With the addition of a new configuration field to the SIP adjacency, it is now possible for users to specify if Cisco Unified Border Element (SP Edition) must auto-detect whether a NAT is in use on that adjacency. If Cisco Unified Border Element (SP Edition) is configured to auto-detect NAT, then for each request that it receives, Cisco Unified Border Element (SP Edition) determines whether a NAT is in use for that endpoint. If Cisco Unified Border Element (SP Edition) determines that NAT is in use, then Cisco Unified Border Element (SP Edition) stores the bindings for that request and uses them when sending a response. Additionally, Cisco Unified Border Element (SP Edition) stores and reuses bindings for REGISTER requests for subsequent Dialog-forming and Out-of-dialog requests.
Cisco Unified Border Element (SP Edition) routing policy allows you to use the * character in a text domain name match string. This character can match any number of characters in the called address. For example, *domain.com can match both sip1.domain.com and sip2.domain.com.
This section contains the steps for implementing SIP configuration flexibility.
4. adjacency sip adjacency-name
6. header-name [contact [add [tls-param]] | from{ passthrough} | to{ passthrough} ]
The Via Header Passthrough feature enables the SBC to interoperate with certain devices that use the Via header to authenticate other devices, such as a PBX, that do not support SIP authentication. With the introduction of this feature, the SBC can be configured to function as a SIP proxy that is compliant with RFC 3261 and RFC 3581 in its handling of the received parameter and rport parameter, which are two parameters of the Via header.
This section contains the following topics:
The following are the restrictions for the Via Header Passthrough feature:
Certain devices use the Via header to authenticate other devices, such as a PBX, that do not support SIP authentication. The Via Header Passthrough feature enables the SBC to interoperate with the devices that use the Via header to authenticate other devices. In releases prior to Release 3.6.0, the SBC would remove the existing Via headers from an incoming SIP message and add its own Via header before forwarding the message. With the introduction of the Via Header Passthrough feature in Release 3.6.0, the SBC can be configured to allow the existing Via headers to pass through and add its own Via header.
When the Via Header Passthrough feature is configured, the SBC adds its own Via header at the top of the stack of Via headers before forwarding the message. If the remote IP address from which the SBC receives the SIP message differs from the IP address specified in the sent-by address of the header, the SBC sets the received parameter to the actual remote IP address before forwarding the message. At the same time, if the SBC receives a SIP message in which the latest entry in the Via header contains the rport parameter with no value set for it, the SBC sets the value of the rport parameter to the source port of the message. In this scenario, the SBC also adds the received parameter to the Via header, regardless of whether the sent-by address in the Via header matches the IP address from which the message was received.
The Via Header Passthrough feature is configured at the SIP adjacency level. To maintain the Via headers on a message routed through the SBC, the Via Header Passthrough feature must be configured on both the inbound adjacency and the outbound adjacency. If this feature is not configured on either one of these adjacencies, the Via headers are removed from the SIP messages that pass through these adjacencies. Note that the SBC adds its own Via header to the outbound SIP message, regardless of whether the Via Header Passthrough feature is configured.
The following procedure shows how to configure the Via Header Passthrough feature.
4. adjacency sip adjacency-name
5. header-name via passthrough inbound
The following is a sample configuration of the Via Header Passthrough feature:
The following is a sample output of the show sbc mySBC sbe adjacencies adj1 detail command: