Comdasys Convergence 4675

Administrator and User Manual
for the
Comdasys Convergence series
&
Comdasys FMC series
Comdasys AG
Rüdesheimer Str. 7
D – 80686 München
Tel.: +49.89.5484333-0
Fax: +49.89.5484333-29
support@comdasys.com
http://www.comdasys.com
Disclaimer
We have taken all possible care to ensure that this manual contains correct, accurate informa-
tion. However, the manufacturer cannot assume liability for any possible errors. In addition,
the manufacturer cannot guarantee that the hardware will meet the purpose you require.
Comdasys reserves the right to make changes according to technical progress at any time.
Brand names may be registered trademarks and must be treated as such.
Copyright
c 2005-2008
Comdasys AG
80686 München, Germany
All rights reserved. No part of this manual may be reproduced, processed or distributed in any
form (print, photocopy, microfilm or any other process) or processed by an electronic system
without prior written permission from the manufacturer.
User Manual edition: May 2008
Contents
2005-2008
c Comdasys AG 3
1 Overview
1.1 Scope of delivery (Convergence 4600 / FMC 4800)
1. Convergence (compare figure ??) with built-in redundant power supply

2. 2 Power cords for redundant power supply
3. Network cable
4. Crossover network cable
5. Mounting brackets for 19” racks
6. Handles for 19” rack usage
7. RS232 to RJ45 console cable
8. Quick reference sheet
Figure 1.1: Convergence 4600/FMC 4800
1. Convergence (compare figure ??) with built-in power supply
2005-2008
c Comdasys AG 4
1.3 Scope of delivery (Convergence 30xx / 33xx)
2. Power cord
3. Network cable
6. RS232 console cable
1.3 Scope of delivery (Convergence 30xx / 33xx)
1. Convergence 30xx or 33xx with built-in power supply (the ports vary on what model you
purchased varying from 4+1 BRI ports to 2 E1/T1 ports)
2. Power cord
3. Network cable
i Note that these devices are configured through an HTTP interface. The standard
configuration GUI is running on port 80. From there it is possible to configure everything
including the gateway components. It is possible to access the gateway configuration via a
separate GUI running on port 8080. Note however that any network setting you make there
will have no effect.
2005-2008
c Comdasys AG 5
Figure 1.3: Convergence 30xx and 33xx
1. Convergence (compare figure ??) with built-in power supply

2. Power cord
3. Network cable
2005-2008
c Comdasys AG 6
1.5 Scope of delivery (Convergence 1600)
1.5 Scope of delivery (Convergence 1600)
1. Convergence (compare figure ??)

2. Power supply 100-240 V, 50-60 Hz AC-DC transformer
3. Power cord
4. Network cable
Figure 1.5: Convergence 1600
1.6 Scope of delivery (Convergence 550 and 650)
1. Convergence (compare figure ??)

2. Power supply 100-240 V, 50-60 Hz AC-DC transformer
3. Power cord
4. Network cable
6. RS232 to RJ45 adapter cable (Convergence 650 only)
2005-2008
c Comdasys AG 7
1.6 Scope of delivery (Convergence 550 and 650)
Figure 1.6: Convergence 650
2005-2008
c Comdasys AG 8
2 Basic configuration
2.1 Prepare configuration
The Convergence is configured by a web interface, that can be opened with the web browser
of your choice. Therefore, the Convergence configuration is independent of the operating
system used and can for example be accessed from Linux, Macintosh or Microsoft Windows
computers. It is also not necessary to install any special tools, except you want to copy files
or have command-line access. Please refer to the Command Line Guide documentation for
more information on that.
For the Web configuration, your web browser must support frames, but nowadays this ap-
plies to almost every modern browser. If you want to use the setup wizard you’ll also need
JavaScript support. Please make sure this is enabled in your web browser.
The LAN1 interface of the Convergence is configured to the following parameters by default.
Network protocol TCP/IP

IP-Address 10.0.0.205
Subnetmask 255.255.255.0
Therefore, in order to be able to communicate with the Convergence , you need to configure
your PC to an address in the same subnet, as for example 10.0.0.206 .
2.2 Establish a connection to the Convergence
1. For starting configuration enter https://10.0.0.205 in your browser’s address

field. For some products, the correct protocol will HTTP, so you have to enter
http://10.0.0.205 to correctly connect.
In order for this to work, the IP address of your PC has to be set up to be in this subnet.
Please refer to the documentation of your operating system for more information on
how to accomplish this.
Possibly your browser will ask you to accept a certificate and warn you that it is self-
signed. To continue the configuration you will have to accept this certificate for estab-
lishing an encrypted connection to the Convergence .
2005-2008
c Comdasys AG 9
! If you are dealing with a device that is equipped with a separate management inter-
face, you need to explicitly enable management access to the device via the LAN interface.
Please refer to section ?? section for more information about this topic.
2. Enter the username and password. The username is admin and the password in the
state of basic configuration is sesam.
For security reasons, you should change the default password as soon as possible.
Information on how this works can be found in section ??.
3. Select your language.
After having logged in successfully you should see the HTML page in figure ??. You
can change the language anytime on the Head.
Figure 2.1: Select your language
2.2.1 Architcture of the WebGUI
The WebGUI of the Convergence consist of different parts. These are
• Page Header
2005-2008
c Comdasys AG 10
• Top Menu Bar

• Top Navigation
• Main Frame
2.2.1.1 Page Header
The page header gives you information about the Convergence you are dealing with.
2.2.1.2 Top Menu Bar
The Top Menu Bar is the top level navigation. This navigation gives you the major option to
select, namely Home, Apply Configuration (refer to ?? for more information), and Language.
2.2.1.3 Top (Main) Navigation
The top navigation is a two level navigation. This manual is structured according to this
navigation. Select any of the top (main) menu points. When you do that, a submenu will open.
You are now able to make a selection and by selecting any of these points the configuration
will change. The main frame will remain empty until you do that.
2.2.1.4 Main Frame
The main frame will always contain the currently selected configuration screen. Use the ?? to
select what part of the Convergence you want to configure.
2.2.1.5 Bottom Menu Bar
In the bottom line, you can find important product and software information on the bottom
right hand side. The most important thing is the software version which should be a four
digit number. This number can be followed by a dot. The number after this dot indicates the
patchset number the product contains. Note that Updates and Updates with included patches
install and behave exactly the same way. The numbering is just to indicate that this software
version is based on some major revision and just contains additional patches.
2.2.2 Home
When clicking home, you will always get to the status page.
2005-2008
c Comdasys AG 11
2.2.3 Apply Configuration
The Convergence has a transaction based configuration mechanism. This means that any
changes you make, will only become active after applying the configuration changes. Clicking
the Apply Configuration options will finally store all changes made since you last applied and
restart the services as necessary through the configuration changes. If you do not want to
interrupt the operations of the Convergence , there is also a way of applying the configuration
changes for individual services only. Please refer to the ?? for more information on this.
2.2.4 GUI concepts
The GUI follows a number of design principles. Understanding these is important for effec-
tively working with it.
2.2.4.1 Default Values
There are both explicit as well as implicit default values. The explicit ones are set by default
in the WebGUI. Implicit ones are fields that can simply be left empty. The system will select
an appropriate value for you. You can leave all fields except the mandatory ones empty.
2.2.4.2 Mandatory Values
Mandatory values have to be configured. In the GUI, you can identify them by the symbol
behind the title. If left empty, you will receive an error message asking you to set the value.
2.2.4.3 Erroneous Values
The WebGUI does check the entered values for consistency and will not accept values failing
this check. This however cannot avoid misconfigurations since only basic sanity checks as
well as a syntax checking of the entered values is performed. These checks include tpye
checks (string or number, etc.), range checks (do entered numbers make sense), and basic
sanity checks (do certain parameters exclude each other, etc.).
2005-2008
c Comdasys AG 12
2.2.5 Home Page (Status)
Here you can see an alphabetical list of all services available on the Convergence. It is
possible to start, stop or restart services individually by clicking on Start: , Stop: or
Restart: . The button with the label Reapply configuration: allows you to make sure
that the corresponding parameters set in the Web interface are activated for the service. If
you want to make smaller configuration changes to individual services without affecting the
operation of all other services, you can make the appropriate changes and save them. Then
you come to this status page to apply the changes and restart the respective service.
The Status ”LEDs” show whether the corresponding service is (compare figure ??):
- active ; - inactive ; - disabled
Applying configuration changes for selected services only

1. Go to the menu item for the service to configure. Make configuration changes and
click Save .
2. Return to the status page and click in the status line of the respective service.
3. Restart the service by clicking .
Figure 2.2: Service Status
2005-2008
c Comdasys AG 13
2.2.6 Convergence 30xx and 33xx
Note that the product with integrated gateway devices have some special properties. First,
as already mentioned in this manual, you have to enter http://10.0.0.205 to correctly
connect. This means that the product is using the HTTP protocol as its default interface.
In addition to that, there is an additional menu entry in the configuration menu by the name
of Gateway. This menu point will bring you to the VoIP gateway configuration. When clicking
this menu, you will get to the configuration page shown in figure ??.
Here you will need to use the standard gateway credentials supplied with the gateway which
is public as username with an empty password. This will bring you into the gateway config-
uration. In order to get a description of the parameters there, please refer to the Mediatrix
3000 Series Digital Gateway documentation. Note that all menu points not making sense in
the integrated product have been made inaccessible.
Figure 2.3: Gateway Configuration
2.2.7 Convergence 4xxx
The Convergence 4600 and 4800 provide an additional management interface for configu-
ration. The management interface is labeled FE on the front side of the appliance. Due to
2005-2008
c Comdasys AG 14
additional available network interfaces the port arrangement differs from the other Comdasys
appliances.
For the Convergence 4xxx series the default IP address is configured on the management
interface instead of the primary lan interface.
2005-2008
c Comdasys AG 15
Please refer to the table below for the port mappings on the front side of your 4xxx Conver-
gence series.
Label Usage
CON Connector for serial console
FE Management Interface, Fast Ethernet Connector
Key USB Connector, e.g. for attaching a keyboard
B1 GBIC Interface 1
B2 GBIC Interface 2
A1 LANA Interface
A2 LANB Interface
A3 DMZ Interface
A4 WAN Interface
2005-2008
c Comdasys AG 16
3 Expert mode
The Expert Mode assumes familiarity with the concepts of IP networking and if applicable with
those of VoIP.
In the expert mode you can find all configuration parameters structured in a two level menu.
The configuration can be performed in any order.
System In the section, you can configure all the system basics, update the unit, factory reset the unit, as we
Network The network part lets the user configure all interfaces, virtual interfaces, traffic shaping and other n
VPN
Security The security portion consists mostly of the firewall settings.
2005-2008
c Comdasys AG 17
3.1 System
Voice-over-IP The VoIP settings contain all the Session Border Controller configurations, Survivability functi
Fixed Mobile Convergence This sections contains all FMC related settings. Note that changes here usually
Diagnostics
Changing menu items marked with ? will be applied immediately, in contrast to the remain-
ing items, which will only be applied after excecuting Apply configuration , or the Reapply
Configuration followed by a restart of the respective service in the Status page. Using Apply
configuration will cause all services to restart.
3.1 System
3.1.1 Basic settings
In this section you can adjust date and time, specify a domain name server (DNS server) and
a host name for the Convergence. Note that the date and time settings will be overridden by
any NTP server settings. If an NTP server is set, the clock is synchronized from there. The
system name should be set for administrative purposes. It is not a crucial setting. The system
name is however shown as the command prompt when you access the system via command
line interface. There it is very helpful to see the system you are on.
2005-2008
c Comdasys AG 18
3.1 System
Figure 3.1: Basic settings
Time and date

Date and time will be applied immediately after pressing the button Save , all the other op-
tions only after selecting Apply configuration. The system time and date are important for
using for example the logging facilities. The settings done here will also be saved in the
hardware clock of the system and thus not be lost with a reboot.
The default values are the currently adjusted time and date respectively.
i The time and date setting will be applied immediately without the need of pressing
Apply Configuration.
Timezone
Usually NTP servers utilize GMT (Greenwich Median Time). Therefore to get the correct
timezone on your device, you need to set the time zone where the device is located. There
are two types of timezones that are supported by the device. The GMT timezones simply
define a fixed offset from GMT / UTC time. This however does not include daylight savings
time. The change between normal and daylight savings time occurs at different times in
different parts of the world. These are coded in the regional time zones (e.g. CET for Central
2005-2008
c Comdasys AG 19
3.1 System
European Time). If you select such a timezone the switch to daylight savings time and back
is done automatically by the device.
Domain name server

For using debugging tools like ping, traceroute and telnet with names instead of addresses
and specifying names for the remote clients of VPN tunnels (e.g. if the remote client works
with a dynamic DNS entry) a DNS server has to be specified. The same holds of course true
for all other services like VoIP where the specification of host names is possible. If you do not
specify a DNS server here, you can only use IP addresses for all services configured on the
Convergence.
If you connect to the internet with PPPoE and PPTP this value will often be substituted with a
DNS server automatically assigned by the provider. You do not have to set this value in that
case.
System name
The entered name must not contain any whitespace or special characters. Any system name
you set here should correspond with any name you assinged in a DNS server. Non matching
forward and reverse lookups as well as differing host names will cause problems with various
services.
By clicking the button Save , the settings will be applied.
3.1.2 Change password
With this menu item, the password for accessing the Convergence can be changed. The
default password is sesam. It is highly recommended to change it before connecting the
appliance to the Internet.
The chosen password should not contain whitespace, since such a password might be man-
gled by the used browser. If you still want to set such a password, please use the CLI interface
to avoid such browser problems. If you want to use passwords with special characters, please
check the Command Line Guide for information on how to safely accomplish this. By clicking
the button Save the new password will be applied.
The new password applies both for access over the web interface and over command line
interface (serial console, SSH).
! The new password will be applied immediately. This means that right after changing
the password with your browser, you will be asked for it to continue with the configuration.
2005-2008
c Comdasys AG 20
3.1 System
! By default the password length is limited to 8 characters for the WebGUI administra-
tion. Excess characters will be ignored silently. There are however ways to increase this
limit (e.g. by using RADIUS) , or to use certificate based authentication. Please refer to the
Command Line Guide for more information.
Figure 3.2: Change the password
2005-2008
c Comdasys AG 21
3.1 System
3.1.3 Install update
Comdasys will publish regular system updates for their delivered systems. For unregistered
users without special maintenance agreements, these can be downloaded from the web page
http://www.comdasys.com. Users with special maintenance agreements will also get
software upgrades providing additional functionality. If you are interested, please contact us
via email: info@comdasys.com.
With this menu item, a local file on your PC can be selected and the update process can be
started. Depending on the network connection, this upload can take up to several minutes.
The update can even fail if done over a low bandwidth WAN link. It is not recommended to
perform the update with a connection of less than 128 kbit/s. However, aborted updates do
not harm the Convergence or influence it in any way.
After the update process, there will not be an automatic reboot or restart of services. In order
for the Update to take effect, you will need to reboot your Convergence system. You can
however perform this reboot at a later time. Having uploaded the update will have no effect
on the running system, since this will only install the update into the flash.
! You should not import old configurations into a more recent versions of the Conver-
gence system. You should have the configuration on the Convergence prior to the update.
During the update process, this configuration will be converted.
! Please refer to the Release Notes before doing an Upgrade. These might contain
special instructions to consider before upgrading to a certain version.
i Although the approach has been documented for an Update here, the exact same
thing can be done for a downgrade as well. This means that you can select an older
version just as if you were uploading a more recent file. Note that you will have to reapply
the configuration after rebooting the system when having downgraded. Note also that not
all services might come up properly after a reboot. Only after reapplying the configuration
this can be ensured. Note that you should only use compatible configurations with older
versions. This can be accomplished by reverting to a saved configuration or by doing a
factory reset.
i A timeout can occur while uploading an update. The Convergence has a hard set
timeout of 2 hours. This means that any upload will abort after this time if it has not com-
pleted. Note that your browser might interrupt the upload quicker than that.
2005-2008
c Comdasys AG 22
3.1 System
Figure 3.3: Install an update
2005-2008
c Comdasys AG 23
3.1 System
Installing an update
1. Download the update and Readme (if applicable) file for the desired version and store
it on your PC. The current version of the Convergence can always be found in the right
bottom corner of the web interface.
2. Select the downloaded update file in the web interface.
3. Click the button Upload for upload.
4. If necessary, do additional configuration steps as recommended in the enclosed
Readme file. If there is none, no special considerations have to be taken.
5. Reboot the system in order for update to take effect.
6. Click Apply Configuration to adapt the configuration
i After rebooting with the new software version, please make sure to click Apply Con-
figuration to adapt the configuration to the new software version
Installing an update for the Convergence 30xx/33xx wit Integrated Voice Gateway
The Voice Gateway Software is separate from the system software, and therefore it must be
updated separately. The Gateway software update is packaged like a hotfix, but it is a full
software update for the gateway component.
1. Download the Gateway update bundle (GW Software Update) and store it on your
PC.
2. Unpack this ZIP archive, it will contain the software file (ending in .sh) and maybe
some documentation and release notes.
3. Select the downloaded update file (muse....sh) in the Upload Update Web Interface.
4. Click the button Upload for upload and wait for the Update to complete.
5. Reboot the system in order for update to take effect.
2005-2008
c Comdasys AG 24
3.1 System
3.1.4 Provisioning
The Convergence features provisioning facilities that can be used for mass deployment.
Figure 3.4: Configuration of the Provisioning
With that it is possible to create a more or less standard configuration plus a list of vari-
ables that are different for the respective Convergence . Provisioning is always a very project
specific topic where there is no real general answer. Suffice to say that Provisioning facil-
ities are present and can be used. For further information please contact your reseller or
support@comdasys.com .
3.1.5 Configuration backup
In this section you can save or restore the configuration of the complete Convergence. By
clicking the button Save , the most important configuration files will be saved into an archive
file
configuration-<date>.cpio.gz
offered for download.
2005-2008
c Comdasys AG 25
3.1 System
Restoring configuration
1. Select the location of the backup file stored on your PC
2. Click the button Send for Upload
3. Apply configuration
Figure 3.5: Configuration backup
i Note that this configuration saving applies to all necessary parameters for the Con-
vergence . This includes all FMC data like users and configured hosts registrations. It will
hence include the complete FMC database snapshot at the time the backup is made. If you
are using a product with integrated voice gateway functionality, this will also include e.g. the
ISDN configuration.
! The language of the GUI is also stored in the configuration archive, since it is part
of the configuration. This means if you restore a configuration later, the language might
change.
2005-2008
c Comdasys AG 26
3.1 System
! This mechanism is intended for backing up and restoring configurations on the same
devices. Please do not use this for provisioning purposes by creating a default configura-
tion and then replicating this to multiple devices. Note that also device specific files will be
included in this archive that you do not want to replicate to arbitrary devices. This however
does enable you to make a one-to-one restoration of a failed device. Saved configurations
do only work on equal restoration devices. Do not use a saved configuration from one de-
vice on a different device type unless this procedure has been okayed by the manufacturer!
3.1.6 Configuration restore
The Configuration Rollback enables you to revert the configuration of your box back to an ear-
lier status. It depends on when you last saved you configuration which ones you will be able to
roll back to. After performing a rollback, you will always have to press Apply Configuration
to activate it. This will also provide you a chance to look at the restored configuration first,
before activating it.
i Before doing bigger changes to your configuration, it is always wise to go to this page
and save the current configuration. This will enable you to roll back to this conifguration at
a later point in time.
i Every time you use the Apply Configuration the current configuration will be
stored.
The naming convention of the stored configurations is as follows: DATE-TIME. The date will
be formatted as year month day always with two digits followed by a minus followed by the
time in 24 hours format. The following is an example filename of a backup ( 080311-1423)
done on March 11th 2008 at 14:23.
Number of Configurations
This field defines how many configurations should be stored on the system. You have a
choice between ’5’, ’15’ or ’25’ stored configurations. Saving a configuration will fail if there
is no space available on the system. The system however has been designed to provide
enough space for all of the above mentioned settings. This however does not necessarily
apply if additional data has been manually copied to the system in CLI mode.
Previous Configuration
Select the configuration you want to restore here by using the drop-down box. To activate this
configuration, you will need to select Apply Configuration .
2005-2008
c Comdasys AG 27
3.1 System
Figure 3.6: Configuration restore
2005-2008
c Comdasys AG 28
3.1 System
Configuration Save now

By Pressing Save you can trigger an immediate backup of the configuration. Note that such
a backup can take several seconds. Afer the backup has completed you can refresh tha page
and see the backup in the Previous Configuration selection list. I
! A restored configuration will not automatically be active after a reboot. The correct
procedure it to always press Apply Configuration after performing a restore. A reboot is
not necessary.
i The Backup will include all FMC settings, therefore you should be careful because
for example newly created users will get lost.
3.1.7 Remote Backup
The Convergenceoffers functionality for providing an automated configuration backup to a

remote system. The Backup can be done through FTP and SCP protocols and can be doned
in scheduled intervals. By default this functionality is disabled, so you need to configure it first
in order to use it.
Active
You need to check this in order to enable the functionality.
Type
You can select between FTP and SCP. Note that you should use secure copy (SCP) whenever
possible because the backed up configuration also includes passwords, but also note that
using SCP needs some manual setup which is described below.
Servername
Specifiy the server to backup to here. You can either specify an IP address or a hostname
here. If you are using hostnames here make sure the DNS server has been set on the Basic
Settings page.
Path
You also need to specify a path on the server here, where the files should be stored. This
path is usually relative to the default login directory of the specified user.
2005-2008
c Comdasys AG 29
3.1 System
Figure 3.7: Remote Backup Configuration
2005-2008
c Comdasys AG 30
3.1 System
Username
You have to specify a username here. If the FTP server does not require authentication, you
should still specify some name here e.g. anonymous.
Password
Specify the password of the defined user on the server. If this setting is incorrect, the backup
will fail. In that case you should check your server logs to see if there is an authentication
mismatch. This setting does not apply to SCP !
Interval
You have a choice of different backup intervals here. The following settings are possible:
• Daily: This will back up the configuration any day. Set the time in the Interval field.
• OnChange: This will create a backup after every material change (this does not include
changes to the FMC configuration)
• Hourly: This will create a backup every hour. There is no need for additional settings.
• Weekly: Backup every week. Select the day via the Interval field.
Time/Day of Week
The setting in the field always has to be an integer, and is only relevant if you have set the
Interval field to either Daily or Weekly.
If Daily is configured there, this field represents the time in full hours (24 hour time) when the
backup should be performed.
If Weekly is selected, this is the day of the week where 1 is Monday.
i The backup archive format of the automatic backup is identical with the backup format
for the manual Configuration Backup. In order to restore a backed up configuration, you
should hence use the Confguration Backup page. See ?? for more information.
i To configure SCP, some manual setup is needed. First, you need to log in to your
Convergence via SSH. If not already done, you need to run ssh-keygen -t dsa to generate
an SSH key pair. Then you need to setup up key-based login to your backup account on the
backup host by running ssh-copy-id -i /root/.ssh/id dsa.pub [backupuser]@[backuphost].
You will then be prompted for the password for that account. After entering the password,
you should be able to log in to the backup account via ssh [backupuser]@[backuphost]
without being asked for the password (the key will be used for authentication instead). Once
that works you are ready to use SCP for remote backups.
2005-2008
c Comdasys AG 31
3.1 System
3.1.8 Restart system
By clicking the button Restart , the Convergence will be rebooted.
Figure 3.8: Restarting the System
It may take up to two minutes until the Convergence is fully operational and reachable again.
Depending on the configured WAN type and the number of possibly configured VPN tunnels,
it can take even longer until all tunnels are available again.
2005-2008
c Comdasys AG 32
3.1 System
3.1.9 Port Numbers
On this page it is possible to define the SSH and the HTTP/HTTPS port used for administra-
tion.
The Default values are 22 for SSH, 443 for HTTPS (or port 80 for HTTP on systems that don’t
use HTTPS), as recommended by the Internet Assigned Numbers Authority
(http://www.iana.org/assignments/port-numbers).
i Note that you do not need to change these values in most cases. Changing them is
mostly done for security purposes if administration through the WAN interface is enabled.
Using non standard ports makes it harder for scan programs to find these open ports.
3.1.10 Restore Factory Defaults
The ’Restore the basic configurations’ page allows you to restore the basic configuration and
/ or reset the ’Dualmode’ database (only FMC products) on the factory state. Refer to figure
?? on page ?? for more information on this.
• Restore the basic configuration

Restoring the basic configuration deleted all configured settings from the Convergence
with the exception of the ’Dualmode database’. To restore the basic configuration click
the first Reset on the right side of the page.
• Reset ’Dualmode’ database (only FMC products)
This action will empty the database. The database includs all ’Dualmode’ settings. To
Reset the database click the second Reset on the right side of the page.
i After the restore / reset a restart of the system is needed!
! Ater ’Restore the basic configuration’ the default IP address is 10.0.0.205 and subnet
mask is 255.255.255.0
3.1.11 Licenses
This product contains Open Source Software. Most Open Source Software mandates that the
license of the package is included with the product containing the software. Therefore, this
page lists all licenses of Open Source packages contained in this Convergence . A mouse
click on the package name shows the complete license text.
2005-2008
c Comdasys AG 33
3.2 Network
Figure 3.9: Reset basic configurations
3.2 Network
3.2.1 WAN interface
The internet connection can be configured with the menu item WAN interface. There are the
following parameters that can be set up (compare figure ?? on page ??).
Connection via IP
If the Convergence is connected to the internet via a leased line or an internet router (xDSL
router, ISDN router, etc.), you have to choose IP and enter the information for your network.
For the field Gateway you should enter the address of your router (default gateway) for the
WAN connection.
Connection via PPPoE / PPTP

If the Convergence is directly connected to the internet via a DSL modem, you will have to
select PPPoE and PPTP (depending on your provider) and enter the connection information
given to you by your provider. Please also refer to your ISP on applicable additional configu-
rations necessary to make with DSL routers. Note that some providers by default do not want
you to connect a router for being able to connect multiple PCs. They will ship special software
to install on the PC for being able to access their network. If you experience problems with
the installation here, please make sure your provider does not make such restrictions.
2005-2008
c Comdasys AG 34
3.2 Network
Figure 3.10: Configuration of the WAN interface
2005-2008
c Comdasys AG 35
3.2 Network
If the connection uses PPPoE, the username and password is all you have to enter.
If the connection uses PPTP there is additional information needed: The internal IP address
of your DSL modem, the related netmask (both should be known by your provider) and a
matching IP address for your Convergence. The IP of the Convergence has to be in the
same network as the IP address of the modem. Please ask your provider or consult your
DSL modem/router manual about the IP settings of your modem. A common IP address is
10.0.0.138.
Configuring WAN Interface

1. Select the connection type: IP, PPPoE, PPTP or choose Deactivated if you do not
want to use WAN interface.
2. Provide configuration details for the selected section as described above.
3. Save changes by clicking on Save . Your changes will be applied after selecting
Apply configuration.
3.2.2 LAN interface 1
This menu item is used for configuring the primary LAN interface. There are the following
parameters that can be set up (compare figure ?? on page ??):
Dynamic IP address
Select this if you have a DHCP server in your LAN network that you want the Convergence
to obtain its IP address from. This only applies to bigger networks where the Convergence
acts for certain dedicated functionality (e.g. VoIP) only. For the NAT parameter see the Static
case.
! Since the Convergence serves as a server for certain protocols such as SIP, the IP
address of the device must be known to the user. Assigning a truly dynamic IP address
hence does not make much sense. DHCP however is frequently used as a tool for the
central administation of IP addresses. You can have DHCP assign a fixed IP address to
a device. This approach is controlled by the MAC address that can be configured in the
DHCP server.
Static IP address
The IP address of the Convergence’s primary LAN interface.
Netmask
The netmask for the IP address of the Convergence’s primary LAN interface.
2005-2008
c Comdasys AG 36
3.2 Network
Figure 3.11: Configuration of the primary LAN interface
2005-2008
c Comdasys AG 37
3.2 Network
NAT
This option should be chosen if there is an address translation required for the whole network
traffic from this LAN to the Convergence’s WAN address. This only applies to outgoing traffic
from the LAN to the WAN.
Generally this is needed, if your provider does not provide official IP addresses for your LAN
(the usual case) and your Convergence is used as an internet router.
! You cannot specify a default gateway here directly. The settings you see below are
for the DHCP server and are only assigned to the hosts in the network. They do not apply
for the Convergence itself. In order to specify a default gateway for the product, please
configure it with the WAN interface. If you do not want to configure a WAN interface and
still have a default gateway, please configure a routing entry. Please see ?? for more
information.
2005-2008
c Comdasys AG 38
3.2 Network
DHCP server
The Convergence is able to automatically assign IP addresses to computers connected to the
primary LAN interface.
If this functionality shall be used, this option has to be selected. Note that this option applies
to DHCP server functionality. Do not confuse this with the above described DHCP client
functionality. You should also make sure that you have no other DHCP server running in your
network since this can have very adverse effects.
from IP, to IP
If the Convergence is intended to be used as DHCP server you have to define the address
range the DHCP server will assign to clients requesting an IP address. This address range
must not contain IP addresses of any other configured computer configured with a static IP
address within this LAN.
Both addresses have to be in the same subnet as the Convergence IP address. The beginning
and the end of the range of course also have to be in the same subnet.
Domain
This is the DNS domain that will be assigned to the client. When using a hostname without
domain in the DHCP client, the domain name will be attached as the default domain.
Standard Gateway IP
By default, the Convergence itself acts as a standard gateway. Another standard gateway can
be set by ticking this checkbox and assigning an IP address below.
IP, DNS and NTP

If the Convergence acts as a DHCP server, you can optionally specify 2 DNS servers and up
to 3 NTP servers. Those addresses will be transmitted and assigned to the computers that
are using DHCP.
Configuring LAN Interface 1

1. Select the connection type: Dynamic IP via DHCP if you have a DHCP server in
your LAN or Static IP otherwise. You should never configure a Static IP address in the
range of your DHCP Server, since this could lead to an IP address conflict!
2. Check NAT if there is an address translation required for traffic from the LAN to the
Convergence’s address.
3. If you want Convergence to act as DHCP-Server or as a Standard Gateway, check
them and provide configuration details for these sections as described above.
2005-2008
c Comdasys AG 39
3.2 Network
4. Optionally you can specify DNS and NTP servers that will be transmitted and as-
signed to the computers that are using DHCP.
2005-2008
c Comdasys AG 40
3.2 Network
3.2.3 LAN interface 2
There are several options for configuring the secondary LAN interface (Compare figure ?? on
page ??):
Figure 3.12: Configuration of the secondary LAN interface
Deactivated
The secondary LAN interface will not be used.
DMZ
i This option is only available on Convergences which don’t feature a dedicated DMZ
interface (see section ??).
The secondary LAN interface serves for a so called demilitarized zone (DMZ); a secure net-
work area, that is separate both from the internet and from the local network. It is mostly used
for servers that shall be reachable from both the internal network and the internet. (e.g. mail
server, web server, etc.)
In this scenario, only the Convergence IP address and netmask in this DMZ has to be speci-
fied. There are no more options left.
2005-2008
c Comdasys AG 41
3.2 Network
Internal net
In this scenario, the secondary interface will be treated exactly the same way as the primary
one.
The possiblities of configuration are therefore the same as in section ??.
2005-2008
c Comdasys AG 42
3.2 Network
3.2.4 DMZ interface
i This option is only available on a Convergence 2600, 3600, and 4600 and on FMC
2800, 3800, 4800
The DMZ interface can be used for implementing a so called demilitarized zone (DMZ); a
secure network area, is separate from both the internet and from the local network. It is
usually being used for servers that shall be reachable from both the internal network and the
internet. (e.g. mail server, web server, etc.). A DMZ will usually have official IP addresses. If
you want to provide services to the internet and want the servers to have private IP addresses,
we are not talking about full DMZ functionality, but rather about port forwarding. Please refer
to the Firewall section for more information on that.
The DMZ interface is deactivated by default. If you choose to activate it by selecting the
radio-button DMZ. To configure the DMZ, only the Convergence ’s IP address and netmask
for this DMZ have to be specified. There are no more options left. Typically you will want to
restrict access to the DMZ. For more information on that, refer to the Firewall section for
more information on that.
Configuring DMZ Interface

1. Select DMZ in order to activate DMZ Interface.
2. Provide IP address and netmask for this DMZ.
Apply Configuration .
2005-2008
c Comdasys AG 43
3.2 Network
Figure 3.13: DMZ interface
2005-2008
c Comdasys AG 44
3.2 Network
3.2.5 Dynamic DNS
With the help of this menu item, it is possible to make the Convergence reachable from the
internet even if a dynamic IP address is assigned by your provider. The principle is very
simple. If a DynDNS provider is set up, the Convergence will post its current IP address each
time it is assigned a new one. This is the only possibility for setting up a VPN tunnel between
two VPN routers without static IP addresses.
For being able to use a dynamic DNS service, you have to register a name with such a service
(most DynDNS providers offer this basic service free of charge). This name and the essential
username and password for updating must be specified here together with the provider of the
service.
Figure 3.14: Dynamic DNS
Table ?? shows the DynDNS operators currently supported.
3.2.6 Name server
The Convergence can run a name server in order to forward and resolve DNS queries. On
this page you can manage the list of forwarders to be used. It will act as a caching server not
2005-2008
c Comdasys AG 45
3.2 Network
Provider Register at
DHS http://www.dhs.org
DynDNS http://www.dyndns.org
DyNS http://www.dyns.cx
easyDNS http://www.easydns.com
EZ.net http://www.ez-ip.net
HN.org http://www.hn.org
JustLinux http://www.justlinix.com
ODS http://www.ods.org
TZO.com http://www.tzo.com
ZoneEdit http://www.zoneedit.com
Table 3.2: Currently supported providers for dynamic DNS service.
i This list can vary depending on the software release!
Configuring Dynamic DNS

1. Select the DynDNS Supplier.
2. Enter your Username and Password and Hostname to be used.
2005-2008
c Comdasys AG 46
3.2 Network
Figure 3.15: Name Server Configuration
2005-2008
c Comdasys AG 47
3.2 Network
forwarding each individual query but rather only query once for each domain name (requeries
will be done according to the expiry times specified in the DNS names resovled). Therefore,
this functionality can also be used for performance improvement with applications that do a lot
of name server lookups. A simple configuration would be to enter the DNS server assigned
by your Internet provider. The PCs should then no longer contact this server for DNS, but the
Convergence which would then act as a caching forwarder.
Instead of configuring a forwarder for all requests, the DNS server can also be run as a slave
server for certain zones, or as a forwarder for certain zones. As slave server, it would not only
act as a caching proxy for certain zones, but as an authoritative name server.
Configuring Name Server

1. Select whether to use custom configuration file: Use existing configuration or to
configure this service via web interface: Activate DNS query forwarding. Choosing
Deactivate DNS query forwarding will disable this service.
2. Provide IP addresses of the Forwarders to be used.
3. If wished, add Zones and Forwarded zones that should be managed by this name
server. Note that the Convergenceacts as a slave server and you have to provide exact
names of the zone files as they are set on the master server. These options should only
be used by administrators familiar with the DNS protocol. They should not be required
for standard scenarios.
2005-2008
c Comdasys AG 48
3.2 Network
3.2.7 Routing
With this menu item you can configure additional routing entries. Standard routes like the
default route and routing between the different configured interfaces is generated automati-
cally. Hence, this menu only has to be used for any additional routes desired. Note that you
only set the routes for outgoing IP packets here. In order to make the network behind the
Convergence accessible from your network, you have to make sure that the network towards
the Convergence is handled correctly.
Use to edit, or to delete an existing entry.
New routes are created by entering the matching values in the last row and can be applied by
clicking the button New .
Figure 3.16: Routing
Adding a new routing entry

1. Click Add to create new entry and specify configuration parameters as follows.
2. Destination The destination network for the desired route. This can also be a single
host.
3. Netmask The netmask of the destination network. Note that 255.255.255.255 will
signify a host route.
2005-2008
c Comdasys AG 49
3.2 Network
4. Gateway The address of the gateway router that connects the destination network
with the local network. This address must be accessible via a local interface. The
gateway must hence represent the next hop that can be used for routing.
5. Interface The interface to which the gateway is connected (directly or indirectly via
one or more switches).
6. Click Save to save the changes. Your changes will be applied after selecting
i Please beware when setting a default route here. Usually, the default route is aut-
matically set if the WAN interface is configured. In that case, the default route points to
the gateway specified in the WAN interface configuration. If you have established an ADSL
connection, the default gateway is usually assigned via DHCP. If you have no WAN interface
configured, you should specify a default gateway here. Specifying a default gateway works
by using destination 0.0.0.0 with netmask 0.0.0.0
Compare figure ?? on page ??.
3.2.8 Bandwidth
QoS and Bandwidth management makes it possible for you to exactly control your network
traffic. For this purpose, the allocation of bandwidth for different services and computers in the
network can be controlled with the available bandwidth management features. The bandwidth
management functionality is also used in conjunction with other functionalities described later,
as for example Call Admission Control. The following example will illustrate the concept:
You want to give precedence to the traffic of realtime applications like Voice-over-IP or Video
Conferencing, because maintaining a constant and low-jitter bandwidth is very critical for the
quality of these services. At the same time, concurrent internet traffic (e.g. for browsing web
pages) should not be shut down completely by too many concurrent real-time sessions. It
must of course by no means interfere with the performance of the prioritized service. Traf-
fic Shaping and QoS is very advanced functionality. You should know what you are doing
because you can easily prevent applications from functioning properly with misconfigurations
here. On the Internet, there is lots of information available on QoS and Traffic Shaping. An
in-depth explanation of the concepts would however be beyond the scope of this document.
The QoS configuration of the Convergence happens in so called classes, which are ordered
hierarchically. This approach is called hierarchical token bucket packet scheduling (HTB).
The classes’ names are composed as following:
<network interface>-<parentclass ids>:<class id>

<parentclass ids> ::= (:<class id>)*
2005-2008
c Comdasys AG 50
3.2 Network
The class id has to be unique for all classes! The configuration sections for the network
interfaces always exist, as long as the interface is configured. In that case, it can only be
changed but never deleted.
Figure 3.17: Bandwidth management overview
The only parameter of a network interface is the default class, the last number of the class’
ID, which will contain all of the data traffic not matched by any other class. Often this class
has only a small amount of bandwidth for itself since everything else is used by its children,
but can make heavy use of excess bandwidth.
Starting from any class in the list, you can arbitrarily create subclasses with the button on
the right hand side of the respective class. Now press the following button on the right hand
side of the respective class to get to the following mask.
The table for entering the configuration data contains the following fields:
Parent class
Shows the name of the parent class for this class. The traffic limit of a child must be less than
that of the parent. If a parent has multiple children, the sum of the bandwidths used by the
children should not exceed that of the parent class.
2005-2008
c Comdasys AG 51
3.2 Network
Figure 3.18: Add new class
Description
Here you can enter a free description for making the setup easier to understand and main-
tain.
Rate
The bandwidth that will be provided for this class. All traffic, that passes through this class
will be shaped in a way, to not exceed this configured bandwidth limit. The unit is by default
”kilobit per second” but you can also enter Kbit, Mbit, bps, Kbps, Mbps. Note: bps stands
for ”bytes per second”.
Ceiling
This field defines the maximum amount of bandwidth this class can use at all. The difference
between rate and ceiling is the bandwidth that this class is allowed to “borrow” if there is
unused bandwidth available in the parent class. If this field is left blank, this class will never
borrow any bandwidth. If more than one class is demanding unused bandwidth, every class
gets allotted a contingent proportional to their own rate. In root classes, it makes no sense to
define a ceiling, because a root class cannot borrow bandwith from a parent class.
2005-2008
c Comdasys AG 52
3.2 Network
Burst and Ceiling Burst

These parameters define how much data is allowed to be sent with maximum (hardware)
speed, before trying to serve date from a different class. This parameter will have a significant
influence on the jitter behavior. The larger this value, the more jitter can possibly be induced.
If you set Ceiling Burst to a small value (e.g. size of a packet), it can be used to cap bursts
(i.e. a high data rate at the beginning of a connection) effectively, so that the data rate will
not exceed the value for ceiling, not even for a very short period of time. Small values can
however lead to packet fragmentation or large delays for very big packets.
Priority
This field is used for setting the priority of the traffic for this class relatively to the classes on
the same level (sister classes). The bigger that number the lower the priority. Furthermore,
classes with higher bandwidths are preferred in the assignment of available bandwith.
2005-2008
c Comdasys AG 53
3.2 Network
Leaf Queuing Discipline

The Leaf Queuing Discipline defines the queuing behavior for this class. Possible values are:
None, SFQ, Packet FIFO, Byte FIFO.
If you choose None, all incoming packets of this class are forwarded in the order of their
arrival.
SQF is a simple, efficiently computed, probabilistic algorithm, which is a useful method when
you want to have one class’ traffic distributed equally over several different hosts and/or ser-
vices in a fair fashion. No single host will be able to use all bandwidth provided for a certain
service then. With the parameter “Quantum”, you can specify how many bytes are allowed to
be taken from the queue (dequeued) until it is the next host’s turn. By default, this is the value
of MTU.
! Never set a value smaller than MTU, since that will prevent larger packets from being
forwarded in one piece!
The parameter “Perturbation” defines the number of seconds after that SQF renews its hash
function for queuing incoming packets randomly. The default value is 10.
Both FIFO queues have the parameter “Limit”, which indicates the length of the queue. With
Byte FIFO you can specify the value using the unit ”bytes” and with Packet FIFO the
number of packets.
MTU
The maximum size of a packet, used for tranfer rate calculation. By default a value of 1500 is
used, which is appropriate for Ethernet based networks (default MTU value).
Filter
These rules define how packets are classified. If the conditions defined here match, the
packet will be assumed to be in the respective class. The algorithm used here is first match.
A packet will fall in the first class for which the conditions match.
You can for example check the source and destination information of the packets. The format
of such a entry is:
[IP address[/subnet prefix]][:port[/port mask]]
Legal values for instance are:

10.1.1.0/24:80 all packets of the network 10.1.1.0 with port 80
:50 all packets with port 50
Compare figure ??.
2005-2008
c Comdasys AG 54
3.2 Network
Figure 3.19: Add new Filter
An additional possibility to classify packets is a mark that can be assigned to a packet by

the firewall. This is a very powerful mechanism that can however be very complex to use.
With this mechanism, it is possible to classify based on things like the DSCP tag, or the layer
7 protocol. This can for example be useful for limiting FTP connections, because they use
dynamic ports and can use arbitrary IP addresses. It is however possible to limit the traffic
used by FTP, or any other protocol to a certain value.
2005-2008
c Comdasys AG 55
3.2 Network
3.2.9 Bandwidth Daemon
The bandwidth daemon monitors the network traffic in order to determine the amount of free
bandwidth. This allows for dynamic allocation of bandwidth for different services. Please see
section ?? for further information on bandwidth management.
In this section you can specify three parameters that affect the bandwidth daemon. These
are sample rate, number of samples and log-level. However, note that the default values the
bandwidth daemon is originally configured with do not need to be changed in most cases.
Sample rate
Specifies the frequency of the checks for available bandwidth in tenth of second. The default
value for this setting is 1 and this means that the daemon performs the checks every 0.1
seconds.
Number of samples
Specifies number of samples to be taken in order to calculate the current average bandwidth.
30 samples is the default. Number of samples together with the default sample rate value
give a time window of 3 seconds.
Log level
You can view log messages created by the bandwidth daemon in the system logfiles by set-
ting log level to error, warning, info, or debug. Choosing none disables logging bandwidth
daemon’s messages.
Logging configuration for Convergence is desribed in section ??.
Finally, save your changes by clicking Save . Your changes will be applied as soon as you
apply the current configuration.
2005-2008
c Comdasys AG 56
3.2 Network
3.2.10 NTP
The table on this site contains one or more NTP servers Convergence should consult in order
to set the system time.
Figure 3.20: Configuration of NTP Server
To add new entry to the list simply fill in name or IP address of an NTP server and click Add
. An NTP server can be also used with a preference by checking preferred. This means
that an answer received from such server won’t be dropped but in case it differs significantly
from other answers. Note that only very reliable and stable NTP servers should be given a
preference.
Setting up NTP
1. Check Active to enable NTP. Click Save to save you changes.
2. Click Add to add an NTP server to be use. You have to provide its IP address.
Optionally you can check Preferred to prefer time information received from this server.
Use to edit, or to delete an existing entry. Your changes will be applied
after selecting Apply Configuration .
2005-2008
c Comdasys AG 57
3.2 Network
Figure 3.21: Adding an NTP Server
2005-2008
c Comdasys AG 58
3.2 Network
! Comdasys uses full NTP4 which can cause trouble when trying to use the NTP
service running on Windows Server 2003 (w32time) as a clock source. The w32time service
has a few known issues which can cause the NTP server on Comdasys products to not
synchronize correctly with it while SNTP clients can often successfully get their time from
the Windows Server 2003. The problem is that SNTP as used in some SIP phones and
Windows clients is a stripped-down version of NTP which is less reliable and less accurate
so it looks like the Windows Server 2003 is running correctly while in fact not being correctly
set up to serve as a reliable NTP clock source. It’s essential that the Windows Server 2003
itself is correctly synchronized against a reliable clock source; the internal system clock is
not sufficient. For more information about configuring w32time see the MicroSoft knowledge
base entry 816042.
2005-2008
c Comdasys AG 59
3.2 Network
3.2.11 VRRP
VRRP is usually used for redundancy purposes in the Convergence. There are different types
of redundancy that depend on the exact scenario. What VRRP offers is the possibility to have
two Convergenceshare a virtual IP address where only one of them will be active at any point
in time.
In the FMC case, setting up VRRP however is not enough. You need to use it in conjunction
with the Database Synchronization feature. Please refer to ?? for more information on this.
Virtual Router Redundancy Protocol (VRRP) is a non-proprietary redundancy protocol de-
scribed in RFC 2338 designed to increase the availability of the default gateway servicing
hosts on the same subnet. This increased reliability is achieved by advertising a ”virtual
router” (an abstract representation of master and backup routers acting as a group) as a de-
fault gateway to the host(s) instead of one physical router. Two or more physical routers are
then configured to stand for the virtual router, with only one doing the actual routing at any
given time. If the current physical router that is routing the data on behalf of the virtual router
fails, an arrangement is made for another physical router to automatically replace it. The phys-
ical router that is currently forwarding data on behalf of the virtual router is called the master
router. Physical routers standing by to take over from the master router in case something
goes wrong are called backup routers.
VRRP is primarily intended to provide redundancy between two Convergence products, but
it can also be used in conjunction with any router providing this functionality such as Cisco,
Huawei, Juniper and others.
VRRP specifies an election protocol to provide the virtual router function described earlier. All
protocol messaging is performed using IP multicast datagrams, thus the protocol can operate
over a variety of multiaccess LAN technologies supporting IP multicast. Each VRRP virtual
router has a single well-known MAC address allocated to it. This document currently only
details the mapping to networks using the IEEE 802 48-bit MAC address. The virtual router
MAC address is used as the source in all periodic VRRP messages sent by the Master router
to enable bridge learning in an extended LAN.
A virtual router is defined by its virtual router identifier (VSID) and a set of IP addresses. A
VRRP router may associate a virtual router with its real addresses on an interface, and may
also be configured with additional virtual router mappings and priority for virtual routers it is
willing to backup. The mapping between VSID and addresses must be coordinated among all
VRRP routers on a LAN.
To minimize network traffic, only the Master for each virtual router sends periodic VRRP Ad-
vertisement messages. A Backup router will not attempt to pre-empt the Master unless it
has higher priority. This eliminates service disruption unless a more preferred path becomes
available. It’s also possible to administratively prohibit all preemption attempts. The only ex-
ception is that a VRRP router will always become Master of any virtual router associated with
addresses it owns. If the Master becomes unavailable then the highest priority Backup will
2005-2008
c Comdasys AG 60
3.2 Network
transition to Master after a short delay, providing a controlled transition of the virtual router
responsibility with minimal service interruption.
The VRRP protocol design provides rapid transition from Backup to Master to minimize ser-
vice interruption, and incorporates optimizations that reduce protocol complexity while guar-
anteeing controlled Master transition for typical operational scenarios. The optimizations re-
sult in an election protocol with minimal runtime state requirements, minimal active protocol
states, and a single message type and sender.The expected duration of Master election (from
the pool of backup routers) in case of a failure is quite small ( ¡¡ 1 second ).
Figure 3.22: VRRP Configuration
Configuration of VRRP
1. In order to add a virtual server you need to use the Add button. Use to
edit, or to delete an existing entry.
2. Specify the Interface that this VRRP virtual address should be assigned on.
3. Set the VSID for the virtual service identifcation. VRRP allows you to define groups
of virtual servers / routers that can provide redundancy for each other. This must be a
number, and this number must be unique for the group of routers you want to provide
redundancy for.
2005-2008
c Comdasys AG 61
3.3 VPN
4. The Priority field specifies the sending VRRP router’s priority for the virtual router.
Higher values equal higher priority. The priority must be between 0 and 255 where
these extrema have special meaning as described below.
The priority value for the VRRP router that owns the IP address(es) associated with the
virtual router MUST be 255 (decimal).
VRRP routers backing up a virtual router MUST use priority values between 1-254
(decimal). The default priority value for VRRP routers backing up a virtual router is 100
(decimal).
The priority value zero (0) has special meaning indicating that the current Master has
stopped participating in VRRP. This is used to trigger Backup routers to quickly transi-
tion to Master without having to wait for the current Master to timeout.
5. Provide the IP address. This is the virtual IP address that should be used for this
Virtual Server. Note that you have to set this exact IP address on all devices with the
same VSID in the same network segement.
6. Click Save to save your changes. Your changes will be applied after selecting
! Note that whenever the Master in a VRRP group comes back up, it will immediately
assume the virtual IP address configured here. This can have undesired effects because
any open session (e.g. SSH) to the currently active node will immediately break as soon as
the master comes back up. This behavior however can differ when using VRRP to provide
redundancy e.g. for the FMC services on the Convergenceİn those cases the VRRP master
will only brought back up, once it is save to do so. This means as soon as there are no more
voice calls active on the slave, but after 4 hours at the very latest. Also see ??
3.3 VPN
3.3.1 Certificates
This menu item is used for the administration of X.509 certificates which can be used for
both IPsec connections and OpenVPN connections. Note that it is necessary to have such a
certificate in place before creating a VPN connection using certificates.
You have to differentiate between plain certificates, containing a public key (signed by a Cer-
tification authority or self-signed), and complete certificate-key pairs, containing a public key
and the matching private key.
Before using certificates for VPN tunnels, there are several steps to be taken:
2005-2008
c Comdasys AG 62
3.3 VPN
Figure 3.23: Certificate management
1. Creation of a self-signed or officially signed (i.e. signed by an offical certification author-

ity) X.509 certificate-key pair.
2. Distribution of the certificate (not the key!) to all VPN remote stations.
3. Creation of a X.509 certificate-key pair for every VPN tunnel terminal station and signing
them using the CA-key.
4. Distribution of the certificate-key pairs to all VPN terminal stations.
For the setup of a VPN tunnel between two Convergences this means in detail:
1. Login to one of the two Convergences (call it Box A) (see Command Line Guide).
2. Execute the script /etc/ssl/mkCAcert.sh to create a self-signed CA cerificate-key
pair. The certificate and the key are automatically saved in the appropriate location.
Example:
/etc/ssl/mkCAcert.sh "RootCA company" "/CN=Root-CA/O=company/C=DE"
3. Download the CA certificate onto the local PC.
4. Login to the web interface of Box A and select the menu item Certificates. The CA
certificate that has just been created is shown in the list of installed CA certificates.
Furthermore, a form is shown below in which a new X.509 certificate can be created.
2005-2008
c Comdasys AG 63
3.3 VPN
5. In this form, a certificate-key pair for each Convergence (Box A and Box B) has to be
created. Thereby at least Common name, Company/Organisation and Country must
be entered. Click on Create certificate .
6. Download the certificate-key pair for Box B onto the local PC.
7. Login to the web interface of Box B and select the menu item Certificates.
8. Upload the CA certificate previously saved on your local PC (see step 3).
9. Upload the X.509 certificate-key pair saved on your local PC (see step 6).
After you have finished all these tasks, the certificates needed for the connection setup are
available on both Convergences.
On the menu page Certificates you will find the following forms:
• Installed CA certificates
• Installed X.509 certificates (i.e. certificate-key pairs)
• Create X.509 certificate (only if a private CA key is present on the Convergence, see
step 2 above)
2005-2008
c Comdasys AG 64
3.3 VPN
Managing CA certificates
CA certificates (i.e. root certificates) are needed to create and to verify X.509 certificates.
To ensure proper authentication, the CA certificates stored on all VPN partner hosts must be
the same.
In this form, CA certificates can be imported, exported or deleted. For the creation of a CA
certificate the script mkCAcert.sh is provided on the Convergence. It is executed in the
command line mode. This script creates two files - a private CA key and a public certificate.
You can of course also use third party tools for creating these certificates, or use existing
ones.
If the certificate was directly created on the Convergence, it can be exported by clicking on
on the right side of the listed certificate. After that, it can be distributed to all other VPN
partners.
All these partners can - if they are also Convergence appliances - import the CA certificate
here.
Managing X.509 certificates

X.509 certificates are used by the Convergence when performing the authentication of VPN
connections. To ensure proper authentication, the X.509 certificates of all VPN partners must
be signed with the same CA key.
X.509 certificates can be imported, exported and deleted in this part of the menu. X.509
certificates can be created within this menu page in case a CA key is available on the Con-
vergence (see next subsection).
Creating X.509 certificates

This part of the menu is only available if there is a complete CA certificate-key pair present on
the Convergence (i.e. that it has been created with mkCAcert.sh). Normally this needs to
be done only once within an organization.
For the creation of the X.509 certificate at least Common name, Company/Organisation
and Country must be entered as information.
The Common name should name the object (e.g. computer, network, campus) to be pro-
tected by the Convergence and for which the certificate is being created.
After creating the certificate, it is available in the list of the installed certificates. It can now be
used for the configuration of VPN connections.
2005-2008
c Comdasys AG 65
3.3 VPN
3.3.2 OpenVPN shared secrets
OpenVPN shared secrets are simple shared secrets protecting an OpenVPN connection
without the need of using certificates. This is a very simple, secure, and effective way if you
are with a small organization that only has to setup a few VPN tunnels. It is necessary to
create a shared secret before setting up the first VPN connection.
An OpenVPN shared secret file is created on the first Convergence involved. Thereafter it is
beeing copied to the local PC via the web browser from where it is being uploaded to a second
Convergence involved. You should use separate shared keys for each VPN connection to
improve security.
All these steps are taken in this menu:
Figure 3.24: OpenVPN Shared Secret Files
The list Current shared secret files contains all local OpenVPN shared secret files present.
They can be exported by clicking on or can be deleted by clicking on .
Adding a shared secret file

1. Provide a user-defined name and click on Create new file . The new OpenVPN
shared secret file is being created containing a random encryption key.
2005-2008
c Comdasys AG 66
3.3 VPN
2. Alternatively, click on Browse and select an existing OpenVPN shared secret file
on the local PC (previously created by a different Convergence ). Click Load file to
upload the file.
3.3.3 Connections
In this menu the connection information of all configured VPN tunnels to remote hosts (other
Convergences or third party products) is managed.
The list shown on this page contains all VPN tunnels configured so far.
Figure 3.25: Managing VPN connections
The active status ”LED” indicates whether the connection is active or inactive. Connections
can be deactivated and activated by clicking on the status ”LED”.
If the connection is inactive the ”LED” will appear so, too . Use to edit, or to
delete an existing entry.
2005-2008
c Comdasys AG 67
3.3 VPN
! Unlike OpenVPN that supports both certificates and shared secrets in any combina-
tion with static and dynamic IP addresses, IPsec has two limitations pertaining to the use
of shared secrets:
1. One of the two terminal stations needs to have a static IP address.
2. The terminal station using a dynamic IP address cannot be accessed via a dynamic
DNS name.
Setting up a new IPsec connection

1. Click on New IPsec Connection and provide configuration details as follows.
2. Connection name
Custom name of the new connection
3. Partner IP, Partner name, Partner unknown
With these radio-buttons, you can define how the VPN remote host can be located: via
its IP address or its name. If the remote station uses dynamic IP addresses, the option
Partner unknown is right one to choose.
When configuring an IPSEC VPN connection, only one partner should use dynamic IP
addresses.
If both partners are using dynamic IP addresses (e.g. dial-in, ADSL) it is recommended
to use OpenVPN in conjuction with a service for dynamic DNS (see ??).
4. Partner network
The local network behind the VPN remote host. This network will be protected by IPsec
and can be accessed only through the tunnel.
5. VPN is locally connected to
This allows you to choose whether the whole network behind the LAN interface 1 is
allowed to use the IPsec connection or just a part of the network (defined IP range).
You can also restrict the use of a VPN tunnel to just a single host with this function.
6. Use compression
Checkbox for enabling or disabling compression.
7. Authentication
IPsec can use two methods for authentication of VPN connections: certificates or com-
mon passwords (Shared secrets).
2005-2008
c Comdasys AG 68
3.3 VPN
•X.509 certificate
When choosing the authentication via X.509 certificates, both partners must have
X.509 certificates signed with the same CA key. Furthermore, the corresponding
CA certificate must be available on both partner stations.
The procedure to ensure this, is described in section ??. You should however have
a basic understanding of X.509 certificates when trying to set up such a connection
in order to avoid potential security pitfalls.
For the configuration of an IPsec connection, the corresponding certificate is se-
lected and the label of the certificate stored on the remote station is typed in. This
label can be looked up in the web interface of the remote station in the menu
Certificates if it’s a Convergence (see section ??). If you are using third party
equipment, you have to refer to that documentation for how to handle certificates.
•Shared secret
When choosing the authentication via a Shared secret, simply use the same pass-
word and type it in on both partner stations.
i When using Shared secrets for authentication, both partners have to use either static
IP addresses or names. The option Partner unknown is not applicable in this case!
Setting up a new OpenVPN connection

1. Click on New OpenVPN Connection and provide configuration details as follows.
2. Connection name
A custom name for the new connection.
3. Partner IP, Partner name, Partner unknown
With these radio-buttons, you can define how the VPN remote host can be located: via
its IP address or its name. If the remote station uses dynamic IP addresses, the option
"Partner unknown" is right one to choose.
When configuring a VPN connection, only one partner may have the parameter Partner
unknown. If both partners use dynamic IP addresses (e.g. dial-in, ADSL), a name has
to be assigned to at least one of them by using a dynamic DNS service (see section
??).
4. Partner network
The local network behind the VPN remote host. This network will be protected by
OpenVPN. This is the network that can be accessed through the VPN tunnel.
2005-2008
c Comdasys AG 69
3.3 VPN
Figure 3.26: New IPsec Connection
2005-2008
c Comdasys AG 70
3.3 VPN
5. Transfer net
Enter two IP addresses that are to be used internally for transferring the VPN packets.
This transfer network can be used for traffic shaping or firewalling. It is important that
both addresses entered here lie within a single network. It is also important to have
matching entries on both sides of the VPN tunnel. The addresses of the Transfer Net-
work have to be reciprocally identical for two VPN hosts - i.e. the local IP address of
one partner has to be the remote IP address of the other.
6. OpenVPN port
OpenVPN works port-based. That means every OpenVPN connection must have a
unique port number. All packets for this connection will then be exchanged via this port.
This port number must be the same on both connection partners.
7. Authentication
OpenVPN can use two methods of authentication for VPN connections: certificates, or
a common password file.
(OpenVPN Shared secret).
•X.509 certificate
When choosing the authentication via X.509 certificates, both partners must have
X.509 certificates signed with the same CA key. Furthermore, the corresponding
CA certificate must be available on both partner stations.
The procedure to ensure this situation is described in the IPSEC section.
For the setup of an OpenVPN connection using certificate authentication, one of
the connection partners has to be configured as TLS server and the other one as
TLS client.
•Shared secret
When choosing the authentication via a Shared secret, the same OpenVPN Shared
secret file simply has to be selected on both partners (see section ??).
3.3.4 L2TP server
L2TP allows you to easily connect client hosts via VPN. It is hence mostly used for Roadwar-
rior scenarios. Using L2TP for such configurations is especially comfortable for clients running
MS Windows 2000 or Windows XP as this type of connection is already part of the standard
network connection schema of those operating systems. In this menu the server-side config-
uration is set. Besides this the login-data for each user and PC is entered.
2005-2008
c Comdasys AG 71
3.3 VPN
Figure 3.27: New OpenVPN connection
Configuring L2TP server

1. L2TP active
With this checkbox, L2TP can be activated and deactivated without needing to reenter
all data. This can be convenient to temporarily shut down L2TP service for some time.
2. L2TP interface address
3. L2TP netmask
4. IP range for clients (from and to address)
These four parameters define the L2TP access network on the Convergence. The IP
range has to be within the subnet defined by the netmask. This subnet must not occur
anywhere else within the IP range of the clients. You should hence use a private IP
address range that is not in use for any interface or VPN tunnel.
5. DNS server for clients
6. WINS server for clients
With these two parameters, a DNS server and/or a WINS server can be assigned to
clients connecting via L2TP. Using this Option, the clients can access internal resources
via name instead of IP address.
2005-2008
c Comdasys AG 72
3.3 VPN
7. Click Save to save the parameters. Your changes will be applied after selecting
Figure 3.28: Configuring the L2TP server
Adding a new L2TP user

1. To create a new user account click on New user and provide configuration details
as follows (compare figure ??).
2. Login-data
To setup a new user, the username, password and the assigned IP address (must be
part of the previously defined L2TP subnet) have to be entered. Entering the IP address
is optional, but assigning a fixed IP address to a specified user is highly recommended
since it enables individually restricting the access with the help of the firewall.
3. IPsec authentication
When establishing a connection to computers running Windows 2000/Windows XP,
the L2TP packets are encrypted with IPsec. Corresponding to normal IPsec con-
nections both Preshared secrets and X.509 certificates can be used. There are also
L2TP/IPSEC client available for other platforms as for example PocketPC. Please refer
to the documentation of your device for more information.
2005-2008
c Comdasys AG 73
3.3 VPN
Figure 3.29: Adding a new L2TP user
2005-2008
c Comdasys AG 74
3.4 Security
Windows XP supports both possibilities whereas Windows 2000 only supports X.509
certificates.
4. X.509 certificate
If you select X.509 Certificate in the menu IPsec authentication the X.509 cer-
tificates on both sides have to be signed by the same CA key. Furthermore, the cor-
responding CA certificate must be available on the client computer. Please refer to
your Windows documentation on how to handle certificates on Windows systems. Un-
less you habe special tools simplifying the process, you will have to use the Microsoft
Management Console.
5. Preshared secret
If you select Shared secret in the menu IPsec authentication, a password has to
be entered that must be the same on all clients running Windows XP connecting to
this Convergence. The problem is that authentication in IPSEC is done via the remote
IP address. Since this address is arbitrary in our case, we cannot identify the remote
computer at the IPSEC level. Therefore, all computers have to authenticate with the
same shared secret.
6. Click Save to save account data. Your changes will be applied after selecting Apply
configuration.
3.4 Security
3.4.1 Security level
On this page, the fundamental level of security that shall be used by the Convergence is
defined. Security as defined here only applies to the accessibility of the Convergence and the
firewall settings.
By selecting Highest security, access to the Convergence is limited to the permitted
administration ports and the defined VPN tunnels. Particularly it is not possible to access
the Internet via the Convergence, to set up own firewall rules or Port-Forwardings using this
setting.
We recommend using this setting if the location secured by the Convergence shall have ac-
cess to the Internet only via a VPN tunnel connected to the remote partner-network. This can
be used for very restrictive branch connectivity solutions.
The option User defined allows you to make significantly more advanced and flexible con-
figurations. In particular, access to the internet can be granted, ports can be forwarded to
certain computers connected to the LAN and your own custom firewall rules can be estab-
lished.
2005-2008
c Comdasys AG 75
3.4 Security
Figure 3.30: Adjusting the security level
The configuration matrix ”Open administration ports via” enables the exact definition of
the allowed locations from which configuration access shall be enabled. The opening of the
administrative ports can be done on a per interface basis.
i The Administration through the LAN1 interface is enabled by default. It is recom-

mended that this access is kept open because you can essentially lock yourself out of the
WebGUI by disabling this.
i Administration on the WAN interface should only be enabled if it is really necessary.

In conjunction with an insecure password, this could put the device in jeopardy for attacks.
In order to increase the security, only the SSH connection could be openend. It is possible
to tunnel HTTPS access through SSH.
"for HTTPS" allows and denies configuration via web browser; "for SSH" allows and
denies access via command line using the SSH protocol.
Attention: The menu items Firewall and Port forwarding are only available if the security
option User defined is selected. The corresponding settings require intermediate knowl-
edge of the TCP/IP protocol.
By switching the security option from User defined to Highest security, firewall rules
and Port-Forwardings that may already have been configured are deactivated but not deleted.
By switching back to User defined they are available again.
2005-2008
c Comdasys AG 76
3.4 Security
3.4.2 Firewall
The firewall of the Convergence can be configured in two ways (also combined):
3.4.2.1 Activate Basic Services
It is possible to select the most important services needed - all necessary firewall rules are
created automatically. Note that the first section deals with outbound connections. You can
also choose to permit all outbound connections.
The more security relevant part however are the inbound connections. By default, these are
disabled on the WAN interface. You can selectively enable the protocols. Note that you need
at least one signalling protocol (either TLS or SIP) plus the media stream protocol (RTP) for a
working setup.
3.4.2.2 Custom Rules
Besides this, it is possible to configure your own, very detailed rules. This way of configuration
is recommended to be used only by experienced users and administrators. Wrong firewall
rules can cause network applications to stop working. People changing these settings should
hence know what they are doing.
3.4.2.3 Activate basic services
The basic services are defined for data traffic between two network interfaces. Thereby,
different outgoing services (i.e. from the internal interface to the Internet) can be allowed just
as data transfer between the two local networks. Select the checkboxes of the appropriate
basic services that shall be allowed for incoming and outgoing requests. By selecting the
checkbox allow all outgoing connections, all ports for the basic services listed are opened.
These options are only shown for the secondary LAN interface if this interface is configured
(i.e. is not deactivated).
3.4.2.4 Custom Rules
The custom rules of the firewall are executed top-down. By clicking on the arrow-buttons
( and ) you can newly arrange the firewall rules. Registered rules can be edited by
clicking on or can be deleted by clicking on .
Creating a new custom firewall rule

1. Click Create rule at the appropriate position shown in figure ??.
2005-2008
c Comdasys AG 77
3.4 Security
Figure 3.31: Firewall configuration
2005-2008
c Comdasys AG 78
3.4 Security
Figure 3.32: Add a new custom firewall rule
2. Define the rule. Specify Protocol (TCP, UDP, ICMP, other), Interfaces and IP details
that this rule shall match.
3. Choose rule target (Filter policy) in order to specify what should happen to the traffic
this rule applies for.
4. Click Create rule to save your changes. Your changes will be applied after selecting
3.4.3 Port forwarding
Port forwarding allows you to forward incoming data packets that arrive at the Convergence
to a certain computer within the local network. It is being used in conjunction with NAT and
is the only way to directly access a computer connected to the private LAN from the Internet.
Port forwarding is also often described as virtual server functionality.
To reach several computers within the private LAN via the same protocol it is also possible to
change the ports.
Example:
Three computers within the LAN shall be accessed via SSH. SSH normaly uses port 22. But
it’s impossible to reach all three computers via port 22 of the Convergence.
2005-2008
c Comdasys AG 79
3.5 Voice-over-IP
With Port forwarding you can now define that e.g. port 2022 of the Convergence is forwarded
to port 22 of the first computer, port 2023 is forwarded to port 22 of the second computer
and so on. An SSH client connecting to port 2022 of the Convergence would actually be
connected to port 22 of the first computer in the LAN.
Setting a new port forwarding rule

1. Click Add in order to define a new port forwarding rule and specify Local port,
Destination IP, Destination port (compare figure ?? on page ??).
2. Local port is the port that will be provided to be forwarded by the Convergence .
3. Destination IP is the IP address of the internal computer to which the data shall be
forwarded.
4. Destination port it the port of the internal computer to which the data shall be for-
warded.
5. Click Save to save your chages. Your changes will be applied after selecting Apply
configuration.
Figure 3.33: Port forwarding
3.5 Voice-over-IP
3.5.1 Introduction to SIP Proxy and SBC Scenarios
The SIP Proxy in the Convergence can be used in a variety of scenarios. The most frequent
use is as a SIP Proxy in front of another SIP server. In the WebGUI, this can be found under
the Survivability template. For these applications, the WebGUI has been geared towards
2005-2008
c Comdasys AG 80
3.5 Voice-over-IP
telephony applications. When acting in front of another SIP server, it is also possible to limit
the number of permitted sessions based on bandwidth restrictions (Call Admission Control).
The second class of frequently used scenarios is SBC (Session Border Controller) Scenarios.
In these, the Convergence will not only perform SIP signalling interworking, but it will also
perform media handling for any SIP initiated sessions. This feature can be used to achieve
a connection between two networks that do not have a routing connection (as for example
customer premise network and data center network), handle NAT between networks, or pro-
tect a network from the outside world without destroying the ability to have VoIP connectivity.
This can be used to voice enable existing networks that have firewalls to separate segments,
use devices from behind a NAT, as for example some NAT router on the Internet, or facilitate
deployments in hosted scenarios. The Convergence supports three different types of SBC
scenarios, Branch SBC, Cascaded SBC, and Central SBC. The latter is only supported by the
bigger higher end Convergence .
Some variants of the SBC scenarios are the SIP Trunking as well as ENUM. With its ENUM
functionality the Convergence acts as an ENUM lookup gateway and as a Session Border
Controller controlling calls coming in over the Internet. The SIP Trunking is a derived SBC
scenario where you only have a single logical connection (that could of course consist of
many individual SIP sessions) between an IP PBX and a Trunking Server usually offered by a
carrier. This setup replaces a local PSTN gateway on the customer premise, and is hence a
step towards a full IP-only customer premise connectivity.
Other scenarios include stand-alone functionality where the Convergence Appliance will act
as a small SIP Server forwarding certain sessions to another server or to a SIP gateway.
It is also possible to configure custom scenarios with the SIP Proxy. This however is beyond
the scope of this manual. Check the Command Line Reference for more information on
that.
3.5.2 Scenario Selection
Before any parameters for the SIP Proxy can be configured, you need to choose among
the Survivability, Branch SBC, Cascaded SBC, SBC, SIP Trunking, Standalone, ENUM, or
Custom template configurations. For all types of branch office scenarios without the need
for media handling, you will most likely want the Survivability Template. The Branch SBC
scenario is suited for branch connectivity scenarios where media handling or NAT traversal is
a requirement. The Cascaded SBC is usually used on the way from a Branch SBC to an IP
PBX to act as a media relay. Both SIP messages as well as media would pass through two
hosts in this scenario. Explaining all usage scenarios would be far beyond the scope of this
manual. You can however find a quick scenario descriptions the each of the sections below.
Select a template and press Select to activate it. You can switch templates without losing
your configured parameters.
2005-2008
c Comdasys AG 81
3.5 Voice-over-IP
3.5.3 Survivability and Call Admission Control Template
The typical survivability scenario is explained rather quickly. Assume having a small/medium
office with some WAN link. The central SIP server usually used for VoIP telephony, and hence
being an IP PBX, is located in the datacenter, at the other side of this WAN link. The WAN
link can either be an Internet line or some leased-line internal to the datacenter network. In
the latter case, using a single interface of the Convergence can be enough. The interface
configuration has a significant impact on the parameters you need to set for the SIP Proxy
here. Both scenarios (single and multiple interface) are mentioned in the appropriate places
in the following.
The Survivability scenario is to provide telephony functionality to the small/medium office even
if the central SIP server is unavailable due to a WAN failure. In such case, the Convergence
will take over the functionality of the SIP server. Once the SIP server is reachable again, the
operation returns to normal.
The current status of the product can be seen in the Status Page described in ??. Beside
the VoIP Router Status display, you will see the text Survivability Mode, if the product has
detected a failure of the central SIP server. Once operation returns to normal, this text display
will disappear again.
The second side to this scenario is Call Admission Control. Since all SIP messages are routed
through the appliance, it can freely decide on how to act upon certain requests. Call Admis-
sion Control is about denying certain requests based on the defined bandwidth constraints.
This mechanism is essential for providing QoS for real-time communications.
3.5.3.1 Survivability Parameter
• Survivability Basic Settings
– Own number (figure ?? on page ??)

The Own Number field is intended for entering the phone number of the branch
office without the extension. Usually, the following scenario is assumed. Under
normal operations, the phones can be reached via two different numbers, their
complete PSTN number and internally by simply dialing an extension. An example
will illustrate this. Let us assume that the branch office can be reached via the ”+49
89 4711” from the outside. Internally you have the extensions ”100” and ”110”.
This means that from the PSTN you can reach the phones by dialing ”+49 89 4711
100”. It is your choice whether you use complete E.164 numbers here or work with
e.g. area code only. Internally, the phones can be reached via their full number
or via their extension only. The registration with the SIP server and the SIP Proxy
in our case here is performed with the full number. This comes naturally since
the central SIP server by handling multiple branches can have many phones with
the extension ”100”. By knowing the Own Number of the branch, the Proxy upon
receiving a call for an extension in Survivability mode can now prepend the number
2005-2008
c Comdasys AG 82
3.5 Voice-over-IP
of the branch and hence find the phone in the Registration database. This means
that extension dialing still works in survivability mode.
If you do not have such a scenario where you want to call the internal phones with
a shortcut, simply leave this field blank.
– Prefix number (figure ?? on page ??)
The Prefix number describes the prefix the number has if it is an outgoing call.
Usually, this is just a simple digit as for example a ”0” for getting an outgoing line.
Expressions for this can however be more complex than that. You can enter ar-
bitrary regular expressions here. Only numbers having the correct prefix will be
routed to the gateway in the survivability case. This prevents unavailable internal
numbers from ending up in the PSTN and going somewhere unintentionally.
– PBX Address (figure ?? on page ??)
As we have already described above, in Survivability Mode, the Convergence proxy
only acts if the central PBX is not reachable. This parameter is for entering the
address of the central PBX. It can either be entered in the form of an IP address,
a host name or even as a DNS SRV address. Note that entering a DNS or DNS
SRV name can introduce more latency in forwarding messages to the IP PBX since
the hostname has to be looked up first. You also have to note that if you enter a
DNS name, the DNS server has to be available upon a WAN failure or any other
conditions the Survivability mode is intended to work in.
– SIP Transmit Type (figure ?? on page ??)
The SIP Transmit Type parameter is the transmission type the proxy uses to contact
the central SIP server. The Convergence supports 3 different SIP transport modes,
UDP, TCP, and the encrypted TLS variant. The type to use depends first and
foremost on the used SIP server. The TCP and UDP types are straightforward and
just specify the used protocol type.
The only type requiring further explanation is TLS. For TLS additional things like
the encryption keys are required. Since this is a very advanced topic, this cannot
be configured via the WebGUI as of yet. The Convergence will generate TLS
keys automatically that can be downloaded for the use in Servers/Phones via SCP.
Please consult the Command Line Reference for more information on how to do
that.
– Timeout (figure ?? on page ??)
The Timeout value is one of the most central parameters in the Survivability sce-
nario. This timeout value will be used to determine whether the IP PBX is online
or not. It is the maximum time the proxy will wait for a response upon a request
before falling to survivability mode. Note that this mode will not lead to the fact that
all SIP messages will be delayed by 2 seconds. There is a background checking
algorithm running that will decide whether the IP PBX is available or not. Usual
2005-2008
c Comdasys AG 83
3.5 Voice-over-IP
values for this timeout parameter range between 2-4 seconds. It will be used for
both the PBX as well as the 2. Node to determine their availability.
– Ignore Gateway during Register (figure ?? on page ??)
This feature is only required if the Convergence is utilized with topology hiding
which will prompt it to change the contact headers of SIP messages. This will be
the case with the Force Return Route and Multiport Mapping features. In these
cases, it might be desirable to have the product handle the messages from some
local voice gateway, but not to perform contact header manipulation on them. This
should be the case whenever there is a routing connection from the central SIP
server to the branch voice gateway in such a scenario. Such a routing connection
can be implemented in various ways, as for example port forwarding. Some SIP
servers also require this because they treat such gateways unlike regular clients.
– Enable Hunting (figure ?? on page ??)
This feature only applies to scenarios where there are multiple fallback gateways
present. In that case it might be desirable that a gateway hunting is performed
between these multiple gateways. The redirection causes here are the same ones
that are defined between the IP PBX and the first gateway. This can be used for
a variety of scenarios as for example stacking gateways or having gateways in
multiple locations and applying Call Admission Control Parameters to them. The
decision parameters for the gateway hunting are configured with the gateways. If
this parameter is not set, only the first gateway will be considered in survivability
mode or with CAC redirection.
• Survivability and Features
– CFW / Forwarding Target (figure ?? on page ??)

∗ CFW in Survivability Mode
Enter a number or a URI here that should be mapped to the target in surviv-
ability mode. It is possible to use regular expressions here, and everything will
be interpreted as such.
∗ Forwarding Target
This is the forwarding target, hence the number of a really registered phone. If
you have multiple phones registered with the same number, the proxy will per-
form SIP forking as per RFC 3261. The forwarding and number mapping will
only be done in survivability mode. The normal operation will not be impacted
at all by this option.
– Map to Office Prefix (figure ?? on page ??)
This feature is used for both survivability and call admission control scenarios. It
is most often used in pure telephony scenarios where the user part of a SIP URI
is always a number. The Map to office prefix function consists of two fields that
2005-2008
c Comdasys AG 84
3.5 Voice-over-IP
Figure 3.34: Survivability: Basic Settings
must both be filled in. The Short Prefix is a number that must match an incoming
request. This is probably best explained by an example:
Assume that you have a number range 123456789xx for the phones connected
to the Convergence where xx stands for an arbitrary extension. Since 123456789
is a very long prefix, there might be additional prefixes configured in your central
softswitch, that you also want to be considered correctly concerning survivability
and CAC. So let us assume you have a second prefix configured, say 58000xx
where the xx is the same suffix as above. The Convergence will then map this
short prefix to the long version above, and only then perform all checks concerning
CAC and survivability.
∗ Short Prefix
Prefix that has to match an incoming request. If such a match is found, the
Convergence will map this prefix to the long office prefix as described below.
∗ Map to Office Prefix
Long office prefix that the above described short one will be mapped to. This
Office Prefix including the extension should then match an actually registered
phone to make the survivability function work properly. It could however also
2005-2008
c Comdasys AG 85
3.5 Voice-over-IP
be mapped to a call that should be routed out through a gateway in the surviv-
ability case.
– Class of Service (figure ?? on page ??)
Sometimes it is usefull to set some restrictions to some phone numbers. With the
Class of Service enhancements parameters it is possible to deny or allow some
target numbers for special phones. For example you can allow or deny national or
international calls or even special numbers.
∗ Source
This parameter should contain the phone number of the source phone.
∗ Destination
Put in here the destination number that is denied or allowed. For example, if
destination contains 00, all phone numbers beginning with 00 are allowed or
denied depending on the policy parameter
∗ Policy
The policy parameter can only contain the values allow or deny. If this param-
eter is set to deny, the call from the source number to the destination number
is blocked.
Figure 3.35: Survivability: Basic Settings
2005-2008
c Comdasys AG 86
3.5 Voice-over-IP
• Sip Settings
– Enable B2BUA handling (figure ?? on page ??)

This function is necessary for gateways that do not properly support SIP forking.
Checking this box will make the Convergence behave like a B2BUA towards the
voice gateway in survivability mode. This means that for each session from and
to the gateway, its own Call ID will be assigned. Towards the SIP endpoints, the
Convergence will continue to behave as a SIP Proxy. Usually, this function will not
be necessary if you have no forking. Forking is necessary if you have multiple SIP
endpoints with the same SIP username. This will normally be the case in voice
scenarios where you have multiple SIP endpoints with the same phone number.
This is commonly described as keyset feature or multiline appearance. Incoming
calls in such multiline scenarios sometimes pose difficulties for gateways because
the SIP proxy in the Convergence will fork the request. This will lead to the fact that
multiple SIP responses are forwarded to the gateway which is a problem for some
of them. With the B2BUA feature enabled, the Convergence will terminate this call
and only forward a single response to the gateway.
– Alive check via SIP instead of ICMP ping (figure ?? on page ??)
There are two ways the Convergence supports to check whether the SIP Server
for which we are providing the survivability functionality is monitored. This monitor-
ing can be applied at the network layer (via ICMP messages) or on the application
layer with SIP OPTION requests. The check with pings should work with all servers
as long as the underlying network supports this. This is usually the case except
firewalls on the way, or a packet filter on the server itself prevents the Ping Echo
Reply messages from getting back to the Convergence . Other than that, the pings
will be sent in intervals of around a minute. This interval can be shorter depending
on the amount of SIP messages flowing through the Convergence . The interval
can also vary if there are abnormal negative responses to requests forwarded to
the server. The non-response to a single ICMP message will not lead to the Con-
vergence switching into survivability mode.
Whenever the SIP server supports SIP OPTIONS (please refer to RFC 3261 for
more information on this SIP request type) requests, this should be used for doing
the alive check. It will also enable the Convergence to switch into survivability
mode for situations in which the central SIP server is reachable, but not responding
correctly. Whenever we receive 5xx or 6xx responses from the central server for an
OPTIONS request, the Convergence switches to survivability mode. If no response
is received, a single non-response will not lead to the Convergence switching to
survivability mode.
– Registration Timeout (figure ?? on page ??)
The Registration Timeout value is only used during Survivablility mode. In that
mode, the Convergence will acknowledge incoming Registers and Subscribes from
the IP Phones. These messages will be sent with a default expires value. If this
2005-2008
c Comdasys AG 87
3.5 Voice-over-IP
value is very long, the danger is that upon return to normal operation, the IP PBX
will have lost the registration of many phones. This parameter forces the phones
to use a shorter registration timeout during survivability and hence to register more
often. Once the connectivity comes back, the IP PBX will get reregisters from the
phones in this branch office very rapidly.
– Disable Loose Routing (figure ?? on page ??)
Loose routing is defined in RFC3261 and will make the Convergence route all in
dialog messages the same way that the dialog setup was routed. This however
assumes properly behaving SIP endpoints and a properly behaving SIP servers.
In simple scenarios, where the endpoints are registered to a server, this works
for most endpoints. With a survivability scenario, where the messages are routed
onwards, and where the proxy is on the return route in addition to that, the correct
behavior of loose routing is not guaranteed with all devices. In order to avoid that,
loose routing can be disabled in normal operation (non survivability). If you see
in dialog messages like ACK and BYEs not flowing as expected. A typical sign is
ACKs or BYEs coming from the softswitch being directly returned to it.
– Fix Broken Loose Routing (figure ?? on page ??)
In contrast to the Disable Loose Routing function, the function here will also disable
the loose routing in survivability mode. This should only be necessary for some
broken endpoints with incomplete support for RFC3261. In all other situations,
loose routing should work fine in survivability mode. Enable this feature only if you
really experience problems. Not
– Force Return Route for NOTIFIES (figure ?? on page ??)
While some SIP servers support an outbound proxy feature for addressing SIP
messages to endpoints, they often do not fully implement the feature for additional
messages beyond RFC3261. With this mode of operation, all messages specified
in RFC3261 would be addressed to the endpoint, but sent to the outbound proxy
that then makes the final delivery. While this works well for INVITE, ACK, BYE and
REFER messages, messages like SUBSCRIBE, NOTIFIES, PUBLISH are often
treated differently. This poses a special problem for NOTIFIES beacause they are
sent depending on header fields in the SUBSCRIBE message. Therefore, similar to
the Force Return Route feature, it is specifically possible to have the Convergence
change the Contact information for SUBSCRIBE and NOTIFY requests. This will
lead to the fact, that notify requests are always addressed to the Convergence
acting as a SIP Proxy. Since there is no such thing as a forking for these requests,
it is easily possible to handle them correctly.
– Mask Proxy Domain on Register (figure ?? on page ??)
If set, the Proxy will replace the domain part of the SIP URI of each message
flowing through it with the SIP Domain (IP address or DNS name) of the SIP server.
Some SIP servers have problems accepting SIP messages for multiple domains or
do not do so due to security reasons. Most systems however work effortlessly
2005-2008
c Comdasys AG 88
3.5 Voice-over-IP
without such modifications. Also check any options that your server might offer to
set domains aliases. This parameter should hence only be used if you encounter
problems pertaining to that.
– Preset Record Route (figure ?? on page ??)
The preset record route parameter allows influencing how the record route Header
in the SIP message will be written. The record route header in SIP is for making
sure that all messages belonging to a session go through all servers that were
on the path of the original message. Explained in more detail, this means that
the messages will go through all SIP entities on the way that marked the original
message with a record route field. If the Convergence is only used with a single
interface and a single IP, you can completely disregard this field. If the Convergence
however is used with a WAN and a LAN address, it can be quite significant what
IP address is set in this record route field. By default, the Convergence always
selects the primary IP address of the interface the packet is going out on. In some
scenarios, especially in those involving VPNs and NAT, this can however be the
wrong one. Therefore, it is possible to explicitly configure this address and port to
be used in the record route field. It can also be interesting for scenarios where the
Convergence is being used behind another firewall that performs port forwarding.
In that case, the external IP address and the forwarded port have to be entered
here.
– No Rerouting on (figure ?? on page ??)
The proxy will perform rerouting on a number of replies from the central softswitch.
This is necessary especially in conjunction with CAC. If the proxy receives a nega-
tive reply for a session initiation request, it will try to perform the specified rerouting.
It will not do any rerouting on the responses specified here. The possible response
codes are listed below. Select all by pressing SHIFT and selecting them with a
Cursor key. Alternatively, you can use CTRL + A to select all.
∗ 400 Bad Request
∗ 401 Unauthorized
∗ 402 PaymentRequired
∗ 403 Forbidden
∗ 404 Not Found
∗ 405 Method Not Allowed
∗ 406 Not Acceptable
∗ 408 Request Timeout
∗ 410 Gone
∗ 480 Temporarily Unavailable
2005-2008
c Comdasys AG 89
3.5 Voice-over-IP
∗ 486 Busy Here

∗ 487 Request Terminated
∗ 504 Server Timeout
∗ 603 Decline
∗ 606 Not Acceptable
Figure 3.36: Survivability Sip Settings
• Redundancy (figure ?? on page ??)
– 2. PBX Node
Some IP PBXs / Softswitches support clustering or redundancy through a second
host. There are two ways of implementing this clustering, either transparent, in
which case we do not have to handle anything exlicitly in the branch office, or with
two IP addresses. This field is meant for the latter concept which is frequently
being used if the 2 nodes of a cluster have been spatially separated. In that case
they are available through different WAN links thus increasing the robustness of the
overall solution. If such redundany precautions have been taken in the data center,
the branch equipment must also support this. If this field is set, the Survivability
function of the Convergence will only take over if both the PBX as well as the 2.
Node have failed. If only the first node has failed, messages will automatically be
forwarded to the second node.
2005-2008
c Comdasys AG 90
3.5 Voice-over-IP
– PBX Alias
The Survivability and Call Admission Control function will only be enabled for SIP
messages that fall into the domain this SIP proxy is responsible for. Please also
refer to the Domains parameter. For correctly determining the direction of the mes-
sages flowing, the proxy must also be aware what messages are coming from the
Server side, and which ones come from the client side. To correctly determine this,
the proxy must be able to know what messages are coming from the PBX. These
can be messages coming from the IP address of the PBX and 2. Node PBX pa-
rameters, but especially clustered or load balanced servers could have messages
coming from other IP addresses also. So it is necessary to configure all source
IP addresses or host names from where SIP messages of the PBX can originate
from.
– Failover Server Replication
This parameter will replicate all Register messages to a second backup server.
This can either be a second Convergence operated in redundancy mode or any
other type of SIP server that can be used as a backup. The usual scenario is that
of a second Convergence being used in this mode.
Figure 3.37: Survivability Redundancy
• Diagnostics (figure ?? on page ??)
2005-2008
c Comdasys AG 91
3.5 Voice-over-IP
– Debug
This switch will make the SIP proxy write debug messages to the system log. These
can either be seen in CLI mode on the Convergence, or on the specified logging
server. See the logging parameters in this document or refer to the Command Line
Guide for more documentation on how to have a look at the logging.
Figure 3.38: Survivability Diagnostics
• RTP Bind Address

This field specifies the address where the media handler is sending /listening. Usually,
this setting is unecessary because the appropriate interface and IP address is deter-
mined automatically based on infomration obtained from the routing stack. This how-
ever can sometimes be impossible especially when working with virtual interfaces, or
multiple IP addresses per interface. If you see that RTP packets are not coming from
the interface or IP address you expect them to come from, please try explicitly setting
this field. It should be noted that this field is only relevant if the media handling through
the Force RTP stream transition feature is enabled.
• Multiport Mapping (Caution: Do not use unless explictly needed)
Multiport mapping makes the Convergence assign a unique port for each device con-
nected behind it. It will always use this unique port number when communicating with
the SIP server. The Convergence will also change all related fields in SIP messages.
The SIP server will hence only see the contact information of the Convergence with
2005-2008
c Comdasys AG 92
3.5 Voice-over-IP
an individual port for each device. This mode of operation is usually not required and
is only necessary for special scenarios involving SIP forking (multiple devices with the
same username part of the URI), where the requests already arrive forked from the
server. If in such sceanrios, the Force Return Route feature is used to change the con-
tact parts of the SIP messages, these would be forked again by the Convergence . It
is then necessary to utilize this feature to put the Convergence in a situation where it
can uniquely determine where to send the already forked request. The destination port
information where the SIP server sent the message is then used to correctly direct the
message to the right SIP endpoint. It should again be reiterated that this type of mes-
sage routing somewhat bends the conventions of SIP, but it is required for the described
scenario. There is one notable exception. If the PBX is able to correctly support an
outbound proxy feature, where the forked request is addressed to the endpoint’s URI
but sent to the Convergence neither the Force Return Route nor the multiport feature
are required. This is the most desirable configuration and should be used whenever
possible.
• Enable Dual Registration Support
This will open a second SIP signalling port on port 5080. Some SIP phones have built-
in functions for implementing survivability functionality. It is then possible to provision
a second SIP server the phone should go to in case the first server stops responding.
The Convergence can emulate two different servers, where the first one would stop
responding to Registration requests of such phones in Survivability mode. This is feature
should not be necessary, since the Convergence implements a transparent survivability
function. However, some phones need this dual registration approach to realize when
they entered survivability mode. This is necessary to adapt the feature handling to the
reduced set available in survivability mode.
• Enable Call FW in Surv.
This feature is to enable processing of SIP 302 response messages in survivability
mode. If all your phones and gateways are able to handle such responses themselves,
you can leave this checkbox disabled and still have the functionality. While there are
many phones that support this feature, gateways mostly do not. Therefore, if you want
to have call forwarding functionality in conjunction with incoming calls through a gate-
way, you should activcate this feature. When activated, the Convergence will intercept
any SIP 302 response message and translate it into a new session with the forwarding
target specified in the SIP response. In that case, the Convergence would behave like
a normal SIP server supporting call forwarding features.
3.5.3.2 Call Admission Controll Parameters
The Convergence can use its built-in bandwidth management capabilities to influence the SIP
signalling decisions. These SIP signalling decisions can both be influenced for packets com-
ing from the phone as well as coming from the central SIP server. Real-time traffic can be
2005-2008
c Comdasys AG 93
3.5 Voice-over-IP
classified and measured while it is flowing through the box (refer to the Bandwidth Manage-
ment Section ?? for more details). The limits for the different traffic bandwidth classes will
be used as decision basis for either permitting or denying the establishment of new SIP ses-
sions. Based on the information obtained from measuring the traffic, Call Admission checks
against predefined policies can now be made. These checks are enforced by the SIP Proxy.
In case of a limit violation that would mean that a SIP 606 Not Acceptable message would
be signalled to the central SIP server or the SIP endpoint. There are many variations to the
parameters and also to the enforcement. Instead of signalling the Not Acceptable directly to
the endpoint, the session can also be just marked (by modifiying the request URI) to let the
central SIP server do the enforcement. The central server can then decide to e.g. signal a
Busy, or it can choose an alternative route (e.g. through a locally present PSTN gateway)to
avoid a network congestion.
Figure 3.39: Survivability and Call Admission Control (CAC Parameters continued)
• CAC
The CAC parameter indicates whether Call Admission Control shall be performed or
not. Uncheck this in order to completely disable this feature.
• CAC check if from IP network (strict checking)
This parameter should be checked if there is a local PSTN in the branch office. If this pa-
rameter is not checked, the Convergence will assume that all Calls to and from non-local
2005-2008
c Comdasys AG 94
3.5 Voice-over-IP
destinations will go over the bottleneck link and hence require Call Admission Control
(of course only if all other parameters like Link etc. match). This would however mean,
that for a Call coming in over the local gateway, going to the central PBX then coming
back in to the Convergence, Call Admission Control would be falsely performed although
the Media Stream would stay in the local network. Strict checking will additionally check
the SDP header to determine how the RTP streams would flow to correctly perform the
Call Admission Control.
• T38 Media Stream Measurement
Enabling T38 stream measurement will make sure that enough bandwidth is reserved,
even though the actual bandwidth use can vary greatly. T38 media stream bandwidth
can range anywhere from 10 kbit/s to 100 kbit/s depending on the nature of the page
that is currently being faxed. A white page will be on the low end, a page with complex
shapes on the high side. Therefore, a simple stream measurement as usually done
for CAC is insufficient escpecially if talking about small branch offices where statistical
effects will not mask such a varying bandwidth. The smaller the branch, and the fewer
the number of simultaneously possible connections, the more severe is the impact of
such an inaccuracy in the stream measurement. It could lead to an additional connection
being permitted, that does not have space once the fax traffic picks up again. Therefore,
this option should always be checked in small branch offices. It works in conjunction
with the FAX URI option that is explained below.
• FAX URIs
This function is especially important in conjunction with the Bandwidth Reservation, and
the T38 fax protocol. If you are not using T38, you will not have to specify anything here.
The particular difficulty lies in the nature of how fax handling with T38 is done in SIP
networks. Faxing is done by first setting up a normal media stream with G.711, G.729
or a similar speech codec. Once the gateway or ATA has detected that it is dealing
with fax traffic, it will initiate a codec renegotiation to the T38 codec. This renegotiation
is done via INVITES, and hence sets up an additional media stream for an existing
session. Once the T38 connection is established, the speech connection will not carry
any data until the fax transmission is finished. This very special behavior needs to be
handled specifically in CAC scenarios. If this box is checked, the bandwidth required for
T38 will already be reserved for the initial call setup, even if a compressed codec is used
there. If there is only insufficient bandwidth for the T38 connection, the original call will
already be rejected.
• Bandwidth Reservation
Bandwidth reservation determines the kind of call admission control done by the Con-
vergence . There are two types. If Bandwidth Reservation is disabled, the CAC will
only count actually established calls. That way, the maximum number of possible calls
can be fitted, but there is the danger of overbooking. Overbooking in those cases can
happen if you have a large number of potential sessions. Those are session that are for
example in a ringing state. This sessions have not been established yet, and hence they
are not counted. Moreover, there is the chance that at least some of these sessions are
2005-2008
c Comdasys AG 95
3.5 Voice-over-IP
never completed (nobody picks up the phone). This means that the CAC check is only
done against the actually established connections. Until a limit is reached, additional
sessions will be permitted. In this window you can have some amount of sessions in a
transient state(Session Progress, Ringing, etc.. Once permitted, all these sessions can
be established in overbook the link by the number of sessions in a transient state that
get established minus one. On a large site, with very many calls, this windows will be
very small so that ovebooking should not be an issue.
The other option is that of reserving bandwidth as soon as the call is setup. This means
that a call is counted as established as soon as the number is dialed. This also means
that sessions in a transient state are fully counted, even though they might never lead
to an established session. This very conservative setup will completely prevent over-
booking, but might waste bandwidth and thus prevent calls from being established that
would theoretically have space especially in situation where calls are not picked up. The
Convergence does however detect SIP forking mechanism which are for example used
for keyset operation in VoIP scenarios. A forked request will only be interpreted as a
single session.
• Ignore Prefix
All prefixes specified here will be ignored for any CAC decision. This means that if
you specify a prefix of xx here, the CAC checks will be based on the dialed number
with the specified prefix being removed first. This feature will only be used in telephony
scenarios where special prefixes can be dialed to e.g. enable the transmission of the
Caller ID. Functions like these are often used by prefixing an access code to the actual
number you want to dial. This prefix must of course not change the CAC assessment
of where the call is going. In order to achieve this, simply add all possible prefixes that
should be ignored to this list. Regular Expressions are allowed here for specifying a
number of prefixes at once. Note however that the special telephony prefixes ”*” or ”#”
are interpreted normally when in the beginning of the regular expressions.
• CAC Bandwidth Check
Each SIP session uses a certain average bandwidth depending on the codec being
used. For G.711 for example the bandwidth required for each session is around 80 - 85
kbit/s including the overhead packets. The bandwidth check parameter here, identifies
how much bandwidth must still be available in order to permit another session. Note that
you have to enter the parameter manually, since codices can be renegotiated during a
session. This means that this parameter has to reflect the highest possible bandwidth
that two endpoints can use after completing their codec negitiation. In pure VoIP sce-
narions that would be 11000 bytes/second for G.711 scenarios and 4000 bytes/second
for G.729 scenarions. In the latter case you should make sure that G.729 is used by all
phones. If not, the fallback codec would typically be G.711. Specifying the maximum
used bandwidth here is important since otherwise it would mean that your session is
permitted first, then renegotiated with another codec and denied there. This kind of be-
haviour would be very user unfriendly. For each Call Admission decision, as to whether
a call should be permitted or not, the worse case is hence assumed. This parameter can
2005-2008
c Comdasys AG 96
3.5 Voice-over-IP
also be used for deliberately leaving some room to the bandwidth limit by checking for
a higher bandwidth than required. The difference would then remain unused which can
be desirable under certain conditions. Note that this field is entered in ”bytes/second”,
not ”bits/s”.
• Redirect to PBX
If there is no more bandwidth for permitting an extra session, the Call can be either de-
nied, or it can be redirected to a gateway. These actions will be discussed later in more
detail. The field here specifies another possible action. The SIP Proxy can modify the
dialled number by prefixing something to let the IP PBX know that the usual call routing
path does not apply. In this case, the rerouting to e.g. a local gateway can be performed
by the central IP PBX. This does not require any Call Admission Control awareness of
the central PBX, simple call routing features with multiple alternative routes, as for ex-
ample found in least cost routing features, do suffice. The central IP PBX can then route
the call over the local gateway in the branch office, thus not generating traffic load on
the bottleneck link.
• Prefix
As already just described, this prefix will be added to the dialled number to inform the
central SIP server that an alternative routing needs to be performed. This prefix can be
any combination of alphanumeric characters and special characters like ”*” or ”#”. In
telephony applications, the prefix will most likely be numeric.
• CAC excluded Numbers
All prefixes specified here will not be considered at all for a CAC decision. Regular
expressions can be specified here. This can be used for excluding certain number
ranges because you know that there will always be enough bandwidth, or because you
maybe want to exclude emergency calls. Excluded calls can cause an overload on a
link if you are not careful in configuring your bandwidth rules.
In Voice scenarios with a central IP PBX as a SIP server, there is a commonly offered
feature named Pickup group. This permits using any telephone and dial a certain special
extension like for example ”*9” in order to pick up the call of another ringing telephone
inside this branch office. In such a case, the Convergence must be told that the ”*9” is
not a regular number but rather the special extension for that. No Admission Control will
be performed on the extensions entered here. Note that you can enter a regular expres-
sion here and the above described functionality will apply to all extensions matching this
expression. This also means that characters having a predefined meaning in a regular
expression must be escaped to match the real character. Escaping can be done by
adding a backslash before the character in question. In order to match the ”*9” used in
the example above, you hence have to enter a ”\*9” into the field. Refer to the Command
Line Reference for more information on regular expressions.
2005-2008
c Comdasys AG 97
3.5 Voice-over-IP
! This is a dangerous function since it can break CAC althogether, especially when
using regular expressions. Be very careful that the expression specified here only matches
the actual calls that you want to have filtered and no more.
• CAC
We have already explained the basic approach of how the Call Admission Control is
handled. In order to configure Call Admission control, we first need to define a link for
which we want to do Call Admission Control. The properties of that link, as for example
how much bandwidth is allowed to be used for voice, is defined inside a traffic class.
See the ?? management section for more information on that. The link definition here is
done by entering the source and destination IP ranges. In the bandwidth management,
multiple voice traffic classes can be defined for each link. After defining the link, we now
need to configure a policy, since a reaction in case of an overload must be configured.
These actions can also be configured in the Convergence Series. The enforcement of
the policy can be any action configurable in SIP. Each CAC policy consists of a Limit
Class, an Action, and a Link. Define the three parameters, then press Add to add
them to the list of Call Admission rules. In the following, we will define the different
parameters in more detail:
– Limit Class
The Limit Class definitions make the connection between the SIP and the IP layer.
All traffic class definitions are used for making assessments as to whether addi-
tional calls can be accommodated. For the Limit definitions, the Bandwidth Man-
agement Configuration is used where a traffic class with certain limits is defined.
The limit is enforced by the Call Admission Control functionality. For more informa-
tion on the definition of the traffic rules refer to the section ?? of this handbook.
As for the configuration, simply select the class representing the real-time traffic
you want to limit with this rule definition.
– Action
For each Call Admission rule definition, the Convergence permits the specification
of an action in the case of a limit violation. As we have already mentioned above,
simply denying calls is the simplest of all actions that can be taken. Sometimes
however it is inappropriate. Imagine for example a case where we can route a call
over multiple links. Since the Convergence is operating at the edge of one or more
bottleneck links, there might be an alternative route to the destination via a second
link. The other possibility is to use the TDM network via a gateway realizing a local
breakout. This second possible action is Redirect. Choose one of the two from the
Drop-Down list. Future versions will come with additional actions.
– Link
2005-2008
c Comdasys AG 98
3.5 Voice-over-IP
The notion of a link is fundamental to the way the Convergence does Call Admis-
sion Control. The simplest case of a link is a physical network connection. The
Convergence however does not stop there. A link is closely associated with the
routing functionality offered by the Convergence. Typically source and destination
addresses are used for classifying packets as belonging to a certain link (matches
the standard IP networking principles). The source address could for example be
used to configure groups for the phones. Group 1 could get a range of IP ad-
dresses, Group 2 another.
Simply enter the Source and Destination IP addresses or network addresses that
you want have the limit and action applied to. The mentioned IP addresses pertain
to the SIP signalling traffic. The source would for example be the local branch net-
work; the destination would most likely be the IP PBX. Type a ”0” for any IP out of
this range.
3.5.3.3 Domain Parameter
The Domain list parameter is one of the most important parameters in the Convergence . The
Convergence will only apply the Survivability, Call Admission Control, and/or Session Border
Controller logic to SIP messages directed at this domain. Domain as used here refers to the
rear part of a URI parameter. This means that if you have some client send a SIP message
for 500@foo.bar to the Convergence it will only act upon it in the way described if foo.bar
can be found in the domain list. Otherwise it will simply perform a DNS lookup and forward
the message appropriately. In that case it will behave like a standard stateful SIP Proxy.
This means that for Survivability scenarios, the message will be routed correctly only if all
applicable domains are entered here. This must be at least the IP address of the IP PBX
and if used also any DNS names as well as aliases. If you specify DNS names here, you
should also specify the corresponding IP address (if possible) to avoid unnecessary DNS
lookups. If a SIP message arrives with the DNS name replaced by the IP address only a
quick comparison has to be performed instead of a DNS reverse lookup. For domain names
where no reverse lookups are possible, both the IP address as well as the domain name must
be specified here to enable the correct operation.
3.5.3.4 Gateway Parameters
• Gateways (figure ?? on page ??)

The gateway parameters are comparatively straightforward. The gateways are used in
the Survivability scenario. They will however also be considered for the Call Admission
Control since a call to a local phone is of course not subject to admission control. Other
than that, the Convergence will use the parameters configured here for performing a
local breakout. The Convergence theoretically supports up to 15 gateways in a hunting
configuration. In practice, anything more than 3 is very uncommon.
2005-2008
c Comdasys AG 99
3.5 Voice-over-IP
– IP address
The IP address is that of the PSTN gateway. The Convergence can interact with
any PSTN gateway that supports SIP as specified in RFC3261. Some restrictions
concerning features available in the phones etc. might however apply. Although
the name of the field says otherwise, it is also possible to specify DNS / DNS SRV
names here. In most cases however, Survivability scenarios will be induced by
WAN failures. If your DNS server is unavailable in such cases, as is frequently the
case, putting the DNS name of the gateway here will result in total failure. Therefore
you should only use DNS names if you are sure the DNS server is available in all
scenarios the Survivability function has to work in. A possibility to achieve that is
to use the DNS slave function in the Convergence where it can be a caching DNS
slave for some configurable master and hence answer DNS queries even if the
master is offline.
Directly behind the IP-address, you need to specify the transmit mode. This can
again be either UDP, TCP or TLS. The same restrictions and possibilities as for the
IP PBX apply, so refer to the subsection Survivability Parameters on page ?? for
more information on this.
– Strip digits
This parameter determines how many characters of the phone number must be re-
moved in Survivability mode before passing the message on to the PSTN breakout
gateway. Under normal operation, this will all be done by the PBX. In survivability
mode, the Convergence will perform the necessary number manipulations.
– Prefix numbers
After a certain amount of digits has been removed, it is possible to prefix any
combination of digits before the call is forwarded by the gateway. Note that the
functionality here does of course not only apply to numbers, it could also be any
characters allowed in URIs. The most common case however with a gateway will
be phone numbers where prefixes are commonly used. Prefixing something would
hence be necessary if the gateway expects numbers in a certain format. As already
explained before, this URI manipulation would normally be performed by the SIP
server. This however is impossible in the Survivability case which is why the Con-
vergence will perform this here. The gateway is hence unaware of the fact that it is
operating in Survivability mode. This functionality is hence completely transparent
to the gateway.
– CAC
It is possible to perform Call Admission Control in Survivability mode before the Call
is being forwarded to a gateway. This is necessary since it cannot be assumed that
the gateway is always locally connected to the LAN. It could be located off site.
This could mean that in a backup case, it can only be reached via some backup
link. There are many scenarios that are conceivable. The Call Admission Control
parameters will allow limiting the number of calls going to the gateway. For more
2005-2008
c Comdasys AG 100
3.5 Voice-over-IP
information on Call Admission Control refer to the more detailed explanation in

the general section. The Redirect action will make the Call Overflow to the next
possible gateway. If there is none, the Redirect will behave the same as a Deny.
Figure 3.40: Gateways
3.5.4 Branch Session Border Controller (SBC) Functionality
This template is very similar to the Survivability scenario, and in fact it will also act as a
survivability component in the network. Therefore we will provide a general introduction here,
but for the description of the actual features we will often refer to the Survivability section. We
will however point out the differences here.
The main difference between the Branch SBC and the Survivability Template is the fact that
with the former, the Convergence will always do media handling in addition to the SIP sig-
nalling handling. The Branch SBC scenario will usually be used in scenarios where you have
a branch office that you want to equip with real-time communication. That could for exam-
ple be a scenario where the users in this branch offices are to be hooked up to a centralized
softswitch. Especially in bigger network it is however often impossible to provide a flatly routed
network across all locations where users are to be connected to the softswitch. This poses
special challenges then, because the peer-to-peer type communication of SIP endpoints con-
cerning media handling actually requires such a network.
2005-2008
c Comdasys AG 101
3.5 Voice-over-IP
Figure 3.41: Branch SBC: Basic Settings
2005-2008
c Comdasys AG 102
3.5 Voice-over-IP
Figure 3.42: Branch SBC: SBC Settings
2005-2008
c Comdasys AG 103
3.5 Voice-over-IP
3.5.4.1 Branch SBC Parameter
• Own number
See ?? for a more detailed description.
• Prefix Number
• PBX Address
• PBX Alias
• Internal IP
Since the Branch SBC will do media handling if a SIP session leaves the boundaries of
the local branch office, the Convergence needs to know the internal network address
for which it should not be doing media handling. For all session where both the source
and the target are within this network, the media streams will continue to flow directly
between the endpoints.
• Netmask
This parameter describes the netmask for the above configured network IP address.
This netmask enables the Convergence to check whether two endpoints are actually
local or not.
• External IP
All Convergence products support multiple virtual and non virtual interface. When acting
as a branch session border controller, there however must be a unique uplink interface
through which outgoing media streams should be routed. When looking at the SIP
messages that are leaving the branch SBC, all SDP bodies will contain this external
IP address, and hence all endpoint having a connection with some endpoint inside the
Branch SBC will be sending their media streams to this external IP address.
• Timeout
• Alive check via SIP instead of ICMP
• Registration Timeout
2005-2008
c Comdasys AG 104
3.5 Voice-over-IP
• RTP Proxy
• Force Return Route
• Mask Proxy Domain on Register
• Local Gateway
This is another Branch SBC specific parameter. You need to configure whether media
handling should be done for calls to and from gateway calls. If checked, the gateway will
be assumed to be local, and media handling will be disabled for all calls between local
endpoints and the local gateway. If not checked, the gateway is assumed to be external,
e.g. located at the central softswitch. This will enable media handling for all external
calls.
• Debug
• Disable Loose Routing
• Failover Server Replication and Failover Server IP
• Gateway DNS Alias
If this checkbox is enabled, the information in the field wiht the same name
3.5.4.2 Survivability Parameter
• Survivability
In the Branch SBC mode of operation, Survivability functionality must be separately
enabled. Check this box to activate survivability. In this case, the Convergence will
behave exactly the same way as in Survivability mode, but it will do the media handling
in addition to that.
• CFW in Survivability Mode
2005-2008
c Comdasys AG 105
3.5 Voice-over-IP
• No ReRouting On
3.5.4.3 CAC
• CAC
The Convergence is able to do Call Admission Control in addition to Branch SBC func-
tions. By default, this functionality is however not enabled in this mode. To enable it,
simply activate this checkbox.
Figure 3.43: Branch SBC CAC Parameter
2005-2008
c Comdasys AG 106
3.5 Voice-over-IP
• Redirect to PBX
The fields Prefix and Redirect to PBX are related. Please see ?? for a more detailed
description of these parameters.
• CAC Excluded Numbers
• CAC
3.5.4.4 Domain Parameter
3.5.4.5 Gateways
3.5.5 Cascaded SBC (Session Border Controller) Template
The cascaded SBC deployment allows the branch offices to connect to a protected SIP server
while using their own private network. The central SBC may or may not serve as a media
bridge for inter-branch calls. This means that the Convergence is deployed in the branch
office with the Branch SBC Template, and centrally the Convergence is deployed with the
Cascaded SBC template. As such, the Cascaded SBC will act mostly as a media bridge.
Since in this configuration mode, the central SIP server cannot see the topology if the network,
the CAC functionality must be activated on the SBCs in order to ensure proper bandwidth
management.
3.5.5.1 Cascaded SBC Parameter
• PBX Address See ?? for a more detailed description.

• PBX Alias See ?? for a more detailed description.
2005-2008
c Comdasys AG 107
3.5 Voice-over-IP
Figure 3.44: Cascaded SBC Parmeter
2005-2008
c Comdasys AG 108
3.5 Voice-over-IP
• Internal IP Since the Branch SBC will do media handling if a SIP session leaves the
boundaries of the local branch office, the Convergence needs to know the internal net-
work address for which it should not be doing media handling. For all session where
both the source and the target are within this network, the media streams will continue
to flow directly between the endpoints.
• Netmask This parameter describes the netmask for the above configured network IP
address. This netmask enables the Convergence to check whether two endpoints are
actually local or not.
• External IP All Convergence products support multiple virtual and non virtual interface.
When acting as a branch session border controller, there however must be a unique
uplink interface through which outgoing media streams should be routed. When looking
at the SIP messages that are leaving the branch SBC, all SDP bodies will contain this
external IP address, and hence all endpoint having a connection with some endpoint
inside the Branch SBC will be sending their media streams to this external IP address.
• RTP Proxy See ?? for a more detailed description.
• Mask Proxy Domain on Register
• Debug
• Disable Loose Routing
• Failover Server Replication and Failover Server IP
• Map Office Prefix to Branch SBC IP
2005-2008
c Comdasys AG 109
3.5 Voice-over-IP
3.5.5.2 CAC
• CAC
The Convergence is able to do Call Admission Control in addition to Branch SBC func-
tions. By default, this functionality is however not enabled in this mode. To enable it,
simply activate this checkbox.
• Redirect to PBX
The fields Prefix and Redirect to PBX are related. Please see ?? for a more detailed
description of these parameters.
• CAC Excluded Numbers
• CAC
3.5.6 SBC (Session Border Controller) Template
A Session Border Controller (SBC) is a VoIP session-aware device that controls call admis-
sion to a network at the border of that network. The central SBC function is not available in
all Convergence products. Contrary to the Branch SBC, the SBC function is not only an in-
frastructure function, but a securiy component providing a separation between networks. The
Convergence currently performs, NAT Traversal, SRTP termination as well as other functions
in that mode. The Convergence is still primarily built to fulfill these infrastructure functions. It
is not built to perform some other functions usually attributed to SBCs, such as protocol trans-
lation (e.g. to MGCP). While the functionality will increase in the future, the Convergence is
still positioned to be a pure SIP device. A typical centralized Session Border Controller breaks
down into two logically distinct pieces.
• Signalling The Signaling SBC function controls access of VoIP signaling messages to
the core of the network, and manipulates the contents of these messages.
2005-2008
c Comdasys AG 110
3.5 Voice-over-IP
• Media
The Media SBC function controls access of media packets to the network, provides
differentiated services and QoS for different media streams. It can also be used to pro-
vide security functions like SRTP termination to differentiate between different security
zones, and avoid things like service theft.
This template will act as a centralized session border controller, handling all media streams
emanating from client coming from the WAN network and being behind a firewall. The most
important function of a centralized SBC is hence the ability to enable clients behind a NAT
firewall to do IP communication. The challenge is to make this work behind arbitrary firewall
types including those typically found in public Internet Hotspots. The goal is enable ubiqitous
IP communication while keeping the network inside the SBC to remain secure. In order to
properly understand this setup, we first need to do some explanation of the supported NAT
networks.
3.5.6.1 Explanation NAT
NATs are active network devices placed in the data path. NATs are similar to firewalls, and
different from routers, in that they are topologically sensitive. They have an ”inside” and an
”outside,” and undertake different operations on intercepted packets depending on whether
the packet is going from inside to outside, or in opposite direction.
NATs are IP header translators, and, in particular, NATs are IP address translators. The
header of an IP packet contains the source and destination IP addresses. If the packet is being
passed in the direction from the inside to the outside, a NAT rewrites the source address in the
packet header to a different value, and alters the IP and TCP header checksums in the packet
at the same time to reflect the change of the address field. When a packet is received from
the outside destined to the inside, the destination address is rewritten to a different value, and
again the IP and TCP header checksums are recalculated. The ”inside” does not necessarily
use globally unique addresses to number every device within the network served by the NAT.
The inside (or ”local”) network may use addresses from private address blocks, implying that
the uniqueness of the address holds only for the site.
NATs are configured with a pool of public addresses, and when an ”inside” host first sends an
outbound packet, an address is drawn from this pool and mapped as a temporary alias to the
inside host’s local address. This mapped address is used as the new source address for the
outgoing packet, and a local session state is set up in the NAT unit for the mapping between
the private and the public addresses. This type of pure NAT has become very uncommon
nowadays, but it is still mentioned for completeness here.
The variant of the NAT commonly used today is the Port-Translating NAT, or NAPT (today
the term NAT is frequently used to also refer to this type of NAT mapping). This form of
NAT is used in the context of TCP and User Datagram Protocol (UDP) sessions, where the
NAT maps the local source address and source port number to a public source address and
2005-2008
c Comdasys AG 111
3.5 Voice-over-IP
a public-side port number for outgoing packets. Incoming packets addressed to this public
address and port pair are translated to the corresponding local address and port.
Again the NAPT is attempting to be transparent in terms of providing a consistent view of the
session to each end, using a symmetric binding of a local address and port pair to an external
address and port pair. NAPTs allow concurrent outgoing sessions to be distinguished by the
combination of the mapped address and mapped port value. In this way each unique external
pool address may be used for up to 65,535 concurrent mapped sessions.
For a while the terminology distinction between NATs and NAPTs was considered important,
but this has faded over time.
It should be noted that a large number of mapped sessions in a firewall can pose both a
security as well as a performance problem. Each NAT mapping is a pinhole in the firewall
that can be used to sneak information into the protected network. In addition to that with a
large number of sessions, the firewall might have to do a lot of comparisons for each arriving
packet to check for the connection this packet belongs to. These restrictions especially pose
problems in VoIP scenarios, since each active SIP clients in a call state necessitates at least
2 active NAT mappings
! Note that if you want to use SIP endpoints across the WAN port, you will need to
use manually change security settings. If your messages arrive on the WAN interface, the
firewall will block those by default. It is however relatively easy to enable SIP and RTP traffic
on the WAN interface. Please refer to the ?? section for more information about this topic.
Signalling The Convergence will do signalling handling and provide Session Border Con-
troller function between an inside and an outside network, typically the Internet. In addition to
that it will do far end NAT traversal. After the client has registered, the remote NAT mapping
is learned by the Convergence so that it can send subsequent requests to this client. A SIP
OPTIONS message is sent periodically (typically every 30 seconds) to keep the remote NAT
mapping alive and thus keep the remote client operational. The SBC will also perform vali-
dation of received SIP messages before forwarding them to the internal SIP server. With that
approach, malformed SIP messages will be detected and dropped. In addition to that, addi-
tional semantic checks will be made on the SIP mesages based on the available information
before forwarding them to the internal SIP server. The connection to the media handling is
done by modifying the SDP bodies of the SIP messages. With that modification, the SBC will
be in the middle of every media stream from a client to the inside network, as well as in every
media stream between two clients behind two distinct NATs.
3.5.6.2 Media Handling
The media handler will create its own session for each connection setup done via the sig-
nalling handling. Similarly to the SIP approach to handling remote NATs, the remote NAT
2005-2008
c Comdasys AG 112
3.5 Voice-over-IP
mapping is learned by the SBC, so that packets can be sent to the client behind the remote
NAT. Once the media stream has been initiated in both directions, no redirection of the media
streams are permitted, expept that is negotiated via SIP messages. This protects the users
from session hijacking. In addition to that, the source of the media stream packets is validated
against the stored session parameters to avoid somebody from sending dummy packets to
the respective port of the SBC and thus disrupting the session. It also features a dead peer
detection to clean up invalid sessions. Additionally, the Convergence can perform SRTP termi-
nation. With that function, the Convergence will terminate all sessions emanting from clients
on the outside network and send plain RTP to the SIP server or any connected equipment
like gateways. In the reverse direction, those devices will send plain RTP to the SBC which in
turn will encrypt everything before sending it to the clients on the outside network.
3.5.6.3 Parameter Configuration:
The following will explain the parameters that can be configured for the SBC template.
This field is for entering the IP address or the DNS name of the PBX for which you want to
act as a Session Border Controller. All requests (passing security checks) coming from the
external interface will be forwarded to this PBX.
• SIP Transmit Type

The SIP Transmit Type parameter is the transmission type the Convergence uses to
contact the SIP server. The Convergence supports 3 different SIP transport modes,
UDP, TCP, and the encrypted TLS variant. The type to use depends first and foremost
on the used SIP server. The TCP and UDP types are straightforward and just specify
the used protocol type.
The only type requiring further explanation is TLS. For TLS additional things like the
encryption keys are required. Since this is a very advanced topic, this cannot be config-
ured via the WebGUI as of yet. The Convergence will generate TLS keys automatically
that can be downloaded for the use in Servers/Phones via SCP. Please consult the
Command Line Reference for more information on how to do that.
• Internal IP
The Convergence can have multiple interfaces as well as multiple IP addresses per
interface. It is therefore necessary to specify which IP address should be used for
communicating with the SIP server. This IP address will then be used both for signalling
as well as media handling.
• External IP
The Convergence can have multiple interfaces as well as multiple IP addresses per
interface. The external IP address is the one the Convergence will use when communi-
cating with the clients. Clients in that respect are the SIP endpoints registered from the
outside of the network boundary the Session Border Controller is protecting.
2005-2008
c Comdasys AG 113
3.5 Voice-over-IP
• Internal URI match

The Internal URI match is a parameter used to classify URIs and that helps to identify
unwanted SIP messages. This field can be a regular expression and should match all
those requests that can occur when connected to this SIP server. The simples form is
certainly to use something like @foo that would match all URI in messages that have a
foo in the host part of their URI. You can use more sophisticated expressions however
that could for example match legal phone number ranges. It is safe to leave this field
blank.
• SIP Port
This enables you to specifiy the SIP port the Convergence should use both for TCP as
well as for UDP SIP messages. If you are using non-standard ports here, you should
also check your firewall configuration that these ports are open. Otherwise any mes-
sages sent to these ports would be denied by the firewall. Using non standard ports
is especially important in conjunction with some public hotspots that explicitly deny the
standard SIP ports to prevent Voice-over-IP applications.
• TLS Port
This enables you to specifiy the SIP port the Convergence should use for TLS SIP
messages. See also SIP Port for a more detailed explanation as to why this should be
necessary. As an addition, it should be noted that blocking TLS SIP traffic is almost
impossible except for matching the port, since the payload is not visible to anybody.
From a network standpoint, it hence looks like a regular SSL session that could also be
an https session.
• TLS Meth. TLSv1
If this is enabled, the Convergence will force TLS Version 1. If disabled, the Conver-
gence will run in a compatbility mode also accepting SSLv2 and SSLv3. RFC3261
mandates support for TLS Version 1, so checking this box should be okay with all com-
pliant SIP endpoints and servers. There are however a lot of implementations still caus-
ing problems with TLS Version 1. In those cases it often helps to fall back to the more
established SSL protocol to get things working. The importance of this should however
decrease during time when TLS becomes more commonplace.
The force return route parameter pertains to the SIP signalling only. If a register is
addressed at the Convergence , it will modify the contact header before forwarding
the message. The modification will lead to the fact that the SIP server will send all
subsequent messages intended for the phone to the SBC first. Dual-way SIP signalling
is essential for NAT scenarios. If this feature is required depends on the SIP server. If
the SIP server has an outbound proxy feature, a contact header modification will not
be required. In such a case, the SIP server would send the SIP messages through the
Convergence no matter what the contact header looks like.
2005-2008
c Comdasys AG 114
3.5 Voice-over-IP
• Presence Server IP
If you have a separate presence server, you can specify the IP address here. This
would force the SBC to handle presence requests, as for example the SIP PUBLISH
method separately from the standard SIP server. As such, you could have a separate
SIP server and Presence server and let the SBC correctly separate the requests for
these. The advantage of this is that your SIP server does not have to be aware of any
presence functionality, because the SBC is already separating the requests.
• Voicemail Server IP
You can specify the IP address of your voicemail server here. This is for special sce-
narios where the voicemail server is also integrated via SIP and where it should be
prevented that in dialog requests should also correctly flow through the SIP server. This
should only be relevant if you are using a SIP proxy type of server as your central SIP
server. In such cases it can happen that in dialog requests such as ACKs and BYEs
are routed throught the SIP server instead of directly to the SBC. Therefore, the Route
headers of the messages must be modified accordingly.
• PSTN Gateway IP
This field is similar to the one for the Voicemal Server IP. If specified, it is used to aid the
correct SIP message modification. Again, if a back-to-back user agent is used instead
of a SIP Proxy as the central server, this will be impossible. All signalling to the gateway
will then be handled by the B2BUA and the SBC will be completely unaware of this. The
media stream can of course still be directly passed to the voice gateway.
• Secure Media (SRTP)
If this is enabled, the SBC will perform SRTP termination for all incoming sessions, and
will only initiate encrypted sessions to the outside world. Internally, RTP will still be used.
• Mask Proxy Domain on Register / SIP Domain
The SBC can hide the SIP domain towards the SIP server. This means that a different
domain can be used towards the outside world, while a completely different SIP domain
can be used on the SIP server. Enter an IP address or a domain name here, and the
SBC will rewrite this domain for all requests coming in from the outside network. The
most elegant solution however is to use DNS names where both the SIP server as well
as the clients coming from the outside network. The resolutions for this domain name
should be the external IP address of the SBC for the clients, and for the SIP server on
the internal networks. If configured properly this way, this parameter is not necessary.
3.5.7 SIP Trunking Template
SIP Trunking is another possibility of using the Convergence . In this scenario, the Conver-
gence acts as a Topology Hiding Session Border Controller. SIP Trunking will mostly be used
for telephony applications, but the Convergence can also support alternative media formats
2005-2008
c Comdasys AG 115
3.5 Voice-over-IP
like video conferencing with the identical configuration. For the explanation of the parameters,
we will however heavily rely on pure VoIP terminology.
In a SIP Trunking scenario, the Convergence will usually be placed at the edge of an office
network.
Figure 3.45: Trunking Parmeter
• Own Number
• PBX
This field is for entering the IP address or the DNS name of the PBX for which you
want to implement SIP Trunking. All requests coming from the Trunking provider will be
forwarded to this PBX. There are two different variants a PBX can behave. One can have
the PBX register with the Trunking provider, or use a static registration with the provider.
On the PBX, simply set the address of the internal interface of the Convergence as
the SIP Trunking address. Hence you do not have your PBX connected to any outside
network. Just the routing / switching between the PBX and the Convergence must be
possible.
2005-2008
c Comdasys AG 116
3.5 Voice-over-IP
Figure 3.46: Trunking Parmeter (continued)
2005-2008
c Comdasys AG 117
3.5 Voice-over-IP
– SIP Transmit Type

The SIP Transmit Type parameter is the transmission type the Convergence uses to
contact the central SIP server. The Convergence supports 3 different SIP transport
modes, UDP, TCP, and the encrypted TLS variant. The type to use depends first
and foremost on the used SIP server. The TCP and UDP types are straightforward
and just specify the used protocol type.
The only type requiring further explanation is TLS. For TLS additional things like
the encryption keys are required. Since this is a very advanced topic, this cannot
be configured via the WebGUI as of yet. The Convergence will generate TLS
keys automatically that can be downloaded for the use in Servers/Phones via SCP.
Please consult the Command Line Reference for more information on how to do
that.
– PBX Port
This field is for defining the port the Convergence will contact the SIP server under.
If left empty, port 5060 will be assumed for the transmit types UDP and TCP, 5061
for the transmit type TLS.
• Trunk Address
The trunk address needs to be set to the IP address, DNS name, or DNS SRV name of
the SIP server of the trunking connection provider. If a DNS SRV name is specified, the
?? must be enabled.
– SIP Transmit Type

The transmit type parameter has the same meaning as ?? towards the PBX. It will
specifiy the way, the SIP messages are transmitted to your trunking provider. The
choices are UDP, TCP, and TLS again, as specified in RFC3261. If your provider
supports TLS, you should try to use it for security reasons. If not, the only other op-
tion to achieve some level of security is by using tunneling techniques likes VPNs
to implement a secure channel across the Internet. Note however, that this secu-
rity only pertains to the signalling level. The Convergence supports SRTP pass-
through by default and can also support SRTP termination. This means that if your
PBX supports SRTP, the encrypted media can be passed through. In cases where
this is not supported, the Convergence can do the termination for your PBX and
return plain RTP while speaking SRTP towards the provider. Since SRTP and the
key negotiation algortihms are not very standardized yet, please refer to ?? for
more information.
! If DNS SRV is enabled, this information will be ignored since the discovered values
from the DNS server are used.
2005-2008
c Comdasys AG 118
3.5 Voice-over-IP
– Trunk Port
This field specifies the port that should be used to contact the trunking provider. As
always, the default SIP ports (5060 for TCP and UDP, 5061 for TLS) will be used if
nothing is specified. If non standard ports are used by your provider, please enter
them here.
! If DNS SRV is enabled, this information will be ignored since the discovered values
from the DNS server are used.
• Retransmisson Timer
The various retransmission timer settings are all tightly related and therefore will be ex-
plained together. Note that all the rentransmission logic only applies to the UDP variant
of SIP. Both the TCP and TLS variant use the connection oriented Transport Control Pro-
tocol for the transmission of the messages. This transport layer protocol ensures that all
messages sent from some source reach the destination. This means that there are error
correction and retransmission mechanisms already built into the transport layer meaning
that the SIP application layer does not have to handle retransmissions any more.
The situation is quite different with UDP, where any message can get lost. The retrans-
mission timers refer to SIP requests. All SIP requests mandate a response from the
endpoint (in our case eihter the PBX or the trunking provider). Since the PBX will usu-
ally be connected through a local ethernet interface, there should be no problem with
lost packets on this side. The trunking provider connection however usually goes over
the Internet where messages can easily be lost or delayed. These timers set the interval
that the Convergence waits for a response to a request before sending it again. Com-
monly the timers are increased with the default being (500 msec, 1000 msec, and 2000
msec).
– Retransmission Timer 1
This is the first retransmission timer and must be set in milliseconds. If no response
(both provisional 1xx responses as well as final ones will be accepted here) to a
request is received within this time, a retransmission is initiated. The accuracy of
the retransmission will be around 50 msec. This means that if this timer is set to 500
msec, which is also the default value, the retransmission will occur in the interval
between 450 msec and 550msec after the first request has been sent without a
reponse arriving.
Also see above for a more detailed explanation. The timer must also be set in
milliseconds with the default being 1000 msec.
2005-2008
c Comdasys AG 119
3.5 Voice-over-IP
Also see above for a more detailed explanation. The timer must also be set in
milliseconds with the default being 2000 msec.
– Final Retransmission Timer
After the final retransmission timer hits, the server will be considered down or un-
reachable, and no further attempts will be made. If DNS SRV is configured, the
failover mode will be entered and a DNS lookup to discover the secondary server
will be initiated. Once that server has been discovered, messages will be sent there
instead of the primary server. The primary server will only be contacted after the
penalty box has expired. Once that has happened, an attempt is made to contact
the primary server. If it still does not respond even to the retransmission sequence,
it will again be put into the penalty box. If it is reachable, all subsequent requests
will go there again.
• Enable DNS SRV

If DNS SRV is enabled, the Convergence can use it to discover a secondary server if the
primary one is offline. DNS SRV is a protocol that allows you to define service classes
for your domain. The product will look for the SIP service class, and then will lookup the
IP address for the discovered host. DNS SRV is supported by all common DNS server
products. Also see the explanations for the Retransmisson Timers as well as the DNS
SRV failover penalty for more detailed information on this.
• DNS SRV failover penalty
This value that is set in seconds specifies the so called penalty box. If a server has been
considered to be offline, the server IP will be put into a penalty box to avoid unnecessary
timeouts for transmission to an offline server. If DNS SRV is enabled, the request will be
sent straight to a backup server. The Convergence will only try to contact the primary
one after the time specified here has expired. This time must be specified in seconds.
• Internal IP
Since the Cascaded SBC will do media handling if a SIP session leaves the boundaries
of a branch office connected to the Cascaded SBC. This means that it will handle all
sessions where media streams flow between two connected branch offices, or between
a branch office and some central entity like a media server. In order to correctly local
branch office, the Convergence needs to know the internal network address for which
it should not be doing media handling. For all session where both the source and the
target are within this network, the media streams will continue to flow directly between
the endpoints.
• External IP
All Convergence products support multiple virtual and non virtual interface. When acting
as a branch session border controller, there however must be a unique uplink interface
through which outgoing media streams should be routed. When looking at the SIP
2005-2008
c Comdasys AG 120
3.5 Voice-over-IP
messages that are leaving the branch SBC, all SDP bodies will contain this external
IP address, and hence all endpoint having a connection with some endpoint inside the
Branch SBC will be sending their media streams to this external IP address.
3.5.8 Standalone Template
The standalone template is the simplest template explained here. The Convergence can act
as a mini SIP server, thus providing basic call functionality and other basic functionalities
supported by the SIP devices. PSTN gateways can be used for making external calls. This
template can also be used in conjunction with the B2BUA to use SIP carrier accounts as
gateways.
Figure 3.47: Standalone Basic Settings
• Own number
Under normal operations, the phones can be reached via two different numbers, their
complete PSTN number and internally by simply dialing an extension. An example
will illustrate this. Let us assume that the branch office can be reached via the ”+49
89 4711” from the outside. Internally you have the extensions ”100” and ”110”. This
2005-2008
c Comdasys AG 121
3.5 Voice-over-IP
means that from the PSTN you can reach the phones by dialling ”+49 89 4711 100”.
Internally, the phones can be reached via their full number or via their extension only.
The registration with the SIP server and the SIP Proxy in our case here is performed with
the full number. By knowing the Own Number of the branch, the Proxy upon receiving
a call for an extension in Survivability mode can now prepend the number of the branch
and hence find the phone in the Registration database. This means that extension
dialling still works in survivability mode. This can be used to avoid having to do number
manipulation in the gateway for incoming calls. If you do not want to use this feature,
simply leave the field blank.
• Prefix number
The Prefix number describes the prefix the number has if it is an outgoing call. Usually
this is just a simple digit as for example a ”0” for getting an outside line. Expressions for
this can however be more complex than that. You can enter arbitrary regular expressions
here. Only numbers having the correct prefix will be routed to the gateway. This pre-
vents unavailable internal numbers from ending up in the PSTN and going somewhere
unintentionally.
Figure 3.48: Standalone SIP Settings
• Timeout
The timeout value is the maximum time the proxy will wait for a response from a gateway
upon a request before falling into hunting mode. If a negative response is received
2005-2008
c Comdasys AG 122
3.5 Voice-over-IP
earlier, the hunting will of course commence sooner.

• Enable Hunting
This feature only applies to scenarios where there are multiple gateways present. In that
case it might be desirable that a gateway hunting is performed between these multiple
gateways. This can be used for a variety of scenarios as for example stacking gateways
or having gateways in multiple locations and applying Call Admission Control Param-
eters to them. The decision parameters for the gateway hunting are configured with
the gateways. If this parameter is not set, only the first gateway will be considered for
outbound calls. The others might however still be used for incoming calls since the SIP
Proxy will of course handle their SIP requests just like he would those of any phone.
Figure 3.49: Standalone Diagnostics
• Debug
can either be seen in CLI mode on the Convergence, or on the specified logging server.
See the logging parameters in this document or refer to the Command Line Guide for
more documentation on how to have a look at the logging.
2005-2008
c Comdasys AG 123
3.5 Voice-over-IP
3.5.8.1 Gateway Parameters
See Survivability Configuration on page ?? for more information on the parameters here.
3.5.9 ENUM Template
The Enum template is relatively straightforward to explain. The typical usage scenario is
the Convergence connected to the Internet externally and connected to a SIP Server / IP
PBX internally. The Convergence acts as an ENUM lookup server and as a Session Border
Controller for incoming calls.
The IP PBX must be configured to forward all calls to the Convergence appliance. The Con-
vergence will try to convert the dialled phone number into an E.164 number to perform an
ENUM lookup. If it successfully finds a SIP URI registered under this number, it will forward
the call via IP. Otherwise it will signal back a trunk busy to the IP PBX that should in turn try
the next available trunk meaning it will route the call as before via PSTN. In that scenario, the
Convergence can be integrated into the existing Voice infrastructure. The Convergence must
of course also be configured to permit incoming calls, by opening the firewall etc. Also see
the firewall section for more details on this.
There might be other usage scenarios, where the ENUM template can be useful. An extensive
discussion would however be beyond the scope of this book.
• PBX Address
This parameter is for entering the address of the connected IP PBX. It can either be
entered in the form of an IP address, a host name or even as a DNS SRV address.
Note that entering a DNS or DNS SRV name can introduce more latency in forwarding
messages to the IP PBX since the hostname has to be looked up first.
• SIP Transmit Type
The SIP Transmit Type parameter is the transmission type the proxy uses to contact the
IP PBX. The Convergence supports 3 different SIP transport modes, UDP, TCP, and the
encrypted TLS variant. The type to use depends first and foremost on the used IP PBX.
The TCP and UDP types are straightforward and just specify the used protocol type.
The only type requiring further explanation is TLS. For TLS additional things like the
encryption keys are required. Since this is a very advanced topic, this cannot be config-
ured via the WebGUI as of yet. The Convergence will generate TLS keys automatically
that can be downloaded for the use in the IP PBX via SCP. Please consult the Command
Line Reference for more information on how to do that.
• Debug
can either be seen in CLI mode on the Convergence, or on the specified logging server.
2005-2008
c Comdasys AG 124
3.5 Voice-over-IP
Figure 3.50: ENUM Basic Configuration
2005-2008
c Comdasys AG 125
3.5 Voice-over-IP
Figure 3.51: ENUM Sip Settings
Figure 3.52: ENUM Diagnostics
2005-2008
c Comdasys AG 126
3.6 SIP Proxy Users
See the logging parameters in this document or refer to the Command Line Guide for
more documentation on how check the logging output.
The following parameters are all used to convert a telephone number into a full E.164 num-
ber.
• City Code
Enter the plain city code 3-digits in the US and other countries. It can also be a number
of variable length in many countries.
• Country Code
Enter the Country Code for your country without any preceding digits. This would be a
”1” for the USA, the ”49” for Germany, etc.
• Long Distance Prefix
Enter the number you have to dial on your phone before making a long distance call. In
the US this is a ”1”, in most European countries a ”0”.
• International Prefix
Enter the number you have to dial on your phone before making an international call. In
the US this is the ”011” in most European countries the ”00”.
3.5.10 Custom Template
The custom template allows you to use your own configuration script for the SIP Proxy. Please
refer to the Command Line Reference on more information on how to create your custom SIP
Proxy configuration script. It is also possible to use one of the above defined scenarios, and
then modify the script appropriately to suit your needs.
3.6 SIP Proxy Users
This menu item lists any currently registered SIP proxy / Session Border Controller users. A
user is represented by its URI and its name, where the name may be an alphanumeric string
or a telephone number extention.
i Note that the relevance of this information varies quite significantly. In Survivability
and Branch SBC mode, this information is only utilized for Survivability functionality and
plays no role in normal mode. In the Cascaded SBC and SIP Trunking scenarios this infor-
mation is not used at all. In the SBC scenario, this information is quite important however
because it is being used for the NAT detection.
2005-2008
c Comdasys AG 127
3.6 SIP Proxy Users
Figure 3.53: SIP Proxy Users
2005-2008
c Comdasys AG 128
3.7 SIP TLS configuration
More details on registered users are provided by the SER server command serctl ul
show. Please refer to the Command Line Reference Guide for further information on the
usage of serctl.
Settings for SIP proxy are described extensively in section ??.
The SIP TLS configuration page is a simple tool to upload a TLS private key and a TLS
certificate used to communicate with the client in TLS mode. Naturally this is only relevant
if you have a client that is able to support SIP in TLS mode. Otherwise you can ignore this
section.
The Convergencegenerates a new privat key and a certificate automatically while booting if
noprivate key or certificate exists. Therefore, if you do not want to setup authentication based
on certificates, there is no need to do any configuration here.
Figure 3.54: SIP TLS configuration
2005-2008
c Comdasys AG 129
3.7.0.1 Upload Private Key and Certificate
To upload a new TLS Private Key press the Browse button and select the new private key
from your file system (Figure: ??).
In the next step press the Upload button and the new TLS private key will be saved onto the
Convergence. The procedure for the TLS certificate is essentially the same (Figure: ??).
! The TLS certificate must fit the TLS private key, otherwise no TLS communication
will be possible
3.7.0.2 Create default private key and certificate
If you do not have any keys to use for TLS communication, you can also use the Conver-
genceto create a key set. Simply press Generate and the Convergencegenerates a new
default TLS private key and TLS certificate. These will be stored on the Convergenceand
activated after pressing Apply Configuration .
3.7.1 B2BUA
Contrary to the SIP Proxy, the B2BUA does not only handle the SIP signalling, it also handles
the media sessions. It is therefore a lot more relevant what types of sessions are being
initiated. The B2BUA must also support the media codecs. Due to these reasons, the B2BUA
at the moment can only be used for Voice scenarios. The biggest use of the B2BUA is for
terminating calls coming from the Internet (e.g. for Security Reasons). In such a setup,
people can be allowed to make calls from the Internet that will be handed to some device
on the LAN without having a direct routing connection. Not even the SIP messages will be
forwarded before being completely parsed and reassembled. The B2BUA will terminate the
call coming from the outside and setup a new internal call. This can be desirable for security
purposes if you are having e.g. mobile users or home workers that you do not want to connect
via e.g. VPN.
In another scenario, the B2BUA routinely gets used in scenarios involving SIP carriers. SIP
carriers usually expect a UA (User Agent like a SIP phone or a Softclient) to be on the other
side. The B2BUA can emulate a phone being permanently connected to the SIP carrier.
Incoming calls for a SIP carrier can then be mapped to arbitrary users or even to the SIP
Proxy and hence an IP PBX. As such, it is possible to have the B2BUA also act like a virtual
gateway. The mapping between users and the SIP carrier accounts is done by a set of simple
Call Routing Rules (see ??) that can be defined.
2005-2008
c Comdasys AG 130
Figure 3.55: The Back 2 Back User Agent
2005-2008
c Comdasys AG 131
3.7.1.1 SIP Carrier Accounts
Here, it is possible to define a SIP carrier account. Refer to your SIP carrier for obtaining the
necessary information. Note that some SIP carriers use the same ID for the phone number
and the User Name. It is possible to have a whole list of SIP carrier accounts by filling out
all necessary fields, then pressing Add . In the following, we will explain the meaning of the
different fields that are available.
Username: Enter the Username for your SIP carrier account here. This Username param-
eter is used for authenticating you at your SIP carrier. Every SIP carrier usually requires
authentication which means that you must enter a value here. Not entering a value here will
cause the system to malfunction.
Password: Enter the Password for your SIP carrier account here.
Phone Number: The phone number is the number given to the user by the SIP carrier
usually without any prefixes. This should be the number you are reachable under within the
SIP network of the carrier.
Host: The host is the SIP server provided by the carrier. Usually they will provide a host-
name, but it can of course also be an IP address. The SIP server is also often called Registrar
or Registry Server.
Domain: The domain tag is the domain name that will be used in the ”from” Header of all
requests and that is expected in that header. The B2BUA manages an internal domain. Most
SIP carriers however do require their domain name to appear in the Header field. For most
SIP carriers, this domain is equal to their DNS domain name. This field can also be an IP
address instead of a domain name. In that case, it will most likely equal the host field.
NAT: This setting indicates whether there is a NAT between the Convergence and the SIP
carrier. If the Convergence itself is performing the NAT, there is no NAT in between when
considered from the perspective of this setting. If this option is checked, the Convergence will
send SIP Pings to keep the SIP signalling channel to the SIP carrier open. The SIP Ping is a
simple SIP OPTIONS packet that most SIP carriers will respond to because this mechanism
is routinely used by other SIP phones as well. Checking this option while not behind a NAT
will cause no harm, it will only cause network traffic.
2005-2008
c Comdasys AG 132
Attempt direct Media Connection: This parameter controls whether the B2BUA should
allow the endpoints to establish a direct media connection. This can be useful for e.g. fax
transmission. It however also might cause security problems, because it will allow a user
inside your local area network to establish a direct connection to the SIP carrier. Furthermore,
the firewall settings in the Convergence must permit this. With the default settings, the firewall
will allow the outgoing media connection from the phone to the SIP carrier. Since we have an
established session then, the firewall will also admit packets coming from the SIP carrier.
If you leave this button unchecked, the B2BUA will terminate the connection from the SIP
carrier. If you forward this call to another user in the B2BUA, a second call leg will be set up.
This means that the media stream will flow from the SIP carrier to the Convergence and that
the Convergence will set up a second call internally to the user. This elegantly circumvents the
NAT problem. This setup is very secure and means that the B2BUA can perform transcoding.
This means that you can use compressed codecs that some SIP carriers support (e.g. GSM)
with a SIP phone that does not support such a codec. This setup can have problems with very
restrictive firewall settings. Usually the Stateful firewall will detect the media streams with their
associated ports and let them traverse the firewall. Better than relying on the firewall setting
not to change however is to explicitly allow this traffic. The simplest way to accomplish this
is to make sure that you permit incoming UDP Traffic for the Convergence. Please refer to
the ?? section for further documentation on how to accomplish this. You can also make more
restrictive firewall rules for this by e.g. only permitting UDP traffic from your SIP carrier.
3.7.1.2 Users
SIP user accounts are very similar to SIP carrier accounts. The difference is that the Con-
vergence is now a server when considered from the connected phone. This means that you
have to use the information here to configure your SIP UA (User Agent) device or Softclient.
As with SIP carriers, it is possible to manage a practically arbitrary number of SIP UAs here.
Fill in the desired parameters, then click Add . In the following, we will explain the meaning
of the different parameters:
Username: Enter the Username the phone has to use for authentication here. You can
leave this field blank and also leave the field in your UA blank. Your UA will then be able to
connect without authentication.
Password: Enter the Username the phone has to use for authentication here. You can leave
this field blank and also leave the field in your UA blank. Your UA will then be able to connect
without authentication.
2005-2008
c Comdasys AG 133
Host: Enter an IP address or hostname if your UA is using a fixed IP address. When entering
this IP address, the B2BUA will always try to contact your UA under the IP address specified.
It will completely ignore the data sent in the Registration request. If your UA is not sending
SIP REGISTER methods, you have to fill in the parameter here.
Dynamic Host: Check this box if you want to use the information obtained via a SIP REGIS-
TER message to contact the UA. If this option is checked, the B2BUA will always try to contact
the UA under the IP address contained within the last REGISTER message of this UA. If this
option is checked, the Host parameter is completely ignored.
NAT: Check this option if your UA can be behind a NAT firewall. This can be the case with
mobile users coming from the Internet side. If this option is checked, the B2BUA will ignore
the IP addresses contained within the SIP REGISTER message if it does not equal the IP
address the IP packet has been received from. This situation forces the B2BUA to conclude
that the UA is behind a NAT firewall. The B2BUA will try to contact the UA not via its private
address, but will send the SIP message to the official IP address the request was received
from. This approach is very efficient since it will in most cases make the use of STUN in
the UA unnecessary. If your UA supports NAT discovery mechanisms, you will probably not
need to check this option. It should be noted that this option however does no harm if the UA
happens not to be behind a firewall.
Attempt direct Media Connection: This parameter controls whether the B2BUA should
allow the endpoints to establish a direct media connection. This can be useful for e.g. fax
transmission. It however also might cause security problems, because it will allow a user
inside your local area network to establish a direct connection to another user on the Internet
or to a SIP carrier.
If you leave this button unchecked, the B2BUA will terminate the connection from the UA. If you
forward this call to another user in the B2BUA, a second call leg will be set up. This means that
the media stream will flow from the first user to the Convergence and that the Convergence
will set up a second call internally to the other user. While this might be undesirable for purely
internal connections, it can elegantly circumvent the NAT problem when having one internal
and one external user. For more information, you can also consult the SIP carrier section ??
on page ??.
Codecs: Check all codecs that should be allowed for the specified user. Any codec not
listed here will lead to a call rejection, or at least a codec negotiation until one of the codecs
mentioned here is used. This can also be used to enforce certain policies. You can for
example allow only compressed codecs for all users coming in from the WAN side in order to
preserve bandwidth. These WAN users will then not be able to set up a call with e.g. G.711.
2005-2008
c Comdasys AG 134
3.8 Diagnostics
3.7.1.3 Call Routing Rules
After the configuration of the users and the SIP carrier accounts, we now need to define some
call routing rules. These rules will be used for making the appropriate connections. You have
to understand that each rule defined here only applies to a single direction. If for example we
define a rule that all numbers starting with a ”0” should be routed to the SIP carrier account,
this does nothing to the other direction. In order to accept calls from the SIP carrier account,
we need to define a second rule. The structure of the rules is very simple. You simply define
a Source and a Target for each rule.
From: Enter the number where the call is coming from. This can only be one of two things,
either a SIP carrier account, or a regular expression (there is no full regular expression sup-
port) identifying a certain number range. If you have multiple rules, these will be evaluated in
a best fit manner. You can enter simple patterns here to work with any number of prefixes.
Enter ”0*” to denote all calls starting with ”0”. To denote a SIP carrier account use the number
entered in the phone number field.
To: Choose either a user or a SIP carrier account. Another option is to route the call to the
SIP proxy. In that case, you however need to specify a number to which extension connected
to the SIP Proxy you want to route the phone. For that, it is of no interest in what mode the
SIP Proxy is configured. If it is for example configured in survivability mode, the call will be
passed on to the central SIP server that then forwards to the phone with the number entered
in the Number field.
Number: Number to be dialled if a call is forwarded to the SIP Proxy. See the description of
the To field for more information.
3.8 Diagnostics
3.8.1 Syslog-File
This page displays the last lines of the Syslog output the Convergence produces. The output
of this file is explained in more detail in the Command Line Guide. The output also depends on
the Syslog settings and the mode that is configured there (see ?? for more detailed description
of the possible settings here). If Debug is used there, a lot of information will be displayed.
The output can be refreshed by pressing the Reload button. It is also possible to adapt the
number of lines displayed, by entering the desired number into the Number of Lines field.
2005-2008
c Comdasys AG 135
3.8 Diagnostics
! By default, the Syslog file is stored in a RAM disk on the device. This means that the
information is lost after a reboot. In order to implement a persistent storage, an external
Syslog Server is recommended. It is however possible to move the the log file to the flash
from the CLI interface.
i The Convergence performs log rotation on a regular basis to avoid filling up the
storage space. This log rotation will compress the current syslog file. All files are stored in
the /var/log/ directory and can be accessed e.g. via WinSCP.
3.8.2 Logging
Here you can specify an external syslog server, on which all important messages from the
Convergence are logged.
Syslog is a standard for logging system messages under Unix and Linux and meanwhile also
many other platforms including Windows. It supports both local and remote (i.e. over the
network) logging.
If you wish to save system messages from the Convergence, you will have to specify the
computer, where the messages should be sent to and the log level for which messages should
be saved. This is especially recommended if the Convergence is operated as a firewall.
Figure 3.56: Logging
2005-2008
c Comdasys AG 136
3.8 Diagnostics
There are the following log levels in descending order:

• Debug: All messages are logged.
• Info: All messages, but real debugging messages are logged.
• Notice: All messages, that are important for the user are logged.
• Warning: All messages, that describe failures are logged.
• Error: All error messages are logged.
• Critical: All critical failure messages are logged.
• Alert: All messages that prevent a service from functioning properly are logged
• Emergency: All messages that prevent a service from functioning are logged
If there is no local computer that can act as a Syslog Server for saving these messages
available, you can either install a free syslog server available from the Comdasys website,
or you can use the local logging on the Convergence. This logging is however limited to the
space available on the Convergence. In order to enable the local logging, simply enable the
Local Logfile checkbox. For more information on the evaluation of such logs, please refer to
the Command Line Guide for additional information.
2005-2008
c Comdasys AG 137
3.8 Diagnostics
3.8.3 Debugging tools
The debugging tools allow you to easily track down the reasons for network connectivity prob-
lems over the web interface without knowing any CLI commands.
Figure 3.57: Debugging tools
The following tools are available:
3.8.4 Ping
Ping sends network packets to a computer and waits for the response while measuring the
elapsed time until a response arrives.
This program is able to examine if a computer is reachable or not. For this reason it is ap-
plicable for instance to check whether the connection to a certain host is working. You can
easily trace down the reason for connectivity problems by first trying to ping the first gateway
on the way, then the second and so forth. Once that fails, you will know exactly what link is
the problem.
3.8.5 Traceroute
This program traces the path packets from the Convergence to a certain host on the take. It
can complement and expedite certain debugging approaches taken with ping. Note that when
trying to trace routes over the internet, that some routers will block this attempt. You will then
be unable to get the desired result for a traceroute although the network connection is working
2005-2008
c Comdasys AG 138
3.8 Diagnostics
properly. Usually, traceroute is used after you have detected a specific network problem with
the ping tool to further narrow down the reason.
i If you assume that an internet connection is inoperable, you have to define the IP
address of your Convergence instead of your system name, because in this case the DNS
service could probably not be able to resolve system names.
The output is shown in realtime line after line. This means: if ping does not respond for several
seconds, the probability that the address is not reachable is very high.
2005-2008
c Comdasys AG 139
3.8 Diagnostics
3.8.6 SNMP
This menu item contains configuration of the SNMP Daemon.

The SNMP Daemon offers basic system informations and a service to monitor the Conver-
gence system status. This includes the surveillance of running processes, diskspace usage
and the CPU’s load average. There are following parameters that can be set up (compare
figure ??):
SNMP Basic Settings

In this menu section you can toggle the SNMP service on-/ off and configure the basic setup.
• Readonly password
Specify a SNMPv1 or SNMPv2c community that will be allowed read-only access.
• Read-/Write password
Specify a SNMPv1 or SNMPv2c community that will be allowed read-write access.
• Enable SNMP trap sending
This checkbox enables active monitoring. The SNMP Daemon will send traps in case
of a process not running or low diskspace. Beside this a trap is sent on starting and
stopping of the SNMPD Daemon.
• SNMP trap community name
Specify the community name which will be used in traps.
Trap destination
Here you can specify one or more ip-addresses as a destination for SNMP traps.
Proxy
This option enables the SNMP Daemon to act as a proxy, passing certain requests to a SNMP
service running on another machine. Following configuration settings are available:
• IP address
The IP-address of the machine to which the proxy should forward.
• Port
Optional: The port on which the target machine is listening for snmp. Default is port 161
• Password
The SNMP community string on the target machine.
2005-2008
c Comdasys AG 140
3.8 Diagnostics
• SNMP Version
Choose between SNMP version 1 or 2c
• Object-ID (OID)
Optional: Part of the OID tree which should be passed through to the target machine.
Default is the whole OID tree .1.3
Setting up the SNMP daemon

1. Check Active to enable SNMP daemon
2. Provide configuration details for basic setup as described above. Click Save to
save your changes. Your changes will be applied after selecting Apply configuration.
3. In addition to the Basic settings you can specify one or more Trap destinations
and Proxies to be used by SNMP daemon. Use Add to add an entry and fill the form.
Use to edit, or to delete an existing entry.
Figure 3.58: SNMP Configuration
2005-2008
c Comdasys AG 141
3.8 Diagnostics
3.8.7 Firewall Report
This section shows how many packets have been dropped and the matched firewall rule.
You can see the over-all number and size of dropped packets and additional information of
the matched rule (protocol, input/output interface, source and destination). Depending on
the direction of packets, rules are joined in three chains INPUT, OUTPUT, and FORWARD.
Information about dropped packets may be helpful for testing connections or improving your
firewall rules.
The information shown on this page is a summary of packets dropped by the firewall and will
be refreshed every time you choose this menu item or click Refresh . You can also reset
firewall packet counters by clicking Reset .
Figure 3.59: Firewall report
2005-2008
c Comdasys AG 142
3.8 Diagnostics
3.8.8 Trace File
Network debugging would not be possible without analyzing network traffic. A prerequisite
for performing such analysis, however, is collecting information, e.g. in form of a packet trace
created with a command line tool tcpdump. This page offers a simple interface for tcpdump.
Creating a new trace

1. Select a network interface you want to listen on from the dropdown box. In order to
gather information from all interfaces, choose ANY.
2. Additionally, you can input some options for tcpdump, as you would do on the com-
mand line.
You can specify port numbers, protocols, number of packets to be traced and many
other options. A trace file created by tcpdump can be then viewed by a network packet
analyzer such as Ethereal. However, an introduction to the network monitoring using
these tools would be far beyond the scope of this manual. Describing all options avail-
able with tcpdump would go far beyond the scope of this manual.
•-s0
Usually only the first 64 bytes of a packet will be traced. This reduced the size
especially of long running traces. Note that traces especially on the LAN interface
can get very large very quickly if no filters are specified. The -s0 parameter will
remove the 64 Byte limitation. The entire packet including the payload will be
visible in the trace file.
•port 5060
This will introduce a filter into the trace and only the packets with source or desti-
nation packets
•src host 10.10.10.10
This will restrict the tracing to all packets coming from the specified host.
•dst host 10.10.10.10
This will restrict the tracing to all packets going to the specified host.
•proto tcp You could also use protocols ip, icmp, udp here. This will trace only the
packets with the specified packets.
An example combining several of the above parameters would something like -s0 port
5060 src host 10.10.10.10 proto udp. This would trace SIP traffic (port 5060 and UDP
by default) coming from host 10.10.10.10.
2005-2008
c Comdasys AG 143
3.8 Diagnostics
3. Click on Start to start the trace. In order to stop and download the trace file, simply
click on Stop and corfirm saving the file to your disk. If you just want to check, whether
the trace is already completed (e.g. in case you have specified a maximum size of file
or number of packets to be traced) click on Status . Your trace will not be interrupted,
if it is still running.
Figure 3.60: Starting trace
2005-2008
c Comdasys AG 144
3.8 Diagnostics
Figure 3.61: Downloading trace file
2005-2008
c Comdasys AG 145
4 Enterprise Mobility (Fixed Mobile
Convergence)
4.1 Introduction to Fixed-Mobile-Convergence for the Enterprise
The vision of FMC is for people to use a single communication device with a single number,
taking advantage of less expensive, high-speed WLAN connectivity, while enjoying widerang-
ing mobility on existing Public Mobile Networks. FMC should provide the subscriber a con-
sistent user experience regardless of location and time-of-day with no interruption of service
when roaming between fixed-line (through Wifi) and mobile networks. The goal of FMC is
to break the paradox that arises from the fragmentation of communications channels and to
make multiple channels (networks) appear and behave as a single channel thus restoring the
core value of communications; improved productivity and reachability.
The Fixed-Mobile-Convergence functionality of the Convergence makes the use of handset
device flexible and independent of the used network infrastructure. This is achieved by con-
necting the Convergence to the PBX system. The mobile device can then be used as a PBX
extension both over the Wifi network, as well as over cellular. A mid-call handover from cel-
lular to WLAN and back is possible as the handset device supports dynamic detection of the
sufficient WLAN network coverage. The Convergence consists of two components, a Client
and a Server. In order for everything to work correctly, the client needs to be properly in-
stalled on the handset. Refer to the separate client documentation for more information on
that. According to the quality of the link over WLAN the Convergence handles media path for
the ongoing calls and carries out the handover of the media stream. While a handover will be
successful in most scenarios, the seamlessness cannot be guaranteed with an abrupt signal
loss. This situation is no different than commonly observed in contemporary cell networks.
Getting onto an elevator is a frequently cited example for such a sudden loss of connectivity.
The speech quality of WLAN calls does not differ significantly from the quality of calls set up
via cellular. The Convergence in conjunction with the client will select the right codec and also
otherwise do everything to guarantee the best possible voice quality. The Convergence can
also do transcoding to support specially optimized codecs on the WLAN side, while using gen-
eral purpose codecs like G711 on the PBX side. When doing transcoding, the Convergence
will need to have control over the media stream at all times.
2005-2008
c Comdasys AG 146
4.1.1 Accessing PBX Features with FMC
4.1.2 Basic Configuration Steps for FMC
Following configuration steps are necessary to configure your dual mode solution. Please
refer to the more detailed descriptions of the menu points above.
1. First you need to Configure a Number Profile. For more information refer to ??.
2. Configure SIP Endpoints. You need to specify a PBX host and if applicable a sep-
arate host for the incoming GSM callthrough calls. This second host will be used for
handling the callthrough calls, that are first connected to the Enterprise and only then
the actual called number is being dialed. You can provide a name for each host which
you will use later to associate e.g. Registrations. Choose a meaningful name that re-
flects the intended usage of this host to simplify the use in the other sections where this
name will be reflected. Click Add to create a new entry, fill the form and click Save to
save your changes. Use to edit, or to delete an existing entry. For detailed
description of the configuration parameters please refer to ??.
3. Configure Global Settings. There are several SIP and RTP related options to con-
figure. You will find detailed description of these in the sections above. ??
4. Callthrough Number You have to specify the dial-in (also called callthrough or tram-
polin number) to be used for handling calls initiated from the GSM network.
5. Configure Registrations. A registration represents the link of a configured user with
a user on the PBX. Click Add to create a new entry, fill the form and click Save to
save your changes. Use to edit, or to delete an existing entry. For detailed
description of the configuration parameters please refer to ??.
6. Create User accounts. Click Add to create new entry, fill the form and click Save
to save your changes. Note that you need to associate the user with a registration for
him to be able to make calls via the PBX. Use to edit, or to delete an
existing entry. For detailed description of the configuration parameters please refer to
??.
7. If not done already install license file for Convergence (refer to ?? for further details
on License Management).
8. Your changes will be applied after selecting Apply configuration.
! Note that the Numbers in the User account configuration must be unequal to the num-
ber used in the Registration. Having both sides equal can lead to weird behavior especially
when using features.
Besides the basic call functionality with a single phone number that is supported both via
WLAN and GSM Convergence provides a wide range of the standard enterprise PBX features.
2005-2008
c Comdasys AG 147
These features are signalled via SIP in WLAN, and via DTMF in cellular mode. The dual mode
client on the handset will make this fact completely transparent to the user. It will be possible
to access the features completely transparently from the handset. Any features described
here will also work through handoffs in both directions. The features described here equal
the features usually provided in a SIP phone. In order to make them usable through handoffs,
their implementation has been changed and distributed between the Convergence and the
client. It should be noted that also combinations of these features are usable. In addition
to these typical SIP client side features, the server based SIP features are also available as
described below. To avoid possible conflicts with systems provided by many operators such
as VoiceMail systems, accessing some features requires using more complex DTMF signals
than just a single digit. Following features are provided:
• Hold
• Toggle
• Consultation
• Conferencing (3pty)
• Transfer
• Combinations of the above
i Note that the selectable features can vary depending on the client, client version, as
well as the used PBX. Feature combinations that are not supported are not offered by the
FMC client.
i The transfer feature requires the PBX to support the SIP REFER message as de-
fined in RFC 3515. The implemented transfer mechanism is an unattended transfer with
a fallback function in case the transfer is declined by the PBX. In that fallback case, the
previous call is resumed.
In addition to the emulated SIP phone features, the server side features of the PBX can be
used. The number and type of features are very dependent on the connected PBX, but there
are some rules to tell what features are available. Many features in SIP PBXes are enabled /
disabled by using access codes. All of these features can usually be fully used in conjunction
with full dual mode operation. In addition to features enabled by access codes, some group
features are also usable via the dual mode handset. The following is a list of features that are
typically supported if the PBX supports this:
• Pickup
• Call Back
• Call Forwarding
2005-2008
c Comdasys AG 148
• Hunting
• Simultaneous Ringing
• Call Groups
• Boss Secretary
• ...
Depending on the implementation, keyset operation is also supported to a limited degree.

The great exception here is any features including indicator lamps, which are not supported
on the dual mode device. The reason for that is that the necessary keys and indicator lamps
are simple not present on a typical dual mode device. Depending on the used PBX, indicator
lamps are however supported passively meaning that if a dual mode device shares a keyset
line with an enterprise phone, and a call is present on the dual mode device, the enterprise
phone shows the inidcation that the other line is indeed busy.
4.1.3 Unified Communication Functions
Besides the above described telephony functionality the Convergence has been designed to
provide an overall and unified communication experience. This naturally does not only include
voice communication, but also Instant Messaging and Presence. XMPP (formerly known as
Jabber) is the industry standard protocol for that, and the Convergence support interacting
with such a server much the same way this is done with the PBX. In order to understand this,
we first have to explain some basic principles about XMPP / Jabber. The assumption is, that
an organization has its own XMPP Server.
The Jabber network is server-based (i.e. clients do not talk directly to one another) but de-
centralized; by design there is no central authoritative server, as there is with services such
as AOL Instant Messenger or MSN Messenger. Anyone may run their own XMPP server on
their own domain. Standard TCP port for Jabber is 5222.
Every user on the network has a unique Jabber ID (usually abbreviated as JID). To avoid the
need for a central server with a list of IDs, the JID is structured like an e-mail address with a
username and a DNS address for the server where that user resides separated by an at sign
(@), such as username@domain.com.
Since a user may wish to log in from multiple locations, the server allows the client to spec-
ify a further string known as a resource, which identifies which of the user’s clients it is (for
example home, work and mobile). This may then be included in the JID by adding a for-
ward slash followed by the name of the resource. Each resource may have specified a nu-
merical value called priority. For example the full JID of a user’s mobile account would be
username@domain.com/mobile. This is what the Convergence uses. It will register with the
XMPP server under a configured user name and as mobile account. Messages that are sim-
ply sent to username@domain.com will go to the client with highest priority, but those sent
2005-2008
c Comdasys AG 149
4.2 FMC Enterprise Configuration Introduction
to username@domain.com/mobile will only go to the mobile client. The configuration of the

priority depends on the XMPP server configuration.
The Convergence will take care of terminating all this signalling towards the XMPP server.
Now since the Mobile Client cannot always be online, the Convergence will handle the for-
warding, provide NAT handling for registration of the FMC client behind NAT firewalls, etc.
The same paradigms will be used as for the voice functionality, meaning that for the XMPP
server, the Convergence will act as the client. The FMC Server component will then take care
of abstracting things like baseband, connection properties, etc. to provide a convenient way
for the user to access these feature from his FMC client .
Please refer to the section ?? for more information on how to configure this.
4.1.4 FMC Interface and Port Handling
The Convergence has multiple network interfaces, that can in principle all be used for the FMC
application. The main interface that handles the connection towards the PBX is the LAN1
interface. The default SIP port for Client registrations is 5060. For the server registrations, the
Convergence will select a dynamic port for each SIP user. The port range for this is 12000
and higher, depending on the number of configured users.
If clients are to be used in different networks, or behind NAT routers, you need to utilize
the Session Border Controller component of the Convergence . This component will provide
security and NAT handling and ensures that all networks configured on the Convergence are
cleanly separated. This Session Border Controller component runs on all interfaces by default
and uses the port 5062 for UDP/TCP signalling and 5061 as TLS signalling. If you want to
make use of these features, you will need to point your client to these ports.
! The FMC application does not accept SIP signalling on port 5060 from any interface
except for LAN1. If you use a different interface, you will need to make use of the above
described SBC functionality.
! If you intend to use TLS, you should make sure to have correct certificates. You
can do this on the SIP TLS configuration section where you can either generate or upload
appropriate certificates.
4.2 FMC Enterprise Configuration Introduction
On the following pages you will find the detailed instruction of the setup of your FMC solution.
The configuration settings are divided into several different groups. First you may want to con-
figure the Global Options followed by the Numbering Profiles, the Endpoints, the Callthrough
2005-2008
c Comdasys AG 150
4.3 Global Settings
Numbers, the Registrations and the User Accounts. If you want to utilize the single number
functionality, you will also have to configure a GSM number for a user.
This means that the menu items in the Dual Mode menu is order the same way it should be
filled out.
i Note that the order of configuration does matter because certain information is re-
quired in order to be able to configure certains things. For instance, you do need a Regis-
tration representing a PBX account in order to configure a dual mode user.
i Registrations and User accounts might sound alike, but in the Convergence they
mean fundamentally different things. The appliance acts with two different identities for
each user. On the one hand, it acts like a server for the FMC Client. On the other side, it
acts like a client towards the PBX. In this manual, Registration is always used to refer to
the latter (the communication side with the PBX), whereas User Account describes the side
towards the handset.
4.3 Global Settings
The following section contains global settings necessary for the FMC component on the sys-
tem. Note that various fields have to be filled in for the system to work properly.
4.3.1 Global Settings / General Options
This part of configuration contains general settings concerning used PBX, SIP related features
and media stream settings. These settings are essential for operating your Convergence
properly.
Enable Callthrough early media

This feature supports the playback of progress indicator ringtones when using the call through
functionality. When setting up a call through the call through Interface, the FMC client will first
setup a call to the server via the callthrough (Trampoline) number. The server will accept the
call and use any extra digits or inband signalled DTMF digits to make a call to the destination.
It is now possible to play a progress indication during this time. Otherwise you will hear
silence until the other side is actually ringing. The ringback tone for the other side will always
be played back no matter if this feature is activated or not.
2005-2008
c Comdasys AG 151
4.3 Global Settings
Figure 4.1: Global Settings
2005-2008
c Comdasys AG 152
4.3 Global Settings
Figure 4.2: Global Settings
2005-2008
c Comdasys AG 153
4.3 Global Settings
Enable Client Early Media

This will prompt the Convergence to respond to all requests from the client for a call setup by
setting up an early media stream. Then all ringbacktones, busy signals, etc. are played back
inband. Note that this setting applies to connections toward the client only meaning that it es-
sentially applies to SIP connections only. For incoming calls that are extended to the cellular
side as well as for callthrough calls you need to check the Enable Callthrough Early Media
Setting. Contrary to that setting, this one has no dependency on the utilized PBX. It is some-
thing that is solely negotiated between client and Server. Therefore, the recommendation is
to put this setting to On because it enables the most consistent user experience for both SIP
and cellular calls.
Disable Inband DTMF detection

The Convergence supports three different mechanisms of detecting DTMF tones coming both
from the Client as well as form the gateway or PBX through the callthrough trunk connection.
By default, all DTMF tones will be detected automatically. The Convergence supports the
following mechanisms for DTMF detection:
• Inband signaling
• Signaling according to RFC2833
• Signaling via SIP INFO method
The Convergence does the automatic detection as follows. The Convergence will automati-
cally try to detect the DTMF mode the peers are using. It will do so after the connection has
been initialized and it has seen the first DTMF coming from the peer. Once it has identified
the used mode, it will continue to use it. A redetection is triggered by restarting the Dual Mode
Server.
Some gateways or PBXes support RFC2833 fallback meaning that they will send DTMFs both
inband and via RFC2833. This will lead to double detections on our side. If the peers does
this, you have to check this box to suppress inband DTMF detection. It is recommended to
use RFC2833 if your equipment supports this. If doing that, this option should always be
checked to avoid wasting resources on the inband DTMF detection.
! The correct detection of the used DTMF mode is not always possible. It can further-
more consume quite some resources especially if the Convergence came to the conclusion
that inband DTMF is being used. In order to avoid such problems, it is recommended that
you always disable inband DTMF if anything else is supported by the peers.
Disable Passthrough of Session Progress

Session progress is a message that can be signalled in SIP to show that the connection setup
is progressing. The Convergence supports this toward the client. It leads to the setup of an
audio stream even before the connection is completed. Through this audio stream, tones can
2005-2008
c Comdasys AG 154
4.3 Global Settings
be played back to give the user an audible feedback. Some PBXs also do that towards their
endpoints. As already noted, the Convergence will also provide Early Media to the client if
Enable Client Early Media (see ??) is enabled. By default, the Convergence will however pass
through the early media coming from the PBXs and forward them to the client. That conflicts
with the early media sent by the Convergence . Although the client can handle this, you will
hear both tones be played back, that from the PBX as well as the one from the Convergence .
If your PBX supports early media, and you want to activate early media towards the client on
the Convergence , you have to check this option. The other option is to not activate the early
media towards the client and leave this box unchecked. In that case the early media will be
passed through from the client and you get the progress tones from you PBX or your media
server.
Disable Number Converter

The Convergence supports a three stage number converting process:
• Source pattern to target pattern mappings defined by explicit rules (see ?? for more
information about this)
• Considering numbers as internal depending on their length (see ??)
• Automatic conversions based on the Number Profile settings performed here (see ??)
When checking this option here, the number conversion process will be completely switched
off. This means that any dialed number will be passed through straight to the PBX without
any modification.
Disable # as Feature Code

Previous versions of the Convergence supported DTMF feature codes in GSM modes that
started with the # sign. This is not ideal since the # sign is frequently used in Interactive Voice
Response systems. The Convergence has to wait for additional digits after seeing a # sign.
This leads to a delay of passing through the # sign.
This problem was solved with more recent versions of the FMC client . Those use different
sequences that do not create this sort of problem. You can therefore check this item resulting
in a better DTMF handling. This will however break the compaibility with former Client ver-
sions. GSM features will then no longer work. The list below should give you an overview, of
the client versions that are using this old signalling specification:
• fgVoIP V2.9.1
• fgVoIP V3.0.0
• fgVoIP V3.11
• fgVoIP V3.12
2005-2008
c Comdasys AG 155
4.3 Global Settings
Enable DTMF invoked Handover

This functionality is only required if you are using a non-supported client (as for example a
softphone) which could be the case e.g. for testing purposes. In those cases, you might what
to invoke a handover to GSM. Since the proprietary signalling is not supported by a generic
SIP client, you can use the following DTMF sequence to invoke a handover: **00. This will
make the appliance dial the configured GSM number for the respective user. If you pick up
the GSM call leg, you can terminate the SIP call. It will also be terminated automatically after
a brief period of time.
4.3.2 SIP Options
Options to be configured in this section affect the general behavior of the SIP related fea-
tures. This is especially relevant for the registration behavior as well as the NAT handling in
conjunction with the SBC component.
Domains
The SIP domain is sometimes important for digest authentication as well as for the request
URI formatting towards some PBXs. All messages orginating from the Convergence towards
the PBX will contain the domain you specify here in the appropriate SIP header fields (in all
places where you would normally find its IP address). If left blank, the IP address of the first
LAN interface will be used.
Registration expiration time

You can specify the default amount of seconds for all outbound registrations. Note that this
setting has absolutely no effect on the client side. It only specifies the registration interval
towards the PBX / Server. Reregistrations will be performed after half the time specified as
this parameter. Note that the PBX can always override the registration expiration timeout
by returning an expires parameter in the Contact Header or a separate Expiry parameter of
the OK response to the sent registration. Note that some PBXs also reject registration with
expiration timeouts that are too brief. If this is the case, you should increase the timeout
here.
i If registrations fail, please make a SIP trace. If you see registrations rejected with the
error request Interval too Brief, you will need to increase the timeout set here. By default,
many servers expect expirations timeouts between 1800 and 3600 seconds.
External IP for NAT

The external IP parameter specifies the IP address which will be used as the source IP ad-
dress for all SIP messages when NAT handling should be done. This implicitly defines the
external interface used for the NAT handling. It does not matter whether the interface for
2005-2008
c Comdasys AG 156
4.3 Global Settings
the IP address specified here is a LAN, WAN, or DMZ interface. For all messages arriving
through this interface on port 5062 (or port 5061 for TLS), NAT handling will be performed.
The Convergence can easily check whehter a NAT is involved. This can be done by checking
for private IP address ranges and seeing if the source of the message matches the source in-
dicated in the SIP signalling. Should this not be the case, NAT handling has to be performed.
This means that all messages must be returned through the firewall pinhole that the message
came from. The same holds true for the media stream. The addresses in the SIP header and
the SDP body will then in part not be considered. There is no need for the configuration of
any special handling on the client side.
i The Convergence when doing NAT handling will utilize a built-in Session Border
Controller for handling clients behind NATs. In those cases, the client needs to be registered
via port 5062. For TLS there is no such distinction since there NAT detection will always
be done by default (so port 5061 can always be used). This distinction is due in part
to security concerns. Explicitly not doing NAT detection makes the communication over
insecure links a little safer. The mechanisms needed to perform the NAT handling can
increase the liklyhood of such attacks as session hijacking. When using TLS as a signalling
protocol, this risk is not there because the signalling is done through a secure channel.
i Note that it is also possible to make use of an external Session Border Controller. For
that purpose simply configure the Convergence as a SIP server in the used Session Border
Controller and have the SBC forward the SIP messages to port 5060 of the Convergence.
Then the external SBC will perform the NAT handling.
Port Ranges
Due to the complexity of the product, the possibility to change the used port ranges has been
restricted to expert mode. The follwoing will provide some information on the utilized port
ranges.
2005-2008
c Comdasys AG 157
4.3 Global Settings
i Port Ranges for Signalling and Media Streams: For signalling the client must use
port 5060 towards the server. As noted above, ports 5061 should be used for TLS and
5062 for NAT handling (always towards the client). For the media streams the port range
16384 - 22384 is used. For NAT handling the ports 35000-36500 are used. A call requiring
NAT handling will use a port in the 16384 and up range in addition to a port above 35000
from where the media stream is forwarded to the appropriate PIN hole. The media stream
from the FMC Server towards the internal SBC component, the internal loopback interface
is used, so externally only the stream from port 35000+ can be seen. Note that the highest
port used depends on the number of simulatenously open connections. Note that a call can
have up to 6 different legs in a callthrough scenario. In the SIP signalling towards the PBX,
the ports 12000 and up are being used. Every configured registration will use its own port.
This usage of different ports is necessary because some PBX have problems if multiple
distinct registrations are coming from the same port and IP address. The media handling
port range towards the PBX is also 16384 - 22384. The port used for callthrough is also
5060.
! When using a client from behind a NAT firewall, it must be registered with port 5062
(or 5061 with TLS) which is where the Session Border Controller component is currently
running. Trying to register with port 5060 will fail because no NAT handling is performed
there. When using TLS, NAT detection is always performed automatically.
4.3.3 Outbound Proxy
This enables you to statically specify the next hop for all SIP messages towards the PBX. This
is often used for placing SIP Proxies or Session Border Controllers on the network edge for
protecting the Convergence and / or the PBX. This option will not really change the message
routing of the messages except for adding this static routing entry. When configured, the
Convergence will add a static route header to accomodate this statically defined next hop.
Other than that everything will remain the same as without an outbound proxy. If you want
more information about outbound proxies, please refer to RFC 3261.
Address
SRV name, hostname, or IP address of the outbound SIP Proxy (DNS SRV excluding the SRV
prefix). Please make sure the DNS settings in the Convergence are correct in case you are
using hostnames here.
Port
The port number will be ignored in the case you have specified a DNS SRV name. Otherwise,
the SIP messages will be sent out to the port specified here.
2005-2008
c Comdasys AG 158
4.3 Global Settings
i This setting will usually be used in conjunction with a large network where the Con-
vergence is for example placed into a branch office that is only connected to the PBX
through a WAN link. In those cases you will often find some device offering survivability
services in the branch office. In order to be able to use this service, all SIP messages have
to be routed through this device. In those cases simply specify the survivable proxy device
as an outbound proxy here.
4.3.4 Callback Number
Configure the phone number for invoking the callback functionality here. It must have the same
format as the number arriving from the PBX when a callback is invoked. The callback feature
tries to revert the direction of a call. This is usually done to make use of the cheaper rates
when making a call from fixed line to the mobile phone as compared to the other direction.
The following section explains the basic functionality of the callback feature:
• User dials a certain number in GSM mode (simply enters the number into the FMC client
and presses callback)
• The FMC client will initiate a call to the configured callback number
• The Convergence will reject this call and initate a call to back to the Client. Now the
direction of the call is reversed.
• The FMC client will pick up the incoming call and dial the actual number via DTMF (the
Convergence will play back ringtones etc.)
• The call is connected if the other party picks up
For security reasons, this feature will work only from GSM numbers known to the Conver-
gence . This means that only configured users will be able to utilize the callback functional-
ity.
i Callback is usually utilized in scenarios where the user is travelling abroad having
bought a national SIM card (e.g. prepaid card). This is registered into the system. When
making a callthrough call you would then however need to pay international call rates be-
cause the callthrough number is in the home country. In order to avoid that, simply invoke
a callback, and the incoming call will be free (or just airtime) on the phone.
i The client needs to support the callback functionality in order to be able to comfort-
ably use it. If the client does not support it, it can still be used manually by calling the
callback number, waiting for the incoming call and then dial the desired number.
2005-2008
c Comdasys AG 159
4.3 Global Settings
4.3.5 IMS Handover
IMS stands for IP Multimedia Subsystem and is a technology mostly driven by mobile oper-
ators to provide an operator centric approach to Fixed Mobile Convergence. This standard
defines a handover mechanism that is implemented by all compatible handsets. The Conver-
gence also supports this way of performing handovers. Contrary to the standard approach,
this mechanism works by having the client initiate the second call. This makes it much less
suitable for Enterprise use, because some of the control over the billing is lost. The IMS VCC
handover will work with all VCC compliant handsets and clients.
Whenever performing a handover between GSM and WLAN or vice versa, the client will hence
attempt to initiate a call to a preconfigured number. In the case of the WLAN to GSM handover,
a GSM call will be made to some fixed line phone number that needs to be configured here.
The treatment of this number should be similar to the callthrough number.
GSM to WLAN Number

This is a number that must be reachable over Wireless LAN. Since in WLAN, we are only
dealing with a pure Client / Server connection this can be any number you choose. To avoid
any conflicts, it should however still be unique in the context of your Enterprise network.
WLAN to GSM Number

This number must be a proper fixed line phone number. The routing on the PBX must be
configured to have this number routed to the Convergence . This number can be compared
to the Callthrough number, but it is only used for handover purposes.
4.3.6 Multiple GSM Number Support
Beyond being a dual mode solution, the Convergence will help you to facilitate your mobile
telephony experience. In order to lower roaming cost and to accommodate the communication
needs, many people own more than one SIM card and hence have more than one number.
These multiple SIM cards can be administered using the Convergence and activated from
anywhere thus always correctly forwarding the calls to the currently used number.
In order to support this feature, it is possible to configure multiple GSM numbers for each user
account (see ??. When we talk about multiple numbers, we speak about at least two and
potentially up to ten, although 5 should be some sort of practical limit. Switching between
those different SIM cards has to be possible without any data connection because it cannot
be guaranteed to be available when needing to do the switch. Therefore activating a different
SIM card should be possible simply by making a call to a special number.
The provisioning of this special number is done here by the administrator. By calling this
number with a provisioned SIM card will identify the calling user and activate the SIM card he
utilized. This implies that the authentication of the user is based on Caller ID. If this is a known
2005-2008
c Comdasys AG 160
4.3 Global Settings
user, the SIM card that he is currently calling with is assumed to be the active number. The
server will reject in order to signal the user that the switching was successful.
4.3.7 RTP Options
The RTP Options are used to set system wide behavior of RTP media streams such as time-
outs and sending of RTP keepalive packets.
TOS for outgoing media

Specify the TOS byte that is to be set in the IP header for all voice payload traffic leaving the
Convergence . It has been originally defined in RFC 791. The following 8 bits were allocated
to the Type of Service (TOS) field in the IP header:
• bits 0-2: precedence

• bit 3: 0 = Normal Delay, 1 = Low Delay
• bit 4: 0 = Normal Throughput, 1 = High Throughput
• bit 5: 0 = Normal Reliability, 1 = High Reliability
• bits 6-7: Reserved for future use
This field is now used for DiffServ and ECN. The original intention was for a sending host to
specify a preference for how the datagram would be handled as it made its way through an
internetwork. For instance, one host could set its IPv4 datagrams’ TOS field value to prefer
low delay, while another might prefer high reliability.
These bits have been redefined, most recently through DiffServ working group in the IETF
and the Explicit Congestion Notification codepoints (see RFC 3168). In order to set the field,
use a decimal number between 0 and 255. The value will be taken as 8 bits with the bitmask’s
meaning being explained above.
! Note that if you want to use FMC services across the WAN port, you will need to
use the separate 5062 (default setting) port for UDP messages. For TLS, you can use
the standard 5061 port. On port 5062 (deault setting), NAT handling has been enabled in
contrast to the standard B2BUA mode. If your messages arrive on the WAN interface, the
firewall will block those by default. It is however relatively easy to enable SIP and RTP traffic
on the WAN interface. Please refer to the ?? section for more information about this topic.
i Note that this setting applies only to WAN interface traffic. To perform generic DSCP
and TOS tagging, you have to define rules in the /etc/sysconfig/firewall.custom file
2005-2008
c Comdasys AG 161
4.4 Number Profiles
Generic DSCP and TOS tagging

To enable generic TOS / DSCP tagging, you have to add the following lines to the /etc/syscon-
fig/firewall.custom file.
iptables -I OUTPUT -t mangle -m layer7 --l7proto rtp \
-j DSCP --set-dscp 34
iptables -I OUTPUT -t mangle -m layer7 --l7proto rtp \
-j TOS --set-tos 16
The TOS and DSCP values must of course be changed to the desired ones. To accomplish
the same for the signalling, use the following lines:
iptables -I OUTPUT -t mangle -m layer7 --l7proto sip \
-j DSCP --set-dscp 35
iptables -I OUTPUT -t mangle -m layer7 --l7proto sip \
-j TOS --set-tos 17
Former Version compatbility

In former versions of the Convergence , it was necessary to set RTP Timeouts, and Keepalives.
This has all been automated with the newer version and there is no need to change these set-
tings. Nevertheless, we will explain the different timers here.
The RTP Timeout is the amount of seconds to wait for RTP traffic before classifying the con-
nection as discontinued, which will result in terminating this connection. This may be used for
dead peer detection and will reduce telephony costs in case of failure.
The default value is 30 and means that if no RTP traffic is received for more than four seconds,
the connection will be dropped. Note that this timer applies only from the dual mode device
towards the Convergence since there the connection towards the PBX must be terminated.
Contrary to the other directions, charges can be incurred on this leg.
i Note that there are some other predefined timeouts hardcoded to the B2BUA. As just
mentioned, the Convergence will drop any call after not having received RTP media for 30
seconds. This is called the RTP timeout and is used for hanging up dead calls. Note that
this timeout does not come into effect when having a call on Hold. If that is the case, there
is a timeout of 300 seconds. Meaning that after a call was on Hold for 300 seconds, it is
simply hung up because it is assumed that the party was forgotten or lost (e.g. when the
FMC user who put the other party on hold dropped out of the call).
4.4 Number Profiles
Every PBX is associated with a unique Number Profile. This profile defines how outgoing
numbers will be formatted towards the PBX. With some options, also the incoming numbers
2005-2008
c Comdasys AG 162
4.4 Number Profiles
from the PBX are modified to provide the correct Caller ID display on the client. The goal is
to always have dialable numbers especially after receiving a call. The number in the Call Log
is then assumed to be in the E164 format so that it can be dialed both via WLAN as well as
over the cellular network. However this cannot be assumed from a number coming from a
PBX. With some PBXs sepcial number formatting would need to be done. With others it is not
even possible to format the numbers approrpiately. This is when the Convergence needs to
take over this job. Note that it is possible to define additional mappings through the Number
Patterns page. The parameters set here in the number profile will be used by the number
converter for formatting outbound requests.
The FMC number converter performs its operations in 3 stages:
1. Source pattern to target pattern mappings defined by explicit rules (see ?? for more
information about this)
2. Considering numbers as internal depending on their length
3. Automatic conversions based on the Number Profile settings performed here
When a match is found in a specific stage, all following stages are skipped. The exception to
this rule are the ??. There the Treat As field determines if further processing is done or not.
Select the Number Profiles menu entry, and you will see the following mask (the content as
always will vary depending on your configuration):
! Note that by default there is no number profile configured. You however need to
configure at least one to proceed. This step is crucial since it determines how numbers
are sent to your PBX. If you make mistakes here, it will lead to no connections or wrong
connections at a later point in time.
i The fields Country Code, Country Prefix, Area Code, Area Prefix have to be set if you
want to have the Convergence operate correctly. Note that numbers on the cell phone are
typically dialed in E164 format and therefore need to be reformatted by the Convergence .
You can add arbitrarily many number profiles. Each number profile must be associated with
a PBX. You can also define multiple SIP Host referencing the same PBX but using different
Number Profiles. This will however be considered later. First we want to define a general
Number Profile.
• Name
This is a name identifying the number profile in the other masks. You will need to use
this name whenever you are referencing the number profile defined here.
2005-2008
c Comdasys AG 163
4.4 Number Profiles
Figure 4.3: Number Profiles Configuration
• Country Code The country code is the international prefix number of the country the
host is located in. This paramter is used in conjunction with the City Code to correctly
compose numbers for outgoing calls.
You have to specify it with leading zeroes instead of the plus sign, e.g. 0049 instead of
+49. The + sign will be handled automatically on the client side already, or on the GSM
side if we are dealing with a callthrough case.
Note that this setting only applies to numbers dialed from your mobile device. Whenever
you dial a number that starts with your own country code, the Convergence will strip
away this country code before extending the call to the PBX.
• Country Prefix Prefix to denote that a country code will follow, e.g. 00. This is required
for properly converting E164 numbers. As briefly mentioned before it will be 00 for most
countries, but in the US it is for example 011.
• Area Code The Area Code is used in conjunction with the Country Code to correctly
compose the numbers for outgoing calls. Note that this only applies to numbers dialed
from the mobile device. Whenever you dial a number that starts with our own city code
(relative to where the Convergence is positioned), the Convergence would strip away
its own Area Code before sending to the PBX. Note that the area code also has to be
specified without any leading zeroes.
2005-2008
c Comdasys AG 164
4.4 Number Profiles
• Area Prefix Enter the number you have to dial on your phone before making a long
distance call. In the US this is a 1, in most European countries a 0.
• Outgoing Prefix With this parameter you can specify the prefix required for getting an
outside line with your PBX. In most cases this will simply be a single digit. Note that this
digit will not be prefixed if the Convergence identifies a call as an internal call.
• Fixed Prefix A fixed prefix can be added to all numbers sent to the PBX. This can be
used for a variety of reasons where you want to know in the PBX that this is actually an
FMC call. This could e.g. be used for doing a special treatment in the billing or a least
cost routing implementation.
• Internal Length Numbers that do not exceed this length will always be considered as
internal numbers. This setting is authoritative for Stage 2. Sometimes there is no real
pattern to internal numbers. Mostly however, internal numbers have a maximum length.
Since there are few real numbers with three digits. To disable this you should set this to
0.
• Remove Prefix
This prefix will be matched against any calls coming from the PBX. If a SIP From header
contains a number with this prefix, the prefix will be removed from this number. This will
however only be done if the call is forwarded directly to the WLAN side of the user. When
forwarding to GSM, the modification is usually not done because the PBX will also do
some number processing. If you want to have the number modification also done if the
call is forwarded to the GSM side, the ?? box must be checked also.
• Use Remove Prefix for GSM
This option activates the removing of the prefix in a SIP From header for a case where
the call is forwarded to the GSM side of the Called User. See ?? for a more in depth
description of this.
As briefly mentioned above, these parameters will be used to do a conversion in three steps.
The first step is an explicit specification as described in ??. If nothing matches, an automatic
conversion in two steps is done
Number Conversion Stage 2

Numbers that are considered as internal by their length. Stage 2 was meant to enable special
treatment for short numbers, meaning Never touch numbers that do not exceed length X, even
if they start with e.g. the outbound prefix. If you do not want these exceptions, just set the
Internal Length value to 0. Then Stage 2 is completely disabled and all numbers undergo
automatic conversions as described below. If Internal Length is set to anything greater than 0
, only numbers that are longer will ever see Stage 3, all short numbers are left untouched.
Number Conversion Stage 3

1. A leading + character is replaced by the country prefix as configured.
2005-2008
c Comdasys AG 165
4.4 Number Profiles
2. The number is checked to see whether it starts with the country prefix followed by the
country code and area code, as specified if so, the number is flagged as outgoing and
the country prefix together with the country code and the are code are removed.
3. If the previous does not apply the number is examined whether it starts with the country
prefix followed by the country code (without area code) if so, the number is flagged as
outgoing and the country prefix together with the country code are replaced by the area
prefix.
4. If the previous does not apply, the number is checked to see whether it begins with the
area prefix and the area code as configured if so, the number is flagged as outgoing
and area prefix together with area code are removed.
5. If the previous does not apply, the number is checked to see whether it begins with a 0
if so, it is flagged as outgoing.
6. All numbers that are flagged as outgoing are prepended by the dialout prefix as speci-
fied.
7. The fixed prefix (if configured) is prepended to all numbers.
! Note that there must be a valid number profile before you can define a SIP Host.
2005-2008
c Comdasys AG 166
4.5 Endpoint configuration
In order to be able to configure any users, you must first configure the SIP endpoint you want
the Convergence to work against. The SIP endpoint will be some sort of SIP Server, typically
a PBX. A SIP server can be one of the following:
• SIP capable PBX

• B2BUA or Softswitch
• SIP Proxy
• Gateway able to handle registrations
Each configured host may have a wide variety of different configuration settings. The most im-
portant ones are the network addresses, authentication options, as well as some SIP settings.
You will have to assign a Number Profile to each enpoint.
! At least one SIP Endpoint has ot be configured before you will be able to do any
further configuration.
Figure 4.4: SIP Hosts configuration
2005-2008
c Comdasys AG 167
Common name
The common name of a SIP host uniquely identifies it. This name will be used throughout all
further configuration. It may be the hostname or DNS name of the configured host, but it does
not have to be. It is used for internal purposes only and should be descriptive because it is
used in other configuration pages.
Hostname/IP Address
This setting enables you to specify the address for a SIP host either as its IP address or as
a fully qualified domain name (FQDN). If you are going to use the FQDN you need to make
sure that the Convergence is able to resolve the configured FQDN correctly.
Port
In some configurations it is necessary to specify the port on which your desired host listens
for incoming SIP connections. The default is to connect to port 5060, the standard SIP port.
If that is okay for your use, you can simply leave this field blank. This should work for most
configurations.
The most frequent reason for using a non-standard port are security considerations to use
a non standard ports for making an attack more difficult. This approach can make denial of
service or other attacks more difficult by obscuring that the Convergence is actually a SIP
aware device. A lot of the scanning bots used for trying to determine vulnerable systems on
the Internet only check for these standard ports. Note however that by obscuring the port
cannot and must not replace real security mechanisms such as digest auhthentication.
Realm
The realm parameter specifies the authentication realm used when connecting and authen-
ticating to the SIP endpoint / host. If the host is behaving completely compliant to the SIP
specifications, it should reject any attempt to register with the wrong realm. All devices con-
nected to the Convergence must hence belong to the same authentication realm to work
together. Although the n otion of a realm is cleanly specified in RFC2543, many UAs fail to
implement it. These then simply ignore the parameter. Therefore, the likelihood is very high
that registrations will work even without setting this parameter.
Preserve Caller ID
This setting applies to incoming calls that are extended to the cellular side of the dual mode
device. If disabled, a special header field is added to preserve the Caller ID of the orignially
received call, while enabling the call to be correctly billed to the called FMC user. Some
PBXs however do not support this special header which is why the From: header needs to
be overwritten. This however will most likely break the billing of the used PBX. Below, both
options are explained in more detail. When in doubt, simply leave disabled.
2005-2008
c Comdasys AG 168
• Disabled The Convergence will add the SIP P-Asserted-Identity Header to message
setting up the cellular call leg towards the dual mode device which contains the Caller
ID of the original call. In order to ensure the correct billing of the call, the From Header
will show the Enterprise number of the called dual mode user. The same holds true for
the Contact: Header. Most PBXs should be able to setup the call with this SIP message.
The important part however is that the original Caller ID is correctly passed on to the
voice gateway. Some PBX also interpret the P-Asserted-ID header and put it into the
From: header towards the gateway. Others simply pass it through to the voice gateway
and rely on that to do the call properties translation to the Caller ID. This is the default
behavior.
• Enabled If enabled the Convergence will simply replace the From: header with the origi-
nal Caller ID. This will almost certainly break billing and make some PBXs reject the call
(because it is not coming from any known user). For others not supporting any special
headers however, this might in fact be the only way to get the Caller ID information right.
The result of the above can be one of two things. Either the user sees the correct Caller
ID of the original caller, or he sees the his own office number / the enterprise trunk number.
The first alternative is of course the preferable one, however not possible in all combinations,
especially if the correct billing is required.
! Even if all of the above is properly supported by the PBX and the Caller ID gets
sent out correctly it might still not arrive on the other side. Most carriers will screen the sent
Caller ID information and restrict the number range to that of the Trunk connection. All other
numbers will usually be replaced by the head number of the Trunk the PBX is connected
to. In order to enable all Caller ID information to come through, you must have the No
Screening feature enabled on your PSTN trunk.
Available Codec
Please select the preferred codec towards the PBX. This codec setting will become effective
whenever a call is terminated on your PBX, or on an IP phone / Gateway connected via your
PBX. The codec set here will always represent the first codec offered in the signalling between
the Convergence and the PBX.
2005-2008
c Comdasys AG 169
i The Convergence supports both the G.711 alaw and ulaw codecs towards the PBX.
Both codecs are always offered, so the PBX is completely free to determine the used codec
by selecting its preference. The use of compressed codecs is not possible and not recom-
mended on this side of the Convergence . Typically compressed codecs are used on the
mobile device, and transcoding to a different compressed codec would seriously degrade
the quality. On the mobile device side, using a compressed codec such as ILBC or GSM
is even recommended because it is less straining for the WIFI network. On the other hand,
especially ILBC is very resilient in bad network condition and could even lead to better voice
quality under certain conditions. When using the FMC client across a WAN connection, the
use of a compressed codec is highly recommended.
Number Converter Profile

You need to select a valid Number Profile for creating a host. Not doing so, will lead to the
creation of the host failing. In order the see how you can configure a converter profile, please
refer to ?? for more information.
! Note that at least one Number Profile needs to be selected for an endpoint. It is
not possible to configure an endpoint without a number profile. Before forwarding a call
to the PBX, the Convergence will enforce the configured number profile against the dialed
number. This is one of the key concepts in FMC. While the cell phone now is an enterprise
phone, numbers are assumed to be dialed in E164 or abbreviated E164 format. This is
done to provide a uniform behavior between plain cellular mode and enterprise mode. It
would be very inconvenient if the stored contact only worked in one of the two modes. The
Convergence will do the number formatting, so that the SIP endpoint will only get proper
enterprise numbers.
Local Interface
Specify the interface to be used for sending / receiving the SIP messages. It will be the IP
address of the configured interface that the PBX will see in all messages. It has to be able
to return messages to this IP, so all routing and security settings on involved firewalls need
to be set appropriately. Different SIP endpoints can be configured to use separate network
interfaces. This enables a clean network separation as is sometimes required for security
purposes.
2005-2008
c Comdasys AG 170
4.6 Callthrough Numbers
Figure 4.5: Callthrough Number
The dial-in (also called callthrough or trampolin number) routes cellular calls through the en-
terprise PBX to keep all supplementary services working. In addition to that, this enables a
true single number service, where the callee will always see the enterprise number. When you
are in the cellular and dial a number, this callthrough number will be dialed by the FMC client
followed by the number of your desired target. The sequence of events is that the mobile user
first sets up a call to the Convergence , and it will then forward the call to the right destination
through the PBX. This usually works without first picking up the call (one-step-dialing).
Sometimes however, this might not work without answering the call because PSTN providers
will cut the resulting phone number after a fixed amount of digits. Numbers up to 18 digits are
supported by most providers. These 18 digits must suffice for both the Callthrough number,
as well as the dialed number.
In that case, your client will make use DTMF dialing (check the client documentation for more
information on that). In that configuration, the Convergence will accept the call and then
listen for a DTMF sequence. The client will signal the callee number via DTMF which will
subsequently be translated to SIP and dialed through the PBX (two-step dialing).
2005-2008
c Comdasys AG 171
! The dial-in number must be specified exactly as the Convergence receives the call
from the media gateway or the PBX. This means that the number should not contain any
prefixes that are stripped by the PBX. If the callthrough number is not working, please check
in a trace that the SIP INVITE message sent by the PBX or media gateway contains exactly
the number specified here.
! The dial-in number is only usable for configured users. This is essential for security
purposes. In order to authenticate the users, the Calling Party number field is used. In most
countries, the accuracy of this number is guaranteed by law and accordingly enforced by
the carriers.
It is possible to specify multiple callthrough numbers here. The assumption is a large organi-
zation with PSTN break-in / break-out in several countries and or locations. In those cases it
is advisable to always use the nearest dial-in number. If you are travelling abroad for exam-
ple, it is most of the times cheaper to use a dial-in number at your current location rather than
always calling home.
Callthrough Numbers Configuration Options

• Number: This field should contain the number exactly as it is called from your PBX or
media gateway. Make sure to not have any additional prefixes or suffixes in here.
• Active: This field Activates/Deactivates the callthrough number. If the number is not
activated, the call to it will be rejected.
• Local Port: The local port will determine the port on which the unit will listen to receive
callthrough calls from the PBX / the media gateway. Signalling here is always SIP UDP.
• Interface: Defines the local interface to be used when communicating to the SIP Server
providing this callthrough number. Even a dedicated interface can be used here. It
is also possible to make use of the WAN interface here to implement the callthrough
number e.g. through a SIP Trunk.
• Active Registration: Enables registration of this Callthrough Number on PBX. In some
PBX it is easier to let endpoints (even if this is a trunk connection) register dynamically
rather than doing a static configuration. This is required for some SIP Trunks. It can also
be required if the SIP host handling the callthrough number is behind a firewall. With the
regsitration information a suitable PBX can even do NAT handling and it would hence be
possible to have the Convergence and the PBX in two completely separate networks.
• Registration IP: Without doing active Registrations, the Convergence will accept all in-
bound calls to the specified number on the above defined interface and port. When
registering to the IP specified, only calls from this host are accepted. Note that it is also
possible to specify a hostname here that has to resolve correctly.
2005-2008
c Comdasys AG 172
• Port: Describes the port of the SIP host the callthrough number should be registered
against.
• Registration Password: In this case the configured number will be used as Request URI
and username for registering with the PBX. This field is for configuring the password
used for digest authentication.
i In case the callthrough number does not work you should check that the number is
configured without any prefixes / suffixes. In order to check you can make a trace of the call
coming in across your PBX. Check the Request URI and the To to exactly match the above
specified number. If the call is rejected, the user cannot be authenticated. This could also
have to do with the Caller ID. The Convergencewill check up to 10 digits. If less digits are
coming in across the gateway, these need to exactly match the configured number. This is
necessary for security purposes, because otherwise the number cannot be guaranteed to
be unique. If you have a number with less digits, the prefix in the Caller ID of the incoming
call also has to match the configured number
2005-2008
c Comdasys AG 173
4.7 Registrations
4.7 Registrations
Figure 4.6: SIP Registrations
It is very important to understand the notion of a Registration. The Convergence provides a

layer of abstraction between the PBX and the mobile device. The PBX for example does not
even know if the device is currently in WLAN or in GSM. Therefore, the Convergence needs
to perform this abstraction. SIP signalling is used both towards the PBX as well as towards
the FMC client. This fact leads to some confusion between Registrations and User Accounts.
Both however are in fact competely different.
A Registration always refers to the PBX side. The Convergence regsiters to the PBX just like a
normal endpoint would. On this side, nothing is known about WIFI or GSM, the Convergence
will always use plain SIP signalling towards the PBX. The User Account on the other hand
manages the communication with the WLAN side of the FMC client.
You therefore always need to define how the Convergence registers with the PBX, even when
using a GSM only client. In a normal configuration, you need one registration per FMC user.
The Convergence will not allow multiple users to be assigned to the same registration. Note
that this information depends on the SIP host you want to register the Convergence and the
handled users to. You will need to configure the registration details as well as a SIP Host to
register to.
2005-2008
c Comdasys AG 174
4.7 Registrations
i At least one SIP Endpoint has to be configured because each Registration has to be
made against a SIP Endpoint. Please refer to ?? for more information on this.
PBX Number
The number of the dualmode handset as registered on the PBX. Note that this number must
also be set on the PBX. The Convergence will use this number to register with the PBX.
Somtimes this parameter is referred to as SIP URI in PBXs.
PBX Username
The username used to register and authenticate on the PBX. Together with the password
defined below, this information will be used if there is a digest challenge from the PBX. The
Convergence supports the auhthentication both for the REGISTER as well as for other SIP
requests where the Convergence is challenged.
! The username should be indentical to the PBX Number because anything else might
be unsupported by certain PBXs.
PBX Password
The password used to authenticate on the PBX. This field may be left blank if no authentication
is required on your PBX. If you want to be using full authentication, you should also use a safe
password here, as specified in the ?? section.
SIP Host
Select the host you want to register this account to. Please refer to the ?? page for more
information on configuring different SIP Hosts / Endpoints.
i Note that a Registration will only become active once a User Account has been
associated with it.
2005-2008
c Comdasys AG 175
4.8 User Accounts
4.8 User Accounts
Each of the SIP user accounts represents an FMC subscriber. As described above, the User
Account is solely responsible for handling the communication towards the FMC client. In order
to associate a User Account with the PBX, a Registration has to be assigned to each User
Account. The following should provide an overview of the necessary details that need to be
configured for each user account.
Figure 4.7: SIP User account configuration
2005-2008
c Comdasys AG 176
4.8 User Accounts
SIP Number
The SIP number is the number the client uses to register with the Convergence . It must
be different from the PBX number, although it can just be different by prefixing something to
the PBX number or e.g. by omitting the country code. This differentation is enforced by the
GUI and is necessary to enforce a very strict separation between the PBX and the FMC client
side. You should also note, that this number has to be unique across all users configured in the
Convergence. The FMC client will use this number for registering against the Convergence.
! The SIP Number has to be unique in two ways. Firstly this number must not be
assigned twice for two different users. Secondly, this number must be different from the
Registration number used with the Server. If you do not follow this rule, you might see
strange effects on the server side that have to do with the nature how incoming SIP mes-
sages are mapped. If you ever see the SIP error message 488, please check all the utilized
numbers for uniqueness. The GUI will enforce this uniqueness as far as it can. Dupli-
cates however can still be introduced e.g. via database batch import, or by accessing the
database directly.
i The SIP number is also used for authentication of the client. Contrary to the Reg-
istration side, this setting is used for both identification and digest authentication. That
means that this number has to be configured into the Client both as a URI as well as for
authentication purposes.
GSM Number
It is possible to assign multiple GSM numbers to a user. This table will always reflect the
currently active number for the user in question. You can select a number form a drop-down
box here. You can also leave this field blank. Doing so will result in the user being unable to
use the system in cellular mode. If a GSM number for a user is configured after the user has
been created with a blank number, the newly configured number will automatically become
active. See ?? for more information on the configuration of a GSM number.
SIP User Password

The password for the SIP user on the FMC client side. This password is solely used for client
authentication and hence must be entered properly into the client.
i Whenever the client Registers with the Convergence, you will see a SIP 401 response
challeging the client. This will prompt the FMC client to resend the original request with the
correct digest information. If this is again rejected, there is probably a password mismatch.
That is the most obvious reason that you should check
2005-2008
c Comdasys AG 177
4.8 User Accounts
i If you want to ensure security it is strongly recommended to use safe passwords

here, containing at least 6 characters including special characters. You should also make
sure not to use dictionary words in this case.
Registrations
Every FMC user must be associated with a user on the PBX. This will determine how the
dual mode user is reachable, under what phone number, the call groups he is part of, etc.
The Convergence must be given the information it needs to register this user with the PBX.
This information is entered in the ?? section. Here you only associate an FMC user with the
account on the PBX.
! Every users must be associated with a registration. If you do not select a registration
here, the creation of the user will fail.
i Whenever you check the Registrations, those will only become active once a User
Account has been associated with them. This means if you have configured Registrations
that have no User Account associated with them, you will not see them register with the
PBX until this is the case.
Enable User
This item has to be checked for a user to be able to use his account. If not checked, the
user is essentially disabled. The user will not be able to register, not be able to make calls. If
disabled, the number of this user will also not be available in cellular operation.
Enable Static Roaming

Static Roaming is the term for forwarding an incoming call to the GSM side of the FMC client
. Depending on the contracts you have with a carrier, this can mean cost for incoming calls
of users. Therefore you can disable this feature on a per user basis. In order to enjoy the full
feature set of the Convergence and especially the single numnber features, you should keep
this enabled.
Use DMC
DMC stands for Direct Media Connect. This is a mechanism for letting payload pass directly
between two IP communication endpoints. In the FMC case this would typically be the FMC
client in WLAN mode communicating with an IP phone connected through a PBX. DMC be-
comes active after a call is established. The media is then renegotiated to let the two parties
communicate directly. This is done using SIP ReINVITE requests mechanisms. As soon as
features are involved, or a handover occurs, the direct media connection is cancelled and
2005-2008
c Comdasys AG 178
4.8 User Accounts
media passes across the Convergence again. This means that during a dialog, the media
connection can change multiple times between direct and indirect media connection. DMC is
activated on a per user basis and is turned off by default.
! DMC will only be attempted in WLAN mode. DMC will also only be attempted if the
user registers locally and is not behind a NAT firewall. In those cases the Convergence
needs to stay in the media stream because those devices could not establish a direct path
of communication.
! DMC will only work correctly if the proper codecs are set. The FMC client needs to
utilize a codec that is also supported by the endpoints directly connected to the PBX. ILBC
is typically not supported by gateways or IP phones.
Former version compatibility
NAT Handling
You do not need to enable anything special for NAT handling. All you need to do to enable
NAT handling is use the target port 5062 on the client. Using this is only recommended if you
actually want to use the handset behind a NAT. If port 5062 is used, and the Convergence
detects that the device is not behind a NAT, it will act normally as if port 5060 was used.
However this detection will take extra effort and is thus unnecessary. If the NAT handling port
is used, the Convergence will use the origin information of all SIP messages and all RTP
traffic from the client to determine where to respond to. This will enable NAT traversal without
any special features on the client (such as STUN).
Enabling NAT Keepalives

If the handset is behind a NAT, it is necessary to have a constant stream of messages to keep
the firewall pinholes open. If the NAT handling port is used, the Convergence will automatically
send NAT keepalives at an interval of 20 seconds. These NAT keepalives are empty UDP
packets. These are very small, but enough to keep any NAT pinholes on the way open. On
the client side, the TCP/IP stack will already consume these empty UDP packets. Thus, no
special settings are necessary on the client side.
i Note that all user changes will take effect immediately after saving without press-
ing Apply Configuration. Note also that this behavior has changed compared to previous
version.
2005-2008
c Comdasys AG 179
4.8 User Accounts
! When deleting a user, this deletion will cascaded to all data associated with this user.
That would be Call Forwardings, GSM Numbers, as well as Registrations. Please make
sure that this is what you want before confirming the deletion.
2005-2008
c Comdasys AG 180
4.9 Number Conversions
GSM Number
In order to provide a true FMC solution, the FMC client also needs to be integrated when in
the cell phone network. The connection to the FMC client in those cases is the GSM number.
The GSM number of the handset is use for static roaming, mid-call handovers as well as
callthrough calls.
You must specify the number exactly as you have to dial it on the PBX for creating an outbound
call. If you need a leading zero there for makinga PSTN call, you also have to specify it here.
• SIP User: You need to select a user to create the GSM number for. You can of course
create multiple GSM numbers per user. Those numbers can be activated in the User
Account settings or by calling the configured GSM switching number to activate the
currently used SIM card / GSM number. You can also refer to ?? for more information.
• GSM Number: This is the GSM number of the handset. As mentioned above, this
number is utilized without doing any mappings for static roaming calls and must be
configured exactly as they need to be dialed with the configured SIP Endpoint.
i The first number created for a user is automatically set as the active number for the
specified user.
! Each GSM number needs to be unique in the entire list of configured numbers. The
reasons lies in the necessity of the Convergence to uniquely map an incoming GSM call to
a user. This would not be possible if the number was configured more than once.
! If the GSM number has 10 digits or less, it must exactly match the Caller ID in
callthrough scenarios. The Convergencewill check at least 10 digits to make sure that a
number does not accidentally match.
The Number Pattern page can be opened by pressing the menu option in the navigation
page.
The mask allows you to define source and target patterns, activate/disable, delete, edit, move
(up/down) a rule and add new ones. The rules are processed from the first to the last. The first
match will be used to apply the appropriate mapping. All in all, the Number Patterns defined
here have priority over the automatic conversions defined in the Number Profiles section.
Both however can work side by side, if the Treat As parameter is set to something other than
Internal Call because the standard number mapping will also be done then.
2005-2008
c Comdasys AG 181
Figure 4.8: Number Patterns
2005-2008
c Comdasys AG 182
Source to target pattern mappings are defined by explicit rules. Incoming Numbers (the num-
bers will be calls coming from the client) that match a source pattern are reformatted as
defined by the target pattern. The source pattern can be any Perl Compatible Regular Ex-
pression (PCRE). Every expression entered will be checked for validity but not for semantically
making sense, so beware! The same holds true for the targert pattern. The target pattern can
only consist of the digits (0-9) and dollarsigns ($). Whenever a piece of a source pattern is
enclosed in brackets, it will be considered as captured subpattern that could be inserted in
the target pattern by using a $ followed by the number of the bracketed pair. Up to 9 captured
substrings can be used. For example, assuming that a leading 0 is used to dial out, then any
of the following definitions shall map the incoming number 911 to the outgoing number 0911,
making it possible to call 911 directly from an internal phone:
Let us consider these examples:
Source Pattern Target Pattern Active

(9)(1)(1) 0$1$2$3 Yes
(9)(11) 0$1$2 Yes
(9)(1)1 0$1$21 Yes
(911) 0$1 Yes
911 0911 Yes
Table 4.1: Number Mapping Example I
! Note that this 911 should only be understood as an example. Emergency num-
bers (depending on country) will automatically handled by the client and will be forwarded
through the GSM network.
! You should be very careful with this function because wrong rules can destroy the
called party numbers thus rendering the whole solution useless. It can also lead to miscon-
nection due to wrong number mappings.
The rule in the middle starts the target pattern with a literal 0, copies the content of the first
and second bracket pair (1and2) and appends a literal 1. Most likely you would use the last
rule since the source pattern is constant and this rule definition has the best readability. In
cases where an incoming number matches several source patterns, the first matching pattern
wins, i.e. as soon as a match is found, no further matching is tried. Copying parts of a
source pattern becomes useful when the source pattern contains wildcard characters. E.g.
assuming you want all numbers that begin with 0005 or 0006 to be mapped to 55505 or
55506, respectively, followed by the rest of the number, you could define:
The first bracket pair matches one of the ciphers 5 or 6 and captures the cipher as $1. The
dot within the second brace pair (captured as $2) matches any single character while the
following plus sign specifies to repeat the last pattern one or more times. Please note that
2005-2008
c Comdasys AG 183
Source Pattern Target Pattern Active

000([56])(.+) 5550$1$2 Yes
Table 4.2: Number Mapping Example II
a plus is a special character so if you want to match a literal + in a source pattern you must
write it as \+. Also note that you cannot use a literal plus sign in the target pattern.
Please see http://www.pcre.org for more information about Perl Compatible Regular
Expressions. If a number matches any of the rules, Stage 2 and Stage 3 are skipped. Hence
the automatic mapping as defined in the Number Profiles pages will not apply!!
Priority
The priority in the number patterns determines the order in which these will be matched. The
number can be 0 or higher with 0 being the highest possible priority.
Source Pattern
Enter the source pattern in the above described format. Note that you can leave this field
empty, but then your rule would never match.
Target Pattern
The match source pattern will be mapped to this. Please use the above described format to
write the patterns. This field must not remain empty.
Treat As
• Internal Call
If this option is selected no further number tanslation will be done.
• Local Area Call
If the call is to be treated as a local area call, depending on the settings in the number
profile, the country code and area code will be removed and any appliable prefixes
made. The converted number will be treated like one the user has dialed and that runs
through the number profile.
• National Call
If the call is to be treated as a national call, depending on the settings in the number pro-
file, the country code will be removed and any appliable prefixes made. The converted
number will be treated like one the user has dialed and that runs through the number
profile.
2005-2008
c Comdasys AG 184
4.10 Client based call forwarding
• International Call
If the call is to be treated as an international call, depending on the settings in the
number profile, any appliable prefixes will be made. The converted number will be
treated like one the user has dialed and that runs through the number profile.
Rule Active
This enables you to activate and deactivate rules. It is useful both for debugging purposes as
well as for temorarily deactivating certain rules. Any defined rule will only be applied if this
option is checked.
This page allows to configure and activate client specific call forwardings. This can also be
done from the FMC client. The see FMC clientmanual for more information on this. The call
forwarding behavior of the Convergence mimics the call forwarding functionality of a standard
SIP client. This means that the server does not have to implement any special features to
support this, except for supporting SIP redirection with the 302 session redirection response.
There are three different ways to do the call forwarding, Always, On Busy, On Unavailable. All
three can be configured and activated separately.
The call forwarding will become active anytime the Convergence receives a call from the PBX.
The reaction will depend on the type of forwarding set. Each type can be configured with a
separate number. Each type can also be activated separately. If multiple forwardings are
activated you have to pay attention to the precendence.
Call forwarding types:
• Always - This will configure the number used for an unconditional immediate forwarding.
The target can be specified here. In order to activate this you can check the checkbox
next to the field for entering the number. The change will take effect immediately.
• Busy - This will configure a call forwarding if the extension and hence the FMC client
is busy. The target can be specified here. In order to activate this you can check
the checkbox next to the field for entering the number. The change will take effect
immediately.
• Unavailable - The call will be forwarded if the called FMC client does not answer for a
period of 60 seconds. The target can be specified here. In order to activate this you can
check the checkbox next to the field for entering the number. The change will take effect
immediately.
2005-2008
c Comdasys AG 185
Figure 4.9: Call Forwarding
2005-2008
c Comdasys AG 186
4.11 PBX Access Codes
i The call forwarding can be activated both via WLAN as well as GSM. In GSM mode,
the callthrough number needs to be configured in the client because the activation is done
through it.
! It is possible to have more forwardings activated simultaneously, however call for-

warding Always overrides remaining two.
! You need to specify the call forwarding number exactly as you need to dial it on the
PBX. That means if the PBX for example expects a leading zero, you need to specify it
here.
4.11 PBX Access Codes
This page allows the configuration of rewrite rules for access codes sent by the FMC client
towards the PBX. Access codes are used by the PBX to implement platform specific features
as for example Group Pickup. These Access Codes however are configurable in the PBX. The
FMC client supports hiding such access code features behind an easily selectable menu. Now
if the Access Code e.g. for Pickup changes on the PBX, you would hence need to change
the stored code on each client. To avoid this, you can simply define a mapping here in the
Convergence. It will then take the access code sent by the client and translate it to the correct
one towards the SIP Endpoint, namely the PBX.
The following example should give a better insight into what is actually happening. If the FMC
user has a predefined setting for a DTMF invoked feature say ∗8 on his FMC client, but the
customer’s PBX expects #9, you can simply specify this mapping here.
Figure 4.10: Predefined Feature Codes
The following can be configured here. Configuration fields:
• Endpoint: This will allow the selection of an endpoint to use. This means that the defined
mapping will be applied for all users registered here.
• Name: You can configure a descriptive name for the feature. This parameter has purely
informational value
• FMC Feature Code: Configure the feature code to search for in every call. This se-
quence will be replaced by the respective PBX Faeture Code. This should only contain
symbols that can be dialed from a standard phone, namely digits, ∗and #
2005-2008
c Comdasys AG 187
4.12 Supported PBX Features
• PBX Feature Code: The code to replace the matched FMC Feature Code with. This
should only contain symbols that can be dialed from a standard phone, namely digits,
∗and #
i This feature is purely optional and is usually only used for special customer
Using this configuration options, it is possible to communicate to clients, which features are
available on the respective SIP endpoints. To avoid a manual configuration of this on the
client, the server will send these supported features. The supported features will be sent
in the response to a registration request via SIP. The client can adapt its display based on
this information to not display unavailable features. This applies to both in-call and out of
call features. In order to achieve this, the PBX supported features must be configured for
every SIP Endpoint. By default, all supported features are enabled, so that you only need to
selectively disable them if not supported by the PBX.
4.12.1 Predefined PBX Features
As mentioned above, the selectable features are static. The features all have a uniqe feature
code Fxx where xx is a number. You can enable or disable them on a per SIP Endpoint Basis.
The following features have been defined:
• Inbound Basic Call

• Outbound Basic Call
• Inbound Enterprise Call
• Outbound Enterprise Call
• Handover
• Manual Handover
• IMS Handover
• Blind Transfer
• Attended Transfer
• Hold
• Consultation
• Toggle
2005-2008
c Comdasys AG 188
• Conference
• Callback
• Pickup
• Group Call Pickup / Boss Secretary
• Call Forwarding
i It depends on the FMC client and its version which fields are actually interpreted and
which ones are ignored.
Figure 4.11: Predefined Feature Codes
The following explains the configuration of the fields in detail.

• Endpoint: You need to select a SIP Endpoint for which these feature settings apply. In
fact, all standard features are automatically added to the table, so that there is no need
to do any work. You just need to select the endpoint for which you want to disable a
certain feature.
2005-2008
c Comdasys AG 189
• Name: This is a descriptive name for the feature in question. There is no need to
configure this since it has been predefined.
• Code: The Feature code here is predefined and cannot be changed.
• Active: Select this to activate or deactivate the feature. This will prompt the Convergence
to signal support for this feature in the Registration response for all users associated with
this endpoint.
2005-2008
c Comdasys AG 190
4.12.2 User Defined PBX Features
Besides the Predefined PBX Features, it is also possible to assign user defined ones. This
again needs to work in conjunction with the client. The idea behind this is to define a mecha-
nism between Server and Client to signal if certain features should be displayed or not. You
will probably not need this unless you have larger strongly customized deployments. The
following should give an overview over the configuration options.
Figure 4.12: User defined Feature Codes
2005-2008
c Comdasys AG 191
The following explains the configuration of the fields in detail. As you can see that this closely
resembles the Predefined PBX Features
• Endpoint: You need to select a SIP Endpoint for which these feature settings apply.
Contrary to the predefined features, you need to set this on a per feature basis here.
• Name: This is a descriptive name for the feature in question. You should put a descrip-
tive name of the feature in questions, but the parameter is purely informational.
• Code: The Feature code to send to the FMC client. The same one must be used on the
client. The format has to be Uxx where xx is a number.
• Active: Select this to activate or deactivate the feature. This will prompt the Convergence
to signal support for this feature in the Registration response for all users associated with
this endpoint.
2005-2008
c Comdasys AG 192
4.13 Client Download
4.13 Client Download
The Convergence allows an easy deployment of the FMC client using a installation package
builder. You simply select an FMC user of you system and the Convergence generates a
ready to use installation file for the FMC client. You can either download the FMC client to
your workstation or sent it directy to an email address.
Figure 4.13: Client Download
• User: select here the user you want to build the client for
• Interface: select here the interface which should be used to connect to the Convergence.
This is used by the Convergence to preconfigure the right registrar IP address for the
FMC client configuration.
• Port: the portnumber for connecting the Convergence. Please note that the Conver-
gence listens only on port 5062 if you are connecting via the WAN interface.
• MOC Number: The MOC (Mobile Originated Call) number is dialed by the FMC client
if it is operating in GSM mode. The number is virtualy the same as the Call through
Number (See ??). You should configure it in international format e.g. +4989123456789
to allow the FMC client to call this number even it is used in a different country.
• MTC Number: The Mobile terminated prefix is used to identify if an incoming GSM call is
initiated by the Convergence or if it is an external call. The FMC client matches the caller
id of the incoming GSM call with the MTC number. Calls triggerd by the Convergence
(static roaming or handover) use the associated PBX number by default as caller id. You
need to put here the PBX numer of your user in international format. If you are unshure
about this field it is save to leave it blank. Then, no matching will be done on the FMC
client.
• Send Client via Mail: Check this box if you want to mail the FMC client to a specific
e-mail address instead of downloading it.
• To-Address: Specify the recipient of the mail here
• SMTP authentication type: Chose here between the PLAIN and LOGIN authentification
method. For Microsoft Exchange SMTP server you have to use the LOGIN method. You
can also set the authentification type to NONE. In this case no username and password
is used e.g. Sendmail or Postfix servers dont have authentification enabled by default.
• SMTP server: Specify here the smtp server used to deliver the client
• SMTP port: The port for connecting the smtp server. Use the default port 25.
• SMTP username: Specify the username here if you need authentication
• SMTP password: Specify the password for the authentication
2005-2008
c Comdasys AG 193
4.14 Import User List
4.14 Import User List
Setting up a large number of users requires sometimes a lot of handwork. To allow the import
of a large number of users you can create a .csv file (Comma Separated Values) and the
Convergence will setup the accounts for you. All the users will be imported for one specific
endpoint.
Each line of the file configures one user and should have the syntax:
PBX Username; PBX Password; PBX Number; SIP Number; SIP Password; GSM
Number
Optionaly you can configure up to three GSM numbers by using the following syntax:
PBX Username; PBX Password; PBX Number; SIP Number; SIP Password; GSM
Number1; GSM Number2; GSM Number3
You can add comments to the file by inserting a as first character into the file. The import will
be only done if all lines of the .csv file are formatted correctly.
! It is not possible to overwrite or recreate users. If user exits allready the complete
importe will be rejected. Remove the corresponding line from the CSV file and try the import
again.
Finaly this is an example of an csv file:
# myimport.csv
#
# PBX Username; PBX Password; PBX Number; SIP Number; SIP Password; GSM Number1;
#
4000;x4rewrre;4000;14000;mypw0815;017212345678
4001;43eedcff;4001;14001;superman;017212345111;017978912345
4002;xnj43ked;4002;14002;sonne123;017212345123
4003;432dsaxd;4004;14003;foobar99;017212345456
Figure 4.14: Import Users List
4.15 XMPP Endpoints
In order to use the XMPP functionalities you have to configure XMPP endpoints and XMPP
users. The concept of XMPP Endpoints and XMPP Users is quite similar to the concept of
SIP Endpoints and SIP User Accounts. The XMPP endpoints are used for Instand Messaging
2005-2008
c Comdasys AG 194
4.15 XMPP Endpoints
and Presence only. You can use here either your own XMPP server or one of the free servers
of the public JABBER network. Look at https://www.xmpp.net/servers to have a list
of public available servers.
Figure 4.15: XMPP Endpoints

• XMPP Endpoint Name: Here you asssing a descriptive name for the XMPP configura-
tion. It is used for internal purposes only.
• Connect Server: Here you specify the the connect server where the the Convergence
registers its XMPP endpoints This could be your your internal XMPP server or a public
server like Google Talk or jabber.org.
• Domain: You can configure a different domain name here. By default the domain name
of the connect server is used but you can overwrite it here. It is save to leave this field
blank.
• Port: This field contains the port number of the remote XMPP server. The XMPP default
port is 5222 and used by default if you leave the field blank.
2005-2008
c Comdasys AG 195
4.16 XMPP Users
• TLS: This checkbox enables TLS (Transport Layer Security) for the communication with
the XMPP server. You should enable this by default since most of the servers will only
work if TLS is enabled.
4.16 XMPP Users
Each FMC User can assigned with an XMPP user in order to use instand messaging fea-
tures. Here you create the mapping between the FMC user, the XMPP user and the XMPP
endpoint.
Figure 4.16: XMPP Users
i Before you can use the XMPP users you have to create the XMPP accounts on your
XMPP server first. This is done by administrative tasks on the XMPP server. If you are
using a public XMPP server you can create your XMPP account with an external XMPP
client like Miranda IM (Windows) or Pidgin (Linux).
2005-2008
c Comdasys AG 196
4.17 Enterprise FMC Status Page
• FMC User Name: Select the FMC user that should be assigned to this XMPP account.
• XMPP Endpoint Name: Select the XMPP endpoint you want to use for this XMPP ac-
count.
• XMPP User Name: Configure your XMPP username here. If your XMPP login is
test123@jabber.org you must put only the userpart (test123) here.
• Password: configure the password for the XMPP user.
• Activate XMPP User: Check this box to activate the XMPP user. If the account is not
activated the Convergence tries not to connect to the XMPP server and XMPP function-
alities are disabled.
4.17 Enterprise FMC Status Page
The status page displays the active PBX registrations, the registered users, as well as all
active calls. You can always press Reload to get the most up to date view. The page will not
refresh automatically. The displayed information in detail includes:
• Active EndPoint Registrations: Every registration to the PBX as well as its status are
listed here. All registrations should be in the Status REGED signifying that they are
correctly registered with the SIP endpoint.
• Registered Users: This displays all users that are currently registered via IP. The IP
address and port will give you some indication as to where these users registered from.
Note that if you see the local host’s IP address here, this indicates that the user regis-
tered from behind a NAT network. In order to see the originCommand Line section.
• Call Status: This will show all active calls where the name represents the local user,
and the Connected User field the party the user is connected to. You will not see who
initiated the call in this screen, only that this call is ongoing.
4.18 Using external Tools with the FMC Database
This section provides information of how to connect to the FMC database with external tools
like Microsoft Access or OpenOffice.org Base. With the usage of external tools you wil gain
more power and flexibility in managing large amounts of FMC configuration data and will also
be able to automate common management tasks.
The current FMC convergences are using a PostgreSQL Database for saving all the following
data in the database:
• Global Settings
2005-2008
c Comdasys AG 197
Figure 4.17: Status Page
2005-2008
c Comdasys AG 198
• SIP Endpoints
• User Accounts
• Registrations
• Numbering Profiles
• Numbering Patterns
• Call Forwarding
• PBX Access Codes
• PBX Features
4.18.0.1 Establishing Database Connection
The database name of the Database to use is FMC, the default username is pgsql and the
password is 18273645. The default port of the PostgreSQL database is defined as 5432.
The PostgreSQL database is configured to listen only to connections from the loopback
adapter or the LANA and/or LANB network. If you want to make a connection to database
from another network, you will need to use a SSH tunnel to forward a local port to the database
port on the FMC via a SSH connection.
Creating a SSH tunnel with a Linux system for example is quite easy, just open a terminal and
enter the following command: ssh -L9500:HOSTNAME:5432 root@HOSTNAME
Just replace the placeholder HOSTNAME with the IP address or hostname of your FMC.
After establishing the SSH connection you can connect to the FMC database via the local port
9500.
4.18.0.2 Using OpenOffice.org Base
For connecting OpenOffice.org Base to the FMC database we will use the PostgreSQL JDBC
driver, which can be found at http://jdbc.postgresql.org.
After starting OpenOffice.org the database wizard will appear. Select the option Connect to
an existing database and select JDBC from the dropdown box.
Enter the URL for the connection in the following format jdbc:postgresql://hostname:
port/databasename .
When you are using the SSH tunnel method to connect to the database, the URL will look like
the following: jdbc:postgresql://localhost:9500/FMC.
2005-2008
c Comdasys AG 199
If you are connecting directly to the database via your local network the URL might look like
this (in this example the FMC has an internal IP address of 10.100.5.65): jdbc:postgresql:
//10.100.5.65:5432/FMC.
The field JDBC driver class must be set to the class org.postgresql.Driver. To
verify that your PostgreSQL JDBC driver works correctly you can press the button Test
class.
Just press Next and enter pgsql as username for the connection and check the box Password
required. Now you can test the connection to the database via the Button Test Connection.
When prompted for the password just enter 18273645. If all of your settings were correct you
will see an infobox popping up which should tellyou that the connection to the database was
successful.
You can now press the Button Finish and work with the database.
4.18.0.3 Using Microsoft Access
For connecting Microsoft Access with the PostgreSQL database you will first need the Post-
greSQL ODBC driver, which can be found at http://www.postgresql.org. You can just
install the downloaded driver by doubleclicking the downloaded .msi file.
If you don’t connect to the database from your internal network you will need a tool to open
an SSH connection and creating a local forwarded (tunneled) port to the FMC. We recom-
mend the usage of PuTTY which is a free and opensource SSH client for Microsoft Windows
operating systems.
For a detailed description of how to setup your PuTTY client with forwarding of local ports see
the PuTTY user documentation which can be found at http://the.earth.li/∼sgtatham/
putty/0.60/htmldoc/Chapter3.html#using-port-forwarding.
After setting up the database connection either via local network or SSH tunnel you will need
to create an ODBC datasource which can be used from inside Microsoft Access later on.
See the Screenshot below how to configure a ODBC Datasource where you use the local port
9500 to access the database via a SSH tunnel.
Now you can start Microsoft Access and create a new database file. After that you can
create links to the FMC Tables via File -> External Data -> Link Tables. A Dialog
appears in which you need to select as file type ODBC and then select the previously created
ODBC datasource. In the next dialog you can select which tables from the FMC database you
want to have linked with your Microsoft Access Database. You are now able to access the
FMC database tables from inside Microsoft Access and all changes you make to the data in
the tables are present on then FMC.
2005-2008
c Comdasys AG 200
Figure 4.18: PostgreSQL ODBC DSN Example
4.18.1 FMC Database Tables
4.18.1.1 sip user
The table sip user contains all user account settings foreign key which points to the corre-
sponding outgoing registration.
i The Username field can be entered into the database, but is currently not used. It is
only there for future use. The field must not be NULL and should therefore just be an empty
string.
4.18.1.2 sip reg
The table sip reg contains the configuration of all outbound registrations and a foreign key
that points to the corresponding endpoint of the registration.
i The Realm field can be entered into the database, but is currently not used. It is only
there for future use and may be NULL at present.
2005-2008
c Comdasys AG 201
4.19 Synchronize database
4.18.1.3 sip endpoint
The table sip endpoint contains all configuration data of the endpoints. A foreign key points
to the converter profile which should be applied when making outgoing calls.
4.18.1.4 settings
The table settings contains all global settings and contains only a key and value column.
4.18.1.5 nc profiles
The table nc profiles contains all configured number converter profiles which can be used
from the endpoint configuration.
4.18.1.6 nc patterns
The table nc patterns contains the configured call routing patterns which should be applied to
all outgoing calls.
i There are also additional tables present such as Codecs. These are for internal use
and should not be altered.
The synchronization of the user data between two Convergenceis ordinarily used in a redun-
dancy configuration. In such a configuration, we would have two appliances, one serving as
a master, the other serving as a slave. This slave will obtain its configuration from the master
server. Therefore, this is not a real synchronisation but rather having a master containing the
configuration. The Slave will however keep a copy of the configuration, so that it can continue
to operate if the master fails.
This applies only to the FMC part of the configuration. Things like IP addressing etc. are con-
sidered separately. This automatically synchronized configuration however includes all Users,
Endpoints, and Registrations, Number Profiles, etc. The synchonization is done by directly
accessing the configuration database of the master server. The all changes to users, en-
points, or registrations will become effective immediately and will therefore also be scheduled
for synchonization right after pressing ”Save” in the WebGUI. In order to lower the network
load, several changes are collected and then synchronized in one step.
2005-2008
c Comdasys AG 202
i It can take up to 3 minutes until all changes have been properly synchronized to the
Slave device.
i Changing the configuration will only be supported on the Master Server. If the Master
is down, the Slave can continue to operate normally. For consistency purposes however,
no configuration change will be possible for the time the Master is down.
4.19.0.7 Operating Mode
The Synchronize database page is used to configure the Convergence in Master, Slave or
in Standalone mode. It will also configure the database synchronization.
The first item Operating mode will be used to select the operating mode for the unit. Master
IP is the IP of the interface which acts as a master and the Slave IP is respectively for the
interface acting as slave.
i To configureboth Master and Slave you need to have a network connection. In theory
a standard routed connection is enough. Since this feature is however used in conjunction
with VRRP, you need to have a connection supporting Multicast requests, usually a switched
connection.
4.19.0.8 Standanlone mode
In the Standalone mode the Convergence uses the database without network connection to
other databases. The IP addresses under the Operating mode item will be ignored. This
is the default operation mode. At any time you can turn a Standalone Convergenceinto the
master of a cluster. You have to be careful turning it into a slave because you will lose your
configuration.
! To update the Convergence it is very important to use the Convergence in Standalone

mode.
4.19.0.9 Master Mode
The Master mode initialize the local database as master and the database from the Conver-
gence with the Slave IP as slave. The connection deamon starts on the master Convergence
after the initializing process. You need to configure the Master the Master IP and Slave IP.
2005-2008
c Comdasys AG 203
Figure 4.19: Synchronize database
2005-2008
c Comdasys AG 204
You also need to download the security key to enable communication between the Master and
the Slave, see ?? for more information on that.
4.19.0.10 Slave mode
This puts the Convergenceinto slave mode. All configuration data will be fetched from the
master. To start the Convergence in Slave mode you need the Master IP and Slave IP. The
Slave IP naturally is the IP address of the unit you are currently configuring and you need to
specify the appropriate interface IP address that should be used for synchronization.
After applying this configuration, the unit will start to synchronize the data from the master
server.
i The Security Keys (see ??) of the Master must be present on the slave. Otherwise
the unit will not be able to synchronize the configuration.
! All FMC configuration data present on this device will be overwritten by data fetched
from the master. This means that the configuration present on this device will be lost
i You can switch a Slave back into Standalone mode, but the synchronized data will
be kept.
4.19.1 Failover Operation
Two HPMC appliances can be deployed in a failover fashion. In such a configuration, the
secondary server can take over the functionality of the primary one. In order to offer that, we
will make use of the VRRP protocol to provide a dynamic failover mechanism. The properties
of this failover mechanism are as follows:
• Secondary appliance will be idle when the primary appliance is active

• VRRP is used to switch the IP address between the master and the slave, so the HPMC
appliances do not have to be in the same multicast domain. The master and the slave
will share one virtual IP address. In addition to that a management / physical address
for each of them is required to enable communication among each other. All three
addresses should be in the same subnet.
• Once the master fails, the secondary appliance will take over
• All active calls will be lost in a failover scenario
• Right after a failure, the call can be re-established via the secondary appliance
2005-2008
c Comdasys AG 205
• The secondary appliance does not have to be maintained, since the configuration will
always be taken from the primary appliance (only pertaining to the FMC configuration)
The configuration of the solution is as follows. The primary server will contain all FMC con-
figuration. The slave server is normally configured for networking, firewalling etc. The FMC
configuration is only done by pointing to the master server via database synchronization, as
described in ?? . This will lead to a mirroring of this configuration. The VRRP portion has to
be setup separately. Please refer to ?? for more information.
2005-2008
c Comdasys AG 206
The SIP TLS configuration page is a simple tool to upload a TLS private key and a TLS
certificate used to communicate with the client in TLS mode. Naturally this is only relevant
if you have a client that is able to support SIP in TLS mode. Otherwise you can ignore this
section.
The Convergencegenerates a new privat key and a certificate automatically while booting if
noprivate key or certificate exists. Therefore, if you do not want to setup authentication based
on certificates, there is no need to do any configuration here.
Figure 4.20: SIP TLS configuration
4.20.0.1 Upload Private Key and Certificate
To upload a new TLS Private Key press the Browse button and select the new private key
from your file system (Figure: ??).
2005-2008
c Comdasys AG 207
4.21 QOS
In the next step press the Upload button and the new TLS private key will be saved onto the
Convergence. The procedure for the TLS certificate is essentially the same (Figure: ??).
! The TLS certificate must fit the TLS private key, otherwise no TLS communication
will be possible
4.20.0.2 Create default private key and certificate
If you do not have any keys to use for TLS communication, you can also use the Conver-
genceto create a key set. Simply press Generate and the Convergencegenerates a new
default TLS private key and TLS certificate. These will be stored on the Convergenceand
activated after pressing Apply Configuration .
4.21 QOS
This page allows to configure layer 3 QoS tagging by using DSCP/TOS byte in IP header.
This tagging is supported both towards the FMC clientside as well as towards the PBX side.
Simply configure the correct interfaces here. Note that this tagging only makes sense for
outbound traffic.
There are three different ways to specify the traffic you want to mark:
• Interface
• IP and Application Protocol
• TCP / UDP Ports
There are several configuration options for each criteria:
• Protocol: Select a Protocol, either UDP, TCP, ICMP or ANY. ANY will match all packets.
• Received on Interface: This will match packets arriving on a specified interface. This
option only applies if the traffic is just forwarded and the Convergencehence acts as a
router. For traffic terminated on this device this rule is useless.
• Sent over Interface: Will match all packets sent out over the given interface. It does not
matter if the packets were forwarded or generated by the local device.
• Destination Port: Matches all packets addressed to the given destination port.
• L7 Protocol: Stands for Layer 7 Protocol and will actually analyze the payload of each
packet to match a certain protocol. Only a subset of the supported protocols is given as
a choice here, namely ANY, SIP, RTP, TLS. More protocols are usable via the CLI.
2005-2008
c Comdasys AG 208
4.21 QOS
! The use of Layer 7 Filtering is discouraged for devices needing to handle high data
rates (in excess of 5MBit constant load) because analyzing each packet can become quite
resource consuming.
Traffic tagging methods:
• DSCP: Stands for DiffServ and is specified in the RFCs 2474 and 2475. The DiffServ
standard supersedes the original specification for defining packet priority described in
RFC 791
• TOS: Type of Service as described in RFC 791
Both set inteded QoS tag into the same byte field in IP header. If this byte field will be
interpreted as DSCP or TOS dependes on network infrastructure settings. Value can be
entered in decimal (e.g.”38”) or hexadecimal (e.g.”0x26”).
i Note that it is only possible to specify one tagging method (i.e. DSCP or TOS) for
any given tagging rule.
2005-2008
c Comdasys AG 209
5 Command Line Interface
The Convergence does not only offer configuration via the Web interface but further provides
access through a CLI (Command Line Interface).
You can access this CLI in three ways:
• Using a SSH client

• Using the serial interface (COM1, 9600-N-1)
• Using the console (i.e. by connecting a VGA monitor and a PS/2 keyboard)
In every case the username is root and the password is identical to the password set in the
Web interface.
You will get a Linux prompt that can be used like any other Linux computer. A detailed descrip-
tion of the functionality accessible through the CLI is provided in the Commandline Guide.
The configuration via the CLI is primarily used for special tasks as resetting to factory defaults
and for extended debugging.
5.1 Accessing Convergence products
The Convergence is preconfigured for the IP address 10.0.0.205/24. In addition to the

suggested way of configuring the box by adding a PC to this network and configure the Con-
vergence this way, there are additional, advanced methods of configuration. These meth-
ods are especially useful for immediately configuring the primary Ethernet interface properly.
There are basically two methods for local and one for remote command line configuration. (Of
course, for initial setup of interface addresses only the local methods are applicable).
5.1.1 The Convergence Command Line Console
There are 12 console windows available when accessing Convergence products with a key-
board and VGA monitor.1 They can be reached by pressing the Alt key and one of the
function keys F1 to F12 simultaneously. Some of these consoles are reserved for special
1
Applies only to Convergence products with VGA connector. As VGA connector is not accessible from outside
the product, this way to connect Convergence is reserved for service purposes. Opening the product and using
VGA connector should be done by the service engineering staff only.
2005-2008
c Comdasys AG 210
5.2 Initial setup using the Command Line Interface
purposes though, so only some of these consoles are usable for an administrator’s command
line console:
F1 Reserved for the start up screen

F2 Usable as command line console
F7 Reserved for future use
F10 Reserved for informational messages
F11 Reserved for error messages (severity warning and higher)
F12 Reserved for critical error messages
5.1.2 The Convergence Serial Line Console
It is also possible to access Convergence products via RS232 (aka COM1) and a terminal
emulator program like MS Windows’ Hyperterminal. The connection parameters for the serial
line are: 9600 baud, 8 data bits, no parity, 1 stop bit, VT100 emulation.
5.1.3 The Convergence Remote SSH Console
The third possibility to get a command line terminal is to use a SSH (i.e. secure shell) con-
nection using any SSH client (e.g. OpenSSH on Unix/Linux, PuTTY on Windows).
Convergence products allow SSH version 2 connections from all configured interfaces, unless
set differently in the security settings of the graphical user interface.
If you log in via one of the local methods (VGA console or RS232 console) you get a login
menu. You can exit this quick configuration menu by pressing s . The quick configuration
menu can be used to e.g. assign an IP address to the unit. The menu does the same as the
analog WebGUI pages.
After exiting the quick configuration menu, you will see the following login prompt:
Akira login:
2005-2008
c Comdasys AG 211
The only available user to log on is root, with the same password as the admin’s password
in the browser interface, initially sesam. You should change this password via the browser as
soon as possible!
After having logged in you see a prompt like this:
Akira login: root
password:
Akira Linux Release 1.2 (Lisa) for i686 at revision 528
No mail.
root@Akira:˜ #
The shell used is a normal bash, as known from almost all Linux distributions and a number
of commercial Unices. The actual numbers may vary, as they show the current version of
the software at the time of this writing. Also the name Akira is just the initial name of the
Convergence and can be altered using the Web interface (system name).
When you have logged in, you probably want to adjust the IP settings of the first LAN interface
first:
Examples:
1. To change your LAN’s IP address to 192.168.1.20 (because your local network is e.g.
192.168.1.0/24), add the following command:
ifconfig eth0 192.168.1.20 network 255.255.255.0
2. If you want to modify the Convergenceś WAN address, e.g. if you have a static internet
address and want to do the rest of the configuration from a remote site, add (e.g. for a
static address 1.2.3.4 with gateway 1.2.3.1):
ifconfig eth1 1.2.3.4 netmask 255.255.255.0 up
route add default gw 1.2.3.1
In both cases, immediately after entering these commands the Convergence is accessible
from the given networks, but these settings have to be done again in the web interface (or in
the basconfig directly, as shown below) to become permanent.
! Be careful if you intend to configure the Convergence remotely: Initially there are no
firewall rules in place and everyone who knows the IP address may log in and modify the box
if the standard password has not been changed. Also pay attention that you don’t change
the IP address of the interface with which you’re currently logged in if you’re connected via
SSH!
2005-2008
c Comdasys AG 212
5.3 Restrictions using the Command Line Interface
5.3 Restrictions using the Command Line Interface
While the command line environment is a plain bash shell there are nevertheless limitations
on what can or should be done here. These limitations result from the approach of the Con-
vergence to
1. remain upgradeable, even when certain changes are done on the command line
2. remain compatible with the web interface
• Your modifications may disappear if you select Apply config in the web interface.
• Your modifications may disappear if you reboot your Convergence.
• Your modifications may disappear if you upgrade to a newer version of the system.
• Your Convergence may suddenly lack functionalities or functionalities stop working as
desired.
• The security of your Convergence might be compromised.
In any of these cases, the manufacturer does not take any responsibility for damage that oc-
curs (especially security breaches) because of improper use of this command line interface.
So the restrictions are (unless explicitly permitted by manufacturer’s support):
• Don’t modify configuration files, unless for special program packets that are not meant
to be configured from the graphical user interface.
• Don’t modify startup scripts.
• Don’t modify parts of software programs.
• Don’t install your own software packages.
• Don’t change passwords (even if you find out how to do that).
Because almost all features of the Convergence products can be configured via the browser
GUI (and this is what you should normally do) all that is left that can safely be done on the
command line is:
• Modify configuration files for special program packets that cannot be configured in the
WebUI (e.g. traffic shaping).
• Check error conditions more thoroughly.
• Debug network connections with the provided tools.
• Modify the central configuration file /etc/config/baseconfig, which contains all
configurable options of the web interface. See chapter ?? for details on this file.
2005-2008
c Comdasys AG 213
5.4 Configuration utilities
To avoid accidential editing of managed configuration file running vi or vim on such a file will
result in a warning and ask you whether to continue2 . If you find the need to edit a managed
configuration file repeatedly you can avoid the warning by passing -n as first argument, e.g.:
vi -n /etc/openser/openser.cfg
Configuring Convergence products is normally done by editing one central configuration file
called the baseconfig file which location is /etc/config/baseconfig. This file controls
how the necessary configuration files for almost all services are generated by the applyconfig.sh
utility. Because the reference for the baseconfig file is quite extensive the details of this file
are described in chapter ?? after explaining the utilities which work with this file first.
5.4.1 The ”applyconfig.sh” utility
applyconfig.sh processes the baseconfig file and generates the configuration files for all
daemons and other services that can be configured via the WebUI. There are two modi in
which applyconfig.sh operates: with or without command line options. When called with-
out any command line options all configuration files are generated, overwriting already existing
ones. If arguments are passed only configuration files for those services are generated.
For example:
applyconfig.sh syslog
causes only the configuration file for the syslog daemon to be generated, overwriting the
previous one.
Because old configuration files are overwritten you should not edit the controlled configura-
tion files directly as the next you’re pressing Apply configuration in the WebGUI all your
changes will get overwritten by applyconfig.sh.
5.4.2 The ”restartservices” utility
Now that applyconfig.sh has written the configuration files we need to restart one or
more (maybe even all) services. This is handled by the restartservices utility, which
even allows groups of services to be restarted.
Like applyconfig.sh this utility operates on all services when called without arguments. If
arguments are given only the specified services are restarted. To get a list of known services
and service group enter:
2
This feature is available since release 4675.18 and 6060.2 respectivly.
2005-2008
c Comdasys AG 214
restartservices -l
Another very useful command line argument is -n which causes restartservices to just show
what it would do without actually doing something so you can be sure that it really will do what
you want it to do, e.g.:
root@Akira/˜ # restartservices -n logging
/usr/bin/setsid /etc/rc.d/rc3.d/K89klogd stop
/usr/bin/setsid /etc/rc.d/rc3.d/K90syslogd stop
/sbin/stophttpd
/sbin/stopsshd
/usr/bin/setsid /etc/rc.d/rc3.d/S10syslogd start
/usr/bin/setsid /etc/rc.d/rc3.d/S11klogd start
/sbin/starthttpd
/sbin/startsshd
5.4.3 The ”chkconfig” utility
chkconfig is used for controlling services’ configuration (checking configuration). Services

can be enabled and disabled depending on whether they should be started when running
restartservices.sh or not. If a service is disabled it won’t be started and will be simply
ignored. When starting services the system looks up whether there is a locking file for a par-
ticular service in /etc/config. The locking file is an empty file named <service>.norun,
e.g. /etc/config/dyndns.norun .
There are two modi in which chkconfig operates: with or without command line options.
When called without any command line options all services that support chkconfig and
their current status (enabled/disabled) are listed. Typing chkconfig followed by the name of
a particular service lists the current status of this service only.
For example:
root@Akira/˜ # chkconfig dyndns
dyndns on
Particular service can be enabled (or disabled) by typing chkconfig followed by the name
of the service and on (or off ).
For example:
chkconfig dyndns on
enables DynDNS
chkconfig dyndns off
2005-2008
c Comdasys AG 215
5.5 The ”baseconfig” configuration file
disables it.
Furthermore, chkconfig can be run with -q (quiet mode) which will suppress output, e.g.
chkconfig -q dyndns. This can be used for scripting purposes, since chkconfig return
value is 0 for enabled services, and >0 otherwise.
5.4.4 applyfirewall.sh / flushfirewall.sh
Convergence products don’t create Linux IPTables firewall rules directly but use an interme-
diate format called CIG which helps simplifying the creation on firewall setups.
Custom IPTables rules may be added in /etc/sysconfig/firewall.custom.
The applyfirewall.sh utility flushes the current firewall rules, compiles the CIG script
(located in /etc/sysconfig/firewall.wig) into IPTables rules and applies them.
The flushfirewall.sh tool just flushes the firewall, thus temporarily disabling it, which
could be done for testing purposes. This, however will not flush NAT related rules. If you want
to disable NAT too, call flushfirewall.sh with the command line option -n.
flushfirewall.sh -n
5.4.5 saveconfiguration / restoreconfiguration
saveconfiguration saves the most important configuration files The files currently are:
/etc/passwd, /etc/htpasswd, /etc/config/baseconfig, /etc/ssl/*, /etc/ssh/*,
/etc/openvpn/* into a file
/tmp/configuration-<date>.cpio.gz (or /root/configuration-<date>.cpio.gz
in older releases)
To restore a configuration that was saved with saveconfiguration use restoreconfiguration
and supply the appropriate file as argument. Note that restoreconfiguration automatically calls
applyconfig.sh and restartservices to regenerate the configuration files for all ser-
vices and to restart them.
5.5 The ”baseconfig” configuration file
This chapter serves as a reference to the parameters of /etc/config/baseconfig, not

as a conceptual guide to techniques behind the products used. If you are interested in the
basic concepts (e.g. on VPNs or iptables) please consult the products’ web sites, mailing lists
etc.
2005-2008
c Comdasys AG 216
5.6 Parameter Reference for baseconfig
The purpose of the baseconfig file is to have a central configuration file that controls the
generation of configuration files for all included services. The generation of configuration files
is handled by the applyconfig.sh script which is described in section ??.
A complete reference to all baseconfig keys, their explanations and their possible values is
provided in chapter ??.
5.5.1 Syntax of baseconfig entries
The file baseconfig contains all configuration parameters that can be set using the web
interface. Whenever data from the web interface is saved the entire file is read, the accord-
ing entries are added/modified/deleted and then the entire file is written back in alphabetical
order.
This behaviour has two consequences:
• You may add as many additional parameters as you want (they just have no effect).
• You cannot use comments in this file the normal way. If you want to add a comment to a
parameter, just create a new parameter with the same name as the original parameter,
followed e.g. with comment.
Example:
system_name=gatekeeper
system_name_comment=This is the name of my box
You already could see the overall syntax of entries in this file:
<Variable>=<Value>
<Variable> is the name of the parameter. A complete list of names used in the Conver-
gence can be found in section ??. <Value> can be any entry, its interpretation depends on
<Variable> and the service that to be configured.
The following chapters describe all keys and their meanings used in the /etc/config/baseconfig
file. See chapter ?? for an overview of this file.
2005-2008
c Comdasys AG 217
5.6.1 Settings for First Local Network interface (lana )
These settings configure the first LAN interface eth0.
Name: lana ip
Description: IP address of first LAN interface or “dhcp” for dynamic IP support
Example: lana ip=10.0.0.205
Name: lana nm
Description: Net mask of first LAN interface
Example: lana nm=255.255.255.0
Name: lana dhcp from

Description: Start of IP range for DHCP on first LAN interface; Has to be in the same
subnet as lana ip/lana nm and has to be smaller than lana dhcp to
Example: lana dhcp from=10.0.0.220
Name: lana dhcp to

Description: End of IP range for DHCP on first LAN interface; Has to be in the same
subnet as lana ip/lana nm and has to be higher than lana dhcp from
Example: lana dhcp to=10.0.0.230
Name: lana dhcp gw ip

Description: Specifies optional standard gateway other than the Convergence itself.
Example: lana dhcp gw ip=10.0.0.223
Name: lana dhcp dns1, lana dhcp dns2

Description: Specifies optional DNS servers forwarded to a DHCP client along with its
assigned address. Not to be confused with system dns, which is used by
the Convergence itself.
Example: lana dhcp dns1=217.145.104.11
Name: lana dhcp ntp1, lana dhcp ntp2, lana dhcp ntp3
Description: Specifies optional NTP time servers forwarded to a DHCP client along with
its assigned address. Not to be confused with system dns, which is used
by the Convergence itself.
Example: lana dhcp ntp1=217.145.104.11
Name: lana nat

Description: Value “0” (no) or “1” (yes); specifies whether NAT should be used between
the first LAN interface (eth0) and WAN (eth1).
Example: lana nat=1
2005-2008
c Comdasys AG 218
5.6.2 Settings for Second Local Network interface (lanb )
These settings configure the second LAN interface eth2.
Name: lanb type

Description: Specifies usage of second LAN interface (eth2). Valid values are:
“inactive”: second LAN interface is not used at all; all values referencing
lanb are not used
“dmz”: second LAN is used as DMZ; NAT is not supported on this inter-
face and the interface cannot be opened unlimited against the first LAN
interface.
“internal”: second LAN is a normal second internal network and treated
like the first LAN
Example: lanb type=inactive
Name: lanb ip
Description: IP address of second LAN interface (eth2) or “dhcp” for dynamic IP support
Example: lanb ip=192.168.1.1
Name: lanb nm
Description: Net mask of second LAN interface (eth2)
Example: lanb nm=255.255.255.0
Name: lanb dhcp from

Description: Start of IP range for DHCP on second LAN interface;
Has to be in the same subnet as lanb ip/lanb nm and has to be smaller
than lanb dhcp to
Example: lanb dhcp from=192.168.1.10
Name: lanb dhcp to

Description: End of IP range for DHCP on second LAN interface;
Has to be in the same subnet as lanb ip/lanb nm and has to be higher
than lanb dhcp from
Example: lanb dhcp to=192.168.1.20
Name: lanb dhcp gw ip

Description: Specifies optional standard gateway other than the Convergence itself.
Example: lanb dhcp gw ip=192.168.1.13
2005-2008
c Comdasys AG 219
Name: lanb dhcp dns1, lanb dhcp dns2

Description: Specifies optional DNS servers forwarded to a DHCP client along with its
assigned address. Not to be confused with system dns, which is used by
the Convergence itself.
Example: lanb dhcp dns1=217.145.104.11
Name: lanb dhcp ntp1, lanb dhcp ntp2, lanb dhcp ntp3
Description: Specifies optional NTP time servers forwarded to a DHCP client along with
its assigned address. Not to be confused with system dns, which is used
by the Convergence itself.
Example: lanb dhcp ntp1=217.145.104.11
Name: lanb nat

Description: Value “0” (no) or “1” (yes); specifies whether NAT should be used between
the second LAN interface (eth2) and WAN (eth1).
Example: lanb nat=1
5.6.3 Settings for Wide Area Network interface (wan )
These settings configure the WAN interface eth1 and its PPP connection, if required.
Name: wan type

Description: Type of WAN connection; one of:
“ip”: static Internet address used; implies wan ip, wan nm
“pppoe”: ISP connection using PPPoE is used for Internet access; implies
wan user, wan pwd
“pptp”: ISP connection using PPTP is used for Internet access; implies
wan user, wan pwd, wan ip, wan gw
Example: wan type=pppoe
Name: wan ip
Description:
• Static IP address of WAN interface (eth1), if a static Internet address
is used for connection
• IP address of Convergence in transfer net to DSL modem, if PPTP is
used
Example: wan ip=62.34.178.34
Name: wan gw
Description: IP address of PPTP DSL modem
Example: wan gw=62.34.178.35
2005-2008
c Comdasys AG 220
Name: wan nm
Description: Netmask of WAN interface (eth1)
Example: wan nm=255.255.255.248
Name: wan user

Description: User name for PPPoE and PPTP connections
Example: wan user=123567.213523@my provider
Name: wan pwd

Description: Password for PPPoE and PPTP connections
Example: wan pwd=kgvfasdhl
5.6.4 Settings for Virtual Interfaces (vif intf)
Use these settings to configure virtual interfaces on your box (so called IP Aliasing). These
settings are also there for another reason. A virtual interface can also be configured as a
VLAN.
The acronym VLAN expands to Virtual Local Area Network. A VLAN is a logical local area
network (or LAN) that extends beyond a single traditional LAN to a group of LAN segments,
given specific configurations.
A LAN is a local area network and is defined as all devices in the same broadcast domain. If
you remember, routers stop broadcasts, switches just forward them. VLAN is a virtual LAN.
In technical terms, a VLAN is a broadcast domain created by switches. Normally, it is a router
creating that broadcast domain. With VLANs, a switch can create the broadcast domain.
This works by, you, the administrator, putting some switch ports in a VLAN other than 1, the
default VLAN. All ports in a single VLAN are in a single broadcast domain. Since switches can
talk to each other, some ports on switch A can be in VLAN 10 and other ports on switch B can
be in VLAN 10. Broadcasts between these devices will not be seen on any other port in any
other VLAN, other than 10. However, these devices can all communicate because they are
on the same VLAN. Without additional configuration, they would not be able to communicate
with any other devices, not in their VLAN.
Similarly to physical LANs, you need a router to exchange packets between two VLANs. In
order to achieve that, you can create a Virtual Interface for each VLAN the Convergence is in.
You can then define routing policies as well as security policies between the virtual interfaces
to route packets any way you like.
i The x must be a consecutive number.
2005-2008
c Comdasys AG 221
Name: vif intfx=[native interface;name;ip;netmask]

Description: The option value must be enclosed in square brackets. The option value is
a semicolon seperated list which must contain the following information:
1. Interface name (such as lana,wan) for which the IP alias should be
created
2. Number of the virtual Interface Every Interface for aliasing needs to
have a number to uniquely identify it. The name of the interface on
the device will then be ”physical interface name”:”number”, only sep-
arated by a colon. For VLANs, this number is the same of the VLAN
tag you want to be using.
3. IP Address of the network to be configured. Note that
4. Netmask of the network to be configured on this virtual interface.
5. Activate VLAN If this switch is set to on, a VLAN interface will be
created with the number as tag.
Example: vif intf0=[lana;gw1;192.168.165.254;255.255.255.0] or

for VLAN vif intf0=[lana;123;192.168.7.67;255.255.255.0;on]
! Note that you cannot configure two interfaces with the same network and netmask.
Especially overlapping netmasks will not be caught by the sanity check in the configuration
management, but can cause very unwanted routing behavior.
5.6.5 Settings for System Settings (system )
These settings configure aspects of the box itself.
Name: system name

Description: Computer name of the Convergence
Example: system name=gatekeeper
Name: system dns

Description: DNS server for name resolution of the Convergence, e.g. for ping, dyndns,
etc.
Example: system dns=217.145.104.11
5.6.6 Settings for System Logging (syslog )
These settings configure the system’s logging behaviour.
2005-2008
c Comdasys AG 222
Name: syslog server

Description: Name or IP address of a remote syslog server that shall get all system and
kernel messages of this Convergence
Example: syslog server=10.0.0.10
Name: syslog level

Description: Severity level for logging; everything from this level on will be logged; val-
ues are (in descending order of verbosity): “debug”, “info”, “notice”,
“warning”, “error”, “critical”, “alert”, “emergency”
Example: syslog level=debug
Name: syslog file

Description: If set, log messages will be logged to this local file. Use with caution! There
is only limited space available and there is no mechanism to prevent syslog
from filling up the entire file system.
Warning: Use this option only, if you are know what you do!
Example: syslog file=1
5.6.7 Port numbers (sshd , https )
Use these settings to customize port numbers for ssh and https.
Name: sshd port

Description: Custom port number for ssh; valid number is any integer from range 0-
65535. Default value is set to “22”.
Example: sshd port=22000
Name: httpd port

Description: Custom port number for https; valid number is any integer from range 0-
65535. Default value is set to “443”.
Example: httpd port=44300
5.6.8 Settings for Dynamic DNS (dyndns )
These settings configure an dynamic DNS service, which is especially useful, when no static
address is available for the WAN interface.
For most services the same username/password may be used for a number of hostnames. If
you use this feature, a malicious user on one Convergence might be able to modify registered
addresses from other boxes, which is a potential security risk!
2005-2008
c Comdasys AG 223
Name: dyndns type

Description: Dynamic DNS service to be used; this Convergence supports several sup-
pliers of dynamic DNS services - have a look on their web sites for addi-
tional information and registration:
“dhs” www.dhs.org
“dyndns” www.dyndns.org
“dyns” www.dyns.cx
“easydns” www.easydns.com
“eznet” www.ez-ip.net
“hnorg” www.hn.org
“justlinux” www.justlinux.com
“ods” www.ods.org
“tzocom” www.tzo.com
“zoneedit” www.zoneedit.com
Example: dyndns type=dyndns
Name: dyndns user

Description: Username you are registered with at the selected dyn-DNS service
Example: dyndns user=comdasys test
Name: dyndns pwd

Description: Password for your registered dyn-DNS username
Example: dyndns pwd=test pwd
Name: dyndns host

Description: Registered hostname for this Convergence. It will be reachable from the
Internet using this name.
Example: dyndns host=gatekeeper.testdom.com
5.6.9 Settings for Name Server (bind )
These settings configure the Name Server function.
Name: bind mode

Description: Intended use of the Name Server; one of:
“on”: Name Server enabled; implies bind dnsx
“off”: Name Server disabled, no query forwarding
“custom”: Custom configuration of Name Server
Example: bind mode=custom
2005-2008
c Comdasys AG 224
Name: bind dnsx

Description: IP address of a DNS server (forwarder ) that should be asked if a DNS
query could not be resolved
Example: bind dns0=10.42.1.10
Name: bind slaveZonex

Description: IP address of a master server for the given zone of type slave
Example: bind slaveZone0=[zoneName;10.42.1.11;zoneFileName]
Name: bind forwardZonex

Description: IP addresses of one or more forwarder servers for the given zone of type
forward. IP addresses have to be separated by blank
Example: bind forwardZone0=[zoneName; 10.42.1.12 10.42.1.14]
5.6.10 Settings for Routing (routex)
These settings contain static routes, one per parameter. The parameters need to be num-
bered consecutively; if a number is missing, processing of routing information will stop at that
gap.
Name: routex
Description: Static route with numerical identifier <x>; parameter contains all informa-
tion in a semicolon separated array:
[<Network to be routed to>; <netmask of network to be routed to>; <gate-
way>; <interface>]
Example: route0=[10.1.0.0;255.255.255.0;10.0.0.254;LANA]
route1=[10.2.0.0;255.255.255.0;10.0.0.254;LANA]
Name: proxy sip transparent

Description: Enables transparent sip proxy functionality
Example: proxy sip transparent=on
5.6.11 Bandwidth (htb )
Name: htb classx

Description:
Example:
Name: htb virtifx

Description:
Example:
2005-2008
c Comdasys AG 225
Name: htb ifx default

Description:
Example:
5.6.12 Settings for Bandwidth Daemon(bw )
These settings configure the bandwidth daemon that monitors the network traffic and calcu-
lates the current average bandwidth. The bandwidth daemon is queried by the SIP proxy for
Call Admission Control (CAC).
Name: bw rate
Description: Sample rate, in tenth of second; the default value is “1”
Example: 1
Name: bw size
Description: Number of samples; combined with bw rate this value determines the size
of a time window the bandwidth daemon uses; the default value is “30”
Example: 30
Name: bw log
Description: Log level; possible values are: “none”, “error”, “warning”, “info”,
“debug”
Example: info
5.6.13 NTP (ntp )
These settings define NTP servers that can be used to synchronize the system time with.
Name: ntp on
Description: Turning on/off NTP; one of:
“on”: NTP feature enabled; implies ntp namex, ntp prefx
“off”: NTP feature disabled
Example: ntp on=on
Name: ntp namex

Description: IP address of an NTP server
Example: ntp name0=10.42.1.10
Name: ntp prefx

Description: Preferring answers sent by a particular NTP server; one of: “on”, “off”
Example: ntp pref0=on
2005-2008
c Comdasys AG 226
5.6.14 Settings for Firewall (fw )
These settings contain all information to configure iptables. In general firewall rules are exe-
cuted in the following order:
• Allow rules for active clients (DNS, dynamic DNS, syslog, etc.)
• Allow rules for admin access (ssh and https)
• Allow rules for IPsec and OpenVPN
• Allow rules for base services (see fw lana services, fw lanb services)
• Include file /etc/sysconfig/firewall.custom (except rules added with ”iptables
-I”)
• User defined rules (with fw rulex ..., see below)
• Deny all
5.6.14.1 Meta Parameters for Firewall (fw )
There are a number of ”meta” rules that cause a whole range of rules to be generated.
Name: fw seclevel
Description: This parameter allows to disable all access configuration and set the Con-
vergence to a special secure mode. Valid values:
• “secure”: All local Internet access is switched off. Only access be-
tween local networks and remote sites via tunnel connections are
possible.
• “custom”: normal operation
Example: fw seclevel=custom
Name: fw loglevel
Description: Level indicating which rules generate messages; value is an integer be-
tween “0” (no logging at all) and “9” (very verbose logging). Default level is
“4” (log all denied packets).
This parameter just states how many iptables LOG rules are created.
Example: fw loglevel=0
Name: fw ssh via lana

Description: Permit (“1”) or deny (“0”) SSH access to the Convergence via the first LAN
interface (eth0)
Example: fw ssh via lana=0
2005-2008
c Comdasys AG 227
Name: fw ssh via lanb

Description: Permit (“1”) or deny (“0”) SSH access to the Convergence via the second
LAN interface (eth2)
Example: fw ssh via lanb=0
Name: fw ssh via wan

Description: Permit (“1”) or deny (“0”) SSH access to the Convergence via the WAN
interface (eth1)
Example: fw ssh via wan=0
Name: fw https via lana

Description: Permit (“1”) or deny (“0”) HTTPS access to the Convergence via the first
Example: fw https via lana=0
Name: fw https via lanb

Description: Permit (“1”) or deny (“0”) HTTPS access to the Convergence via the second
Example: fw https via lanb=0
Name: fw https via wan

Description: Permit (“1”) or deny (“0”) HTTPS access to the Convergence via the WAN
interface (eth1)
Example: fw https via wan=0
Name: fw lana all open

Description: Permit (“1”) or deny (“0”) unlimited access from the first LAN interface (eth0)
to the internet.
This only applies to outgoing connections.
Example: fw lana all open=1
Name: fw lana services

Description: List of outgoing services, seperated by whitespaces, that are valid through
the first LAN interface (eth0). Valid services are:
“DNS”, “FTP”, “SSH”, “TELNET”, “POP3”, “SMTP”, “HTTPS”, “HTTP”, “NTP”,
“PING”, “SNMP”
Example: fw lana services=FTP SSH HTTP HTTPS
Name: fw lanb all open

Description: Permit (“1”) or deny (“0”) unlimited access from the second LAN interface
(eth2) to the internet.
This only applies to outgoing connections.
Example: fw lanb all open=0
2005-2008
c Comdasys AG 228
Name: fw lanb services

Description: List of outgoing services, seperated by whitespaces, that are valid through
the second LAN interface (eth2). Valid services are:
“DNS”, “FTP”, “SSH”, “TELNET”, “POP3”, “SMTP”, “HTTPS”, “HTTP”, “NTP”,
“PING”, “SNMP”
Example: fw lanb services=FTP SSH HTTP HTTPS
Name: fw lana lanb open

Description: Permit (“1”) or deny (“0”) unlimited access between the two LANs (Only
supported, if second LAN is internal)
Example: fw lana lanb open=1
5.6.14.2 Firewall Rules (fw rulex )
These settings contain rules, one per parameter set fw rulex

The rules have to be numbered consecutively (substitute x with that number); if a number is
missing, processing of rules will stop at that gap.
Almost all parameters apart from fw rulex in int, fw rulex out int (which may be
ANY), fw rulex policy and fw rulex type are optional; generally not giving a parameter
means a wildcard (all possible values).
If the security level (fw seclevel) is switched from custom to secure, all existing firewall rule
parameter are renamed to no fw rulex and therefore not applicable. If the security level
is switched back, all these rules are activated again by renaming them back to their normal
names.
Name: fw rulex in int

Description: Incoming interface for rule x; one of “ANY”, “WAN ”, “LAN1”, “LAN2”, a tunnel
name (generating forward rule) or “LOCAL” (generating incoming rule)
Example: see example below ??
Name: fw rulex out int

Description: Incoming interface for rule x; one of “ANY”, “WAN ”, “LAN1”, “LAN2”, a tunnel
name (generating forward rule) or “LOCAL” (generating outgoing rule)
Name: fw rulex s ip
Description: Source IP address; may also specify a network address.
In fact, if fw rulex s nm is not “255.255.255.255”, it has to be a valid
network address.
2005-2008
c Comdasys AG 229
Name: fw rulex s nm
Description: Source IP address netmask.
If fw rulex s nm is not “255.255.255.255”, fw rulex s ip has to be
a valid network address.
Name: fw rulex s port

Description: Source port for packet; only used if fw rulex type is “TCP” or “UDP”
Name: fw rulex d ip
Description: Destination IP address; may also specify a network address.
In fact, if fw rulex d nm is not “255.255.255.255”, it has to be a valid
network address.
Name: fw rulex d nm
Description: Destination IP address netmask.
If fw rulex d nm is not “255.255.255.255”, fw rulex d ip has to be
a valid network address.
Name: fw rulex d port

Description: Destination port for packet; only used if fw rulex type is “TCP” or “UDP”
Name: fw rulex policy

Description: “ACCEPT” or “DENY” (which is useless in most cases, because the “DENY
ALL” rules are next to these rules.
Name: fw rulex type

Description: Protocol type for this rule; is either “TCP”, “UDP” or “ICMP” or a protocol
number (e.g. from /etc/protocols)
2005-2008
c Comdasys AG 230
Name: fw rulex icmp type

Description: ICMP type to which the rule shall apply; only used if fw rulex type is
ICMP. Valid values are:
“address-mask-request”, “address-mask-reply”,
“destination-unreachable”, “echo-reply”, “echo-request”,
“parameter-problem”, “redirect”, “router-advertisement”,
“router-solicitation”, “source-quench”, “timestampreply”,
“timestamp-request”, “time-exceeded”
5.6.15 Example for fw rulex
fw_rule0_in_int=ANY
fw_rule0_out_int=WAN
fw_rule0_d_ip=16.1.2.120
fw_rule0_d_nm=255.255.255.255
fw_rule0_d_port=22
fw_rule0_policy=ACCEPT
fw_rule0_type=TCP
This allows access from any internal network SSH (i.e. port 22) access to the internet com-
puter with address 16.1.2.120.
5.6.16 Settings for Port Forwarding (fwd )
These settings contain port forwardings to computers in NAT’ed local networks, one per pa-
rameter. The parameters have to be numbered consecutively; if a number is missing, pro-
cessing will stop at that gap.
Name: fwdx
Description: Forwarding rule; parameter contains all information in semicolon separated
array:
Port on Convergence target IP address, target port
Example: fwd0=[2222;10.0.0.10;22]
Sets port forwarding from Convergenceś WAN interface
port 2222 to the SSH port on local box 10.0.0.10
5.6.17 Settings for VPNs (vpnx )
These settings contain VPN definitions, one tunnel per parameter set vpnx . The tunnels
have to be numbered consecutively; if a number is missing, processing of tunnels will stop at
that gap.
2005-2008
c Comdasys AG 231
These parameters describe IPsec and OpenVPN tunnels. While most parameters are com-
mon for both types, there are some specific ones:
• IPsec only: vpnx local if, vpnx remote
• OpenVPN only: vpnx local ip, vpnx remote ip, vpnx port, vpnx tls
Name: vpnx name

Description: A (preferably not too long) unique name describing the tunnel connection.
Example: vpn0 name=munich-branch
Name: vpnx active

Description: A possibility to activate (“1”) or deactivate (“0”) a tunnel temporarily.
Example: vpn0 active=1
Name: vpnx type

Description: Sets the type of the tunnel. It has either the value “openvpn” or “ipsec”.
If the type is “openvpn”, a tun device with the VPN’s number will be used
(e.g. for vpn0 ... a device /dev/tun0 will be created)
Example: vpn0 type=ipsec
Name: vpnx partner net

Description: Remote side’s network to be secured by the tunnel.
Example: vpn0 partner net=10.5.0.0
Name: vpnx partner nm

Description: Netmask of remote side’s network be secured by the tunnel.
Example: vpn0 partner net=255.255.255.0
Name: vpnx partner ip

Description: Public IP address of remote VPN gateway.
If this value is given, vpnx partner name is not evaluated.
If neither this parameter nor vpnx partner name are set, a road warrior
with dynamic IP address is assumed.
Example: vpn0 partner ip=219.23.132.67
Name: vpnx partner name

Description: Public DNS name of remote VPN gateway.
A dynamic DNS name may only be used with OpenVPN tunnels, as IPsec
and dynamic DNS names result in synchronisation problems as soon as
the dynamic DNS host’s IP address changes.
If neither this parameter nor vpnx partner ip are set, a road warrior with
dynamic IP address is assumed.
Example: vpn0 partner name=vpngate.mycompany.com
2005-2008
c Comdasys AG 232
Name: vpnx local if

Description: Interface connected to the IPsec tunnel; alternatively an IP address on a
local network, that will be connected to the tunnel then.
Example: vpn0 local if=LAN1
Name: vpnx local ip

Description: Local side’s IP address for OpenVPN transfer network. This address and
vpnx remote ip must be unique (especially different OpenVPN connec-
tions may not use the same addresses).
This address must be used as remote IP on the remote gateway.
Example: vpn0 local ip=10.254.254.1
Name: vpnx remote ip

Description: Remote side’s IP address for OpenVPN transfer network. This address
and vpnx local ip must be unique (especially different OpenVPN con-
nections may not use the same addresses).
This address must be used as local IP on the remote gateway.
Example: vpn0 remote ip=10.254.254.2
Name: vpnx port

Description: Port number to be used for the OpenVPN connection. The port must be
unique (especially different OpenVPN connections may not use the same
port). Normally port numbers start from 5000 and are incremented for ad-
ditional connections.
This port must be the same as configured on the remote gateway.
Example: vpn0 port=5001
Name: vpnx ss
Description: Defines
• a shared secret for a password based setup of an IPsec connection
• a shared secret file for a shared secret based setup of an OpenVPN
connection. The file /etc/openvpn/secrets/<ss>.key must ex-
ist.
This parameter and vpnx cert are mutually exclusive.
Example: vpn0 ss=test secret
2005-2008
c Comdasys AG 233
Name: vpnx cert

Description: Defines a certificate for a certificate based setup of the IPsec/OpenVPN
connection. This parameter and vpnx ss are mutually exclusive.
The following files must exist locally for IPsec connections:
• /etc/ipsec.d/certs/<certificate>-cert.pem
containing a X.509 certificate
• /etc/ipsec.d/private/<certificate>-key.pem
containing the RSA key
The following files must exist locally for OpenVPN connections:
• /etc/ssl/certs/<certificate>-cert.pem
• /etc/ssl/private/<certificate>-key.pem
containing the RSA key
• /etc/ssl/CA/certs/<CA certificate>-cert.pem
containing the CA certificate the certificate was signed with
All these files are normally managed by the web interface.
Example: vpn0 cert=roadwarrior
Name: vpnx remote

Description: Describes the X.509 compatible subject of the remote certificate.
If the remote certificate was created on the Convergence and exported to
the remote PC as PKCS12 certificate, the subject can be checked in the
web interface or with the following command on the Convergence:
openssl x509 -in /

etc/ssl/certs/<remotecertificate>.cert.pem -text |
grep
Subject:
This information is only necessary for IPsec connections, for OpenVPN

connections the CA cert information is processed automatically (TLS con-
nection).
Example: vpn0 remote=CN=L2TP-Mobile,OU=Mobile,O=Test-Org,C=DE
Name: vpnx tls

Description: Certificate based OpenVPN connections use TLS; one of the connection
partners has to be defined as TLS server, the other one as TLS client.
Example: vpn0 tls=server
2005-2008
c Comdasys AG 234
5.6.18 Settings for L2TP Server (l2tp )
5.6.18.1 Generic L2TP Server Settings (l2tp )
These settings contain all information to set up a L2PT server on the Convergence.
Name: l2tp active

Description: This parameter allows a temporary switch off of the l2tp server without the
need to delete all parameters. Values are “1” (active) and “0” (not active).
Example: l2tp active=1
Name: l2tp local ip

Description: Sets the local IP address within the network allocated to the L2TP transfer
network. At the same time, together with “l2tp netmask”, defines the
L2TP transfer network.
Example: l2tp localip=192.168.2.1
Name: l2tp netmask

Description: Defines the size of the L2TP transfer network
Example: l2tp netmask=255.255.255.0
Name: l2tp rangestart

Description: Within the L2TP transfer network, defines the first address to assign to
a client that has not defined its own static IP address; the value has
to be within the L2TP transfer network defined by l2tp localip and
l2tp netmask.
Example: l2tp rangestart=192.168.2.100
Name: l2tp rangeend

Description: Within the L2TP transfer network, defines the last address to be assigned
to a client that has not defined its own static IP address; the value has
to be within the L2TP transfer network defined by l2tp localip and
l2tp netmask.
Example: l2tp rangeend=192.168.2.200
Name: l2tp msdns

Description: Defines a DNS server that will be assigned to the clients (optional)
Example: l2tp msdns=217.145.104.11
Name: l2tp mswins

Description: Defines a WINS server that will be assigned to the clients (optional) to allow
them WINS name resolution and browsing.
Example: l2tp mswins=10.0.0.200
2005-2008
c Comdasys AG 235
5.6.18.2 User Based L2TP Server Settings (l2tp userx )
These settings contain settings that apply to special users / computers upon their connection
setup. The user specific parameters have to be numbered consecutively; if a number is
missing, processing will stop at that gap.
When using L2TP to connect Windows XP and Windows 2000 computers, there is a number
of protocol layers involved:
1. Mostly PPP to connect the remote computer to the Internet; authentication is done via
connection settings.
2. An IPsec connection is set up to establish an encrypted communication channel; the
authentication can be done via passwords (shared secrets) or certificates; both possi-
bilities can be configured on a per-user basis.
3. An L2TP (Layer 2 tunnel protocol) connection is established on top of IPsec. No authen-
tication is done on this layer.
4. On top there is another PPP session that finally establishes an IP session between the
remote computer and the Convergence. This session has to be authenticated again,
using username and password. Within this session, the remote computer also receives
its IP address.
Name: l2tp userx name

Description: PPP login name
Example: l2tp user0 name=testuser
Name: l2tp userx pwd

Description: PPP login password
Example: l2tp user0 pwd=testpwd
Name: l2tp userx ip

Description: Optional static IP address; if this value is set, the user always receives the
same IP address, otherwise he gets one from the pool l2tp rangestart
- l2tp rangeend. The value has to be within the L2TP transfer network
defined by l2tp localip and l2tp netmask, but outside the pool de-
fined by l2tp rangestart and l2tp rangeend.
This option might be interesting for setting special firewall rules for particu-
lar users.
Example: l2tp user0 ip=192.168.1.30
Name: l2tp userx ss

Description: Defines a shared secret for a password based setup of the IPsec connec-
tion. This parameter and l2tp userx cert / l2tp userx remote are
mutually exclusive.
Example: l2tp user0 ss=test secret
2005-2008
c Comdasys AG 236
Name: l2tp userx cert

Description: Defines a certificate for a certificate based setup of the IPsec connection.
This parameter and l2tp userx ss are mutually exclusive.
The following files must exist locally:
• /etc/ipsec.d/certs/<certificate>-cert.pem
• /etc/ipsec.d/private/<certificate>-key.pem
containing the RSA key.
These files are normally managed by the web interface.
Example: l2tp user0 cert=roadwarrior
Name: l2tp userx remote

Description: Describes the X.509 compatible subject of the remote certificate.
If the remote certificate was created on the Convergence and exported to
the remote PC as PKCS12 certificate, the subject can be checked in the
web interface or with the following command on the Convergence:
openssl x509 -in /etc/ssl/certs/<remotecertificate>.cert.pem
-text | grep Subject:
Example: l2tp user0 remote=CN=L2TP-Mobile,OU=Mobile,O=Test-Org,C=DE
5.6.19 Settings for SNMP (snmp )
These settings configure the SNMP-Daemon.
Name: snmp enable

Description: Enable or Disable the SNMP daemon
Example: snmp enable=on
Name: snmp ropass

Description: Specify the read-only community pass for SNMP version 1 and 2c
Example: snmp ropass=example
Name: snmp rwpass

Description: Specify the read-write community pass for SNMP version 1 and 2c
Example: snmp rwpass=example
Name: snmp proxy(0..9)

Description: Enable the snmp daemon to act as a proxy format = [ip-
adress;port;password;version;OID]
Example: snmp proxy0=[127.0.0.1;22;password;2c;.1.3]
2005-2008
c Comdasys AG 237
5.7 Settings for Voice-over-IP (ser )
Name: snmp trap

Description: Enables the trap-sending functionality of the SNMP daemon
Example: snmp trap=on
Name: snmp trap community

Description: Specify the SNMP community name for sending traps
Example: snmp trap communitys=foo
Name: snmp trap dest(0..9)

Description: Specify the ip-adress destination for SNMP traps
Example: snmp trap dest=127.0.0.1
These settings configure the SIP proxy service. This service features multiple configuration
templates that are explained in more detail in the handbook. The parameter values discussed
here are sometimes used for multiple configuration templates. This is always explained to-
gether with the keys. Besides the parameter values as explained below, the keys for tls have
to be setup if this is desired. All Comdasys products will autocreate tls keys for use with the
SIP Proxy. If the interaction with phones is desired, there are two ways of setting this up. Ei-
ther you download the preconfigured keys (they are generated on first boot of the Comdasys
device, or you upload the desired keys to the Comdasys.
5.7.1 SIP Proxy Scenarios
The most important parameter is that for selecting the used template profile is the ser type
parameter. This one selects the scenario the product is to be used in. The following scenarios
are possible.
5.7.1.1 Disabled
Disable SIP Proxy functionality.
5.7.1.2 Custom
Custom template that permits configuration via CLI. This is usually not recommended unless
for specialized projects. This is mostly used in large projects with specialized configuration
templates that are put into the Convergence through mass deployment tools.
2005-2008
c Comdasys AG 238
5.7.1.3 Standalone
Standalone template which will make SIP Proxy act as a standalone SIP server. This is a
very simple template to setup simple configurations. The configuration of voice gateways to
enable outbound calls is supported.
5.7.1.4 Survivability
Survivability template which will forward all messages to a central SIP server unless this one
is unavailable. In this case, the SIP Proxy will take over the role of the central SIP server. This
template also support CAC scenarios.
5.7.1.5 Session Border Controller
Session Border Controller template that makes the SIP Proxy act as an SBC in front of a SIP
server / B2BUA. There is a great varierty of configurations for this. Depending on the exact
usage, the Survivability and Branch SBC configurations could also apply. This selection is
the template for a typical centralized Session Border Controller used to connect endpoints
coming from the Internet, usually behind NAT Routers. This template will hence perform NAT
handling.
5.7.1.6 Branch Session Border Controller
Branch SBC which sits in front of a SIP server but at a decentral location instead of a central
one as with the SBC template. As such, it will typically serve in Enterprise Branch Office
scenarios, or in Hosted scenarios. A hosted service provider can use the product to terminate
his service at the customer premise. In order to use that service, the Convergence would
receive one data center IP address as well an IP address in the local range. With that, the
phones on the customer premise would only interact with the Convergence through a local IP
address. No changes to the network, routing or anything else would be necessary to support
deploying a VoIP solution.
5.7.1.7 SIP Trunking Scenario
The Convergence offers two different ways of handling SIP Trunking scenarios, via the SIP
Proxy / SBC component and via the B2BUA. The selection here will make the Convergence
behave like a special SBC for SIP Trunking scenarios. As such, it will not perform a registration
with a provider, the locally connected PBX / SIP server behind the SBC has to perform that.
The SBC approach has the advantage that features between the local PBX and the Trunking
Provider are transparently handed through. This is something a B2BUA approach cannot
absolutely guarantee.
2005-2008
c Comdasys AG 239
5.7.1.8 Cascaded SBC Scenario
This scenario is a very specialized central SBC scenario where it is assumed that a Branch
SBC is connected behind. In contrast to the central SBC scenario, it will not stay in the
media path for connections that stay ”inside” a single branch. This also works dynamically for
features. For example if you first have a branch internal call, the central SBC will not be in the
media stream. If the media however is renegotiated for example because one party was put
on hold, the central SBC can pcik up the media stream.
5.7.1.9 ENUM Scenario
With this template the SIP Proxy will act as an IP-to-IP gateway performing message forward-
ing based on ENUM lookups as well as SBC functionality for incoming calls.
5.7.2 Configuration Explanation
Name: ser type

Description: This value selects the profile type, the SIP Proxy is to be setup
in. The Comdasys Convergence appliances support a number of pre-
defined scenarios that are explained in more detail in the following.
“disabled” Disabled
“custom” Custom template
“standalone” Standalone
“survivability” Survivability
“sbc” Session Border Controller
“branch” Branch Session Border Controller
“cascaded” Cascaded Session Border Controller
“enum”
Example: ser type=survivability
Name: ser action

Description: For each Call Admission rule definition, the SIP proxy permits the specifica-
tion of an action in the case of a limit violation. As mentioned with the CAC
parameters, simply denying calls is the simplest of all actions that can be
taken. Sometimes however it is inappropriate. Imagine for example a case
where we can route a call over multiple links. Since the Convergence Se-
ries is operating at the edge of one or more bottleneck links, there might be
an alternative route to the destination via a second link. The other possibil-
ity is to use the TDM network via a gateway realizing a local breakout. This
second possible action is Redirect. Choose one of the two from the Drop-
Down list. Future versions will come with additional actions. The possible
action are ”redirect” and ”deny”.
Example: ser action0=deny
2005-2008
c Comdasys AG 240
Name: ser amt

Description: This parameter is relevant for Survivability, Standalone, Branch SBC, and
Enum scenarios. This parameter represents the digit combination a user
has to dial for getting an outside line. In Standalone mode this will be
directly used for determining the calls that have to go to the gateway. In
the other modes, the parameter will only be used in Survivability mode. In
theory, you can put any regular expression here, although in reality this will
mostly be a single digit as for example a 0 or a 9.
Example: ser amt=0
Name: ser cac

Description: This option applies to the Branch SBC as well as to the Survivability sce-
narios. All Call Admission control related settings for these two scenarios
will only apply if this option is activated. This parameter however does not
apply for any Call Admission Control settings towards a gateway. It only ap-
plies to to the Call Admission Control towards the central SIP server. The
possible actions are ”on” and ”off”.
Example: ser cac=on
Name: ser cacchecknet

Description: This parameter should be checked if there is a local PSTN in the branch
office. If this parameter is not checked, the SIP Proxy will assume that all
Calls to and from non-local destinations will go over the bottleneck link and
hence require Call Admission Control (of course only if all other parameters
match). This would however mean, that for a Call coming in over the local
gateway, going to the central SIP server then coming back in to the SIP
Proxy, Call Admission Control would be falsely performed although the Me-
dia Stream would stay in the local network. Strict checking will additionally
check the SDP header to determine how the RTP streams would flow to
correctly perform the Call Admission Control. The possible actions are ”on”
and ”off”.
Example: ser cacchecknet=on
Name: ser callforward

Description: This parameter is a list, meaning that you have to attach a number from
0 - ... . Therefore, it is of course possible to have multiple entries where
the numbers must of course be unique. Also note that this parameter can
only be used in conjunction with the ser callforwardtarget parame-
ter. This parameter is only relevant in the Survivability scenario and will only
become active in survivability mode. The parameter will identify an incom-
ing call in survivability mode. If the user part of the request URI matches
the this parameter, the call will immedialtely be redirected to the user given
in the ser callforwardtarget parameter with the matching index.
Example: ser callforward0=4711
2005-2008
c Comdasys AG 241
Name: ser callforwardtarget

Description: This parameter is a list, meaning that you have to attach a number from
0 - ... . Therefore, it is of course possible to have multiple entries where
the numbers must of course be unique. Also note that this parameter can
only be used in conjunction with the ser callforward parameter. This
parameter is only relevant in the Survivability scenario and will only become
active in survivability mode. A call in survivability mode directed to the
user name given in the ser callforward with the matching index will be
directed to the username given here.
Example: ser callforwardtarget0=4712
Name: ser children

Description: Determines the number pf threads being forked off in the SIP proxy per
interface. A higher number of threads will lead to a higher efficiency in
using the available CPU resources at the expense of higher memory and
resource usage. Recommended number for smaller Convergence boxes is
8, for bigger ones 16 or 32.
Example: ser children=8
Name: ser debug

Description: This option will enable debug support for the SIP proxy. The debugging
messages will be printed out in the system log. See “syslog” documenta-
tion for more information on how to read and use this debug output. Note
that some output will be generated by default. Among these is CDR in-
formation in survivability mode that will always be generated. The debug
mode should only be switched on for testing purposes since depending on
the traffic conditions, a lot of log information can be generated. The possi-
ble values are ”on” and ”off”.
Example: ser debug=off
Name: ser domain

Description: The Domain list parameter is one of the most important parameters for the
SIP Proxy. The SIP Proxy will only apply the Survivability / Call Admission
Control / SBC logic to SIP messages directed at specified domains. Do-
main as used here refers to the rear part of a URI parameter. This means
that if you have some client send a SIP message for 500@foo.bar to
the Comdasys Convergence appliance, it will only act upon it in the way
described here if foo.bar can be found in the domain list. Otherwise it
will simply perform a DNS lookup and forward the message appropriately.
Possible values are either foo.bar, or an ip address.
Example: ser domain0=foo.bar
2005-2008
c Comdasys AG 242
Name: ser dst ip

Description: The notion of a link is fundamental to the way the Call Admission Control
is done. The simplest case of a link is a physical network connection. The
Convergence however does not stop there. A link is closely associated
with the routing functionality offered by the ConvergenceṪypically source
and destination addresses are used for classifying packets as belonging to
a certain link (matches the standard IP networking principles). The source
address could for example be used to configure groups for the phones.
Group 1 could get a range of IP addresses, Group 2 another. Simply enter
the Source and Destination IP addresses or network addresses that you
want have the limit and action applied to. The mentioned IP addresses
pertain to the SIP signalling traffic. The source would for example be the
local branch network; the destination would most likely be the IP PBX. Use
a ”0” for each byte of the IP address where you want to specify network
ranges.
Example: ser dst ip0=192.168.1.1
Name: ser dualreg

Description: This enables dual registration functionality inside the SIP proxy for sup-
porting Survivability scenarios with Cisco or Siemens phones. In princi-
pal, this is not necessary since the Comdasys survivability functionality is
completely transparent to the UAs. Some UAs however support displaying
something to the user to inform him about survivability mode. One of these
options lets the phones register to a primary server and a backup server.
As soon as the primary server stops responding, they will register to the
backup server for continous operation. Sometimes, it is desirable to use
this phone functionality. Comdasys supports this by running on port 5080
in addition to the standard port. If enabled, the SIP proxy will stop respond-
ing on port 5060 and only respond on port 5080 thus emulating the backup
server functionality. This option is very rarely used. The possible values
are either ”on” or ”off”.
Example: ser dualreg=off
Name: ser excludegw

Description: This parameter has to be considered in conjunction with the ser return
parameter. It applies to all scenarios involving the explicit defintion of a
gateway. If the return route for SIP messages is forced by the proxy, it might
be necessary to exclude the local gateway from this, since your SIP server
might want to stay in direct touch with the local gateway. This can have
multiple reasons, the most likely reason would be features. The possible
values are either ”on” or ”off”.
Example: ser excludegw=on
2005-2008
c Comdasys AG 243
Name: ser failover

Description: This option enables you to turn on or off failover server support. Failover
server support is usually realized in conjunction with DNS SRV or VRRP
to have a backup take over the IP address of the primary SIP proxy. The
option here only refers to the SIP part of this construct which requires to
have a backup server be in the same conditions concerning states and
registrations as the primary server. If this option is set, all state informa-
tion will be replicated to the failover server that can be specified with the
ser failover server parameter. The possible values are either ”on” or
”off”.
Example: ser failover=on
Name: ser failover server

Description: For more information on this option please also refer to
ser failover server. This option will set the IP address or DNS
name of the failover server that all state information should be forwarded
to. Note that the backup server should again have the primary server set
as failover pendant, since the roles are bound to change depending on
configuration of course. Setting this up in such a manner will however
by no means result in messages bouncing back and forth since this is
automatically detected by the software. The possible values are either ”on”
or ”off”.
Example: ser failover server=on
Name: ser faxuri

Description: This parameter must be seen in conjunction with the
ser t38redirection parameter. This means that all streams for
T38 will be treated differently than the normal voice streams. In contrast
to normal voice streams, T38 streams will exhibit a great deal of variance
when it comes to a call in progress. T38 streams can vary from anywhere
between 10 kbit/s and 100 kbit/s in throughput, meaning that a measure-
ment is not something you want to rely on. Therefore, we do a reservation
for these cases, where the call for the fax remains reserved for the entire
duration of the call. In this case, it is of course not necessary to have
Example: ser faxuri0=45674@foo.bar
2005-2008
c Comdasys AG 244
Name: ser forwarding

Description: This function activates server based call forwarding in Survivability mode,
or as a Standalone server. It does not have an effect in any other usage
scenario. Even in the Survivability scenario, it will only have an effect if you
are currently in survivability mode. In that mode, this flag instructs the SIP
Proxy to catch any SIP 302 response sent by an UA and creates a new
INVITE request from that. This also works in conjunction with SIP forking.
If the original request was forked and one UA responds with 302, all other
branches will be Cancelled. The possible values are ”on” or ”off”.
Example: ser forwarding=off
Name: ser gateway ip

Description: This parameter is a list, meaning that you have to attach a number from 0
- ... . Therefore, it is of course possible to have multiple entries where the
numbers must of course be unique. As the name already indicates, this
parameter denotes the gateway IP address. Gateways can be defined for
most scenarios except ENUM and SBC. For all remaining scenarios, it is
possible to define multiple gateways. The gateways will be addressed in a
hunting mode, meaning that the SIP proxy will first always address the first
gateway. If it gets an error from there, it will proceed to the second one and
so on. For the exact behavior in this case, please see the centryser hunting
parameter.
Example: ser gateway ip0=192.168.1.2
Name: ser gateway prefix

Description: The prefix determines what digits or characters to attach to the front of
the URI before forwarding to the gateway. The prefixing will only apply in
Survivability mode. The prefixing will always be executed after stripping the
URI. Also refer to ser gateway strip for more information on this.
Example: ser gateway prefix0=0
Name: ser gateway strip

Description: Determines how many digits should be stripped from the front of the num-
ber before forwarding the request to the gateway. Note that this only ap-
plies to Survivability scenarios. In normal mode, the SIP Proxy will never do
changes to the URI when forwarding requests to a gateway. Note that this
parameter does not specify what to remove from the front of the number, it
rather specifies the number of digits to remove. It should be noted that this
not only works for digits, but for all characters permitted in SIP URIs.
Example: ser gateway strip0=1
2005-2008
c Comdasys AG 245
Name: ser gateway transmit

Description: This determines the SIP transmit type to be used towards the gateway.
RFC3261 currently defines three transmit types, udp, tcp, and tls. Most
systems currently use udp, so this will most likely be your protocol of choice.
There are reasons however for using tcp, which is also supported by a
lot of systems. If you need security, there is no other way but to use tls.
Beware however that you cannot do traces of tls encrypted signalling to
track down errors. It is therefore highly recommended to set up a system
with an unencrypted protocol and only switch to tls once everything works.
The possible values are either ”udp”, ”tcp”, or ”tls”.
Example: ser gateway transmit0=tcp
Name: ser hunting

Description: This paramerter determines the behavior of the SIP Proxy if multiple gate-
ways are being set up. If set to on, a gateway hunting will be done meaning
that the SIP Proxy will automatically try the next gateway if the previous
one did not respond or responded with an error. Mostly this error will be
a ”486 Busy”. Note that the hunting usually only applies in Survivability
mode, since in normal mode, the central SIP server can correctly address
the SIP messages to go to the correct gateway. In these cases the central
SIP server would perform the gateway hunting. There are however special
scenarios where the SIP Proxy itself is specified as a gateway (e.g. Branch
SBC functions). In that case, the Proxy will of course also perform the
hunting functionality. The possible values are either ”on” or ”off”.
Example: ser hunting=on
Name: ser limitcall

Description: Each SIP session uses a certain average bandwidth depending on the
codec being used. For G.711 for example the bandwidth required for each
session is around 75 - 80 kbit/s including the overhead packets. The band-
width check parameter here, identifies how much bandwidth must still be
available in order to permit another session. Note that you have to enter the
parameter manually, since codices can be renegotiated during a session.
This means that this parameter has to reflect the worst case that can occur
in your network. Otherwise this would mean that your session is permitted
first, then renegotiated with another codec and denied there. This kind of
behaviour would be very user unfriendly. For each Call Admission decision,
as to whether a call should be permitted or not, the worse case is hence
assumed. This field should therefore reflect this worst case. It can also be
used for deliberately leaving some room to the bandwidth limit by checking
for a higher bandwidth than required. The difference would then remain un-
used which can be desirable under certain conditions. Note that this field
is entered in ”bytes/second”, not ”bits/s”.
Example: ser limitcall=8000
2005-2008
c Comdasys AG 246
Name: ser limitclass

Description: The Limit Class definitions make the connection between the SIP and the
IP layer in Call Admission Control scenarios. All traffic class definitions are
used for making assessments as to whether additional calls can be accom-
modated. For the Limit definitions, the Bandwidth Management Configura-
tion is used where a traffic class with certain limits is defined. The limit is
enforced by the Call Admission Control functionality. For more information
on the definition of the traffic rules refer to the Bandwidth section of this
handbook or the User Guide.
Example: ser limitclass0=eth0-2:4
Name: ser multiport

Description: Only use this parameter if you know what you are doing. This option has a
severe impact on the SIP request routing behavior. Setting this option will
make the SIP proxy modify all SIP requests in such a way, that every UA
connected behind the SIP proxy will be mapped to a separate port on the
SIP proxy. This means that the central SIP server will think that all phones
have the IP address if the SIP proxy, but each one with a separate port. This
enables supporting features in e.g. NAT scenarios where the return route
also has to pass through the SIP proxy. Please also refer to ser return
for more information. This option is not required if your SIP server features
an option to route requests through a SIP proxy. The possible values are
either ”on” or ”off”.
Example: ser multiport=on
Name: ser notifyreturn

Description: This parameter enables or disabled the function of sending Survivability
Notifies. If enabled, the SIP proxy will send a SIP NOTIFY message to all
registered devices each time the Survivability mode changes. This means
that a message will be sent, if the Survivability mode becomes active, an-
other one will be sent if normal operations is being restored. The possible
Example: ser notifyreturn=on
2005-2008
c Comdasys AG 247
Name: ser ownnumber

Description: This parameter is being used for short dialing in Survivability and Stan-
dalone mode. As such, it of course also applies to the Branch SBC mode.
If you have a telephone with the phone number e.g. 49893333567, where
567 is the short number of the phone, you want to be able to use both the
long and the short number in survivability mode where the PBX normally
doing the translation is offline. The phone registers (SIP registration) with
the full number. To make it reachable now, the Comdasys must know the
prefix, hence the 49893333 which it will attach to the short number to lo-
cate the phone. If you do not set this up, it will only have an impact on this
feature (Short numbers in Survivability mode). It is not used for anything
else.
Example: ser ownnumber=49893333
Name: ser pbx

Description: This entry is the IP address of the softswitch, SIP server, or SIP PBX. In
Survivability, Enum, SBC, and Branch SBC scenarios, this will be the target
of all messages received from any UAs. In the Standalone scenario, this
entry does not have any effect, since the Comdasys will be the main SIP
server. It is possible to specify both IP addresses and domain names. The
domain names can also be DNS SRV entries. Also see the ?? parameter
that determines the protocol to use for communication with the SIP server.
You can specify eihter IP addresses or domain names.
Example: ser pbx=192.168.10.3
Name: ser pbxalias

numbers must of course be unique.
This parameter will be used for identifying downstream messages as com-
ing from the PBX. This is important for e.g. performing the CAC function-
ality where incoming calls have to be handled. Messages can come from
phones or the PBX. The PBX could be a load-balanced or cluster system
meaning that messages could come from multiple IP addresses. The PBX
Alias is the way to tell the Comdasys that all these messages are coming
from the PBX. If the PBX only has a single IP address it is not necessary
to set this parameter, you can just leave it blank. You can specify eihter IP
addresses or domain names.
Example: ser pbxalias0=192.168.10.3
2005-2008
c Comdasys AG 248
Name: ser pickup

numbers must of course be unique.
This parameters allows you to specifiy extensions / URIs that will be ex-
cluded from Call Admission Control. Usually this is only relevant for pure
telephony scenarios. There it is more than common to use certain exten-
sions for doing control functionalities. This means that you make a call to
such a special extensions for e.g. activate a call forwarding. Although a
call is made, there is no real media that is ever sent in any case. Another
example for this are pickup group extensions. Enter a list of all extensions
that should be included from CAC. Note that it is possible to specify arbi-
trary regular expressions. Therefore also beware to escape (prefix by \) all
special characters used in regular expressions as for example .,?,* . Also
see the Regular Expression section for more details.
Example: ser pickup0=\*5
Name: ser prefixpbx

Description: As described in the ser redirectpbx parameter, this prefix will be added
to the dialled number to inform the central SIP server that an alternative
routing needs to be performed. This prefix can be any combination of al-
phanumeric characters and special characters like ”*” or the hash sign. In
telephony applications, the prefix will most likely be numeric.
Example: ser prefixpbx=*0
Name: ser proxy

Description: This parameter will have an effect on the response routing. This parameter
must be seen in conjunction with the centryser return parameter since it
will only have an effect if this one is set. The central SIP server will return
these messages to the IP address specified here. This applies only to SIP
requests. Response routing is determined by the Record-Route parameter
which is explained in ser rrpreset.
Example: ser proxy=192.168.6.7
Name: ser port

Description: This specifies the port for the return routing of the messages. Similar to
centryser proxy parameter, this has only an effect in conjunction with the
centryser proxy parameter. Please see these two for more information on
this option.
Example: ser port=5060
2005-2008
c Comdasys AG 249
Name: ser redirectpbx

Description: If there is no more bandwidth for permitting an extra session, the Call can
be either denied, or it can be redirected to a gateway. These actions are
described with the ser action in more detail. The field here specifies
another possible action. The SIP Proxy can modify the dialled number by
prefixing something to let the IP PBX know that the usual call routing path
does not apply. In this case, the rerouting to e.g. a local gateway can be
performed by the central IP PBX. This does not require any Call Admission
Control awareness of the central PBX, simple call routing features with mul-
tiple alternative routes, as for example found in least cost routing features,
do suffice. The central IP PBX can then route the call over the local gate-
way in the branch office, thus not generating traffic load on the bottleneck
link. Also refer to the ser prefixpbx and ser redirectpbxamtonly
parameters for more information. The possible values are either ”on” or
”off”.
Example: ser redirectpbx=on
Name: ser redirectamtonly

Description: This parameter only has an effect in conjunction with the
ser redirectpbx parameter. If enabled, the SIP Proxy will only
permit the redirection of outgoing calls. All other non-internal calls will not
get redirected but rather denied with a ”606 Not Acceptable” message.
Example: ser redirectamtonly=on
Name: ser reserve

Description: Enables or disables the bandwidth reservation. If enabled, the SIP proxy
will reserve the bandwidth for all initated SIP requests that have not been
finally answered. This means that there could be unused bandwidth in your
line, since reserved bandwidth might never be claimed because a Session
is denied. In that case, other Sessions could have been accomodated. The
higher the bandwidth available on your link, the more significant this effect
gets. On the other hand, if this option is enabled, I can never overbook a
link. The possible values are either ”on” or ”off”.
Example: ser reserve=on
Name: ser src ip

Description: This is a Call Admission Control parameter that has to be seen in con-
junction with the ser limitclass and the ser dst ip parameter. This
specifies the destination of the SIP signalling for which this CAC rule de-
fined in the ser limitclass should apply. This parameter is again a list
parameter. The matching up with the ser limitclass is done through
the index number. See also the ser dst ip parameter for a more in
depth explanation of the meaning.
Example: ser src ip0=10.10.1.1
2005-2008
c Comdasys AG 250
Name: ser survcachetimeout

Description: This is the time the last alive message from the central PBX will assumed to
be valid, even if checks fail in the meantime. This lazy timeout is intended to
reduce the number of alive messages sent, and to avoid a frequent switch-
ing due to e.g. a flapping line. This time must be given in seconds.
Example: ser survcachetimeout=30
Name: ser reroutecodes

Description: This option only applies to survivability scenarios. By default, the SIP
Proxy will reroute for all error conditions, meaning that for every non suc-
cessful reply sent for a SIP request, a rerouting to the gateway will be
induced. For this parameter just specify all codes where no rerouting
should apply. It is possible to specifiy arbitrary response codes, not only
the ones defined in the RFC. The most frequently used however are:
“400” 400 Bad Request
“401” 401 Unauthorized
“402” 402 Payment Required
“403” 403 Forbidden
“404” 404 Not Found
“405” 405 Method Not Allowed
“406” 406 Not Acceptable The reply codes are defined in a
“410” 410 Gone
“480” 480 Temporarily Unavailable
“486” 486 Busy
“487” 487 Request Terminated
“603” 603 Decline
“606” 606 Not Acceptable
list separated by blanks.
Example: ser reroutecodes=400 401 402
Name: ser rewrite

Description: This option is only relevant for all scenarios that involve a separate SIP
server. Some SIP servers react very sensitively to the SIP URI. If a UA
does not support outbound proxy functionality, the SIP domain when rout-
ing messages through the SIP proxy will be that of the SIP proxy, unless of
course DNS / DNS SRV is being used. As mentioned, some SIP servers
will then refuse to handle the sent requests. Therefore, the Comdasys SIP
proxy allows you to rewrite the SIP domain on all messages sent to the SIP
server. The domain that the requests will get rewritten with is that of the
ser pbx parameter. The possible values are either ”on” or ”off”.
Example: ser rewrite=off
2005-2008
c Comdasys AG 251
Name: ser rrpreset

Description: This parameter enables presetting the record route header that will be in-
serted by the SIP proxy in the SIP requests that are forwarded to the central
SIP server. This parameter will only be applied if its use has been enabled
by setting the ser rrpreseton parameter. By default, the SIP proxy will
insert the correct Record Route header. The ability to do this automati-
cally is however hampered in NAT and multiple interface scenarios. In such
circumstances, it is necessary to statically fix this parameter.
Example: ser rrpreset=off
Name: ser rrpreseton

Description: This parameter enables or disables the use of the ser rrpreset param-
eter. Also refer to this one for more information. The possible values are
either ”on” or ”off”.
Example: ser rrpreseton=off
Name: ser rtp

Description: This parameter determines if the SIP proxy also handles the media
streams. In Branch SBC and SBC scenarios, the SIP proxy will always
do this. In all other scenarios, this is optional and can be modified with
this parameter. If set active, the SDP information in the SIP messaging
will be modified in a way so that the media stream runs through the SIP
proxy. This is a requirement in NAT scenarios and for SRTP termination
(optionally available). The possible values are either ”on” or ”off”.
Example: ser rtp=off
Name: ser return

Description: This parameter determines if the SIP proxy will change all upstream mes-
sages in such a way, that all requests coming from the main server will
also flow through the SIP proxy under all circumstances. This applies to
all scenarions that involve another SIP server such as SBC, Survivability
and ENUM scenarios. This will make the SIP proxy modify all contact fields
that determine the SIP routing such as the Contact, Route, Record-Route
header fields. If your SIP server and UAs support Outbound Proxy function-
alities, it is not necessary to set this field. Be very careful using this field
since it can break some functions of your SIP server. In will for example
have adverse effects on any features involving SIP forking. The possible
Example: ser return=off
2005-2008
c Comdasys AG 252
Name: ser t38redirection

Description: If enabled, the SIP proxy will use bandwidth reservation to handle the
greatly varying bandwidth requirements of a T38 media stream instead of
measuring it. In order to let the SIP proxy know where he can expect T38
to be negotiated you can specify special fax URIs. See the ser faxuri
parameter for more information on that.
Example: ser t38redirection=on
Name: ser rereg

Description: Timeout value for SIP Proxy to confirm registrations in survivability mode.
This means that independent of the registration timeout value given in the
UA, the SIP proxy will only OK them with the timeout given here in surviv-
ability mode. This is to expedite the reregistration with the SIP server once
the connectivity is restored.
Example: ser rereg=720
Name: ser transmit

Description: This determines the SIP transmit type to be used towards the SIP server.
RFC3261 currently defines three transmit types, udp, tcp, and tls. Most
systems currently use udp, so this will most likely be your protocol of choice.
There are reasons however for using tcp, which is also supported by a
lot of systems. If you need security, there is no other way but to use tls.
Beware however that you cannot do traces of tls encrypted signalling to
track down errors. It is therefore highly recommended to set up a system
with an unencrypted protocol and only switch to tls once everything works.
The possible values are either ”udp”, ”tcp”, or ”tls”.
Example: ser transmit=udp
Name: ser timeout

Description: Timeout value for SIP Proxy to take action itself. This parameter is im-
portant for all scenarios, although a save default is in place for e.g. the
SBC templare. For survivability, this parameter is absolutely critical, since
it defines the timeout for the Survivability function. If there is no response
provisional or final within this time period, the SIP Proxy will assume Sur-
vivability mode.
Example: ser timeout=2
2005-2008
c Comdasys AG 253
Name: ser b2buasurv

Description: This function is necessary for gateways that do not properly support SIP
forking. Checking this box will make the Convergence behave like a B2BUA
towards the voice gateway in survivability mode. This means that for each
session from and to the gateway, its own Call ID will be assigned. Towards
the SIP endpoints, the Convergence will continue to behave as a SIP Proxy.
Usually, this function will not be necessary if you have no forking. Forking is
necessary if you have multiple SIP endpoints with the same SIP username.
This will normally be the case in voice scenarios where you have multiple
SIP endpoints with the same phone number. This is commonly described
as keyset feature or multiline appearance. Incoming calls in such multiline
scenarios sometimes pose difficulties for gateways because the SIP proxy
in the Convergence will fork the request. This will lead to the fact that
multiple SIP responses are forwarded to the gateway which is a problem
for some of them. With the B2BUA feature enabled, the Convergence will
terminate this call and only forward a single response to the gateway.
This parameter applies only to the Survivability and Branch SBC templates.
Example: ser b2buasurv=on
Name: ser city code

Description: This is used to convert numbers routed to the Convergence to full E.164
numbers for doing proper ENUM lookups. Enter the plain city code (3-
digits area code in the US). It can also be a number of variable length in
many other countries.
This parameter applies only to the ENUM template.
Example: ser city code=89
Name: ser country code

Description: This parameter applies only to the ENUM template. Enter the Country
Code for your country without any preceding digits. This would be a ”1”
for the USA, the ”49” for Germany, etc. This parameter will be used to
properly convert any incoming numbers to E.164 format. You have to enter
this parameter correclty. Otherwise outbound calls will not work.
Example: ser country code=49]
Name: ser dest ip mask

Description: This applies only to the Branch SBC and Survivability Templates. This
parameter is part of the link defintion for doing CAC. CAC is done on a
per link basis. This link definition is done via the Source and Destination
IP address. The parameter here is the netmask for the destination IP. It
will usually be the PBX IP address for which you do CAC. In that case, the
netmask will only point to a single host instead of a network.
Example: ser dest ip mask=255.255.255.255
2005-2008
c Comdasys AG 254
Name: ser distance prefix

Description: Enter the number you have to dial on your phone before making a long
distance call. In the US this is a ”1”, in most European countries a ”0”. Do
not confuse this with the prefix you have to dial on your phone to get an
outside line on the PBX. This value is needed to correctly convert incoming
and outgoing numbers into E.164 format. Assume for example that you
want to call somebody with the area code 221. In order to do that, you
have to dial a number in front of that, e.g. 0221 xxxx. In that case enter the
0 for the the parameter here.
This parameter applies only to the ENUM template.
Example: ser distance prefix=0
Name: ser external ip

Description: All Convergence products support multiple virtual and non virtual inter-
faces. When acting as a session border controller, there however must
be a unique uplink interface through which outgoing media streams should
be routed. When looking at the SIP messages that are leaving the LAN
network of the SBC towards the outside of the SBC, all SDP bodies will
contain this external IP address. Thus, all endpoints having a connection
with some endpoint inside the SBC will be sending their media streams to
this external IP address. The external IP address however has a different
meaning in the different templates. In a branch session border controller
scenario it denominates the side towards the PBX, in most cases the WAN
interface or a VPN connection. In the central SBC scenario, the external
IP address will point to the endpoints that can register from behind NAT
firewalls.
This parameter only applies to the various SBC templates.
Example: ser external ip=10.10.10.10
Name: ser fix looseroute

Description: This only applies to the Survivability and Branch SBC templates. Loose
routing is defined in RFC3261 and will make the Convergence route all
in dialog messages the same way that the dialog setup was routed. This
however assumes properly behaving SIP endpoints and a properly behav-
ing SIP servers. In simple scenarios, where the endpoints are registered
to a server, this works for most endpoints. With a survivability scenario,
where the messages are routed onwards, and where the proxy is on the
return route in addition to that, the correct behavior of loose routing is not
guaranteed with all devices. In order to avoid that, loose routing can be
disabled in normal operation (non survivability). If you see in dialog mes-
sages like ACK and BYEs not flowing as expected. A typical sign is ACKs
or BYEs coming from the softswitch being directly returned to it.
Example: ser fix looseroute=on
2005-2008
c Comdasys AG 255
Name: ser fromhost

Description: Please refer ot the ser usesipping parameter for more informaiton on that.
When using the SIP OPTIONS messages to check whether a server is still
available, you can configure the URI hsot part the Convergence should be
sending. Simply specifiy the host part of the URI with this parameter. The
switch must repsond to the URI with a non 5xx and 6xx response. You can
also refer to the ser userpart for setting the user part of the URI.
This only applies to the Survivability and Branch SBC templates.
Example: ser fromhost=sipserver.foo.bar
Name: ser gateway access

Description: The access code is a way of forcing calls onto a certain gateway in Sur-
vivability mode. This only applies to Survivability mode! Under normal op-
eration, it is assumed that the PBX is responsible for directing the calls to
the appropriate gateway. Any call received in Survivability mode that starts
with an appropiate prefix will be forwarded to the best matching gateway.
If you put a 0 there for example, any number starting with a 0 would be
sent to this gateway. The check is made sequentially, not in a best match
manner! This means the gateway with the first access code match will be
selected. If there is no match, the first gateway will be selected. If hunting
is enabled and the gateway with the access code match is busy, the call will
be forwarded to the next gateway in the list.
This only applies to the Branch SBC and Survivability templates.
Example: ser gateway access=*9
Name: ser gateway action

Description: The Redirect action will make the Call Overflow to the next possible gate-
way. If there is none, the Redirect will behave the same as a Deny. The
Deny action will abort the call with a ”606 Not Acceptable” response. The
CAC has to be activated for this parameter to have an effect.
This only applies to the Survivability template.
Example: ser gateway action=deny
Name: ser gateway cac

Description: It is possible to perform Call Admission Control in Survivability mode be-
fore the Call is being forwarded to a gateway. This is necessary since it
cannot be assumed that the gateway is always connected to the LAN. It
could be located off site. This could mean that in a backup case, it can
only be reached via some backup link. There are many scenarios that are
conceivable. The Call Admission Control parameters will allow limiting the
number of calls going to the gateway. For more information on Call Admis-
sion Control refer to the more detailed explanation in the general section.
Example: ser gateway cac=on
2005-2008
c Comdasys AG 256
Name: ser gateway dest ip

Description: This parameter applies only for CAC scenarios towards the gateway. In
order to configure Call Admission control, we first need to define a link. The
link definition here is done by entering the source and destination IP ranges.
After defining the link, you can configure a policy, since a reaction in case of
an overload must be configured. Here you can define the source IP address
for which the CAC rule towards the gateway would apply. Usually this will
be the IP range of your SIP phones. Also refer to the ser gateway cac
parameter for more information.
Example: ser gateway dest ip=10.10.10.10
Name: ser gateway limitclass

Description: In order to define a CAC action, you will need to associate a limit class with
your CAC link. Also refer to the ser cac and ser gateway cac sections
for more information on this.
Example: ser gateway limitclass=eth0-1:3]
Name: ser gateway src ip

Description: This parameter applies only for CAC scenarios towards the gateway. In
order to configure Call Admission control, we first need to define a link.
The link definition here is done by entering the source and destination IP
ranges. After defining the link, you can configure a policy, since a reac-
tion in case of an overload must be configured. Here you can define the
destination IP address for which the CAC rule towards the gateway would
apply. Usually this will be the IP address of the gateway. Also refer to the
ser gateway cac parameter for more information.
Example: ser gateway src ip=10.23.34.10
2005-2008
c Comdasys AG 257
Name: ser gwdnsalias

Description: This parameter only has an effect if ser gwdnsaliascheck is set. In Branch
SBC mode, the Convergence can act as a virtual gateway for the PBX. If
a media gateway is placed inside the branch SBC, there is no way for the
PBX to directly address the media gateway on the internal private network
of the branch SBC. In those cases, the PBX can send the messages di-
rectly to the branch SBC IP address. The branch SBC will always change
the contact header of any message or response coming from the gateway
to the external IP address of itself. Therefore, the PBX will also send all
subsequent requests through the SBC. That way, the media gateway is
completely hidden from the PBX. It could be the case however, that the
gateway is provisioned via a DNS name in the PBX. In that case, you will
also want to have the DNS name in the contact header of any SIP message
coming from the gateway. You can set this DNS name here.
This only applies to the Branch SBC template.
Example: ser gwdnsalias=gw.foo.bar
Name: ser gwdnsaliascheck

Description: This item will activate the setting of the ser gwdnsalias parameter. Please
see the ser gwdnsaliascheck key for more information.
This only applies to the Branch SBC template.
Example: ser gwdnsaliascheck=on
Name: ser ignoreprefix

Description: All prefixes specified here will be ignored for any CAC decision. This means
that if you specify a prefix of xx here, the CAC checks will be based on the
dialed number with the specified prefix being removed first. This feature will
only be used in telephony scenarios where special prefixes can be dialed
to e.g. enable the transmission of the Caller ID. Function like these are
often used by prefixing an access code to the actual number you want to
dial. This prefix must of course not change the CAC assessment of where
the call is going. This only applies to the Survivability and Branch SBC
operation modes.
Example: ser ignoreprefix=on
2005-2008
c Comdasys AG 258
Name: ser internal ip

Description: Whenever it is operating as an SBC, the Convergence is basically forming
the bridge between two different networks. All Convergence products how-
ever support multiple virtual and non virtual interfaces. When acting as a
session border controller, there must be a unique interface through which
local endpoints communicate should be routed. When looking at the SIP
messages that are coming from the outside network, all SDP bodies will be
rewritten with this internal IP address. Hence, all endpoints having a con-
nection with some endpoint outside the SBC will be sending their media
streams to this internal IP address. At least one interface of the Conver-
gence must have this internal IP address assigned. For more information
on this topic also refer to ser external ip. This only applies to the dif-
ferent SBC templates.
Example: ser internal ip=192.168.1.1
Name: ser internal mask

Description: Please also refer to ser internal ip for more information on this topic.
This parameter defines the internal network that is associated with the
SBC. This can actually be a superset of the netmask associated with the
actual interface of the Convergenceİt defines what IP addresses are to be
treated as being SBC internal. All other IP addresses will be treated to be
external ones no matter from which interface of the SBC they are This only
applies to the different SBC templates.
Example: ser internal mask=255.255.255.0
Name: ser international prefix

Description: Enter the number you have to dial on your phone before making an interna-
tional call. In the US this is the ”011” in most European countries the ”00”.
This parameter will be used to properly convert dialed numbers to E.164
format.
This only applies to the ENUM mode of operation.
Example: ser international prefix=00
Name: ser local gw

Description: You need to configure whether media handling should be done for calls
to and from gateway calls. If turned on, the gateway will be assumed to
be local, and media handling will be disabled for all calls between local
endpoints and the local gateway. If not checked, the gateway is assumed
to be external, e.g. located at the central softswitch. This will enable media
handling for all external calls.
This parameter only applies to the Branch SBC operational mode.
Example: ser local gw=on
2005-2008
c Comdasys AG 259
Name: ser looseroute

Description: Loose routing is defined in RFC3261 and will make the Convergence route
all in dialog messages the same way that the dialog setup was routed. This
however assumes properly behaving SIP endpoints and a properly behav-
ing SIP servers. In simple scenarios, where the endpoints are registered
to a server, this works for most endpoints. With a survivability scenario,
where the messages are routed onwards, and where the proxy is on the
return route in addition to that, the correct behavior of loose routing is not
guaranteed with all devices. In order to avoid that, loose routing can be
disabled in normal operation (non survivability). If you see in dialog mes-
sages like ACK and BYEs not flowing as expected. A typical sign is ACKs
or BYEs coming from the softswitch being directly returned to it.
Setting this value to on will turn on this feature. In order to have standard
loose routing, simply leave this blank.
This only applies to the Survivability and Branch SBC operational modes.
Example: ser looseroute=on
Name: ser pbx port

Description: With this parameter, you can configure to which port the Convergence will
be sending the SIP requests towards the PBX. If this is not defined, the
standard ports for the selected transmit types will be chosen. This is port
5060 for UDP and TCP and port 5061 for SIP TLS.
Example: ser pbx port=5060
Name: ser pbxnode

Description: Some IP PBXs / Softswitches support clustering or redundancy through a
second host. There are two ways of implementing this clustering, either
transparent, in which case we do not have to handle anything exlicitly in
the branch office, or with two IP addresses. This field is meant for the latter
concept which is frequently being used if the 2 nodes of a cluster have been
spatially separated. In that case they are available through different WAN
links thus increasing the robustness of the overall solution. If such redun-
dany precautions have been taken in the data center, the branch equipment
must also support this. If this field is set, the Survivability function of the
Convergence will only take over if both the PBX as well as the 2. Node
have failed. If only the first node has failed, messages will automatically be
forwarded to the second node.
This parameter only applies to the Survivability and Branch SBC modes of
operation.
Example: ser pbxnode=62.222.111.5
2005-2008
c Comdasys AG 260
Name: ser pickup

Description: All prefixes specified here will not be considered at all for a CAC deci-
sion. Regular expressions can be specified here. This can be used for
excluding certain number ranges because you know that there will always
be enough bandwidth, or because you maybe want to exclude emergency
calls. Excluded calls can cause an overload on a link if you are not careful
in configuring your bandwidth rules.
In Voice scenarios with a central IP PBX as SIP server, there is a commonly
offered feature named Pickup group. This permits using any telephone and
dial a certain special extension like for example ”*9” in order to pick up
the call of another ringing telephone inside this branch office. In such a
case, the Convergence must be told that the ”*9” is not a regular number
but rather the special extension for that. No Admission Control will be per-
formed on the extensions entered here. Note that you can enter a regular
expression here and the above described functionality will apply to all ex-
tensions matching this expression. This also means that characters having
a predefined meaning in a regular expression must be escaped to match
the real character. Escaping can be done by adding a backslash before
the character in question. In order to match the ”*9” used in the example
above, you hence have to enter a ”\*9” into the field.
Caution:
This is a dangerous function since it can break CAC althogether, especially
when using regular expressions. Be very careful that the expression spec-
ified here only matches the actual calls that you want to have filtered and
no more.
Example: ser pickup=9
Name: ser presence

Description: This is a very rarely needed parameter. You only need to consider it, if your
presence server is to directly communicate with the SBC without interaction
of your PBX. It is being used for doing proper internal classification of mes-
sages and separating out all presence requests. If you are unsure about
this, simply leave it blank which should work okay for almost all scenarios.
In that case, the presence messages would be sent to your SIP server that
should in turn forward them correctly.
This applies only to the SBC mode of operation.
Example: ser presence=10.11.12.13
Name: ser pstn gw

Description: This parameter specifies the IP address of the used SIP gateway. It usually
does not have to be specified, but the Convergence can optimize some
media streams if it e.g. knows the IP address of the VoiceMail and the
Media gateway. This applies to the SBC mode of operation only.
Example: ser pstn gw=10.10.10.5
2005-2008
c Comdasys AG 261
Name: ser retrans final

Description: his parameter specifies the time after which the Convergence will do the
final retransmission of a message to the trunking side if no response (pro-
visional or final) was received in this period. The time is specified in mil-
liseconds.
This only applies to the SIP Trunking template.
Example: ser retrans final=8000
Name: ser retrans1

Description: This parameter specifies the time after which the Convergence will do the
first retransmission of a message to the trunking side if no response (provi-
sional or final) was received in this period. The time is specified in millisec-
onds.
Example: ser retrans1=2000
Name: ser retrans2

second retransmission of a message to the trunking side if no response
(provisional or final) was received in this period. The time is specified in
milliseconds.
Name: ser retrans3

third (and usually final retransmission) of a message to the trunking side if
no response (provisional or final) was received in this period. The time is
specified in milliseconds.
Name: ser rtp proxy tos

Description: You can define the TOS bit that will be set for all outgoing media streams.
Note that this parameter only applies to the SBC templates and to those
calls where the SBC component is doing actual media handling. If you
want to do TOS tagging beyond this, please refer to the firewall section.
Example: ser rtp proxy tos=0x184
2005-2008
c Comdasys AG 262
Name: ser sipport

Description: This defines the port where the Proxy / SBC component will be listening
for incoming SIP requests. If left blank, the default 5060 port will be used.
Note that setting this port only applies to the UDP and TCP variants. Refer
to the ser tlsport for setting the TLS port.
Example: ser sipport=5064
Name: ser src ip mask

Description: This parameter is used for CAC settings only, so you should also refer
to the ser cac section for more information. This parameter defines the
netmask for the ser src ip parameter. This parameter applies only to the
Survivability and Branch SBC operational modes.
Example: ser src ip mask=255.255.255.0
Name: ser srtp

Description: Whenever turned on, the Convergence will start terminating SRTP calls
that are coming from clients and passing to the internal network of the SBC.
The Convergence will then rewrite all SDP bodies of incoming messages.
There, SAVP offerings will be replaced with AVP offerings. Once the call is
established, the media stream will be decrypted. To the SIP endpoint side,
the media stream will be encrypted if SAVP was offered by the client. This
parameter only applies to the SBC mode of operation.
Example: ser srtp=on
Name: ser surv

Description: In the Branch SBC mode of operation, Survivability functionality must be
separately enabled. Set this value to on to activate survivability. In this
case, the Convergence will behave exactly the same way as in Survivability
mode, but it will do the media handling in addition to that.
This parameter only applies to the Branch SBC mode of operation.
Example: ser surv=on
2005-2008
c Comdasys AG 263
Name: ser tlsmethod

Description: Sets the TLS protocol method which can be:
• TLSv1 - means the Convergence will accept only TLSv1 connections
(rfc3261 conformant).
• SSLv3 - means Convergence will accept only SSLv3 connections
• SSLv2 - means Convergence will accept only SSLv2 connections (al-
most all old clients support this).
• SSLv23 - means Convergence will accept any of the above methods,
but the initial SSL hello must be v2 (in the initial hello all the supported
protocols are advertised enabling switching to a higher and more se-
cure version). The initial v2 hello means it will not accept connections
from SSLv3 or TLSv1 only clients.
If you want RFC3261 conformance and all your clients support TLSv1 (or
you are planning to use encrypted tunnels only between different Conver-
gence proxies) use TLSv1. If you want to support older clients use SSLv23
(in fact most of the applications with SSL support use the SSLv23 method).
This applies to the central SBC mode of operation.
Example: ser tlsmethod=[VALUE]
Name: ser tlsport

Description: This defines the port where the Proxy / SBC component will be listening for
incoming SIP TLS requests. If left blank, the default 5061 port will be used.
Note that setting this port only applies to the TLS SIP variant. Refer to the
ser sipport for setting TCP and UDP ports.
Example: ser tlsport=5071
Name: ser tos

Description: The TOS (Type Of Service) to be used for the sent SIP packages. The
values apply to both UDP and TCP packages.
Example: ser tos=0x180
Name: ser trunk dnssrv

Description: If this parameter is set activated, any hostname entered in
ser trunk host will be interpreted as a DNC SRV name. Thus a
DNS SRV lookup will be performed at first. The message will be forwarded
to the server with the highest priority. If multiple servers have the same
priority, the messages will be distributed acording to the weight assigned
to the DNS SRV host. If the first host fails, the backup host is contacted.
This parameter only applies to the SIP Truning mode of operation.
Example: ser trunk dnssrv=on
2005-2008
c Comdasys AG 264
Name: ser trunk port

Description: This parameter sets the port to which outgoing SIP messages are ad-
dressed on the Trunking provider side. Note that this parameter only needs
to be set if DNS SRV is not being used. With DNS SRV enabled, the target
host port will be queried from the DNS server. If left blank, the default of
5060 for UDP and TCP and 5061 for TLS respectively will be used.
This parameter only applies to the SIP Truning mode of operation.
Example: ser trunk port=5060
Name: ser trunk srvpenalty

Description: This specifies the time period for the penalty box. If a host obtained via a
DNS SRV lookup is not reachable for a certain amount of time, it will be
placed into the penalty box. This means that no further attempts will be
placed to that server for the specified time. Only after that time, another re-
quest is tried to that server. This parameter only applies to the SIP Truning
mode of operation.
Example: ser trunk srvpenalty=30
Name: ser trunk transmit

Description: The SIP Transmit Type parameter is the transmission type the Convergence
uses to contact the central local PBX. The Convergence supports 3 differ-
ent SIP transport modes, UDP, TCP, and the encrypted TLS variant. The
type to use depends first and foremost on the used IP PBX. The TCP and
UDP types are straightforward and just specify the used protocol type.
The only type requiring further explanation is TLS. For TLS additional things
like the encryption keys are required. Since this is a very advanced topic,
this cannot be configured via the WebGUI as of yet. The Convergence will
generate TLS keys automatically that can be downloaded for the use in
Servers/Phones via SCP. Please consult the Command Line Reference for
more information on how to do that.
This parameter applies only to the SIP Trunking template.
Example: ser trunk transmit=udp
Name: ser userpart

Description: Please refer ot the ser usesipping parameter for more informaiton on that.
When using the SIP OPTIONS messages to check whether a server is still
available, you can configure the URI user part the Convergence should be
sending. Simply specifiy the user part of the URI with this parameter. The
switch must repsond to the URI with a non 5xx and 6xx response. You can
also refer to the ser fromhost for setting the host part of the URI.
Example: ser userpart=user
2005-2008
c Comdasys AG 265
Name: ser usesipping

Description: There are two ways the Convergence supports to check whether the SIP
Server for which we are providing the survivability functionality is monitored.
This monitoring can be applied at the network layer (via ICMP messages) or
on the application layer with SIP OPTION requests. The check with pings
should work with all servers as long as the underlying network supports
this. This is usually the case except firewalls on the way, or a packet filter
on the server itself prevents the Ping Echo Reply messages from getting
back to the ConvergenceȮther than that, the pings will be sent in intervals
of around a minute. This interval can be shorter depending on the amount
of SIP messages flowing through the ConvergenceṪhe interval can also
vary if there are abnormal negative responses to requests forwarded to the
server. The non-response to a single ICMP message will not lead to the
Convergence switching into survivability mode.
Whenever the SIP server supports SIP OPTIONS (please refer to RFC
3261 for more information on this SIP request type) requests, this should
be used for doing the alive check. It will also enable the Convergence to
switch into survivability mode for situations in which the central SIP server
is reachable, but not responding correctly. Whenever we receive 5xx or 6xx
responses from the central server for an OPTIONS request, the Conver-
gence switches to survivability mode. If no response is received, a single
non-response will not lead to the Convergence switching to survivability
mode.
Example: ser usesipping=on
Name: ser voicemail

Description: This is a very rarely needed parameter. You only need to consider it, if your
voicemail system is to directly communicate with the SBC without interac-
tion of your PBX. It is being used for doing proper internal classification of
messages. If you are unsure about this, simply leave it blank which should
work okay for almost all scenarios.
This applies only to the SBC mode of operation.
Example: ser voicemail=10.10.10.10
2005-2008
c Comdasys AG 266
Name: ser multiport

Description: This activates multiport mapping towards the SIP server. If activated the
Convergence will always change the contact header of SIP requests that
are being forwarded to the SIP server. As such, the SIP server will think that
the SBC is the actual endpoint. The same holds true in the other direction
where all headers are modified that the endpoint returns the messages to
the SBC. Since now all endpoints connected behind the SBC would seem
to come from the same IP and port combination, namely the SBC. In order
to avoid confusion especially with multiple registrations of different phones,
each registered phone will be mapped to a unique port. Any message
arriving from the PBX on that port will hence be forwarded to the correct
phone. The phones will continue to send to the configured SIP port, so the
port mapping only applies to the direction towards the SIP server.
This applies only to the SBC, Branch SBC and Cascaded SBC modes of
operation.
Example: ser multiport=on
Name: ser topohide

Description: An SBC typically separates an untrusted and a trusted network. Usually,
SBC are made to protect a datacenter from Internet users. Branch SBC
are slightly different since the users are not really Internet users, but well
known branch users. Nevertheless, the SBC should protect the hosts in the
datacenter by isolating them from the users. One of the measures taken
here to make attacks more difficult is so called topology hiding. What is
done there is that all IP addresses of the datacenter appearing in the SIP
message as for example To: and From: headers are rewritten with the
external IP address of the SBC thus concealing the network architecture
of the data center. By just using this option, the normal RFC compliant
mechanics of routing SIP messages are not affected. This means however
that some headers as for example VIA cannot be modified. This applies
only to the SBC, Branch SBC and Cascaded SBC modes of operation.
Example: ser topohide=on
2005-2008
c Comdasys AG 267
Name: ser topohide vias

Description: Refer also to the ser topohide parameter. In addition to the general
header fields, the header fields concerning the message routing such as
VIA and Record Route headers will be modified. In a simple configuration,
with a server, an SBC and a client, this configuration does not pose a prob-
lem. The SBC will remove the VIA headers in both directions meaning that
any routings behind or before the SBC will not work properly if they rely on
the presence of VIA or record route headers. This could for example im-
pact the use of SIP proxies outside the SBC since the SBC will always send
outbound messages to the registered user. This feature is hence a security
feature that hides all headers, but endangers proper RFC3261 message
routing. If you want to preserve proper RFC3261 compliant message rout-
ing, you should not activate this feature. This applies only to the SBC mode
of operation.
Example: ser topohide vias=on
5.7.3 Settings for Dualmode Enterprise operation
Contrary to earlier versions, the FMC settings are now stored in a database. Therefore, it is
not possible to perform any CLI configurations here. You can however access the database
directly.
For more information about this refer to ??.
2005-2008
c Comdasys AG 268
6 Documentation for packaged products
This chapter contains documentation from third-party products that are used by Convergence
products. The documentations are included for completeness reasons. Please note that these
documents are copyrighted by their respective owners and are not the property of Comdasys
AG.
6.1 Traffic Control / Quality of Service
The Convergence Series porducts feature sophisticated traffic control and bandwidth man-
agement support. Since traffic control is an immensely complex topic, you should refer to
http://lartc.org/howto/ to get a more detailed introduction as to how Linux handles
this. Here we will only describe where to find the respective configuration files. There are
two ways for configuring traffic control in the Convergence Series. The Convergence series
has a config file where the kind of configuration can be selected. It can be found under
/etc/sysconfig/trafficshaping. If configuration via the shaper script is selected, all
of the features of Linux traffic control can be utilized. The downside is a very complex configu-
ration process, which must be done in /usr/sbin/shaper.sh. A very simple but frequently
used configuration can be found there which can be adapted to your liking.
The preferred way of configuring traffic control in the convergence series is via htb.init. HTB
stands for Hierarchical Token n Bucket which can be configured to work in conjunction with
SFQ (Stochastic Fairness Queuing) and Priority Queuing. An example configuration is avail-
able from the Comdasys Website which documents the way this is configured. Online help for
this topic is available on the box itself by displaying the README file in the htb directory.
6.2 DNS Server (ISC BIND9)
Most Convergence products have the ISC BIND9 installed. As the BIND9 configuration file
reference is longer than this document we do not include it here. For in-depth documentation
please consult the BIND9 Administrator’s Reference Manual, located at:
http://www.nominum.com/content/documents/bind9arm.pdf
2005-2008
c Comdasys AG 269
6.3 SIP Proxy / Registrar
The Convergence Series uses the OpenSER (derived from SER from IPTel.org) as Proxy /
Registrar. Details can be found at http://www.openser.org/, including links to further
documentation. Note that the documenation included here is only a small excerpt of the
lower level functionalities of OpenSER. There is also a lot of documentation available on the
Internet.
i Own additions however have been made both to the documentation as well as to the
software. Most commands used in the WebGUI generated openser.cfg file are actually not
part of the standard OpenSER.
6.3.1 Control script serctl
There is a script openserctl to control the SIP Proxy server process. It can be used to man-
age users, access control lists, in memory contacts, and to monitor server health. Executing
serctl with no arguments will produce this output:
# openserctl
/usr/sbin/openserctl 1.1 - $Revision: 1.6.2.2 $
parameter usage:
* subscribers *
add <username> <password> <email> .. add a new subscriber (*)
passwd <username> <passwd> ......... change user’s password (*)
rm <username> ...................... delete a user (*)
mail <username> .................... send an email to a user
alias show [<alias>] ............... show aliases

alias rm <alias> ................... remove an alias
alias add <alias> <uri> ............ add an aliases
rpid add <username> <rpid> ......... add rpid for a user (*)
rpid rm <username> ................. set rpid to NULL for a user (*)
rpid show <username> ............... show rpid of a user
alias_db show <alias> .............. show alias details

alias_db list <sip-id> ............. list aliases for uri
alias_db add <alias> <sip-id> ...... add an alias (*)
alias_db rm <alias> ................ remove an alias (*)
alias_db help ...................... help message
speeddial show <speeddial-id> ....... show speeddial details
2005-2008
c Comdasys AG 270
speeddial list <sip-id> ............. list speeddial for uri

speeddial add <sip-id> <sd-id> <new-uri> [<desc>] ... add a speedial (*)
speeddial rm <sip-id> <sd-id> ....... remove a speeddial (*)
speeddial help ...................... help message
avp list [-T table] [-u <sip-id|uuid>]

[-a attribute] [-v value] [-t type] ... list AVPs
avp add [-T table] <sip-id|uuid>
<attribute> <type> <value> ............ add AVP (*)
avp rm [-T table] [-u <sip-id|uuid>]
[-a attribute] [-v value] [-t type] ... remove AVP (*)
avp help .................................. help message
* access control lists *

acl show [<username>] .............. show user membership
acl grant <username> <group> ....... grant user membership (*)
acl revoke <username> [<group>] .... grant user membership(s) (*)
* usrloc *
ul show [<username>]................ show in-RAM online users
ul rm <username> [<contact URI>].... delete user’s UsrLoc entries
ul add <username> <uri> ............ introduce a permanent UrLoc entry
showdb [<username>] ................ show online users flushed in DB
* pa *
pa pres <p_uri> <pstate>............ set pstate for a presentity
pa loc <p_uri> <loc>................ set location for a presentity
* domains *
domain show ........................ show list of served domains
domain add <domainname> ............ add a new served domain
domain rm <domainname> ............. remove a served domain
* lcr *
* IP addresses must be entered in dotted quad format e.g. 1.2.3.4 *
* <uri_scheme> and <transport> must be entered in integer or text,*
* e.g. transport ’2’ is identical to transport ’tcp’. *
* scheme: 1=sip, 2=sips; transport: 1=udp, 2=tcp, 3=tls *
* Examples: openserctl lcr addgw_grp usa 1 *
* openserctl lcr addgw level3 1.2.3.4 5080 sip tcp 1 *
* openserctl lcr addroute +1 % 1 1 *
lcr show ...................................... show routes, gateways and group
lcr reload .................................... reload lcr gateways
lcr addgw_grp <grp_name> ...................... add gateway group, autocreate g
lcr addgw_grp <grp_name> <grp_id> ............. add gateway group with grp_id
2005-2008
c Comdasys AG 271
lcr rmgw_grp <grp_id> ........................ delete the gw_grp

lcr addgw <gw_name> <ip> <port> <scheme> <transport> <grp_id> ...........
add a gateway
lcr addgw <gw_name> <ip> <port> <scheme> <transport> <grp_id> <prefix> ..
add a gateway with p
lcr rmgw <gw_name> .....................................................
delete a gateway
lcr addroute <prefix> <from> <grp_id> <prio> .. add a route
lcr rmroute <prefix> <from> <grp_id> <prio> .. delete a route
* control and diagnostics *

moni ... show internal status start .... start openser
ps ..... show runnig processes stop ..... stop openser
fifo ... send raw FIFO commands restart .. restart openser
ping <uri> .. ping a URI (OPTIONS)
cisco_restart <uri> .. restart a Cisco phone (NOTIFY)
Commands labeled with (*) will prompt for a MySQL password.

If the variable PW is set, the password will not be prompted.
ACL privileges are: local ld int voicemail free-pstn prepaid
Adding and deleting users with serctl

User account management is performed with these commands:
serctl add
serctl password
serctl rm
The contents of the in memory cache can be managed with the ul argument. Please take
care using these commands. As for example:
serctl ul rm joe
will remove the current contact information about Joe from memory. Whereas
openserctl rm joe
will delete joe’s account.
Examining in memory cache with openserctl

The command serctl ul show will list any currently registered clients. The output will look
like this:
2005-2008
c Comdasys AG 272
===Domain list===
---Domain---
name : ’location’
size : 512
table: 0x402ee6d0
d_ll {
n : 2
first: 0x402f1a74
last : 0x402f089c
}
lock : 0
...Record(0x402f1a74)...
domain: ’location’
aor : ’test’
˜˜˜Contact(0x402f708c)˜˜˜
domain : ’location’
aor : ’test’
Contact: ’sip:test@192.168.0.100:5060’
Expires: 2501
q : 0.00
Call-ID: ’000a8a93-d4660017-4571a6cd-658ac1bf@192.168.0.100’
CSeq : 101
State : CS_SYNC
next : (nil)
prev : (nil)
˜˜˜/Contact˜˜˜˜
.../Record...
...Record(0x402f089c)...
domain: ’location’
aor : ’joe’
˜˜˜Contact(0x402f0924)˜˜˜
domain : ’location’
aor : ’joe’
Contact: ’sip:192.168.0.101:14354’
Expires: 432
q : 0.00
Call-ID: ’e8d93059-e46e-4fd9-958b-ccb36a1cf245@192.168.0.101’
CSeq : 11
State : CS_SYNC
next : (nil)
prev : (nil)
˜˜˜/Contact˜˜˜˜
.../Record...
2005-2008
c Comdasys AG 273
---/Domain---
===/Domain list===
Examining server status

Two commands can be used to check the health of the server. The first command openserctl
ps returns a list of all SER related processes, the ip address and the port they are listening
on. For example:
[root@gateway /root]# openserctl ps

0 31029 attendant
1 31033 receiver child=0 sock=0 @ 127.0.0.1::5060
9 31049 fifo server
10 31072 timer
The second command,

openserctl monitor
shows the server version, uptime, pending and completed transactions, and the number of
major category responses the server has sent. For example:
[cycle #: 1; if constant make sure server lives]

Server: OpenSer (1.1.1comdasys-tls (i386/linux))
Now: Sun May 18 18:44:32 2008
Up Since: Fri May 16 07:34:32 2008
Up time: 213000 [sec]
Transaction Statistics:
Module name = tm; statistics=11
tm:received_replies = 8465
tm:relayed_replies = 8355
tm:local_replies = 71
tm:UAS_transactions = 8317
tm:UAC_transactions = 0
tm:2xx_transactions = 4243
2005-2008
c Comdasys AG 274
tm:inuse_transactions = 2
Stateless Server Statistics:

Module name = sl; statistics=9
sl:1xx_replies = 0
sl:2xx_replies = 0
sl:3xx_replies = 0
sl:4xx_replies = 0
sl:5xx_replies = 0
sl:6xx_replies = 0
sl:sent_replies = 0
sl:sent_err_replies = 0
sl:received_ACKs = 0
UsrLoc Stats:
Module name = usrloc; statistics=6
usrloc:aliases-users = 0
usrloc:aliases-contacts = 0
usrloc:aliases-expires = 0
usrloc:location-users = 1
usrloc:location-contacts = 1
usrloc:location-expires = 16
6.3.2 TLS
TLS, as defined in SIP RFC 3261, is a mandatory feature for proxies and can be used to
secure the SIP signalling on a hop-by-hop basis (not end-to-end). It is a secure SIP transport
method (besides UDP and TCP) for user agents or other SIP servers/proxies connecting to
the Convergence. TLS works on top of TCP.
The configuration of the SIP server is written to the file /etc/ser/ser.cfg. It is dynamically
created by the web based configuration application depending on the selected scenario. The
”SBC” (Session Border Controller) scenario currently uses TLS as the only possible transport
method. For a documentation of the syntax of the configuration file and the rich sets of
features and commands of the OpenSER please refer to its documentation.
The main configuration settings regarding TLS are shown below.
The default paths for the server certificate and private key is
/etc/ser Put the server certificate in the file
/etc/ser/cert.pem
and the private key into
2005-2008
c Comdasys AG 275
/etc/ser/prik.pem
and make sure to set the file permissions to a restrictive value (”600”: -rw-------).
tls certificate="/etc/ser/cert.pem" path to server certificate
tls private key="/etc/ser/prik.pem" path to server private key
tls method=TLSv1 possible values are TLSv1, SSLv2, SSLv3,
SSLv23
disable tls=0 temporarily disables TLS when set to 1
tls verify=on requires a certificate from the connecting client
tls require certificate=on only used if tls verify=on
• tls require cert=0 - the verification pro-
cess will succeed if the client does not
provide a certificate, or if it provides one,
it verifies correctly against the server’s list
of trusted certification authorities.
• tls require cert=1 - the verification
process will only succeed if the client pro-
vides a certificate and this verifies cor-
rectly against the server’s list of trusted
CAs.
6.3.3 Regular expressions
Various options for the SER accept regular expressions. A regular expression, or regexp, is a
way of describing a class of strings. It matches every input record whose text belongs to that
class. Thus they are used in comparison expressions to match input strings.
The simplest regular expression is a sequence of letters, numbers, or both. Such a regexp
matches any string that contains that sequence. Thus, the regexp ‘foo’ matches any string
containing ‘foo’. Other kinds of regexps let you specify more complicated classes of strings.
Regular Expression Operators

You can combine regular expressions with the following characters, called regular expression
operators, or metacharacters, to increase the power and versatility of regular expressions.
Here is a table of metacharacters. All characters not listed in the table stand for themselves.
Operator Description Example
‘ˆ’ This matches the beginning of the string ‘ˆ00’ matches two zero digits at the
or the beginning of a line within the string. beginning of a string, and may be
used to identify international calls.
‘$’ This is similar to ‘ˆ’, but it matches the ‘p$’ matches a record that ends
end of a string or the end of a line within with a ‘p’.
the string.
2005-2008
c Comdasys AG 276
‘.’ This matches any single character except ‘.P’ matches any single character
a newline. followed by a ‘P’ in a string. Using
concatenation we can make reg-
ular expressions like ‘U.A’, which
matches any three-character se-
quence that begins with ‘U’ and
ends with ‘A’.
‘[...]’ This is called a character set. It matches ‘[MVX]’ matches any one of the
any one of the characters that are en- characters ‘M’, ‘V’, or ‘X’ in a string.
closed in the square brackets.
Ranges of characters are indicated by ‘[0-9]’ matches any digit.
using a hyphen between the beginning
and ending characters, and enclosing the
whole thing in brackets.
‘[ˆ...]’ This is a complemented character set. ‘[ˆ0-9]’ matches any character
The first character after the ‘[’ must be that is not a digit.
a ‘ˆ’. It matches any characters except
those in the square brackets (or newline).
‘|’ This is the alternation operator and it is ‘ˆP|[0-9]’ matches any string
used to specify alternatives. The alter- that matches either ‘ˆP’ or ‘[0-9]’.
nation applies to the largest possible reg- This means it matches any string
exps on either side. that contains a digit or starts with
‘P’.
‘(...)’ Parentheses are used for grouping in reg-
ular expressions as in arithmetic. They
can be used to concatenate regular ex-
pressions containing the alternation oper-
ator, ‘|’.
‘*’ This symbol means that the preceding ‘ph*’ applies the ‘*’ symbol to the
regular expression is to be matched zero preceding ‘p’ and looks for matches
or as many times as possible to find a to one ‘p’ followed by any number
match. of ‘h’s. This will also match just ‘p’
if no ‘h’s are present.
The ‘*’ repeats the smallest possible pre-
ceding expression. Use parentheses if
you wish to repeat a larger expression. It
finds as many repetitions as possible.
‘+’ This symbol is similar to ‘*’, but the pre- ‘wh+y’ would match ‘why’ and
ceding expression it to be matched at ‘whhy’ but not ‘wy’, whereas ‘wh*y’
least once. would match all three of these
strings.
‘?’ This symbol is similar to ‘*’, but the pre- ‘fe?d’ will match ‘fed’ and ‘fd’, but
ceding expression can be matched once nothing else.
or not at all.
2005-2008
c Comdasys AG 277
‘\’ This is used to suppress the special ‘\$’ matches the character ‘$’.
meaning of a character when matching.
In regular expressions, the ‘*’, ‘+’, and ‘?’ operators have the highest precedence, followed
by concatenation, and finally by ‘|’. As in arithmetic, parentheses can change how operators
are grouped.
Case is significant in regular expressions, both when matching ordinary characters (i.e., not
metacharacters), and inside character sets. Thus a ‘w’ in a regular expression matches only
a lower case ‘w’ and not an upper case ‘W’.
2005-2008
c Comdasys AG 278
7 Extended options and debugging
The Convergence does not only offer configuration via the Web interface but further provides
access through a CLI (Command Line Interface).
You can access this CLI in three ways:
• Using a SSH client

• Using the serial interface (COM1, 9600-N-1)
• Using the console (i.e. by connecting a VGA monitor and a PS/2 keyboard)
In every case the username is root and the password is identical to the password set in the
Web interface.
You will get a Linux prompt that can be used like any other Linux computer. A detailed descrip-
tion of the functionality accessible through the CLI is provided in the Commandline Guide.
The configuration via the CLI is primarily used for special tasks as resetting to factory defaults
and for extended debugging.
2005-2008
c Comdasys AG 279
A Sample scenarios
A.0.4 Survivability
In the Survivability scenario, the Convergence is simply used as a SIP Proxy that can take over
the functionality of a central softswitch (compare figure ?? ??). All you need to do to configure
this is use the Convergence as an outbound proxy for your local phones and gateways. The
Convergence will constantly monitor the connection to the softswitch. Once the connection
breaks, the Convergence will instanly take over.
Using the Convergence in your branch office can also help address the QoS problems typically
associated with converged networks. Maintaining voice quality is a requirement that cannot
be tackled with standard quality of service means. Too many voice calls on a WAN link
will degrade the voice quality of all connections. In order to avoid that, the Convergence can
enforce hard limits on the number of possible calls based on predefined bandwidth constraints.
This functionality is commonly referred to as Call Admission Control.
The Convergence will continuously monitor the VoIP traffic streams. If the maximum allowable
number of calls or the maximum allowable user bandwidth is reached, all additional calls flow-
ing over that WAN link would be denied. This is accomplished via standard SIP mechanisms,
so that neither special software in the data center nor special phone hardware is necessary.
The advantages of this decentralized over centralized server-based ones are numerous:
• Works with all SIP compliant servers

• Works also if NATs and Topology Hiding is used in the network
• Works for multiple SIP servers delivering different applications
• Works for a mix of Video and VoIP
A.0.5 Branch Connectivity and Branch Session Border Controller
The more generic Branch Connectivity Solution is very similar to the Standard Survivability
scenario. For an illustration, please compare to figure ?? There is one major difference in the
handling of network. In the Branch Connectivity Scenario, the Convergence has two network
connections, one internal, one external one. The SIP signalling and VoIP media handling
is translated between these two networks. As such, the device serves as a decentralized
Session Border Controller. Contrary to a far end NAT traversal solution like a central SBC, the
decentral SBC has a number of advantages especially in Enterprise scenarios.
2005-2008
c Comdasys AG 280
A Sample scenarios
Figure A.1: Survivability Scenario
2005-2008
c Comdasys AG 281
A Sample scenarios
• Clean Network Separation with Clean Routing

• Enhanced stability because there is no need for firewall pinholing for potentially thou-
sands of phones
• Increased Security and Simplification of Firewall rules due to Server-Server only Com-
munication
• Single Device Demarcation line between Headquarter and Branch Office
• Improved bandwidth utilization because branch traffic stays in branch office
• Enables the use of local PSTN gateways even behind NATs in branch offices
• Additional Functionality can be implemented in the Branch
A.0.6 Hosted Communication
The Hosted scenario is a slight variation of the Branch Connectivity Scenario. The difference
is probably the ownership of the device as well as the security policy. In Hosted Scenar-
ios, the Convergence is a customer premise termination equipment managed by the Hosted
Operator. This means that the Convergence is used to deliver a service to the customer
premises. Security and Survivability are important topics there. Figure ?? should give you an
overview.
A.0.7 Scenarios with Integrated Voice Gateways
If you have a Comdasys product with integrated Voice Gateway cards, you can support the
same scenarios as described here, with having the Voice Gateway built into the device. The
figure ?? should give an overview of how this fits together.
A.0.8 SIP Trunking
When used for SIP Trunking, the Convergence will support such functionalities as:
• Securing Network Boundaries and providing Connectivity between your PBX and the
external network
• NAT handling for both signalling and payload
• Signalling control of calls through the network, and gracefully reject calls when nec-
essary, protecting the network from Denial of Service attacks and sudden spikes in
congestion.
• Support for both Full Topology Hiding as well as SIP Proxy mode for improving interop-
erability and Feature interworking
2005-2008
c Comdasys AG 282
A Sample scenarios
Figure A.2: Hosted Scenario
Figure A.3: BiaB Scenario
2005-2008
c Comdasys AG 283
A Sample scenarios
• Advanced Security Features such as TLS and SRTP Termination for implementing se-
cure connectivity over insecure network links without having to upgrade all your equip-
ment. You can also use VPN based encryption for communication towards the SIP
Trunking provider
• DNS SRV handling for supporting redundancy configurations with your SIP Trunking
Provider
Figure ?? ?? shows a SIP trunking scenario.

The Convergence supports two different types of SIP Trunking scenarios. They can act as a
transparent Session Border Controller for PBXs that natively support SIP trunks or for Carriers
not needing a Registration with their service. The other way is acting as a true Back-to-Back
User Agent supporting Registrations, Transcoding, etc. If that is selected proprietary SIP
signalling will however not be supported. The following gives an overview of the different
modes of operation:
Figure A.4: SIP Trunking Scenario
• SBC Mode
– Full Termination of Media
– Malformed Packet Protection and Topology hiding, but supports transparent pass-
through of signalling
– DNS SRV Solution and Support for failover and load balancing solutions
• B2BUA Mode
2005-2008
c Comdasys AG 284
A Sample scenarios
– Can Actively Register

– Can handle various Individual Accounts (as common with some smaller SIP providers)
– Full Termination of both Signalling and Media
The choice which way to use will depend on wheter your carrier requires SIP registration and
whether your PBX connected to this trunk can perform the registration or not. If it can, the
transparent SBC approach is the suitable one because it can preserve the features across
the SIP Trunk. With this approach even propriertary signalling such as SIP-Q is possible.
If that is not the case, you will need to use the Back-to-Back User Agent based approach.
This can be configured in the B2BUA section.
i Products with Integrated Voice Gateway and Autoattendent functionality only support
the SIP Trunking without Registration. They cannot handle individual user accounts with
digest authentication with the SIP Provider.
A.0.9 Central SBC
The Convergence can also be used as a central Session Border Controller for Remote and
Internet users. The Convergence can provide the following functions:
• SIP NAT Handling

• RTP NAT Handling
• QoS / Traffic Shaping
• Protects Softswitch from unauthorized access
• Layer 7 packet inspection for FW pinholing
• TLS Termination
• SRTP Termination
• Topology Hiding
Figure ?? ?? should provide an overview of a typical deployment.
2005-2008
c Comdasys AG 285
A Sample scenarios
Figure A.5: Central SBC Scenario
2005-2008
c Comdasys AG 286
A Sample scenarios
A.0.10 Cascaded SBC
The Cascaded SBC Scenario has to be seen in conjunction with the Branch SBC scenario. It
is a special version of the Centralized SBC. Media streams will be achnored for all connections
from the Branch to the Headquarter, or for connections between branches. If the connection
stays behind one of the Branch SBCs however, the Cascaded SBC will not anchor these
media streams.
Figure ?? ?? provides a typical setup for this scenario.
Figure A.6: Cascaded SBC Scenario
A.0.11 FMC
The Convergence enable enterprises to fully leverage their existing network infrastructure as
well as their WLAN networks for enabling more efficient voice communication while drastically
reducing the cost of mobile communication. This can be accomplished by offering its employ-
ees a true one number solution for their fixed line and mobile phones where the Mobile phone
can either be connected via GSM or via WLAN while retaining the Enterprise PBX features.
Besides Enterprises, Service Providers can use the Convergence to enhance their offering
2005-2008
c Comdasys AG 287
A Sample scenarios
by Voice Features and can thus become Virtual Mobile Operators. This would make special
sense to pure ISPs, WISPs (Wireless Internet Service Providers) and IP Telephony Service
Providers.
The Convergence enables enterprises and service providers, to deploy converged applica-
tions that now become seamlessly usable on their mobile devices. The Convergence allow
enterprises to make full use of dual mode phones (WLAN/WiFi/GSM/UTMS/CDMA) by en-
abling them to use their own wireless infrastructure for voice calls wherever possible. Besides
using their own wireless infrastructure, the WLAN capabilities of the dual mode phones can be
utilized anywhere in the range of an accessible Hotspot. The Comdasys FMC systems enable
static as well as dynamic handovers for making sure that the appropriate transport WLAN or
GSM/UMTS/CDMA is being used. The Comdasys FMC will also make sure that the media
path is handled appropriately depending on where the dual mode phone is currently located
(e.g. NAT handling for dual mode phone behind a Hotspot) The following picture shows the
principal layout of this scenario.
2005-2008
c Comdasys AG 288
A Sample scenarios
Figure A.7: FMC Scenario
2005-2008
c Comdasys AG 289
B Support
For a more in depth information on the Configuration, you should first refer to the Command
Line Handbook. This will give you information about the possibilities of tracking down miscon-
figurations or problem through tracing etc. The Command Line reference is available from
ftp://ftp.comdasys.com/pub/documentation
For further support, Howto’s and FAQ’s visit our Website:
http://www.comdasys.com/Support/
or request support via eMail:
support@comdasys.com
2005-2008
c Comdasys AG 290

Comdasys Convergence 4675

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Comdasys Convergence 4675

Transféré par

Droits d'auteur :

Formats disponibles

Administrator and User Manual

1.1 Scope of delivery (Convergence 4600 / FMC 4800)

1. Convergence (compare figure ??) with built-in redundant power supply

Figure 1.1: Convergence 4600/FMC 4800

1.2 Scope of delivery (Convergence 3600 / FMC 3800)

1. Convergence (compare figure ??) with built-in power supply

Figure 1.2: Convergence 3600/FMC 3800

1.3 Scope of delivery (Convergence 30xx / 33xx)

Figure 1.3: Convergence 30xx and 33xx

1.4 Scope of delivery (Convergence 2600 / FMC 2800)

1. Convergence (compare figure ??) with built-in power supply

Figure 1.4: Convergence 2600/FMC 2800

1.5 Scope of delivery (Convergence 1600)

1. Convergence (compare figure ??)

Figure 1.5: Convergence 1600

1.6 Scope of delivery (Convergence 550 and 650)

1. Convergence (compare figure ??)

Figure 1.6: Convergence 650

2.1 Prepare configuration

Network protocol TCP/IP

2.2 Establish a connection to the Convergence

1. For starting configuration enter https://10.0.0.205 in your browser’s address

Figure 2.1: Select your language

2.2.1 Architcture of the WebGUI

The WebGUI of the Convergence consist of different parts. These are

• Top Menu Bar

2.2.1.1 Page Header

2.2.1.2 Top Menu Bar

2.2.1.3 Top (Main) Navigation

2.2.1.4 Main Frame

2.2.1.5 Bottom Menu Bar

2.2.3 Apply Configuration

2.2.4 GUI concepts

2.2.4.1 Default Values

2.2.4.2 Mandatory Values

2.2.4.3 Erroneous Values

2.2.5 Home Page (Status)

Applying configuration changes for selected services only

Figure 2.2: Service Status

2.2.6 Convergence 30xx and 33xx

Figure 2.3: Gateway Configuration

2.2.7 Convergence 4xxx

Security The security portion consists mostly of the firewall settings.

3.1.1 Basic settings

Figure 3.1: Basic settings

Time and date

Domain name server

3.1.2 Change password

Figure 3.2: Change the password

3.1.3 Install update

Figure 3.3: Install an update

Figure 3.4: Configuration of the Provisioning

3.1.5 Configuration backup

Figure 3.5: Configuration backup

3.1.6 Configuration restore

Figure 3.6: Configuration restore

Configuration Save now

3.1.7 Remote Backup

The Convergenceoffers functionality for providing an automated configuration backup to a

Figure 3.7: Remote Backup Configuration

3.1.8 Restart system

By clicking the button Restart , the Convergence will be rebooted.

Figure 3.8: Restarting the System

3.1.9 Port Numbers