Top

Basic Configuration Concepts

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

Call Agent Name SIP or Endpoint Peer
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.

Top

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.



Top

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.



Top

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.



Top

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.



Top

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



Top

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



Top

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



Top

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.



Top

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.

Top

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.

Top

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.

Top

Basic Ruleset Concepts

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 DGW Configuration Guide - Reference Guide document published on the Media5 Documentation Portal.

Refer to the DGE Configuration Guide - Ruleset Replacement Expressions also published on the Media5 documentation portal.
IMPORTANT: Although it is possible to configure existing ruleset parameters via the CLI, it is not possible to create or edit a ruleset from the CLI: it must be either imported or directly created or edited in the DGW Web interface.
Top

Ruleset Replacement Expressions

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.

For example,
  • $aU uses the User part of the P-Asserted-Identity header
  • $th uses the Host part of the To header
  • sip:$aU@$th, used as the parameter of the Set R-URI action, uses the P-Asserted-Identity and To headers of the incoming request and puts them into the Request URI of the outgoing request.
Note: Special characters should be backslash-escaped, for example, as follows: \ → \\ or $ → \$
Note: It is important to know that if a mediation action (Section SIP Mediation) changes the content of a SIP message, the replacement expression will refer to the value after modification. E.g., if you apply the rule action “SetFrom(sip:new@from.com)”, $fu will return new@from.com!
Top

Ruleset Replacement Expression Exhaustive List

Macro Replacements Description
$r Request-URI (R-URI). The expression refers to current Request-URI which may be changed during the course of request processing
$r. Complete R-URI header
$ru user@host[:port] part of R-URI
$rU User part of the R-URI
$rd R-URI domain (host:port)
$rh Host part of the R-URI
$rp Port number of the R-URI
$rP R-URI Parameters
$f From header
$f. Complete From header field
$fu user@host[:port] part of the From URI
$fU User part of the From URI
$fd From URI domain (host:port)
$fh Host part of the From URI
$fp Port number of the From URI
$fn Display name of the From header field
$fP Parameters of the From header field. Does not include the parameters of the URI.
$ft The tag of the From header field
$fH The name of the From header field, exactly as it is stated in the SIP request.
$t To header
$t. Complete To header
$tu user@host[:port] part of the To URI
$tU User part of the To URI
$td To URI domain (host:port)
$th Host part of the To URI
$tp Port number of the To URI
$tn Display name of the To header field
$tP Parameters of the To header field. Does not include the parameters of the URI.
$tt The tag of the To header
$tH The name of the To header, exactly as it is stated in the SIP request.
$a P-Asserted-Identity (PAI)
$a. Complete PAI header.
$au user@host[:port] part of the PAI URI
$aU User part of the PAI URI
$ad PAI URI Domain (host:port).
$ah Host part of the PAI URI
$ap Port number of the PAI URI
$aP Parameters of the PAI header field. Does not include the parameters of the URI.
$at The tag of the PAI
$aH The name of the PAI header field, exactly as it is stated in the SIP request.
$p P-Preferred-Identity (PPI)
$p. Complete PPI header field.
$pu user@host[:port] part of the PPI URI.
$pU User part of the PPI URI.
$pd PPI URI Domain (host:port).
$ph Host part of the PPI URI.
$pp Port number of the PPI URI.
$pP Parameters of the PPI header field. Does not include the parameters of the URI.
$pt The tag of the PPI header field.
$pH The name of the PPI header, exactly as it is stated in the SIP request.
$c Call-ID
$ci Call-ID of the SIP request
$s Source party
$si Source IP address of the inbound SIP request
$sp Source port number of the inbound SIP request
$d Expected destination party
$di Destination IP address of the outbound SIP request. This replacement expression is only available in outbound rules.
$dp Destination port number of the outbound SIP request. This replacement expression is only available in outbound rules.
$R Interface of the inbound SIP request
$Ri IP address of the Signaling Interface on which the inbound SIP request was received
$Rp Port number of the Signaling Interface on which the inbound SIP request was received
$Rf ID of the Signaling Interface on which the inbound SIP request was received
$Rn Name of the Signaling Interface on which the inbound SIP request was received
$RI The configured address of the SignalingInterface.PublicIpAddr parameter on which the inbound SIP request was received
$H Arbitrary Headers.

