Components and call flows

Before looking at configuration, you can expand the content below to review key terms and acronyms used throughout this guide.

Definitions and acronyms

Inbound call flow

1. A customer calls into the contact center. The call lands on the CUBE from the carrier.
2. CUBE sends a SIP INVITE to the contact center (Cisco CUSP, CVP, CUCM, Genesys SIP Server, etc.).
3. A routing script sends the call back out to the SIP number provisioned in Mindful Callback, either using a new INVITE or a REFER back to the CUBE.
4. CUBE sends an INVITE to Mindful Callback and the customer hears the callback offer.

Callback call flow

CUBE customer-first callback call flow

1. Mindful Callback sends an INVITE to CUBE using the customer callback number as the destination.
2. CUBE sends the call to the customer over the public telephone network.
3. When the customer answers the call, Mindful Callback sends another INVITE to CUBE with the Call Center Phone Number of the Call Target in Mindful Callback. This is usually a contact center DN.
4. CUBE invites the contact center and the call queues at high priority for the next agent. When an agent answers, the customer and agent are connected. At that point, Mindful Callback steps out of the signaling path.

Basic configuration for standard SIP and RTP

The basic configuration is required whether you will use standard SIP and RTP, or SIP over TLS with SRTP. This section covers the following steps to establish standard SIP and RTP communication:

1. Configure your firewall
2. Allow Mindful Callback SIP proxy IP addresses
3. Create Mindful Callback URI containers
4. Create SIP Profiles to convert between private and public IP addresses
5. Configure Dial Peers

1. Configure your firewall

If there are any firewalls between the CUBE and Mindful Callback, the SIP and RTP proxy IP addresses (as provided by the Mindful team in the Mindful Callback SIP questionnaire) must be whitelisted against the CUBE's public IP in those firewalls. If you use TLS as the SIP transport protocol, we also recommend that firewall SIP ALG (packet inspection) be disabled for this traffic.

2. Allow Mindful Callback SIP proxy IP addresses

CUBE maintains a trusted list of IP addresses to validate the remote IPs of incoming VoIP calls. You will need to add the Mindful Callback SIP Proxy IP addresses (as provided in the Mindful Callback SIP questionnaire) to the allowed list using the config command ip address trusted list followed by a list of IPs. Following is an example showing two IP addresses being added to the IP address trusted list:

#conf term
         voice service voip
         ip address trusted list
         ipv4 x.x.x.x
         ipv4 x.x.x.x

3. Create Mindful Callback URI containers

So that calls coming into the CUBE from Mindful Callback can be identified using a single Dial Peer, a URI container should be created. The configuration below shows an example of how to create a URI container containing the same two example Mindful Callback IP addresses added to the trusted list above.

#conf term
        voice class uri 10 sip
        host ipv4: x.x.x.x
        host ipv4: x.x.x.x

4. Create SIP Profiles to convert between private and public IP addresses

This will typically result in call failure between the CUBE and Mindful Callback (or no/one-way audio). If the CUBE has an interface configured with the public IP, or if the CUBE is behind a firewall that has SIP ALG enabled (where the firewall will take care of rewriting the IPs within the SIP headers/SDP), this section can be ignored.

If the CUBE is using a NAT IP address and SIP ALG is not enabled, you will need to create two SIP Profiles--one inbound and one outbound--which contain a set of rules to rewrite the CUBE's private IP as the public IP and vice versa, as the SIP messages traverse between the CUBE and the Mindful Callback SIP proxies. If the CUBE is already configured against an external SIP entity, such as a telephony service provider (carrier), a SIP Profile performing this function may already exist.

Here is an example of how to create the SIP Profiles (number 10 for the outbound profile and 20 for the inbound profile in this example) that will rewrite the IPs as needed:

