Definitions and acronyms

Inbound Call Flow

• A customer calls into the contact center, and the call lands on the SBC from the carrier.
• The SBC invites the contact center (an Avaya Aura platform, for example).
• A routing script sends the call back out to the SIP number provisioned in Mindful, using a new SIP INVITE to the SBC.
• The SBC sends an INVITE to Mindful and the customer hears a callback offer.

Choose Hold Call Flow

• A customer declines a callback offer. Mindful sends a SIP REFER to the SBC with a refer-to header containing the number of the contact center (typically a queueing DN).
• The SBC invites the contact center (an Avaya Aura platform, for example).
• The call queues at normal inbound priority for the next agent.

Return Call (Callback) Call Flow

• Mindful sends an INVITE to the SBC using the customer callback number as the destination.
• The SBC sends the call out to the customer over the PSTN.
• Once the customer answers the call, Mindful sends another INVITE to the SBC with the Callback Number configured in Mindful. This is usually the number of a contact center DN (such as an Avaya Communication Manager VDN)
• The SBC invites the contact center and the call queues at high priority for the next agent. As soon as an agent answers, the customer and agent are connected, and Mindful steps out of the SIP signaling path.

Option 1: Standard SIP & RTP

The steps in this section should be performed whether you intend to use standard SIP and RTP, or you intend to use Secure SIP over TLS. These steps lay the groundwork for the integration, which can be built upon later for additional security.

Configure a Firewall (if applicable)

If there is a firewall in front of the SBC, new rules should be created to allow traffic between the SBC and Mindful, adding the Mindful Callback signaling (SIP) and media (RTP) IP addresses.

The Mindful Solution Delivery Team will provide a /24 range of IP addresses, of which some IPs are set aside for signaling and the remaining IPs for media. These may be added into a single rule/policy or split into separate signaling and media rules/policies as required by your security team.

Baseline SBC Configuration

Baseline configuration for the SBC should already be configured. Physical Interfaces, Network Interfaces, and Media Manager should be enabled to allow steering of the voice media between Realms within the SBC.

Realm Configuration

Quick access: Configuration > media-manager > realm-config

A Realm is a network, or a collection of networks or addresses used by the SBC for communicating with those elements over a shared connection. A basic SBC configuration may typically contain two or more realms--one for external SIP entities (such as the telephony service carrier and Mindful) and one for internal SIP entities (ACD, PBX, and IVR). The following image shows an example:

Before starting with the SBC configuration for Mindful, determine whether an existing Realm will be used or if a new Realm should be created. In this guide, an existing Realm--the Realm named Public currently used for calls to and from the SIP provider--is also used for the Mindful.

The Realm can be configured with default values, selecting a network interface to be used for calls inbound and outbound to and from the Realm, and it is recommended that the Access Control Trust Level be set to high:

Depending on your NAT configuration, some Manipulations may also be set in the configuration for this Realm. See the NAT configuration section for more details.

Create a New SIP Manipulation

Quick Access: Configuration > session-router > sip-manipulation

The Mindful SIP Router validates and routes incoming SIP INVITEs using a custom SIP header called X-Mindful-Routing-Token. When your Mindful Organization is set up by the Solution Delivery team, the routing token will be provided, and this needs to be sent as the value of the new X-Mindful-Routing-Token SIP header in the INVITE to Mindful Callback.

In the SBC, this can be accomplished using a SIP Manipulation, which allows manipulation of the SIP/SDP headers, using rules created under a single Manipulation entry.

If there is an existing SIP Manipulation in use with calls to Mindful, use that one rather than creating a new one.

If there is not an existing SIP Manipulation for calls to Mindful, create a new one by following the steps below:

• Select sip-manipulation from the side menu.
• Click Add to open the Add SIP Manipulation page.
• Name the Manipulation something like toMindfulCallback:

• In the CfgRules field, click Add and select header-rule:

• Configure the Add SIP Manipulation / Header Rule page as shown below:

• Name: Enter a name for the rule (such as AddRoutingToken)
• Header Name: Enter X-Mindful-Routing-Token
• Action: Select add
• Comparison Type: Select case-sensitive
• Msg Type: Select any
• Methods: Click in the field and add INVITE
• New Value: Enter your Mindful Routing Token

Once the new header rule is added, click OK to add the rule, and then click OK again to add the new or modified SIP Manipulation.

SIP Interface Configuration

Quick Access: Configuration > session-router > sip-interface