The replacement expressions in this group mention the name of an arbitrary header between parentheses. The core headers (From, To, Call-ID, Via, Route, Record-Route, Contact) cannot be replaced.

Example: $H(Server) will be replaced by the value of the Server header field.
$H(headername) Value of the 'headername' header
$HU(headername) User part of the URI in the 'headername' header.
$Hd(headername) URI Domain (host:port) of the 'headername' header.
$Hu(headername) user@host[:port] part of the URI in the 'headername' header.
$Hh(headername) Host part of the URI in the 'headername' header.
$Hp(headername) Port number of the URI in the 'headername' header.
$Hn(headername) Display name of the 'headername' header.
$HP(headername) Parameters of the 'headername' header field. Does not include the parameters of the URI.
$HH(headername) Header headername (as URI) headers
$m Request method
$m The method of the request.
$V Call parameter
$V(gui.varname) Value of the 'varname' call parameter.
$B Cnum and Rnum
$B(cnum.rnum) Value of the regular expression backreference.
  • Rnum is the index of the rule condition containing the regular expression, starting at 1.
  • Cnum is the index of the subexpression within the regular expression, starting at 1.
$U Register cache
$Ua Originating AoR from the registration cache. This replacement expression can only be used after the execution of a‘Restore contact from registrar’ or a ‘Retarget R-URI from cache’ action.
$UA Originating alias from the registration cache. This replacement expression can only be used after the execution of a ‘Restore contact from registrar’ or a ‘Retarget R-URI from cache’ action.
$_ Operations on Values
$_u(value) Changes the value to uppercase.
$_l(value) Changes the value to lowercase.
$_s(value) Size of the value.
$_5(value) MD5 sum of the value.
$_r(value) Random number from 0 to 'value' - 1. Example: $_r(5) gives 0, 1, 2, 3 or 4.
$# URL-encoded
$#(value) Encodes the value into a URL format with appropriate escaping for characters outside the ASCII character set.
$attr Global Attributes
$attr(version) Version number of the DGW firmware. The returned value matches with the %version% macro in DGW firmware.
$attr(profile) Profile identification of the DGW firmware. The returned value matches with the %profile% macro in DGW firmware.
$attr(serial) Serial number of the Mediatrix unit. The returned value matches with the %serial% macro in DGW firmware.
$attr(mac) MAC address of the Mediatrix unit. The returned value matches with the %mac% macro in DGW firmware.
$attr(product) Product name of the Mediatrix unit. The returned value matches with the %product% macro in DGW firmware.
$attr(productseries) Product series name of the Mediatrix unit. The returned value matches with the %productseries% macro in DGW firmware.
Top

Basic Registration Concepts

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.

Top

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.

Top

Registration Agent

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

In some use cases, using the Registration Agent may be necessary to have a separate entity perform the REGISTERs on behalf of users. For example:
  • 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.
Top

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.

Top

Basic Configuration Tasks

Configuring a Call Agent

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

Creating a Media Interface

Before you begin
A Network Interface must be configured.
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.
Top

Creating a Signaling Interface

Before you begin
A Network Interface must be configured. IPv6 is not supported, therefore Ipv6 configured Network interfaces cannot be used.
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.
Top

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.
    The changes will be applied to the configuration, but the modified configuration is not yet applied to the system.
  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.
Top

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

Associating Call Agent Rulesets to a Call Agent

Before you begin
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


Top

Associating Routing Rulesets to Your Configuration

Before you begin
Importing Rulesets must be completed for Routing Rulesets to be available.
Steps
  1. Go to SBC/Configuration
  2. In the Routing Rulesets table click to add the first route.
  3. 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.
  4. Repeat steps 2 and 3 for each Routing Ruleset you wish to associate to your configuration.
  5. If necessary, in the Parameters field enter the required parameters for each route.
  6. Click Save.
  7. Click Apply to apply all changes to the configuration.
Result


Top

Configuring the Call Agent Penalty Box

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


Top

Setting the Keep-Alive Interval

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

Basic Ruleset Tasks

Importing Rulesets

Before you begin
Rulesets must be imported. The latest Ruleset package can be found on the https://media5.secure.force.com/supportportal (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 importation from the 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.

Top

Modifying a Ruleset

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 DGW Configuration Guide - Reference Guide published on the Media5 Documentation Portal.
  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.
Top

Adding Rules to a Ruleset

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 DGW Configuration Guide - Reference Guide document published on the Media5 Documentation Portal.
  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.
Top

Changing the Name and Description of a Ruleset

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

Deleting a Ruleset

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 SBCConfiguration.
  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.
Top

Cloning a Ruleset

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 published on the Media5 documentation portal.
  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.
Top

Creating a New Ruleset

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 DGW Configuration Guide - Reference Guide document published on the Media5 Documentation Portal.
  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.
Top

Changing the Execution Priority Level of a Ruleset Rule

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 SBCConfiguration.
  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.
Top

Changing the Execution Priority Level of a Rule Action

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

Changing the Execution Priority Level of a Rule Condition

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

Basic Registration Tasks

Configuring a Registration Agent

Configure the registration agent used to issue the registrations.

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.
    Note: 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
Top

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

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

Parameters

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
For more details on the following parameters ,refer to the DGW Configuration Guide - Reference Guide published on the Media5 Documentation Portal.

Tcp Connect Timeout

Refer to Sbc.SignalingInterface.TcpConnectTimeout .

Tcp Idle Timeout

Refer to Sbc.SignalingInterface.TcpIdleTimeout.

Registration Expiration

Refer to Sbc.RegistrationAgent.ExpireValue.

Registration Expiration

Refer to Sbc.RegistrationAgent.RetryInterval.

Min Severity

Refer to Sbc.MinSeverity.
Top

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
For more details on the following parameters, refer to the DGW Configuration Guide - Reference Guide document published on the Media5 Documentation Portal.

Tcp Connect Timeout

Refer to Sbc.SignalingInterfaceStatus.TcpConnectTimeout.

Tcp Idle Timeout

Refer to Sbc.SignalingInterfaceStatus.TcpIdleTimeout

Need Restart Info

Refer to Sbc.NeedRestartInfo.
Top

Online Help

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

Top

DGW Documentation

Mediatrix devices are supplied with an exhaustive set of documentation.

Mediatrix user documentation is available on the Media5 Documentation Portal.

Several types of documents were created to clearly present the information you are looking for. Our documentation includes:
  • Release notes: Generated at each GA release, this document includes the known and solved issues of the software. It also outlines the changes and the new features the release includes.
  • 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.
  • Technical bulletins: These documents are created to facilitate the configuration of a specific technical action, such as performing a firmware upgrade.
  • Hardware installation guide: They provide the detailed procedure on how to safely and adequately install the unit. It provides information on card installation, cable connections, and how to access for the first time the Management interface.
  • User guide: The user guide explains how to customise to your needs the configuration of the unit. Although this document is task oriented, it provides conceptual information to help the user understand the purpose and impact of each task. The User Guide will provide information such as where and how TR-069 can be configured in the Management Interface, how to set firewalls, or how to use the CLI to configure parameters that are not available in the Management Interface.
  • Reference guide: This exhaustive document has been created for advanced users. It includes a description of all the parameters used by all the services of the Mediatrix units. You will find, for example, scripts to configure a specific parameter, notification messages sent by a service, or an action description used to create Rulesets. This document includes reference information such as a dictionary, and it does not include any step-by-step procedures.
Top

Copyright Notice

Copyright © 2023 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.