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) supports SIP instant messaging (IM). Two options for SIP instant messaging are configurable—record-route passthrough and privacy for SIP Instant Messaging.
The typical SIP instant messaging implementation uses end-to-end Record-Route passthrough, but privacy is not applied.
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 Instant Messaging
|
|
The SIP Instant Messaging feature was introduced on the Cisco IOS XR. |
Cisco Unified Border Element (SP Edition) supports SIP instant messaging (IM). For SIP instant messaging, SBC handles the calls as follows:
SBC can be configured to pass through Record-Route headers from one side of the IM dialog to the other so that the end-to-end Route header set is available to caller and callee. In this case, SBC remains in the flow of messages by appending Record-Route headers and not rewriting the Contact.
Two options for SIP instant messaging are configurable and explained in the following sections:
The typical SIP instant messaging implementation will use end-to-end Record-Route passthrough but will not apply privacy.
This section explains Record-Route passthrough and contains the following subsections:
A Record-Route set represents the hop-by-hop route SIP messages must traverse between two endpoints as part of a SIP dialog. The final hop to the endpoint is represented by the Contact header. SBC's normal behavior is to rewrite the Contact and maintain two independent Record-Route sets, one for each side of the call. Each of these Record-Route sets represents the route between the endpoint and the adjacency on that side of the call.
Passing through the end-to-end Record-Route set means that the adjacencies on a call do not represent the last hop and therefore must not be identified by the Contact header. When passing through the end-to-end Record Route set, SBC also passes through the end-to-end Contacts without rewriting them. In this case, SBC remains in the flow by appending Record-Route headers representing the inbound and outbound adjacencies.
If inbound and outbound adjacencies have conflicting Record-Route passthrough configurations, the setting of the inbound adjacency is used. For example, if the inbound adjacency enables Record-Route passthrough but the outbound adjacency does not, the outbound adjacency will forward the supplied Record-Route set, append a Record-Route header corresponding to the outbound adjacency, and leave the Contact header unaltered.
Record-Route passthrough behavior does not apply to SIP messages received from or going to Registered endpoints regardless of the inbound adjacency's Record-Route passthrough configuration.
The SIP specification (RFC 326) mandates that registrars ignore Record-Route headers present on a REGISTER message. Therefore to ensure that SBC remains in subsequent dialogs created to or from registered subscribers, SBC must rewrite the Contact in REGISTER messages. SBC updates the Contacts in later dialogs created by a registered endpoint so that they match the Contact previously published to network. At the point that SBC rewrites the Contact, SBC terminates any existing Record-Route set and creates a new one.
To pass through Record-Route sets, SBC provides configuration on a per adjacency basis using the passthrough header record-route command.
– For dialog-creating requests, any Record-Route set present on the request is passed through SBC and forwarded to the receiving endpoint.
– The Contact present on the request is passed through SBC and forwarded to the receiving endpoint.
– Record-Route headers representing the inbound and outbound adjacency are appended to the request.
– The end-to-end Record-Route set is passed back through SBC on the response and forwarded to the calling endpoint. Both endpoints see the entire end-to-end Record-Route set.
– The preceding will be the behavior regardless of outbound adjacency configuration.
– Subsequent in-dialog requests do not have their Request URI updated to match the Contact received on the dialog-creating request.
If a request is from or to a registered subscriber, it is processed as though record-route passthrough was turned off.
If topology hiding or privacy is applied to a call, the Record-Route set is stripped from the request regardless of the record-route passthrough configuration.
Configuring Record-Route passthrough does not result in the Route headers being passed through on subsequent messages.
With Record-Route passthrough enabled, messages in an IM dialog are adjusted as described earlier in this section. As an example of these Record-Route passthrough adjustments, the following requests show how enabling Record-Route passthrough affects an INVITE request that is used for an IM dialog. In the first example, Record-Route passthrough is not used. In the second example, Record-Route passthrough is enabled, and SBC adds the Record-Route information in bold font to the INVITE request. In both examples, privacy is not used.
In these examples, the INVITE requests are outbound from the SBC to a SIP proxy server.
Outbound INVITE (without Record-Route passthrough):
Outbound INVITE (with Record-Route passthrough):
For IM privacy, the CAC configuration that is used for normal calls is also used for IM dialogs. The CAC table entry command option caller-privacy configures privacy. For information on using this command, see 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.
If privacy is enabled, SBC adjusts three fields in the SIP IM SDP to make them anonymous.
m=message port [/ number_of_ports ] sip format_list
In the preceding, format_list is a SIP URL and may contain user sensitive information. The user-sensitive information is hidden by stripping all messages indicating Media Description lines and forwarding an Offer containing the following Media Description line:
m=message 5060 sip sip:anonymous@192.168.10.10
The following examples show how enabling caller-privacy affects the SDP messages that are used for an IM dialog. In the examples, 192.168.10.10 is the local address of the outbound adjacency, and 192.168.2.20 is the address of the inbound adjacency. In the examples, the information in bold font has been adjusted to make the caller anonymous. The following example is outbound from the SBC to a SIP proxy server.
Outbound INVITE (without privacy):
Outbound INVITE (with privacy):
The following example is outbound from the SBC to a SIP gateway.
Outbound 200 OK (without privacy):
Outbound 200 OK (with privacy)
In the SDP, SBC identifies IM dialogs by the presence of m=message or m=x-ms-message. For an offer that includes both IM and audio/video media lines, SBC rejects the offer with error code 488, Not Acceptable Here. After the initial media negotiation, any subsequent reoffer that attempts to change a call from an IM to a non-IM or vice versa is also rejected with error code 488.
SBC passes through SDP for IM dialogs unchanged with the exception of modifications due to privacy (see “Privacy for SIP Instant Messaging” section). SBC does not allocate any gates or media pinholes.
The following sections provide more information on how SBC handles SDP for SIP instant messaging:
SDP attached to SIP IM dialogs can contain SIP URLs in the Media Description lines. For example:
m=message 5060 sip sip:example@home.net
If an endpoint sends an in-dialog message to the URL in the SDP (by placing the URL in the Request URI), the behavior is as follows:
For information on Record-Route passthrough, see the “Record-Route Passthrough for SIP Instant Messaging” section.
This section describes some miscellaneous SDP handling for SIP instant messaging.