Configure SIPREC auto-failover for a CFS-Perimeta-MiaRec connection
This article describes the required steps to configure auto-failover for SIPREC recording in scenario when Metaswitch CFS communicates to MiaRec recorder through Perimeta SBC as a SIP Proxy. If Perimeta SBC is not used as a SIP Proxy, then check the appropriate guide.
A network topology is shown in the following diagram.
Here, Metaswitch CFS communicates with two MiaRec recordings servers through Perimeta SBC as a SIP Proxy. DNS SRV records are used to set priorities of the recording servers.
In this configuration, auto-failover is handled by Perimeta SBC rather than CFS.
Step 1. Configure DNS SRV records
Create 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):
# _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”
miarec-siprec.your-domain.com with your domain name accordingly.
Use the appropriate values for
default-interop-profile attributes (check other adjacency on your SBC as a reference).
Explanation of the attributes of this adjacency:
- Important! The setting
signaling-peer-port 0forces Perimeta SBC to use DNS SRV lookup rather than DNS A record loookup. If the signaling peer port is non-zero, then SRV failobrt will not work.
interop/ping-enablesetting, Perimeta SBC will send periodically SIP OPTIONS (keep-alive) message to both MiaRec servers to test their availability.
interop/preferred-transport tcpsetting, 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).
dynamic-routing-domain-matchsetting, 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
signaling-peersetting, 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-portsetting 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
- 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.
- Locate and expand the Controlled Networks object, then the Configured SIP Bindings object below it.
- Locate the SIP Binding previously created for MiaRec recorder (or create new one).
- 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.comin 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
- Make a test call.
- Verify if such call is recorded by the primary MiaRec server. If no calls are recorded, then check the Troubleshooting section below.
- Complete the call.
Simulate a failure of the primary server by stopping the recording service via SSH console:
service miarec stop
Make another test call.
- Verify if such call is recorded by the secondary MiaRec server. If no calls are recorded, then check the Troubleshooting section below.
Restore the recording service on the primary server:
service miarec start
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.
In case of issues, check the following sources:
- Check the alarms for MiaRec SIP Binding in MetaView Explorer.
- Check the 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.
- Enable trace in MiaRec under Administration -> Maintenance -> Troubleshooting and check the collected trace file.