Multi-system Selective SRTP Pass-through

Prior to Release S-CX6.3F1, Oracle® Enterprise Session Border Controller provided a single Secure Real-time Transport Protocol (SRTP) operational mode, referred to as SRTP Media Proxy Mode. In this original processing mode, each Oracle® Enterprise Session Border Controller in the SRTP media path served as a proxy for the media — always decrypting inbound traffic, and encrypting outbound traffic.

Release S-CX6.3F1 introduces support for a new, alternative processing mode, referred to as Multi-system Selective SRTP Pass-through Mode. In this new mode encryption and decryption of SRTP media is handled by the SRTP endpoints, the calling and called parties. Off-load of the processor-intensive encryption/decryption provides the Oracle® Enterprise Session Border Controller with the ability to handle a larger number of simultaneous SRTP sessions.

With Multi-system Selective SRTP Pass-through enabled, the Oracle® Enterprise Session Border Controller can configured to selectively allow hair-pinned (spiral) SRTP packets to pass through the Oracle® Enterprise Session Border Controller without encryption or decryption.

Note:

hair-pinned calls are those calls where the calling and called parties are within the same realm and/or within the same sub-network.

Constraints

Multi-system Selective SRTP Pass-through support has the following constraints:

The realm, or realms in which the calling and called parties are located are configured for Multi-system Selective SRTP Pass-through support.
The call session does not require SIP—INFO to RFC 2833 tone translation.
The call session does not require SDES and can be used for the exchange of SRTP keying material. Both the calling and called parties must support the same key exchange protocol.
Multi-system Selective SRTP Pass-through support should not be enabled in topologies where core-side application servers may change the c-line to inject a media server or some other media device in the media path. In such cases, SRTP should be terminated at the SD for each endpoint, so that the media server receives unencrypted media. In the other case, where the c-line is not subject to modification, Multi-system Selective SRTP Pass-through can be enabled.

If any of these conditions are not met, Multi-system Selective SRTP Pass-through processing cannot be provided, and the call is serviced as specified by SRTP Media Proxy Mode.

Operational Overview

To set up Multi-system Selective SRTP Pass-through, the ingress and egress Oracle® Enterprise Session Border Controllers (which can, in fact, be a single Oracle® Enterprise Session Border Controller) exchange the SDES keying material that they receive from their respective endpoint so that the Oracle® Enterprise Session Border Controller peer can pass the material to its adjacent endpoint. The endpoint to endpoint exchange of keying material enables the endpoints themselves to generate encryption/decryption keys.

The actual exchange of keying material takes place in SIP messages (specifically, INVITE, 200 OK, and ACK) that carry offer or answer SDPs. Encrypted keying material is conveyed within a media attribute for each SRTP session. The name of the media attribute is configurable.

When either Oracle® Enterprise Session Border Controller receives the encrypted keying material sent by its remote peer, it decrypts the media attribute and passes the plaintext attribute to its endpoint. Consequently, subsequent SRTP packets from the endpoints pass through the Oracle® Enterprise Session Border Controllers without being decrypted and encrypted because both endpoints (now is possession of each others keying material) are able to decrypt the SRTP packets received from the other.

Call Flows

The following three sections describe call signalling for common scenarios.

Call Setup

A: The calling party sends an INVITE with SDP to SBC-A. The offer SDP contains an SDES crypto attribute within the SRTP media line.

B: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SD-A adds an a=X-acme-srtp-msm media attribute. The a=X-acme-srtp-msm attribute contains a cookie that includes an encryption of the SDES crypto attribute present in the SDP. The encryption is done using the shared secret configured for encrypting SRTP Pass-through information.

C: SBC-B receives the offer SDP that has the cookie sent by SBC-A. It is assumed that the proxies that forward the offer SDP sent by SBC-A preserve and forward the cookie added by SBC-A.

D: SBC-B checks if the egress realm has Multi-system Selective SRTP Pass-through enabled. If so, SBC-B decrypts the cookie using the shared secret to retrieve the SDES crypto attribute. SBC-B adds the SDES crypto attribute retrieved from the cookie to the offer SDP sent to UA-B.