#conf term
        voice class sip-profiles 10
         request ANY sip-header X-Mindful-Routing-Token add "X-Mindful-Routing-Token: <token>"
         response ANY sip-header Contact modify "10.10.0.1" "8.2.2.2"
         request ANY sip-header Contact modify "10.10.0.1" "8.2.2.2"
         response ANY sip-header From modify "10.10.0.1" "8.2.2.2"
         request ANY sip-header From modify "10.10.0.1" "8.2.2.2"
         response ANY sip-header Via modify "10.10.0.1" "8.2.2.2"
         request ANY sip-header Via modify "10.10.0.1" "8.2.2.2"
         request ANY sdp-header Audio-Connection-Info modify "10.10.0.1" "8.2.2.2"
         response ANY sdp-header Audio-Connection-Info modify "10.10.0.1" "8.2.2.2"
         request ANY sdp-header Connection-Info modify "10.10.0.1" "8.2.2.2"
         response ANY sdp-header Connection-Info modify "10.10.0.1" "8.2.2.2"
         request ANY sdp-header Session-Owner modify "10.10.0.1" "8.2.2.2"
         response ANY sdp-header Session-Owner modify "10.10.0.1" "8.2.2.2"

In this example, the CUBE's private IP is 10.10.0.1, and the public IP is 8.2.2.2.

#conf term
        voice class sip-profiles 20
         response ANY sip-header Contact modify "8.2.2.2" "10.10.0.1"
         request ANY sip-header Contact modify "8.2.2.2" "10.10.0.1"
         request ANY sip-header SIP-Req-URI modify "8.2.2.2" "10.10.0.1"
         request ANY sip-header SIP-Req-URI modify "8.2.2.2" "10.10.0.1"
         response ANY sdp-header Audio-Connection-Info modify "8.2.2.2" "10.10.0.1"
         response ANY sdp-header Connection-Info modify "8.2.2.2" "10.10.0.1"
         request ANY sdp-header Audio-Connection-Info modify "8.2.2.2" "10.10.0.1"
         request ANY sdp-header Connection-Info modify "8.2.2.2" "10.10.0.1"

This profile does the reverse, for calls coming into the CUBE from Mindful Callback. This profile is used to rewrite the headers back from public IP to private IP. This is required for callbacks when the customer and agent are connected. Without this configuration, the CUBE will try to establish media connections between its own private and public IPs, resulting in no audio or one-way audio.

These two profiles will be used with the Mindful Callback Dial Peers shown later in this guide.

5. Configure Dial Peers

Multiple Dial Peers may be used in the Mindful Callback call flow after the inbound call arrives at the contact center, depending on the existing Dial Peer configuration.

CUBE Dial Peers

Incoming Dial Peers

• An incoming Dial Peer for calls coming into the CUBE from your telephony platform (such as CUCM or CVP) heading to Mindful Callback.
• An incoming Dial Peer for agent-leg calls coming into the CUBE from Mindful Callback.
• An incoming Dial Peer for customer-leg and agent-leg calls from Mindful Callback.

Outgoing Dial Peers

• An outgoing Dial Peer for calls leaving the CUBE and heading to Mindful Callback.
• An outgoing Dial Peer for agent-leg calls heading to the telephony platform.
• An outgoing Dial Peer for customer-leg callbacks that will leave the CUBE heading to the public telephone network to call the customer.

Some of these Dial Peers may already exist in your CUBE, particularly those to and from the PSTN (SIP or POTS) and those to and from the contact center. The two Dial Peers that will need to be created for the Mindful Callback call flow are those to and from the Mindful Callback SIP proxies (marked in light and dark blue in the diagram and described below).

Outgoing Dial Peer to Mindful Callback

Create an outgoing Dial Peer that matches the SIP number range provided by the Mindful team. This will typically be a nine-digit number range (for example, 257550000 to 275509999). Following is an example of configuration for an outgoing Dial Peer to Mindful Callback.

#conf term
        dial-peer voice 25755 voip
         description outgoing calls to Mindful Callback
         destination-pattern 25755....
         session protocol sipv2
         session target dns:sip-callback.getmindful.com:5060
         session transport udp
         voice-class sip early-offer forced
         voice-class sip profiles 10
         voice-class sip pass-thru headers unsupp 
         dtmf-relay rtp-nte
         codec g711ulaw
         no vad