The SIP Interface will be configured with one or more SIP ports, using the IP address of the network interface configured in the associated Realm. For example:

Mindful Callback does not support SIP over TCP, unless using TLS (see the TLS section in this guide). Thus, for standard SIP communication with Mindful, a SIP port using UDP must be configured for this interface. This can be configured in addition to any existing SIP ports using other transport protocols on the same interface.

By default, the SBC has a maximum limit of 1,500 bytes (MTU size) for the packet size when using UDP, and any SIP requests exceeding this may result in call failure. To avoid this, the option max-udp-length=0 can be configured on the SIP Interface or Realm:

This option allows SIP messages exceeding the MTU size to be fragmented, in which case the far-end SIP entity (Mindful) will re-assemble these fragmented packets. This setting may be required on both external and internal SIP Interfaces or Realms.

The remainder of the SIP Interface configuration can be left with default values, although it is recommended to set the Proxy Mode to Proxy and the Trust Mode to all. Some additional steps may be required for NAT configuration. See the NAT configuration section in this guide for more details.

Session Agent Configuration

Quick access: Configuration > session-router > session-agent

The session agent is a SIP endpoint that defines the target address (FQDN or IP address), port, signaling protocol (SIP or H.323), transport protocol, and Realm used when sending SIP messages to that endpoint.

A new Session Agent must be created for Mindful. On the Session Agent page, click New Session Agent at the top of the session-agent list. Coinfigure the Mindful Session Agent as shown below:

• Hostname: Enter the Mindful Callback SIP domain.
• Port: Enter 5060 (or 5061 for TLS).
• State: Enable the Session Agent.
• Transport Method: Select UDP.
• Realm ID: Select the Realm used for Mindful (Public in our example).
• Refer Call Transfer: Enable this to allow the SBC to handle the SIP REFER that is sent by Mindful Callback if the caller declines the callback offer, to send the call back into queue.
  • Instead of passing the REFER through to the contact center, the SBC terminates the REFER and sends an INVITE to the contact center using the refer-to header of the REFER.

The hostname may be different in your integration. The Mindful Solution Delivery team will provide the correct hostname for your Mindful Organization. Additionally, take note of the port. It is usually 5060 for Mindful Callback using standard SIP, and 5061 when using TLS.

Select the new SIP Manipulation as the Out Manipulationid configured previously in this guide:

Once configured, click OK to save the new Session Agent. You will be returned to the list of Session Agents, not including the newly created one.

Local Policy Configuration

Quick Access: Configuration > session-router > local-policy

The local-policy section contains a set of rules that define how calls are routed within the SBC, using the from address, the to address, or the Realm. For Mindful, a new Local Policy must be created to send calls destined for Mindful Callback to the new Mindful Session Agent target.

To create a new entry, on the page containing the list of local policies, click New. Configure the Add Local Policy page as shown:

• From Address: This can be anything (using the * wildcard)
• To Address: Enter the five-digit prefix used in the nine-digit SIP numbers provisioned in your Mindful Organization.
  • The Mindful Solution Delivery team can provide the prefix to be configured here.
• Source Realm: Enter any Realm from which calls to Mindful can originate.
  • In this example, calls to Mindful will only originate from the Private Realm (the contact center), but multiple Realms or even a wildcard * can be added here.

Before saving the new policy, a Policy attribute must be defined to determine what action to take when the policy is triggered. To add a policy attribute to the new local policy, click Add in the Policy Attributes field to open the Add Local Policy / Policy Attribute page. Configure the policy attribute as shown:

• Next Hop: Select the Mindful Session Agent created previously.
• Realm: Select the Realm used in sending calls out to Mindful.
• State: Enable the policy attribute.
• App Protocol: Select SIP.
• Lookup: Select single.

Once configured, click OK to save the Policy Attribute, and then click OK again to save the Local Policy.

In addition to creating the local policy for Mindful, the other local policies involved in the Mindful Callback flow may also need to be modified. The existing local policy that sends calls out to the SIP Provider should be configured so that calls from Mindful are also included as the Source Realm in that policy. For example, the screenshot below shows the local policy used for calls starting with a 1 or +1 that go out to the SIP provider configured to use any Source Realm.

When Mindful places a call to a customer, it sends an INVITE to the SBC using the e164 number format (for example, +1 for the North American region). Configure the SBC to route those calls out to the SIP Provider. If you already have Translation rules which add a + prefix on the SIP provider Session Agent, this translation should not be applied to customer calls from Mindful (unless a Translation rule to strip the plus (+) from the customer calls from Mindful is applied to the Mindful Session Agent).

