Skip to end of metadata
Go to start of metadata

Download PDF Document

2018-07-11

For Mediatrix Sentinel and Mediatrix 3000

v. 42.3.986


1 Configuration notes

These documents are created to facilitate the configuration of a specific use case. They address a configuration aspect we consider that most users will need to perform. However, in some cases, a configuration note is created after receiving a question from a customer. They provide standard step by step procedures detailing the values of the parameters to use. They provide a means of validation and present some conceptual information. The configuration notes are specifically created to guide the user through an aspect of the configuration.

To access the configuration notes, go to Configuration notes.

2 Call Agents

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. The same Call Agent can be used for inbound and outbound requests. However, in most cases, the inbound request will go through one Call Agent and the outbound request will use another Call Agent. Call Agents are then identified as the inbound Call Agent and the outbound Call Agent, indicating if the Call Agent is managing an inbound or an outbound request.

Call Agents can be associated with one or several Rulesets which can be applied to the inbound or the outbound requests. A Call Agent can be assigned to Signaling and Media Interfaces which are associated with Network Interfaces. To determine the Call Agent an incoming 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 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, 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 request will then be sent to the Signaling Interface associated with the Call Agent. The outbound request will be sent to the Network Interface associated with the Signaling Interface. 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 default Call Agents allow the Mediatrix unit to communicate with seven different types of end-points.

Call Agent Name Endpoint Type
wan_ip_trunk_ca SIP server located on the WAN.
trunk_lines_ca Public Switch Telephony Network (PSTN), through PRI, BRI or FXO ports.
phone_lines_ca Telephones, through FXS ports.
lan_ip_pbx_ca IP Private branch exchange (PBX) located on the LAN.
local_users_ca Users via SIP telephony located on the LAN.
remote_users_ca Users using SIP telephony located on the WAN.
registration_ca Used to route the registrations issued by the Registration Agent.
secondary_ip_trunk_ca SIP server if the wan_ip_trunk_ca Call Agent is not available.

For more details on Rulesets, refer to Rulesets.


2.1 phone_lines_ca Call Agent

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.


2.2 trunk_lines_ca Call Agent

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.


2.3 local_users_ca Call Agent

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.


2.4 remote_users_ca Call Agent

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.


2.5 lan_ip_pbx_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).


2.6 wan_ip_trunk_ca Call Agent

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).


2.7 secondary_ip_trunk_ca Call Agent

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).


2.8 registration_ca Call Agent

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.


2.9 Configuring a Call Agent

Context

If you are not familiar with the meaning of the fields and buttons, click Show Help, located at the upper right corner of the Web page. When activated, the fields and buttons that offer online help will change to green and if you hover over them, the description will be displayed.

Steps

  1. Go to SBC/Configuration.
  2. In the Call Agent Configuration table, click Edit located on the row of the Call Agent you wish to configure.
  3. In the Configure Call Agent table, complete the fields as required and make sure the Enable check box is selected.

    Note

    Monitoring Parameters are not mandatory.

  4. Complete the fields of the Call Agent Configuration as required.
  5. Click Save.

    Note

    The changes are saved, but not all applied to the configuration.

  6. Click Apply to apply all changes to the configuration.

Result

No will be displayed in the Config. Modified field, indicating that the configuration that was modified is now applied to the system. When the Mediatrix unit will use the selected Call Agent for a communication, the selected parameters will be applied.

3 Signaling and Media Interfaces

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).

The following Signaling and Media Interfaces are supplied by default:

  • lan1_m
  • lan1_s
  • loop_m
  • loop_s
  • uplink_s
  • uplink_m

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.


3.1 Creating a Media Interface

Before You Start

A Network Interface must be configured.

Context

If you are not familiar with the meaning of the fields and buttons, click Show Help, located at the upper right corner of the Web page. When activated, the fields and buttons that offer online help will change to green and if you hover over them, the description will be displayed.

Steps

  1. Go to SBC > Configuration.
  2. In the Media Interface Configuration table, click .

    Note

    A new line of empty fields is added to the Media Interface Configuration table. An error message will be displayed indicating that the configuration of the row is invalid. This is normal as the Media Interface is not yet configured.

  3. In the Media Interface Configuration table, complete the fields as required.

    Note

    The Network Interfaces displayed in the Network column, are created under Network > Interfaces tab.

  4. Click Save.

    Note

    The changes are saved, but not all applied to the configuration.

  5. Click Apply to apply all changes to the configuration.
  6. Click restart required services, located at the top of the page.

Result

The Media Interface will be available when configuring a Call Agent, in the Media Interface selection list of the Configure Call Agent page.

3.2 Creating a Signaling Interface

Before You Start

A Network Interface must be configured. IPv6 is not supported, therefore Ipv6 configured Network interfaces cannot be used.

Context

If you are not familiar with the meaning of the fields and buttons, click Show Help, located at the upper right corner of the Web page. When activated, the fields and buttons that offer online help will change to green and if you hover over them, the description will be displayed.

Steps

  1. Go to SBC/Configuration.
  2. In the Signaling Interface Configuration table, click .

    Note

    A line is added to the Signaling Interface Configuration table. An error message will be displayed indicating that the configuration of the row is invalid. This is normal as the Signaling Interface is not yet configured.

  3. In the Signaling Interface Configuration table, complete the fields as required.

    Note

    The Network Interfaces displayed in the Network column, are created under Network > Interfaces page.

  4. Click Save.

    Note

    The changes are saved, but not all applied to the configuration.

  5. Click Apply to apply all changes to the configuration.
  6. Click restart required services, located at the top of the page.

Result

The Signaling Interface will be available when configuring a Call Agent, in the Signaling Interface selection list of the Configure Call Agent page.

4 Rulesets

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

There are two types of Rulesets:

  • Call Agent Rulesets : they describe how inbound or outbound requests are handled by a specific Call Agent. They can also implement services or collect data.
  • Routing Rulesets: they are used to globally route outbound requests, i.e. that they apply to all Call Agents.

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 Agents can have two origins:

  • Factory: Read only Ruleset delivered with the application.
  • Custom: User defined Ruleset.
A custom Ruleset has priority over a factory Ruleset. If a custom Ruleset is created with the same name as a factory Ruleset, it is the custom Ruleset that will be shown and used. Once the custom Ruleset is deleted, the factory Ruleset will be reactivated. Cloning, editing and saving a factory Ruleset will create a custom Ruleset without modifying the factory Ruleset.

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 Reference Guide .


4.1 Creating a New Ruleset

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets.

Note

To save time, consider Cloning a Ruleset.

Steps

  1. Go to SBC > Rulesets.
  2. In the Rulesets page, enter a name in the empty field of either the Call Agent Rulesets or Routing Rulesets table.
  3. Click .

    Note

    The name of the Ruleset will be added at the end of the table.

  4. In the Rulesets page, click located on the row of the Ruleset you have just created.
  5. In the Ruleset Edit page, in either the Outbound Rules or Inbound Rules, click Insert new rule.
  6. In the Conditions and Actions section, complete the fields as required.

    Note

    For more details on Actions and Conditions, refer to the Reference Guide .

  7. If necessary, click Add condition to add another condition.
  8. If necessary, click Add to add another action.
  9. Click Save.

    Note

    The new rule is saved but the modified configuration is not yet applied to the system.

    Note

    Rules are executed from top to bottom. Consider Changing the Execution Priority Level of a Ruleset Rule.

  10. Go to SBC > Configuration.
  11. Click Apply.

    Note

    The modified configuration is applied to the system.

Result

The new Ruleset is available to be associated with a Call Agent.

4.2 Cloning a Ruleset

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets

Steps

  1. Go to SBC > Rulesets.
  2. In the Rulesets page, click next to the Ruleset you wish to clone.
  3. Click OK.

    Note

    The cloned Ruleset will be added at the end of the table. The name of the cloned Ruleset will include a numerical suffix to distinguish it from the original Ruleset.

  4. In the Rulesets page, click located on the row of the Ruleset you have just cloned.
  5. Click Edit next to the rules you wish to modify.
  6. In the Conditions and Actions section, modify the fields as required.

    Note

    For more details on Actions and Conditions, refer to the Reference Guide.

  7. If necessary, click Add condition to add another condition.
  8. If necessary, click Add to add another action.
  9. Click Save.
  10. Click Change Name /description to change the name and the description of the Ruleset.
  11. Click Save.

    Note

    The new cloned rule is saved but the modified configuration is not yet applied to the system.

    Note

    Rules are executed from top to bottom. Consider Changing the Execution Priority Level of a Ruleset Rule.

  12. Go to SBC > Configuration.
  13. Click Apply.

    Note

    The modified configuration is now applied to the system.

Result

The new Ruleset is available to be associated with a Call Agent.

4.3 Modifying a Ruleset

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets

Steps

  1. Go to SBC > Rulesets.
  2. In the Rulesets page, click located on the row of the Ruleset you wish to modify.
  3. In the Ruleset Edit page, click Edit located on the row of the rule you wish to modify.
  4. In the Conditions and Actions section, modify the fields as required.

    Note

    For more details on Actions and Conditions, refer to the Reference Guide .

  5. If necessary, click Add condition to add another condition.
  6. If necessary, click Add to add another action.
  7. Click Save.

    Note

    The modified rule is saved but the modified configuration is not yet applied to the system.

    Note

    Rules are executed from top to bottom. Consider Changing the Execution Priority Level of a Ruleset Rule.

  8. Go to SBC > Configuration.
  9. Click Apply.

    Note

    The modified configuration is now applied to the system.

Result

The Ruleset will be applied with the new changes.

4.4 Adding Rules to a Ruleset

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets

Steps

  1. Go to SBC > Rulesets.
  2. In the Rulesets page, click located on the row of the Ruleset for which you wish to add a rule.
  3. In the Ruleset Edit page,
    • click Insert new rule to add a rule at the top of the list of rules
    • click Append new rule to add a rule at the bottom of the list of rules.
  4. In the Conditions and Actions sections, complete the fields as required.

    Note

    For more details on Actions and Conditions, refer to the Reference Guide .

  5. If necessary, click Add condition to add another condition.
  6. If necessary, click Add to add another action.
  7. Click Save.

    Note

    The new rule is added to the Ruleset and saved, but the modified configuration is not yet applied to the system.

  8. Go to SBC > Configuration.
  9. Click Apply.

    Note

    The modified configuration is now applied to the system.

Result

The rule will be executed the next time the Ruleset is used.

4.5 Changing the Name and Description of a Ruleset

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets.

Steps

  1. Go to SBC > Rulesets.
  2. In the Rulesets page, click located on the row of the Ruleset you wish to modify.
  3. In the Ruleset Edit page, click Change Name /description located next to the name of the Ruleset.
  4. In the Ruleset Change Name/Description page, modify the fields as required.
  5. Click Save.

    Note

    The new name is saved but the modified configuration is not yet applied to the system.

  6. Go to SBC > Configuration.
  7. Click Apply.

    Note

    The modified configuration is now applied to the system.

Result

If you change de name of the Ruleset, you will need to re-associate the Ruleset to the Call Agent it is associated with otherwise, the configuration will be considered invalid.

4.6 Deleting a Ruleset

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets.

Steps

  1. Go to SBC > Rulesets.
  2. In the Rulesets page, click next to the Ruleset you wish to delete.
  3. Click OK.
  4. Go to SBC > Configuration.
  5. Click Apply.

    Note

    The modified configuration is now applied to the system.

Result

The Ruleset will no longer be available in the Rulesets page to be associated with a Ruleset. If the Ruleset was associated with a Call Agent, it will need to be removed manually from the list of Rulesets associated with the Call Agent otherwise, the configuration will be considered invalid.

4.7 Changing the Execution Priority Level of a Call Agent Ruleset

Steps

  1. Go to SBC > Configuration.
  2. In the Call Agent Configuration table, click next to the Call Agent for which you wish to modify the Ruleset priority level.
  3. Use the arrows of the Call Agent Rulesets table to move a Ruleset up or down.
  4. Click Save.
  5. Click Apply to apply the modified configuration to the system.

Result

Inbound rules of the Ruleset will be executed in ascending Ruleset priority order but Outbound rules will be executed in descending Ruleset priority order.

4.8 Changing the Execution Priority Level of a Routing Ruleset

Steps

  1. Go to SBC > Configuration.
  2. Use the arrows of the Routing Rulesets table to move a Ruleset up or down.
  3. Click Save.

    Note

    The changes will be applied to the configuration, but the modified configuration is not yet applied to the system.

  4. Click Apply to apply the modified configuration to the system.

Result

Inbound rules of the Ruleset will be executed in ascending Ruleset priority order but Outbound rules will be executed in descending Ruleset priority order.

4.9 Changing the Execution Priority Level of a Ruleset Rule

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets.

Steps

  1. Go to SBC > Rulesets.
  2. Click next to the Ruleset for which you wish to change the priority level of rules.
  3. Use the Up and Down buttons to move the rules.
  4. Go to SBC > Configuration.
  5. Click Apply.

    Note

    The changes are saved to the configuration and the modified configuration is now applied to the system.

Result

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

4.10 Changing the Execution Priority Level of a Rule Action

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets

Steps

  1. Go to SBC > Rulesets.
  2. Click next to the Ruleset for which you wish to change the priority level of rule actions.
  3. Click Edit next to the rule for which you wish to change the actions order.
  4. Click or to move actions.
  5. Click Save.

    Note

    The new priority level is saved but the modified configuration is not yet applied to the system.

  6. Go to SBC > Configuration.
  7. Click Apply.

    Note

    The modified configuration is now applied to the system.

Result

When the Ruleset is used, the actions of a rule are always executed in the ascending priority order.

4.11 Changing the Execution Priority Level of a Rule Condition

Before You Start

This feature is not available on Mediatrix 3000 units.

Context

This procedure applies to Call Agent and Routing Rulesets

Steps

  1. Go to SBC > Rulesets.
  2. Click next to the Ruleset for which you wish to change the priority level of rule conditions.
  3. Click Edit next to the rule for which you wish to change the conditions order.
  4. Click or to move conditions.
  5. Click Save.

    Note

    The new priority level is saved but the modified configuration is not yet applied to the system.

  6. Go to SBC > Configuration.
  7. Click Apply.

    Note

    The modified configuration is now applied to the system.

Result

When the Ruleset is used, the conditions of the rule are always executed in the ascending priority order.

4.12 Importing Rulesets

Before You Start

Rulesets must be imported. The latest Ruleset package can be found on the Media5 Support Portal (you will be required to supply a user name and password).

Context

This procedure is valid for Call Agent and Routing Rulesets.

Steps

  1. Go to Management/File.

    Note

    Required Rulesets depend on the scenario being configured. Refer to the Call Agent and Routing Ruleset sections of the configuration notes for details on Rulesets needed to complete the configuration.

    Note

    Step 2 is only required when importing the first Ruleset and if you are not using a secure connexion to access the Management Interface (http://).

  2. Click Activate unsecure file transfer through web browser.
  3. From the Path field, select sbc/rulesets/.
  4. Click Browse, and navigate to the Ruleset you wish to import.

    Note

    Ruleset file extension must be *.crs for Call Agent Rulesets or *.rrs for Routing Rulesets.

  5. Click Import.

Result

The imported Ruleset will appear in the Internal files table, with the selected path in front of the name. The Ruleset will be available in the tables of the SBC/Rulesets page.

4.13 Call Agent Rulesets

Name Description
automatic_media_relay Media goes through the SBC except for users in the same network.
drop_common_scanners_in Drop requests from known SIP scanners.
drop_register_in Drop all inbound registration requests.
drop_unregistered_users_in Drop inbound requests from unregistered users.
media_relay Force Media to go through the SBC.
rate_limit_invite_per_source_in Limit call attempts per second per source IP address.
rate_limit_register_per_source_in Limit registration attempts per minute per source IP address.
register_cache_out Create alias in cache for outbound registrations and restore the contact from the cache for inbound requests.
registrar_in Store contact locally and reply to inbound registration requests.
registration_throttling_in Use different expiration for UA and registrar.
reject_unregistered_users_in Reject inbound requests from unregistered users.
remote_users_behind_nat Handle Far-End NAT for registrations and calls.
topology_hiding_out Remove user-agent or server header on outbound requests.
uac_authentication_out Provide authentication credentials for outbound requests.

4.13.1 Associating Call Agent Rulesets to a Call Agent

Before You Start

Steps

  1. Go to SBC/Configuration.

    Note

    Refer to the Call Agents section to identify which Rulesets are associated with the Call Agents used in this Use Case.

  2. From the Call Agent Configuration table, click located on the same row as the Call Agent to which you wish to associate a Ruleset.
  3. In the Call Agent Rulesets table, click .
  4. From the Name selection list, select a Ruleset.
  5. To add other Rulesets, click .
  6. Click Save.
  7. In the Configure Call Agent page, click Save.
  8. Click Apply to apply all changes to the configuration.

Result


4.14 Routing Rulesets

Name Description
lan_pbx_to_remote_users Route from lan_ip_pbx_ca to remote_users_ca
lan_pbx_to_wan_ip_trunk_failover_to_second Route from lan_ip_pbx_ca to wan_ip_trunk_ca with failover to secondary_ip_trunk_ca
lan_pbx_to_wan_ip_trunk_failover_to_second_dm Route from lan_ip_pbx_cato wan_ip_trunk_ca with failover to secondary_ip_trunk_ca in demarcation setup.
lan_pbx_to_wan_ip_trunk_failover_to_trunk_dm Route from lan_ip_pbx_ca to wan_ip_trunk_ca with failover to trunk_lines_ca in demarcation setup
local_users_to_wan_ip_trunk_failover_to_second Route from local_users_ca to wan_ip_trunk_ca with failover to secondary_ip_trunk_ca.
registration_to_wan_ip_trunk_failover_to_second Route from registration_ca to wan_ip_trunk_ca with failover to secondary_ip_trunk_ca
registration_to_wan_ip_trunk Route from registration_ca to wan_ip_trunk_ca
remote_users_to_lan_pbx Route from remote_users_ca to lan_ip_pbx_ca
secondary_ip_trunk_to_lan_pbx Route from secondary_ip_trunk_ca to lan_ip_pbx_ca
trunk_lines_to_local_pbx_dm Route from trunk_lines_ca to lan_ip_pbx_ca in demarcation setup
wan_ip_trunk_to_lan_pbx Route from wan_ip_trunk_ca to lan_ip_pbx_ca

4.14.1 Associating Routing Rulesets to Your Configuration

Before You Start

Importing Rulesets must be completed for Routing Rulesets to be available.

Steps

  1. Go to SBC/Configuration
  2. In the Routing Rulesets table, from the Name selection list, select the Routing Ruleset you wish to apply to the configuration.

    Note

    Refer to the Routing Rulesets section to identify the Rulesets that apply to this Use Case.

  3. If necessary, in the Parameters field enter the required parameters.
  4. Click .
  5. Repeat steps 2 and 3 for each Routing Ruleset you wish to associate to your configuration.
  6. Click Save.
  7. Click Apply to apply all changes to the configuration.

Result


5 Monitoring


5.1 Penalty Box

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.

There are typically three situations that will cause a peer host to be put in the penalty box:

  • If the transaction timer of a communication is expired, the peer host will be considered Down and will be put in the penalty box.
  • If the transaction timer of a keep-alive communication is expired, the peer host will be considered Down and will be put in the penalty box.
  • If after sending a keep-alive request or any other message to a peer host, the Call Agent receives one of the selected error codes, the peer host will be put in the penalty box. It is the error code that will indicate that the peer host cannot be used.

    Note

    When configuring the Call Agent it is possible to indicate the error codes that will trigger the peer host to be sent to the penalty box.( SBC/Configuration/Blacklisting Error Codes)

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.


5.1.1 Configuring the Call Agent Penalty Box

Context

If you are not familiar with the meaning of the fields and buttons, click Show Help, located at the upper right corner of the Web page. When activated, the fields and buttons that offer online help will change to green and if you hover over them, the description will be displayed.

Steps

  1. Go to SBC/Configuration.
  2. Click next to the Call Agent you wish to configure.
  3. In the Configure Call Agent table, set the Keep-Alive field to 30.
  4. Set the Blacklisting Duration to 60.
  5. Click Save.

Result


5.2 Keep-Alive

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.


5.2.1 Setting the Keep-Alive Interval

This is an example on how to configure the Keep-Alive Interval.

Context

If you are not familiar with the meaning of the fields and buttons, click Show Help, located at the upper right corner of the Web page. When activated, the fields and buttons that offer online help will change to green and if you hover over them, the description will be displayed.

Steps

  1. Go to SBC/Configuration.
  2. From the Call Agent Configuration table, click next to the Call Agent you wish to configure.
  3. In the Keep-Alive Interval, indicate the interval in seconds for sending SIP options to the Call Agent Peer host.

    Note

    30 seconds is a good compromise between the speed at which errors are detected versus the resources used by the keep-alive signals.

    Note

    0 indicates that the keep-alive feature is disabled.

  4. Click Save.

5.3 Registration Agent

The Registration Agent is a module that performs REGISTERs on behalf of other users.

In some use cases, using the Registration Agent may be necessary to have a module perform the REGISTERs on behalf of users. For example:

  • To register a SIP PBX to a SIP Service Provider using « SipConnect » registrations when the PBX does not support this kind of registration.
  • When users cannot register themselves.
  • To separate internal and external networks in Demarcation Point scenarios
The Registration Agent is only involved with the registrations it initiates. If the Registration Agent is used, its REGISTERs are routed to the Mediatrix unit via the registration_ca Call Agent.


5.3.1 Configuring a Registration Agent

Context

Note

This procedure is only necessary if your Mediatrix unit registers to the service provider.

Steps

  1. Go to SBC/Registration.
  2. In the Registration Agent Configuration table, click .

    Note

    A new line of fields is added.

  3. Complete the User Name, Friendly Name, and Domain parameters fields according to the service provider's requirements.
  4. In the Contact field, enter credentials to register against the service provider. Format must be sip:user@public_IP Address or sip:public_IP Address or sips:user@public_IP_Address:sip listening port;uri-parameters of the unit.
  5. If necessary, repeat step 2 to step 4 if you are using more than one service provider.
  6. Click Apply.

Result


6 Registration


6.1 Registration Caching

Registration processing allows maintaining an endpoint reachable even from behind NATs.

When a call is routed by a Ruleset that includes the REGISTER throttling and Enable REGISTER caching actions, the SBC replaces the information of the Contact header with its own IP address before forwarding the call to an endpoint. Because a private IP address is used as the contact address in the Contact header field of the REGISTER messages, it becomes impossible to reach the user from the public Internet without going through the SBC since the contact's address is private.

The manipulated registration information is then registered in the registrar. When a Call is destined to the user, the call will be directed to the SBC. In order for the SBC to know which user is actually being contacted, the SBC keeps a local copy of the user's registration. The local copy includes the private IP address and the user’s SIP URI as well as the public IP address included in the IP header that was assigned to the SIP message by the NAT.

If periodic request-response traffic does not cross the NAT behind which the user is located, the NAT address binding expires and the user becomes unreachable. Therefore, the SBC forces re-registration to keep NAT bindings alive.


6.1.1 Finding a Specific AoR in the Registration Cache

Steps

  1. Go to SBC/Registration
  2. In the Filter table, enter the AoR.
  3. Click Search.

Result

The Registration Cache table only displays the registration(s) related to the selected AoR.

6.2 Registration Throttling

Registration throttling protects SIP infrastructures against registration overloads.

Although registration overloads are often self-inflicted by the keep-alive functionality, it may also be caused by a router outage, broken client or Denial of Service attack. The SBC fends off such overloads by using high-performance in-memory registration cache that serves upstream registrations at high-rate, handles them locally, and propagates them down-stream at substantially reduced rate. That’s the case if the registrations were to create new bindings, deleting existing ones or if they were to expire downstream. The propagated registration changes become effective on the SBC only if confirmed by the downstream server. If a registration expires without being refreshed the SBC issues a warning event.


6.3 Registration Cache Clearing

Clearing the registration cache will remove all inaccurate information that could remain if an equipment connecting to the SBC is restarted with new information such as a new IP address.

When the registration cache is cleared, all equipments connecting to the SBC need to re-register themselves before being able to receive SIP requests because without re-registration the SBC will not have the private contact address to know where to route the SIP.


6.3.1 Clearing the Registration Cache

Steps

  1. Go to SBC/ Registration.
  2. Click Clear Registration Cache located under the Registration Cache table.

Result

All entries of the Registration Cache table will be erased and Registration Throttling will restart from scratch. The next REGISTERs will be immediately relayed to their destinations on their first occurrence.

7 Parameters


7.1 SBC-Configuration Parameters

Although the services can be configured in great part in the web browser, some aspects of the configuration can only be completed with the MIB parameters by :

  • using a MIB browser
  • using the CLI
  • creating a configuration script containing the configuration parameters

Tcp Connect Timeout

Refer to Sbc.SignalingInterface.TcpConnectTimeout in the Reference Guide .

Tcp Idle Timeout

Refer to Sbc.SignalingInterface.TcpIdleTimeout in the Reference Guide .

Registration Expiration

Refer to Sbc.RegistrationAgent.ExpireValue in the Reference Guide .

Registration Expiration

Refer to Sbc.RegistrationAgent.RetryInterval in the Reference Guide .

Min Severity

Refer to Sbc.MinSeverity in the Reference Guide .

7.2 SBC > Status Parameters

Although the services can be configured in great part in the web browser, some aspects of the configuration can only be completed with the MIB parameters by :

  • using a MIB browser
  • using the CLI
  • creating a configuration script containing the configuration variables

Tcp Connect Timeout

Refer to Sbc.SignalingInterfaceStatus.TcpConnectTimeout in the Reference Guide .

Tcp Idle Timeout

Refer to Sbc.SignalingInterfaceStatus.TcpIdleTimeout in the Reference Guide .

Need Restart Info

Refer to Sbc.NeedRestartInfo in the Reference Guide .

8 Copyright Notice

Copyright © 2018 Media5 Corporation.

This document contains information that is proprietary to Media5 Corporation.

Media5 Corporation reserves all rights to this document as well as to the Intellectual Property of the document and the technology and know-how that it includes and represents.

This publication cannot be reproduced, neither in whole nor in part, in any form whatsoever, without written prior approval by Media5 Corporation.

Media5 Corporation reserves the right to revise this publication and make changes at any time and without the obligation to notify any person and/or entity of such revisions and/or changes.