Secure and Non-Secure Flows in the Same Realm

To simplify deployments, the E-SBC allows secure and non-secure flows in the same realm.This broadened set of capabilities means the E-SBC can support RTP and SRTP flows, and it can support a larger group of UAs that might have varying SRTP abilities. Prior to this release, when a cryptographic session arrived at the E-SBC and failed to match an applicable media security profile, it was rejected.

This broadened support for secure and non-secure flows and for UAs with various SRTP abilities is established throughout the OS, residing in these configurations:

media-sec-policy
sdes-profile

While configurations reside there, you should also note special considerations for the security-policy configuration and implications for security associations.

Mode Settings in the Media Security Policy

The media security policy configuration’s mode parameter offers three settings. It is the any mode that allows you to support secure and non-secure flows in the same realm.

For Incoming Flows

This section describes the way all three settings behavior for incoming flows.

rtp—If the incoming media security policy associated with a realm has rtp set as its mode, then the E-SBC only accepts offer SDP containing RTP/AVP media lines. Otherwise, the E-SBC rejects the session with a 488 Not Acceptable Here.
srtp—If the incoming media security policy associated with a realm has srtp set as its mode, the E-SBC only accepts offer SDP containing RTP/SAVP media lines. Otherwise, the E-SBC rejects the session with a 488 Not Acceptable Here.
any—If the incoming media security policy associated with a realm has any set as its mode, the E-SBC accepts offer SDP that has RTP/AVP media lines, RTP/SAVP media lines, or both.

For Outgoing Flows

This section describes the way all three settings behavior for outgoing flows.

rtp—If the outgoing media security policy associated with a realm has rtp set as its mode, then the E-SBC converts any RTP/SAVP media lines from incoming offer SDP to RTP/AVP for the offer SDP it sends out.

Incoming offer SDP might look like this:

v=0
o=MxSIP 0 1480968866 IN IP4 192.168.22.180
s=SIP Call
c=IN IP4 192.168.22.180
t=0 0
m=audio 5010 RTP/SAVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:f0oLKTuMYwXqrKa7Ch+MOBvLe8YnXnD6Kmnj4LQ2

The E-SBC will take that and convert it to the following for outgoing traffic.

v=0
o=MxSIP 0 1480968866 IN IP4 172.16.22.180
s=SIP Call
c=IN IP4 172.16.22.180
t=0 0
m=audio 6000 RTP/AVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-1

This conversion can result in multiple media lines with RTP/AVP for the same media profile and an RTP/SAVP media line for the same media profile. To prevent duplicate lines in the SDP the E-SBC sends, the E-SBC inspects incoming SDP to determine is RTP/AVP and RTP/SAVP media lines exist for the same media profile. If it finds such a media profile, the E-SBC disables the RTP/AVP (by setting the port to 0 in the outgoing offer SDP) corresponding to the RTP/AVP media line for that media profile. Doing so forces the UA answering the SDP offer to choose the media lines corresponding to the RTP/SAVP media lines in the incoming offer SDP. An SRTP-RTP session results.

The incoming offer SDP might look like this:

v=0
o=MxSIP 0 1480968866 IN IP4 192.168.22.180
s=SIP Call
c=IN IP4 192.168.22.180
t=0 0
m=audio 5012 RTP/AVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
m=audio 5010 RTP/SAVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:f0oLKTuMYwXqrKa7Ch+MOBvLe8YnXnD6Kmnj4LQ2

And the outgoing offer SDP will look like this:

v=0
o=MxSIP 0 1480968866 IN IP4 172.16.22.180
s=SIP Call
c=IN IP4 172.16.22.180
t=0 0
m=audio 0 RTP/AVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
m=audio 6002 RTP/AVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15

If an incoming offer has both RTP/AVP and RTP/SAVP media lines, and there exists duplicate media descriptions for the same codec, then Oracle® Enterprise Session Border Controller removes the duplicate description.

srtp—If the outgoing media security policy associated with a realm has srtp set as its mode, the E-SBC converts any RTP/AVP media lines from an incoming offer SDP to RTP/SAVP for the offer SDP the E-SBC sends.

The incoming offer SDP might look like this:

v=0
o=MxSIP 0 1480968866 IN IP4 192.168.22.180
s=SIP Call
c=IN IP4 192.168.22.180
t=0 0
m=audio 5012 RTP/AVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15

And the outgoing offer SDP will look like this:

v=0
o=MxSIP 0 1480968866 IN IP4 172.16.22.180
s=SIP Call
c=IN IP4 172.16.22.180
t=0 0
m=audio 6000 RTP/SAVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-1
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:f0oLKTuMYwXqrKa7Ch+MOBvLe8YnXnD6Kmnj4LQ2

This conversion might result in multiple media lines with RTP/SAVP for the same media profile if the incoming offer SDP has an RTP/AVP media line and an RTP/SAVP media for the same media profile. To prevent multiple identical media lines in the SDP it sends, the E-SBC inspects the incoming SDP to determine whether both RTP/AVP and RTP/SAVP media lines exist for the same media profile. If it finds such a media profile, the E-SBC disables the RTP/SAVP (by setting the port to 0 in the outgoing offer SDP) corresponding to the RTP/AVP media line for that media profile. Doing so forces the UA answering the SDP offer to choose the media lines corresponding to the RTP/SAVP media lines in the incoming offer SDP. An SRTP-SRTP session results.

The incoming offer SDP might look like this:

v=0
o=MxSIP 0 1480968866 IN IP4 192.168.22.180
s=SIP Call
c=IN IP4 192.168.22.180
t=0 0
m=audio 5012 RTP/AVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
m=audio 5010 RTP/SAVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:f0oLKTuMYwXqrKa7Ch+MOBvLe8YnXnD6Kmnj4LQ2

And the outgoing offer SDP will look like this:

v=0
o=MxSIP 0 1480968866 IN IP4 172.16.22.180
s=SIP Call
c=IN IP4 172.16.22.180
t=0 0
m=audio 0 RTP/SAVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
m=audio 6002 RTP/SAVP 0 8 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-1
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:f0oLKTuMYwXqrKa7Ch+MOBvLe8YnXnD6Kmnj4LQ2

any—If the outgoing media security policy associated with a realm has any set as its mode, the E-SBC creates offer SDP based on the value configured in the egress-offer-format, which is set either in the sdes-profile configuration.
- If the value is same-as-ingress, the E-SBC leaves the profile of the media lines unchanged.
- If the value is simultaneous-best-effort, the E-SBC inspects the incoming offer SDP and:
  - Adds an RTP/SAVP media line for any media profile that has only the RTP/AVP media profile
  - Adds an RTP/AVP media line for any media profile that has only the RTP/SAVP media profile
  Should the media profile in the incoming offer SDP already have two media lines (one fore RTP/AVP and on for RTP/SAVP), the E-SBC does not have to make these additions. It will map the media lines in the answer it receives with the media lines from the incoming offer SDP. It will also ensure that media lines in the answer SDP it sends match the media lines from the incoming offer SDP.

Using Security Associations for RTP and RTCP

With RTP and SRTP supported in the same realm, you want to configure your SRTP security policies to preserve system resources. You need to do to avoid session agent interaction that can have an adverse impact on the number of sessions.

To do so, check the local-ip-match-address for the STRP security policy has an IP address different from the all steering pool IP addresses for realms requiring both RTP and SRTP. The E-SBC recognizes this difference automatically and sets the connection address of media lines in SDP accordingly:

The connection address for RTP media lines is the IP address of the applicable steering pool. The E-SBC passes through RTP and RTCP packets sent by and received from the steering pool IP address. This operation requires no reference to session agents because the steering pool address does not match the IP address for the SRTP security policy’s local-ip-address-match value.
The connection address of the SRTP media lines continues to be the local-ip-address-match value from the applicable SRTP security policy.

Since RTP and RTCP packets are sent to and from the steering pool’s IP address (an IP address for which there is no SRTP security policy configured), there is no reason to reference session agents.

ACLI Instructions and Examples

This section shows you how to configure your E-SBC to support secure and non-secure flows in the same realm.

To configure a security policy to support secure and non-secure flows in the same realm:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type security and press Enter.

ORACLE(configure)# security
ORACLE(security)#