Finally, make sure that calls to the contact center also include agent-leg calls from Mindful :

This example shows that calls to the contact center (DNs starting with 400) can be routed from the Public Realm (from Mindful).

SBC Behind NAT configuration

If the Oracle E-SBC is behind a NAT device, some kind of translation needs to occur to ensure that public IPs are used in SIP messages to external entities (such as SIP Provider and Mindful Callback) and that the public IP is replaced with the private IP on SIP messages from those entities. Some NAT devices use packet inspection (such as SIP ALG) to rewrite the IP addresses inside the SIP messages. Using that usually means no NAT translation is required inside the SBC. However, not all NAT devices support packet inspection, and this method does not generally support encrypted SIP due to the NAT device being unable to open the encrypted packets.

For situations where the SBC is behind a NAT device, and not using packet inspection, there are several ways to handle NAT translation within the Oracle E-SBC itself. In the following example, a built-in SPL plug-in is used to translate the SIP VIA and SDP/Connection (c-line) headers to use the SBC's public IP, and a built-in SIP Manipulation rule set is used to translate the To and From headers in each direction using the public Realm. Your SBC may already be configured with NAT rules if it is behind a NAT device, in which case, the same configuration should be applied to the Mindful Callback configuration within the SBC.

Using the built-in SPL plugin

Oracle E-SBC includes a built-in SPL (SBC Processing Language) plugin called the Support for SBC Behind NAT plugin. Details on how this is configured and how it works can be found in the official Oracle documentation. At a high level, the plugin basically allows the private and public IP addresses of the external interface to be swapped in each direction.

To use this built-in plugin, add the following to the SPL Options of the SIP Interface used for Mindful Callback, replacing 8.8.100.100 with the SBC's public IP address, and replacing 10.10.10.10 with the internal/private IP of that interface:

HeaderNatPublicSipIfIp=8.8.100.100,HeaderNatPrivateSipIfIp=10.10.10.10

Using the above example, this means that when a SIP message is sent out through this SIP Interface with a private IP address of 10.10.10.10, the SBC will rewrite that IP with public IP 8.8.100.100 on the VIA and SDP/Connection headers. In the opposite direction, when a SIP message comes into this interface, the public IP 8.8.100.100 is rewritten as private IP 10.10.10.10 in the VIA and SDP/Connection headers.

Using the Built-in NAT SIP Manipulation

The Oracle E-SBC contains a built-in SIP Manipulation called ACME_NAT_TO_FROM_IP. This Manipulation cannot be viewed from the UI, although using the command show built-in-sip-manipulations from the ACLI will show the Manipulation with a short description.

This Manipulation replaces the host part of the From header in a SIP message with the IP of the outbound SIP Interface, and the Host part of the To header with the IP or hostname of the destination SIP entity.

To use the Manipulation, it can be assigned to both the In-ManipulationId and Out-ManipulationId properties in either a Session Agent, Realm, or SIP Interface:

Note that the built-in Manipulation rule will not be shown in the drop-down list, so the name of the Manipulation must be typed into the ManipulationId fields.

Correcting the Request URI for Choose Hold Transfers

In some environments, when a caller declines the callback offer and Mindful sends a REFER to the SBC, the Oracle E-SBC terminates the REFER and issues an INVITE into the contact center. However, the request-uri SIP header in this INVITE may contain the SBC's public IP instead of the IP of the target SIP entity.

If this occurs in your environment, this can be corrected by creating a simple SIP Manipulation and applying it to the contact center Session Agent. An example is shown below:

Quick Access: Configuration > session-router > sip-manipulation

• Click New to open the Add SIP Manipulation page.
• Give the SIP Manipulation a name (such as SET-RequestURI).
• In the CfgRules section, click Add and select header-rule:

The Add SIP Manipulation / Header Rule page will open. Configure this page as shown below:

• Name: Enter a descriptive name, such as requesturi.
• Header Name: Enter request-uri.
• Action: Select manipulate.
• Comparison Type: Select case-sensitive.
• Msg Type: Select any.

This header rule is used to modify the request-uri SIP header, but since it is only part of the header that is to be changed, an element rule needs to be added to this header rule. Under CfgRules, click Add and select element-rule:

The Add SIP Manipulation / Header Rule / Element Rule page will open. Configure this page as as shown below:

