Technical Helpweb

Dialogic® PowerMedia™ Extended Media Server (PowerMedia XMS) - more articles

Incoming IP traffic not received by XMS

Introduction:

On a Linux server with Dialogic® PowerMedia™ XMS and having two network interfaces defined (multihomed), in certain configurations it is possible for IP network packets (SIP or RTP) to be dropped. These dropped packets would result in either call control issues or issues with media operations, such as video, audio, or fax issues.

The configuration involves the PowerMedia XMS server’s operating system (“OS”) configuration which has two network interfaces that are set up for asymmetrically routed packets (outgoing route and incoming packet routes are different) and how the Reverse Path Filtering (“rp_filter”) has been set-up.

As an example, assuming the PowerMedia XMS server’s OS has two network interfaces named eth0 and eth1. If PowerMedia XMS is sending IP traffic on network interface eth1 and the remote end point is sending ip traffic to the eth0, based on default settings of the OS’s rp_filter, the incoming traffic from the remote host on eth0 will be dropped. This is to protect the Linux server from malicious attacks such as distributed denial-of-service (DDoS) attacks .

How to identify:

The behavior can be seen by using a tool such as wireshark to see how SIP and RTP IP traffic is flowing between the PowerMedia XMS system and other endpoints. Figure 1 shows an example configuration where the PowerMedia XMS server has two network interfaces defined as eth0 and eth1 that are in communication with an Media Resource Control Protocol (“MRCP”) server that is being used to stream text-to-speech (“TTS”) data.

Figure 1 - Configuration showing RTP packets being dropped (click to enlarge)

The PowerMedia XMS server has two network interfaces, i.e., eth0 and eth1.

• eth0 configured as 192.219.76.1/24 
• eth1 configured as 192.168.1.1/24 
• PowerMedia XMS server’s default IP gateway 192.219.76.3 (not shown)

The PowerMedia XMS network configuration is set up to use 192.219.76.1 (eth0) for SIP signaling and 192.168.1.1 (eth1) for RTP.  The MRCP server is at 10.1.1.1/24 and reachable via 192.168.1.208 router (not shown). The configuration is such that the SIP signaling path between the XMS and MRCP servers is different than the media (RTP) path between the XMS and MRCP servers. With the rp_filter =1, the reverse path filtering is configured for strict mode. In strict mode, the rp_filter will drop the RTP packets coming in on the eth1 packet interface since it is different network interface than the SIP signaling on eth0.  As of April 2016, Red Hat Enterprise Linux 6 and above and CentOS 6 and above have the rp_filter =1 (strict mode) as the default.

For this example configuration in figure 1, a change to the PowerMedia XMS server’s Linux routing table is needed so that MRCP SIP signaling path and media path are on the same interface eth1, 192.168.1.1 and will prevent the RTP packets from being dropped.

To determine the rp_filter settings, the sysctl command can be used to examine how it has been set-up. On the Linux server, run the following command to see the kernel rp_filter setting. When set to 1, the rp_filter is enabled which means if the incoming IP network traffic is using a different network interface, then those packets will be dropped.

[root@xms ~]# sysctl -a | grep "\.rp_filter"
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.enp11s7.rp_filter = 1
net.ipv4.conf.enp12s8.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.virbr0.rp_filter = 1
net.ipv4.conf.virbr0-nic.rp_filter = 1

The rp_filter parameter is defined in Linux document below:

rp_filter - INTEGER
        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path 
            Each incoming packet is tested against the FIB and if the interface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path 
            Each incoming packet's source address is also tested against the FIB
            and if the source address is not reachable via any interface
            the packet check will fail.

        Current recommended practice in RFC3704 is to enable strict mode 
        to prevent IP spoofing from DDos attacks. If using asymmetric routing
        or other complicated routing, then loose mode is recommended.

        The max value from conf/{all,interface}/rp_filter is used 
        when doing source validation on the {interface}.

        Default value is 0. Note that some distributions enable it
        in startup scripts.

Solutions:

To address the network connectivity issues, network security or network configuration may need to be changed. Linux network administration is considered beyond the scope of PowerMedia XMS; however, what follows is guidance on possible solutions. Be sure to consult with your network system administrator before implementing. As of April 2016, the article located here, provides an explanation of the rp_filter and different configuration options for handling incoming IP traffic.

For the PowerMedia XMS installation, it is recommended to use the Linux routing table for defining specific remote hosts that will interface with the PowerMedia XMS server. The type of network configuration needed will differ depending on how the site’s network has been set-up and it is not possible to provide a “one size fits all” solution. Next we provide one possible solution to the example shown in figure 1 above.

Using the figure 1 example, one possible solution is to design the PowerMedia XMS server’s Linux routing tables so that MRCP SIP signaling path and media path are on the same interface eth1, 192.168.1.1. In this configuration the MRCP server is not on either subnet (eth0 or eth1) and the XMS server kernel is using the default gateway of 192.219.76.3 to send SIP signaling messages to the MRCP server.

The PowerMedia XMS server should be changed such that the XMS server will send SIP signaling messages that were formerly going to the MRCP from eth0 (192.219.76.1) to using eth1 (192.168.1.1).

Temporary Solution:

Enter “ip route add 10.1.1.0/24 via 192.168.1.208”. This static route will send the traffic to 10.1.1.0 subnet through 192.168.1.208 router. To see the current routing table, use “route –n” as below. The “ip route add” entry is not permanent.

[root@xmsi ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.1.1.0        192.168.1.208   255.255.255.0   UG    0      0        0 eth1
192.219.76.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
0.0.0.0         192.219.76.3    0.0.0.0         UG    0      0        0 eth0

Solution:

For a non-temporary solution, a change can be made to /etc/sysconfig/network-scripts/route-eth1 as listed below that will have the same effect:

GATEWAY0= 192.168.1.208 

NETMASK0=255.255.255.0 

ADDRESS0=10.1.1.0 

Another option would be to change the rp_filter configuration on how it is handling packets. Note that this involves changes to network security or network configuration; please consult with your network system administrator. In order to change the rp_filter setting adjust the following lines in /etc/sysctl.conf:

net.ipv4.conf.all.rp_filter = 0 

net.ipv4.conf.default.rp_filter = 0 

net.ipv4.conf.eth0.rp_filter = 0 

net.ipv4.conf.eth1.rp_filter = 0 

After making the changes, the network services need to be restarted to take effect.

Using any of the above options, the flow of SIP signaling and media packets will appear as in figure 2 below. The media packets will no longer be dropped and the user will no longer see an interruption of media.

Figure 2 - IP Packet flow after change to network configuration (click to enlarge)

Products:

Dialogic® PowerMedia™ XMS Release 3.x when installed on CentOS 7.x (or equivalent)

Legal Note:

This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to use open source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic responsible for any present or future effects such usage might have, including without limitation effects on your products, your business, or your intellectual property rights.