- Administration Guide
- Hardware requirements
- Installation
- Ansible-based installation on Linux
- VMWare OVA template-based installation
- Deploying MiaRec on Amazon AWS (up to 2,000 users)
- 1. Network architecture
- 2. Create VPC
- 3. Create EC2 instances
- 4. Configure Elastic IP address
- 5. Install MiaRec software on EC2 instance
- 6. Configure Route 53 DNS Failover for web traffic
- 7. Configure DNS SRV for SIPREC traffic
- 8. Configure SIPREC recording
- 9. Configure automatic file relocation to Amazon S3
- 10. Configure MiaRec replication
- 11. Configure HTTPS for web server
- 12. Configure CloudWatch monitoring
- 13. Disaster recovery plan
- Installation on Windows
- Update
- Post-installation tasks
- Phone system integration
- Avaya Aura call recording
- Avaya SBCE SIPREC call recording
- 01. How it works
- 02. Access Avaya SBCE web interface
- 03. Add Server Configuration Profile
- 04. Add Routing Profile for Recording Server
- 05. Define Application Rules
- 06. Define Media Rules
- 07. Configure UCID
- 08. Define End Point Policy Group
- 09. Define Session Policies
- 10. Define Session Flows
- 11. Define Server Flows
- 12. Configure MiaRec SIPREC recordging interface
- Broadsoft call recording
- Cisco CUBE SIPREC call recording
- Cisco UCM call recording
- Cisco active recording (Built-in-Bridge)
- Overview
- Cisco phones supporting Built-in-Bridge feature
- Configure CUCM
- Configure phones
- Configure MiaRec
- Configure firewall
- Optional configuration
- Cisco phone services
- Cisco active recording (Built-in-Bridge)
- Cisco UCM recording announcement
- Metaswitch call recording
- Soft key integration with phones
- User management
- Storage management
- Customization
- Maintenance
- Speech Analytics
- MiaRec Architecture
- Screen Recording
- High availability
High availability for Cisco Built-in-bridge recording
High availability and automatic failover for Cisco active recording interface is based on the following technologies:
- MiaRec automatic replication between multiple servers in a cluster
- Multiple SIP Trunks or DNS SRV for automatic failover and/or load balancing
- SIP OPTIONS Ping feature in Cisco UCM for fast detection of server unavailability
How it works
The recording server in Cisco UCM is configured as a SIP Trunk. Cisco UCM supports configuration of multiple SIP Trunks with automatic failover between them.
Additionally, 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. If the recording server is available – indicated by any other responses other than “503” or “408”, Cisco UCM marks this recording server as available. Cisco UCM will send new INVITE only to “available” recording servers.
MiaRec supports automatic call replication between two or more recording servers. Audio file and call metadata is automatically uploaded to replication target server(s) upon call completion or by schedule (for example, at night).
Alternatively, instead of configuring multiple SIP Trunks in Cisco UCM it is possible to configure a single SIP Trunk pointing to DNS SRV records. The multiple recording servers are configured as SRV records. Such configuration allows to build automatic failover and load balancing configurations with multiple recording servers.
Example of DNS SRV records:
# _service._proto.name. TTL class SRV priority weight port target.
_sip._tcp.example.com. 86400 IN SRV 10 40 5060 miarec1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 30 5060 miarec2.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 30 5060 miarec3.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 0 5060 miarec4.example.com.
The first three records share a priority of 10, so the weight field’s value will be used by Cisco UCM to determine which recording server to contact. The sum of all three values is 100, so “miarec1” will be used 40% of the time. The remaining two hosts “miarec2” and “miarec3” will be used for 30% of requests each. If “miarec1” is unavailable, these two remaining servers will share the load equally, since they will each be selected 50% of the time.
If all three servers with priority 10 are unavailable, the records with the next lowest priority value will be chosen, which is “miarec4”. This might me a machine in another physical location, presumably not vulnerable to anything that would cause the first three servers to become unavailable.
Limitations:
- Load balancing provided by SRV records is inherently limited, since the information is essentially static. Current load of servers is not taken into account.
- In case of failover from one server to another, the currently active recordings on a failed server are interrupted. The new recording server will handle only new SIP requests.
Check also: MiaRec automatic replication