• Type: Select uri-host.
• Action: Select replace.
• Match Val Type: Select any.
• Comparison Type: Select case-sensitive.
• New Value: Enter the built-in variable $REMOTE_IP, which contains the destination IP address or host.

Click OK to return to the header rule, then click OK again to return to the SIP Manipulation rule, then a final OK to save the new rule.

This rule can be applied to the Out Manipulationid parameter of the contact center Session Agent now, as well. When in place, this will ensure that any SIP INVITE to the contact center using this Session Agent will have the correct RequestURI host/IP value.

The Oracle SBC configuration is now complete and ready for testing! Save and Activate the configuration before testing. In the next section, we will discuss updates for SIP over TLS with SRTP.

Option 2: SIP over TLS with SRTP

To secure the SIP and RTP traffic between the SBC and Mindful, some additional configuration needs to be performed on the SBC. This should only be performed after completing the steps in the previous section. We recommend taking a backup of the current SBC configuration before making the following configuration changes. This way. the configuration can be quickly reverted in case of issues arising from the TLS & SRTP implementation.

Download the Entrust Intermediate Root CA certificate

Mindful Callback uses certificates signed by the Certificate Authority (CA) Entrust to provide secure SIP connections. Since the Oracle SBC requires the Intermediate Root CA certificate, this must be downloaded before importing into the new Certificate Record. To download the required certificates, visit https://www.entrust.com/resources/certificate-solutions/tools/root-certificate-downloads.

Note that the G2 certificates are used with Mindful Callback, so download the (Non-EV SSL) CA – L1K Chain/Intermediate certificate as highlighted here:

Verify the Existing End-entity Certificate

Quick Access: Configuration > security > certificate-record

Before creating a new Entrust Certificate Record, confirm that that the SBC has an end-entity Certificate Record configured. The end entity certificate is the server certificate presented by the SBC during TLS handshakes with other TLS enabled SIP devices.

To confirm this, navigate to the Certificate Record configuration section and the end-entity Certificate Record should be listed. There may be more than one entry if records are created for different SIP Interfaces. Below is an example showing a single entry containing an end-entity certificate for the SBC's public interface:

If no end-entity certificate exists, follow the official Oracle Enterprise SBC documentation to create a new record and generate a Certificate Signing Request (CSR), then have that CSR signed by a Certificate Authority. After that, import the resulting signed certificate into the SBC end-entity Certificate Record.

Create a new Entrust Certificate Record

Quick Access: Configuration > security > certificate-record

After verifying the end-entity Certificate Record, a new Certificate Record must be created for the Entrust Intermediate CA certificate. On the Certificate Record page, click New to add a new record. The following example uses the default values when a new Certificate Record is created:

• Name: Enter a name for the record, such as EntrustIntermediate.
• Country, State, Locality: Set these as required for your locality.
• Key Size, Trusted, Key Usage List, Algorithm parameters: Leave these at their default values.

When finished, click OK to save the new Certificate Record.

Import the Entrust Intermediate Root Certificate into the new Certificate Record

Quick Access: Configuration > security > certificate-record

To import the certificate, select the new Entrust Certificate Record and click Import:

This will open an Import Certificate page:

• Format: Select try-all or x509.
• Import Method: Select File.
• Click Upload, then select the entrust_l1k.cer file downloaded earlier.
• Click Import to import the certificate. The certificate should now be imported into the Certificate Record.

The imported certificate cannot be displayed in the Oracle Web UI. However, you can verify it in the ACLI by using the show security certificates brief command as shown in this example:

Here we can see the Mindful Callback Intermediate CA certificate in the Mindful Certificate Record. Your end-entity certificate will also be listed (not shown in this example).

Create a new TLS Profile (or Amend an Existing Profile)

Quick Access: Configuration > security > tls-profile

Now that the Entrust Certificate Record has been created and the Entrust Intermediate CA record imported, the new record should be associated with a TLS Profile. If you already have a TLS Profile associated with the SIP Interface used for communication with Mindful, this record can be amended to include the Entrust Intermediate Certificate Record as a trusted entity. If no TLS profile exists, a new one should be created.

To create a new profile, click New on the TLS Profile page and configure the profile as shown below:

• Name: Enter a name, such as TLSProfile1.
• End Entity Certificate: Select your end-entity Certificate Record.
• Trusted CA Certificates: Select the trusted certificate created earlier.
  • If you are modifying an existing TLS Profile, this may already contain one or more trusted certificates. If so, add the new Entrust Certificate Record to the existing trusted list.