E: The called party sends an answer SDP with a SDES crypto attribute on the SRTP media line to SBC-B.

F: SBC-B checks if it has received a cookie in the offer SDP and adds the cookie to the answer SDP. The cookie contains an encryption of the SDES crypto attribute received in the answer SDP from UA-B. SBC-B does not install any SA or media policy so that SRTP packets from/to UA-B can pass through SBC-B without any decryption/encryption.

G: SBC-A receives the answer SDP that has the cookie sent by SBC-B.

H: SBC-A decrypts the cookie using the shared secret to retrieve the SDES crypto attribute. SBC-A adds the SDES crypto attribute retrieved from the cookie to the answer SDP. SBC-A does not install any SA or media policy so that SRTP packets from/to UA-A can pass through SBC-A without any decryption/encryption.

Music on Hold

After a call is established, one of the endpoints can put the other endpoint on hold. An application server might intercept the re-INVITE from one endpoint (for putting the other on hold) and implement MoH as follows.

A: Endpoint UA-A sends an offer SDP for hold to SBC-A.

B: SBC-A forwards offer SDP without any cookie since there will be no media going from/to UA-A.

C: SBC-B receives an offer SDP that is addressed to the MS without any cookie.

D: Because there is no cookie in the ingress offer SDP, SD-B generates its own SDES crypto attributes for the egress offer SDP sent to UA-B.

E: SBC-B receives am answer SDP from UA-B.

F: SBC-B sends its answer SDP without any cookie and encrypts SRTP packets going to UA-B. Note that there will be no SRTP packets going from UA-B to SBC-B.

As a result, MoH is heard by UA-B as it decrypts SRTP packets encrypted by SBC-B. When UA-A resumes, the steps to establish media between UA-A and UA-B will be the same as the steps used for call setup.

Once the media is reestablished between UA-A and UA-B media travelling between the two UAs will not be decrypted by either SBC.

Call Transfer

A call transfer can also happen after a call is established. For example, endpoint UA-B can transfer UA-A to another endpoint, UA-C. UA-B can make a blind transfer or an attended transfer. The following diagram describes a blind call transfer with SRTP Pass-through enabled. Note it does not show the SIP message exchange between UA-B and the Application Server to facilitate the call transfer (i.e. the INVITE from UA-B to put the call on hold and the REFER/NOTIFY message exchange between UA-B and the Application Server). After UA-A is put on hold and the transfer target (that is, UA-C) is received from UA-B, the Application Server attempts to establish a call to UA-C. After the call to UA-C is established, the Application Server takes UA-A off hold and connects its media session to that of UA-C.

A: SBC-B receives an INVITE (from the Application Server to invite UA-C) without an offer SDP.

B: SBC-B sends an INVITE without an offer SDP to UA-C.

C: SBC-B receives a 200 OK response with an offer SDP that has a SDES crypto attribute on the SRTP media line from UA-C.

D: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SBC-B adds a cookie to the egress offer SDP that is sent to the core realm.

E: SBC-A receives a re-INVITE to UA-A with the offer SDP that has the cookie sent by SBC-B.

F: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SBC-A adds the SDES crypto attribute retrieved from the cookie to the offer SDP sent to UA-A.

G: SBC-A receives an answer SDP that has a SDES crypto attribute on the SRTP media line from UA-A.

H: SBC-A checks if it has a cookie in the offer SDP and adds the cookie to the answer SDP that is sent to the core realm. The cookie contains an encryption of the SDES crypto attribute received in the answer SDP from UA-B. SBC-A stops the encryption of any SRTP packets going to UA-B (set up for MoH) so that SRTP packets from/to UA-B can now pass through SBC-A without any decryption/encryption.

I: SBC-B receives the answer SDP that has the cookie sent by SBC-A.

H: SBC-B decrypts the cookie using the shared secret to retrieve the SDES crypto attribute. SBC-B adds the SDES crypto attribute retrieved from the cookie to the answer SDP.

After the call to UA-C is established and the call to UA-A is resumed (with the resulted media going between UA-A and UA-C) the Application Server disconnects the call with UA-A. Note that steps C-J are essentially the same steps as steps A-H in the Call Setup example. The difference is that the offer SDP from C comes to SD-B in a 200 OK response and the answer SDP sent by SBC-B to C is in the ACK.

