Metaswitch call recording

This guide describes the configuration procedures required for MiaRec call recording software for interoperability with Metaswitch MetaSphere CFS and/or Perimeta SBC.

The MiaRec is a multi-tenant call recording platform that communicates with Metaswitch over the Session Initiation Protocol (SIP) interface and conforms to the SIP Recording (SIPREC) standard.

Metaswitch SIPREC configuration

This article explains how to set up MiaRec SIPREC call recording on the Metaswitch CFS platform.

Requirements:

  • MetaSwitch CFS v.9.0.10 or higher

SIPREC recording interface is supported in Metaswitch CFS starting from v.9.0.10

Service impact

The step to enable call recording on MetaSphere CFS, by modifying the global Application Servers object, requires you to disable this object briefly in order to make configuration changes. This means that any other services provided to MetaSphere CFS by Application Servers will be unavailable for a short period, typically no more than five minutes. It is recommended to do this step during a maintenance window or when call usage is low.

Apart from a brief outage in services provided to MetaSphere CFS by Application Servers, as described above, this procedure has no impact on service.

Network architecture

Metaswitch system uses the established SIPREC link to send call details (caller/called phone number, service provider id etc) and audio RTP stream to MiaRec recording server.

Metaswitch MiaRec Hosted Call Recording SIPREC

Step 1. Configure SIPREC recording interface in MiaRec

  1. Using MiaRec web portal, navigate to Administration -> System -> Recording Interfaces.

  2. Click Configure button for SIPREC interface

  3. Fill in the fields as follows:

    • Enable: checked (True)
    • Signaling UDP port: the desired port for SIP signaling. By default, MiaRec uses port 5080 for SIPREC, but you can change it to any other value.

    • Signaling TCP port: should be the same as UDP. Metaswitch CFS may send SIP packets towards to MiaRec using either UDP or TCP based on varios criteria, for example, it may choose TCP for large packets and UDP for smaller packets. So, both TCP and UDP listening ports should be enabled in MiaRec and both these ports should have the same value.

    • Public ip-address: specify the public ip-address of the MiaRec server if you use port forwarding for SIPREC traffic.

    • Use default values for other fields.

Update firewall settings. If you change SIPREC signaling port, then you need to update the firewall settings on the MiaRec server.

Step 2. Import the Remote Media Gateway Model used for the MiaRec recording server

  1. Download rmgm_Miarec_521149_9.3_v1.txt and save it to the MetaView User's home directory on the computer where you are running MetaView Explorer.

  2. Log in to MetaView Explorer.

  3. Select Object tree and views. Expand the tree until you can see the Network Element object corresponding to your MetaSphere CFS.

  4. Locate and expand the Controlled Networks object, then the Remote Media Gateway Models object below it.

  5. In the Import - file field, type the name of the Remote Media Gateway Model import file. Click apply to confirm your changes.

  6. Click on the import button to import the file.

The Import - status field should change to In progress and then to Succeeded to indicate that the configuration has been imported successfully.

If the status does not change to Succeeded, then look at the Import - log correlator field, and click on the go to log button next to this field to jump to the MetaView Explorer log viewer window, which shows a summary log describing the import action you have just taken. If there were problems with the import, you can follow the links within the log viewer to see the earlier logs relating to this problem. Take any action recommended by these logs and retry the import.

Step 3. Create the Configured SIP Binding

  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. Click on the add sub-component button and choose Configured SIP Binding.

  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 IP address and port or Domain name SRV lookup (auto fail-over)
    • Contact IP address and Contact IP port: set to the address and port of the MiaRec recording server (if the "Contact address scheme" is "IP address and port")
    • Contact domain name: set to the DNS SRV domain name of the MiaRec recording servers (if the "Contact address scheme" is "DNS SRV")
    • Proxy IP address and Proxy IP port: set to the IP address and port used to communicate with the proxy, or leave blank if a proxy is not being used
    • 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 True.
  5. Click apply to confirm your changes

Step 4. Create the Application Server

  1. In MetaView Explorer, navigate to Call Feature Server -> Call Services -> Global Application Servers.

  2. Click on the add sub-component button and choose Application Server.

  3. Fill in the fields as follows.

    • Directory number: select a free telephone number within one of the number ranges owned by the CFS (see Note 1)
    • Configured SIP Binding: select the binding that you created in the previous step
    • Server type: select Recording and leave all the other values unselected
  4. Click apply to confirm your changes.

Note 1. The Directory number setting is rather critical. It is important to select a phone number that is treated as local in respect to the recorded users. Otherwise, if it is treated by routing rules as an external, then Metaswitch CFS may send SIPREC signaling packets through a SIP Trunk, which is wrong. This issue is easily detectable by looking at SIP messages call flow in SAS tool.

