Overview
Protocol translation and repair are a key Cisco Unified Border Element (CUBE) function. CUBE can be deployed between two incompatible SIP devices to normalize messaging, ensuring end-to-end compatibility.
Service providers may have policies for which SIP messaging fields should be present (and the values they contain) before a SIP call enters their network. Similarly, enterprises and small businesses may have policies for the information that can enter or exit their networks for policy or security reasons from a service provider SIP trunk.
CUBE Session Initiation Protocol (SIP) profiles change SIP incoming or outgoing messages so that interoperability between incompatible devices can be ensured.
You can configure SIP profiles with rules to add, remove, copy, or modify the SIP, Session Description Protocol (SDP), and peer headers that enter or leave CUBE. The rules in a SIP profile configuration can also be tagged with a unique number. Tagging the rules allows you to insert or delete rules at any position of the existing SIP profile configuration without deleting and reconfiguring the entire voice-class sip profile.
In addition to network policy compliance, CUBE SIP profiles can be used to resolve incompatibilities between SIP devices inside the enterprise network. These are some of the situations in which incompatibilities can arise:
-
A device rejects an unknown header (value or parameter) instead of ignoring it.
-
A device sends incorrect data in a SIP message.
-
A device does not implement (or implements incorrectly) protocol procedures.
-
A device expects an optional header value or parameter, or an optional protocol procedure that can be implemented in multiple ways.
-
A device sends a value or parameter that must be changed or suppressed before it leaves or enters the network.
-
Variations in the SIP standards on how to achieve certain functions.
The SIP profiles feature on CUBE provides a solution to these incompatibilities and customization issues.
SIP profiles can also be used to change a header name from the long form to the compact form. For example, From to f. This can be used as a way to reduce the length of a SIP message. By default, the device never sends the compact form of the SIP messages although it receives either the long or the short form.
Feature Information
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Feature Name |
Releases |
Feature Information |
---|---|---|
SIP Profiles (for inbound messages) |
Baseline Functionality |
This feature modifies the following commands: The inbound keyword was added to the sip-profiles and voice-class sip profiles commands. |
Important Characteristics of SIP Profiles
Given below are a few important notes for SIP Profiles:
-
Session Initiation Protocol (SIP) and Session Description Protocol (SDP) headers are supported. SDP can be either a standalone body or part of a Multipurpose Internet Mail Extensions (MIME) message.
-
The rules that are configured for an INVITE message are applied only to the first INVITE of a call. A special REINVITE keyword is used to manipulate subsequent INVITEs of a call.
-
Manipulation of SIP headers by outbound SIP profiles occurs as the last step before the message leaves the CUBE device; that is, after destination dial-peer matching has taken place. Changes to the SIP messages are not remembered or acted on by the CUBE application. The Content-length field is recalculated after the SIP Profiles rules are applied to the outgoing message.
-
If the ANY keyword is used in place of a header, it indicates that a rule must be applied to any message within the specified category.
-
SIP header modification can be cryptic. It can sometimes be easier to remove a header and add it back (with the new value), rather than modifying it.
-
To include '?' (question-mark) character as part of match-pattern or replace-pattern, you must press "Ctrl+v" keys and then type '?'. This is needed to treat ‘?’ as an input character itself instead of usual device help prompt.
Note
Regex features like look-ahead, look-behind, operator, and non capturing group are not supported (for example, ?!, ?:, ?<=,, and so| on).
-
For header values used to add, modify or copy a header:
-
If a whitespace occurs, the entire value must be included between double quotes. For example, “User-Agent: CISCO CUBE”
-
If double quotes occur, a back slash must prefix the double quotes. For example, “User-Agent: \”CISCO\” CUBE”
-
Basic regular expressions are supported.
-
-
If an incoming SIP message contains certain proprietary attributes, CUBE can copy these unsupported SDP attributes or lines from incoming leg to outgoing leg using a SIP profile rule.
-
The copy variable can be used in an outbound profile to add or modify the outgoing message.
-
Copy Variables u01 to u99 are shared by inbound and outbound SIP Profiles.
Inbound SIP Profile:
-
If the incoming message contains multiple instances of the same header, the header values are stored as a comma separated list, and this needs to be considered while modifying it.
-
Modification by an inbound SIP profile takes place before regular SIP call processing happens so that behavior of CUBE would be as if it received the message directly without modification.
If inbound dial peer matching fails as required information could not be extracted from headers (like Request-URI, Via, From or To) due to issues in them, global level sip-profile config is applied. An example is a request with invalid SIP-Req-URI.
-
After modification by inbound SIP Profiles, the parameters in SIP message might change, which might change the inbound dial-peer matched when actual dial-peer lookup is done.
-
In the register pass-through feature, there is only one dial-peer for register and response. So both register from phone and response from registrar would go through the same inbound sip profile under the dial-peer if any.