The Mediatrix unit uses many services to carry out tasks and support features.

The are two types of services:

• system services : You cannot perform service commands on system services. The service is restarted by using the Reboot button located under the Reboot tab of the DGW Web interface.
  Note: If the unit is in use when clicking Reboot, all calls are terminated.
• user services: You can perform service commands on user services. The service is restarted by using the start

button located under the Services tab of the DGW Web interface, next to the service.

When a service needs to be restarted, the restart required services is systematically displayed. If you are not able to restart a service because it is a system service, click the Reboot link in the top menu. The Reboot page then opens. You must click Reboot. This restarts the Mediatrix unit. If the unit is in use when you click Reboot, all calls are terminated

Services can also be restarted via the CLI using the Scm.ServiceCommandsRestart parameter.

The Mediatrix unit uses many services to carry out tasks and support features.

When a system or a user service needs to be restarted, the Some changes require to restart a service to apply new configuration message is systematically displayed on the DGW Web pages. Also, every service has the NeedRestartInfo CLI/MIB parameter to indicate if the service needs to be restarted for the configuration to fully take effect.

The administrator can disable the use of specific endpoints or all endpoints of a unit through the administrative state configuration. It is also possible to select the initial endpoint state to be applied on unit start-up.

An event is something that happens in the system and that needs to be reported. Event notifications are formatted text messages issued by the DGW software to signal something of interest to the unit administrator.

Event notifications can be logged by a Syslog server.

It is possible to send the event notifications to a SIP server.

The event notifications sent to a SIP server are included in the SIP Notify messages. When choosing to send event notifications to a SIP server, it is not allowed to send all notifications, i.e. select the All criteria when configuring event notifications. This has been implemented to avoid sending high volumes of traffic and risking the overload of the SIP server.

The destination can be configured with the sipEp.sipNotificationsGateway parameter and the sipEp.maxNotificationsPerNotify parameter is used to define how many messages can be sent in a single "SIP NOTIFY" request the

For more details, refer to DGW Configuration Guide - Reference Guide published on the Media5 documentation portal at https://documentation.media5corp.com

The DGW Local Log displays the Event Notifications related to the events occurring on the Mediatrix unit that are generated by the Mediatrix Notifications and Logging Manager (Nlm) service.

Notifications will be displayed in the Local Log Entries table of the DGW Web interface provided the issuing of events for a service is enabled, and if the event meets the selected severity level chosen to be reported.

The event notifications can be logged in a file saved in the DGW File Management system.

Event notifications logged to a file will be available in the DGW Web interface, under Management/File tabs. The log to file feature is not available on the Mediatrix 4102S and C7 Series as they do not have more than 1MB or more user storage. The number of files stored in the unit is limited. When the maximal number is reached, the oldest stored file is deleted. The limit is configured in the LogFileMaxNb Mib parameter.

The event notification can be sent via the SNMP transport.

Packet captures are data packets intercepted when passing through a specific computer network.

Captured packets can be sent to a specific location where they can be analysed. The content of the capture can therefore be used to diagnose or troubleshoot network problems and determine if network security policies are being followed.

Diagnostic Traces are specifically used for troubleshooting purposes. As for Event Notifications, they report errors, warnings, or system information.

Diagnostic Traces do not need to be activated, except at the specific demand of Media5 Technical Assistance Center.

The PCM traces are two different RTP streams made specifically to record all analog or digital signals that are either sent or received by the telephony ports of the Mediatrix unit.

These RTP streams are sent to a configurable IP address, normally an IP address on your network where it can be recorded with a packet sniffer (such as Wireshark). Moreover, they are independent from the regular RTP streams of the VoIP call. On the analog devices, the streams are sent instantly at device start-up, with an average ptime of 5 ms. The resulting streams, depending on the model, are around 15 kB/s.

Only the configured port, port #1 and/or #2 send the PCM traces for a maximum of four simultaneous RTP streams.

All streams are sent instantly at start-up with an average ptime of 15 ms. This means that until the PCM traces are disabled, even an idle unit will continuously send up to 66.6 packets/s X 4 streams = 267 packets/s using approximately 174 bytes each, for a total of 46 Kbytes of upstream bandwidth.

On digital devices, the streams will be sent once a call is in process of being established (ISDN SETUP, SIP INVITE). This means no data will be sent if the gateway is idle with no calls in progress.

The name is set when adding a new virtual machine with the CreateVm command. The user cannot modify the name after.

When the CreateVm command is called without a name, the index is used to generate a unique name such as VM_Index.

When adding a VM with the CreateVm command, the amount of allocated memory is set; this amount cannot be modified after adding the VM.

When the CreateVm command is called without an amount of allocated memory, a minimal value of 128 MB is set.

The VM config allows the user to associate none or all USB Ports to a virtual machine.

A USB port can be associated with one VM. The first VM that is configured with USB can use all available USB ports.

If an another VM tries to use a USB port already in use, the Vm service ignores this config and starts the VM as if it was configured with NONE, and sets its configuration status (ConfigStatus) to USBNotAvailable.

Enabling the Virtual Switch with the Eth.Links.VirtualSwitch parameter grants network access to the VM. Once enabled, the virtual switch creates a bridge between the VM and the associated Ethernet link.

When the Virtual Switch is enabled, the Vm.Vm.NetworkAdapter parameter configures its virtualised network adapter.

The unit can be preinstalled with a factory-installed VM stored in the vm/images/factory folder. This folder can only be created in factory and must have the factory-installed VM files.

In all cases, the content of /vm/drives is erased.

These vulnerabilities allow a non-privileged process to read sensitive data in memory, thus accessing privileged information from the kernel or other processes.

A Virtual Machine (VM) running inside the Sentinel 400 may be vulnerable to Meltdown (CVE-2017-5754) and to the two variants of Spectre (CVE-2017-5753 and CVE-2017-5715).

For more information on these vulnerabilities:

• https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
• https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

Mediatrix units running a Virtual Machine are equipped with various sizes of Solid State Drive (SSD) for storage.

A Solid State Drive (SSD) is a form of flash-based storage. Media5 uses high quality, enterprise grade SSDs in its products. However due to its technical nature, flash memory can handle so many read/write cycles. Beyond that, the performance may degrade or in extreme cases, the drive may fail. For customers using a Mediatrix unit running a Virtual Machine, special attention should be paid to the number of writes caused by the Operating System running in the virtual machine, as well as by the application. If the Virtual Machine is not optimised, it will lead to excessive read/write access to the SSD, and hence significantly reduce the lifespan of the SSD. For more details, please refer to Technical Bulletins - Virtual machine installation published on the Media5 Documentation Portal.

SSD lifespan can be extrapolated and Virtual Machine optimisation can be validated.

For example, let the virtual machine run for a month (or a week), read and compare the WearPercentage parameter at different times during this interval. Use the collected information to extrapolate the lifespan.

For example: the Wear Percentage increased from 19% to 20% in 2 months. Take the remaining 80% divided by a monthly increase of 0.5% gives 160 months left. Therefore at least 13 years left at the current increase rate.

The DGW firmware in the Mediatrix system, by itself, is not vulnerable since it does not allow running rogue code:

• https://www.media5corp.com/media5-statement-meltdown-spectre-vulnerabilities/

But it is theoretically possible, for a Virtual Machine compromised by the Spectre vulnerability, to read memory outside the Virtual Machine and access sensitive data of the Mediatrix system. The best protection against this is to secure your VM, to make sure there is no known means an attacker can use to break into your VM.

Media5 also recommends to always keep your Sentinel 400 up-to-date with to the latest DGW firmware version.

The DNS server list is the ordered list of DNS servers that the device uses to resolve network names.

Up to four servers can be used. The DNS servers can be specified statically or obtained automatically (for example through DHCPor PPP). DNS query results are cached on the system to optimise name resolution time. For more details, refer to DGW Configuration Guide - DNS Behavior with Mediatrix Gateways published on the Media5 Documentation Portal.

The Simple Network Time Protocol (SNTP) is used to update and synchronise the clock of the Mediatrix unit (day, month, time) when it is restarted.

Mediatrix units do not all include a real time clock allowing them to maintain accurate time when they are shutdown. Your system needs to have access to accurate time, for example if you are using HTTPS or for the caller ID feature. The Mediatrix unit implements a SNTP client, which can synchronise the local clock with remote NTP/SNTP servers. The configuration can be automatic (through DHCP for example), with fallback, or static, with up to four servers.

The time format (also known as 'TZ' format) is based on the format described by the IEEE 1003.1 standard (i.e. POSIX specification).

STDOFFSET[DST[OFFSET],[START[/TIME],END[/TIME]]]

Before connecting the Mediatrix unit to the network, Media5 strongly recommends to reserve an IP address in your network server – if using one – for the unit you are about to connect.

This way, the IP address associated with a particular unit will be known. Network servers generally allocate a range of IP addresses for use on a network and reserve IP addresses for specific devices using a unique identifier for each device. The Mediatrix unit unique identifier is the media access control (MAC) address. Refer to Locating the MAC Address of Your Mediatrix Unit.

There are four Network Interfaces created by default on the Mediatrix unit: Uplink, Lan 1, UplinkV6, and Rescue.

The Link Layer Discovery Protocol (LLDP) service is used by network devices for advertising their identity, capabilities, and neighbors on a IEEE 802 local area network, usually wired Ethernet.

LLDP cannot be activated on more than one network interface at a time.

Each Ethernet port of the Mediatrix unit is associated with an Ethernet link.

An Ethernet link has connectivity if at least one of its port status is not disconnected. The link connectivity is periodically polled (every 500 milliseconds). It takes two consecutive detections of the same link state before reporting a link connectivity transition. This avoids reporting many link connectivity transitions if the Ethernet cable is plugged and unplugged quickly.

When the Mediatrix unit restarts, it establishes the connection to the access concentrator in conformance with RFC 2516 section 5.1.

When the Type drop-down menu is set to IPv6 Auto-Conf, the network interface is an IPv6 over Ethernet connection with IP parameters obtained by stateless auto-configuration or stateful (DHCPv6) configuration.

All IPv6 addresses present in the router advertisements are applied to the network interface

Many network switches use the Spanning Tree Protocol (STP) to manage Ethernet ports activity.

STP uses a detection timeout before a router advertisement is sent to the Mediatrix unit. The default value for this timeout is usually 30 seconds. However, when the unit wants to get an IPv6 address in Stateless autoconfiguration, this timeout is too long and the unit falls into Stateful Autoconfiguration mode before it receives the router advertisement. This results in the unit receiving a DHCPv6 address. To solve the issue, check if the default STP detection timeout value in your router can be modified. If so, set it to a value of 8 s or less. If you cannot modify the timeout value, Media5 recommends to disable the Spanning Tree Protocol on the network to which the unit is connected.

Stateful autoconfiguration is managed by DHCPv6. The DHCPv6 lease is negotiated according to the limitations listed in section 1.5 of RFC 3315.

There are two protocols for detecting the Ethernet link speed: parallel detection and auto-negotiation (IEEE 802.3u).

The auto-negotiation protocol allows the detection of the connection speed and duplex mode. It exchanges capabilities and establishes the most efficient connection. When both endpoints support the auto-negotiation, there are no problems. However, when only one endpoint supports auto-negotiation, the parallel detection protocol is used. This protocol can only detect the connection speed; the duplex mode cannot be detected. In this case, the connection may not be established. The Mediatrix unit has the possibility to force the desired Ethernet link speed and duplex mode by disabling the auto-negotiation and selecting the proper setting. When forcing a link speed at one end, be sure that the other end (a hub, switch, etc.) has the same configuration. To avoid any problem, the link speed and duplex mode of the other endpoint must be exactly the same.

QoS (Quality of Service) features enable network managers to decide on packet priority queuing.

Differentiated Services (DiffServ, or DS) is a protocol for specifying and controlling network traffic by class so that certain types of traffic (for example voice traffic which requires a relatively uninterrupted flow of data) might get precedence over other kinds of traffic.

DiffServ replaces the first bits in the ToS byte with a differentiated services code point (DSCP). It uses the existing IPv4 Type of Service byte. In DGW the entire ToS byte is currently configurable, thus the ToS decimal value is used. Please refer to:

• https://tools.ietf.org/html/rfc2474 for the definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.
• https://en.wikipedia.org/wiki/Differentiated_services for the differentiated services.

It is possible to apply bandwidth limitations to the network interfaces.

The limitations are applied on the raw data of the physical link and not only on the payload of the packets. All headers, checksums and control bits (TCP, IP, CRC, etc.) are considered in the actual bandwidth. A bandwidth limitation is applied on a physical link and not on a virtual network interface. All high-level network interfaces (including VLANs) using the same physical link are affected by a configured limitation. This limitation is applied to outgoing traffic only (egress). Bandwidth limitation is an average of the amount of data sent per second. Thus, it is normal that the unit sends a small burst of data after a period of silence.

The local firewall allows you to create and configure rules to filter incoming packets that have the Mediatrix unit as destination.

The Local Firewall is therefore a security feature that allows you to protect your Mediatrix unit from receiving packets from unwanted or unauthorized peers. As a best practice, the way the Local Firewall should work is to, by default, drop all incoming packets (i.e. not forward the packet to its destination) and let incoming packets go through only if they match a rule requirements. However, incoming packets for an IP communication established by the Mediatrix unit are always accepted (Example : If the Mediatrix unit sends a DNS request, the answer will be accepted).

When configuring the Local Firewall, enabling the default policy to drop all incoming packets should be the last step you perform otherwise, you may lose contact with the Mediatrix unit, even if you are performing the initial configuration of your system. Therefore, start by creating the rules that allow the Mediatrix unit to accept some packets. This way communication will not be lost and you will not need to perform a partial or factory reset to reconnect with the Mediatrix unit.

You can use a maximum of 20 rules, but the more rules are enabled, the more overall performance is affected.

The order in which the incoming packets are tested against the rules is important if you want to make sure that they actually have a filtering effect on incoming packets.

Rules can be configured to accept or to decline packets. But, always put the most restrictive rules first as they are executed sequentially starting with the first one listed at the top of the table i.e. make sure that the order in which the rules are executed does not cause a rule to be systematically excluded.

Network IP routing defines the routes for outgoing network traffic, where each route is associated with a network interface. The selection of which route a network packet should follow is generally based on the destination IP address criteria.

The Static IPv4 Routes are used to specify additional routes from the default ones automatically created by the configuration of the various network interfaces (see the BNI service).

The Advanced IP Routes are used only when IPv4 Forwarding is enabled, and allow to select a route, not just from the destination IP address, but also from the source IP address and interface criteria.

The Network firewall allows you to dynamically create and configure rules to filter incoming packets forwarded by the Mediatrix unit among its network interfaces, when the unit is used as a router. Its main functionality is to secure the traffic routed from and to the devices inside the local network.

Since this is a network firewall, rules only apply to incoming packets forwarded by the unit. The traffic is analyzed and filtered by all the rules configured. If no rule matches the incoming packet, the default policy is applied. A rule's priority is determined by its index in the table. Rules using Network Names are automatically updated as the associated IP addresses and network mask are modified. If the Network Firewall service is stopped, all forwarded traffic is accepted, this tab is greyed out and the parameters are not displayed.

Of course, the more rules are enabled, the more overall performance is affected. You can use a maximum of 20 rules.

The order in which the incoming packets are tested against the rules is important if you want to make sure that they actually have a filtering effect on incoming packets.

Rules can be configured to accept or to decline packets. But, always put the most restrictive rules first as they are executed sequentially starting with the first one listed at the top of the table i.e. make sure that the order in which the rules are executed does not cause a rule to be systematically excluded.

Network Address Translation (NAT, also known as network masquerading or IP masquerading) rewrites the source and/or destination addresses/ports of IP packets as they pass through a router or firewall. It is most commonly used to connect multiple computers to the Internet (or any other IP network) by using one IP address. This allows home users and small businesses to cheaply and efficiently connect their network to the Internet.

The basic purpose of NAT is to multiplex traffic from the internal network and present it to the Internet as if it was coming from a single computer having only one IP address. The Mediatrix unit’s NAT service allows the dynamic creation and configuration of network address translation rules. Depending on some criteria, the packet matching the rule may see its source or destination address modified.

A NAT rule specifies a set of matching conditions for network packets.

The NAT rules are applied on a first match basis, in the order they appear in the configuration.

Because the first match is applied, you must ensure that specific rules come before more general rules, or the specific rules might not be applied as desired.

When using the Network Firewall service, it is important to configure it with respect to the Destination NAT rules because:

An example of this would be port forwarding where the DNAT changes the routed address of a packet to a new IP address/port. The Network Firewall must also accept connection to this IP/port in order for the port forwarding to work.

The Mediatrix unit contains an embedded DHCP server that allocates IP addresses and provides leases to the various subnets that are configured

These subnets could have PCs or other IP devices connected to the unit’s LAN Ethernet connectors. These devices could be any combination of switches, PCs, IP phones, etc. If the DHCP service is stopped (which is the default configuration), the DHCP Server tab is greyed out and the parameters are not displayed.

A parameter’s configuration source can be toggled. Here are the possible configuration sources:

The following table lists the configuration parameters and their available configuration sources:

The DHCP server manages hosts’ network configuration on a given subnet. Each subnet can be seen as having a distinct DHCP server managing it, which is called a subnet server.

To activate a subnet server for a given network interface, the name of that network interface and the name of the subnet must match, the subnet enable option must be enabled and the configuration of the subnet must be valid. Only one subnet can be defined per network interface.

The network interface can be a physical interface or a logical interface (ex: sub-interface using VLAN). The subnet server status is updated dynamically according to many parameters.

When an address is leased to a host, several network configuration parameters are sent to that host at the same time according to the options found in the DHCP request. Parameters are set to default at subnet creation time. A parameter can be defined with a subnet specific configuration.

The subnet server will not send a parameter with an empty value. This means that if a client requests a domain name and the subnet server domain name parameter contains an empty field, the subnet server will not add the domain name option in the DHCP response.

In order to assign leases, the subnet server draws from an IP address pool (or subnet scope) defined by a start address and an end address. The subnet mask assigned to hosts is taken directly from the network interface. All hosts on the same subnet share the same configuration. The maximum number of supported hosts on a subnet is 254.

Specific IP addresses (static leases), designated by their MAC address, can be defined as reserved for specific hosts.

The subnet server will always assign leases within the IP address pool with an exception for static leases. When a static lease is defined for the host requesting an address, this lease will be assigned to the host if the IP address is within the subnet range even if the address is not within the IP address pool.

Call Agents represent logical end-points that connect the Mediatrix unit to peers.

For security reasons, the Mediatrix unit communicates by default only with well-known and defined peers. When a request cannot be associated with a Call Agent, it is rejected. Each Call Agent is tied to a specific peer, ensuring all inbound and outbound communications with that peer. Routing rulesets are used to route SIP signaling between Call Agents, where inbound requests from a Call Agent are sent to another (or the same) Call Agent that will send an outbound request to it's related peer. Call Agents can be associated with one or several Rulesets which can be applied to the inbound or the outbound requests.

When there is an inbound request, to determine the Call Agent the inbound request will go through, the Mediatrix unit uses the destination IP address to choose the Network interface. Then the destination port of the inbound request will determine the Signaling or Media Interface used. Finally, the source address and the source port, will allow the Mediatrix unit to direct the request to the appropriate Call Agent. At this point any Rulesets associated with the Call Agent will be applied in order of priority.

When a request is sent out, i.e. there is an outbound request, the Routing Rulesets will determine which Call Agent will be used. Then the Call Agent Rulesets will be applied to the outbound request, in reverse priority order. The outbound request will then be sent through the Signaling and Media Interface associated with the Call Agent. If the public IP address is used, then the SIP request will use this address as the source IP address. The outbound request will then be sent to the peer address of the Call Agent or according to the routing Ruleset if the peer is a Network.

In addition, a Call Agent tracks REGISTER requests or monitor the peer host using SIP options. When these features are activated, the Call Agent registration state and monitoring state are updated allowing a Routing Ruleset to select another Call Agent based on the state of a primary Call Agent.

Eight default types of Call Agents were created for Mediatrix unit. This should be enough to cover all your needs. However, for advanced users, it is possible to create new Call Agents.

Seven of the eight default Call Agents allow the Mediatrix unit to communicate with seven different types of end-points.

The phone_lines_ca Call Agent is used to route calls via an FXS port of the Mediatrix unit.

Typically it will route calls to and from analog phones and faxes within the enterprise premises. This Call Agent will be used for example when a call is routed from one colleague to another using analog phones connected on the FXS ports of the Mediatrix unit. In such a scenario, the call does not go through the LAN network nor the Internet. Since by default this Call Agent uses the loop_m Media Interface to route the media, the media_relay Ruleset is usually associated with this Call Agent.

The phone_lines_ca Call Agent is associated with the phone_lines_gw gateway of the SipEp service. By default, each FXS port sends a REGISTER by the phone_lines_ca Call Agent. Therefore, the administrator must make sure to route these REGISTERs to a server, or to disable them in the SipEp service. If needed, FXS ports can be configured in the Pots service.

The trunk_lines_ca Call Agent is used to route calls to the Public Switch Telephony Network (PSTN) or a enterprise's existent PBX through the PRI, BRI or FXO ports of the unit.

Calls made outside the enterprise premises to telecommunication service providers or calls made within the enterprise through a PBX will typically be routed through this Call Agent. Since by default this Call Agent uses the loop_m Media Interface to route the media, the media_relay Ruleset is usually associated with this Call Agent.

If there are no PRI, BRI or FXO card on the unit, calls through trunk lines can also be routed by the wan_ip_trunk_ca or secondary_ip_trunk_ca Call Agent, provided there is an analog or digital gateway to convert the VoIP call to an analog or digital call, or vice versa.

Further more, the trunk_lines_ca Call Agent is associated with the trunk_lines_gw of the SipEp service. FXO/PRI/BRI ports will need to be configured in either the Pots, Isdn, R2 or Eam services for the calls to be routed properly.

The local_users_ca Call Agent is used to route calls from and to local users, i.e. located in the LAN, via VoIP calls.

For the call to use this Call Agent, the endpoint must belong to the company and use the company's system. This Call Agent is often used as a regrouping point of all local endpoints to be routed to a PBX or Trunk lines. For instance, if you are a Media5 corporation employee, with a cell phone using the Media5 fone application and the entreprise IP-PBX, then your call will be routed through the local_users_ca Call Agent. If an internal employee is using an analog phone, the call can also be routed through this Call Agent provided the call goes first through a gateway to convert the analog call into a VoIP call.

The remote_users_ca Call Agent is used to route calls from users working out the office and using VoIP calls through an external network or Internet.

Calls are routed through a WAN then to the Mediatrix unit via the remote_users_ca Call Agent.

The lan_ip_pbx_ca Call Agent routes calls to and from an IP PBX located in the LAN. The IP PBX manages all internal communications between different SIP clients (soft phones or SIP gateways).

This Call Agent is usually used to link a local PBX with an external trunk (IP or PSTN).

The wan_ip_trunk_ca Call Agent is used to route VoIP calls.

Calls are routed from or to the main SIP server or provider located in the WAN. Typical peers for this Call Agent are the head office of the enterprise, an Internet telephony service provider (ITSP) or an IP Multimedia Core Network Subsystem (IMS).

The secondary_ip_trunk_caCall Agent is used to route VoIP calls.

This Call Agent is identical to the wan_ip_trunk_ca Call Agent. The secondary_ip_trunk_ca can be used for different purposes. The most common use for this Call Agent, is to route calls to and from the backup server in the event the primary server does not respond. However, this Call Agent can also be used, for example, to route calls directly to and from a Branch Office or route a specific type of call such as international calls. Typical peers for this Call Agent are the head office of the enterprise, an Internet telephony service provider (ITSP) or an IP Multimedia Core Network Subsystem (IMS).

The registration_ca Call Agent is used to route the registrations issued by the Registration Agent.

The registration_ca Call Agent should not be used for other purposes. The registrations issued by the Registration Agent must be routed from the registration_ca to the Call Agent facing the destination Sip registrar (typically wan_ip_trunk_ca_ca or secondary_ip_trunk_ca).

The registration is routed using the User Name, Password and Domain to build the AOR and the R-URI . The Contact is the contact header of the registration, it should contain the IP-address or FQDN of the Mediatrix unit.

The Signaling Interface is used for SIP signaling and the Media Interface is used for media ( RTP, UDPTL ) processing.

When configuring a Call Agent, you must select a Signaling Interface and a Media Interface. These interfaces are used whenever SIP signaling or media packets are sent to or received by the Call Agent.

It is possible to create several Signaling and Media Interfaces on the same Network Interface but for different purposes. For example, one set of Signaling and Media Interfaces for a WAN SIP Trunk and another set of Signaling and Media Interfaces for remote user calls. This means, for instance, that two Signaling Interfaces will be created on the same Network Interface, using the same IP address, but with a port range that will differ according to their intended use and to avoid conflicts.

A Media or Signaling Interface can be used by more than one Call Agent, but a specific Signaling or Media Interface can be created for a specific Call Agent. This provides the liberty to define non conflicting range of contactable interfaces on any physical network interfaces of the units for your network structure needs (such as Vlans, PPPoE interfaces, multiple Ethernet ports or multiple addresses on a link).

loop_m and loop_s interfaces are used to communicate with the internal services of the unit. For example, the loop interfaces can be used to communicate with the SipEp service to access phone ports.

The penalty box feature is enabled for a specific Call Agent to temporarily avoid contacting the peer hosts (addresses) that are expected not to answer.

Without the use of the penalty box, DNS SRV failover is delayed until the SIP transaction times out. In a DNS SRV failover, without the use of the penalty box, the Call Agent will first try to communicate with the peer host on the first server, then once the SIP transaction has timed out, it will try the second and so on, always waiting for the SIP transaction timer to expire. With the penalty box, the call Agent will not try any servers that are already in the penalty box. Remember, dynamic call routing (e.g. survivability) based on server availability requires the penalty box to be enabled.

It is possible to configure how much time a peer host will remain in the penalty box, and the delay before which a peer host is considered down. This delay starts after the expiration of the transaction timer. It is also possible to disable the penalty box feature by using the special value 0 as the duration the peer host will remain in the penalty box.

The Keep-Alive monitoring parameter allows the unit to periodically send messages to a server to make sure the server can still be reached.

The Keep-Alive parameter is set individually for each Call Agent. SIP options are sent periodically for each Call Agent to their corresponding server. Any response received from the server means that it can be reached. No additional processing is performed on the response. If no response is received after the retransmission timer expires, the Sbc service considers the server as unreachable. In this case, any call attempt through the Call Agent is refused and the peer host will be sent to the Penalty Box. SIP options are still sent when the server cannot be reached and as soon as it can be reached again, new calls are allowed.

Rulesets define one or several rules used to filter, manipulate or route inbound or outbound requests.

When a request arrives at a Call Agent from a peer, the inbound rules of the Rulesets associated with the Call Agent are executed. Then, Routing Rulesets are executed until a Call Agent is selected for the destination. Last, the outbound rules of the Rulesets associated with the destination Call Agent are executed before sending the request to the peer.

Inbound rules of the Ruleset are executed in ascending Ruleset priority order. Outbound rules are executed in descending Ruleset priority order.

The Mediatrix unit is fundamentally rule driven. This means that almost all features can be activated based on certain conditions evaluated at run-time, based on parts of the signaling messages or media payload. All rules are constructed using the same pattern. They consist of a set of one or more conditions. If all conditions apply (logical conjunction), a set of one or more actions is executed. It is important to understand that rules are generally applied only on incoming or outbound requests. However, some rules have a scope that goes beyond these incoming or outbound requests. For example, header filters apply to all requests exchanged, including incoming requests.

Call Agent Rulesets have an *.crs extension and Routing Rulesets use the *.rrs extension. For more details on Ruleset conditions and descriptions, refer to the DGW Configuration Guide - Reference Guide document published on the Media5 Documentation Portal.

Ruleset replacement expressions are used when the value of a parameter, a command or an action is not known in advance, i.e. the value depends on the result of the SIP message processing.

A Ruleset replacement expression is a string that represents a SIP processing status. Replacement expressions always start with the dollar (“$”) sign followed by an identifier. When the Ruleset uses a replacement expression, the replacement expression is replaced by the value of the SIP processing status representing the replacement expression.