Specifications

MBG Engineering Guidelines, Release 8.0
11 Advanced Options
11.1 Resiliency
Supported MiNet sets have a resiliency list of up to four IP addresses. If a set loses its connection and cannot
reestablish, it will try the next IP address on its list until it has exhausted all IP addresses on its resiliency list. For
MiNet sets supporting persistent resiliency lists, this resiliency list is “remembered” through a power cycle.
The resiliency list can be manually configured with arbitrary IP addresses. Ideally they correspond to multiple
MBG servers, but that is up to the administrator.
In a clustered environment, Mitel recommends populating the resiliency list with nodes in the cluster. If the
cluster is spread across a subnet boundary, include nodes from each subnet to prevent a single point of failure.
Note: The resiliency assignments do not in any way bind a given device to a specific node. Devices that do not
support redirection (a subset of MiNet devices, plus any SIP devices) will stay with the server to which they
initially connected. Clustering load balancing does consider devices that cannot be redirected.
11.2 IP Translations
Multiple servers deployed on the same DMZ need to each be addressable by individual public IPs so Teleworker
clients can reach them. The IP addresses configured on their interfaces should be DMZ addresses, most likely
from the RFC 1918 range to prevent routing to or from the DMZ without specific rules in the firewall and on the
LAN. This presents a problem for MBG servers that need to stream to one another.
Consider an example of two servers, server A and server B, both installed in a DMZ configuration on the same
DMZ.
Public IP DMZ IP
MBG A 66.46.21.11 192.168.0.5
MBG B 66.46.21.12 192.168.0.6
Set 1 connected to MBG-A calls set 2 connected to MBG-B. MBG-B intercepts the signaling and MBG-A sees a
request to stream from set 1 to the public IP of MBG-B. If MBG-A streams to MBG-B via its public IP, there is a
very strong possibility that the firewall will not permit the SRTP traffic to route back to the DMZ that it originated
from, resulting in audio problems. Furthermore, it is a waste of bandwidth on the public side of the firewall to
stream traffic out to it that is destined for a server on the same network once the firewall’s NAT rules take effect.
The solution is simple. Both problems are solved by streaming directly from MBG-A's to MBG-B using their DMZ
addresses. Unfortunately MBG-A is not aware of the existence of MBG-B. This is the purpose of the IP
Translations feature.
In the MBG management GUI, choose Configuration and then IP Translations. In this example, the administrator
would enter the following rule on MBG-A:
Destination address: 66.46.21.12
Translation address: 192.168.0.6
Now when MBG-A encounters the IP address of 66.46.21.12 in the call setup, it translates it to 192.168.0.6
instead. For this to work in both directions, a reciprocal rule must be entered on MBG-B:
Destination address: 66.46.21.11
Translation address: 192.168.0.5
36