Type media-security and press Enter.

ORACLE(security)# media-security
ORACLE(media-security)#

Type media-sec-policy and press Enter. If you are editing a pre-existing configuration, you needs to select it before you can make changes.
```
ORACLE(media-security)# media-sec-policy
ORACLE(media-sec-policy)#
```

Type inbound to enter the setting for inbound flows.

ORACLE(media-sec-policy)# inbound
ORACLE(inbound)#

mode—Enter the mode that you want to use for inbound flows. You can choose from rtp, srtp, and any. Refer to the For Incoming Flows (1082) section Mode Settings in the Media Security Policy (1082) description for details about each value.
protocol—Change this value to none. Use the done command to save your work, and exit the inbound configuration.

Type outbound to enter the setting for inbound flows.

ORACLE(media-sec-policy)# outbound
ORACLE(outbound)#

mode—Enter the mode that you want to use for outbound flows. You can choose from rtp, srtp, and any. Refer to the For Outgoing Flows (1082) section Mode Settings in the Media Security Policy (1082) description for details about each value.
protocol—Change this value from to none. Use the done command to save your work, and exit the outbound configuration.
Type done and continue.

Egress Offer Format for SDES Profile Configuration

To set the egress offer format for an SDES profile configuration:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type security and press Enter.

ORACLE(configure)# security
ORACLE(security)#

Type media-security and press Enter.

ORACLE(security)# media-security
ORACLE(media-security)#

Type sdes-profile and press Enter. If you are editing a pre-existing configuration, you needs to select it before you can make changes.
```
ORACLE(media-security)# sdes-profile
ORACLE(sdes-profile)#
```
egress-offer-format—Choose an egress offer format for this profile to use when you set the outbound mode in the media security policy to any. You can select one of two values:
- If the value is same-as-ingress (default), the E-SBC leaves the profile of the media lines unchanged.
- If the value is simultaneous-best-effort, the E-SBC inspects the incoming offer SDP and:
  - Adds an RTP/SAVP media line for any media profile that has only the RTP/AVP media profile
  - Adds an RTP/AVP media line for any media profile that has only the RTP/SAVP media profile
Type done to save your work and continue.

To set the egress offer format for an SDES profile configuration:
In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type security and press Enter.

ORACLE(configure)# security
ORACLE(security)#

Type media-security and press Enter.

ORACLE(security)# media-security
ORACLE(media-security)#

egress-offer-format—Choose an egress offer format for this profile to use when you set the outbound mode in the media security policy to any. You can select one of two values:
- If the value is same-as-ingress (default), the E-SBC leaves the profile of the media lines unchanged.
- If the value is simultaneous-best-effort, the E-SBC inspects the incoming offer SDP and:
  - Adds an RTP/SAVP media line for any media profile that has only the RTP/AVP media profile
  - Adds an RTP/AVP media line for any media profile that has only the RTP/SAVP media profile
Type done to save your work and continue.

Supporting UAs with Different SRTP Capabilities

To support UAs with different levels of SRTP capabilities, the use-ingress-session-params parameter appears in the sdes-profile configuration. The values for this parameter allow the Oracle® Enterprise Session Border Controller to accept and (where applicable) mirror the UA’s proposed cryptographic session parameters:

srtp-auth—Decides whether or not authentication is performed in SRTP
srtp-encrypt—Decides whether or not encryption is performed in SRTP
srtcp-encrypt—Decides whether or not encryption is performed in SRTCP

Using these possible values, the Oracle® Enterprise Session Border Controller accepts the corresponding incoming session parameters.

Receiving Offer SDP

When the Oracle® Enterprise Session Border Controller receives offer SDP with applicable session parameters, it uses the same session parameters in its answer SDP (if it can support the same). This is true even if the value for that session parameter differs from the available media security profile.

Consider this example: An SDES profile is applied for incoming direction for a media security policy configured with the srtcp-encrypt value set to enabled. With the use-ingress-session-params parameter set to srtcp-encrypt for the SDES profile, the Oracle® Enterprise Session Border Controller accepts the offer SDP and also sets UNENCRYPTED_SRTCP for the cryptographic attributes in its answer SDP. When the call connects, the Oracle® Enterprise Session Border Controller does not encrypt or decrypt SRTCP packets. Without the SDES profile set this way, the Oracle® Enterprise Session Border Controller would reject offer SDP if any of its cryptographic attributes showed UNENCRYPTED_SRTCP in its session parameters list.

