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) by default passes through all a= lines in SIP messages containing SDP offers and answers that it forwards. You can also configure Cisco Unified Border Element (SP Edition) to block certain a= lines, either by specifying a whitelist (a finite set of a=lines that are passed through, with all others blocked), or alternatively a blacklist (a finite set of a=lines that are blocked, with all others passed through). Additionally, user exits in the Cisco Unified Border Element (SP Edition) code base allow customers to write their own code to insert and/or strip one or more media-level a= lines when processing an offer on an answer.
The SIP-I Support feature enables Cisco Unified Border Element (SP Edition) to pass through the ISDN User Part (ISUP) parameters in Session Initiation Protocol (SIP) messages that are added by a SIP or Public Switched Telephone Network (PSTN) interworking gateway.
The SIP Non-SDP Body Filtering feature adds support for Cisco Unified Border Element (SP Edition) to process non-SDP bodies, and in particular the ISUP body using SIP-I.
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 SDP Handling
This section contains the following subsections:
Review the following restrictions for SIP SDP Attribute Passthrough:
At the point where the policy is applied, a (rate-limited) warning log is issued if the policy attempts to delete one of these lines.
Additional per-call storage is needed to store the SDP policy that is being applied. This is expected to be ~160 bytes per call.
To support interoperation with endpoints that may require an agreed Session Description Protocol (SDP) to be resent for 200 INVITE responses, the user can configure SBC to repeat an agreed SDP, in a 200 INVITE response, when needed, after the successful provisioning of an offer-answer exchange.
This option is configured in the CAC policy for SIP calls. The default is off.
The agreed SDP answer is the SDP answer from the latest completed SDP offer/answer exchange procedure.
When Repeat SDP on 200 Invite Response is configured, the call flow is as shown in the following three figures.
shows the call flow for an SDP on the second reliable response.
Figure 19-1 Call Flow for SDP on Second Reliable Response
shows the call flow for an SDP on the final response.
Figure 19-2 Call Flow for SDP on Final Response
shows the call flow for no SDP on the final response.
Figure 19-3 Call Flow for No SDP on Final Response
See the “Configuring Repeat SDP on 200 INVITE Response” section for the configuration procedure.
See the “Example of Repeat SDP on 200 INVITE Response Configuration” section for and example configuration.
This section contains the steps for implementing SIP SDP Attribute Passthrough.
Note The caller and callee commands have been used in this procedure. In some scenarios, the branch command can be used as an alternative to the caller and callee command pair. The branch command has been introduced in Release 3.5.0. See the “Configuring Directed Nonlimiting CAC Policies” section for information about this command.
4. sip sdp-match-table table-name1
5. action whitelist | blacklist
6. match-string attribute-name1
7. match-string attribute-name2
9. sip sdp-match-table table-name2
10. action whitelist | blacklist
11. match-string attribute-name1
12. match-string attribute-name3
14. sip sdp-policy-table table-name1
17. sip sdp-policy-table table-name2
21. first-cac-table table-name
24. table-type {policy-set | limit {list of limit tables}}
28. caller-inbound-policy policytab-name
29. caller-outbound-policy policytab-name
30. callee-inbound-policy policytab-name
31. callee-outbound-policy policytab-name
36. active-cac-policy-set number
38. show sbc service-name sbe cac-policy-set number table number entry number
Use the following procedure to configure SBC to send a repeat SDP on 200 INVITE responses.
This section provides a sample configuration and output for SIP SDP Attribute Passthrough.
Note The caller and callee commands have been used in this procedure. In some scenarios, the branch command can be used as an alternative to the caller and callee command pair. The branch command has been introduced in Release 3.5.0. See the “Configuring Directed Nonlimiting CAC Policies” section for information about this command.
This section provides a sample configuration and output for SIP SDP Attribute Passthrough.
The following example shows how to configure SBC to send a repeat SDP on 200 INVITE responses.
This section contains the following subsections:
The following prerequisite is required to implement SIP Non-SDP Body Filtering and SIP-I Support:
Before implementing SIP Non-SDP Body Filtering and SIP-I Support, Cisco Unified Border Element (SP Edition) must already be configured. See the procedures described in Chapter3, “”
The following restrictions and limitations apply to SIP Non-SDP Body Filtering and SIP-I Support:
The following sections provide information about the SIP Non-SDP Body Filtering feature and the SIP-I Support feature.
The SIP Non-SDP Body Filtering feature adds support for Cisco Unified Border Element (SP Edition) to process non-SDP bodies, and in particular the ISUP body using SIP-I. The SBC can pass through, strip out, or reject non-SDP bodies. The message body of a SIP message is described using header fields such as Content-Disposition, Content-Encoding, and Content-Type, which provide information about the body. SBC uses a body profile that you create and associate to filter non-SDP bodies from incoming and outgoing SIP messages, based on the Content-Type header field. A body profile allows a message containing a specific non-SDP body to take one of the following actions:
Like any other SIP profile, such as a method profile, you need to first create a body profile. Then you can associate the body profile to cause the body profile to take action on incoming and outgoing SIP messages that fall under the SBE mode, or adjacency mode, or method profile mode.
You can create a body profile:
The body command and action (body) command are used in conjunction with the sip body-profile command. The body command names a body type or content header type for a non-SDP message body. The action (body) command sets the action to take on a body type in a SIP body profile.
After creating a body profile, you can associate the body profile at the following levels and configuration modes:
The SIP-I Support feature enables Cisco Unified Border Element (SP Edition) to pass through the ISDN User Part (ISUP) parameters in Session Initiation Protocol (SIP) messages that are added by a SIP or Public Switched Telephone Network (PSTN) interworking gateway. ISUP is a call control protocol used in SS7 networks primarily for setting up and tearing down telephone calls and for maintenance of the network.
SIP-I is an approach defined by ITU-T Q.1912.5. SIP-I provides an approach for interworking SIP networks and the traditional, circuit-based ISDN User Part (ISUP) networks. SIP-I provides a method for passing through ISUP-specific header parameters through a SIP network so that calls that originate and terminate on the circuit-based ISUP network can cross a SIP network with no loss of information.
SIP-I allows transparent passthrough of ISUP parameters through a SIP network by attaching a copy of the ISUP message to the SIP message at the incoming PSTN gateway. The ISUP message appears as a non-SDP message body on the SIP message. SIP-I has a mechanism to indicate the presence of ISUP (based on Content-Type header) and if the ISUP is mandatory or can be passed through, depending on the Content-Disposition header. The SBC passes through the ISUP message body without coding or decoding the ISUP message.
The mapping between SIP and ISUP protocols is carried out by the Media Gateway Controller (MGC). In the SBC, the ISUP parameters can be carried in the SIP Request-Uniform Resource Identifier (URI) or the SIP message body.
Cisco Unified Border Element (SP Edition) supports the following SIP-I and profile functions:
The following is an example of a non-SDP message body; the SIP message body is not shown in detail for brevity’s sake. The non-SDP body present in the example is of type “application/resource-lists+xml”:
The follow steps describe a sample configuration where a body profile is created with a particular body type and action to take on that body type and then the body profile is associated at the SIP signaling level.
4. sip body-profile {profile_name}
6. action [ pass | nopass | strip | reject]
9. sip default body-profile [[inbound | outbound] {profile_name}
The following is a configuration example of SIP Non-SDP Body Filtering:
The following example displays all the non-SDP message body profiles in use:
The following example displays the details of the specified non-SDP message body profile named “profile2”: