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

Properties Common to SIP Adjacencies

The following properties are common to SIP adjacencies:

• Adjacencies are known by name. The name makes it easy for a Cisco Unified Border Element (SP Edition) policy to reference the adjacency.
• An adjacency has a local address and port for incoming call setup.
• An adjacency has a peer address and port. This is the point of contact for outgoing calls. In the SIP case, this is only true if the "force-signaling-peer" option is set for that adjacency.
• An adjacency forms the output of a routing policy decision. In other words, the routing phase for a call results in selection of an outgoing adjacency for that call. Normally, adjacency selection is done based on a destination telephone number prefix. However, two adjacencies can also be bridged together by using a source adjacency as a routing input.

About SIP Adjacencies in the Deployment

Figure 6-1 shows a simple SIP network where:

• SIP subscribers register with the SIP proxy, which acts as a single point of contact for all of them.
• The softswitch is a gateway between the SIP network and the public switched telephone network (PSTN).
• The softswitch routing policy assigns a particular phone prefix to each SIP proxy, allowing calls from the PSTN network to be routed through the proxy to a given subscriber. (In other deployments, subscribers may register directly with a softswitch without going through a proxy first.)

Figure 6-1 SIP Network

Figure 6-2 shows placement of a Cisco Unified Border Element (SP Edition) in two possible positions within the SIP network, with the adjacencies noted. Each adjacency enables call setup to one or more neighboring devices, as follows:

• ADJ_SIP1A allows call setup between SBC1 and the softswitch.
• ADJ_SIP1B allows call setup between SBC1 and the proxy.
• ADJ_SIP2A allows call setup between SBC2 and the proxy.
• ADJ_SIP_SUBSCRIBERS allows call setup between SBC2 and the subscribers.

In the case of SBC2, SIP registrations are being routed through the SBC. Registrations received on ADJ_SIP_SUBSCRIBERS are being routed to the proxy over ADJ_SIP2A.

The key difference between subscriber and nonsubscriber adjacencies is that:

• Nonsubscriber adjacencies have a configured single point of contact, the peer address for the adjacency.
• Subscriber adjacencies do not have a single point of contact and are instead configured to accept registrations.

SIP registrations require a routing policy to determine which is the correct outgoing adjacency for a given registration. This works in a very similar way to a call routing policy. See the procedures described in the Implementing Cisco Unified Border Element (SP Edition) Policies module.

Figure 6-2 Adjacencies in a SIP Network Deployment

How Adjacencies Affect Media Routing

For a distributed Cisco Unified Border Element (SP Edition) deployment, each adjacency is configured with a media location. The media location is an ID used to select the data border elements (DBEs) suitable for relaying media traffic for calls set up over the adjacency.

If a call is routed out over the same or different adjacency, the media may bypass a DBE. The media bypass feature allows the media packets to bypass the Cisco Unified Border Element (SP Edition) to enable the endpoints to communicate directly to each other. Media packets flow directly without going through the DBE component of the SBC after the call signaling is done. Signaling packets still flow through the SBC as usual.

The configuration is set per adjacency, and allows media bypass across different adjacencies. Media-bypass configuration is enabled under adjacency configuration. Media bypass is useful when two endpoints are on the same subnet, but the DBE is located elsewhere on the network.

Figure 6-3 and Figure 6-4 illustrate how adjacency configuration controls media routing. In this example:

• Adjacency A connects to Peer1
• Adjacency B connects to Peer2a and 2b
• Adjacency C connects to Peer3

Adjacencies A and B are configured with media location 1. In other words, calls routed over them will use the same DBE (or set of DBEs) for media. Adjacency C is configured with media location 2.

Figure 6-3 How Adjacency Configuration Controls Media Routing

Now consider three calls: Peer1-Peer3, Peer1-Peer2a, and Peer2a-Peer2b. The media for these calls is routed as shown in Figure 6-4.