Step 5. Enable call recording service on MetaSphere CFS

This step requires you to disable the global Application Servers object briefly in order to make configuration changes. This means that any other services provided to MetaSphere CFS by Application Servers will be unavailable for a short period, typically no more than five minutes. If you are running this MOP on a live system, you are recommended to do this step during a maintenance window or when call usage is low.

  1. In MetaView Explorer, navigate to Call Feature Server -> Call Services -> Application Servers.

  2. Click on disable to disable the object so that you can modify it.

  3. Set Recording service support to Configured.

  4. Set Recording service - default subscribed setting and Recording service - default enabled setting according to the desired behavior.

  5. In Recording service - default server, select the Application Server that you added earlier in this procedure.

  6. Click apply to confirm your changes, then enable to re-enable the Application Servers object. Check that it becomes active and no alarms are shown.

Step 6. Enable recording individually for each user in Metaswitch CFS.

This step is not required if you have enabled Call Recording on all lines by default.

You can use either MetaView Web or MetaView Explorer for this step. Repeat it for each line that you will use for testing Call Recording.

  • If you are using MetaView Web:

    1. Search for the Business Group Line, MLHG (see Note 1), MADN or PBX DID Number using its directory number, or search for the PBX using its name.
    2. Go to the Configuration tab and expand the Advanced section to show the Recording Service fields.
    3. Ensure that the service is both subscribed and enabled, and that the server is set to the new server you added earlier in this procedure.
    4. Click apply to confirm your changes.
  • If you are using MetaView Explorer:

    1. Use the Find option on the left-hand menu to find the line.
    2. Then find the Application Servers child object below it. For a PBX DID Number, the equivalent child object is DID Number Call Services.
    3. Ensure that the service is both subscribed and enabled, and that the server is set to the new server you added earlier in this procedure.
    4. Click apply to confirm your changes.

Note 1 - According to the specifications, configuring recording on MLHG pilot number does not record all calls through it and whether a call is recorded depends solely on the configuration of the member who answers. However, the recording service on MLHG pilot does record calls sent to the pilot's voicemail.

Step 7. Enable recording of intra-Business Group calls, if required

To record internal calls between subscribers within the same Business Group, enable the corresponding option in the Business Group settings:

Metaswitch - allow recording of intra-Business Group calls

Caution!. If recording of intra-Business Group calls is disabled, it may affect the consultative transfer scenarios as well. The transferred calls may not be recorded as they are treated as intra-business group calls in the Metaswitch phone platform.

Step 8. Enable a recording announcement, if required

Metaswitch platform can generate a periodical beep tone when recording is enabled.

This option is configurable on Business Group level:

Metaswitch - recording announcement

Step 9. Disable media bypass in Perimeta SBC for all recorded users

Subscribers behind Perimeta that have call recording enabled should not be allowed to use SBC media bypass, as this has been found to cause problems in the media path (one-way or no-audio issue for some call scenarios, including attended call transfer, hold/resume and 3-party conference). To disable it, on the adjacency facing the subscriber, type 'call-media-policy' and then 'media-bypass-policy forbid'.

Step 10. Make a test call and verify the recording

Make a call to or from one of the test lines on which Call Recording has been enabled. Check the recording on the MiaRec recording server.

If recording is not available, use MetaView Service Assurance Server to confirm that the call is being handled correctly

Detailed procedure:

  1. Log in to the MetaView Service Assurance Server Web GUI.
  2. Click Search.
  3. On the Number tab, enter the number of the Business Group Line to or from which you made the test call.
  4. Find the call that you made to or from the test number, and check the MetaView Service Assurance Server output to confirm that a SIP INVITE message was sent from MetaSphere CFS to the MiaRec recording server for this call.

Known limitations

No RTP towards MiaRec when Perimeta SBC is placed between CFS and MiaRec servers.

If SIPREC traffic is routed through Perimeta SBC, then you may face with no RTP issue. RTP packets are not delievered by SBC to MiaRec.

By default, the NAT auto-detect feature is enabled on the Perimeta SBC. SBC typically will wait for the endpoint to send RTP traffic before it will begin sending any of its own. Since MiaRec recorder is just a collection point, both ends would sit waiting for RTP.

You need to build a new adjacency on the SBC specific for the MiaRec server like shown below:

adjacency sip MiaRecCallRecording
    adjacency-limits
      regs 0
      regs-rate sustain 0 per-second
    call-media-policy
      media-bypass-policy forbid
      repeat-sdp-on-200ok
    interop
      header-settings from rewrite host local port include
        # Effective value: host local port include
      preferred-transport tcp
      message-manipulation
        edit-profiles inbound ""
        edit-profiles outbound ""
    mandated-transport tcp
    adjacency-type preset-access
    privacy untrusted
    realm “Name associated with RTP Ports”
    service-address “Name associated with Service Network”
    signaling-local-port 5080
    signaling-peer “IP address or domain name of MiaRec”
    signaling-peer-port 5080
    statistics-setting detail
    default-interop-profile “Name of Blacklist Profile”
    deactivation-mode normal
    activate

SIP packets towards the MiaRec server are corrupted

Symptomps:

  • MiaRec responses to the INVITE message with the error "400 BadRequest".
  • The XML call metadata is not available in the received INVITE message on the MiaRec server side.

This issue may happen when SIPREC traffic is routed through a Cisco ISR router and port 5060 is chosen for SIPREC connection.

By default, Cisco ISR router activates SIP ALG helper for SIP traffic on port 5060. If you use that port, then router will modify SIP messages from Metaswitch CFS. Cisco ISR router doesn't support SIPREC protocol with a multipart body content and it simply removes SIPREC XML call metadata from the INVITE message by mistake. The simplest solution is to choose a non-standard port for SIPREC connection, for example, 5080. Cisco router activates SIP ALG only for traffic on port 5060. Alternatively, you can disable SIP ALG in Cisco ISR router.

Duplicate call recordings in particular call scenarios on Metaswitch CFS before 9.3.20_SU68

A duplicate of call recording issue may occur when call is answered on UC device (Mobility App, Desktop App, physical desk phone), then picked up on another device using the same line.

Fix: Upgrade the Metaswitch CFS server to version 9.3.20_SU68 or higher.

MiaRec configuration for Metaswitch call recording

1. Configure SIPREC recording interface

In MiaRec web portal navigate to Administration -> System -> Recording interfaces.

  • Enable "SIPREC" recording interface
  • Disable all other recording interfaces if you do not use them

Recording interfaces

Click on Configure link for SIPREC interface.

  • Check Enable SIPREC recording
  • Change parameters Signaling UDP port and Signaling TCP port according to the port configuration in Metaswitch SBC. By default MiaRec is listening on port 5080 for both TCP and UDP signaling data.
  • If MiaRec server is located behind NAT, then specify Public Ip-address which is used by Metaswitch SBC to establish SIPREC connection. Make sure that port forwarding is configured properly on your NAT router. If MiaRec server and Metaswitch SBC are in the same network, then leave this parameter empty.
  • If necessary, change default values of UDP port range for RTP media packets. Edit parameters Begin RTP port range and End RTP port range. Make sure that the port range is large enough for anticipated number of concurrently recorded calls. One concurrent call requires one UDP port for single media stream recording and two UDP ports for dual media stream recording.

Make sure that firewall is configured properly and inbound connections on SIP signaling and RTP ports are permitted. See Firewall configuration

SIPREC interface

2. Configure extension mapping setting

  1. Navigate in MiaRec web portal to Administration -> System -> Recording rules and click Edit Configuration.

  2. Change Extension is ... to Metaswitch extension.

  3. Click Save

3. Enable multi-tenancy

  1. Navigate in MiaRec web portal to Administration -> Customization-> Multitenancy and click Edit Configuration.

  2. Make sure Multitenancy is enabled.

  3. Click Save

See also Understanding multi-tenancy

4. Create new tenant (customer)

Navigate in MiaRec web portal to Administration -> User management -> Tenants and click Add Tenant.

  • Set tenant name
  • Allocate licenses for this tenant

Add tenant

5. Create/edit role permissions

MiaRec supports role-based access control with granular permissions. You can create such roles as administrator, supervisor, agent, etc. See Understanding roles and permissions

6. Create users for web-access

Check also Automatic user provisioning

Inside Tenant account select Users tab and click Add user.

Add user

In Web access settings section specify Login and Password for this user.

Add user

Ignore Metaswitch internal redirect numbers

Since Release 2018.05.15, MiaRec includes enhancements to some call recording scenarios in Metaswitch environment.

Navigate to Administration -> System -> Recording Interfaces -> SIPREC and configure your EAS / VM Admin Number(s) in the Ignore participants attribute like:

MiaRec changelog

Description of affected scenarios

When call is routed from the main ICM number to MLHG, the XML metadata in SIPREC packet contains VM Admin Number as one of participants.

Previous versions of MiaRec displayed the VM Admin Number (9999999992) in "From" column. The original calling number (70865XXXXX) was displayed in call details. It was non-intuitive to end-users.

MiaRec changelog

Since Release 2018.05.15, MiaRec shows the calling number in "From" field. The VM Admin Number is not shown at all.

MiaRec changelog

Automatic user provisioning