Key parameters include:

• Destination-pattern 25755….: This parameter specifies the number pattern that will be used to match calls to send out of the CUBE using this Dial Peer. In this case, any call with a nine-digit destination number starting with 25755 will match this Dial Peer.
• session target dns:sip-callback.mindful.cx:5060: This parameter is used to send a SIP INVITE to the Mindful Callback SIP proxy DNS name. Make sure that sip-callback.mindful.cx can be resolved by the CUBE.
• voice-class sip profiles 10: This references the SIP Profile created earlier and may not be required.
• voice-class sip pass-thru headers unsupp: This is only required when using custom SIP headers to pass user data to Mindful Callback (only supported on IOS 15.4(1)T or higher).
• session transport udp: Mindful Callback only supports UDP for unsecure SIP, so this parameter may not be required if CUBE is using UDP as the default signaling protocol.
• dtmf-relay rtp-nte: All DTMF between Mindful Callback and CUBE should use RFC2833 (RTP events). This parameter may not be required if CUBE has this set globally.
• codec g711ulaw: We recommend using the g711u codec for audio. This parameter may not be required if CUBE has g711u set as a preferred codec globally.

Note that if the CUBE is configured with multiple interfaces that can be used for signaling, the relevant bind parameters should also be added to the Dial Peers. See the following example (assuming GigabitEthernet2 is the interface used for calls going outside of the local network):

voice-class sip bind control source GigabitEthernet2
        voice-class sip bind media source GigabitEthernet2

Incoming Dial Peer from Mindful Callback

This incoming Dial Peer will catch calls coming into the CUBE from Mindful Callback with the incoming called-number parameter matching the range of the contact center queues (Cisco UCCE Dialed Numbers, UCCX Trigger DNs, Genesys Routing Points, etc.).

If no incoming Dial Peer exists, calls may still work (using a default incoming Dial Peer instead), but this Dial Peer may be needed if a SIP Profile was configured in a previous step to convert between private and public IP addresses.

Following is an example configuration for this Dial Peer:

dial-peer voice 10 voip
         description Incoming from Mindful Callback
         session protocol sipv2
         incoming uri via 10
         voice-class codec 10
         voice-class sip profiles 10
         voice-class sip profiles 20 inbound
         voice-class sip pass-thru headers unsupp
         dtmf-relay rtp-nte
         no vad

Key parameters include:

• incoming uri via 10: In this example, this matches calls coming in from Mindful Callback based on the Via sip header. The host IP in the Via from Mindful Callback will match one of the SIP proxy IP addresses added into the URI container earlier in this guide.
• voice-class sip profiles 10: This references the SIP profile created earlier in this guide and may not be required.
• voice-class sip profiles 20 inbound: This references the inbound SIP profile created earlier and may not be required.
• dtmf-relay rtp-nte: To facilitate DTMF between Mindful Callback and the customer, RFC2833 (rtp event, known in Cisco IOS as rtp-nte) should be used between Mindful Callback and CUBE.

Additional configuration for SIP over TLS with SRTP

To secure the SIP and RTP traffic between the CUBE and Mindful Callback, you will need to configure a few more items.

1. Enable TLS 1.2.
2. Configure Trustpoints (and import the Mindful Callback intermediate CA certificate).
3. Configure the SRTP Cipher Suite preference.
4. Edit the Mindful Callback outgoing Dial Peer.

Enable TLS 1.2

The first step to implement TLS is to make sure that TLS 1.2 is supported in the global sip-ua section of the CUBE configuration. To verify whether this has already been done or not, use the command:

#show run | s transport tcp tls

More than one result may be returned, but the important value is the entry in the sip-ua section. This section will list the TLS versions supported. For example:

transport tcp tls v1.2

If this is not shown, that may be okay, because CUBE supports TLS 1.2 by default. However, if this line is present only with lower versions of TLS (1.0 or 1.1), then you will need to add TLS 1.2.