• The first call traverses two adjacencies with different media locations. Its media is relayed through two DBEs.
• The second call traverses two adjacencies with the same media location. Its media is relayed through a single DBE.
• The third call traverses a single adjacency with media by pass enabled. Its media is sent directly between the two peers without involving a DBE.

Figure 6-4 Media Routing for Three Calls: Peer1-Peer3, Peer1-Peer2a, and Peer2a-Peer2b

Configuring Force-Signaling-Peer Adjacency

This task configures a force-signaling-peer adjacency.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. force-signaling-peer

6. attach

7. exit

DETAILED STEPS

Configuring a SIP Adjacency

You can only modify adjacencies when the adjacency is detached. Before modifying an adjacency, you can detach the adjacency first with the no attach command. The adjacency stays in the going down state when a call is active or when the ping enable feature is running. During this state, existing calls are not torn down and new calls are not accepted. The adjacency does not go to detached state until all calls have ended. An adjacency cannot be attached until the adjacency is in detached state.

If you wish to override the option to wait till active calls on the adjacency end, the adjacency can be detached immediately using the following commands:

• no attach force abort—Executes a forced detach, tearing down calls without signaling their end.
• no attach force normal—Executes a forced detach, tearing down calls gracefully.

To check the state of the adjacency, you can use the show sbc sbe adjacencies command.

Caution Adjacencies can only be modified when the status is detached. Before modifying an adjacency, use the no attach command first.

---

