Phone system integration

Avaya Aura call recording

Avaya TSAPI DMCC recording

1. Introduction

This article describes how to configure the MiaRec Call Recording System with the Avaya Application Enablement Services and Avaya Communication Manager to record incoming and outgoing phone calls using TSAPI and DMCC services.

MiaRec uses TSAPI interface from Avaya Aura Application Enablement Services (AES) to monitor skill groups and agent stations on Avaya Aura Communication Manager, and Device, Media, and Call Control (DMCC) interfaces to capture media associated with the monitored agents for call recording with the Multiple Registration method.

Avaya DMCC-based recording

Requirements:

  • Avaya Communication Manager v6.3.2 or higher
  • Avaya Application Enablement Services (AES) Server v6.3.1 or higher
  • TSAPI Basic License per each recorded extension and each monitored ACD Split / Hunt Group
  • DMCC Basic License for each recorded extension

2. Configure Avaya Communication Manager

This section presents configuration steps for the Avaya Communication Manager. It is assumed that an appropriate license file and authentication file have been installed on the server, and that login and password credentials are available.

The configuration and verification operations illustrated in this section were all performed using the Communication Manager System Administration Terminal (SAT).

The procedures include the following areas:

  • Verify license
  • Verify the status CTI link for TSAPI service
  • Administer system parameters features
  • Administer agent stations

2.1. Verify license

Log into the System Access Terminal (SAT) to verify that the Communication Manager license has proper permissions for features required for call recording. Use the "display system-parameters customer-options" command to verify that the Computer Telephony Adjunct Links customer option is set to "y" on Page 4. If this option is not set to "y", then contact Avaya sales team of business partner for a proper license file.

display system-parameters customer-options                      Page   4 of  12
                                OPTIONAL FEATURES

    Abbreviated Dialing Enhanced List? y           Audible Message Waiting? y
        Access Security Gateway (ASG)? y               Authorization Codes? y
        Analog Trunk Incoming Call ID? y                        CAS Branch? n
 A/D Grp/Sys List Dialing Start at 01? y                          CAS Main? n
Answer Supervision by Call Classifier? y                 Change COR by FAC? n
                                  ARS? y  Computer Telephony Adjunct Links? y
                 ARS/AAR Partitioning? y   Cvg Of Calls Redirected Off-net? y
          ARS/AAR Dialing without FAC? n                       DCS (Basic)? y
          ASAI Link Core Capabilities? y                 DCS Call Coverage? y
          ASAI Link Plus Capabilities? y                DCS with Rerouting? y
       Async. Transfer Mode (ATM) PNC? n
  Async. Transfer Mode (ATM) Trunking? n    Digital Loss Plan Modification? y
              ATM WAN Spare Processor? n                           DS1 MSP? y
                                 ATMS? y             DS1 Echo Cancellation? y
                  Attendant Vectoring? y

2.2. Verify the status of CTI link for TSAPI service

Log into the System Access Terminal (SAT) to enter the "status aesvcs cti-link" command. The link status should show no for maintenance busy (Mnt Busy), the Service State should indicate established and Version should be 6 or higher.

status aesvcs cti-link

                          AE SERVICES CTI LINK STATUS

CTI   Version  Mnt   AE Services      Service       Msgs     Msgs
Link           Busy  Server           State         Sent     Rcvd

1     7        no    aes              established   15       15

If the CTI link is not established, then follow instructions in chapter Administering Communication Manager for AE Services in document Application Enablement Services Administration and Maintenance Guide available at http://support.avaya.com

2.3. Administer agent stations

Use the "change station xxxxx" command, where xxxxx is the phone's extension, and change IP SoftPhone to "y", to allow a virtual IP softphone (DMCC) to be registered against the station. The MiaRec application will use the Multiple Registration feature of Communication Manager to register the DMCC-based recording device against the station.

change station 3001                                             Page   1 of   5
                                     STATION

Extension: 3001                          Lock Messages? n               BCC: 0
     Type: 9608                          Security Code: *                TN: 1
     Port: S00003                      Coverage Path 1:                 COR: 1
     Name: User Two                    Coverage Path 2:                 COS: 1
                                       Hunt-to Station:               Tests? y
STATION OPTIONS
                                           Time of Day Lock Table:
              Loss Group: 19         Personalized Ringing Pattern: 1
                                                 Message Lamp Ext: 3001
            Speakerphone: 2-way               Mute Button Enabled? y
        Display Language: english                  Button Modules: 0
 Survivable GK Node Name:
          Survivable COR: internal              Media Complex Ext:
   Survivable Trunk Dest? y                          IP SoftPhone? y

                                               IP Video Softphone? n
                              Short/Prefixed Registration Allowed: default

                                              Customizable Labels? y

2.4. Administer System Parameters Features

Enter the "change system-parameters features" command. Navigate to Page 5, and verify that Create Universal Call ID (UCID) has value “y”. If not, then set it to "y" and set UCID Network Node ID to an unassigned node ID.

change system-parameters features                               Page   5 of  17
                        FEATURE-RELATED SYSTEM PARAMETERS

SYSTEM PRINTER PARAMETERS
  Endpoint:               Lines Per Page: 60

SYSTEM-WIDE PARAMETERS
                                     Switch Name:
            Emergency Extension Forwarding (min): 10
          Enable Inter-Gateway Alternate Routing? n
Enable Dial Plan Transparency in Survivable Mode? n
                              COR to Use for DPT: station

MALICIOUS CALL TRACE PARAMETERS
               Apply MCT Warning Tone? n   MCT Voice Recorder Trunk Group:

SEND ALL CALLS OPTIONS
     Send All Calls Applies to: station    Auto Inspect on Send All Calls? n

UNIVERSAL CALL ID
     Create Universal Call ID (UCID)? y    UCID Network Node ID: 9999
     Copy UCID for Station Conference/Transfer? n

Navigate to Page 13, and set Send UCID to ASAI to "y". This parameter allows for the universal call ID to be sent to MiaRec call recording application.

change system-parameters features                               Page  13 of  17
                        FEATURE-RELATED SYSTEM PARAMETERS

 CALL CENTER MISCELLANEOUS
                         Clear Callr-info: next-call
        Allow Ringer-off with Auto-Answer? n

    Reporting for PC Non-Predictive Calls? n


  ASAI
            Copy ASAI UUI During Conference/Transfer? n
        Call Classification After Answer Supervision? n
                                   Send UCID to ASAI? y

2.5. Configure Service Observe

For the purposes of Multi Registration, service observe must be enabled for the COR to which the Target Stations will be assigned. Using the command "change cor 1" set both Can be Service Observed? and Can be a Service Observer? to "y".

change cor 1                                                    Page   1 of  23
                              CLASS OF RESTRICTION

               COR Number: 1
          COR Description:

                      FRL: 0                                APLT? y
  Can Be Service Observed? y           Calling Party Restriction: outward
Can Be A Service Observer? y            Called Party Restriction: none
        Time of Day Chart: 1       Forced Entry of Account Codes? n
         Priority Queuing? n                Direct Agent Calling? n
     Restriction Override: none       Facility Access Trunk Test? n
     Restricted Call List? n                 Can Change Coverage? n

            Access to MCT? y            Fully Restricted Service? n
Group II Category For MFC: 7            Hear VDN of Origin Annc.? n
         Send ANI for MFE? n             Add/Remove Agent Skills? n
            MF ANI Prefix:              Automatic Charge Display? n
Hear System Music on Hold? y   PASTE (Display PBX Data on Phone)? n
                        Can Be Picked Up By Directed Call Pickup? n
                                    Can Use Directed Call Pickup? n
                                    Group Controlled Restriction: inactive

3. Configure Avaya Application Enablement Services

This section provides the procedures for configuring Avaya Application Enablement Services. The procedures include the following areas:

  • Verify TSAPI and DMCC services licensing
  • Administer TSAPI link
  • Obtain Tlink name
  • Administer CTI user for MiaRec

3.1. Verify TSAPI and DMCC services licensing

Prior to any administration, verify that the TSAPI and DMCC services have been licensed properly. Open the AES OAM web interface by browsing to "https://ip-address-or-dns", where "ip-address-or-dns" is the IP address or DNS alias of the Appliation Enabledment Services server, and log in using the appropriate credentials (not shown).

Select Licensing -> WebLM Server Access in the left pane, to display the Web License Manager pop-up screen (not shown), and log in using the appropriate credentials.

Avaya AES WebLM Server Access

If the licenses are managed centrally on the System Manager, then select Services -> Licenses in the System Manager home screen. Otherwise, the Web License Manager screen is shown immediately.

Avaya System Manager Licenses

In the Web License Manager screen, select Application_Enablement under Licenses Products to display license capacity and current usage.

Verify that there are sufficient licenses for TSAPI Simultaneous Users and Device Media and Call Control, as shown below. Note that the TSAPI license is used for device monitoring, and the DMCC license is used for media recording.

MiaRec requires TSAPI Basic license for each monitored IP Phone, softphone and ACD Split (Hunt Group) and DMCC Basic license for each recorded IP phone and softphone.

If the TSAPI or DMCC service is not licensed, contact the Avaya sales team or business partner for a proper license file.

Avaya AES TSAPI licenses

3.2. Administer TSAPI link

To administer a TSAPI link, select AE Services -> TSAPI -> TSAPI Links from the left pan of the Management Console. The TSAPI Links screen is displayed, as shown below. If the TSAPI Link is not configured yet, then click Add Link to create one.

Avaya AES TSAPI Links

The Add TSAPI Links screen is displayed next.

The Link field is only local to the Application Enablement Services server, and may be set to any available number. For Switch Connection, select the relevant switch connection from the drob-down list. In this case, the existing switch connection "cm2" is selected. For Switch CTI Link Number, select the CTI Link number from Section 2.2. Make sure that ASAI Link Version is 6 or higher. Retain the default values in the remaining fields.

Avaya AES TSAPI Add Link

3.3. Verify Switch Connection PE/CLAN IPs

Select Communications Manager Interface -> Switch Connections from the left pane. The Switch Connections screen shows a listing of the existing switch connections.

Locate the connection name associated with the relevant Communication Manager, in this case "cm2", and click Edit PE/CLAN IPs button for the corresponding connection.

Avaya AES Switch Connections

In the Edit Processor Ethernet IP screen, verify that ip-address is configured for Communication Manager and Status is shown "In Use". If the ip-address is not configured, then use Add/Edit Name or IP button to configure it.

Avaya AES Switch Connections

Navigate back to the Switch Connections screen and verify that the Number of Active Connections is valid.

Avaya AES Switch Connections

3.4. Verify Switch Connection H.323 Gatekeeper

Select Communications Manager Interface -> Switch Connections from the left pane. The Switch Connections screen shows a listing of the existing switch connections.

Locate the connection name associated with the relevant Communication Manager, in this case "cm2", and click Edit H.323 Gatekeeper button for the corresponding connection.

Avaya AES Switch Connections

In the Edit H.323 Gatekeeper screen, verify that ip-address is configured for Communication Manager. If the ip-address is not configured yet, then use Add Name or IP button to configure it.

Avaya AES Switch Connections

Usually, it is recommended to click Edit Connection button and uncheck Secure H323 Connection option. Otherwise, the DMCC RegisterTerminal request may fail with "unspecified" error.

3.5. Obtain Tlink name

Select Security -> Security Database -> Tlinks from the left pane. The Tlinks screen shows a listing of the Tlink names. Locate the Tlink Name associated with the switch connection to Avaya Communication Manager. A new TLink name is automatically generated for the TSAPI service. Locate the TLink name associated with the relevant switch connection, which would use the name of the switch connection as part of the Tlink name. Make a note of the associated Tlink name, to be used later for configuring the MiaRec server.

In this case, the associated Tlink name is "AVAYA#CM2#CSTA#AES"'. Note the use of the switch connection "CM2" from Section 3.2 as part of the Tlink name.

If Tlink doesn't exist, then follow instructions in AE Services Administration in document Application Enablement Services Administration and Maintenance Guide available at http://support.avaya.com

Avaya AES Tlinks

3.6. Administer CTI user for MiaRec

Select User Management -> Add User from the left pane, to display the Add User screen in the right pane.

Enter desired values for User Id, Common Name, Surname, User Password, and Confirm Password. Retain the default value of “None” for Avaya Role, and select “Yes” from the CT User drop-down list. Click on Apply at the bottom of the screen (not shown below). Make a note of the User Id and Password, to be used later for configuring the MiaRec server.

Avaya AES Add User

Next, you need to change the security level for the CTI User as it needs to have unrestricted access privileges.

Select Administration -> Security Database -> CTI Users -> List All Users from the left pane. Choose the previously created CTI user, and click Edit.

Avaya AES Edit CTI User

The Edit CTI User screen appears. Tick the Unrestricted Access box and Apply Changes at the bottom of the screen.

Avaya AES Edit CTI User

3.7. Configure DMCC port

On the AES Management Console navigate to Networking -> Ports to set the DMCC server port. Enable either Unencrypted Port or "Encrypted Port** or both as shown in the screen below. Note the port values to use in the following steps for MiaRec server configuration. Click Apply Changes button (not shown) at the bottom of the screen to complete the process.

Avaya AES DMCC ports

3.8. Enable Security Database

Select Security -> Security Database -> Control from the left pane, to display the SDB Control for DMCC and TSAPI screen in the right pane. Check Enable SDB for DMCC Service and Enable SDB TSAPI Service, JTAPI and Telephony Service, and click Apply Changes.

Avaya AES Enable SDB

3.8. Restart TSAPI and DMCC services

Select Maintenance -> Service Controller from the left pane, to display the Service Controller screen in the right pane. Check DMCC Service and TSAPI Service, and click Restart Service.

Avaya AES Restart Services

4. Configure MiaRec Call Recording System

This section presents configuration steps for MiaRec call recording system. It is assumed that MiaRec is already installed on the server. The procedures include the following areas:

  • Install AES TSAPI Client
  • Administer MiaRec TSAPI link to AES
  • Administer MiaRec DMCC link to AES

4.1. Install AES TSAPI Client

Download Application Enablement Services TSAPI Client from http://support.avaya.com

Install it on MiaRec server. During installation enter the IP address of the Avaya AES server in the Host Name or IP Address field, retaining the default port of 450 (see below screenshot). Click on Add to List and then Next to finish installation.

Avaya AES TSAPI Client install

4.2. Administer MiaRec DMCC settings

Navigate in the MiaRec web interface to Administration -> System -> Recording Interfaces and click Configure link for Avaya DMCC interface.

MiaRec DMCC settings

In the Configure Recording Interface (Avaya DMCC) screen, configure the following settings:

  • Option Enable should be checked
  • Option AES server should point to HOST:PORT of AES server, where the HOST is an ip-address or DNS name of the Application Enablement Services server and the PORT is DMCC port obtained in the Section 3.7. Configure DMCC port
  • Option Use SSL should be checked when Encrypted DMCC port is used for connection to AES server
  • Option DMCC login and "DMCC password** should be set to the credentials of CTI user created in Section 3.6. Administer CTI user for MiaRec.
  • Option SwitchName should be set the hostname of Communication Manager used to register DMCC virtual softphone against to
  • Retain default settings for other values

MiaRec DMCC settings

4.3. Administer MiaRec TSAPI settings

Navigate in the MiaRec web interface to Administration -> System -> Recording Interfaces and click Configure link for Avaya TSAPI interface.

MiaRec DMCC settings

In the Configure Recording Interface (Avaya TSAPI) screen, configure the following settings:

  • Option Enable should be checked
  • Option TSAPI Link should point to the obtained TLink in the Section 3.5. Obtain Tlink name.
  • Option TSAPI login and "TSAPI password** should be set to the credentials of CTI user created in Section 3.6. Administer CTI user for MiaRec.
  • Option Media Source should be set to DMCC
  • Option Monitored phones should list all recorded extensions, comma-separated. A range of extensions is supported, like 3000-3100, 5001, 5002
  • Option Monitored ACD Splits should list all ACDs, which the recorded users may login to. MiaRec monitors ACDs for login/logout events. A range value is supported, like 4900-49100, 55000, 56000
  • Option Ignore dialing phase could be enabled to avoid recording of initial dialing phase of the outgoing call scenario
  • Retain default settings for other values

MiaRec DMCC settings

5. Verification and Troubleshooting

This section provides the tests that can be performed to verify proper configuration of Avaya Communication Manager, Avaya Application Enablement Services and MiaRec call recording application.

5.1. Verify Avaya Communication Manager

On Avaya Communication Manager, verify the status of the administered CTI links by using the "status aesvcs cti-link" command. The link status should show "no" for maintenance busy (Mnt Busy) and the Service State should indicate "established".

status aesvcs cti-link

                          AE SERVICES CTI LINK STATUS

CTI   Version  Mnt   AE Services      Service       Msgs     Msgs
Link           Busy  Server           State         Sent     Rcvd

1     4        no    aes-server1      established   15       15

The "status aesvcs interface" command should indicate the interface is listening.

status aesvcs interface

                          AE SERVICES INTERFACE STATUS

Local Node        Enabled?  Number of     Status
                            Connections

procr             yes       1             listening

The "status aesvcs link" command will indicate the number of messages sent from, and received at the CLAN interface (or procr), to and from Avaya Application Enablement Services, including maintenance traffic.

status aesvcs link

                            AE SERVICES LINK STATUS

Srvr/  AE Services     Remote IP        Remote  Local Node      Msgs    Msgs
Link   Server                           Port                    Sent    Rcvd

01/01  aes-server1     10.0.0.25        43909   procr           224     209

Once the MiaRec call recording application is running, the "list monitored-station" command will show each station, which is monitored by MiaRec via TSAPI interface.

list monitored-station

                            MONITORED STATION

  Station     Association 1    Association 2    Association 3    Association 4
  Ext         CTI Link  CRV    CTI Link  CRV    CTI Link  CRV    CTI Link  CRV
  -------     -------------    -------------    -------------    -------------
32129          1          10
32130          1           9
32131          1          22
32132          1           7

5.2. Verify Avaya Application Enablement Services

On Application Enablement Services, verify the status of the switch connection by selecting Status -> Status and Control -> Switch Conn Summary from the left pane. Verify that the Conn State is “Talking” for the switch connection associated with Avaya Communication Manager, and that the Associations column reflects the total number of monitored skill groups and agent stations as configured previously.

Avaya AES Switch Connection Summary

Verify the status of the TSAPI link by selecting Status -> Status and Control -> TSAPI Service Summary from the left pane. Verify the Conn Status is “Talking” as shown below.

Avaya AES TSAPI Link Details

Verify the status of the CTI User by selecting Status -> Status and Control -> TSAPI Service Summary from the left pane. Click the User Status button (not shown below). The CTI User Status screen is displayed. Verify that an open session exists for the CTI user created for MiaRec as shown below. This verification step assumes that MiaRec application is configured properly and running.

Avaya AES CTI User Status

Verify the status of the DMCC link by selecting Status -> Status and Control -> DMCC Service Summary from the left pane. The DMCC Service Summary - Session Summary screen is displayed.

Verify the User column shows an active session with the MiaRec user name and that the # of Associated Devices column reflects the total number of configured DMCC devices.

Avaya AES CTI User Status

Click Device Summary link in the Status -> Status and Control -> DMCC Service Summary screen to see the list of currently registered DMCC devices.

Avaya AES CTI User Status

5.3. Verify TSAPI device monitoring status in MiaRec

Navigate in the MiaRec web interface to Administration -> System -> Recording Interfaces and click Status link for Avaya TSAPI interface.

MiaRec DMCC settings

In the Avaya TSAPI status screen, click View TSAPI monitored devices link for the appropriate recorder instance (the screenshot below shows one instance).

MiaRec DMCC settings

In the Avaya TSAPI monitored devices screen, verify status of the monitored devices. If any of devices shows failed state, then click on the extension link in that window to see the detailed error message.

MiaRec DMCC settings

The error message describes the actual reasons of failure. Read the message and apply appropriate corrections. For example, the message in the following screenshot says that device identifier (extension) is not valid. In this case, remove this extension from the Monitored Phones list in configuration.

MiaRec DMCC settings

If the Avaya TSAPI monitored devices screen shows none of devices (neither successfully monitored nor failed), then probably the TSAPI link connection is not established to AES server. In this case, navigate to Administration -> Maintenance -> System Log and check any error messages. The screenshot below shows that the TSAPI login/password is invalid. Make the appropriate corrections to the configuration.

MiaRec DMCC settings

5.4. Verify DMCC device registration status in MiaRec

Navigate in the MiaRec web interface to Administration -> System -> Recording Interfaces and click Status link for Avaya DMCC interface.

MiaRec DMCC settings

In the Avaya DMCC status screen, click View DNCC registered devices link for the appropriate recorder instance (the screenshot below shows one instance).

MiaRec DMCC settings

In the Avaya DMCC devices screen, verify status of the registered devices. If any of devices shows failed state, then click on the extension link in that window to see the detailed error message.

MiaRec DMCC settings

If the Avaya DMCC registered devices screen shows none of devices (neither successfully registered nor failed), then probably the DMCC connection is not established to the AES server. In this case, navigate to Administration -> Maintenance -> System Log and check any error messages. The screenshot below shows that the DMCC login/password is rejected. Make the appropriate corrections to the configuration.

MiaRec DMCC settings

5.5. Check MiaRec trace log

MiaRec provides detailed logging for troubleshooting purposes. Navigate to Administration -> Maintenance -> Troubleshooting to enable log in MiaRec.

More details about MiaRec recorder trace

6. Additional references

Avaya TSAPI passive recording

1. Introduction

This article describes how to configure the MiaRec Call Recording System with the Avaya Application Enablement Services and Avaya Communication Manager to record incoming and outgoing phone calls.

MiaRec uses port mirroring on a network switch to capture media associated with the recorded stations and TSAPI interface of Avaya Application Enablement Services (AES) to extract agent and call state information.

Requirements:

  • Avaya Communication Manager v6.3.2 or higher
  • Avaya Application Enablement Services (AES) Server v6.3.1 or higher
  • TSAPI Basic License per each recorded extension and each monitored ACD Split / Hunt Group
  • Network Switch with Port Mirroring support (see A list of Switches with port mirroring)
  • Server for MiaRec with two network adapters (see Recommended server)

2. Network Configuration

MiaRec uses port mirroring function on a network switch to capture voice packet related to the agents' IP phones and softphones. MiaRec server needs to have two Network Interface Cards (NICs), one of which is used for port mirroring (capturing voice) and another is used for regular network connection. The first NIC doesn't need to have TCP/IP stack enabled (see Network adapter configuration)

Port mirroring function has to be configured on a network switch in the following way:

  • Ports of the C-LAN and MedPro cards should be configured as sources for port mirroring session
  • MiaRec capturing port should be configured as a destination for port mirroring session

Recording calls on Avaya S8700 and G650

Below is an example of port mirroring configuration on Extreme Networks Summit X250e-24p network switch.

For other models please refer to Port Mirroring Configuration.

Assuming that:

  • C-LAN card is connected to Port 1 of the Summit X250e
  • MedPro card is connected to Port 2 of the Summit X250e
  • MiaRec capturing NIC is connected to Port 24 of the Summit X250e

In this case you need to execute following commands on the switch:

enable mirroring port 24
mirroring add port 1
mirroring add port 2

Save configuration into permanent memory (NVRAM) otherwise port mirroring settings will be lost after switch reboot:

save config

3. Configure Avaya Communication Manager

This section presents configuration steps for the Avaya Communication Manager. It is assumed that an appropriate license file and authentication file have been installed on the server, and that login and password credentials are available.

The configuration and verification operations illustrated in this section were all performed using the Communication Manager System Administration Terminal (SAT).

The procedures include the following areas:

  • Verify the status CTI link for TSAPI service
  • Disable RTP encryption
  • Enable RTCP reporting
  • Disable IP-IP Direct Audio (optional)
  • Administer System Parameters Features

3.1. Verify the status of CTI link for TSAPI service

Log into the System Access Terminal (SAT) to enter the "status aesvcs cti-link" command. The link status should show no for maintenance busy (Mnt Busy), the Service State should indicate established and Version should be 6 or higher.

status aesvcs cti-link

                          AE SERVICES CTI LINK STATUS

CTI   Version  Mnt   AE Services      Service       Msgs     Msgs
Link           Busy  Server           State         Sent     Rcvd

1     7        no    aes              established   15       15




If the CTI link is not established, then follow instructions in chapter Administering Communication Manager for AE Services in document Application Enablement Services Administration and Maintenance Guide available at http://support.avaya.com

3.2. Disable RTP encryption

Execute the "list ip-codec-set" command.

list ip-codec-set

                                IP CODEC SETS

Codec  Codec 1     Codec 2     Codec 3     Codec 4     Codec 5
Set

  1    G.711MU
  2    G.711MU
  3    G.711MU
  4    G.711MU
  5    G.711MU
  6    G.711MU
  7    G.711MU

For each of codec sets execute the "change ip-codec-set N" command, where N is an index of set (from 1 to 7 in above example).

For example, to edit the first codec set, execute the "change ip-codec-set 1" command and make certain that Media Encryption list contains only a single value "none". If other values are presented there (for example, "aes"), then remove all other values except "none" as shown below:

change ip-codec-set 1                                           Page   1 of   2

                          IP Codec Set

    Codec Set: 1

    Audio        Silence      Frames   Packet
    Codec        Suppression  Per Pkt  Size(ms)
 1: G.711MU           n         2        20
 2:
 3:
 4:
 5:
 6:
 7:


     Media Encryption
 1: none
 2: 
 3:

Repeat this step for all the remaining codec sets.

3.3. Enable RTCP reporting

Enter the "change ip-network-region N" command, where N is an existing network region used for the agents' ip phones and softphones. Make certain that the RTCP Reporting Enabled field is set to "y", as shown below. The RTCP packets are used by MiaRec to map IP addresses to agent extensions.

change ip-network-region 1                                      Page   1 of  19
                               IP NETWORK REGION
  Region: 1
Location:         Authoritative Domain: voip.example.com
    Name:
MEDIA PARAMETERS                Intra-region IP-IP Direct Audio: yes
      Codec Set: 1              Inter-region IP-IP Direct Audio: yes
   UDP Port Min: 2048                      IP Audio Hairpinning? y
   UDP Port Max: 3029
DIFFSERV/TOS PARAMETERS                  RTCP Reporting Enabled? y
 Call Control PHB Value: 34      RTCP MONITOR SERVER PARAMETERS
        Audio PHB Value: 46       Use Default Server Parameters? y
        Video PHB Value: 26

3.4. Disable IP-IP Direct Audio (optional)

You can skip this step if recording of internal calls between IP phones is not needed.

Avaya Communication Manager supports "shuffling" of the media streams, which allows two IP phones to send media directly between each other bypassing the media gateway. "Shuffling" (IP-IP Direct Audio) should be disabled when internal calls between IP phones need to be recorded. IP-IP Direct Audio can be disabled either for individual IP phones or for a whole ip network region.

To disable IP-IP Direct Audio for individual IP phone, enter the "change station xxxxx", where xxxxx is phone's extension and change "Direct IP-IP Audio Connections" to "n" on Page 2.

Parameter "IP Audio Harpinning" is recommended to set to "y". In this case MedPro board acts as a proxy without allocating of resources on TDM bus.

change station 51001                                            Page   2 of   5
                                     STATION
FEATURE OPTIONS
           LWC Reception: spe              Auto Select Any Idle Appearance? n
          LWC Activation? y                         Coverage Msg Retrieval? y
  LWC Log External Calls? n                                    Auto Answer: none
             CDR Privacy? n                               Data Restriction? n
   Redirect Notification? y                     Idle Appearance Preference? n
 Per Button Ring Control? n                   Bridged Idle Line Preference? n
   Bridged Call Alerting? n                       Restrict Last Appearance? y
  Active Station Ringing: single
                                                         EMU Login Allowed? n
        H.320 Conversion? n          Per Station CPN - Send Calling Number?
       Service Link Mode: as-needed
         Multimedia Mode: enhanced
    MWI Served User Type:                       Display Client Redirection? n
              AUDIX Name:                      Select Last Used Appearance? n
             IP Hoteling? n                      Coverage After Forwarding? s
                                                   Multimedia Early Answer? n
 Remote Softphone Emergency Calls: as-on-local Direct IP-IP Audio Connections? n
  Emergency Location Ext: 51001         Always Use? n IP Audio Hairpinning? y

To disable IP-IP Direct Audio for all IP phones inside the IP network region, enter the "change ip-network-region N" command, where N is an existing network region used for the agents' ip phones and softphones and change "Intra-region IP-IP Direct Audio" and "Inter-region IP-IP Direct Audio" to "no".

Parameter "IP Audio Hairpinning" is recommended to set to "y".

change ip-network-region 1                                      Page   1 of  19
                               IP NETWORK REGION
  Region: 1
Location:         Authoritative Domain: voip.example.com
    Name:
MEDIA PARAMETERS                Intra-region IP-IP Direct Audio: no
      Codec Set: 1              Inter-region IP-IP Direct Audio: no
   UDP Port Min: 2048                      IP Audio Hairpinning? y
   UDP Port Max: 3029
DIFFSERV/TOS PARAMETERS                  RTCP Reporting Enabled? y
 Call Control PHB Value: 34      RTCP MONITOR SERVER PARAMETERS
        Audio PHB Value: 46       Use Default Server Parameters? y
        Video PHB Value: 26

Alternatively, instead of changing "IP-IP Direct Audio" parameter, you can change port mirroring configuration and mirror each IP phone's port rather than CLAN and MedPro ports (see below network diagram).

Such configuration of port mirroring allows a recording of internal calls without changing of "IP-IP Direct Audio" parameter.

Record internal calls on Avaya network

3.5. Administer System Parameters Features

Enter the "change system-parameters features" command. Navigate to Page 5, and verify that Create Universal Call ID (UCID) has value “y”. If not, then set it to "y" and set UCID Network Node ID to an unassigned node ID.

change system-parameters features                               Page   5 of  17
                        FEATURE-RELATED SYSTEM PARAMETERS

SYSTEM PRINTER PARAMETERS
  Endpoint:               Lines Per Page: 60

SYSTEM-WIDE PARAMETERS
                                     Switch Name:
            Emergency Extension Forwarding (min): 10
          Enable Inter-Gateway Alternate Routing? n
Enable Dial Plan Transparency in Survivable Mode? n
                              COR to Use for DPT: station

MALICIOUS CALL TRACE PARAMETERS
               Apply MCT Warning Tone? n   MCT Voice Recorder Trunk Group:

SEND ALL CALLS OPTIONS
     Send All Calls Applies to: station    Auto Inspect on Send All Calls? n

UNIVERSAL CALL ID
     Create Universal Call ID (UCID)? y    UCID Network Node ID: 9999
     Copy UCID for Station Conference/Transfer? n

Navigate to Page 13, and set Send UCID to ASAI to "y". This parameter allows for the universal call ID to be sent to MiaRec call recording application.

change system-parameters features                               Page  13 of  17
                        FEATURE-RELATED SYSTEM PARAMETERS

 CALL CENTER MISCELLANEOUS
                         Clear Callr-info: next-call
        Allow Ringer-off with Auto-Answer? n

    Reporting for PC Non-Predictive Calls? n


  ASAI
            Copy ASAI UUI During Conference/Transfer? n
        Call Classification After Answer Supervision? n
                                   Send UCID to ASAI? y

4. Configure Avaya Application Enablement Services

This section provides the procedures for configuring Avaya Application Enablement Services. The procedures include the following areas:

  • Verify TSAPI service licensing
  • Administer TSAPI link
  • Obtain Tlink name
  • Administer CTI user for MiaRec

4.1. Verify TSAPI service licensing

Prior to any administration, verify that the TSAPI service has been licensed properly. Open the AES OAM web interface by browsing to "https://ip-address-or-dns", where "ip-address-or-dns" is the IP address or DNS alias of the Appliation Enabledment Services server, and log in using the appropriate credentials (not shown).

Select Licensing -> WebLM Server Access in the left pane, to display the Web License Manager pop-up screen (not shown), and log in using the appropriate credentials.

Avaya AES WebLM Server Access

If the licenses are managed centrally on the System Manager, then select Services -> Licenses in the System Manager home screen. Otherwise, the Web License Manager screen is shown immediately.

Avaya System Manager Licenses

In the Web License Manager screen, select Application_Enablement under Licenses Products to display license capacity and current usage

Make certain that a number of TSAPI Simultaneous Users (licenses) is enough. MiaRec requires TSAPI Basic license for each recorded IP Phone and softphone and for each monitored ACD Split (Hunt Group). If the TSAPI service is not licensed, contact the Avaya sales team or business partner for a proper license file.

Avaya AES TSAPI licenses

4.2. Administer TSAPI link

To administer a TSAPI link, select AE Services -> TSAPI -> TSAPI Links from the left pan of the Management Console. The TSAPI Links screen is displayed, as shown below. If the TSAPI Link is not configured yet, then click Add Link to create one.

Avaya AES TSAPI Links

The Add TSAPI Links screen is displayed next.

The Link field is only local to the Application Enablement Services server, and may be set to any available number. For Switch Connection, select the relevant switch connection from the drob-down list. In this case, the existing switch connection "cm2" is selected. For Switch CTI Link Number, select the CTI Link number from Section 3.1. Make sure that ASAI Link Version is 6 or higher. Retain the default values in the remaining fields.

Avaya AES TSAPI Add Link

4.3. Obtain Tlink name

Select Security -> Security Database -> Tlinks from the left pane. The Tlinks screen shows a listing of the Tlink names. Locate the Tlink Name associated with the switch connection to Avaya Communication Manager. A new TLink name is automatically generated for the TSAPI service. Locate the TLink name associated with the relevant switch connection, which would use the name of the switch connection as part of the Tlink name. Make a note of the associated Tlink name, to be used later for configuring the MiaRec server.

In this case, the associated Tlink name is "AVAYA#CM2#CSTA#AES"'. Note the use of the switch connection "CM2" from Section 4.2 as part of the Tlink name.

If Tlink doesn't exist, then follow instructions in AE Services Administration in document Application Enablement Services Administration and Maintenance Guide available at http://support.avaya.com

Avaya AES Tlinks

4.4. Administer CTI user for MiaRec

Select User Management -> Add User from the left pane, to display the Add User screen in the right pane.

Enter desired values for User Id, Common Name, Surname, User Password, and Confirm Password. Retain the default value of “None” for Avaya Role, and select “Yes” from the CT User drop-down list. Click on Apply at the bottom of the screen (not shown below). Make a note of the User Id and Password, to be used later for configuring the MiaRec server.

Avaya AES Add User

Next, you need to change the security level for the CTI User as it needs to have unrestricted access privileges.

Select Administration -> Security Database -> CTI Users -> List All Users from the left pane. Choose the previously created CTI user, and click Edit.

Avaya AES Edit CTI User

The Edit CTI User screen appears. Tick the Unrestricted Access box and Apply Changes at the bottom of the screen.

Avaya AES Edit CTI User

5. Configure MiaRec Call Recording System

This section presents configuration steps for MiaRec call recording system. It is assumed that MiaRec is already installed on the server. The procedures include the following areas:

  • Install AES TSAPI Client
  • Administer MiaRec TSAPI link to AES

5.1. Install AES TSAPI Client

Download Application Enablement Services TSAPI Client from http://support.avaya.com

Install it on MiaRec server. During installation enter the IP address of the Avaya AES server in the Host Name or IP Address field, retaining the default port of 450 (see below screenshot). Click on Add to List and then Next to finish installation.

Avaya AES TSAPI Client install

5.2. Administer MiaRec link to AES

Navigate in the MiaRec web interface to Administration -> System -> Recording Interfaces and click Configure link for Avaya TSAPI interface.

MiaRec DMCC settings

In the Configure Recording Interface (Avaya TSAPI) screen, configure the following settings:

  • Option Enable should be checked
  • Option TSAPI Link should point to the obtained TLink in the Section 3.5. Obtain Tlink name.
  • Option TSAPI login and "TSAPI password** should be set to the credentials of CTI user created in Section 3.6. Administer CTI user for MiaRec.
  • Option Media Source should be set to Passive - port mirroring
  • Option Monitored phones should list all recorded extensions, comma-separated. A range of extensions is supported, like 3000-3100, 5001, 5002
  • Option Monitored ACD Splits should list all ACDs, which the recorded users may login to. MiaRec monitors ACDs for login/logout events. A range value is supported, like 4900-49100, 55000, 56000
  • Option Ignore dialing phase could be enabled to avoid recording of initial dialing phase of the outgoing call scenario
  • Retain default settings for other values

MiaRec DMCC settings

5.2. Enable passive recording

Navigate in the MiaRec web interface to Administration -> System -> Recording Interfaces and enable the following protocols:

  • Passive network capture
  • Avaya H.323
  • H.323
  • SIP (required if some of phones have SIP firmware)

MiaRec DMCC settings

6. Verification

This section provides the tests that can be performed to verify proper configuration of Avaya Communication Manager, Avaya Application Enablement Services and MiaRec call recording application.

6.1. Verify Avaya Communication Manager

On Avaya Communication Manager, verify the status of the administered CTI links by using the "status aesvcs cti-link" command. The link status should show "no" for maintenance busy (Mnt Busy) and the Service State should indicate "established".

status aesvcs cti-link

                          AE SERVICES CTI LINK STATUS

CTI   Version  Mnt   AE Services      Service       Msgs     Msgs
Link           Busy  Server           State         Sent     Rcvd

1     4        no    aes-server1      established   15       15

The "status aesvcs interface" command should indicate the interface is listening.

status aesvcs interface

                          AE SERVICES INTERFACE STATUS

Local Node        Enabled?  Number of     Status
                            Connections

procr             yes       1             listening

The "status aesvcs link" command will indicate the number of messages sent from, and received at the CLAN interface (or procr), to and from Avaya Application Enablement Services, including maintenance traffic.

status aesvcs link

                            AE SERVICES LINK STATUS

Srvr/  AE Services     Remote IP        Remote  Local Node      Msgs    Msgs
Link   Server                           Port                    Sent    Rcvd

01/01  aes-server1     10.0.0.25        43909   procr           224     209

Once the MiaRec call recording application is running, the "list monitored-station" command will show each station, which is monitored by MiaRec via TSAPI interface.

list monitored-station

                            MONITORED STATION

  Station     Association 1    Association 2    Association 3    Association 4
  Ext         CTI Link  CRV    CTI Link  CRV    CTI Link  CRV    CTI Link  CRV
  -------     -------------    -------------    -------------    -------------
32129          1          10
32130          1           9
32131          1          22
32132          1           7

6.2. Verify Avaya Application Enablement Services

On Application Enablement Services, verify the status of the switch connection by selecting Status -> Status and Control -> Switch Conn Summary from the left pane. Verify that the Conn State is “Talking” for the switch connection associated with Avaya Communication Manager, and that the Associations column reflects the total number of monitored skill groups and agent stations as configured previously.

Avaya AES Switch Connection Summary

Verify the status of the TSAPI link by selecting Status -> Status and Control -> TSAPI Service Summary from the left pane. Verify the Conn Status is “Talking” as shown below.

Avaya AES TSAPI Link Details

Verify the status of the CTI User by selecting Status -> Status and Control -> TSAPI Service Summary from the left pane. Click the User Status button (not shown below). The CTI User Status screen is displayed. Verify that an open session exists for the CTI user created for MiaRec as shown below. This verification step assumes that MiaRec application is configured properly and running.

Avaya AES CTI User Status

6.3. Verify TSAPI device monitoring status in MiaRec

Navigate in the MiaRec web interface to Administration -> System -> Recording Interfaces and click Status link for Avaya TSAPI interface.

MiaRec DMCC settings

In the Avaya TSAPI status screen, click View TSAPI monitored devices link for the appropriate recorder instance (the screenshot below shows one instance).

MiaRec DMCC settings

In the Avaya TSAPI monitored devices screen, verify status of the monitored devices. If any of devices shows failed state, then click on the extension link in that window to see the detailed error message.

MiaRec DMCC settings

The error message describes the actual reasons of failure. Read the message and apply appropriate corrections. For example, the message in the following screenshot says that device identifier (extension) is not valid. In this case, remove this extension from the Monitored Phones list in configuration.

MiaRec DMCC settings

If the Avaya TSAPI monitored devices screen shows none of devices (neither successfully monitored nor failed), then probably the TSAPI link connection is not established to AES server. In this case, navigate to Administration -> Maintenance -> System Log and check any error messages. The screenshot below shows that the TSAPI login/password is invalid. Make the appropriate corrections to the configuration.

MiaRec DMCC settings

6.4. Check MiaRec trace log

MiaRec provides detailed logging for troubleshooting purposes. Navigate to Administration -> Maintenance -> Troubleshooting to enable log in MiaRec.

More details about MiaRec recorder trace

7. Additional references

Avaya SBCE SIPREC call recording

This guide provides instructions for configuring SIPREC-based call recording on Avaya Session Border Controller for Enterprise (SBCE) in Avaya Aura environment.

Note, this guide covers SIPREC-related configuration only.

It assumes that Avaya Communication Manager, Session Manager and SBCE are pre-configured properly and you can make calls from local endpoints to SIP Trunk through SBCE, and, if applicable, calls from Remote Workers to SIP Trunk or local endpoints.

01. How it works

The Session Recording Protocol (SIPREC) is an open SIP-based protocol for call recording. The standard is defined by Internet Engineering Task Force (IETF). Avaya SBCE acts as the Session Recording Client, while MiaRec acts as the Session Recording Server. Recording of a media session is done by sending a copy of a media stream to the recording server. Metadata is the information that is passed by the recording client to the recording server in a SIP session. The recording metadata describes the communication session and its media streams, and also identifies the participants of the call.

When call passes through SBCE to SIP Trunk, the call metadata and media are forked to the recording server using SIPREC protocol. MiaRec application records call sessions. End users can access recordings using web user interface.

Avaya SBCE SIPREC call recording

Prerequisites:

  • Avaya SBCE v.7.1 or newer (older versions do not support SIPREC or have limited support)
  • Every recorded call additionally requires one standard and one advanced license on Avaya SBCE

Supported call scenarios:

  • Inbound/outbound calls via SIP Trunk to local endpoints at the enterprise site

    Avaya SBCE SIPREC call recording

  • Inbound/outbound calls via SIP Trunk to Remote Workers

    Avaya SBCE SIPREC call recording

  • Internal calls between Remote Workers and local endpoints at the enterprise site

    Avaya SBCE SIPREC call recording

  • Internal calls between Remote Workers

    Avaya SBCE SIPREC call recording

Not supported call scenarios:

  • Internal calls between local endpoints at the enterprise site. Avaya SBCE is not in a media path for this scenario, so call recording cannot be done using SIPREC on the SBCE.

02. Access Avaya SBCE web interface

Access the Session Border Controller using a web browser by entering the URL https://, where is the private IP address configured at installation. A log in screen is presented. Log in using the appropriate username and password.

Avaya SBCE SIPREC configuration

Once logged in, a dashboard is presented with a menu on the left-hand side. The menu is used as a starting point for all configuration of the Avaya SBCE.

Avaya SBCE SIPREC configuration

03. Add Server Configuration Profile

To define the MiaRec recording server, navigate to Global Profiles -> Server Configuration in the main menu on the left hand side. Click on Add and enter an appropriate name in the pop-up menu.

Avaya SBCE SIPREC configuration

Click on Next and enter details in the dialogue box:

  • In the Server Type drop down menu, select Recording Server.
  • Click on Add to enter an IP address
  • In the IP Addresses / FQDN box, type the MiaRec recording server interface address.
  • In the Port box, enter the port to be used for the listening port configured on the MiaRec (TLS or TCP). This guide describes TCP transport configuration.
  • In the Transport drop down menu, select TCP.

Avaya SBCE SIPREC configuration

Click on Next to configure Hearbeat as follows:

  • Enable Heartbeat with method OPTIONS

Avaya SBCE SIPREC configuration

Click on Next to configure Grooming as follows:

  • Enable Grooming which allows us to support multiple connections.
  • No interworking profile required for MiaRec
  • If using TLS, then select the Client profile created (note, the configuration of TLS profile is not covered in this guide)

Avaya SBCE SIPREC configuration

Click Finish

04. Add Routing Profile for Recording Server

Routing information is required for routing recordings to MiaRec. The IP addresses and ports defined here will be used as the destination addresses for signalling.

To define routing to the MiaRec SIP Trunk, navigate to Global Profiles -> Routing in the main menu on the left hand side. Click on Add and enter an appropriate name in the dialogue box.

Avaya SBCE SIPREC configuration

Click on Next and enter details for the Routing Profile:

  • Click on Add to specify the IP address for the MiaRec SIP trunk.
  • Assign a priority in the Priority / Weight field. If only a single recording server is used, then choose 1. If multiple recordings servers are configured for load balancing / auto-failover, then choose priority/weight for each server accordingly.
  • Select the recording server defined in Step 2 in the Server Configuration drop down menu. This automatically populates the Next Hop Address field

Avaya SBCE SIPREC configuration

Click Finish.

05. Define Application Rules

An application rules needs to be defined for MiaRec. To create a new Application Rules, navigate to Domain Policies -> Application Rules. Click on Add and enter an appropriate name in the pop-up menu and select Next.

Avaya SBCE SIPREC configuration

On the Application Rule pop-up windows check In and Out boxes for Audio, and select Finish.

Avaya SBCE SIPREC configuration

06. Define Media Rules

Audio formats need to be specified for MiaRec. To create a Media Rule for MiaRec, navigate to Domain Policies -> Media Rules. Click on Add and enter an appropriate name in the pop-up menu and select Next.

Avaya SBCE SIPREC configuration

On the Media Rule pop-up, under Audio Encryption, select a Preferred Format #1 and select continue. If using, SRTP select SRTP_AES_CM_128_128_HMAC_SHA1_80 or for RTP select RTP (it is recommended to use SRTP when TLS is enabled as well. Otherwise, use RTP), select Next.

Avaya SBCE SIPREC configuration

On the Media Rule pop-up, under the Audio Codec section, select box for Codec Prioritization. For Preferred Codecs select PCMU, PCMA and telephone-event, and click >.

Avaya SBCE SIPREC configuration

Select Next and Finish to save the configuration (not shown).

07. Configure UCID

UCID needs to be enabled for Signaling Rules that are defined for Session Manager and MiaRec. Navigate to Domain Policies -> Signaling Rules. Select the policy for Session Manager and select the UCID tab. Click Edit, check box for Enabled and type in a unique value in Node ID field. Select Finish to save configuration.

Perform similar steps for MiaRec signaling rule.

Notes:

  • UCID will need to be enabled on the Signaling rule for MiaRec and the one for SM.

  • Node ID should be unique on the SBC and across the solution.

  • Protocol Discriminator should match what is on CM configuration. This is typically 0x00 as that is the recommended value.

Avaya SBCE SIPREC configuration

08. Define End Point Policy Group

To define an End Point Policy Group for MiaRec, navigate to Domain Policies -> End Point Policy Group and select Add. Click on Add and enter an appropriate name in the pop-up menu and select Next.

Avaya SBCE SIPREC configuration

On the Policy Group pop-up, select the Application Rule defined in Step 5 and select the Media Rule defined in Step 6. Select Finish to save configuration.

Avaya SBCE SIPREC configuration

09. Define Session Policies

To define Session Policy for MiaRec, navigate to Domain Policies -> Session Policies and select Add. Click on Add and enter an appropriate name in the pop-up menu and select Next.

Avaya SBCE SIPREC configuration

On the Session Policy pop-up, select box for Media Anchoring and Recording Server.

For Recording Type select Full Time.

For Routing Profile select the Routing profile configured in Step 4.

Avaya SBCE SIPREC configuration

10. Define Session Flows

To define Session Policy for MiaRec, navigate to Device Specific Settings -> Session Flows and select Add. Click on Add and enter an appropriate Flow Name in the pop-up menu and select the Session Policy defined in Step 9. Select Finish to save the configuration.

Avaya SBCE SIPREC configuration

11. Define Server Flows

The End Point Server Flows allow calls to be recorded by MiaRec when they are passing through Avaya SBCE to the Service Provider’s SIP Trunk. Navigate to Device Specific Setting -> End Point Flows -> Server Flows.

Create two Server Flows for MiaRec, one to record calls coming in from Service Provider’s SIP Trunking service and another for calls coming in from Session Manager.

Avaya SBCE SIPREC configuration

Server flow 1. SIP Trunk -> Session Manager, i.e. inbound calls

Configure:

  • For Server Configuration select the one created in Step 3.
  • For Received Interface select the one used towards Service Provider for SIP Trunk
  • For Signaling Interface select the one used towards Session Manager for SIP signaling
  • For Media Interface select the one used towards Session Manager for RTP media
  • For Endpoint Policy Group select the one created in Step 8
  • For Routing Profile select default i.e. Routing profile without any IP address
  • For Topology Hiding select None. The SBC will send the same information it sends to SM based on the TH set in the SM server flow.

Avaya SBCE SIPREC configuration

Server flow 2. Session Manager -> SIP Trunk, i.e. outbound calls

This server flow is similar to the previous one, but for reverse call direction, outbound call through Service Provider's SIP Trunk. The Received Interface, Signaling Interface and Media Interface are reversed.

Configure:

  • For Server Configuration select the one created in Step 3.
  • For Received Interface select the one used towards Session Manager for SIP signaling
  • For Signaling Interface select the one used towards Service Provider for SIP signaling
  • For Media Interface select the one used towards Service Provider for RTP media
  • For Endpoint Policy Group select the one created in Step 8
  • For Routing Profile select default i.e. Routing profile without any IP address
  • For Topology Hiding select None. The SBC will send the same information it sends to SM based on the TH set in the SM server flow.

Avaya SBCE SIPREC configuration

Server flow 3. Remote worker calls.

If Remote Workers connect to SBCE via external network interface different from the Service Provider's SIP Trunk, then an additional server flow is required to record Remote Worker calls:

  • For Server Configuration select the one created in Step 3.
  • For Received Interface select the one used towards Remote Workers
  • For Signaling Interface select the one used towards Session Manager for SIP signaling
  • For Media Interface select the one used towards Session Manager for RTP media
  • For Endpoint Policy Group select the one created in Step 8
  • For Routing Profile select default i.e. Routing profile without any IP address
  • For Topology Hiding select None. The SBC will send the same information it sends to SM based on the TH set in the SM server flow.

12. Configure MiaRec SIPREC recordging 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 Avaya SBCE. 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 Avaya SBCE to establish SIPREC connection. Make sure that port forwarding is configured properly on your NAT router. If MiaRec server and Cisco CUBE 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

Broadsoft call recording

Broadsoft SIPREC recording

LDAP integration

Cisco CUBE SIPREC call recording

Cisco CUBE SIPREC configuration

This guide provides instructions for configuring call recording on Cisco CUBE using SIPREC protocol.

How it works

The Session Recording Protocol (SIPREC) is an open SIP-based protocol for call recording. The standard is defined by Internet Engineering Task Force (IETF). Cisco CUBE acts as the Session Recording Client, while MiaRec acts as the Session Recording Server. Recording of a media session is done by sending a copy of a media stream to the recording server. Metadata is the information that is passed by the recording client to the recording server in a SIP session. The recording metadata describes the communication session and its media streams, and also identifies the participants of the call.

Cisco CUBE SIPREC call recording

Restrictions for Cisco CUBE SIPREC Recording

Cisco CUBE doesn't support SIPREC-based recording for the following calls:

  • IPv6-to-IPv6 call recording
  • IPv6-to-IPv4 call recording if the recording server is configured on the IPv6 call leg
  • Calls that do not use Session Initiation Protocol (SIP). Must be a SIP-to-SIP call flow
  • Flow-around calls
  • Session Description Protocol (SDP) pass-through calls
  • Real-time Transport Protocol (RTP) loopback calls
  • High-density transcoder calls
  • Secure Real-time Transport Protocol (SRTP) passthrough calls
  • SRTP-RTP calls with forking for SRTP leg (forking is supported for the RTP leg)
  • Multicast music on hold (MOH)
  • Recording is not supported if CUBE is running a TCL IVR application
  • Media mixing on forked streams is not supported
  • Digital Signal Processing (DSP) resources are not supported on forked legs

Restrictions for Video Recording

  • If the main call has multiple video streams (m-lines), the video streams other than the first video m-line are not forked
  • Application media streams of the primary call are not forked to the recording server
  • Forking is not supported if the anchor leg or recording server is on IPv6

Configuration of SIPREC on Cisco CUBE

Step 1. Enter the configuration mode

Device> enable
Device# configure terminal

Step 2. Choose a dummy dial-peer tag for the recorder.

Note, 8000 in this example is a dummy dial-peer tag for the recorder. You need to make sure it doesn't conflict the the existing dial-peers.

Execute the following command to view a list of the existing dial-peers:

Device# show dial-peer voice

Check if 8000 is not used yet. Otherwise, choose a different dial-peer tag like 8002 and make the corresponding changes to the commands in the next steps.

Step 3. Create a SIPREC recorder profile

Here we choose 200 for a recording profile tag. If 200 is not available, then choose a different value and make the corresponding changes to the commands in the next steps.

Device(config)# media profile recorder 200
Device(cfg-mediaprofile)# media-type audio
Device(cfg-mediaprofile)# media-recording 8000
Device(cfg-mediaprofile)# exit

Where:

  • 8000 is a dummy dial-peer for the recorder (see Step 2)
  • 200 is a recorder profile tag

Step 4. Create a media class that points to SIPREC recorder

Here we choose 100 for a media class tag. If 100 is not available, then choose a different value and make the corresponding changes to the commands in the next steps.

Device(config)# media class 100
Device(cfg-mediaclass)# recorder profile 200 siprec
Device(cfg-mediaclass)# exit

Where:

  • 100 is a media class tag
  • 200 is a recorder profile tag (configured above)

Step 5. Create s dial-peer pointing to the MiaRec recorder.

Device(config)# dial-peer voice 8000 voip
Device(config-dial-peer)# description MiaRec SIPREC recorder
Device(config-dial-peer)# media class 100
Device(config-dial-peer)# destination-pattern 8000
Device(config-dial-peer)# session protocol sipv2
Device(config-dial-peer)# session target ipv:10.1.2.3:5080
Device(config-dial-peer)# session transport tcp
Device(config-dial-peer)# exit

Where:

  • 8000 is a dummy dial-peer for the recorder (configured above)
  • 10.1.2.3:5080 is an IP address and port of the recorder (change it to the ip-address of your MiaRec recording server)
  • destination-pattern 8000 is a dummy configuration. It is ignored by CUBE because this dial-peer is a recorder rather than SIP trunk.

Step 6. Assign recorder to the existing dial peer(s).

It is recommended to assign the recorder to the incoming dial-peer rather than the outgoing peer.

First, check your existing dial-peers by running command:

Device# show dial-peer voice

In below example, we modify the existing dial-peer 1 that matches inbound call legs (your dial-peer tag may differ).

Second, modify the existing dial pear by adding command media-class 100. This command activates call recording on dial-peer.

dial-peer voice 1 voip
description Generic incoming dial match
session protocol sipv2
incoming called-number .
media-class 100
...

With such configuration, SIPREC recording will be enabled on all calls passing through CUBE.

If you need to enable SIPREC recording on selective call scenarios, then check [2].

References:

MiaRec SIPREC configuration

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 Cisco CUBE. 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 Cisco CUBE to establish SIPREC connection. Make sure that port forwarding is configured properly on your NAT router. If MiaRec server and Cisco CUBE 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

Cisco UCM call recording

Cisco active recording (Built-in-Bridge)

This guide describes the configuration procedures required for call recording on Cisco Unified Communication Manager (UCM) platform and phones that have Built-in-Bridge (BiB) capability.

Requirements

The features utilized in this method of recording require the following:

Overview

This guide describes the configuration procedures required for call recording on Cisco Unified Communication Manager (UCM) platform and phones that have Built-in-Bridge (BiB) capability.

How it works

The MiaRec call recording system utilizes Built-in-Bridge call monitoring and recording capability available in 3rd generation of Cisco phones. Cisco UCM establishes SIP trunk connections to MiaRec recording server and notifies the latter when call is started. Cisco IP phone relays RTP media directly to the recorder.

Record Calls on Cisco Unified Communications Manager - Network Diagram

Cisco phones supporting Built-in-Bridge feature

The following table lists Cisco IP phone models, which support Built-in-Bridge feature for call recording and monitoring.

Phone modelSupported protocols
Cisco 6901 not supported
Cisco 12 S not supported
Cisco 12 SP not supported
Cisco 30 SP+ not supported
Cisco 3905 not supported
Cisco 3911 not supported
Cisco 6901 not supported
Cisco 6911 SCCP, SIP
Cisco 6921 SCCP, SIP
Cisco 6941 SCCP, SIP
Cisco 6945 SCCP, SIP
Cisco 6961 SCCP, SIP
Cisco 7811 SIP
Cisco 7821 SIP
Cisco 7841 SIP
Cisco 7861 SIP
Cisco 7902 not supported
Cisco 7905 not supported
Cisco 7906 SCCP, SIP
Cisco 7910 not supported
Cisco 7911 SCCP, SIP
Cisco 7912 not supported
Cisco 7914 Sidecar SCCP
Cisco 7915 Sidecar SCCP, SIP
Cisco CKEM Sidecar SIP
Cisco 7920 not supported
Cisco 7921 SCCP
Cisco 7925 SCCP
Cisco 7926 SCCP
Cisco 7931 SCCP, SIP
Cisco 7935 not supported
Cisco 7936 not supported
Cisco 7937 SCCP
Cisco 7940 not supported
Cisco 7941 SCCP, SIP
Cisco 7941G-GE SCCP, SIP
Cisco 7942 SCCP, SIP
Cisco 7945 SCCP, SIP
Cisco 7960 not supported
Cisco 7961 SCCP, SIP
Cisco 7961G-GE SCCP, SIP
Cisco 7962 SCCP, SIP
Cisco 7965 SCCP, SIP
Cisco 7970 SCCP, SIP
Cisco 7971 SCCP, SIP
Cisco 7975 SCCP, SIP
Cisco 7985 SCCP, SIP
Cisco 8811 SIP
Cisco 8831 SIP
Cisco 8841 SIP
Cisco 8845 SIP
Cisco 8851 SIP
Cisco 8861 SIP
Cisco 8865 SIP
Cisco 8941 SCCP, SIP
Cisco 8945 SCCP, SIP
Cisco 8961 SIP
Cisco 9951 SIP
Cisco 9971 SIP
Cisco DX650 SIP
Cisco E20 not supported
Cisco EX60 not supported
Cisco EX90 not supported
Cisco CTS 500 not supported
Cisco CTS 500-32 not supported
Cisco ATA 186 not supported
Cisco ATA 187 not supported
Cisco ATA 188 not supported
Cisco IP Communicator SCCP, SIP
Cisco Jabber for Windows SCCP, SIP
Cisco Jabber for Mac SCCP, SIP
Cisco Jabber for iPad not supported
Cisco Jabber for Android not supported
Cisco Unified Personal Communicator not supported
Cisco VGC Phone not supported
VG224 not supported
VG248 not supported
CTI Port not supported
CTI Remote Device not supported
CTI Route Point not supported

Last table update: 2015/10/01

Identify phones that support Built-in-Bridge recording

Up to date list of phone models that support Built-in-Bridge recording may be received with the following instructions:

  1. Start Cisco Unified Reporting by choosing Cisco Unified Reporting in the Navigation menu in Cisco Unified Communications Manager Administration and clicking Go.
  2. Click System Reports in the navigation bar.
  3. In the list of reports that displays in the left column, click the Unified CM Phone Feature List option.
  4. Click the Generate a new report link to generate a new report, or click the Unified CM Phone Feature List link if a report already exists.
  5. To generate a report of all devices that support recording, choose these settings from the respective drop-down list boxes and click the Submit button:

    • Product: All
    • Feature: Record
  6. The List Features pane displays a list of all devices that support the recording feature. You can click on the Up and Down arrows next to the column headers (Product or Protocol) to sort the list.

Identify phones supporting built-in-bridge

Configure CUCM

Create SIP profile for recorder

Use the Device > Device Settings > SIP Profile menu option in Cisco Unified Communications Manager Administration to create SIP profile for recorder.

The following figure illustrates creating a SIP profile for the recorder.

Create SIP profile for recorder

Make sure that the Deliver Conference Bridge Identifier option is checked. When enabled it allows to deliver additional information (specifically, the b-number that identifies a conference bridge) to the recorder across the SIP trunk. If the check box is left unchecked, the far-end information for the remote conference remains empty. Check the Deliver Conference Bridge Identifier check box on the remote cluster SIP profile as well.

Create SIP profile for recorder 2

Checking this check box is not required for recording, but the conference bridge identifier helps to group multiple call segments belonging to the same conference into one interaction, like shown in below screenshot:

Group calls into interaction

Configure SIP OPTIONS Ping

In multi-server setup, it is recommended to enable SIP Options Ping feature for each recording server. In a single-server setup, this feature should be disabled (see details below).

  • Single-server setup - disable SIP OPTIONS Ping
  • Multi-server setup - enable SIP OPTIONS Ping

Cisco UCM starting from v.8.5(1) supports SIP OPTIONS Ping feature. Cisco UCM periodically sends a SIP OPTIONS (ping) message to each recording server to detect its availability. If the recording server is unavailable – indicated by either no response, response of “408 Request Timeout” response of “503 Service Unavailable”, Cisco UCM marks this recording server as unavailable. It skips that server in the round-robin or sequential list of recording servers. The SIP Options Ping feature allows to detect availability of the recording server earlier, without having to wait until a call is ready to be recorded.

However, in single-node deployments, SIP Options Ping is not recommended. Not only is it not helpful, but it can result in unnecessary failure recovery delays.

Create SIP OPTIONS Ping

Create SIP Trunk Security Profile

Create SIP Trunk Security Profile for each MiaRec recording server.

Use the System > Security > SIP Trunk Security Profile menu option in Cisco Unified Communications Manager Administration to create SIP Trunk Security profile for recorder.

  • Set Incoming Transport Type to TCP+UDP.
  • Set Outgoing Transport Type to TCP (this setting has to match the configuration of MiaRec). TCP is recommended.
  • Uncheck option Enable Digest Authentication
  • Set Device Security Mode parameter to Non Secure.

Create SIP Trunk Security Profile

Create a SIP Trunk that points to the recorder

Use the Device > Trunk menu option in Cisco Unified Communications Manager Administration to create SIP trunk that points to the recorder.

  • Ensure that the Media Termination Point Required check box is unchecked.
  • Select the Run On All Active Unified CM Nodes check box.

Create SIP Trunk

Make sure the SIP Privacy option is set to None, otherwise you will see in call details a text "Anonymous" instead of user's extension.

Create SIP Trunk

In SIP Information section configure:

  • Destination Address should point to ip-address or DNS name of the recorder server
  • Destination Port should match the port on which MiaRec recorder is listening for messages from CUCM (see configuration of MiaRec below)
  • Select the previously created SIP Trunk Security Profile for the recorder
  • Select the previously created SIP Profile for the recorder

Create SIP Trunk

Create a recording profile

Use the Device > Device Settings > Recording Profile menu option in Cisco Unified Communications Manager Administration to create recording profile.

The following figure illustrates creating a recording profile.

Set Recording Destination Address to the directory number that associates the recorder with this recording profile. The only guideline for this number: it should be possible for UCM to route it to the SIP trunk where the recorder is defined. No user is going to directly call this number, this is internal to the system. Make sure it does not collide with your numbering plan. This is why the example shows '7777'.

Set Recording Calling Search Space to the CSS that includes partitions containing the user phones and the partition that you set up for the MiaRec SIP Trunk. Important! Recording will not work if CSS of the Recording Profile and phones do not match! The screenshot below shows None value, but in most production configuration, it should be explicitly set to the correct CSS.

Create Recording Profile

Create a route pattern/group for the recorder

This configuration step depends on how many recorders are used in a cluster, one or multiple.

For a single recorder, create a route pattern.

For multiple recorders in HA configuration, create a route group.

Single server configuration

Use the Call Routing > Route/Hunt > Route Pattern menu option in Cisco Unified Communications Manager Administration to create a route pattern for the MiaRec recorder SIP trunk:

  • Route Pattern should match to the directory number associated with MiaRec recorder. This DN is used to reach the SIP Trunk of MiaRec recorder. No user is going to directly call this number manually. Make sure it does not collide with your numbering plan. This is why the example shows '7777'.

  • Set Route partition to the partition that includes the user phones.

  • In Gateway/Route List select the SIP trunk that points to the announcement player

Reoute Pattern Configuration

Multiple servers configuration

How it works

Cisco Built-in-Bridge redundant recorder

Each recording server in Cisco UCM is configured as a separate SIP Trunk. Cisco UCM will failover automatically from the primary recording server to the secondary in case of failure.

Create a new Route Group

Use the Call Routing > Route/Hunt > Route Group menu option in Cisco Unified Communications Manager Administration to create a route group for the MiaRec SIP trunk:

  • Assign the previously created SIP trunk(s) to this route group at the Find Device to Add to Route Group pane. Select the desired SIP trunk(s) and click on the Add to Route Group button.
  • Set the Distribution Algorithm setting to Top Down. Note, the Circular algorithm is not suitable for call recording SIP Trunk because it causes CUCM to send one side of audio one recorder and another side to another recorder (during playback, you will hear one side of conversation).

Reoute Pattern Configuration

Create a new route list

Select Call Routing > Route/Hunt > Route List menu item and click on the Add New button.

  • Select the appropriate Cisco Unified Communications Manager Group and click on the Save button.
  • Click on the Add Route Group button at the Route List Member Information panel.
  • Select the previously created route group at the Route Group setting, then click Save.
  • At the Route List Configuration page click on the Save button.

Create a new route pattern

Route Pattern should match to the Recording Destination Address in the previously created recording profile:

  • Set Route partition to the partition that includes the user phones.
  • In Gateway/Route List select the route list of which the recorder is a member.

Reoute Pattern Configuration

Enable Built-in-Bridge for all phones (optional)

Built-in-Bridge setting can be enabled on per-phone basis or on system level (default to all phones).

Access the System > Service Parameters menu option in Cisco Unified Communications Manager Administration, select your CUCM server from the Server list and Cisco CallManager from the Service list:

Service Parameter Configuration

To enable Built-in-Bridge on system level change the option Clusterwide Parameters (Device - Phone) -> Builtin Bridge Enable to On:

Clusterwide Builtin Bridge Enable

Codecs configuration

Codecs iLBC, iSAC, L16 and AAC-LD should be disabled for Recording-Enabled devices as they are not supported by MiaRec recording system at the moment.

Use the System > Service Parameters menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

Change the following settings of group Clusterwide Parameters (System - Location and Region):

  • iLBC Codec Enabled to Enabled for All Devices Except Recording-Enabled Devices
  • iSAC Codec Enabled to Enabled for All Devices Except Recording-Enabled Devices
  • Default Intraregion Max Audio Bit Rate to 64 kbps (G.722, G.711)

Codecs Configuration

Disable 256kpbs wideband codec

Latest models of Cisco phones support high quality 256kbps wideband codec for phone-to-phone communications withing the same region. Unfortunately, this codec is not supported by Cisco Built-in-Bridge recording method and it should be disabled otherwise internal calls between users will not be recorded.

Navigate to the System > Region menu option in Cisco Unified Communications Manager Administration and change per-region setting Max Audio Bit Rate to either Use System Default or 64 kbps (G.722, G.711) as shown in below screenshot.

256kbps Codecs Configuration

Recording of conference calls

Recording of conference calls on Cisco platform has the following limitations:

  • Cisco UCM doesn't support re-negotiated of audio codecs for calls which are recorded with Built-in-Bridge method.
  • The Cisco Software Conference Bridge supports only G.711 and 256k wideband codecs.

The following call scenario may occur:

  • One user makes a call to another user. If these two users use Cisco phones, then G.722 wideband codec is chosen for such call.
  • Then one of users tries to create a 3-way conference and add the third user to the conference.
  • CUCM creates a software-based conference to mix audio from three users. The software-based conference doesn’t support G.722 codec.
  • CUCM needs to re-negotiate codec with each of users and change it from G.722 to G.711.
  • But CUCM cannot do that because such call is recorded with BiB method and codec is fixed for such call.
  • As a result a user, who tries to create a conference is dropped from a conference.

There are two workarounds for this situation:

  1. Disable G.722 codec for users, which are recorded with BiB method.

  2. Allocate codec transcoding resources on Cisco platform to automatically convert audio from one codec to another on-flight.

To disable G.722 codec, change the setting G.722 Codec Enabled to Enabled for All Devices Except Recording-Enabled Devices.

G.722 Codecs Configuration

Troubleshooting issues with codecs

Follow the instructions in the following article to determine if issue with call recording is caused by codecs:

Configure phones

Enable Built-in-Bridge on per-phone basis

Note, Built-in-Bridge option may be configured clusterwide for all phones.

Use the Device > Phone menu option in Cisco Unified Communications Manager Administration to enable Built-in-Bridge option.

The following figure illustrates turning on the IP phone Built-in-Bridge to allow monitoring or recording.

Enable Built-in-Bridge

Enable recording for a line appearance

Use the Device > Phone menu option in Cisco Unified Communications Manager Administration to configure line appearance of particular phone.

  • To enable recording of an agent, set the Recording Option in the line appearance of the agent to one of the following options:

    • Automatic Call Recording Enabled
    • Selective Call Recording Enabled
  • In the Recording Profile option select the previously created recording profile from the drop-down list box

The following figure illustrates enabling recording for a line appearance.

Line configuration

Configure MiaRec

In MiaRec web portal navigate to the Administration -> System Configuration -> Recording Interfaces menu.

Click Configure for Cisco Built-in-Bridge recording interface.

Recording interfaces

Inside the opened dialog change the following settings:

Option Description
Signaling UDP port and Signaling TCP port These port values should be set to the same values as configured in step Create a SIP Trunk that points to the recorder
Begin RTP port range and End RTP port range RTP port range should be set to values not conflicting to other recording interfaces or other networking applications running on the same host as MiaRec application. Make sure that the port range is large enough for anticipated number of concurrently recorded calls. One concurrent call requires two UDP ports for receiving media streams from agent's phone.
Public Ip-address Public IP address if MiaRec server is located behind NAT. Make sure that port forwarding is configured properly on your NAT router. If MiaRec server is not behind NAT, then leave this parameter empty.
No-Audio Begin Timeout This timeout value specifies how long to wait for the first RTP media packet before give up.
No-Audio Normal Timeout In case of RTP transmission stop, this timeout value specifies how long to want for RTP restoration before forcibly completing call recording.

Cisco active recording

Configure firewall

If firewall is running on MiaRec recording server, then add exclusion rules for the following ports as described in step Configure MiaRec:

  • Signaling UDP Port and Signaling TCP Port
  • Begin/End RTP port range (UDP)

Optional configuration

Configure tones for recording (optional)

Set the service parameters for playing tone to True to allow tone to be played either to agent only, to customer only, or to both.

Use the System > Service Parameters menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

Change corresponding options of group Clusterwide Parameters (Feature – Call Recording).

The following figure illustrates using service parameters to configure tones.

Play Recording Notification Tone

[Howto] Configure SIP/TLS for SIP Trunk (optional)

This guide describes how to configure in Cisco UCM a SIP/TLS encrypted connection for SIP Trunk towards MiaRec recorder.

1. Configure Signaling TLS port in MiaRec

Navigate in MiaRec web portal to Administration -> Recording Interfaces -> Cisco BiB Configuration.

Configure the listening port in parameter Signaling TLS port, for example port 5071.

SIP/TLS for SIP Trunk

Important! If firewall is enabled on MiaRec server, make sure it allows inbound connection to this port.

MiaRec application automatically generates certificate. The location of the certificate file is configured in the same screen in the parameter SSL certificate file. By default, it has name tls_certificate.pem.

SIP/TLS for SIP Trunk

Locate this file on the MiaRec recording server. We will need to import this file into CUCM.

On Windows, the file is located in the same directory as MiaRec.exe file (by default, C:\Program Files (x86)\MiaRec Business\Bin).

On Linux, the file is located in /opt/miarec/shared or in older versions /var/lib/miarec.

2. Import MiaRec SSL certificate into Cisco UCM

Login to Cisco Unfied OS Administration using Cisco UCM admin password. Navigate to Security > Certificate Management and click Upload Certificate/Certificate Chain.

  • Select CallManager-trust for Certificate Purpose
  • Upload the SSL certificate file from MiaRec server

SIP/TLS for SIP Trunk

3. Configure SIP Trunk Security Profile

Create SIP Trunk Security Profile for SIP/TLS connection to MiaRec recording server.

Use the System > Security > SIP Trunk Security Profile menu option in Cisco Unified Communications Manager Administration to create SIP Trunk Security profile for recorder.

  • Set Device Security Mode parameter to Encrypted.
  • Set Incoming Transport Type to TLS.
  • Set Outgoing Transport Type to TLS (this setting has to match the configuration of MiaRec).
  • Uncheck option Enable Digest Authentication
  • Configure Incoming Port. CUCM will send SIP messages to MiaRec from this port. CUCM requires a unique port for each configured SIP Trunk. If the default port 5061 is busy, then try another port like 5062, 5063, etc.

SIP/TLS for SIP Trunk

4. Configure SIP Trunk

Use the Device > Trunk menu option in Cisco Unified Communications Manager Administration to edit the previously created non-secure SIP trunk that points to the MiaRec recorder.

In SIP Information section configure:

  • Destination Port should match the port on which MiaRec recorder is listening for messages from CUCM (5071 in our example)
  • Select the previously created SIP Trunk Security Profile (TLS) for the recorder

SIP/TLS for SIP Trunk

Click Reset button for this Trunk to reload CUCM configuration.

6. Troubleshooting

Enable trace logging in MiaRec (menu Administration -> Maintenance -> Troubleshooting) and look for any error messages related to TLS.

Successful establishment of TLS connection produces the following output in trace.log file:

2018/01/03 09:46:59.028 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(195)   Constructed context: method=SSLv23 ctx=09153A88
2018/01/03 09:46:59.028 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(510)   Constructed channel: ssl=09164AF8 method=SSLv23 context=00747C48
2018/01/03 09:46:59.028 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    General: state=before/accept initialization
2018/01/03 09:46:59.028 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=before/accept initialization
2018/01/03 09:46:59.082 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 read client hello A
2018/01/03 09:46:59.082 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 write server hello A
2018/01/03 09:46:59.082 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 write certificate A
2018/01/03 09:46:59.088 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 write key exchange A
2018/01/03 09:46:59.088 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 write server done A
2018/01/03 09:46:59.088 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 flush data
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 read client key exchange A
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 read finished A
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 write session ticket A
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 write change cipher spec A
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 write finished A
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSLv3 flush data
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    General: state=SSL negotiation finished successfully
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  PSSLChannel.cxx(22)    Accept: state=SSL negotiation finished successfully
2018/01/03 09:46:59.136 09:46:58.835    1         OpalListener:4b64 TransportTLS.cxx(144)   TLS         Started connection to 192.168.1.200:34226 (if=192.168.1.106:5071)
2018/01/03 09:46:59.136 09:46:58.835    4         OpalListener:4b64  ListenerTLS.cxx(49)    TLS Listen  Waiting on socket accept on tls$*:5071
2018/01/03 09:46:59.137 09:46:58.835    3     TransportHandler:467c     Listener.cxx(93)    Listen          Started handler thread on tls$192.168.1.200:34226<if-read=tls$192.168.1.106:5071, if-write=tls$192.168.1.106:5071> 0x09160FC0
2018/01/03 09:46:59.137 09:46:58.835    3     TransportHandler:467c CiscoBiBManager.cpp(185)    CiscoBiB Listener thread started on tls$192.168.1.200:34226<if-read=tls$192.168.1.106:5071, if-write=tls$192.168.1.106:5071> 0x09160FC0
2018/01/03 09:46:59.137 09:46:58.835    3     TransportHandler:467c       SipPdu.cpp(156)   SIP         PDU Created: <<Uninitialised>> CSeq=
2018/01/03 09:46:59.161 09:46:58.835    5     TransportHandler:467c       SipPdu.cpp(671)   SIP         PDU Parsed 399 bytes on tls$192.168.1.200:34226<if-read=tls$192.168.1.106:5071, if-write=tls$192.168.1.106:5071> 0x09160FC0
2018/01/03 09:46:59.161 09:46:58.835    4     TransportHandler:467c       SipPdu.cpp(734)   SIP         PDU Received 399 bytes on tls$192.168.1.200:34226<if-read=tls$192.168.1.106:5071, if-write=tls$192.168.1.106:5071> 0x09160FC0
OPTIONS sip:192.168.1.106:5071 SIP/2.0
Content-Length: 0
Contact: <sip:192.168.1.200:5061;transport=tls>
User-Agent: Cisco-CUCM11.5
Call-ID: 17095a80-a4d11712-19475-c801a8c0@192.168.1.200
CSeq: 101 OPTIONS
Date: Wed, 03 Jan 2018 17:46:58 GMT
Via: SIP/2.0/TLS 192.168.1.200:5061;branch=z9hG4bK1959e66d3ef22
From: <sip:192.168.1.200>;tag=275457321
Max-Forwards: 0
To: <sip:192.168.1.106>

Contact MiaRec representative if you face with any issues.

Cisco UCM recording announcement

Overview

MiaRec has implemented a unique solution for automatic recording announcement for any call scenario on Cisco platform. Such scenarios include both inbound and outbound calls.

The uniqueness of such solution is that it supports outbound call scenarios, which are normally not routed trough IVR system. With MiaRec solution, the customers will hear pre-recorded announcement at the beginning of conversation. Configuration is very flexible and allows to exclude some call scenarios from automatic announcement playback. For example, when agent makes outgoing call to another agent, then announcement could be avoided.

The announcement message is recorded into audio file together with a conversation, which serves as a proof that both parties have been notified about recording.

How it works

The following diagram describes outbound call flow scenario, but it is valid for inbound call scenario as well.

  • MiaRec application monitors call events using TAPI interface to Cisco Unified Communications Manager.
  • When agent makes new call to customer (1), the Cisco UCM notifies MiaRec application about new call via TAPI (2).
  • Call recording is implemented using Cisco active recording method (Built-in-Bridge) shown on diagram as (3).
  • When call recording begins, MiaRec application sends a command to CUCM to play recording notification into communication channel (4).
  • Both agent and customer hear such notification.

Cisco recording announcement architecture

Requirements

  • Cisco UCM version 8.5.1 or newer (1)
  • Cisco IP phones supporting Built-in-Bridge (2)
  • TAPI interface to Cisco UCM

Notes:

  1. In order to implement recording announcement, MiaRec application uses Agent Greeting feature of Cisco Unified Communications Manager, which is available starting from version 8.5.1

  2. Built-in-Bridge feature is required in order to be able to play recording announcement into established communication channel

When recording announcement is played back

MiaRec plays recording announcement as a result of one of two events:

  • When call is connected
  • When recording is started

In the first case, a recording announcement will always be played back even if the call is not recorded. In the second case, a recording announcement will be played back only if such call is actually recorded. If recording is disabled for agent, then no announcement will be played back.

What scenarios are supported

MiaRec may play recording announcement for all possible call scenarios that involve Cisco IP Phone.

Additionally, MiaRec supports flexible filters, that allow exclusion of some call scenarios from recording announcement. For example, internal calls between agents usually do not require announcement.

Installation guide

MiaRec recording announcement solution for Cisco UCM consists of multiple components:

  • Controller. The controller application monitors call events and initiates playback of greeting when the pre-configured conditions match.
  • Player. The playe application is presented as a SIP Trunk in CUCM environment. It plays back the pre-recorded greeting message into the call session.
  • Recorder. The MiaRec recorder component records calls using Built-in-Bridge interface

Cisco recording announcement architecture

This guide describes configuration of the Controller and Player components.

Player - Configuration

The configuration of MiaRec recording announcement player is stored in text INI file SipPlayer.ini.

Section [Main]

Example of configuration:

[Main]

AudioFile=call-maybe-recorded.wav

AudioFile16KHz=call-maybe-recorded-16KHz.wav
  • Set AudioFile to the pre-recorded audio file for announcement message, something like "This call may be recorded". MiaRec comes with a sample audio file. You can use the sample file or record your own. The file format: mono, 8KHz, wav uncompressed.

  • Option AudioFile16KHz is similar to AudioFile, but for calls using high quality wideband codecs (G.722). The file format: mono, 16KHz, wav uncompressed.

Section [SIP]

The recording announcement player behaves as an auto-answering machine. It listens for inbound SIP connection from Cisco UCM, answers the call, plays back the announcement message and automatically hangs up. In the latter sections you will configure SIP Trunk in CUCM for player component.

In this section, you need to configure various SIP parameters for the player.

[SIP]

PortUDP=5060
PortTCP=5060

PortRtpMin = 30000
PortRtpMax = 31999
  • Options PortUDP and PortTCP specify the listening ports for SIP interface for UDP and TCP protocols respectively. Normally, TCP is used for SIP Trunk in CUCM environment. So, you only need to use PortTCP. Other protocol may be disabled by setting its value to 0. If a firewall is enabled, then you need to add these ports to the allowed list.

  • Options PortRtpMin and PortRtpMax specify the UDP port range for RTP packets. If a firewall is enabled, then you need to add this port range to the allowed list.

CUCM - SIP profile

Use the Device > Device Settings > SIP Profile menu option in Cisco Unified Communications Manager Administration to create SIP profile for MiaRec recording announcement player.

The following figure illustrates creating a SIP profile for the recorder.

Create SIP profile for recorder

CUCM - SIP Trunk Security Profile

Use the System > Security > SIP Trunk Security Profile menu option in Cisco Unified Communications Manager Administration to create SIP Trunk Security profile for MiaRec recording announcement player.

  • Set Incoming Transport Type to TCP+UDP.
  • Set Outgoing Transport Type to TCP (this setting has to match the configuration of MiaRec). TCP is recommended.
  • Uncheck option Enable Digest Authentication
  • Set Device Security Mode parameter to Non Secure.

Create SIP Trunk Security Profile

CUCM - SIP Trunk

Use the Device > Trunk menu option in Cisco Unified Communications Manager Administration to create SIP trunk that points to the MiaRec announcement player.

  • Set Device Pool to the same pool as used for phones themselves
  • Set Calling Search Space to the CSS that contains the user phones

In SIP Information section configure:

  • Destination Address should point to ip-address or DNS name of the MiaRec announcement player
  • Destination Port should match the port on which MiaRec announcement player is listening for messages from CUCM
  • Select the previously created SIP Trunk Security Profile for the announcement player
  • Select the previously created SIP Profile for the announcement player

Create SIP Trunk

CUCM - Route pattern

Use the Call Routing > Route/Hunt > Route Pattern menu option in Cisco Unified Communications Manager Administration to create a route pattern for the MiaRec announcement player SIP trunk:

  • Route Pattern should match to the directory number associated with MiaRec announcement player. This DN is used to reach the SIP Trunk of MiaRec announcement player. The latter will automatically answer incoming calls made to this DN and playback the recording announcement player. No user is going to directly call this number manually. Make sure it does not collide with your numbering plan. This is why the example shows '7777'.

  • Set Route partition to the partition that includes the user phones.

  • In Gateway/Route List select the SIP trunk that points to the announcement player

Reoute Pattern Configuration

Verify SIP Trunk configuration

If the MiaRec announcement player is running, then you should be able to dial from your phone the configured directory number (7777 in above example). You should hear the announcement message and then the call should hanghup automatically.

In the next steps, you will configure the controller component, which will automatically route calls to this directory number based on varios criteria, like "outbound only" or "matching phone prefix", etc.

CUCM - Built-in-Bridge (system level)

Built-in-Bridge setting can be enabled on per-phone basis or on system level (default to all phones).

Access the System > Service Parameters menu option in Cisco Unified Communications Manager Administration, select your CUCM server from the Server list and Cisco CallManager from the Service list:

Service Parameter Configuration

To enable Built-in-Bridge on system level change the option Clusterwide Parameters (Device - Phone) -> Builtin Bridge Enable to On:

Clusterwide Builtin Bridge Enable

CUCM - TAPI user

You must first create the application user who is capable of monitoring and controlling phones.

Navigate in Cisco Unified CM Administration web portal to the menu User Management -> Application User and click Add New button to create new user account.

Add application user

In the list Available Devices select the devices, which state should be monitored by MiaRec announcement controller and click arrow V to move such devices to the list Controlled Devices.

In case of Extension Mobility, you can use CTI Controlled Device Profiles instead of Controlled Devices list.

Add application user

In the section Permissions Information click the Add to Access Control Group button to select permissions for application user.

Add application user

In the new pop-up window select the following required options:

  • Standard CTI Allow Control of All Devices
  • Standard CTI Allow Control of Phones supporting Connected Xfer and conf
  • Standard CTI Allow Control of Phones supporting Rollover Mode
  • Standard CTI Enabled

Other options are not required.

Add application user

Save the settings of new application user.

Controller - Cisco TAPI TSP driver

The Cisco TAPI Service Provider (TSP) is a TAPI driver that is installed on the Windows server that allows communication of line events between MiaRec recording announcement controller and the Cisco UCM.

Download the TAPI driver

The installer for the client can be obtained from the Cisco Unified CM Administration portal using the following steps:

  1. Open Cisco Unified CM Administration portal in a web browser and log in with an administrator account.

  2. Once logged in, hover over the Application menu across the top of the site, and click the Plugins link.

  3. On the Find and List Plugins page, enter "Cisco TAPI" into the search field and click Find.

  4. The plugin list will load. Click the Download link on either 32-bit or 64-bit client depending on your operating system.

Download Cisco TAPI driver

Install the TAPI driver

Open the CiscoTSP.exe installer and follow instructions on screen. You will be asked for Cisco CallManager address and application user/password as created in previous steps.

Restart operating system is required after installation of Cisco TAPI driver.

[Optional] Modify Cisco TAPI configuration

To modify Cisco TAPI driver configuration use CiscoConfig.exe utility, which is installed with TAPI driver.

Start this utility and click Configure button.

Configure Cisco TAPI driver

The following screenshots demonstrate example of configuration.

Configure Cisco TAPI driver

Configure Cisco TAPI driver

Controller - Verify TAPI configuration

To verify the TSP operation on the machine where the TSP is installed, use the Microsoft Windows Phone Dialer Application.

Windows Phone Dialer

When the program is run, a dialog box displays that asks which line and address the user wants to use to connect. If there are no lines in the Line drop down list, then a problem may exist between the TSP and the Cisco Unified Communications Manager.

If lines are available, choose one of the lines, keep the Address set to zero (0) and click OK. Enter a Number to dial, and a call should be placed to that number.

If call is successful, you know that the TSP is operational on the machine where the TSP is installed. If problems are encountered with installation and setup of Remote TSP, this test represents a good way to verify whether the TSP is operating properly and that the problem is with the configuration and setup of Remote TSP.

Enable trace in Cisco TAPI driver.

Start CiscoConfig.exe utility and click the Trace tab.

Select Trace On check box and select:

  • TSP Trace to trace the TSP internal messages.
  • CTI Trace to trace the messages sent between CTI and TSP.
  • TSPI Trace to trace the requests and events that are sent between TSP and TAPI.

Select Error to just log errors in the TSP or Detailed to log internal messages for debugging purposes.

Set up a Directory that is the path for the trace log. For example, C:\CiscoTapiLog

No. of Files: Setting this to a value greater than or equal to 1 enables rolling log files. For example, a value of 10 will cause up to 10 log files to be used in a cyclic fashion. Max lines/file: specifies the maximum number of trace statements that will be written to each log file. For example, a value of 1000 will cause up to 1000 trace statements to be written to each log file.

Cisco TAPI Trace config

After Trace is enabled in Cisco TAPI driver, start the TAPI application (for example, Windows Phone Dialer) and then examine logs.

Controller - Configuration

The configuration of MiaRec recording announcement controller is stored in text INI file.

Section [Filters]

MiaRec supports selective recording announcement using advanced filters. For example, you can activate recording announcement only for outbound calls. Or only for calls matching particular phone prefix, etc.

The following section illustrates some of examples:

##############
[Filters]
##############

; ------------------------
; Example 1
; Play recording announcement for extension 203
; ------------------------
filter1 condition = caller-number = 203 OR called-number = 203
filter1 action = play

; ------------------------
; Example 2
; Play recording announcement for all calls between 2xx and 2xx
; ------------------------
filter2 condition = caller-number LIKE '2__' AND called-number = LIKE '2__'
filter2 action = play

; ------------------------
; Example 3
; Ignore all calls, where caller extension is 3 digits
; ------------------------
filter3 condition = caller-number LIKE '___'
filter3 action = ignore

default_action = play

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.

Softkey integration with Polycom VVX (Metaswitch platform)

MiaRec integrates with Polycom VVX series phones to provide on-demand and pause/resume recording control via softkey.

Supported models:

  • Polycom VVX 300, 400, 500, 600, 1500 Series

How it works

A phone loads a custom Endpoint Pack Extension from Metaswitch SIP Provisioning Server.

MiaRec Phone Services

During an active call call, a custom labeled softkey is shown on phone's screen. The following screenshot shows "MiaRec" softkey. it is possible to change the key's name.

MiaRec Phone Service on Polycom VVX phone

When user presses this key, an XML application is loaded by phone from the MiaRec recording server. User will see "Record/No Record" and/or "Pause/Resume" buttons, depending on the configured permissions.

MiaRec Phone Service on Polycom VVX phone

Configuration guide

Step 1. Download MiaRec's Endpoint Pack Extension (EPE)

Download one of the following extensions that matches to a version of your existing Endpoint Pack (EP) for Polycom VVX phones:

Note 1: If your Polycom Endpoint Pack version is not listed here, then you can follow the procedure in Amending the Base Version of a Pack Extension article in Metaswitch Community site, or contact MiaRec Support for assistance.

Note 2: If you already have another pack extension in your system, then you need to merge multiple extensions into one. Follow the procedure in Concatenating more than one Pack Extension article on Metaswitch Community site, or contact MiaRec Support for assistance.

Step 2. Install MiaRec's Endpoint Pack Extension into Metaswitch SIP provisioning server

Follow the procedure in Deploying a Pack Extension for an Endpoint Pack on SIP Provisioning Server chapter of MetaView SIP Provisioning Server Guide.

Step 3. Use the CommPortal Phone Configurator to enable MiaRec's softkey integration

Use MetaView Web to log on to the CommPortal Phone Configurator at the required level of your phone profile hierarchy:

  • Persistent Profile (if the app should be enabled/disabled for all your SIP phones)

  • Business Group or Department (to enable it for all SIP phones within a particular Business Group or Department).

Open Programmable Keys - Bottom section and assign MiaRec recording button to one of line keys (Key 1 is a good choice).

  • Select MiaRec Record Button in the Soft key action. If you do not see this option, then the Endpoint Pack Extension is not installed properly

  • Enter your MiaRec web portal address under MiaRec Server Address, like https://recorder.example.com. Use https:// (encrypted connection) and domain address (do not use IP-address because SSL certificate validation will fail). The MiaRec web server requires a valid SSL certificate (read below).

  • Choose a name for the soft key

MiaRec Phone Services

A valid SSL certificate is required for the MiaRec web portal. Follow the procedure in Enable HTTPS for MiaRec Web portal to configure SSL certificate.

Note, Polycom phones do not support wildcard SSL certificates, i.e. if your MiaRec web server uses SSL certificate for domain *.example.com, then XML application will fail to load to Polycom phone with error "SSL/TLS handshake failed". To resolve this issue, use a single-domain SSL certificate for a MiaRec web portal, for example, you can use free SSL certificate from Let's Encrypt.

Step 4. Configure MiaRec application

  1. Follow the procedure in User authentication using Metaswitch CommPortal to activate the authentication of users with CommPortal

  2. Navigate in the MiaRec web portal to Administration -> System -> Phone services. Click Edit configuration for the tenant. Make sure the phone services are enabled for this tenant and Authentication option is set to Authenticate users using the web access password

  3. Navigate in the MiaRec web portal to Administration -> User management -> Tenants -> [select tenant] -> Roles. For subscriber roles, make sure the following permissions are granted:

    • Allow for resource Phone services
    • View for resource Own call recordings
    • [optional] Trigger on-demand for resource Own call recordings. This permission is required only if subscribers need to control recording on-demand
    • [optional] Pause recording for resource Own call recordings. This permissions is required only if subscribers need to pause recording during a call (for example, for PCI compliance)
  4. Navigate in the MiaRec web portal to Administration -> User management -> Tenants -> [select tenant] -> Users. For subscribers, make sure the following settings are configured:

    • Login attribute is set to the same username as used for CommPortal authentication
    • Allow web access is enabled
    • Authenticate with is set to Metaswitch CommPortal
    • [optional] Record is set to On-demand (you can optionally choose between Keep recording and Discard recording depending on your preferences). This option is required only if subscribers need to control recording on-demand

Step 5. Verification

  1. Reboot the phone. The phone should load new configuration from SIP PS
  2. Make a test call
  3. Verify in MiaRec web portal if this call is being recorded
  4. Verify in MiaRec web portal if this call is associated with correct user profile. See Associating calls with user
  5. While call is still in progress, verify if the configured soft key is displayed on phone's screen
  6. Press the soft key and test Record/No record and Pause/Resume buttons (note, these buttons may be hidden if subscriber doesn't have appropriate permissions to control on-demand or pause recording)

Troubleshooting

Check System Log in MiaRec

Navigate in MiaRec web portal to Administration -> Maintenance -> System Log and check if there are any warnings/errors.

Use your web browser to simulate the hardware phone

Open in your web browser the same link as you configured in the Polycom configuration file, for example:

https://[YOUR-MIAREC-SERVER]/api/phone_services/polycom/calls/active_call?login=123456

You should be able to login to phone services and see the recording controls.

MiaRec Phone Services

Check Polycom phone logs

By default Polycom phone automatically uploads own log file to the provisioning system using FTP. Check that log file for any errors.

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

Soft key integration with phones

Overview - Soft keys on IP phones

MiaRec integrates with various phone models to provide the following features:

  • On-demand recording Users may use their phones to switch on/off recording during an active call.

  • Pause/resume recording Users may use their phones to pause recording for a short period of time. For example, when processing credit card transactions over the phone, a user may pause recording before a customer says the credit card information. Such feature allows to comply with PCI requirements.

The following images display example of integration with various phone models.

Cisco 7900 series softphone:

MiaRec phone services on Cisco phone

Polycom VVX400 phone:

MiaRec phone services on Polycom VVX phone

Cisco SPA504G phone:

MiaRec phone services on Cisco SPA504G phone

Yealink T46S phone:

Yealink pause/resume recording softkey

Mitel 6800i Series phone:

Mitel pause/resume recording softkey

Configure MiaRec phone services

This guide is for configuring phone services for Polycom VVX, Yealink, Mitel, Panasonic and Cisco/Linksys SPA phone models only. If you need to configure Cisco 7900 series phones, please, check the guide here.

MiaRec integrates with Polycom VVX, Yealink, Mitel, Panasonic and Cisco SPA series phones to provide the following features:

  • On-demand recording Users may use their phones to switch on/off recording for the current call.

  • Pause/resume recording Users may use their phones to pause recording for short period of time. For example, when processing credit card transactions over the phone, an agent may pause recording before a customer speaks the credit card information. Such features allows to comply with PCI requirements.

Configurations steps:

  1. Configure MiaRec phone services
  2. Configure "Login" and "PIN" attributes at the user profile
  3. Allow "Phone services" permissions at the role profile.
  4. Configure phone

Configure MiaRec phone services

Navigate in MiaRec web portal to Administration -> System -> Phone Services. Click Edit configuration button to open the settings page (see the following screenshot).

MiaRec Phone Services

Configure "Login" and "PIN" attributes at the user profile

Navigate in MiaRec web portal to Administration -> User Management -> Users and edit the corresponding user profiles. It is necessary to configure unique "Login" for each user. Users will need to provide their Login and PIN when they access the MiaRec services the first time from their phone.

MiaRec Phone Services

Allow "Phone services" permission at the role profile

Navigate in MiaRec web portal to Administration -> User Management -> Roles and edit the corresponding role profile.

MiaRec Phone Services

Configure phone

View active phone registration (sessions)

When user succesfully signs in to MiaRec phone services from his/her phone, the corresponding session is opened by MiaRec. An administrator may see all opened sessions using Web portal. Navigate to Administration -> System -> Phone services and click the link View active phone sessions:

MiaRec Phone Services

An administrator may terminate (delete) any active session from this screen. If the session is deleted, then the user will be required to signin again from his/her phone manually.

MiaRec Phone Services

Integration with Cisco SPA series phones

Cisco SPA series phones could be configured in a few ways:

  • Using phone's built-in web interface
  • Auto-provisioining of phone using HTTP, for example, in Broadworks or Metaswitch environment.

Supported models:

  • Cisco SPA 300, 500 series

Soft key MiaRec is displayed on Cisco SPA series phone when phone services are configured properly.

MiaRec Phone Service on Cisco SPA series phone

Click the MiaRec phone services button to see the Recording controls screen. The Record/No Record and Pause/Resume buttons are displayed on this screen:

MiaRec Phone Service on Cisco SPA series phone

Option 1. Configure phone using built-in web interface

Open phone's built-in web interface and navigate to Administration -> Advanced Settings -> Phone.

  1. Change "Programmable Softkey Enable" to yes

  2. Insert the following text into PSK 1 field (or any other field if PSK 1 is already used).

    fnc=xml;url=http://{MIAREC_WEB_SERVER}/api/phone_services/cisco_spa/calls/active_call?login=$UID1;nme=MiaRec
    

    Where {MIAREC_WEB_SERVER} is your MiaRec web server address and nme=MiaRec a soft key title. $UID1 will be substituted with the first line SIP Auth User ID. It should match to the correponding configuration of user profile in MiaRec web portal (menu Administration -> User Management -> Users, field Login).

  3. Add psk1|1 to Connected Key List field.

    Before:

    conf|3;xfer|4;toggle;bxfer;confLx;xferLx;park;phold;flash;
    

    After:

    psk1|1;conf|3;xfer|4;toggle;bxfer;confLx;xferLx;park;phold;flash;
    

    A number after | symbol specifies a position of button (1st in our example). psk1 corresponds to PSK 1 field configured above.

MiaRec Phone Service on Cisco SPA series phone

For more detail about Custom Phone Keys you can check the Cisco Small Business SPA300 Series, SPA500 Series, and WIP310 IP Phone Administration Guide

Option 2. Configure phone using Metaswitch SIP provisioining server

You need to create Endpoint Pack Extension for Metaswitch. You can find the detailed instructions in Metaswitch Community. See the document [Cisco] Creating a Cisco pack extension.

MiaRec Phone Services

File metadata.yaml (example):

ID: cisco_SPA5xx_accredited  
PackVersion: 17  
Version: 1  
Position: End  
TemplatePositions:  
- Template: config.ftl  
  Position: End  

File templates/schema.yaml (example):

group_names:
  CustomParameters:
    display_name:
      default: Custom Parameters

settings:
  - name: custom_MiaRecPhoneServices_Button
    group_name: CustomParameters
    display_name: 
      default: MiaRecPhoneServices_Button
    syntax:
      type: Boolean
    default_value: false

File templates/config.ftl (example):

<flat-profile>  
${logger.log("MiaRec Phone Services soft key")}  
  <Programmable_Softkey_Enable ua="na">Yes</Programmable_Softkey_Enable>  
  <Connected_Key_List ua="na">psk16|1;${profile.AdvConnKeyList}</Connected_Key_List>  
  <PSK_16 ua="na">fnc=xml;url=http://{MIAREC_WEB_SERVER}/api/phone_services/cisco_spa/calls/active_call?login=$UID1;nme=MiaRec</PSK_16>  
</flat-profile> 

Where {MIAREC_WEB_SERVER} is your MiaRec web server address and nme=MiaRec a soft key title. $UID1 will be substituted with the first line SIP Auth User ID. It should match to the correponding configuration of user profile in MiaRec web portal (menu Administration -> User Management -> Users, field Login).

Option 3. Configure phone using generic provisioining server (HTTP-based server)

If you are a service provider and provision phone using Broadworks, Metaswitch or home-grown HTTP based system, then you need to add the following customizations to your Cisco SPA phone configuration template. For more details check Cisco Small Business IP Telephony Devices Provisioning Guide

Example of Plain Text configuration:

Programmable_Softkey_Enable   "Yes" ;

Connected_Key_List                   "psk1|1;conf|3;xfer|4;toggle;bxfer;confLx;xferLx;park;phold;flash;" ;

PSK_1 "fnc=xml;url=http://{MIAREC_WEB_SERVER}/api/phone_services/cisco_spa/calls/active_call?login=$UID1;nme=MiaRec" ;

Where {MIAREC_WEB_SERVER} is your MiaRec web server address and nme=MiaRec a soft key title. $UID1 will be substituted with the first line SIP Auth User ID. It should match to the correponding configuration of user profile in MiaRec web portal (menu Administration -> User Management -> Users, field Login).

Troubleshooting

MiaRec System Log

Navigate in MiaRec web portal to Administration -> Maintenance -> System Log and check if there are any warnings/errors.

Use your web browser to simulate the hardware phone

Open in your web browser the same link as you configured in the Polycom configuration file, for example:

https://miarec.example.com/api/phone_services/cisco_spa/calls/active_call?login=123456

You should be able to see XML page like the following:

MiaRec Phone Services

Integration with Mitel/Aastra phones

MiaRec integrates with Mitel 6800 series phones (previously known as Aastra) to provide on-demand and pause/resume recording control using softkey.

The photos below show Mitel 6867i phone integrated with MiaRec XML application in action.

Mitel MiaRec softkey

Mitel 6871i / MiaRec softkey integration

Users can press Record / No Record softkey buttons during a call to selectively record some calls (on-demand recording).

The following photo demonstrates "Recording" state. User can press "No Record" to disable recording.

Mitel on-demand recording softkey

The following photo demonstrates "Not Recording" state. User can press "Record" to enable recording.

Mitel on-demand recording softkey

Additionally, MiaRec supports pause/resume recording for PCI Compliance. Users can press Pause and Resume softkey buttons to temporary mute recording, for example, when customer speaks credit card number.

Mitel pause/resume recording softkey

Configuration of Mitel phone

The MiaRec XML application can be configured in Mitel phone using:

  • Phone web interface
  • Generic provisioning server (recommended).
  • Metaswitch SIP Provisioning Server (recommended)

Option 1. Configuration of phone using web interface

Open web interface to Mitel phone and navigate to Softkeys and XML->Top Keys.

Choose one of available line keys and set:

  • Type to XML
  • Label to the preferred title, for example, MiaRec or Record
  • Value should point to MiaRec web server. Format is the following:

    https://miarec.example.com/api/aastra?login={LOGIN}&password={PASSWORD}
    

    Where:

    • {LOGIN} is a web access login configured on user's profile in MiaRec web portal
    • {PASSWORD} is either Phone Services PIN or web access password depending on phone services configuration in MiaRec.
    • miarec.example.com should replaced with your MiaRec server address

Mitel softkey configuration

HTTP vs HTTPS?

The URL for XML application supports both http:// and https://. For quick testing purposes you can use HTTP (non-encrypted) protocol for XML application, but for production, it is required to use HTTPS as it provides encryption. The user's login/password has to be sent to MiaRec server during authentication, so, encryption is required to protect this data from man-in-middle attacks.

Your MiaRec web server can be deployed with a self-signed certificate (not recommended for production) or with a SSL certificate signed by such providers like Verisign, DigiCert, GoDaddy, etc.

Mitel phone by default trusts only certificates that are signed by fullowing providers: Comodo (EssentialSSL and 4096-bit RSA), CyberTrust, DigiCert, Entrust, GoDaddy, GeoTrust, Mitel MBG, Symantec (Class 3 Secure Server CA - G4), Thawte, TrustZone and Verisign.

If your SSL certificate is signed by other provider, then it is necessary to download provider's CA certificate to the phone as a trusted SSL certificate. Check the Mitel SIP Phones Administration Guide for details (chapter HTTPS Client/Server Configuration).

Option 2. Configuration of phone using a generic provisioning server

Add the following lines to your phone's configuration file:

topsoftkeyX type: xml
topsoftkeyX label: MiaRec
topsoftkeyX value: https://miarec.example.com/api/aastra?login={LOGIN}&password={PASSWORD}

Where:

  • X is a number from 1 to 10 (depending on phone model).
  • {LOGIN} is a web access login configured on user's profile in MiaRec web portal
  • {PASSWORD} is either Phone Services PIN or web access password depending on phone services configuration in MiaRec.
  • miarec.example.com should replaced with your MiaRec server address

Option 3. Configuration of phone using Metaswitch SIP Provisioning Server

If you are a Metaswitch service provide using Metaswitch SIP Provisioning Server, then you can automate provisioning of MiaRec to all users using custom Endpoint Pack with the following settings:

topsoftkeyX type: xml
topsoftkeyX label: MiaRec
topsoftkeyX value: https://miarec.example.com/api/aastra?login=${userData.directoryNumber}&pat=${userData.commportalPAT}

Where:

  • X is a number from 1 to 10 (depending on phone model).
  • miarec.example.com should replaced with your MiaRec server address

The value ${userData.directoryNumber} will be replaced automatically with the extension of subscriber.

The value ${userData.commportalPAT} will be replaced with subscriber's Persistent Authentication Token (PAT).

Requirements for CommPortal-based authentication

  • CommPortal-based user authentication should be enabled in MiaRec (see menu Administration -> User Authentication -> Metaswitch CommPortal Authentication
  • Phone services authentication type on Tenant's profile should be set to Authenticate users using the web access password (see menu Administration -> User Management -> Tenants -> Tenant Profile -> Phone Services
  • Authentication type on User's profile should be set to CommPortal (see menu Administration -> User Management -> Users -> User Profile).

How MiaRec integrates with Metaswith CFS / CommPortal

Below diagram shows how MiaRec phone services are integrated with Metaswitch platform.

  1. The phone loads a custom made EndPoint Pack from Metaswitch SIP Provisioning server. This endpoint pack includes configuration of softkeys as well as HTTPS trust certificate (if necessary). The CommPortal Persistent Authentication Token (PAT) is generated for user and injected into the configuration file.

  2. User makes/receives call from Metaswitch CFS

  3. Upon pressing the pre-configured softkey, the phone loads XML application from MiaRec web server. The MiaRec server receives user's login and CommPortal Persistent Authentication Token (PAT) in the request, and passes those values to Metaswitch CommPortal for validation. After user credentials verification, the recording control buttons are displayed on phone's screen.

MiaRec Phone Services

Troubleshooting

MiaRec System Log

Navigate in MiaRec web portal to Administration -> Maintenance -> System Log and check if there are any warnings/errors.

Use your web browser to simulate a hardware phone

Open in your web browser the same link as you configured in the Mitel configuration file, for example:

https://miarec.example.com/api/aastra?login=123456&password=secret

You should be able to see XML formatted page like:

<?xml version="1.0" encoding="utf-8"?>
  <AastraIPPhoneFormattedTextScreen
    destroyOnExit="yes"
    LockIn="no"
    Beep="no"
  >

  <TopTitle>Recording controls</TopTitle>
  <Line>
     From: 551200159 
  </Line>
  <Line>
     To: 300 
  </Line>
  <Line>
     NOT RECORDING
  </Line>

  <SoftKey index="1">
      <Label>Record</Label>
      <URI>https://miarec.example/api/aastra/calls/...</URI>
  </SoftKey>

  <SoftKey index="2">
        <Label>Pause</Label>
        <URI>https://miarec.example/api/aastra/calls/...</URI>
  </SoftKey>

Integration with Polycom VVX series phones

Supported models:

  • Polycom VVX 300, 400, 500, 600, 1500

Edit Polycom XML configuration files on your provisioning server

You need to add the following settings to the XML configuration file:

<feature>
    <feature.enhancedFeatureKeys feature.enhancedFeatureKeys.enabled="1">
    </feature.enhancedFeatureKeys>
</feature>

<softkey
  softkey.1.label="MiaRec"
  softkey.1.action="https://{MIAREC_WEB_SERVER}/api/phone_services/polycom/calls/active_call?login={LOGIN}"
  softkey.1.enable="1"
  softkey.1.insert="0"
  softkey.1.precede="1"
  softkey.1.use.active="1"
  softkey.1.use.alerting="0"
  softkey.1.use.dialtone="0"
  softkey.1.use.hold="0"
  softkey.1.use.idle="0"
  softkey.1.use.proceeding="0"
  softkey.1.use.setup="0"
>
</softkey>

Where {MIAREC_WEB_SERVER} is your MiaRec web server address and {LOGIN} is an login of the particular user. Each user should have unique login. The login should match to the correponding configuration of user profile in MiaRec web portal (menu Administration -> User Management -> Users).

Below diagram shows how MiaRec phone services are integrated with Metaswitch platform:

MiaRec Phone Services

Troubleshooting

MiaRec System Log

Navigate in MiaRec web portal to Administration -> Maintenance -> System Log and check if there are any warnings/errors.

Use your web browser to simulate the hardware phone

Open in your web browser the same link as you configured in the Polycom configuration file, for example:

https://miarec.example.com/api/phone_services/polycom/calls/active_call?login=123456

You should be able to login to phone services and see the recording controls.

MiaRec Phone Services

Check Polycom phone logs

By default Polycom phone automatically uploads own log file to the provisioning system using FTP. Check that log file for any errors.

Known limitations

Polycom phones do not support wildcard SSL certificates, i.e. if your MiaRec web server uses SSL certificate for domain *.example.com, then XML application will fail to load to Polycom phone with error "SSL/TLS handshake failed".

Solution: use a single-domain SSL certificate for MiaRec web portal, for example, you can use free SSL certificate from Let's Encrypt.

Integration with Yealink phones

MiaRec integrates with Yealink phones to provide on-demand and pause/resume recording control using softkey.

The photos below show example of Yealink T46S and T48S with MiaRec XML application in action

Yealink T46S / MiaRec softkey integration

Users can press Record / No Record softkey buttons during a call to selectively record some calls (on-demand recording).

The following photo demonstrates "Recording" state. User can press "No Record" to disable recording.

Yealink on-demand recording softkey

The following photo demonstrates "Not Recording" state. User can press "Record" to enable recording.

Yealink on-demand recording softkey

Additionally, MiaRec supports pause/resume recording for PCI Compliance. Users can press Pause and Resume softkey buttons to temporary mute recording, for example, when customer speaks credit card number.

Yealink pause/resume recording softkey

Yealink T48S / MiaRec softkey integration

Yealink on-demand recording softkey

Yealink on-demand recording softkey

Yealink pause/resume recording softkey

Configuration of Yealink phone

The MiaRec XML application can be configured in Yealink phone using:

  • Phone web interface
  • Provisioning server (recommended)

Option 1. Configuration of phone using web interface

Open web interface to Yealink phone and navigate to DssKey -> Line Key1-9.

Choose one of available line keys and set:

  • Type to XML Browser
  • Label to preferred title, for example, MiaRec or Record
  • Value should point to MiaRec web server. Format is the following:

    https://server.example.com/api/yealink?login={LOGIN}&password={PASSWORD}
    

    Where:

    • {LOGIN} is a web access login configured on user's profile in MiaRec web portal
    • {PASSWORD} is either Phone Services PIN or web access password depending on phone services configuration in MiaRec.
    • miarec.example.com should replaced with your MiaRec server address

Yealink softkey configuration

Option 2. Configuration of phone using provisioning server

Add the following lines to your phone's configuration file:

linekey.X.type = 27
linekey.X.label = "MiaRec"
linekey.X.value = https://miarec.example.com/api/yealink?login={LOGIN}&password={PASSWORD}

Where:

  • X is a number from 1 to 10 (depending on phone model).
  • {LOGIN} is a web access login configured on user's profile in MiaRec web portal
  • {PASSWORD} is either Phone Services PIN or web access password depending on phone services configuration in MiaRec.
  • miarec.example.com should replaced with your MiaRec server address

Option 3. Configuration of phone using Metaswitch SIP Provisioning Server

If you are a Metaswitch service provide using Metaswitch SIP Provisioning Server, then you can automate provisioning of MiaRec to all users using custom Endpoint Pack with the following settings:

linekey.X.type = 27
linekey.X.label = "MiaRec"
linekey.X.value = https://miarec.example.com/api/yealink?login=${userData.directoryNumber}&pat=${userData.commportalPAT}

Where:

  • X is a number from 1 to 10 (depending on phone model).
  • miarec.example.com should replaced with your MiaRec server address

The value ${userData.directoryNumber} will be replaced automatically with the extension of subscriber. The value ${userData.commportalPAT} will be replaced with subscriber's Persistent Authentication Token (PAT).

Below diagram shows how MiaRec phone services are integrated with Metaswitch platform:

MiaRec Phone Services

Troubleshooting

MiaRec System Log

Navigate in MiaRec web portal to Administration -> Maintenance -> System Log and check if there are any warnings/errors.

Use your web browser to simulate a hardware phone

Open in your web browser the same link as you configured in the Yealink configuration file, for example:

https://miarec.example.com/api/yealink?login=123456&password=secret

You should be able to login to see XML formatted page for Yealink phone like.

<?xml version="1.0" encoding="utf-8"?>
  <YealinkIPPhoneTextScreen
    destroyOnExit="yes"
    LockIn="no"
    Beep="no"
  >

  <Title>Recording controls</Title>
  <Text>
     From: 551200159 
     To: 300 

     NOT RECORDING
  </Text>

  <SoftKey index="1">
      <Label>Record</Label>
      <URI>https://miarec.example/api/yealink/calls/...</URI>
  </SoftKey>

  <SoftKey index="2">
        <Label>Pause</Label>
        <URI>https://miarec.example/api/yealink/calls/...</URI>
  </SoftKey>

Softkey integration with Cisco 7900, 7800 and 8800 series phones

Overview

MiaRec integrates with Cisco phone services to provide the following features:

  • On-demand recording Agents may use their Cisco phones to switch on/off recording for the current call.

  • Pause/resume recording Agents may use their Cisco phones to pause recording for short period of time. For example, when processing credit card transactions over the phone, an agent may pause recording before a customer says critical credit card information. Such features allows to comply with PCI requirements.

Control MiaRec recording from Cisco softphone

MiaRec phone services on Cisco phone

Control MiaRec recording from Cisco hardware phone

Requirements:

  • Cisco phone with XML phone services support

Create MiaRec IP Phone Service

Open Cisco Unified Communications Manager administration web portal.

  1. Select the Device - Device Settings - Phone Services menu item.

  2. Click on Add New

  3. Type in the Service Name: MiaRec (you may use different name here)

  4. Type in the Service Description: MiaRec Phone Service

  5. Type in the Service URL:

    http://0.0.0.0/cisco_phone_service/active_call?name=#DEVICENAME#
    

    Replace 0.0.0.0 with your MiaRec server ip-address. This URL should point to MiaRec web portal. If the web portal is running on port different from the default 80, then include port into URL, like http://1.2.3.4:8080/cisco_phone_service.... It is recommended to use direct ip-address instead of domain name because name resolution may not work from within Cisco IP phone.

    Alternatively, you can use the following URLs, which allow to control recording in one-click:

    URL Description
    http://0.0.0.0/cisco_phone_service/call/active_call/ondemand/keep?name=#DEVICENAME# Enable recording in one-click
    http://0.0.0.0/cisco_phone_service/call/active_call/ondemand/discard?name=#DEVICENAME# Disable recording in one-click
    http://0.0.0.0/cisco_phone_service/call/active_call/muting/mute?name=#DEVICENAME# Pause recording in one-click
    http://0.0.0.0/cisco_phone_service/call/active_call/muting/unmute?name=#DEVICENAME# Resume recording in one-click
  6. Check Enable option.

  7. Save it.

See below screenshot for details.

Create MiaRec IP Phone Service

Subscribe each phone to MiaRec phone service

Open Cisco Unified Communications Manager administration web portal.

  1. Select the Device - Phone menu item.

  2. Select the desired phone/device.

  3. Select Subscribe/Unsubscribe Services from the "Related links" dropdown list.

    Subscribe Cisco IP phone to MiaRec phone service

  4. In the new pop up window select MiaRec from the list box.

  5. Click the Next button.

    Subscribe Cisco IP phone to MiaRec phone service

  6. Click the Subscribe button.

    Subscribe Cisco IP phone to MiaRec phone service

  7. Verify that the phone subscribed to MiaRec phone service successfully and click the Save button. Then close this pop up window.

    Subscribe Cisco IP phone to MiaRec phone service

Now, after you save phone configuration and restart the phone, the MiaRec phone services should be available upon clicking the Services button on the phone.

[Optional] Use phone's line button for quick access to MiaRec phone services.

  1. Click the Modify Button Items in the Phone Configuration window

    Subscribe Cisco IP phone to MiaRec phone service

  2. Select the Add a new SURL from the list Unassigned Associated Items and click < button.

    Subscribe Cisco IP phone to MiaRec phone service

  3. If you receive the error Must Remove An Item From Associated List Before This Operation is Allowed., then select one of unnecessary items in the list Associated Items and click V button.

    Subscribe Cisco IP phone to MiaRec phone service

    Subscribe Cisco IP phone to MiaRec phone service

  4. Select the Add a new SURL in the list Associated Items and click button ^ as many times as necessary to move it to the correct position. For example, if the phone has only 4 line buttons, then position should be from 1 to 4, otherwise the button will not be visible.

    Subscribe Cisco IP phone to MiaRec phone service

  5. Click the Save button and close this pop up window.

  6. Click the newly created Add a new SURL link.

    Subscribe Cisco IP phone to MiaRec phone service

  7. Select MiaRec from the list box and click Save button two times.

    Subscribe Cisco IP phone to MiaRec phone service

  8. Verify that MiaRec is shown on the line button. Save the phone configuration and click Apply Config (depending on phone firmware it may be necessary to restart the phone to apply changes).

    Subscribe Cisco IP phone to MiaRec phone service