Configure SIPREC auto-failover for a CFS-Perimeta-MiaRec connection

Note: This article describes the required steps to configure auto-failover for SIPREC recording in scenario when Metaswitch CFS communicates to MiaRec recorder through Perimeta SBC as a SIP Proxy. If Perimeta SBC is not used as a SIP Proxy, then check the appropriate guide.

A network topology is shown in the following diagram.

Here, Metaswitch CFS communicates with two MiaRec recordings servers through Perimeta SBC as a SIP Proxy. DNS SRV records are used to set priorities of the recording servers.

In this configuration, auto-failover is handled by Perimeta SBC rather than CFS.

Step 1. Configure DNS SRV records

Create the two A-records on your DNS server. Each of records should point to the corresponding MiaRec server:

Create DNS SRV records on your DNS server for TCP protocol (we recommend to use TCP protocol for SBC-to-MiaRec communication):

TCP records:

# _service._proto.name.                    TTL   class   SRV   priority  weight    port   target.
_sip._tcp.miarec-siprec.your-domain.com.   1800  IN      SRV   10        50        5080   miarec1.your-domain.com.
_sip._tcp.miarec-siprec.your-domain.com.   1800  IN      SRV   20        50        5080   miarec2.your-domain.com.

In this example, we define DNS SRV name miarec-siprec.your-domain.com that points to two MiaRec servers. We use different priority values for MiaRec servers, i.e. miarec1 has priority 10 and miarec2 has priority 20. The miarec1 server will be used as a primary server. Perimeta SBC will route 100% of SIPREC traffic to miarec1 unless this server is not reachable. If miarec1 is unavailable, Perimeta SBC will route SIPREC traffic to miarec2 as a failover mechanism.

Additionally, create A-record for miarec-siprec.your-domain.com that points to the primary server. This is a fake record, which is used to suppress "could not resolve domain name" alarm on CFS SIP Binding. It doesn't affect auto-failover and server priorities.

Step 2. Configure Perimeta SBC

First, make sure DNS SRV lookup is enabled in Perimeta SBC. It may require the appropriate licenses to activate this feature.

Execute the following command in CLI:

sbc
    signaling
        sip dns-lookup srv-records

Create adjacency for MiaRec recorder:

config
  sbc
    signaling
      adjacency sip MiaRecCallRecording
        deactivation-mode normal
        call-media-policy
          media-bypass-policy forbid
          repeat-sdp-on-200ok
        interop
          preferred-transport tcp
          ping-enable
        mandated-transport tcp
        adjacency-type preset-peering
        privacy untrusted
        realm “Name associated with RTP Ports”
        service-address “Name associated with Service Network”
        signaling-local-port 5080
        signaling-peer miarec-siprec.your-domain.com
        dynamic-routing-domain-match miarec-siprec.your-domain.com
        signaling-peer-port 0
        statistics-setting detail
        default-interop-profile “Name of Blacklist Profile”

Replace miarec-siprec.your-domain.com with your domain name accordingly.

Use the appropriate values for realm, service-address and default-interop-profile attributes (check other adjacency on your SBC as a reference).

Explanation of the attributes of this adjacency:

• With interop/ping-enable setting, Perimeta SBC will send periodically SIP OPTIONS (keep-alive) message to both MiaRec servers to test their availability
• With interop/preferred-transport tcp setting, Perimeta SBC is instructed to use TCP protocol for communication with MiaRec (TCP is a preferred protocol for cases when SBC and MiaRec are located in different network segments).
• With dynamic-routing-domain-match setting, we specify a condition when this adjancency is applied. In this example, SBC will use the adjacency when it receives a SIP INVITE packet from CFS to the request URI miarec-siprec.your-domain.com
• With signaling-peer setting, we specify the address of MiaRec servers (should be DNS SRV name). SBC will resolve this domain name into two records (miarec1 and miarec2) and route SIPREC traffic between them accordingly.
• signaling-local-port setting is not really important. It can be any other value. We use a port 5080 rather than a default 5060 to make our troubleshooting easier. Particularly, when looking at a call flow in SAS trace, we can easily tell if the adjacency is in place or not by looking at the source port of the SIP INVITE message.

Step 3. Configure SIP Binding for MiaRec on Metaswitch CFS

1. In MetaView Explorer, select Object tree and views. Expand the tree until you can see the Network Element object corresponding to your MetaSphere CFS. Expand this object.

2. Locate and expand the Controlled Networks object, then the Configured SIP Bindings object below it.

3. Locate the SIP Binding previously created for MiaRec recorder (or create new one).

4. Fill in the fields as follows. Any fields not listed below can be left with their default values.

   • Name: fill in a name that will help you to associate this binding with the recording server. For example, "MiaRec recorder"
   • Usage: set to Application Server
   • Use DN for identification: set to True
   • SIP authentication required: set to False
   • IP address match required: set to True
   • Contact address scheme: set to Domain name A/AAAA lookup (do not use DNS SVR lookup here as the auto-failover is a responsibility of Perimeta SBC in this setup!)
   • Contact domain name: set to the fake domain name previously created for MiaRec recording servers (miarec-siprec.your-domain.com in our example)
   • Proxy IP address and Proxy IP port: set to the IP address and port used to communicate with Perimeta SBC (SIP proxy)
   • Trusted: set to True
   • Media Gateway model: select the model that you imported earlier in this procedure
   • Maximum call appearances: set this to the maximum concurrent calls for the recording service. Enabling Call Recording on large numbers of lines will increase the resources used by the service, particularly Media Gateway resources. Ensure that you have enough capacity to handle the expected level of recorded calls. If the MiaRec recorder server is located in a separate network, make sure that appropriate bandwidth is available for the the anticipated recording data network traffic.
   • Poll peer device: set to False (polling of peers is a responsibility of Perimeta SBC in this setup).
   • Transport protocol: set to UDP (this is important setting. Don't be surprised, CFS-to-SBC communication is via UDP, but SBC-to-MiaRec communication is via TCP. That is how it should work).

Step 4. Test auto-failover

1. Make a test call
2. Verify if such call is recorded by the primary MiaRec server. If no calls are recorded, then check the Troubleshooting section below.
3. Complete the call

4. Simulate a failure of the primary server by stopping the recording service via SSH console:

   service miarec stop

5. Make another test call

6. Verify if such call is recorded by the secondary MiaRec server. If no calls are recorded, then check the Troubleshooting section below.

7. Restore the recording service on the primary server:

   service miarec start

8. Make another test call. 9 Verify if such call is recorded again by the primary MiaRec server. Note, it may take about 10 minutes before Perimeta SBC begins sending SIPREC traffic to the primary server after its restoration.

Troubleshooting

In case of issues, check the following sources:

1. Check alarms for MiaRec SIP Binding in MetaView Explorer.
2. Check SIP messages call flow in SAS trace. Verify if SIPREC INVITE mesage is sent through Perimeta SBC. Verify if SBC sends SIP INVITE to the corresponding MiaRec server. For example, if the first server is down, SBC should send SIP INVITE to the secondary server rather than trying to reach the primary one.
3. Enable trace in MiaRec under Administration -> Maintenance -> Troubleshooting and check the collected trace file.