Note For User-to-Network Interface (UNI) registration support for a SIP inherit profile, you have the option of using the default value or a preset-access or a preset-core value. When using the default value for those adjacencies without specific per adjacency configuration, the sip inherit profile preset-standard-non-ims command in the SBE configuration mode (config-sbc-sbe) is applied to the adjacencies by default, and UNI registration support is enabled for this default configuration.When configuring a a preset-access or a preset-core value, use the inherit profile preset-p-cscf-access command on the adjacency facing subscribers and the inherit profile preset-p-cscf-core command on the adjacency facing the SIP proxy. If you use other combinations (for example, if both the inbound and outbound adjacencies are configured as preset-core, Cisco Unified Border Element (SP Edition) will not store the registration information, nor will it rewrite the Contact: header to make sure it's on the signaling path of future messages.

This task configures two session initiation protocol (SIP) adjacencies. The first adjacency is configured for a gateway/endpoint. The second adjacency is configured with proxy/softswitch.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. sip inherit profile {preset-ibcf-ext-untrusted | preset-ibcf-external | preset-ibcf-internal | preset-p-cscf-access | preset-p-cscf-core | preset-standard-non-ims}

5. adjacency sip adjacency-name

6. signaling-address ipv4 ipv4_IP_address

7. signaling-port port_num

8. remote-address ipv4 ipv4_IP_address/prefix

9. signaling-peer peer_address

10. signaling-peer-port port_num

11. account account-name

12. registration rewrite-register

13. attach

14. exit

15. adjacency sip adjacency-name

16. inherit profile { preset-access | preset-core | preset-ibcf-ext-untrusted | preset-ibcf-external | preset-ibcf-internal | preset-p-cscf-access | preset-p-cscf-core | preset-peering | preset-standard-non-ims}

17. signaling-address ipv4 ipv4_IP_address

18. signaling-port port_num

19. remote-address ipv4 ipv4_IP_address/prefix

20. fast-register disable

21. signaling-peer peer_name

22. signaling-peer-port port_num

23. account account-name

24. registration target address host_address

25. registration target port port_num

26. attach

27. exit

28. end

29. show

DETAILED STEPS

Assigning SIP Adjacencies to Adjacency Groups

Use the procedure in this section to assign an SIP adjacency to an adjacency group.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. group adjacency-group-name

6. end

7. show

DETAILED STEPS

Configuring a SIP Adjacency: Example

The following example configures two SIP adjacencies. The first adjacency is configured for a gateway/endpoint. The second adjacency is configured with proxy/softswitch.

1. Activate SBE, as follows:

2. Activate DBE, as follows:

3. Create the SIP adjacencies, as follows:

4. Create the SIP adjacency for gateway/endpoint:

5. Create the SIP adjacency for proxy/softswitch:

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. ping-enable

6. ping-interval interval

7. ping-lifetime duration

8. ping-fail-count fail-count

9. exit

DETAILED STEPS

SIP UAS Failure Detection: Example

In the following configuration example, PING is enabled on each of three adjacencies. A round robin call policy is set so that calls are distributed between the three adjacencies in a weighted random manner. If a UAS is unreachable, calls will be distributed between the remaining two adjacencies.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. outbound-flood-rate rate

6. exit

DETAILED STEPS

SIP Outbound Flood Protection: Example

The following configuration example sets an outbound flood rate of 100 outbound request signals per second.

Security Configuration on an Adjacency

You can independently configure client and server security support on a SIP adjacency, using the following options:

• Untrusted—Specifies that this adjacency is not secured by any means. Only unsecured calls (not the calls to SIPS URIs) are made out of this adjacency.
• Untrusted-Encrypted—Specifies that the adjacency is untrusted and SSL/TLS encryption is used.
• Trusted-Encrypted—Specifies that the encrypted signaling is used to ensure security on this adjacency. The default certificate and key of the router are used for encryption. Only secure calls (calls to SIPS URIs) are made out of this adjacency.
• Trusted-Unencrypted—Specifies that a non-encryption mechanism is used to guarantee secure signaling for all messages on this adjacency. For example, this mechanism could be a single trusted physical link. Either secure or unsecured calls are made out of this adjacency. This configuration allows endpoints that do not support encryption to participate in secure SIP calls.

SIP Over TLS Overview

SIP Over Transport Layer Security (TLS) encryption provides a secure, encrypted transport to carry all SIP messages from the caller to the callee's domain. From there, the request is sent securely to the callee.

Cisco Unified Border Element (SP Edition) provides the following support for SIP Over TLS:

• Secured SIP calls can flow through Cisco Unified Border Element (SP Edition).
• A SIP adjacency can be secured by encryption or by another mechanism (for example, a single trusted physical-layer link or an interface to a trusted network).
• Inbound and outbound connections are immediately closed if a remote peer attempts to use encryption when encryption is not supported.
• Inbound and outbound connections are immediately closed if a remote peer fails to use encryption when encryption is required.
• You can view the level of security support configured for a given SIP adjacency by using the show sbc sbc-name sbe adjacencies adj name detail command.
• Calls received on untrusted adjacencies are not routed over outbound secure-encrypted adjacencies.
• Adjacencies secured by means of encryption can listen by default on port 5061. The port is configured to a different value.
• The fully-qualified domain name (FQDN) in the certificate offered by the remote peer is checked against the domain from which the request is received. The signal is dropped if the two do not match.
• Advanced Encryption Standard (AES) 128-bit Secure Hash Algorithm (SHA) is supported.
• The PKI HA updates the standby router with the certificate and trustpoint configuration changes.

The following are main security factors that are used in routing or rejecting a call:

• Calls to a SIPS URI must be secure. Calls to a SIP URI do not have to be secure.
• Signals received on a trusted adjacency are considered secure. Signals received on an untrusted adjacency are considered unsecured.

The following security factors apply to untrusted encrypted adjacencies:

• Secure calls may not be received on untrusted adjacencies of any type.

– Cisco Unified Border Element (SP Edition) allows unsecured calls to be received over the untrusted encrypted adjacency.

– Cisco Unified Border Element (SP Edition) rejects secured call that it receives over the untrusted encrypted adjacency.

• Secure calls cannot be routed to untrusted adjacencies.

– Cisco Unified Border Element (SP Edition) can route unsecured calls over the untrusted encrypted adjacency.

– Cisco Unified Border Element (SP Edition) does not route secured calls over the untrusted encrypted adjacency.

Table 6-1 and Table 6-2 summarize how Cisco Unified Border Element (SP Edition) handles inbound and outbound calls based on the call type, trust relationship, and encryption.

Table 6-3 and Table 6-4 summarize how Cisco Unified Border Element (SP Edition) handles inbound and outbound registrations based on the registration type, trust relationship, and encryption.

For the SBC to be able to forward Secure SIP (SIPS) registrations to a trusted-unencrypted adjacency, all the following conditions must be met:

• The source adjacency must have a non-IP Multimedia Subsystem (non-IMS) or non-IMS access adjacency profile that specifies tracking of the registration state.
• The destination adjacency must have a non-IMS adjacency profile.
• The destination adjacency must be configured to accept a SIPS URI registration. This procedure is explained in the “Enabling the Conversion of SIPS URIs to SIP URIs on a Trusted-Unencrypted Adjacency” section.

When the SBC forwards secure registrations to a trusted-unencrypted adjacency that meets these conditions, the outbound registration is modified as follows:

• The Address of Record (AoR) in the To and From headers is converted from a SIPS URI to a SIP URI.
• The Request URI is converted from a SIPS URI to a SIP URI. Note that the Request URI may not be identical to the AoR.
• The URIs in the Contact headers are converted from SIPS to SIP.
• The URIs in Record Route headers are passed through unchanged. Note that according to RFC 3261, Record Route headers must be ignored on receipt if they are present in REGISTER messages.
• The URIs in other SIP headers are passed through unchanged.

Note The SBC rejects registrations that contain a mix of SIP URIs and SIPS URIs in their AoRs and contacts. On receipt of the REGISTER response, the SBC reverses the changes and passes back SIPS URIs in the response forwarded to the endpoint.

The following are restrictions for this feature:

• There is no change in the processing of non-INVITE messages, such as SUBSCRIBE, NOTIFY, and PUBLISH, by the SBC. For these messages, the SBC does not convert SIPS URIs to SIP URIs.
• The SBC does not support registrations to trusted-unencrypted adjacencies in scenarios where either the inbound adjacency or the outbound adjacency has an IMS profile.

User Agent Server-Side Processing

Inbound requests are marked according to two factors: whether the caller is trusted, and whether the call is intended for a secure target.

The caller-trust is determined in the following ways:

• SIP requests arriving over trusted adjacencies are marked as trusted.
• SIP requests arriving over untrusted adjacencies are marked as untrusted.

Desired target security is determined in the following ways:

• Requests for SIPS URIs are marked to require the outbound-security.
• Requests for SIP URIs are marked not to require the outbound-security.

Inbound requests are rejected if the caller is untrusted and the target requires security. All other combinations are forwarded to routing processing.

Routing Processing

The Routing Policy System (RPS) policy determines where the requests are routed next, with the following default behaviors:

• If a call requires the outbound security, the RPS considers only the trusted outbound adjacencies.
• If a call does not require the outbound security, the RPS considers only untrusted or trusted-unencrypted outbound adjacencies.

If the RPS is unable to find a suitable outbound adjacency for a call, the call is rejected.

User Agent Client-Side Processing

Outbound adjacencies preserve the URI scheme of the original request, ensuring that if a call is originally targeted at a SIPS URI, it is sent out to a SIPS URI. Or, if the call is originally targeted at a SIP URI, it is sent out to a SIP URI.

Upon receipt of 3xx class responses and target-refresh indications, the contact set is examined. Untrusted adjacencies do not permit the target of the call to be rerouted to a SIPS target. Likewise, trusted adjacencies do not permit the target of the call to be rerouted to a SIP target. If this is attempted by the remote peer, the call is brought down.

Configurable Mutual TLS Authentication Per Interface

The Configurable Mutual TLS Authentication Per Interface feature helps you to configure unilateral or mutual TLS authentication on a per adjacency basis for SIP over TLS calls.

In a SIP over TLS call, SBC can either be a TLS client side or TLS server side. This feature is relevant only when the SBC is a TLS server side.

While negotiating a TLS connection, the server side sends its certificate to the client side to perform the server authentication. After the server authentication, the server may require a certificate from the client for client authentication. When client authentication is not used, the authentication is referred to as a unilateral authentication. When both — server and client — requires authentication, then it is referred to as a mutual authentication.

The message flow diagram, Figure 6-5, illustrates the negotiation process of a TLS connection. The bold line represents the messages required when mutual authentication is enabled on the server side:

Figure 6-5 Mutual TLS Authentication Message Flow Diagram

When SBC acts as TLS client side, it can automatically negotiate with the server side to perform the client authentication. But when SBC acts as TLS server side, you need to configure SBC so that SBC can decide whether to send a CertificateRequest message to the client side to get the client's certificate to do client authentication.

Use the tls mutual-authentication command to configure mutual authentication.

Restrictions and Limitations—Configurable Mutual TLS Authentication

• The configuration on a SIP adjacency cannot be modified while the adjacency is attached.
• The security configuration of the adjacency must be trusted encrypted or untrusted encrypted.
• Multiple TLS-enabled adjacencies that use the same local address and port must have the same configuration. Otherwise, the configuration will be rejected and an error message will be displaced on the console.
• Configuring trust points on a per adjacency basis is not possible because SBC uses global trust points to validate peer's certification. This limitation will not pose any limitation for certificate verification on SBC because, SBC automatically searches for a matching certificate from its global trust points.
• SBC only supports one certificate while SBC is a TLS server side. It is not possible to configure different certificates for each adjacency. The certificate is picked from the primary trust point.
• Certificate chain is not synchronized in SSO config-sync redundancy mode and hence the TLS certificates are not replicated to the standby. The incoming TLS calls might fail because of non-availability of TLS certificates.

TLS Transport Parameter in Record-Route Headers

This feature allows you to add a transport=tls parameter to the SBC-originated Contact and Record-Route headers when using TLS. This feature is applicable when the security for the SBC inbound adjacency is configured as untrusted-encrypted.

The transport=tls parameter was deprecated in RFC3261 for better interoperability. With the implementation of RFC3261, the Contact and Record-Route header of 200(INVITE), back to caller, would use SIP URI without the transport parameter such as Contact: <sip:192.168.1.1:5060>, Record-Route: <sip:192.168.1.1:5060;lr>. Because of this, the subsequent mid-dialog requests—re-INVITE—are sent using TCP or UDP based on the SIP URI instead of TLS. Since SBC is expecting a TLS message on the port, the call is dropped.

Figure 6-6 shows the message flow where the SIP call is received over TLS, but the call was dropped. The ACK in response to the 200OK (TLS) message is sent from the SIP to SBC using TCP or UDP.

Figure 6-6 Message Flow During a SIP Call Over TLS

To avoid call drops, the caller is forced to use the TLS transport for the ACK by adding the transport=tls parameter. This feature is controlled on a per adjacency basis.

Use header-name [contact [add [tls-param]] | from{ passthrough} | to{ passthrough} ] command in (config-sbc-sbe-adj-sip) mode to configure the transport=tls parameter in the Contact and Record-Route header.

Configuring SIP Over TLS on Cisco Unified Border Element (SP Edition)

Use the procedure in this section to configure SIP over TLS on Cisco Unified Border Element (SP Edition):

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. security trusted-encrypted

6. redirect-mode { pass-through | recurse}

7. authentication nonce

8. signaling-address ipv4 ipv4_IP_address

9. signaling-port port-num

10. remote-address ipv4 ip-address ip-mask

11. signaling-peer peer-name

12. signaling-peer-port port-num

13. dbe-location-id dbe-location-id

14. reg-min-expiry period

15. attach force [abort | normal]

DETAILED STEPS

SIP Over TLS Configuration Example

The following example shows a SIP over TLS configuration:

The Cisco Unified Border Element (SP Edition) configuration example is illustrated here.

SIP Over TLS Verification

Use the following commands to check certificates on the node:

show crypto pki certificates—displays information about your certificate, the certification authority certificate (CA), and any registration authority (RA) certificates.

show crypto key pubkey-chain rsa—enters public key configuration mode (so you can manually specify and show other devices' RSA public keys).

show crypto key mypubkey rsa—displays the RSA public keys of your router.

Enabling the Conversion of SIPS URIs to SIP URIs on a Trusted-Unencrypted Adjacency

Use the procedure described in this section to enable the conversion of SIPS URIs to SIP URIs on a trusted-unencrypted adjacency. Performing this procedure is one of the requirements for configuring the SBC to forward secure registrations to a trusted-unencrypted adjacency. See “SIP Over TLS Overview” section for more information about this feature.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. adjacency sip adjacency-name

5. security trusted-unencrypted

6. registration unencrypted-convert

7. end

DETAILED STEPS

In the following example, the output of the show sbc adjacencies command shows that conversion of SIPS URIs to SIP URIs is enabled:

Restrictions for SIP Peer Availability Detection

The SIP Peer Availability Detection feature has the following restrictions:

• The OPTION requests will use the SIP method congestion response codes.
• If the number of OPTIONS messages to the peer are reduced, the time taken to detect dead peer by the SBC increases substantially.

Configuring SIP Peer Availability Detection

Use the procedure described in this section to configure the detection of SIP peer availability:

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. ping-enable

6. ping-bad-rsp-codes ranges

7. ping-suppression

8. exit

9. end

10. show sbc sbc-name sbe adjacencies adjacency-name Detail

DETAILED STEPS

Example

The following example shows how to configure the congestion response codes on a SIP adjacency by sending SIP OPTIONS pings:

Restrictions for Redundant Peer Addresses

The Redundant Peer Addresses feature has the following restrictions:

• This is a signaling-only feature.
• Alternative redundant addresses for a peer cannot be automatically detected, and must therefore, be configured using the ping-enable command.
• The main peer address in an adjacency share the same priority values, ranging from 1 to 6, as the redundant peer addresses.
• A single load-balancing method is provided. The SBC selects the active peer IP address with the highest configured priority for all the outgoing SIP requests.
• The source address of fast-REGISTER requests cannot be changed.
• If a SIP request is sent to a peer address, and no response is received, the SBC subsequently detects that the peer address has failed. However, the destination address of the SIP request does not change, and it is retried to the failed address. New requests are sent to an active address.
• The destination addresses and ports configured for a given adjacency are not available in message editing configuration. Therefore, there is no per-destination equivalent for the existing signaling-peer and signaling-peer-port header filtering syntax.
• The optimization to send only pings when required (ping suppression) cannot be configured on the adjacencies facing redundant peers.

Configuring Redundant Peer Addresses

Use the procedure described in this section to configure redundant peer addresses:

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. no attach

6. force-signaling-peer all

7. ping-enable

8. exit

9. redundant peer index

10. address address

11. port port

12. network { IPv4 address netmask | IPv6 address netmask }

13. priority priority

14. activate

15. exit

16. signaling-peer-switch { always | fail }

17. signaling-peer-priority priority

18. exit

19. end

20. show sbc sbc-name sbe adjacencies adjacency-name peers

DETAILED STEPS

Redundant Peer Addresses Example

The following example shows a redundant peer addresses configuration:

Redundant Peer Addresses Verification

Use the following commands to verify the peers:

• show sbc sbe adjacencies detail —Displays detailed configuration of a SIP adjacency.
• show sbc sbe adjacencies peer —Lists the configured peers for an adjacency.
• show sbc sbe all-peers —Displays a peer’s information.