• Verify Depth: Set this to at least 2 (the default value of 10 is fine).
• Mutual Authenticate: Leave this unselected.
• TLS Version: Select tlsv12.
• Allow Self Signed Cert: Select the checkbox.

When finished, click OK to save the TLS Profile.

Modify the SIP Interface with a TLS entry

Quick Access: Configuration > session-router > sip-interface

Now that the new TLS Profile has been created (or an existing TLS profile modified), the SIP Interface used for Mindful Callback SIP communication should have a SIP port configured to use this TLS profile. If your SIP Interface already contains a port entry for TLS using an existing TLS profile (modified in the previous section), you do not need to do anything here. However, if no TLS entry exists on the SIP Interface, a new one should be added.

To add a new TLS port using the new TLS profile, Modify the SIP Interface used for Mindful Callback SIP communication, and under SIP Ports, click New. Configure the SIP Port as shown below, using the IP address associated with the SIP Interface, the TLS port (such as 5061, which is the default SIP port for TLS), and selecting the TLS profile created or modified in the previous section:

Click OK to save the new SIP port. The Ports section for the SIP Interface may now contain one or more Port entries, as seen in the following example:

This example shows both TLS and UDP ports – if the SIP Interface in your environment should only support TLS, the UDP entry may not be required.

Modify the Mindful Session Agent to use TLS

Quick Access: Configuration > session-router > session-agent

The previously created Session Agent needs to be modified to use TLS. To do this, edit the Session Agent and change the following values:

• Port: Change the port to 5061 (the Mindful Callback SIP TLS port).
• Transport Method: Change to StaticTLS.

Once configured, click OK to save the modified Session Agent.

Configure Media Security (Step 1: Create a New SDES Profile)

Quick Access: Configuration > security > [SHOW ALL] > media security > sdes-profile

To use secure audio (SRTP) with SIP over TLS, some media security configuration needs to be updated and associated with the Realm. Note that this may already be in place in your environment. This guide assumes no policy is configured for that Realm.

The first configuration is the SDES profile, which defines some crypto parameters and egress offer format. To open the Media Security section in the web UI, the Show All toggle switch should be enabled to show the normally hidden Media Security section. When Show All is enabled, you will see the list of hidden configuration areas, including the Media Security section, as shown below.

Open the sdes-profile section and use the New button to create a new SDES profile as shown below:

• Name: Give the profile a name, such as SDES.
• Crypto List: Ensure that AES_CM_HMAC_SHA1_80 and AES_CM_HMAC_SHA1_32 are present.
• Srtp Auth, Srtp Encrypt, SrTCP Encrypt: Select all three checkboxes.
• Egress Offer Format: Select rfc5939-compliant.
  • If same-as-ingress is used, then the call flow may fail if the calls coming into the SBC do not also use TLS/SRTP. This is because the SBC will use the same RTP or SRTP capabilities for the INVITE to Mindful.

When finished, click OK to save the SDES profile.

Configure Media Security (Step 2: Create a New Media Security Policy)

Quick Access: Configuration > security > [SHOW ALL] > media security > media-sec-policy

Once the SDES profile is configured, a Media Security Policy should be created to use the SDES profile. As with the SDES Profile, the Media Sec Policy configuration is hidden by default in the SBC Web UI, and the Show All toggle switch should be set to show the hidden Media Security section.

On the Media Sec Policy page, use the New button to create a new Media Security Policy, then configure it as shown below:

• Name: Give the policy a name, such as PublicMediaSec if this policy will be associated with the public Realm.
• Use the following for both the Inbound and Outbound sections:
  • Profile: Select the SDES profile created in the previous section.
  • Mode: Select any (or srtp if only SRTP is supported with the Realm)
  • Protocol: Select sdes.

Associate the Media Security Policy with the Realm

Quick Access: Configuration > media-manager > realm-config

The final step to configure the SRTP is to associate the Media Security Policy with the SBC Realm used in communication with Mindful.

From the Realm Config page, edit the Realm used for Mindful (for example, the Public Realm). On the Modify Realm Config page, select the Media Security Policy created in the previous section, as shown in this example:

Once the Realm has been configured with the Media Security Policy, click OK to save the changes.

The TLS and SRTP configuration is now complete and ready for testing! Remember to Save and Activate the configuration when finished.