MiaRec supports automatic provisioning of users based on call metadata information received in SIPREC message. If MiaRec receives call recording for unknown extension, then it can use call metadata from SIPREC message to automatically create user account within particular tenant account. Alternatively, you can create user accounts manually in MiaRec web portal.

Add tenant

In order to enable such functionality, it is necessary to configure Metaswitch System Name and Metaswitch Business Group for the tenant account. If such settings are specified, then MiaRec will associate call recordings with this tenant only when they match to System/Group name.

When Auto-provision users is enabled, then you can specify which default role will be assigned to newly created users and which group they will be placed in.

Add tenant

High availability configuration

SIPREC auto-failover configuration

There are two types of network topology for SIPREC recording in Metaswitch environment:

  1. A direct connection between Metaswitch CFS and MiaRec (see the figure 1)
  2. Perimeta SBC as a SIP Proxy between CFS and MiaRec (see the figure 2)

Usually, the 2nd option is used when CFS and MiaRec are located in different network segments and a direct communication is forbidden between those segments. In this case, Perimeta SBC is used as a SIP Proxy between CFS and MiaRec.

If both CFS and MiaRec servers are located within the same network, then we recommend to use the 1st option as it is easier to configure and maintain.

Figure 1. A direct connection of Metaswitch CFS to MiaRec recorder

Metaswitch CFS SIPREC auto-failover with MiaRec

Figure 2. Perimeta SBC as a SIP Proxy between CFS and MiaRec recorder

Metaswitch CFS SIPREC auto-failover with MiaRec

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.

Metaswitch CFS SIPREC auto-failover with MiaRec

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:

Alias Record Type Points to Description
miarec1.your-domain.com A record x.x.x.x This A-record should point to ip-address of the primary MiaRec server
miarec2.your-domain.com A record y.y.y.y This A-record should point to ip-address of the secondary 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.

Alias Record Type Points to Description
miarec-siprec.your-domain.com A record x.x.x.x This A-record should point to ip-address of the primary MiaRec server

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 (contact your Metaswitch representative if you are not able to active it).

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 SRV lookup
    • Contact domain name: set to the DNS SRV domain name of the 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 an 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 up to 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.

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

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

A network topology is shown in the following diagram.

Here, Metaswitch CFS communicates with two MiaRec recordings servers using SIPREC protocol. DNS SRV records are used to configure priority of the recording servers.

Metaswitch CFS SIPREC auto-failover with MiaRec

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:

Alias Record Type Points to Description
miarec1.your-domain.com A record x.x.x.x This A-record should point to ip-address of the primary MiaRec server
miarec2.your-domain.com A record y.y.y.y This A-record should point to ip-address of the secondary MiaRec server

Create DNS SRV records on your DNS server for both UDP and TCP protocols:

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.

UDP records:

# _service._proto.name.                   TTL   class   SRV   priority  weight    port   target.
_sip._udp.miarec-siprec.your-domain.com.  1800  IN      SRV   10        50        5080   miarec1.your-domain.com.
_sip._udp.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. Metaswitch CFS will send 100% of SIPREC traffic to miarec1 unless this server is not reachable. If miarec1 is unavailable, Metaswitch CFS will send SIPREC traffic to miarec2 as a failover mechanism.

Why do we need both TCP and UDP records for SIPREC?

In some scenarios, Metaswitch may send SIP re-INVITE packet using TCP protocol even if the original INVITE was sent out using UDP. That's why we need to enable both TCP and UDP protocols.

Step 2. 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 SRV lookup (auto fail-over)
    • Contact domain name: set to the DNS SRV domain name of the MiaRec recording servers (miarec-siprec.your-domain.com in our example)
    • Proxy IP address: leave blank as we are not using proxy for SIPREC in this setup
    • 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 True.

Important! This configuration assumes that 1) CFS can resolve domain names, i.e. DNS server(s) is properly configured in CFS and 2) CFS can communicate directly to MiaRec server, i.e. firewall/router, if any, is configured properly to allow such direct communication.

Step 3. 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 a few minutes before CFS 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 CFS sends SIP INVITE to the corresponding MiaRec server. For example, if the first server is down, CFS should try to 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.

User authentication using Metaswitch CommPortal

MiaRec supports integration with Metaswitch CommPortal. The latter can be used to verify users' credentials. This means that the same login and password may be used for both CommPortal and MiaRec web portals.

Metaswitch CommPortal integration

Navigate to Administration -> User Authentication -> Metaswitch CommPortal Authentication and specify the CommPortal URL. You can optionally provide a test account/password and verify connection to CommPortal.

Metaswitch CommPortal integration

After that on each user's profile you need to change Authentication with to Metaswitch CommPortal.

Metaswitch CommPortal integration