Receiving Answer SDP

When the Oracle® Enterprise Session Border Controller receives answer SDP with the accepted session parameter, the value for the same session parameters that the Oracle® Enterprise Session Border Controller uses might or might not be the same as the incoming value. Configuration of the outbound media security profile controls the value used because the Oracle® Enterprise Session Border Controller makes offer SDP, which cannot be changed, with the session parameters based on the outgoing media security profile.

Consider this example: An SDES profile is applied for incoming direction for a media security policy configured with the srtcp-encrypt value set to enabled, so the cryptographic attributes in the SDP the Oracle® Enterprise Session Border Controller sends do not have the UNENCRYPTED_SRTCP session parameters. If the UNENCRYPTED_SRTCP appears in the corresponding answer SDP it receives, the Oracle® Enterprise Session Border Controller accepts it if the srtcp-encrypt value appears in the use-ingress-session-params parameter. But the Oracle® Enterprise Session Border Controller still performs SRTCP encryption. When the call connects, the Oracle® Enterprise Session Border Controller encrypts outgoing SRTCP packets but does not decrypt incoming SRTCP packets. So if the UA (receiving the Oracle® Enterprise Session Border Controller’s offer SDP) does not support SRTCP decryption, it will likely reject the offer SDP.

ACLI Instructions and Examples

To set the ingress session parameters for an SDES profile configuration:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type security and press Enter.

ORACLE(configure)# security
ORACLE(security)#

Type media-security and press Enter.

ORACLE(security)# media-security
ORACLE(media-security)#

Type sdes-profile and press Enter. If you are editing a pre-existing configuration, you needs to select it before you can make changes.
```
ORACLE(media-security)# sdes-profile
ORACLE(sdes-profile)#
```
use-ingress-session-params—Enter the list of values for which the Oracle® Enterprise Session Border Controller will accept and (where applicable) mirror the UA’s proposed cryptographic session parameters:
- srtp-auth—Decides whether or not authentication is performed in SRTP
- srtp-encrypt—Decides whether or not encryption is performed in SRTP
- srtcp-encrypt—Decides whether or not encryption is performed in SRTCP
```
ORACLE(sdes-profile)# use-ingress-session-params srtp-auth srtp-encrypt srtcp-encrypt
```
Type done to save your work and continue.

Refining Interoperability

To refine any remaining interoperability issues, you can use the options parameter in the media-sec-policy and sdes-profile configurations.

Common values to configure an option are include-local-id and include-remote-id.

include-local-id—The Oracle® Enterprise Session Border Controller includes the IDi in the I_MESSAGE and the IDr in the R_MESSAGE.
When used for the outbound direction of a media security policy, the IDi is included in the I_MESSAGE the Oracle® Enterprise Session Border Controller sends. The content of the IDi is the value of the Contact header found in the INVITE message.
include-remote-id—The system includes the IDr in the I_MESSAGE.

Refining Interoperability Configuration

You can configure these options for media-sec-policy, sdes-profile, and mikey-profile configurations. The following uses the mikey-profile to demonstrate how to enter them.

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type security and press Enter.

ORACLE(configure)# security
ORACLE(security)#

Type media-security and press Enter.

ORACLE(security)# media-security
ORACLE(media-security)#

Type mikey-profile and press Enter. If you are editing a pre-existing configuration, you needs to select it before you can make changes.
```
ORACLE(media-security)# mikey-profile
ORACLE(mikey-profile)#
```
options——Your entry will look like this when you add both values:
```
ORACLE(mikey-profile)# options include-local-id, include-remote-id
```
You can you the plus sign (+) and the minus sign (-) to add and remove values from the options list.

To remove an value, your entry would look like this:
```
ORACLE(mikey-profile)# options -include-local-id
```
To add an value, your entry would look like this:
```
ORACLE(mikey-profile)# options +include-local-id
```