To add TLS 1.2, use the transport tcp tls command in the sip-ua config section:

#conf term
        sip-ua
         transport tcp tls

or use the following command to support only TLS 1.2 (no other versions):

#conf termsip-ua transport tcp tls v1.2

Configure Trustpoints

CUBE uses objects called Trustpoints to store TLS certificates and associated configuration. To successfully communicate between Mindful Callback and CUBE securely, two Trustpoints need to be configured on the CUBE.

1. The CUBE's local Trustpoint
   • This will contain the CUBE's own self-signed certificate (CA), so when another SIP device attempts to perform a secure TLS handshake with CUBE, the CUBE will provide its own certificate to verify against the list of trusted certificates stored in the other SIP device.
   • CUBE requires this Trustpoint and certificate to exist in order to respond to any request on it's SIP TLS port (usually port 5061).
2. A Trustpoint created to store the Intermediate CA certificate for the Mindful Callback SIP Proxy
   • When CUBE attempts to perform a TLS handshake with Mindful Callback, Mindful Callback sends it's own TLS certificate in the handshake. CUBE will check this against it's list of certificates contained in the Trustpoints. Once it matches the received certificate with the Mindful Callback Intermediate CA certificate stored in CUBE, the handshake can complete successfully.

This section contains instructions to:

• Verify whether CUBE already has a valid local Trustpoint/certificate configured.
• Create a local Trustpoint if one is not already present.
• Create a Trustpoint for Mindful Callback and import the Mindful Callback Intermediate CA certificate.

Verify the CUBE local Trustpoint

First ensure that the CUBE has a default Trustpoint configured:

#show crypto pki certificate

This command will return a list of certificates. One of the listed certificates may be the one presented by the CUBE in TLS handshakes with external endpoints. This can be a CA signed certificate or a self-signed certificate. For example:

Router Self-Signed Certificate
         Status: Available
         Certificate Serial Number (hex): 01
         Certificate Usage: General Purpose
         Issuer:
         hostname=CUBE.yourdomain.com
         Subject:
         Name: CUBE.yourdomain.com
         hostname=CUBE.yourdomain.com
         Validity Date:
         start date: 02:15:14 UTC Nov 10 2021
         end date: 02:15:14 UTC Nov 10 2031
        Associated Trustpoints: cube1
         Storage: nvram:CUBEexample#1.cer

The Associated Trustpoints line shows that the certificate is associated with a Trustpoint. In this example, Associated Trustpoints: cube1.

To view this in the CUBE's runtime configuration, use the following command:

#show run | s crypto pki Trustpoint cube1

The output will show the details of the Trustpoint:

crypto pki Trustpoint cube1
         enrollment selfsigned
         revocation-check none
         rsakeypair RSA2048 2048

Use the following command to verify that the Trustpoint is set as the default in the sip-ua section. This will ensure that this certificate is presented when a SIP device performs a TLS handshake with the CUBE.

#show run | s sip-ua

The output should look similar to the following:

sip-ua
         transport tcp tls v1.2
         connection-reuse via-port
         crypto signaling default Trustpoint cube1

Create a CUBE local Trustpoint

If there is no Trustpoint configured, consult the Cisco documentation appropriate to your router's IOS version to configure a default Trustpoint.

The following example shows how to set up a self-signed certificate and use it as the default Trustpoint:

First, create the Trustpoint:

#conf term
        crypto pki Trustpoint cube1
        enrollment selfsigned
        revocation-check none
        rsakeypair RSA2048 2048

Next, generate the self-signed certificate:

#conf term
        crypto pki enroll cube1
        % Include the router serial number in the subject name? [yes/no]: no
        % Include an IP address in the subject name? [no]: no
        Generate Self Signed Router Certificate? [yes/no]: yes

Finally, set the Trustpoint as the default in the sip-ua settings:

#conf term
        sip-ua
         crypto signaling default transport cube1

Create a Mindful Callback Trustpoint and import the certificate

To create the Trustpoint to store the Mindful Callback Intermediate CA certificate, start with the following configuration:

#conf term
        crypto pki Trustpoint mindfulca
         enrollment terminal
         revocation-check none
        crypto pki authenticate mindfulca

You will be asked to paste the Mindful Callback intermediate CA certificate provided by the Mindful Solution Delivery team (as a .pem file) into the console. Alternatively, you can download the certificates directly from Entrust at https://www.entrust.com/resources/certificate-solutions/tools/root-certificate-downloads. In the Entrust Root Certification Authority (G2) column, download the Root certificate and the (Non‐EV SSL) CA - L1K certificate.

The .pem file contains two certificates: the root CA and intermediate CA. Use the second (intermediate) certificate and copy the second section including the BEGIN and END lines. For example:

-----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----

You should then be asked to accept the certificate:

% Do you accept this certificate? [yes/no]: yes

Complete the certificate enrollment process as shown below:

crypto pki enroll mindfulca% Include the router serial number in the subject name? [yes/no]: no% Include an IP address in the subject name? [no]: noDisplay Certificate Request to terminal? [yes/no]: no

The certificate will now be stored in the new mindfulca Trustpoint. You can verify the configuration with the following command:

#show crypto pki certificate

3. Configure the SRTP cipher suite preference

The Mindful Callback SIP/RTP proxies support the SHA1_80 cipher suite, so you should create a suite preference profile. For example:

#conf term
        voice class srtp-crypto 10
         crypto 1 AES_CM_128_HMAC_SHA1_80

Note that a suitable SRTP crypto preference profile may already exist. If so, there is no need to configure a new profile.

4. Edit the Mindful Callback outgoing Dial Peer

The outgoing Dial Peer to Mindful Callback should be modified to add TLS- and SRTP-specific parameters. Following is an example of the Dial Peer configured earlier in this guide, modified to use TLS with SRTP for outgoing calls to Mindful Callback:

#conf term
        dial-peer voice 25755 voip
         description outgoing calls to Mindful Callback
         destination-pattern 25755....
         session protocol sipv2
         session target dns:sip-callback.mindful.cx:5061
         session transport tcp tls
        voice-class sip url sips
         voice-class sip early-offer forced
         voice-class sip profiles 10
        voice-class sip srtp-crypto 10
         voice-class sip pass-thru headers unsupp*
         dtmf-relay rtp-nte
         srtp
         codec g711ulaw
         no vad

The key changes to the Dial Peer are:

• session target dns sip-callback.mindful.cx:5061: The port changes from 5060 to 5061.
• session transport tcp tls: This forces the use of TLS, which runs over TCP.
• voice-class sip url sips: This forces the SIP URI string in the INVITE to Mindful to use the sips: prefix instead of sip:.
• voice-class sip srtp-crypto 10: This enforces the use of the SRTP cipher preference profile created earlier. If a suitable profile already existed, use the existing profile ID instead.
• srtp: This forces the use of SRTP for the audio stream.

Incoming TLS from Mindful

Currently, Mindful Callback does not validate the certificate that it receives from CUBE in the TLS handshake, so there is no requirement to provide the CUBE certificate to the Mindful team. Mindful Callback will still use TLS and SRTP for SIP and media, so the communication is still secure.

However, you will still need to configure the incoming Dial Peer for calls from Mindful Callback to use SRTP. For example:

#conf term
        dial-peer voice 10 voip
         description Incoming from MRQA2
         translation-profile incoming Inbound_DIDs
         session protocol sipv2
         incoming uri via 10
         voice-class codec 10
         voice-class sip profiles 10
         voice-class sip profiles 20 inbound
        voice-class sip srtp-crypto 10
         dtmf-relay rtp-nte
         voice-class sip pass-thru headers unsupp
        srtp
         no vad

The key changes to the Dial Peer are:

• voice-class sip srtp-crypto 10: This enforces the use of the SRTP cipher preference profile created earlier. If a suitable profile already existed, use the existing profile ID instead.
• srtp: This forces the use of SRTP for the audio stream.