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

OPTIONS Support

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.

Restrictions for OPTIONS Support

• Cisco Unified Border Element (SP Edition) strips out SDP blocks from messages when it allows the OPTIONS method to pass through. This limits what the SIP endpoints can exchange.
• The SBC-SIG does not send the Accept and Allow headers on any methods, including OPTIONS.
• Cisco Unified Border Element (SP Edition) allows only the 100Rel and Replaces tags of the Supported header to pass through, while the other tags of this header are controlled by whitelists and blacklists.

Rewriting From Header on Non-Register Requests

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.

Restrictions for Rewriting From Header on Non-REGISTER Requests

• This feature is not applicable for REGISTER requests.
• This feature may only work in a limited way with the Rewrite-Register feature.
• If the From header contains a Tel URI, then Cisco Unified Border Element (SP Edition) does not rewrite the header since it does not have a hostport.
• Depending on the number of headers, options and SIP whitelist profiles, Cisco Unified Border Element (SP Edition) limits the size of the From header that it allows to pass through to approximately 1000 bytes.

Rewriting To Header on Non-REGISTER Requests

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.

Auto-detecting NAT

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.

Restrictions for Auto-detecting NAT

• Cisco Unified Border Element (SP Edition) can auto-detect NAT only by comparing the Sent-by stopper in the Via header with the remote address and port of the message.
• If the stopper contains a domain name, instead of an IP address, Cisco Unified Border Element (SP Edition) cannot auto-detect whether NAT is in use. In this case, Cisco Unified Border Element (SP Edition) assumes that NAT is in use.
• Auto-detecting NAT is applied only to Out-of-dialog requests or Dialog-forming requests.

Routing on Wildcard Domains

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.

Restrictions for Routing on Wildcard Domains

• You can only specify one wildcard character in a given match string.
• This feature applies only to text domain name match rules, and not to dialed digit match rules.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. passthrough from header

6. header-name [contact [add [tls-param]] | from{ passthrough} | to{ passthrough} ]

7. nat force-on

8. exit

DETAILED STEPS

Restrictions for Via Header Passthrough

The following are the restrictions for the Via Header Passthrough feature:

• This feature does not support the Topology Hiding feature. After the Via Header Passthrough feature is configured, the data that is passed through the SBC includes information about the topology of the network between the sender and the SBC. If you want to protect the network between the sender and the SBC by using the Topology Hiding feature, do not configure the Via Header Passthrough feature.
• The existing restriction on editing Via headers by using the SIP Message Editing feature is still applicable.

Information About Via Header Passthrough

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.

How to Configure Via Header Passthrough

The following procedure shows how to configure the Via Header Passthrough feature.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. adjacency sip adjacency-name

5. header-name via passthrough inbound

6. header-name via passthrough outbound

7. end

8. show sbc sbc-name sbe adjacencies adjacency-name detail

DETAILED STEPS

Configuration Example: Via Header Passthrough

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: