SIP to SS7 Configuration Guide

Perform the First Boot/Initial Setup

Power Connection

Sangoma NSG comes with three types of power supplies

• AC PSU

  • AC Single PSU                                  (Default)

  • AC Dual-Redundant PSU

• DC PSU

  • DC Dual-Redundant PSU

PSU Connection

• Standard 110V or 220V, 50-60Hz connection.

• Optional Dual-Redundant AC 110V or 220V, 50-60Hz connection.

• Optional Dual-Redundant DC -48V

DC PSU Connection

Connecting cables to a power supply depends on the remote power source.

The PSU has voltage reverse protection.

If the red and black wires are connected the wrong way, the system will not power up. But there will be no damage to the PSU or the system.

Establishing Initial WebGUI Connection

NSG factory settings are not very useful, as the Primary Ethernet port:eth0 is set to a static IP address. Proceed to connect to the NSG Appliance via Laptop’s web browser.

• Connect the Primary Signaling Port: eth0 to a LAN Switch

• Connect Laptop to LAN Switch

• Configure Laptop to IP address: 192.168.168.1/24

• Using Laptop web browser go to URL: http://192.168.168.2:81

• Login via

  • Username: root, Password: sangoma
    
    
    

    Open

    

    
     

    Open

    

Change Password

After successful Login, please proceed to change the default password. Sangoma NSG appliance comes with default password.

For security reasons please change the password.

• Select Password page from side/top System menu

• Enter your new password

• Press update to save

Console SSH Configuration

By default NSG systems come with SSH enabled. To configure ssh service

• Select Services from side/top System Menu

• Enable or disable Secure Shell service
  
  
  

  
  
  

NSG License

Each NSG appliance comes with pre-installed license.

In case of upgrades, of expansions please contact Sangoma Sales.

 To update NSG license

• Select License from side/top Configuration Menu

•  NSG License from Sangoma Support

• Upload the License into the NSG Gateway via the Upload Button The License page offers the detailed license overview.
  
  
  

Network Configuration

Network configuration section only applies to Physical Network Interfaces: eth0 and eth1. It does not apply to VLAN IP and route configuration.

Network Setup

•  Physical network interfaces: eth0, eth1 are configured in the section

Configuration-> Settings-> IP Settings.

This section can only be used to modify/configure IP, Host, DNS information for Physical Network interfaces eth0 and eth1.

Default Route/Gateway 

To configure a system default route through the IP Settings section, the appropriate interface role type to use is “External”. The External interfaces get associated to the default system route.

CAUTION:

• There can only be ONE External network interface.

• There can only be ONE system default route.

Static Routes

Static routes that apply to physical network interfaces eth0, eth1 should be configured in

Configuration-> Network -> IP Route section.

CAUTION:

• Do not try to configure VLAN routes in this section. .

• route configuration files are only meant to be used for eth0,eth1 interfaces.

Media Ethernet Interface: Transcoding

• NSG comes with optional, media/codec transcoding hardware. The media transcoding hardware network interface is: eth2. The media transcoding network interface comes preconfigured with a 10.x.x.x ip address.

Configuration of the eth2 device should be performed in Configuration->Settings->Media.

CAUTION:

One should take this into account when assigning IP addresses to eth0,eth1 or VLAN interfaces. Confirm that ip address range set does not conflict with eth2 media transcoding network interface.

VLAN Config IP & Routes

• VLAN’s can be configured in section Configuration-> VLAN

• VLAN can be configured on top of eth0 and eth1 network interface only.

• All VLAN related configuration such as IP address, VLAN ID and VLAN routes must be configured in VLAN configuration section only.

CAUTION:

• Do not use Static IP Route section to create a VLAN routes.

• Static IP Route section is only for physical interfaces eth0 and eth1.

VLAN Default Route

• If a system default route needs to be configured via VLAN interface.

• Configure the system default route in Configuration->  VLAN section.

• Refer to the VLAN section below.

CAUTION:

• Make sure that all physical network interfaces in IP Settings section are configured for role “LAN”. No physical network interface eth0, eth1 should be configured for role “External”.  This would result in multiple system default routes.

Physical Network Interface Configuration

 By default the NSG appliance pre-configured with 192.168.168.2/24 address on Primary Port (eth0). The IP address can be changed based as follows

• Select IP Settings from side/top Configuration menu

• Specify Firewall Mode and Hostname

• Select Edit under eth0 and eth1 device and configure

NOTE

• eth2 device is a Sangoma Transcoding device and should be modified.

• eth2 device is configured in Configuration -> Media section of the GUI will configure this device

Appliance Network Interfaces

• eth0

  • Primary Signaling Port

  • By default provisioned as static 192.168.168.2

  • By default allows access to ssh and management http

• eth1

  • Secondary Signaling or Management Port

  • By default provisioned as static no IP address

  • By default allows access to ssh and management http

• eth2

  • Sangoma transcoding DSP board

  • Provisioned using Media page.  Do not modify in this section.

Selecting Default Route

NSG appliance should have a single default route. The default route is used to access Internet.

To configure a default route on eth0

• Set the eth0 interface mode to External.

• Refer to section below.

Network Section

Interface Section

Network Role

When configuring a network interface, the first thing you need to consider is the network role in IP Settings. Will this network card be used to connect to the Internet, for a local network, for a network with just server systems? The following network roles in IP Settings are supported in NSG and are described in further detail in the next sections:

• External - network interface with direct or indirect access to the Internet

• LAN - local area network

• Hot LAN - local area network for untrusted systems

• DMZ - de-militarized zone for a public network
   

Types

Ethernet Options

Setting custom Ethernet options such as disabling auto negotiation is done as part of the IP Settings.

• Select IP Settings from side/top Configuration Menu

Specify Options field in order to add special configuration to this interface.

Virtual IP’s

NSG supports virtual IPs. To add a virtual IP address, click on the link to configure a virtual IP address and add specify the IP Address and Netmask. You will also need to create advanced firewall rules if the virtual IP is on the Internet

IP Troubleshooting

In most installs, the network cards and IP settings will work straight out of the box. However, getting the network up the first time can be an exercise in frustration in some circumstances. Issues include; 

• Network card compatibility

• Invalid networks settings (username, password, default gateway)

Cable/DSL modems that cache network card hardware information

Static Routes

In some cases a static route must be defined for a specific network interface: eth0 or eth1. The static route support is done via File Editor 

• Select IP Route from side/top Configuration Menu

• Add a custom route command

Save and Apply

The IP Route section only allows route add command syntax

Routing Table Status

• Select VLAN Status from side/top Overview Menu

• Second table shows full system routing table.
  
  
  

VLAN

Virtual local area network, virtual LAN or VLAN is a concept of partitioning a physical network, so that distinct broadcast domains are created. NSG mark’s packets through tagging, so that a single interconnect (trunk) may be used to transport data for various VLANs.

 A VLAN has the same attributes as a physical local area network (LAN), but it allows for end stations to be grouped together more easily even if not on the same network switch. VLAN membership can be configured through software instead of physically relocating devices or connections. Most enterprise-level networks today use the concept of virtual LANs(VLAN). Without VLANs, a switch considers all interfaces on the switch to be in the same broadcast domain

VLAN Configuration

Currently NSG only supports VLAN configuration via GUI

• Select VLAN from side/top Configuration Menu

• Copy in the VLAN configuration script below into the file editor

• Save

  • On save the VLAN configuration will be applied

  • Proceed to VLAN Status confirm VLAN configuration
    
    

Example of sample script that could be copied into the VLAN config startup script:

In the example above, a single VLAN was created

• on top of the Primary Signaling Ethernet Port:eth0 with

• VLAN ID=5 and

• IP =192.168.1.100/24.

VLAN Routes

An optional route can be created to point to a gateway within a VLAN network 

Additional VLAN

If more VLAN’s are needed, proceed to repeat the above steps for all VLANs.

When Save button is pressed

• The VLAN configuration will be applied

• The script above will be executed line by line.

• Status window will pop up with VLAN config status. If one of the lines fails, the pop up will report it.

• Proceed to Overview -> VLAN status below to confirm VLAN and Route configuration

VLAN Status

• Select VLAN Status from side/top Overview Menu

• This page shows

  • All configured VLANs

  • System Routing table

  • Individual VLAN configuration

  • Individual VLAN IP information
    
    

Date & Time Service Config

The Date/Time configuration tool allows you to:

• Select your time zone

• Synchronize your clock with network time servers

• Enable/disable a local time server for your network

 Note that you need to configure your IP address and default route in order to be able to use a default time server that is located on the internet.

To configure

• Select Date from side/top System menu

• Refer below to all available options

Initial Gateway Configuration

NSG by default contains following VoIP/TDM Sections

• Global Gateway Config

  • Configured in Global gateway section.

  • Used to configure SIP, RTP, RADIUS options.

• SIP/RTP

  • Configured in Global Gateway section

  • SIP profile is always started

• MG

  • Configured in MG gateway section

  • MG Termination ID’s are mapped to TDM channels in TDM gateway section.

  • For full MG configuration one must configure MG and TDM sections.

• SS7

  • Configured in TDM gateway section

  • ISUP Termination

  • M2UA Signaling Gateway

• Media/Transcoding

  • Configured in Media gateway section

  • Enable and select hw codec support

  • Note: HW transcoding is an optional feature.

• Dialplan

  • Used for SIP to TDM

  • Note: Dialplan is not used in MG/Megaco/H.248 mode.

• Apply

  • All configuration files are saved to disk at this step.

  • Above configuration sections only save information in local database.

  • NSG Gateway can be started in Control Panel after this step

  • TDM Status can be used to monitor Gateway Status.

Global Gateway Configuration

• Select Global from side/top Configuration Menu

• Change a SIP global variable and Click on Save (Disk Icon)

• Proceed to Control Panel and Restart the VoIP Gateway.

SS7 ISUP Configuration

SS7 is a signaling protocol, it is used to carry call control information such as call start, call progress, call hang-up etc. The SS7 call control information is used to control arbitrary number of voice channels that are carried using T1/E1 spans.

In a typical SS7 setup the telco will provide you with SS7 information that will be used to map T1/E1 physical spans and channels into SS7 call control information.

 The NSG TDM SS7 configuration page has been designed as bottom up SS7 configuration approach.

1. Identify T1/E1 spans on your system

2. For each T1/E1 span on your system:

   1. Determine which T1/E1 spans will carry SS7 Link channels

   2. T1/E1 Span can either carry an

      1. SS7 Link in one of its channels or

      2. All T1/E1 channels can be used to carry voice.

   3. Configure T1/E1 physical configuration parameters

   4. Identify if T1/E1 span carries SS7 link or is Voice Only

2. If T1/E1 span has an SS7 link associate with it:

   1. Create a new SS7 Link

   2. Next step is to bind the new SS7 Link to an SS7 Linkset.

   3. If an SS7 Link set does not exist, Create a new SS7 Link Set

   4. Then bind the SS7 Link to an existing or new SS7 Link Set

   5. Next step is to bind the SS7 Linkset into an SS7 Route.

   6. If an SS7 Route does not exist, Create a new SS7 Route

   7. Then bind the SS7 Linkset to an existing or new SS7 Route

   8. Next step is to bind the SS7 Route into an SS7 ISUP Interface

   9. If an SS7 ISUP Interface does not exist, Create a new SS7 ISUP Interface

   10. Then bind the SS7 Route to an existing or new SS7 ISUP Interface

3. The Last step is to assign CIC values to each physical T1/E1 timeslot in the span.

Whether the Span carries only voice or it contains the SS7 Link, each timeslot must be associated with a SS7 CIC value.

This way when an incoming SS7 Call Start message arrives with an arbitrary CIC value. The NSG system can open the appropriate physical voice channel associated with the CIC value.

Once all T1/E1 spans are configured you need to Apply the configuration files.

Note that this step does not start the NSG gateway. It just writes the appropriate configuration files.

Proceed to the Control Panel to start the NSG SS7 to VoIP Gateway.

 TDM SS7 Configuration Page

• Select TDM from side/top Configuration menu

• The TDM section will display all installed TDM Spans/Ports.

The TDM Configuration page will display to the user every T1/E1 card detected by NSG.

Each card is logically separated into ports, which initially displays the firmware version and the Echo Cancellation security chip ID. If the echo cancellation security chip ID is 0, then the card installed does not have echo cancellation. If there is a alert image next to the firmware version, that means the firmware on the system is out of date, and must be updated in order to have the most up to date and efficient firmware running.

Port Identification

• In order to determine which physical T1/E1 port is: Port 1 Card 1

• Select Identify button for Port 1 Card 1

• The LED light will start flashing on a rear RJ45 T1/E1 port: rear panel.

• Look at the rear panel of the appliance and plug in RJ45 cable to the blinking RJ45 T1/E1 port.

• Once the Port 1 Card 1 is identified, the subsequent ports for that board are labeled.

• Or alternatively keep using the Identify feature for each port.

Edit T1/E1 Config

• Once the port has been identified and plugged into the T1/E1 network.

• Select Edit button for Port 1 Card 1 to configure the physical T1/E1 parameters.

• Select the port configuration type: T1 or E1

  • T1: North American Market and Japan

  • E1: Europe and the world

• Fill in Physical Configuration T1 or E1 parameters

  • Fill in the T1/E1 parameters based on the provider provision document.

Standard T1/E1 Parameters

• In case advanced parameters are not necessary proceed

• Apply to Port

  • Applies the configuration for a single T1/E1 port

  • (The one that is currently being edited)

• Apply to all Ports

  • Apply to all T1/E1 ports on a board.

  • Bulk config feature

  • (This feature saves time as T1/E1 ports are usually provisioned the same)

Advanced T1/E1 Parameters

Span Link Type

 When configuring TDM Terminations for SIP to ISUP Media Gateway there are two possibilities

• Voice Mode

  • All TDM channels are used for Voice 64kbs G.711

  • Example: All channels 1-31 on an E1 line are used for voice

  • Link Type = Voice Only 

• Mix Mode

  • Voice 64kbs G.711 channels and SS7 signaling channels.

  • Example: Channel 16 is used for SS7 signaling, 1-15,17-31 are used for voice.

  • Link Type = ISUP Termination

• If configuring for Voice Mode select No Signaling Link

• If configuring for Mixed Mode select ISUP Termination

SS7 Network Overview

Links

physical signaling links between the TX board and the adjacent signaling points. One link configuration must be performed for each physical signaling link. The attributes of a link include the point code of the adjacent signaling point, protocol variant employed on the link (ITU-T or ANSI), point code length, maximum packet length, various timer values, membership in a linkset, and others.

Linksets

are groups of from one to 16 links that directly connect two signaling points. Although a linkset usually contains all parallel signaling links between 2 SPs, it is possible to define parallel link sets. Each signaling link defined is assigned membership in exactly one link set.

Routes

specify the destination signaling points (or sub-networks (clusters) when route masks are employed) that are accessible from the target node. Each route is assigned a direction - up or down. One up route is required for the actual point code assigned to the signaling point being configured and for each point code that is to be emulated. Up routes are used to identify incoming messages that are to be routed up to the applications/user parts. One down route is required for each remote signaling point/network/cluster that is to be accessible from the SP being configured.

MTP2 Link Configuration

 Proceed to configure the SS7 ISUP link that exists on a DS0 timeslot of a T1/E1 port. The information required for the SS7 Link configuration must be provided by the Telco.

Next screen will confirm if the T1/E1 port contains a signaling link.

• Please select YES if the SS7 signaling link exists on current T1/E1 port.

• By selecting NO this T1/E1 port would not contain a signaling link, but the voice channels would still be controlled by the ISUP signaling.  Thus channel mapping would still apply

The following screen will configure the MTP1 and MTP2 protocol configuration of the SS7 Link.

Click on Apply to Port button to proceed to next configuration section

MTP3 Linkset Configuration

A number of links can be grouped into a linkset that connects to an adjacent point. Each signaling link is provided with a unique code called a signaling link code (SLC). Traffic is load-shared across this linkset. The signaling links within a linkset also provide a redundant transport mechanism. Therefore the more links there are to a linkset the higher the transport bandwidth is and the higher the redundancy.

Linkset configuration on NSG GUI is based on Linkset profiles. It is designed so that multiple SS7 signaling links can use the same SS7 Linkset Profile. The term used when attaching links to linksets in NSG is BIND. You have to bind a link to a linkset in order to proceed.

NOTE

• If no Linkset profile exists, user will be directed to the Linkset profile creation page.

If Linkset profile already exists, user will be directed to Link profile list page. Where user will be able create a Linkset profile or edit existing Linkset profile

Click on Create Profile once the configuration is completed.

NOTE

• On very fist Linkset profile, the Link will automatically be BINDED to the Linkset.

MTP3 SS7 Route

Route is a collection of linksets to reach a particular destination. A linkset can belong to more than one route. Service Provider personnel statically maintain signaling endpoint routing tables. The routing table identifies the links, linksets, primary routes, and alternate routes for each DPC. All links in the linkset share the traffic load equally.

 After a successful Linkset configuration, NSG GUI will present a user with Route Configuration screen.

• If no Route profiles exist, user will be presented with Route create page.

• If a Route profile already exists, user will be presented with Route profile list. Where user will be able to either create new Route or edit existing Route profile.

ISUP Interface Configuration

ISUP connects, manages, and disconnects all voice and data calls in the PSTN. ISUP sets up and tears down the circuits used to connect PSTN voice and data subscribers.. ISUP is used in cellular or mobile networks for trunking connections.

 ISUP information is transferred in MTP3 messages similar to the other L4 protocols. The ISUP section covers the following topics:

• ISUP ServicesBasic and Supplementary

• End-to-end SignalingPass-along and SCCP

• Call Setup and Teardown

• ISUP Message Format

• ISUP Call Control Messages

Like the linkset configuration and route configuration profiles, the ISUP Interface configuration is also configured as profiles. It is setup so that 1 SS7 route can be attached to 1 ISUP Interface.

After a successful Route configuration, NSG GUI will present a user with Route Configuration screen.

• If no ISUP profiles exist, user will be presented with ISUP create page.

If an ISUP profile already exists, user will be presented with ISUP profile list. Where user will be able to either create new ISUP Interface Profile 

ISUP CIC Channel Mapping

 The last step of the configuration is to bind the TDM voice channels to ISUP Profile and map ISUP CIC’s to the TDM timeslots.

Media Transcoding Configuration

NSG will enable ALL Media Codec’s by default.  There is no extra configuration needed.

Use this configuration page in case you want to limit which codecs should be enabled, or disable media codec support.

To access NSG Media Transcoding Configuration

• Select Media from side/top Configuration Menu

• Select any or all supported/listed codecs

• Once done press Save

Media Hardware 

Once Codec selection has been made, proceed to Advanced Options section of the Media page.

• Select SCAN

o This step will auto-detect all NSG transcoding resources

• Confirm that GUI detected exact number of transcoding resources as installed.

• User has an option of changing the assigned Local IP address of the Media device.

Applying Configuration

The changes made in the Configuration section of the WebUI are only stored one the scratch disk. User MUST proceed to Apply page in the Management Section to save new configuration.

• Select Apply from side/top Configuration Menu

• Visually confirm the warnings

  • License warning need to be resolved with Sales

• Select Generate Config to apply the configuration to file/disk.

• Generate Config will generate all necessary NSG SS7 VoIP Gateway configuration files needed to successful start the NSG gateway

The generate config option will not be offered in case NSG gateway is started. Confirm that NSG is fully stopped in Control Panel before Applying configuration.

Dialplan

When a call is received in the NetBorder SS7 Gateway, from SIP,H232 or SS7 the dialplan is fetched to retrieve the route information to find the outgoing call location.

To access Dialplan configuration section 

• Select Dialplan from side/top Configuration Menu

• Change a variable and Click on Save (Disk Icon)

• Proceed to Control Panel and Restart the VoIP Gateway.

Dialplan is pre-configured for

• SIP to TDM and TDM to SIP Bridging.

Section "from-sip" routes calls from SIP to PSTN/SS7 Section "from-pstn" routes calls from PSTN/SS7 to SIP.

Note that default dial plans allow for unchallenged SIP INVITEs. Normally this is OK for equipment that is installed in private networks or behind Session Border Controllers. However, should the SS7 Gateway be installed on a public IP address, the dial plan needs to be modified to block these requests to mitigate security risks. Note however that NSG is not a security device, it is a VoIP Gateway. Sangoma recommendeds to use Session Border Controller to secure VoIP Networks.

Dialplan Reload/Apply

Note that Dialplan can be modified in real time without the need to restart the gateway.
 you Save the Dialplan, you will be prompted to Reload the gateway which will apply the changes without any service interrupt. All the currently established calls will not be affected. Only the newly established calls will start using the new dialplan rules.

PSTN to SIP Dialplan

By default NSG is setup to send an call to a SIP IP address. The remote SIP address must be configured in Configuration -> Global section.

Dialplan Syntax

There are several elements used to build an XML dialplan. In general, the dialplan groups logically similar functions and calling activities into a 'context'. Within a context are extensions, each with 'condition' rules and associated 'actions' to perform when the condition rules match.
 following is a sample dialplan to illustrate these concepts. We have left out the XML "wrapper" to help make the basic concepts more clear:

Each rule is processed in order until you reach the action tag which tells NSG what action to perform. You are not limited to only one condition or action tag for a given extension.

In our above example, a call to extension 501 rings the extensions. If the user does not answer, the second action answers the call, and following actions delay for 1000 milliseconds (which is 1 second) and connect the call to the voicemail system

Context

Contexts are a logical grouping of extensions. You may have multiple extensions contained within a single context.The context tag has a required parameter of 'name'. There is one reserved name, any, which matches any context. The name is used by incoming call handlers (like the [Sofia] SIP driver) to select the dialplan that runs when it needs to route a call. There is often more than one context in a dialplan.
A fully qualified context definition is shown below. Typically you'll not need all the trimmings, but they are shown here for completeness.

Extensions

Extensions are destinations for a call. This is the meat of NSG routing dialed numbers. They are given a name and contain a group of conditions, that if met, will execute certain actions.

A 'name' parameter is required: It must be a unique name assigned to an extension for identification and later use.

For example:

Conditions

 Dialplan conditions are typically used to match a destination number to an extension. They have, however, much more power than may appear on the surface.
NSG has a set of built-in variables used for testing. In this example, the built-in variable destination_number is compared against the regular expression ^500$. This comparison is 'true' if <destination_number> is set to 500

Each condition is parsed with the Perl Compatible Regular Expression library. (go here for PCRE syntax information).
If a regular expression contains any terms wrapped in parentheses, and the expression matches, the variables $1,$2..$N will be set to the matching contents within the parenthesis, and may be used in subsequent action tags within this extension's block.

For example, this simple expression matches a four digit extension number, and captures the last two digits into $1.

A destination number of 3425 would set $1 to 25 and then bridge the call to the phone at 25@example.com

Multiple Conditions (Logical AND)

 You can emulate the logical AND operation available in many programming languages using multiple conditions. When you place more than one condition in an extension, all conditions must match before the actions will be executed. For example, this block will only execute the actions if the destination number is 500 AND it is Sunday.

Keep in mind that you must observe correct XML syntax when using this structure. Be sure to close all conditions except the last one with />. The last condition contains the final actions to be run, and is closed on the line after the last action.
By default, if any condition is false, NSG will move on to the anti-actions or the next extension without even evaluating any more conditions

Multiple Conditions (Logical OR, XOR)

It is possible to emulate the logical OR operation available in many programming languages, using multiple conditions. In this situation, if one of the conditions matches, the actions are executed.

For example, this block executes its actions if the destination number is 501 OR the destination number is 502.

This method works well if your OR condition is for the same field. However, if you need to use two or more different fields then use the new regex syntax

Using this method it becomes easier to match the caller's name OR caller ID number and execute actions whether either is true.
A slightly more advanced use of this method is demonstrated here:

Basically, for this new syntax you can have a condition to have a "regex" attr instead of "field" and "expression" etc. When there is a "regex" attr, that means you plan to have one or more <regex> tags that are similar to the condition tag itself that it has field and expression in it.

The value of the "regex" attr is either "all" or "any" or "xor indicating if all expressions must match or just any expression or only one must match(xor) . If it's set to "any" it will stop testing the regex tags as soon as it finds one match, if it is set to "all", it will stop as soon as it finds one failure.

From there it will behave like a normal condition tag either executing the actions or anti-actions and breaking based on the "break" attr.

The basic difference here is once there is a "regex" attr, the <regex> tags parsed for "all" or "any" take the place of the single "field" and "condition"

NOTE: Also, if any captures are done in the "expression" attrs of a <regex> tag, only the data from the newest capture encountered will be considered in the $n expansion or FIELD_DATA creation. In addition, you can set DP_REGEX_MATCH_1 .. DP_REGEX_MATCH_N to preserve captures into arrays.

This is another example to show that all regex conditions must be true, then the action will get executed; otherwise, the anti-action will. This is the same logic as follows:

Basically, the <condition regex="all"> tells the parser, "Hey, execute the <action>'s only if all regexes PASS, otherwise execute any <anti-action>'s".

Complex Condition/Action Rules

 Here is a more complex example, performing time-based routing for a support organization. The user dials extension 1100. The actual support extension is 1105 and is staffed every day from 8am to 10pm, except Friday, when it is staffed between 8am and 1pm. At all other times, calls to 1100 are sent to the support after-hours mailbox

In this example, we use the break=never parameter to cause the first condition to 'fall-through' to the next condition no matter if the first condition is true or false. This is useful to set certain flags as part of extension processing. This example sets the variable begins_with_one if the destination number begins with 1

Variables

Condition statements can match against channel variables, or against an array of built in variables.

Built-In Variables

The following variables, called 'caller profile fields', can be accessed from condition statements directly:

• context Why can we use the context as a field? Give us examples of usages please.

• rdnis Redirected Number, the directory number to which the call was last presented.

• destination_number Called Number, the number this call is trying to reach (within a given context)

• dialplan Name of the dialplan module that are used, the name is provided by each dialplan module. Example: XML

• caller_id_name Name of the caller (provided by the User Agent that has called us).

• caller_id_number Directory Number of the party who called (caller) -- can be masked (hidden)

• ani Automatic Number Identification, the number of the calling party (caller) -- cannot be masked

• aniii The type of device placing the call ANI2

• uuid Unique identifier of the current call? (looks like a GUID)

• source Name of the FreeSWITCH module that received the call (e.g. PortAudio)

• chan_name Name of the current channel (Example: PortAudio/1234). Give us examples when this one can be used.

• network_addr IP address of the signaling source for a VoIP call.

• year Calendar year, 0-9999

• yday Day of year, 1-366

• mon Month, 1-12 (Jan = 1, etc.)

• mday Day of month, 1-31

• week Week of year, 1-53

• mweek Week of month, 1-6

• wday Day of week, 1-7 (Sun = 1, Mon = 2, etc.) or "sun", "mon", "tue", etc.

• hour Hour, 0-23

• minute Minute (of the hour), 0-59

• minute-of-day Minute of the day, (1-1440) (midnight = 1, 1am = 60, noon = 720, etc.)

• time-of-day Time range formatted: hh:mm[:ss]-hh:mm[:ss] (seconds optional) Example: "08:00-17:00"

• date-time Date/time range formatted: YYYY-MM-DD hh:mm[:ss]~YYYY-MM-DD hh:mm[:ss] (seconds optional, note tilde between dates) Example: 2010-10-01 00:00:01~2010-10-15 23:59:59

Caller Profile Fields vs. Channel Variables

One thing that may seem confusing is the distinction between a caller profile field (the built-in variables) and a channel variable.

Caller profile fields are accessed like this:

While channel variables are accessed like this:

Please take note of the ${variable_name} syntax. Channel variables may also be used in action statements. In addition, API functions can be called from inside a condition statement to provide dynamic data.

For example, you can use the cond API:

This example tests ${my_var}. If it is more than 12, "YES" is returned. Otherwise "NO" is returned. The condition tests the results for "YES" and logs the resulting message to the NSG log.

Starting the Gateway

After successful initial configuration, the NSG gateway needs to be started. The Control Panel is used to start, stop, restart the complete NSG gateway. One can also control on the fly configuration in the Profile Panel once the gateway has been started.

• Select Control Panel from side/top Overview Menu

• Confirm that warnings are clear

• Start the Media Processing First

  • Media Processing will start the Transcoding resources.

  • Note that Media Processing is optional

• Start the Media Gateway Second.

  • Media Gatway will start

  • TDM Hardware Spans (T1/E1 ports)

  • Netborder SS7 to VoIP Gateway Software

• Confirm that the boot button is selected.

  • This will confirm that gateway starts on reboot.

• When the Gateway starts successfully the green status bar will appear.

• System is now running.