Early Media

Different application servers may implement early media in different ways. In general, the SBC supports early media in the following way.

If the SBC receives an SDP without any cookie in a provisional response, the SBC generates its own SRTP crypto context and exchanges it with the caller via the SDP included in the provisional response. The SBC continues to decrypt and encrypt early media packets going to and from the caller. The SBC stops decrypting and encrypting only if it receives a final response with an answer SDP that signals that SRTP Pass-through should be enabled.

Multi-system Selective SRTP Pass-through with Media Release

When SRTP Pass-through is allowed, the hair-pinned media can also be released to the network if media release is configured — that is, if realm-config parameters msm-release is enabled, mm-in-realm is disabled, or mm-in-network is disabled. If SRTP Pass-through is not allowed, media release will not be allowed either.

Multi-system Selective SRTP Pass-through Configuration

Use the following procedure to enable Multi-system Selective SRTP Pass-through within a specific realm.

Use the following command sequence to move to realm-config Configuration Mode.

ORACLE# configure terminal 
ORACLE(configure)# media-manager 
ORACLE(media-manager)# realm-config 
ORACLE(realm-config)#

Use the srtp-msm-passthrough parameter to enable Multi-system Selective SRTP Pass-through within a specific realm.
By default, pass-through support is disabled.
```
ORACLE(realm-config)# srtp-msm-passthrough enabled 
ORACLE(realm-config)# 
```
Use done, exit, and verify-config to complete enabling Multi-system Selective SRTP Pass-through within the current realm.

verify-config checks that the srtp-msm-password parameter has been configured, and outputs an error if it has not been configured. verify-config also checks other configuration settings that conflict with Multi-system SRTP Pass-through operation. Among these possible mis-configurations are the following.

rfc2833-mode set to preferred on a SIP interface within a realm that has srtp-msm-passthrough enabled

rfc2833-mode set to preferred and app-protocol set to SIP on a session-agent within a realm that has srtp-msm-passthrough enabled.
If required, repeat Steps 1 through 3 to enable Multi-system Selective SRTP Pass-through on additional realms.

Use the following procedure to specify values needed to support the exchange of SDES keying information.

Use the following command sequence to move to security Configuration Mode.

ORACLE# configure terminal 
ORACLE(configure)# security 
ORACLE(security)#

Use the srtp-msm-attr-name parameter to specify the name of the media attribute used to convey SDES keying information within a SDP media description.
A valid attribute name must consist of characters from the US-ASCII subset of ISO-10646/UTF-8 as specified in RFC 2327, SDP: Session Description Protocol. IANA-registered names should not be used. Values should begin with an X-1 prefix to prevent collision with registered values.

In the absence of a specified attribute name, the SD provides a default value of X-acme-srtp-msm.
```
ORACLE(security)# srtp-msm-attr-name X-key-material 
ORACLE(security)# 
```
Use the srtp-msm-password parameter to provide the shared secret used to derive the key for encrypting SDES keying material that is placed in the media attribute of an SDP media description. Ingress keying material is encrypted using this shared secret before being forwarded to the network core. On egress, the encrypted keying material is decrypted with this same key.
Allowable values are characters strings that contain a minimum of 8 and a maximum of 16 characters.
```
ORACLE(security)# srtp-msm-password IsHeEleemosynary 
ORACLE(security)# 
```
Use done, exit, and verify-config to complete necessary configuration.

verify-config checks that the srtp-msm-password parameter has been configured, and outputs an error if it has not been configured. verify-config also checks other configuration settings that conflict with Multi-system SRTP Pass-through operation. Among these possible mis-configurations are the following.

rfc2833-mode set to preferred on a SIP interface within a realm that has srtp-msm-passthrough enabled

rfc2833-mode set to preferred and app-protocol set to SIP on a session-agent within a realm that has srtp-msm-passthrough enabled.

Statistics

The number of media sessions set up with Multi-systems Selective SRTP Pass-through is tracked and included in the output of the show mbcd statistics command.