Administrationshandbuch Mitel TA7102i
Administrationshandbuch Mitel TA7102i
Administrationshandbuch Mitel TA7102i
Disclaimer
No part of this document may be reproduced in any form without the written permission of the
copyright owner.
The contents of this document are subject to revision without notice due to continued progress in
methodology, design and manufacturing. Aastra shall have no liability for any error or damage of any
kind resulting from the use of this document.
Trademarks
Microsoft and Windows are registered trademarks of Microsoft Corporation.
Adobe and Acrobat are registered trademarks of Adobe Systems Incorporated.
All other trademarks and registered trademarks are the property of their respective owners.
Third-Party Software Copyright Information
The Dgw v2.0 Application firmware aggregates some third-party software modules (open source and
commercial) that are distributed to you in accordance with their respective licenses. Refer to the Third
Party Software Copyright Information addendum, which lists the third-party software modules along
with any copyright and license information.
P R E F A C E
Document Objectives
The Dgw v2.0 application Software Configuration Guide provides technical information on how to configure
and operate the application for your Aastra unit.
Use the Dgw v2.0 application Software Configuration Guide in conjunction with the appropriate publications
listed in “Related Documentation” on page iii.
Any reference to gateway unit 4102S does relate to terminal adapter TA7102i.
Intended Audience
Related Documentation
In addition to this manual, the Aastra unit document set includes the following:
Model-Specific Hardware Installation Guide
Describes how to install the hardware of your specific Aastra unit.
This booklet allows you to quickly setup and work with the Aastra unit.
Lists all the parameters, tables, and commands available in the Dgw v2.0 application.
Lists and describes all syslog messages and notification messages that the Dgw v2.0 application
may send.
Third Party Software Copyright Information (please contact your Aastra representative for
detailed information if needed.
This document lists the third-party software modules used in the Aastra unit along with any
copyright and license information.
Be sure to read any readme files, technical bulletins, or additional release notes for important information.
Document Structure
The Dgw v2.0 application Software Configuration Guide contains the following information.
Title Summary
“Chapter 1 - System Overview” on page 1 Provides an overview of the Dgw v2.0 application as
well as the units that support it.
“Chapter 2 - Command Line Interface (CLI)” on Describes how to access the CLI environment in order
page 11 to perform configuration tasks.
“Chapter 3 - Web Interface Configuration” on Describes how to access the embedded web server of
page 33 the Aastra unit.
System Parameters
“Chapter 4 - Services” on page 43 Describes how to view and start/stop system and
network parameters.
“Chapter 5 - Hardware Parameters” on page 49 Describes the hardware installed on your Aastra unit.
“Chapter 6 - Endpoints Configuration” on Describes how to set the administrative state of the
page 53 Aastra unit endpoints.
“Chapter 7 - Syslog Configuration” on page 57 Describes how the Aastra unit handles syslog
messages and notification messages.
Network Parameters
“Chapter 10 - IPv4 vs. IPv6” on page 71 This chapter describes the differences between IPv4
and IPv6 addressing.
“Chapter 11 - Host Parameters” on page 75 Describes how to set the host information used by the
Aastra unit, as well as the default gateway, DNS
servers and SNTP servers configuration source.
“Chapter 12 - Interface Parameters” on page 85 Describes how to set the interfaces of the Aastra unit.
“Chapter 13 - VLAN Parameters” on page 99 Describes how to create and manage dynamic VLANs.
“Chapter 14 - Local QoS (Quality of Service) Describes how to configure packets tagging sent from
Configuration” on page 101 the Aastra unit.
“Chapter 15 - Local Firewall Configuration” on Describes how to configure the local firewall feature.
page 107
“Chapter 17 - Network Firewall Configuration” on Describes how to configure the network firewall
page 121 parameters.
“Chapter 18 - NAT Configuration” on page 127 Describes the configuration parameters to define the
Aastra unit´s NAT.
Title Summary
“Chapter 19 - DHCP Server Settings” on Describes how to configure the embedded DHCP
page 135 server of the Aastra unit.
POTS Parameters
“Chapter 20 - POTS Configuration” on page 145 Describes how to configure the POTS (Plain Old
Telephony System) line service.
SIP Parameters
“Chapter 21 - SIP Gateways” on page 155 Describes how to add and remove SIP gateways.
“Chapter 22 - SIP Servers” on page 159 Describes how to configure the SIP server and SIP
user agent parameters.
“Chapter 23 - SIP Registration” on page 167 Describes how to configure the registration
parameters of the Aastra unit.
“Chapter 24 - SIP Authentication” on page 179 Describes how to configure authentication parameters
of the Aastra unit
“Chapter 25 - SIP Transport Parameters” on Describes the SIP transport parameters you can set.
page 183
“Chapter 26 - Interop Parameters” on page 189 Describes the SIP interop parameters you can set.
“Chapter 27 - Miscellaneous SIP Parameters” on Describes how to configure the SIP penalty box and
page 211 SIP transport parameters of the Aastra unit.
Media Parameters
“Chapter 28 - Voice & Fax Codecs Configuration” Describes the various voice and fax codecs
on page 231 parameters you can set.
“Chapter 29 - Security” on page 253 Describes how to properly configure the security
parameters of the Aastra unit.
“Chapter 30 - RTP Statistics Configuration” on Describes how to read and configure the RTP
page 257 statistics.
“Chapter 31 - Miscellaneous Media Parameters” Describes how to configure parameters that apply to
on page 263 all codecs.
Telephony Parameters
“Chapter 32 - DTMF Maps Configuration” on Describes how to configure and use the DTMF maps.
page 279
“Chapter 33 - Call Forward Configuration” on Describes how to set and use three types of Call
page 287 Forward.
“Chapter 34 - Telephony Services Configuration” Describes how to set the Aastra unit subscriber
on page 295 services.
“Chapter 35 - Tone Customization Parameters Describes how to override the pattern for a specific
Configuration” on page 317 tone defined for the selected country.
“Chapter 36 - Music on Hold Parameters Describes how to configure the Music on Hold (MOH)
Configuration” on page 321 parameters.
Title Summary
“Chapter 37 - Country Parameters Configuration” Describes how to set the Aastra unit with the proper
on page 325 country settings.
Management Parameters
“Chapter 40 - Creating a Configuration Script” Describes how to use the configuration scripts
on page 414 download feature to update the Aastra unit
configuration.
“Chapter 41 - Configuration Backup/Restore” on Describes how to backup and restore the Aastra unit
page 415 configuration.
“Chapter 42 - Firmware Download” on page 423 Describes how to download a firmware pack available
on the designated update files server into the Aastra
unit.
“Chapter 44 - SNMP Configuration” on page 437 Describes to configure the SNMP privacy parameters
of the Aastra unit.
“Chapter 48 - CWMP Configuration” on page 569 Describes how to set the CWMP parameters of the
Aastra unit.
“Chapter 45 - Access Control Configuration” on Describes how to set the Access Control parameters
page 443 of the Aastra unit.
“File Manager” on page 449 This chapter describes how to use the unit’s File
Manager.
“Chapter 47 - Miscellaneous” on page 451 Describes how to set various parameters used to
manage the Aastra unit.
Appendices
“Appendix A - Country-Specific Parameters” on Lists the various parameters specific to a country such
page 455 as loss plan, tones and rings, etc.
“Appendix B - Scripting Language” on page 477 Describes the Aastra proprietary scripting language. It
also lists a few configuration samples that can be
pasted or typed into the CLI or downloaded into the
Aastra unit via the Configuration Script feature.
“Appendix C - Maximum Transmission Unit Describes the MTU (Maximum Transmission Unit)
(MTU)” on page 485 requirements of the Aastra Unit.
“Appendix D - Web Interface – SNMP Variables Lists the SNMP variables corresponding to the web
Mapping” on page 487 interface of the Aastra unit
Document Conventions
The following information provides an explanation of the symbols that appear on the Aastra unit and in the
documentation for the product.
Warning Definition
Warning: Means danger. You are in a situation that could cause bodily injury. Before you work on any
equipment, you must be aware of the hazards involved with electrical circuitry and be familiar with standard
practices for preventing accidents.
Other Conventions
The following are other conventions you will encounter in this manual.
Caution: Indicates a potentially hazardous situation which, if not avoided, may result in minor or moderate
injury and/or damage to the equipment or property.
Standards Supported Indicates which RFC, Draft or other standard document is supported for a
specific feature.
Standards Supported
When available, this document lists the standards onto which features are based. These standards may be
RFCs (Request for Comments), Internet-Drafts, or other standard documents.
The Dgw v2.0 application’s implementations are based on the standards, so it’s possible that some behaviour
differs from the official standards.
For more information on and a list of RFCs and Internet-Drafts, refer to the IETF web site at http://www.ietf.org.
1 System Overview
This chapter provides an overview of the Aastra devices supported by the Dgw v2.0 application:
Introduction to the Aastra devices and the models available.
Description of the various ways to manage the Aastra unit.
How to use the DEFAULT/RESET button (partial reset and factory reset procedures).
How to configure user access to the Aastra unit.
Introduction
The Aastra unit integrates features such as TLS, SRTP, and HTTPS designed to bring enhanced security for
network management, SIP signalling and media transmission aspects.
The following describes the devices that the application supports.
TA7102i
The Aastra TA7102i is a standalone Internet telephony access device that connects to virtually any business
telephone system supporting standard analog lines.
Key Features
The following are the key features offered by the various models available.
Table 2: Aastra Units Key Features
Feature
Feature
T.38 support
Command Line Interface (CLI)
SSL/TLS Encryption
60 VRMS ringing voltage, 2 kilometres loop distance .
DSP Limitation
The Aastra unit models currently suffer from local limitation of their DSPs. When using a codec other than
G.711, enabling Secure RTP (SRTP) and/or using conferences has an impact on the Aastra unit’s overall
performance as SRTP and conferences require CPU power. This means there is a limitation on the lines that
can be used simultaneously, depending on the codecs enabled and SRTP. This could mean that a user picking
up a telephone on these models may not have a dial tone due to lack of resources in order to not affect the
quality of ongoing calls.
The DSPs offer channels as resources to the Aastra unit. The Aastra unit is limited to two conferences per
DSP. See “Conference” on page 305 for more details on Conference limitations.
Howerver, as recomendation is to use the conference service in the call server this would normally not cause
any problem. Please note that:
One FXS line requires one channel.
There is a maximum of 2 conferences per DSP
Each conference requires one additional channel
In the following tables, compressed RTP refers to codecs other than G.711. Numbers in Bold indicate a
possible under-capacity.
TA7102i
Table 3 describes the TA7102 processing capacity.
Table 3: TA7102i Offered Channels vs. Processing Capacity
Model Compr.
Phys. 3-way Conf. G.711 RTP Compr. RTP G.711 SRTP
SRTP
Channels Channels Channels Channels Channels
Channels
TA7102i 2 2 4 4 4 4
Management Choices
The Aastra unit offers various management options to configure the unit.
Web GUI The Aastra unit web interface offers the The Aastra unit web interface allows
following options: you to configure the following
• Password-protected access information:
via basic HTTP • Network attributes
authentication, as described • SIP parameters
in RFC 2617
• VoIP settings
• User-friendly GUI
• Management settings such
as configuration scripts,
restore / backup, etc.
SNMPv1/2/3 The Aastra unit SNMP feature offers the The Aastra unit SNMP feature allows
following options: you to configure all the MIB services.
• Password-protected access
• Remote management
• Simultaneous management
Refer to “Chapter 44 - SNMP
Configuration” on page 437 for more
details.
Command Line The Aastra unit uses a proprietary CLI The Aastra unit CLI feature allows you
Interface (CLI) to configure all the unit’s parameters. to configure all the MIB services.
Unit Manager The Unit Manager Network (UMN) is a The UMN offers the following:
Network PC-Windows based element • Auto-discovery
management system designed to
• Group provisioning
facilitate the deployment, configuration
and provisioning of Aastra access • SNMP access and remote
devices gateways. management.
The UMN enables the simple and
remote configuration and deployment of
numerous Aastra units.
RESET/DEFAULT Button
At Run-Time
You can use the RESET/DEFAULT button at run-time – you can press the button while the Aastra unit is
running without powering the unit off. Table 5 describes the actions you can perform in this case.
Table 5: RESET/DEFAULT Button Interaction
RESET/
DEFAULT Button Action Comments LEDs Pattern
Pressed for:
2 to 6 seconds Restarts the Aastra No changes are made to the Power LED:
unit Aastra unit settings. • blinking, 1Hz,
50% duty
All other LEDs:
• OFF
7 to 11 seconds Sets the Aastra unit Sets some of the Aastra unit All LEDs
in Partial Reset Mode configuration to pre-determined • blinking, 1Hz,
values. 50% duty
12 to 16 seconds Restarts the Aastra Deletes the persistent All LEDs
unit in Factory Reset configuration values, creates a • steady ON
new configuration file with the
default factory values, and then
restarts the unit.
17 seconds and No action is taken The RESET/DEFAULT button N/A
more pressed event is ignored.
At Start-Time
You can use the RESET/DEFAULT button at start-time – you power the unit off, and then depress the button
until the LEDs stop blinking and remain ON. This applies the “Factory Reset” procedure (see “Factory Reset”
on page 7). This feature reverts the Aastra unit back to its default factory settings.
Partial Reset
The Partial reset provides a way to contact the Aastra unit in a known and static state while keeping most of
the configuration unchanged.
Following a partial reset, the Aastra unit management interface is set to the Rescue interface. The default IPv4
address for this interface is 192.168.0.1/24 and has its corresponding link-local IPv6 available and printed on
the sticker under the Aastra unit (see “Chapter 10 - IPv4 vs. IPv6” on page 71 for more details). Any existing
network interface that conflicts with the Rescue interface address is disabled.
You can contact the Aastra unit this address to access its configuration parameters. It is not advised to access
the unit on a regular basis through the Rescue network interface. You should reconfigure the unit’s network
interfaces as soon as possible in order to access it through another interface.
In a partial reset, the following services and parameters are also affected:
AAA service: User(s) from profile are restored with their factory password.
SNMP service: Resets the enableSnmpV1, enableSnmpV2, enableSnmpV3 and snmpPort
values to their default values.
WEB service: Resets the serverPort to its default value.
CLI service: The CLI variables revert back to their default value.
NAT service: The configuration is rolled back if it was being modified. A new rule is then
automatically applied in the source and in the destination NAT tables to prevent incorrect rules
from blocking access to the unit. If those rules are not the first priority, they are raised. If there
are no rules in the tables, the new rules are not added since there are no rules to override.
LFW service: When a partial reset is triggered and the firewall is enabled, the configuration is
rolled back if it was being modified. A new rule is then automatically applied in the firewall to
allow access to the 'Rescue' interface. However, if the firewall is disabled, the configuration is
rolled back but no rule is added.
HOC service: The Management Interface reverts back to its default value.
BNI service: The Rescue interface is configured and enabled with:
• its hidden IPv4 link configuration values
• its hidden IPv4 address configuration
• an IPv6 link-local address on all network links
Hidden values are set by the unit's profile.
Just before the Rescue is configured, all IPv4 network interfaces that could possibly conflict with the
Rescue interface are disabled.
If the BNI Service is stopped when the partial reset occurs, it is started and the above configuration
is applied.
You can disable the partial reset procedure, even if users depress the Reset/Default button. The following
parameters are supported:
Table 6: Partial Reset Parameters
Parameter Description
All All the actions are allowed: reset, partial reset and factory reset.
DisablePartialReset All actions are allowed except the partial reset.
Value Meaning
100 All
200 DisablePartialReset
Factory Reset
The Factory reset reverts the Aastra unit back to its default factory settings. It deletes the persistent MIB values
of the unit, including:
The firmware pack download configuration files.
The SNMP configuration, including the SNMPv3 passwords and users.
The PPPoE configuration, including the PPP user names and passwords.
The Factory reset creates a new configuration file with the default factory values. It should be performed with
the Aastra unit connected to a network with access to a DHCP server. If the unit cannot find a DHCP server,
it sends requests indefinitely.
The following procedure requires that you have physical access to the Aastra unit. However, you can also
trigger a factory reset remotely:
via the web interface of the Aastra unit. See “Firmware Packs Configuration” on page 425 for
more details.
via the Command Line Interface of the Aastra unit by using the fpu.defaultsetting
command.
This procedure resets all variables in the MIB modules to their default value.
When the Aastra unit has finished its provisioning sequence, it is ready to be used with a DHCP-
provided IP address and MIB parameters.
This procedure can also be performed at run-time.
Note: The Factory reset alters any persistent configuration data of the Aastra unit.
User Access
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
The following describes how to configure user access to the Aastra unit. The access information is available
for the SNMP and Web interface management methods.
Note: Currently, the user name cannot be modified. To access the unit via SNMPv1, you must use the user
name as being the “community name” and there must be no password for this user name.
Policy Description
Minimum Length of User Password The minimum length the user password must have to be considered
as valid.
Upper and Lower Case Required Indicates if the user password is required to contain an upper and a
on User Password lower case characters to be considered as valid.
Here is an example of a valid password : 'Password' and examples of
invalid passwords : '1234', 'password', '1password', 1PASSWORD.
Numeral character Required on Indicates if the user password is required to contain a numeral
User Password character to be considered as valid.
Here is an example of a valid password : '1password2' and examples
of invalid passwords : 'password', 'Password'.
Policy Description
Special character Required on Indicates if the user password is required to contain a special character
User Password to be considered as valid.
Here is an example of a valid passwords : 'pass$word', 'pass_word#'
and examples of invalid passwords : 'password', 'Password', '1234',
'1Password'.
For more information on how to get a customized user profile, please refer to your Aastra representative.
Partial Reset
AAA service: User(s) from profile are restored with their factory password.
The current manual offers reference information on the features that the Aastra unit supports.
If you plan on using the web interface configuration.
If you plan on using the CLI configuration.
If you plan on using the SNMP configuration, go to “Chapter 44 - SNMP Configuration” on
page 437
“Appendix B - Scripting Language” on page 477 also offers a few configuration samples that can be pasted or
typed into the CLI or downloaded into the Aastra unit via the Configuration Script feature.
This chapter describes how to access the CLI environment in order to perform configuration tasks.
Introduction
Configuring the CLI
Accessing the CLI
• Accessing the CLI via a Telnet Session
• Accessing the CLI via a SSH Session
Working in the CLI
• Contexts
• Exiting from the CLI
• Command Completion
• Macros
• History
• Service Restart
• Configuring the Aastra unitwith the CLI
List of Commands / Keywords
Introduction
You can configure the Aastra unit parameters through a proprietary Command Line Interface (CLI)
environment. It allows you to configure the unit parameters by Aastra, Telnet or SSH.
The CLI uses the Aastra proprietary scripting language as described in “Appendix B - Scripting Language” on
page 477.
You must configure the CLI access. This can be done via the MIB variables. Once you have access to the CLI,
you can also use it to configure the access.
The configuration is loaded when it is started. It configures and starts Telnet and SSH according to the options
offered through the configuration variables. The configuration can be updated by the CLI service while running.
Partial Reset
When a partial reset is triggered, the CLI variables revert back to their default value.
Note: When performing a partial reset, the root password is removed. See “Partial Reset” on page 6 for
more details.
Connecting via Telnet requires a computer with a Telnet remote client running on a PC that acts as a Telnet
host. The Telnet host accesses the Aastra unit via its LAN or WAN network interface.
The Telnet session is opened from the PC where the client application is installed. It thus establishes a direct
connection to the unit. This could cause some problems if the client PC cannot directly access the unit because
of firewall restrictions, etc.
This window may differ if you are not using the default Windows Telnet client.
Connecting via a Secure Socket Shell (SSH) session requires a computer with a SSH or OpenSSH compatible
remote shell client running on a PC that acts as a SSH host. All communication between a client and server
is encrypted before being sent over the network, thus packet sniffers are unable to extract user names,
passwords, and other potentially sensitive data.
The command interpreter interface of the CLI is a program called by the Telnet or SSH client.
It allows you to browse the parameters of the unit. It also allows you to write the command lines and the CLI
interprets and executes it. The following figure illustrates the CLI in the global context after preforming a ls
command:
Contexts
The CLI has various contexts. A context is defined as a service name indicated by its textual key (for instance,
the Conf service). Upon entering the CLI, you are located in the Global context. This is indicated by the
following prompt:
Global>
You can change context by using the cd (change directory) command with the following syntax:
cd Service_Name
This allows you to enter into a service context. You can thus execute commands without writing the service
name. For instance:
Global>cd Conf
The prompt then changes to:
Conf>
You can use the following to get back to the global context:
Conf>cd
You can also access another service context from the Conf context:
Conf>cd Bni
Executing a command is different depending on if you are in the global context or a service context. See
“commands” on page 20 for examples.
Command Completion
The CLI command completion function works on everything in the CLI including aliases, macros, commands,
names, etc. It is case insensitive, which means that typing interface is the same as typing Interface.
However, names that are unique are case sensitive, such as interface names.
To display all possible commands or statements, enter at least one character and press the Tab key to
complete the command line. If more than one possibility exists, they are listed and you can select the one you
want.
Let’s say for instance that you type the following command in the Bni context:
Bni>Net[+ Tab key]
The CLI displays the following choices:
NetworkInterfaces NetworkInterfacesStatus
Bni>NetworkInterfaces
Macros
Macros are internal hardcoded commands that are frequently used. The CLI currently supports the following
macros:
Table 9: Macros
Macro Description
You can see the list of available macros by typing the following command from anywhere in the CLI:
Conf.Macros
This will return a table similar to the following:
_____________________________
| Name | Description |
|__________|__________________|
| Reboot | Reboot unit |
| Restart | Restart service |
|__________|__________________|
History
You can recall the history commands and navigate through the history using the up and down arrows.
Services Restart
Whenever you perform changes in the configuration, this usually means that you must restart a service for the
changes to take effect. When this is the case, the following message appears in the CLI:
Need Restart
Use the Restart macro as described in “Macros” on page 15.
Syslog Messages
You can access the notifications, diagnostic traces and SIP signalling logs of the Aastra unit. Use the logs on
command to display Syslog traces as soon as they are sent. Use the logs off command to stop displaying
the logs.
Welcome Message
You can define a message that is displayed when connecting to the CLI by typing the following:
Global>set Cli.WelcomeMessage=Value
Where Value is the actual message you want displayed. The following escape characters are supported:
\n for new line
\t for tab
\\ for the \ character.
Other characters are left unchanged.
Help
The CLI allows you to get help on the various keywords supported. You can have access to general or
contextual help.
You can access the general help by typing the help keyword:
Global>help
In that case, the CLI displays the list of all keywords available.
You can also access a more specific general help by typing the help keyword in a context.
Conf>help
In that case, the CLI displays the list of all keywords available as well as a description of the context.
You can access the contextual help by typing the help keyword followed by the keyword.
Global>help set
The following sections describe the commands and keywords and their syntax depending on the context in
which you are located. Each syntax also has an example in blue.
access
Retrieves the access type of the expression. The expression
may be a variable (scalar), a table cell, or a table column. Applies To
access Service_Name.Table_Name.Column_Name
access Hoc.DnsServersInfo.IpAddress
access Table_Name.Column_Name
access DnsServersInfo.IpAddress
alias / unalias
The alias function allows you to create a keyboard shortcut, an
abbreviation, a mean of avoiding typing a long command Applies To
sequence. You can assign an alias to services, scalars, tables,
and commands. You cannot currently assign an alias to Services Tables Columns Variables
columns.
Once an alias has been added, you can use it in place of the
entity name when typing commands. You can delete an alias
with the unalias command.
Note: When naming an alias, you cannot use an existing macro name, service name, nor MIB object name
from the same context.
You can see the list of available aliases by typing the following command from anywhere in the CLI:
Conf.Alias
This will return a table similar to the following:
_______________________________________________
| Name | Entity | Type | Context |
|__________|___________________|______|_________|
| TimeOut | InactivityTimeOut | 200 | Cli |
|__________|___________________|______|_________|
unalias aliasName
unalias IPAddress
unalias aliasName
unalias IPAddress
cd
Changes context (global or service context).
Applies To
Enter into a Context – Global Context
Services Tables Columns Variables
Use this syntax when in the global context.
cd Service_Name
cd Hoc
columnars
Retrieves the columns associated with a table.
Applies To
Table Consultation – Global Context
Services Tables Columns Variables
Use this syntax when in the global context.
columnars Service_Name.Table_Name
columnars Hoc.DnsServersInfo
commands
Retrieves the commands associated with a service or a table.
Applies To
Service Consultation – Global Context
Services Tables Columns Variables
Use this syntax when in the global context.
commands Service_Name
commands Bni
defval
Retrieves the default value of the expression. The expression
may be a variable (scalar), a table column, or a table cell). Applies To
defval Service_Name.Table_Name.Column_Name
defval Hoc.DnsServersInfo.IpAddress
defval Table_Name.Column_Name
defval DnsServersInfo.IpAddress
dump
Displays the unit’s whole configuration on screen.
dump Applies To
get
Retrieves the value of the expression. The expression may be a
variable (scalar), a table, a table row, a table column, or a table Applies To
cell). Note that entering the get command is optional.
Services Tables Columns Variables
help
Retrieves the documentation related to the expression. This
keyword is case sentitive. Applies To
You can have access to general or contextual help. You can
Services Tables Columns Variables
access the general help by typing the help keyword. You can
access the contextual help by typing the help keyword followed
by the name of the expression.
help Service_Name.Table_Name.Column_Name
help Hoc.DnsServersInfo.IpAddress
help Table_Name.Column_Name
help DnsServersInfo.IpAddress
indexes
Retrieves the indexes associated with the expression of a table.
The expression may be the table itself or one of its columns. Applies To
keys
Retrieves the keys associated with the expression of a table. The
expression may be the table itself or one of its columns. Applies To
logs off
Stops to display of Syslog traces.
logs off Applies To
logs on
Displays Syslog traces as soon as they are sent.
The traces displayed are the notifications coming from the Applies To
services, the diagnostic traces and the Signaling Logs.
Services Tables Columns Variables
logs on
ls
Retrieves the list of services available in a global context and the
objects of the service on a service context. Applies To
name
Retrieves the name of the expression. This keyword is case
sensitive. You must type the exact name after the name key. Applies To
name Service_Name.Table_Name.Column_Name
name Hoc.DnsServersInfo.IpAddress
name Table_Name.Column_Name
name DnsServersInfo.IpAddress
objects
Retrieves the objects associated with the expression of a
service. Applies To
PCapture
Starts a network capture. Typing ctrl+c stops immediately a running capture command and displays statistics.
Supported parameters can be found by typing "help pcapture".
The Telnet and SSH ports are automatically filtered out. The host addresses are not converted to names to
avoid DNS lookups. The protocol and port numbers are not converted to names either.
Use this syntax.
pcapture [options] [expression]
pcapture -raw -c 50 port 161
Options:
-c 'count': Exit after receiving 'count' packets.
-raw: Raw packets are output (unreadable output, must be redirected to file or Wireshark)
-D: Print the list of network interfaces available on the system and on which pcapture can
capture packets.
-e: Print the link-level header on each dump line.
-i 'if': Listen on interface 'if'. Can be any of the interfaces returned by option -D or can be set to
'any'. 'any' will listen on all interfaces but not in promiscuous mode.
-p: Don't put the interface into promiscuous mode.
-S: Print absolute, rather than relative, TCP sequence numbers.
-T 'expression': Force packets selected by 'expression' to be interpreted of the specified type.
Supported types are rtp, rtcp, snmp, tftp.
Expression:
Selects which packets will be dumped. If no expression is given, all packets on the net will
be dumped. Otherwise, only packets for which expression is 'true' will be dumped. For the
expression syntax, see pcap-filter(7).
It is possible to route the capture to Wireshark to have a remote live capture. From the remote PC (Windows
or Linux), type the following command:
plink.exe -pw "" [email protected] "pcapture -raw port 161" | wireshark -k -i -
This example connects by using plink (from putty) in SSH to the unit 10.4.127.128 by using the username
"public" and an empty password. It would capture the SNMP packets.
For more information in the pcapture command, please refer to the following page: http://www.tcpdump.org/
pcap3_man.html.
ping (IPv4)
Executes a ping command using IPv4 with the arguments and the target host provided by the user.
Use this syntax when using the ping command:
ping [-c COUNT -s SIZE -q] host_name
ping -c 3 -s 300 -q 192.168.0.25
ping (IPv6)
Executes a ping command using IPv6 with the arguments and the target host provided by the user.
Use this syntax when using the ping command:
ping [-c COUNT -s SIZE -q] host_name
ping -c 3 -s 300 -q 192.168.0.25
The supported ping arguments are:
-c COUNT: Stops the ping after it has sent COUNT packets.
-s SIZE: Sends SIZE data bytes in packets (default = 56).
-q: Shows information only at the start and when finished.
Typing Ctrl+c immediately stops a running ping command and displays statistics.
scalars
Retrieves the scalars associated with the expression of a
service. Applies To
set
Assigns a constant value to the expression. The expression may
be a variable (scalar) or a table cell. Applies To
Use this syntax when in the global context. The Index parameter is the first column of the table.
Service_Name.Table_Name[Index=key].Column_Name=Value
Hoc.DnsServersInfo[Priority=2].IpAddress=”192.168.0.10”
set Service_Name.Table_Name[Index=key].Column_Name=Value
set Hoc.DnsServersInfo[Priority=2].IpAddress=”192.168.0.10”
show
Retrieves the value of the expression.
Applies To
Variable Consultation – Global Context
Services Tables Columns Variables
Use this syntax when in the global context.
show Service_Name.Scalar_Name
show Cli.InactivityTimeOut
sysinfo
Displays the current unit status. The information displayed is:
System Description
Serial Number
Firmware Version
Host Name
Mac Address
System Uptime
System Time
Snmp Port
Installed Hardware Information (Name, description, location).
tables
Retrieves the tables associated with the a service.
Applies To
Service Consultation – Global Context
Services Tables Columns Variables
Use this syntax when in the global context.
tables Service_Name
tables Bni
type
Retrieves the type of the data of the expression. The expression
may be a variable (scalar), a table column, or a table cell. Applies To
type Service_Name.Table_Name.Column_Name
type Hoc.DnsServersInfo.IpAddress
type Table_Name.Column_Name
type DnsServersInfo.IpAddress
Command Execution
This section describes the syntax to use to execute a MIB command.
Global Context
Service_Name.Command arg1=value1 -b arg2=[value2 value3 value4]
SipEp.InsertGateway Name=test
Service Context
Command arg1=value1 -b arg2=[value2 value3 value4]
InsertGateway Name=test
The Aastra unit contains an embedded web server to set parameters by using the HTTP or HTTPS protocol.
Introduction
100 Secure The Web server only accepts requests using HTTPS. Requests using HTTP
are ignored. This is the default value.
200 Unsecure The Web server only accepts requests using HTTP. Requests using HTTPS
are ignored.
300 Both The Web server accepts requests using HTTP or HTTPS.
If you are using HTTPS (either in “Secure” mode or “Both” mode), the web server needs a valid
server certificate with “server authentication” extended key usage installed on the Aastra unit. See
“Chapter 43 - Certificates Management” on page 431 for more details.
Accessing the web pages via HTTPS adds additional delay since encryption is used. To access the
unit via HTTPS, your browser must support RFC 2246 (TLS 1.0).
Note that the web server does not listen to the configured modes when the management interface
is down or a configuration error occurred (e.g., missing or invalid certificate for HTTPS mode) while
setting up the web server.
3. Set the TCP port on which the web service listens for HTTP requests in the serverPort variable.
You can also use the following line in the CLI or a configuration script:
web.serverPort="Value"
4. Set the port on which the web service listens for HTTPS requests in the secureServerPort
variable.
You can also use the following line in the CLI or a configuration script:
web.secureServerPort="Value"
Macro Description
Aastra recommends that you use the latest version of the Microsoft
® Internet Explorer web browser to
properly access the web interface.
Menu Items
The Menu frame is displayed at the top of the browser window. It contains management links that allow you
to display web pages in the Content frame. The management links available vary depending on the Aastra unit
you are using.
Table 12: Menu Frame Links
Link Description
Link Description
Status: Allows you to view the status of the Aastra unit POTS parameters. See
“Chapter - POTS Parameters” on page 143for more details.
Config: Allows you to configure the POTS parameters of the Aastra unit. See
POTS “Chapter 20 - General POTS Configuration” on page 145 for more details.
FXS Config: Allows you to configure the FXS parameters of the Aastra unit. See
“Chapter 20 - POTS Configuration” on page 145 for more details.
FXO Config: Not applicable.
Gateways: Allows you to add and remove SIP gateways in the Aastra unit. See
“Chapter 21 - SIP Gateways Configuration” on page 155 for more details.
Servers: Allows you to configure the SIP server and SIP user agent parameters
of the Aastra unit. See “Chapter 22 - SIP Servers” on page 159 for more details.
Registrations: Allows you to configure the registration parameters of the Aastra
unit. See “Chapter 23 - Endpoints Registration” on page 167 for more details.
Authentication: Allows you to configure authentication parameters of the Aastra
unit. See “Chapter 24 - SIP Authentication” on page 179 for more details.
SIP Transport: Allows you to configure the SIP transport parameters of the Aastra
unit. See “Chapter 25 - SIP Transport Parameters” on page 183 for more details.
Interop: Allows you to configure the SIP interop parameters of the Aastra unit.
See “Chapter 26 - Interop Parameters” on page 189 for more details.
Misc: Allows you to configure interoperability features of the Aastra unit. See
“Chapter 27 - SIP Penalty Box” on page 211 for more details.
Codecs: Allows you to configure the voice and data codec related parameters of
the Aastra unit. See “Chapter 28 - Voice & Fax Codecs Configuration” on
page 231 for more details.
Security: Allows you to properly configure the security parameters of the Aastra
unit. See “Chapter 29 - Security” on page 253 for more details.
Media
RTP Stats: Allows you to read and configure the RTP statistics collected by the
Aastra unit. See “Chapter 30 - RTP Statistics Configuration” on page 257 for
more details.
Misc: Allows you to configure parameters that apply to all codecs. See “Chapter
31 - Miscellaneous Media Parameters” on page 263 for more details.
DTMF Maps: Allows you to configure the various DTMF maps of the Aastra unit.
See “Chapter 32 - DTMF Maps Configuration” on page 279 for more details.
Call Forward: Allows you to configure three types of Call Forward. See “Chapter
33 - Call Forward Configuration” on page 287 for more details.
Services: Allows you to configure the Aastra unit subscriber services. See
“Chapter 34 - General Configuration” on page 295 for more details.
Tone Customization: Allows you to override the pattern for a specific tone
defined for the selected country. See “Chapter 35 - Tone Customization
Parameters Configuration” on page 317 for more details.
Telephony Music on Hold: Allows you to configure the Music on Hold service of the Aastra
unit. See “Chapter 36 - Configuring the TFTP Server” on page 321 for more
details.
Misc: Allows you to configure the country in which the Aastra unit is located. See
“Chapter 37 - Country Configuration” on page 325 for more details.
Link Description
Status: Allows you to view the current status of the call routing service. See
“Chapter 38 - Call Router Configuration” on page 335 for more details.
Route Config: Allows you to configure the call routing service of the Aastra unit.
Call Router
See “Chapter 38 - Call Router Configuration” on page 335 for more details.
Auto-routing: Allows you to configure the auto-routing feature of the Aastra unit.
See “Chapter 39 - Auto-Routing Configuration” on page 391 for more details.
Configuration Scripts: Allows you to configure the various configuration scripts
parameters of the Aastra unit. See “Chapter 40 - Creating a Configuration Script”
on page 414 for more details.
Backup / Restore: Allows you to configure how to backup and restore the Aastra
unit’s configuration. See “Chapter 41 - Configuration Backup/Restore” on
page 415 for more details.
Firmware Upgrade: Allows you to configure the various firmware upgrade
parameters of the Aastra unit. See “Chapter 42 - Firmware Download” on
page 423 for more details.
Certificates: Allows you to add and delete security certificates in the Aastra unit.
Management See “Chapter 43 - Certificates Management” on page 431 for more details.
SNMP: Allows you to configure the SNMP privacy parameters of the Aastra unit.
See “Chapter 44 - SNMP Configuration” on page 437 for more details.
CWMP: Not applicable.
Access Control: Allows you to set the Access Control parameters of the Aastra
unit. See “Chapter 45 - Users” on page 443 for more details.
File:Allows you to use the unit’s File Manager. See “File Manager” on page 449
for more details.
Misc: Allows you to set various parameters used to manage the Aastra unit. See
“Chapter 47 - Management Interface Configuration” on page 451 for more details.
Reboot Allows you to restart the Aastra unit.
Submitting Changes
When you perform changes in the web interface and click the Submit button, the Aastra unit validates the
changes. A message is displayed next to any invalid value. A message is also displayed if a service must be
restarted and a link is displayed at the top of the page. This link brings you to the Services page. In this page,
each service that requires to be restarted has a “*” beside its name. See “Chapter 4 - Services” on page 53
for more details.
If you are not able to restart one or more services, click the Reboot link in the top menu. The Reboot page then
opens. You must click Reboot. This restarts the Aastra unit. If the unit is in use when you click Reboot, all calls
are terminated.
If you want to configure the Aastra unit to perform a basic call, this usually involves the following:
Table 13: Basic Call Configuration Steps
Configuring the POTS You must minimally configure the FXS “Chapter 20 - POTS
parameters interfaces so that they can send and receive Configuration” on page 145
TA7102i calls.
Configuring the SIP Configuring the SIP endpoint allows you to “Chapter 22 - Introduction” on
Endpoint register your ISDN telephone or FXS interfaces page 159
to a SIP server. This includes setting the “Chapter 23 - Registration
following parameters: Configuration” on page 169
• Registrar Server Host “Chapter 21 - SIP Gateways” on
• Proxy Home Domain Host page 155
• User Name
• Friendly Name
• Gateway Name
Configuring the Call You must create routes that will route calls from “Call Router Configuration” on
Router with Routes FXS to SIP and from SIP to FXS. page 335
Configuration of the You must create mappings that will allow you to “Mappings” on page 358
Call Router: Mapping properly communicate from FXS to SIP and
from SIP to FXS.
4 Services
This chapter describes how to view and start/stop system and network parameters of the Aastra unit.
Services Table
The Aastra unit uses many services grouped in two classes: system and user. You can perform service
commands on user services, but not the system services.
Whenever you perform changes in the various sections of the web interfaces, this usually means that you must
restart a service for the changes to take effect. When a service needs to be restarted, it is displayed in bold
and the message Restart needed is displayed in the Comment column.
If you are not able to restart a service because it is a system service, click the Reboot link in the top menu.
The Reboot page then opens. You must click Reboot. This restarts the Aastra unit. If the unit is in use when
you click Reboot, all calls are terminated.
Service Description
System Services
Authentication, Authorization Authenticates a user and grants rights to perform specific tasks
and Accounting (AAA) on the system.
Certificate Manager (CERT) Manages certificate files and provides access to these
certificates.
Configuration Manager Responsible of configuration scripts transfers, as well as
(CONF) configuration image upload/download for backup/restore of the
unit configuration.
Device Control Manager Auto-detects and identifies the hardware components of the unit.
(DCM)
Ethernet Manager (ETH) Configures the system's Ethernet ports parameters.
File Manager (FILE) Manages the files created with the File transfer protocol.
Firmware Pack Updater Handles firmware upgrade and downgrade operations.
(FPU)
Host Configuration (HOC) Configures network parameters that apply to the Aastra unit (not
to a specific interface).
Local Quality Of Service Configures the packets tagging sent from the Aastra unit.
(LQOS)
Process Control Manager Responsible to boot and restart the unit.
(PCM)
Service Controller Manager Responsible to:
(SCM) • Manage services information.
• Offer proxy functionality for service interoperation.
User Services
Basic Network Interface Configures the IP address and network mask for the Uplink and
(BNI) LAN1 networks.
Call Routing (CROUT) Routes calls between interfaces.
Call Detail Record (CDR)
Command Line Interface Allows you user to configure the unit parameters by, Telnet or
(CLI) SSH.
CPE WAN Management Not applicable.
Protocol (CWMP)
DHCP Server (Dhcp) Allows the user to lease IP addresses and send network
configuration to hosts located on any network.
Endpoint Administration Holds basic administration and status at endpoint and unit level.
(EpAdm)
Endpoint Services (EpServ) Manages endpoint behaviour and holds configuration
parameters related to endpoints (such as DTMF maps,
telephony services, etc.).
IP Routing (IpRouting) Allows the user to configure the unit's routing table.
IP Synchronization (IpSync) Controls the IP media synchronization using clock reference
signals sent over IP.
Service Description
2. In the User Service section, select the service startup type of a service in the Startup Type column.
Table 16: Startup Types
Type Description
You can put only user services in manual startup type. Proceed with caution when setting services
to manual because this could prevent you from successfully contacting the unit.
3. Select if you want to perform service commands on one or more services in the Action column.
Table 17: Actions
Action Description
Action Description
When a service needs to be restarted to apply new configuration you have set elsewhere in the web
interface, it is displayed in bold and the message Restart needed is displayed in the Comment
column.
If you stop, start or restart a service, any dependent services are also affected. The tabs of the
services that have been stopped or have never been started because their startup type is manual
are greyed out. Upon clicking these tabs, a list of services that must be restarted is displayed.
4. Click the Restart Required Services button at the bottom of the page.
2. Click Restart Required Services to restart only the services that needed a restart for their
configuration to be applied.
If you click Cancel, this cancels the restart during the grace delay period.
If a specific service needs to be restarted, locate the scmMIB, then set the serviceCommandsRestart variable
for this service to restart.
You can also start a service by setting the serviceCommandsStart variable for this service to Start.
You can also stop a service by setting the serviceCommandsStop variable for this service to Stop.
If you are not able to restart a service because it is a system service, you must restart the Aastra unit.
5 Hardware Parameters
For Aastra unit models that have two Ethernet ports, you can configure how each port provides a link interface.
2. In the Unit Configuration section, set the Eth Ports drop-down menu with the proper behaviour.
Table 18: Bridging Parameters
Parameter Description
Separate Each Ethernet port provides an independent link interface. This is the required
configuration for IP Routing.
Bridge Both Ethernet ports are bridged together and provide a single link interface.
6 7 8 9 10
5. Enter the name of the new interface for bridging in the blank field in the bottom left of the window,
then click the button.
The name is case-sensitive. Using the special value “All” is not allowed.
6. In the Interface Configuration section, select the link on which to activate the interface in the Link
column.
Select the link associated with the bridge. The name varies depending on the platform used.
7. Select the configuration source of the interface information in the Type drop-down menu.
Table 19: Interface Configuration Sources
Source Description
IPv4 The IPv4 address and network mask are provided by querying a DHCP server and
DHCP using standard DHCP fields or options. Using the DHCP configuration assumes that
you have properly set your DHCP server with the relevant information. DHCP servers
may provide a list of IP configuration parameters to use. See “DHCP Server
Configuration” on page 95 for more details.
IPv4 You manually enter the IPv4 address and network mask and they remain the same
Static every time the Aastra unit restarts. Use the static configuration if you are not using a
DHCP server/PPP peer or if you want to bypass it.
IPv4 IPv4 over PPP connection, address and network mask are provided by the PPP peer
PPPoE using IPCP. PPP peers may provide a list of IP configuration parameters to use. See
“PPPoE Configuration” on page 91 for more details.
IPv6 IPv6 state-less auto-configuration.
Auto-
Conf
IPv6 You manually enter the IPv6 address and network mask and they remain the same
Static every time the Aastra unit restarts. Use the IPv6 static configuration if you are not using
IPv6 stateless or stateful auto-configuration or if you want to bypass it.
Note: If no network is configured in IPv6, the unit does not have any IPv6 address, not even the Link-Local
address. When a network is configured in IPv6, the Link-Local (FE80 ::...) address is automatically created
and displayed in the Network Status information.
8. If the interface configuration source is IPv4 Static or IPv6 Static, enter the address and network
mask (if applicable) of the network interface in the Static IP address field.
9. If the interface configuration source is IPv4 Static or IPv6 Static, set the Static Default Router field
with the IP address of the default gateway for the network interface.
10. Define whether or not the Aastra unit should attempt to activate the corresponding network interface
in the Activation drop-down menu.
It may not be possible to enable a network interface, for instance if another network interface is
already enabled in the same subnet. The actual status of network interfaces is shown in the Status
page.
Note: The newly created interface will be the only valid interface after the restart, make sure this interface
is Enabled and correctly configured according on the Interface Configuration Source (your network).
Ring Management
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
Parameter Descriprion
Cascade The FXS ports are prevented from ringing at the same time in order to reduce the peak
power usage of the device.
Simultaneous All ports are ringing at the same time.
Value Description
100 Cascade
200 Simultaneous
This chapter describes how to set the administrative state of the Aastra unit’s endpoints.
Unit Configuration
The unit configuration section allows you to define the administrative state of all the Aastra unit’s endpoints.
2. In the Unit States section, select a temporary state for all of the unit’s endpoints in the Action
column.
This command locks/unlocks all endpoints of the Aastra unit. This state is kept until you modify it or
the unit restarts. It offers the following settings:
Table 22: Action Settings
Setting Description
Force Lock Cancels all the endpoints registration to the SIP server. All active calls in
progress are terminated immediately. No new calls may be initiated.
Lock Cancels all the endpoints registration to the SIP server. Active calls in
progress remain established until normal call termination. No new calls
may be initiated.
Unlock Registers the endpoints to the SIP server.
Endpoints Configuration
The endpoints configuration allows you to define the administrative state of the Aastra unit’s endpoints.
Setting Description
2. Select a temporary state for each endpoint in the corresponding Action column.
This command locks/unlocks an endpoint of the Aastra unit. This state is kept until you modify it or
the unit restarts. It offers the following settings:
Table 24: Action Settings
Setting Description
Force Lock Cancels the endpoint registration to the SIP server. All active calls in
progress are terminated immediately. No new calls may be initiated.
Lock Cancels the endpoint registration to the SIP server. Active calls in
progress remain established until normal call termination. No new calls
may be initiated.
Unlock Registers the endpoint to the SIP server.
Administration
1
2
Parameter Description
Parameter Description
Enable When all signaling gateways are not ready, the unit
operational state is set to disabled.
2. Set the Shutdown Endpoint When Operational State is Disable And Its Usage State Is 'idle-
unusable' drop-down menu with the proper behaviour.
Table 26: Endpoint Shutdown Parameters
Parameter Description
Parameter Description
BlockNewCalls No new requests are accepted once all activity are terminated. Endpoints cannot make and
receive calls.
AllowNewCalls New requests are accepted until all activities are simultaneously terminated. Endpoints can
make and receive calls.
Value Meaning
100 BlockNewCalls
Value Meaning
200 AllowNewCalls
7 Syslog Configuration
This chapter describes how the Aastra unit. handles syslog messages and notification messages.
For a list and description of all syslog messages and notification messages that the Aastra unit may send, refer
to the Notification Reference Guide.
The Syslog daemon is a general purpose utility for monitoring applications and network devices with the TCP/
IP protocol. With this software, you can monitor useful messages coming from the Aastra unit. If no Syslog
daemon address is provided by a DHCP server or specified by the administrator, no messages are sent.
For instance, if you want to download a new firmware into the Aastra unit, you can monitor each step of the
firmware download phase. Furthermore, if the unit encounters an abnormal behaviour, you may see accurate
messages that will help you troubleshoot the problem.
The Aastra unit supports RFC 3164 as a “device” only (see definition of device in section 3 of the RFC).
4
5
2. Set the static IP address or domain name and port number of the device to use to archive log entries
in the Remote Host field.
Use the special port value zero to indicate the protocol default. For instance, the TFTP default port
is 69 and the HTTP/HTTPS default port is 80.
3. In the Service Severity section, select the minimal severity to issue a notification message for the
various services in the corresponding drop-down menus.
Any syslog message with a severity value greater than the selected value is ignored. Available
values are:
Table 29: Severity Values
A higher level mask includes lower level masks, e.g., Warning includes Error and Critical. The
default value is Warning.
4. In the Technical Assistance Centre section, enable diagnostic traces by setting the Diagnostic
Traces drop-down menu to Enable.
At the request of Aastra’s Technical Support personnel, enabling these traces will allow Aastra to
further assist you in resolving some issues. However, be advised that enabling this feature issues
a lot of messages to the syslog host. These messages may be filtered by using the Diagnostic
Traces Filter field.
Note: Enabling all the traces could affect the performance of the Aastra unit.
5. If applicable, define the filter applied to diagnostic traces by clicking the Edit button in the Filter field.
The following opens:
You can use the filter to narrow down the number of traces sent at the request of Aastra´s Technical
Support personnel.
6. Click Submit if you do not need to set other parameters.
3. Set the unit's endpoint on which the PCM capture must be performed in the pcmCaptureEndpoint
variable.
You can also use the following line in the CLI or a configuration script:
mipt.pcmCaptureEndpoint="Value"
The format is InterfaceName-Channel#. For digital interfaces (such as ISDN), you must append a
-Channel# for the requested channel.
The list of endpoints is available under EpAdm.EndpointTable. Valid examples (depending of the
platform) are:
• PCM capture is to be done on channel #3 of a PRI interface located in slot #2: Slot2/
E1T1-3
• PCM capture is to be done on channel #2 of a BRI interface: Bri1-2
• PCM capture is to be done on the 16th FXS port: Port16
Note: Note that PCM capture does not support capturing on multiple endpoints simultaneously.
4. Set the IP address where the captured PCM packets should be sent in the pcmCaptureIpAddr
variable.
You can also use the following line in the CLI or a configuration script:
mipt.pcmCaptureIpAddr="Value"
The PCM traces destination must be set so it can be recorded in a Wireshark capture on your
network, normally sent to the PC doing the capture.
8 Events Configuration
This chapter describes how to associate a NOTIFICATION message and how to send it (via syslog or via a
SIP NOTIFY packet).
For a list and description of all syslog messages and notification messages that the Aastra unit may send, refer
to the Notification Reference Guide.
Notification Events
You can configure an event router in order to apply a set of rules to select the proper transport protocol
scheme. A rule entry is made up of three different values: type, criteria and action.
Note that more than one notification may be sent for a single event based on the event router table rules.
4 5 6 7 8
3. If you want to add a rule entry before an existing entry, locate the proper row in the table and click
the button of this row.
4. Set the Activation drop-down menu with the current activation state for the corresponding system
event.
Table 30: Activation Parameters
Parameter Description
5. Optional: Set the corresponding Criteria field with the expression an event must match in order to
apply the specified action. The expression is based on the event type.
This step is optional because a proper value may be automatically entered by the Aastra unit upon
setting the Service (Step 5) and Notification (Step 6) drop-down menus.
An event of type notification uses the notification ID as expression criteria. The notification ID is the
combination of the service number key and the message number key separated by a dot. The
information regarding the service and message number key is available in the Notification
Reference Guide document.
Several basic criteria can also be specified on the same line, separated by commas. Criteria can
specify inclusion or exclusion. A group of exclusion criteria can follow the group of inclusion criteria.
The group of exclusion criteria must begin with a hyphen (-).
Matching an inclusion criteria causes the action to be executed unless an exclusion criteria is also
matched. Exclusion criteria have precedence over inclusion criteria.
Spaces are allowed before or after a basic criterion; however, spaces are not accepted within a
basic criterion, i.e. before or after the dot.
Examples:
Service ISDN (number key = 1850)
Message %1$s: Physical link state changed to up (number key = 5)
The corresponding Criteria is: 1850.5
You can also use the special expression All, which means all available services and messages.
Criteria 1850.All,1600.200,1600.W,-1850.500,1600.300
1850.All,1600.200,1600.W are inclusion criteria and -1850.500,1600.300 are exclusion criteria. All
notifications from service 1850, except notification 500, will match the expression. All notifications
from service 1600 with Warning level, except notification 300, will match the expression. Notification
200 from service 1600 will match the expression, no matter the severity level.
6. In the corresponding Service drop-down menu, select the service for which you want to send
events.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
7. In the Notification drop-down menu, select the notification message that you want to send.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
8. In the Action drop-down menu, select the action to apply to the system event if the criteria matches.
The action represents a transport targeted for the event. The format of the event under which the
message is carried is dependent on the protocol in use.
The possible actions are:
Table 31: Action Parameters
Parameter Description
Send Via The event notification is sent using syslog as transport. See “Chapter 7 - Syslog
Syslog Configuration” on page 71 for more details.
Send Via The event notification is sent using SIP Notify as transport.
SIP
Log The event notification is logged in Local Log.
Locally
Value Description
Valid The current content of the fields Type, Criteria and Action is valid.
Invalid The current content of the fields Type, Criteria and Action is not valid.
Value Description
Not The current content of the fields Type, Criteria and Action is valid but not
Supported supported.
Deleting a Rule
You can delete a rule row from the table in the web interface.
Monitoring Parameters
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
You can set two monitoring parameters for the Notification Events table.
Value is the name of the SIP gateway from which the NOTIFICATION is sent.
3. Set the maxNotificationsPerNotify variable with the maximal number of notification events the
device may have to send in one SIP NOTIFY request.
Notifications are sent in XML elements through the SIP NOTIFY's body request.
You can also use the following line in the CLI or a configuration script:
sipEp.maxNotificationsPerNotify="Value"
9 Local Log
This chapter describes local log status and entries for your Aastra unit.
You can display, clear and refresh local log status and entries.
2 3
Parameter Description
Maximum Number of Entries Maximum number of entries that the local log can contain. When
adding a new entry while the local log is full, the oldest entry is
erased to make room for the new one.
Number of Error Entries Current number of error entries in the local log.
Number of Critical Entries Current number of critical entries in the local log.
Parameter Description
Local Time Local date and time at which the log entry was inserted. Format is
YYYY-MM-DD HH:MM:SS.
Severity Severity of the log entry.
Service Name Textual identifier of the service that issued the log entry.
Service Key Numerical identifier of the service that issued the log entry.
Message Key Numerical identifier of the notification message.
Message Content The readable content of the log message.
This chapter describes the differences between IPv4 and IPv6 addressing.
Introduction
IPv6 (Internet Protocol version 6) is the successor to the most common Internet Protocol today (IPv4). This is
largely driven by the fact that IPv4’s 32-bit address is quickly being consumed by the ever-expanding sites and
products on the internet. IPv6’s 128-bit address space should not have this problem for the foreseeable future.
IPv6 addresses, in addition to being longer, are distinguished from IPv4 addresses by the use of colons ":",
e.g., 2001:470:8929:4000:201:80ff:fe3c:642f. An IPv4 address is noted by 4 sets of decimal numbers
separated by periods ".", e.g., 192.168.10.1.
Please note that IPv6 addresses should be written between [ ] to allow port numbers to be set. For instance:
[fd0f:8b72:5::1]:5060.
The Aastra unit fully supports IPv4 IP addresses, as well as IPv6 IP addresses in some of its features. The
following table lists all the network related features of the Aastra unit with their availability in IPv4 and IPv6.
Table 35: IPv4 vs. IPv6 Availability
Backup/Restore transfer
Command Line Interface (CLI)
Configuration file transfer
Embedded DHCP server
Firmware Transfer
IP Routing
IP Sync
Link Layer Discovery Protocol (LLDP) QoS settings
Local Firewall (LFW)
Network Address Translation (NAT)
Network Configuration (IP addresses, DNS and SNTP servers)
Network Firewall (NFW)
Online Certificate Status Protocol (OCSP)
Remote Authentication Dial In User Service (Radius )
SIP signaling and media transport
Simple Network Management Protocol (SNMP)
TR-069
WEB Configuration
If you configure the Aastra unit with IPv6 addresses, then decide to go downgrade to a firmware version that
does not support IPv6, all IPv6 networks are deleted.
Please note that IPv6 addresses should be written between [ ]. For instance: [fd0f:8b72:5::1].
When using an IPv6 address starting with "FE80::" (IPv6 link-local addresses), there must be additional
information: the IPv6 scope identifier (this represents the network link that will be used to contact the IPv6 link-
local address). The format is "[IPv6 link-local%ScopeIdentifier]".
To contact the IPv6 link-local IPv6 address "fe80::201:80ff:fe3c:642f", you would use:
[fe80::201:80ff:fe3c:642f%4]
On Linux, the scope identifier may be the link name or the interface number. The interface number can be
determined through the Linux command line.
To contact the IPv6 link-local IPv6 address "fe80::201:80ff:fe3c:642f", you would use:
[fe80::201:80ff:fe3c:642f%2] or [fe80::201:80ff:fe3c:642f%eth0]
11 Host Parameters
This chapter describes how to set the host information of the Aastra unit:
General Configuration (automatic configuration interface)
Host name and domain name.
Default gateway parameters.
DNS parameters.
SNTP client parameters.
Time parameters.
General Configuration
The General Configuration section allows you to configure the networks that will provide the automatic
configuration (host name, default gateway, DNS servers and SNTP servers) used by the Aastra unit.
Automatic configuration may be provided via IPv4 (DHCPv4) and/or via IPv6 (stateless auto-configuration and
DHCPv6).
2
3
2. Set the Automatic IPv4 config source network drop-down menu with the IPv4 network interface that
provides the automatic configuration.
3. Set the Automatic IPv6 config source network drop-down menu with the IPv6 network interface that
provides the automatic configuration.
4. Click Submit if you do not need to set other parameters.
The current automatic configuration interface is displayed in the Status page.
Host Configuration
The Host Configuration section allows you to configure the host name and domain name of the Aastra unit.
2
3
Source Description
Automatic The domain name is automatically obtained from the network. The value obtained
IPv4 depends on the connection type of the automatic network interface (see “General
Configuration” on page 75) if any. Using the automatic configuration assumes that
you have properly set your network server with the relevant information.
Note: Some Uplink connection types (for example Static and PPPoE) cannot obtain
domain name information from the network, and therefore lead to no domain name
being applied to the system.
Automatic The domain name is automatically obtained from the IPv6 network defined in the
IPv6 Automatic IPv6 config source network drop-down menu.
Static You manually enter the domain name and it remains the same every time the Aastra
unit restarts. Use the static configuration if you are not using a network server or if
you want to bypass it.
When switching from the Static to Automatic IPv4 or Automatic IPv6 configuration source, the last
value correctly obtained from the network (if any) is applied to the system.
The default gateway (also known as default router) is the gateway to which the Aastra unit sends packets
when all other internally known routes have failed.
1. In the Default Gateway Configuration – IPv4 section of the Host page, select the IPv4 configuration
source of the default gateway information in the Configuration Source drop-down menu.
1
2
3
4
Source Description
Automatic The default gateway is automatically obtained from the network. The value obtained
IPv4 depends on the connection type of the automatic network interface (see “General
Configuration” on page 75) if any. Using the automatic configuration assumes that
you have properly set your network server with the relevant information.
Note: Some Uplink connection types (for example Static) cannot obtain default
gateway information from the network, and therefore lead to no default gateway being
applied to the system.
Static You manually enter the IP address of the default gateway and it remains the same
every time the Aastra unit restarts. Use the static configuration if you are not using a
network server or if you want to bypass it.
When switching from the Static to Automatic configuration source, the last value correctly obtained
from the network (if any) is applied to the system.
2. If the default gateway configuration source is Static, enter the static default gateway address in the
IP address field.
This can be an IP address or domain name. The default value is 192.168.10.10.
IPv6 Configuration
3. In the Default Gateway Configuration – IPv6 section of the Host page, select the IPv6 configuration
source of the default gateway information in the Configuration Source drop-down menu.
Table 38: IPv6 Default Gateway Configuration Sources
Source Description
Automatic The default gateway name is automatically obtained from the IPv6 network defined
IPv6 in the Automatic IPv6 config source network drop-down menu.
Static You manually enter the IPv6 address of the default gateway and it remains the same
every time the Aastra unit restarts. Use the static configuration if you are not using a
network server or if you want to bypass it.
When switching from the Static to Automatic IPv6 configuration source, the last value correctly
obtained from the network (if any) is applied to the system.
4. If the default gateway configuration source is Static, enter the static default gateway IPv6 address
in the IP address field.
This can be an IP address or domain name.
5. Click Submit if you do not need to set other parameters.
The current default gateway address is displayed in the Status page.
DNS Configuration
You can use up to four Domain Name Servers (DNS) to which the Aastra unit can connect. The DNS servers
list is the ordered list of DNS servers that the Aastra unit uses to resolve network names. DNS query results
are cached on the system to optimize name resolution time.
Source Description
Automatic The DNS servers are automatically obtained from the network. The value obtained
IPv4 depends on the connection type of the automatic network interface (see “General
Configuration” on page 75) if any. Using the automatic configuration assumes that
you have properly set your network server with the relevant information.
Note: Some Uplink connection types (for example Static) cannot obtain DNS
information from the network, and therefore lead to no DNS servers being applied to
the system.
Automatic The DNS servers are automatically obtained from the IPv6 network defined in the
IPv6 Automatic IPv6 config source network drop-down menu.
Static You manually enter up to four DNS servers IP addresses and they remain the same
every time the Aastra unit restarts. Use the static configuration if you are not using a
network server or if you want to bypass it.
When switching from the Static to Automatic IPv4 or Automatic IPv6 configuration source, the last
values correctly obtained from the network (if any) are applied to the system.
2. If the DNS configuration source is Static, enter up to four static DNS addresses in the following
fields:
• Primary DNS
• Secondary DNS
• Third DNS
• Fourth DNS
3. Click Submit if you do not need to set other parameters.
The current list of DNS servers is displayed in the Status page.
SNTP Configuration
Standards Supported • RFC 2030: Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI
• bootp-dhcp-option-88
The Simple Network Time Protocol (SNTP) enables the notion of time (date, month, time) into the Aastra unit.
SNTP is used to synchronize a SNTP client with a SNTP or NTP server by using UDP as transport. It updates
the internal clock of the unit to maintain the system time accurate. It is required when dealing with features
such as the caller ID.
The Aastra unit implements a SNTP version 3 client.
Note: The Aastra unit hardware does not include a real time clock. The unit uses the SNTP client to get and
set its clock. As certain services need correct time to work properly (such as HTTPS), you should configure
your SNTP client with an available SNTP server in order to update and synchronise the local clock at boot
time.
Source Description
Automatic The SNTP parameters are automatically obtained from the network. The value
IPv4 obtained depends on the connection type of the automatic network interface (see
“General Configuration” on page 75) if any. Using the automatic configuration
assumes that you have properly set your network server with the relevant
information.
Note: Some Uplink connection types (for example Static and PPPoE) cannot obtain
SNTP information from the network, and therefore lead to no SNTP parameters being
applied to the system.
Automatic The SNTP parameters are automatically obtained from the IPv6 network defined in
IPv6 the Automatic IPv6 config source network drop-down menu.
Source Description
Static You manually enter the values and they remain the same every time the Aastra unit
restarts. Use the static configuration if you are not using a network server or if you
want to bypass it.
When switching from the Static to Automatic IPv4 or Automatic IPv6 configuration source, the last
values correctly obtained from the network (if any) are applied to the system.
2. If the SNTP configuration source is Static, enter up to four static SNTP server IP addresses or
domain names and port numbers in the following fields:
• Primary SNTP
• Secondary SNTP
• Third SNTP
• Fourth SNTP
3. Set the synchronization information:
Table 41: SNTP Synchronization Information
Field Description
Time Configuration
You can define the current system date and time configured in the unit by specifying in which time zone the
unit is located.
If the time seems not valid, verify the SNTP configuration in “SNTP Configuration” on page 79.
The format of the string is validated upon entry. Invalid entries are refused. The default value is:
EST5DST4,M4.1.0/02:00:00,M10.5.0/02:00:00
A POSIX string is a set of standard operating system interfaces based on the UNIX operating
system. The format of the IEEE 1003.1 POSIX string is defined in the bootp-dhcp-option-88 Internet
draft as:
STDOFFSET[DST[OFFSET],[START[/TIME],END[/TIME]]]
Refer to the following sub-sections for explanations on each part of the string.
2. Click Submit if you do not need to set other parameters.
The current system time is displayed in the Status page.
STD / DST
Three or more characters for the standard (STD) or alternative daylight saving time (DST) time zone. Only STD
is mandatory. If DST is not supplied, the daylight saving time does not apply. Lower and upper case letters are
allowed. All characters are allowed except digits, leading colon (:), comma (,), minus (-), plus (+), and ASCII
NUL.
OFFSET
Difference between the GMT time and the local time. The offset has the format h[h][:m[m][:s[s]]]. If no offset is
supplied for DST, the alternative time is assumed to be one hour ahead of standard time. One or more digits
can be used; the value is always interpreted as a decimal number.
The hour value must be between 0 and 24. The minutes and seconds values, if present, must be between 0
and 59. If preceded by a minus sign (-), the time zone is east of the prime meridian, otherwise it is west, which
can be indicated by the preceding plus sign (+). For example, New York time is GMT 5.
START / END
Indicates when to change to and return from the daylight saving time. The START argument is the date when
the change from the standard to the daylight save time occurs; END is the date for changing back. If START
and END are not specified, the default is the US Daylight saving time start and end dates. The format for start
and end must be one of the following:
n where n is the number of days since the start of the year from 0 to 365. It must contain the
leap year day if the current year is a leap year. With this format, you are responsible to
determine all the leap year details.
Jn where n is the Julian day number of the year from 1 to 365. Leap days are not counted. That
is, in all years – including leap years – February 28 is day 59 and March 1 is day 60. It is
impossible to refer to the occasional February 29 explicitly. The TIME parameter has the same
format as OFFSET but there can be no leading minus (-) or plus (+) sign. If TIME is not
specified, the default is 02:00:00.
Mx[x].y.z where x is the month, y is a week count (in which the z day exists) and z is the day
of the week starting at 0 (Sunday). For instance:
M10.4.0
is the fourth Sunday of October. It does not matter if the Sunday is in the 4th or 5th week.
M10.5.0
is the last Sunday of October (5 indicates the last z day). It does not matter if the Sunday is in the
4th or 5th week.
M10.1.6
is the first week with a Saturday (thus the first Saturday). It does not matter if the Saturday is in the
first or second week.
The TIME parameter has the same format as OFFSET but there can be no leading minus (-) or plus
(+) sign. If TIME is not specified, the default is 02:00:00.
Example
The following is an example of a proper POSIX string:
Standard Offset Month, Week, and Day Month, Week, and Day
time zone to start the Daylight to stop the Daylight
Saving Time Saving Time
EST5DST4,M4.0.0/02:00:00,M10.5.0/02:00:00
Additional Parameters
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
Value Description
Enable When DNS A/AAAA records are accessed from the cache, they are sent to requesting
service in a randomized order.
Disable When DNS A/AAAA records are accessed from the cache, they are sent to requesting
service in the same order they were originally received from the network. This is the default
value.
Value Meaning
0 Disable
1 Enable
Parameter Description
Name Name (FQDN) of the static host. This name must be unique across the table.
The name only accepts valid FQDNs as defined by RFC 3986 (Uniform Resource Identifier
(URI): Generic Syntax). In addition, strict validation is applied, i.e. the suggested syntax
defined in RFC 1035 is enforced.
IpAddresses List of static IP addresses associated with the FQDN specified in the StaticHosts.Name
variable.
This list contains numerical IPv4 or IPv6 addresses. IP addresses MUST be separated by
a comma (,).
Index Index in the table. A value of zero (default) causes automatic selection of the largest
current index value + 1. If the index value already exists in the table, the insertion is
refused. This parameter is optional.
• address and address1 are numerical IPv4 or IPv6 addresses separated by a comma.
The value of this variable is also returned by the "sysName" object in SNMPv2-MIB.
2. Set the system location in the systemLocation variable.
You can also use the following line in the CLI or a configuration script:
hoc.systemLocation="Value"
The value of this variable is also returned by the "sysLocation" object in SNMPv2-MIB.
12 Interface Parameters
This chapter describes how to set the interfaces of the Aastra unit:
How to reserve an IP address in a network server.
Link Connectivity Detection
Partial Reset
Managing interfaces.
PPPoE parameters.
LLDP Configuration
Ethernet Link Configuration
DHCP Server Configuration
Ethernet Connection Speed
Configuring a MTU Value
Reserving an IP Address
Before connecting the Aastra unit to the network, Aastra strongly recommends that you reserve an IP address
in your network server – if you are using one – for the unit you are about to connect. This way, you know the
IP address associated with a particular unit.
Network servers generally allocate a range of IP addresses for use on a network and reserve IP addresses
for specific devices using a unique identifier for each device. The Aastra unit unique identifier is its media
access control (MAC) address. You can locate the MAC address as follows:
It is printed on the label located on the bottom side of the unit.
It is stored in the Device Info page of the web interface.
You can take one of the telephones connected to the Aastra unit and dial *#*1 on the keypad.
The MAC address of the Aastra unit will be stated.
Aastra recommends to reserve an IP address with an infinite lease for each Aastra unit on the network.
Each Ethernet port of the Aastra unit is associated with an Ethernet link. This information is available in the
Ethernet Ports Status section of the Network / Status page. A link has connectivity if at least one of its port
status is not disconnected.
The link connectivity is periodically polled (every 500 milliseconds). It takes two consecutive detections of the
same link state before reporting a link connectivity transition. This avoids reporting many link connectivity
transitions if the Ethernet cable is plugged and unplugged quickly.
Partial Reset
When a partial reset is triggered, the Rescue interface is configured and enabled with:
its hidden IPv4 link configuration values
its hidden IPv4 address configuration
Interfaces Configuration
The Interface Configuration section allows you to add and remove up to 48 network interfaces. By default, this
section contains the following network interfaces:
The Uplink interface, which defines the uplink information required by the Aastra unit to
properly connect to the WAN. The Uplink network interface is the IP interface that encapsulates
the following link interface (WAN connection):
• eth1 (TA7102i), wan for the Aastra TA7102i
By default, this interface uses the IPv4 DHCP connection type.
The Rescue interface, which defines the address and network mask to use to contact the
Aastra unit after a partial reset operation. You cannot delete this interface. See “Partial Reset”
on page 15 for more details.
The LAN interface IPv4 address and network mask.
The current status of the network interfaces is displayed in the Status page. It allows you to know which
interfaces are actually enabled. Enabled networks are activated when their configured link gets connectivity
and are deactivated as soon as the link connectivity is lost. See “Link Connectivity Detection” on page 85 for
more details.
The Interfaces Status section of the Status page displays the status of all currently enabled network interfaces,
including interfaces with an invalid configuration or waiting for a response.
When configuring network interfaces, Aastra recommends to have a syslog client properly configured and
enabled in order to receive any message related to the network interfaces behaviour. The interface used to
access the syslog client must also be properly enabled. See “Chapter 7 - Syslog Configuration” on page 71
for more details on enabling a syslog client.
Caution: Use extreme care when configuring network interfaces, especially when configuring the network
interface used to contact the unit for management. Be careful never to disable or delete the network interface
used to contact the unit. Also be careful to always set the unit’s management interface to be an interface
that you can contact.
Note: When performing a partial reset (see “Partial Reset” on page 15 for more details), the management
interface used for SNMP, CLI and WEB is automatically set to the Rescue interface. In that case, you must
change the Aastra unit system management network interface to something other than Rescue. Note that
you must be able to contact the interface you select.
3 4 5 6 7
2. If you want to add a new interface, enter its name in the blank field in the bottom left of the window,
then click the button.
The name is case-sensitive. Using the special value “All” is not allowed.
You can use the following ASCII codes in the network interface name:
49 1 77 M 103 g
50 2 78 N 104 h
51 3 79 O 105 i
52 4 80 P 106 j
53 5 81 Q 107 k
54 6 82 R 108 l
55 7 83 S 109 m
56 8 84 T 110 n
57 9 85 U 111 o
65 A 86 V 112 p
66 B 87 W 113 q
67 C 88 X 114 r
68 D 89 Y 115 s
69 E 90 Z 116 t
70 F 95 _, underscore 117 u
71 G 97 a 118 v
72 H 98 b 119 w
73 I 99 c 120 x
74 J 100 d 121 y
75 K 101 e 122 z
76 L 102 f
A valid network interface name must be compliant with the following rules:
• It must start with a letter
• It cannot contain characters other than letters, numbers, underscores.
If your Aastra unit contains an invalid interface name created in a previous firmware version without
the validation feature, the invalid interface name will be modified everywhere it appears on the first
restart and a syslog notification will be sent.
You can also delete an existing network interface by clicking the corresponding button. You
cannot delete the Rescue interface.
3. In the Interface Configuration section, select the link on which to activate the interface in the Link
column.
A VLAN is listed with the following syntax:
Link.VLAN ID
For instance, if you have added VLAN 20 on the interface eth5, it is listed as follows:
eth5.20
4. Select the configuration source of the interface information in the Type drop-down menu.
Table 46: Interface Configuration Sources
Source Description
IPv4 The IPv4 address and network mask are provided by querying a DHCP server and
DHCP using standard DHCP fields or options. Using the DHCP configuration assumes that
you have properly set your DHCP server with the relevant information. DHCP servers
may provide a list of IP configuration parameters to use. See “DHCP Server
Configuration” on page 95 for more details.
IPv4 You manually enter the IPv4 address and network mask and they remain the same
Static every time the Aastra unit restarts. Use the static configuration if you are not using a
DHCP server/PPP peer or if you want to bypass it.
IPv4 IPv4 over PPP connection, address and network mask are provided by the PPP peer
PPPoE using IPCP. PPP peers may provide a list of IP configuration parameters to use. See
“PPPoE Configuration” on page 91 for more details.
IPv6 IPv6 state-less auto-configuration. See “IPv6 Autoconfiguration Interfaces” on page 89
Auto- for more details.
Conf
IPv6 You manually enter the IPv6 address and network mask and they remain the same
Static every time the Aastra unit restarts. Use the IPv6 static configuration if you are not using
IPv6 stateless or stateful auto-configuration or if you want to bypass it.
Note: If no network is configured in IPv6, the unit does not have any IPv6 address, not even the Link-Local
address. When a network is configured in IPv6, the Link-Local (FE80 ::...) address is automatically created
and displayed in the Network Status information.
5. If the interface configuration source is IPv4 Static or IPv6 Static, enter the address and network
mask (if applicable) of the network interface in the Static IP address field.
6. If the interface configuration source is IPv4 Static or IPv6 Static, set the Static Default Router field
with the IP address of the default gateway for the network interface.
7. Define whether or not the Aastra unit should attempt to activate the corresponding network interface
in the Activation drop-down menu.
It may not be possible to enable a network interface, for instance if another network interface is
already enabled in the same subnet. The actual status of network interfaces is shown in the Status
page.
8. Click Submit if you do not need to set other parameters.
The current network interface information is displayed in the Status page.
Table 47: Network Interface Status
Status Description
Disabled The interface is not operational because it is explicitly disabled or the link
interface is unavailable.
Invalid Config The interface is not operational because its configuration is not valid.
Status Description
Network Conflict The interface is configured with an IP address that is already used on the
network.
Link Down The interface is configured with a link that has no connectivity.
Waiting The interface is not operational because a response from a peer or server
Response is required.
Active The interface is operational.
Stateless Autoconfiguration
All IPv6 addresses present in the router advertisements are applied to the network interface. Each IPv6
address is assigned a network name based on the configured network name with a suffix in the following
format: ConfiguredNetworkName-XX-Y.
XX is the address scope
GU (Global Unique)
UL (Unique Local)
LL (Link-Local)
Y is a unique ID for the address scope.
Stateful Autoconfiguration
Stateful autoconfiguration is managed by DHCPv6. The DHCPv6 lease is negotiated according to RFC 3315
with the limitations listed in section 1.5. DHCPv6 may be used to obtain the following information (depending
on the router advertisement flags):
IPv6 addresses (when the router advertisement “managed” flag is set)
Other configuration (when the router advertisement “other” flag is set)
If only the “other” flag is set in the router advertisement, the DHCPv6 client only sends an information request
to the DHCPv6 server, otherwise it sends a DHCPv6 solicit message. If the flags change over time, only the
transitions from “not set” to “set“ are handled.
eth.networkInterfacesPriority="Value"
where Value may be any number between 0 and 100.
You can define whether or not the Aastra unit should attempt to activate the rescue network interface.
It may not be possible to enable a network interface, for instance if another network interface is
already enabled in the same subnet. The actual status of network interfaces is shown in the Status
page.
2. Click Submit if you do not need to set other parameters.
PPPoE Configuration
Standards Supported • RFC 1332 – The PPP Internet Protocol Control Protocol
(IPCP)
• RFC 1334 – PPP Authentication Protocolsa
• RFC 1661 – The Point-to-Point Protocol (PPP)
• RFC 1877 – PPP Internet Protocol Control Protocol
Extensions for Name Server Addressesb
• RFC 1994 – Challenge Handshake Authentication Protocol
(CHAP)
• RFC 2516 – A Method for Transmitting PPP Over Ethernet
(PPPoE)
a. Section 2 (PAP), section 3 is obsoleted by RFC 1994
b. Supported except for sections 1.2 and 1.4
The PPPoE Configuration section applies only if you have selected the PPPoE connection type in the Interface
Configuration section of the web page.
1
2
3
This is used as the Service-Name field of the packet broadcasted to the access concentrators. See
RFC 2516 section 5.1 for details.
The field may be set with any string of characters, with a maximum of 255 characters.
If you leave this field empty, the Aastra unit looks for any access concentrator.
2. Select the authentication protocol to use for authenticating the system to the PPP peer in the
Protocol drop-down menu.
• PAP: Use the Password Authentication Protocol.
• CHAP: Use the Challenge Handshake Authentication Protocol.
3. Set the PPP user name and password that identify the system to the PPP peer during the
authentication process in the User Name and Password fields.
Caution: The User Name and Password fields are not accessible if you have the User or Observer access
right. See “Users” on page 591 for more details.
When connecting to an access concentrator, it may request that the Aastra unit identifies itself with
a specific user name and password.
There are no restrictions, you can use any combination of characters.
4. Click Submit if you do not need to set other parameters.
The current PPPoE information is displayed in the Status page.
PPP Negotiation
When the Aastra unit restarts, it establishes the connection to the access concentrator in conformance with
the RFCs listed in “PPPoE Configuration” on page 91.
When establishing a PPP connection, the Aastra unit goes through three distinct phases:
Discovery phase
Authentication phase
Network-layer protocol phase
Discovery Phase
The Aastra unit broadcasts the value of the Service Name field.
The access concentrator with a matching service name answers the Aastra unit.
If no access concentrator answers, this creates a “PPPoE failure” error.
If more than one access concentrators respond to the discovery, the Aastra unit tries to
establish the PPP connection with the first one that supports the requested service name.
Authenthication Phase
If the access concentrator requests authentication, the Aastra unit sends the ID/secret pair configured in the
User Name and Password fields. If the access concentrator rejects the authentication, this creates an
“authentication failure” error.
Parameter Description
Value Meaning
100 Disabled
200 MacAscii
300 MacBinary
LLDP Configuration
The Link Layer Discovery Protocol (LLDP) service is used by network devices for advertising their identity,
capabilities, and neighbors on a IEEE 802 local area network, usually wired Ethernet.
The LLDP Configuration section allows you to configure parameters related to LLDP.
1
2
3
Parameter Description
3. Select whether to enable the LLDP-MED protocol override of the VLAN ID, User Priority and
DiffServ values in the Override Network Policy drop-down menu.
Table 51: Override Network Policy Parameters
Parameter Description
Enable The service listens for LLDP advertisements, and overrides the previously
configured VLAN ID, User Priority and DiffServ with the values received.
Disable The service only publishes its characteristics and configurations by LLDP,
and does not override anything.
The Ethernet Link Configuration section allows you to configure the MTU as well as IEEE 802.1X
authentication.
The Maximum Transmission Unit (MTU) is a parameter that determines the largest packet than can
be transmitted by an IP interface (without it needing to be broken down into smaller units). Each
interface used by TCP/IP may have a different MTU value specified. See “Appendix C - Maximum
Transmission Unit (MTU)” on page 639 for more details on MTU.
The range is from 576 to 1500 bytes. All VLAN connections use the MTU size configured on their
related Ethernet link.
Note: The MTU value applied for a PPPoE connection is the smallest of the value negotiated with the server
and the value configured here.
2. Define the IEEE 802.1x authentication protocol activation to use for a specific Ethernet link in the
corresponding 802.1x Authentication drop-down menu.
802.1X Authentication is a tag optionally added to the Ethernet frame header to specify the support
of the IEEE 802.1X Authentication. It allows getting authorization and access to secured network(s).
Table 52: 802.1x Authentication Parameters
Parameter Description
Disable The IEEE 802.1x authentication protocol is disabled on the Ethernet link interface.
Enable The IEEE 802.1x authentication protocol using the EAP-TLS authentication
method is enabled on the Ethernet link to get an access, through an IEEE 802.1x
EAP-TLS authenticator (such as an IEEE 802.1x capable network device), to
secured network(s). The Ethernet link interface remains always 'UP' whatever the
result of the IEEE 802.1x authentication.
3. Set the username used to authenticate each Ethernet link interfaces during the IEEE 802.1x EAP-
TLS authentication process in the corresponding EAP Username field.
This parameter is used only when the IEEE 802.1x authentication is enabled (802.1x Authentication
drop-down menu set to Enabled).
4. Define the IEEE 802.1x level of validation used by the device to authenticate the IEEE 802.1x EAP-
TLS peer's certificate.
This parameter also controls the criteria used to select the host certificate sent during the
authentication handshakes..
Table 53: 802.1x Certificate Validation Parameters
Parameter Description
State Description
Note: This section applies only if you are using the DHCP connection type (“Interfaces Configuration” on
page 86).
DHCP servers generally allocate a range of IP addresses for use on a network and reserve IP addresses for
specific devices using a unique identifier for each device. The Aastra unit unique identifier is its media access
control (MAC) address.
You can locate the MAC address as follows:
on the label located on the bottom side of the unit.
in the System > Information web page
you can dial the following digits on a telephone connected to the Aastra unit:
*#*1
The Aastra unit answers back with its MAC address. This applies to units with FXS interfaces. See
“General POTS Configuration” on page 160 for more details.
Aastra recommends to reserve an IP address with an infinite lease for each Aastra unit on the network.
DHCP Negotiation
The DHCP lease is negotiated according to RFC 2131 (supports the client side of the protocol) and RFC 2132
(only sections 3.3, 3.5, 3.8 and 8.3). The following paramaters are set
Table 55: DHCP Parameters
Host Name (option 12) Set according to the Host Name parameter of the Network > Host
page (“Host Configuration” on page 89). This option cannot be empty
according to RFC 2132. If the Host Name parameter is empty, the
DHCP option 12 is not sent.
Vendor Class Identifier (option 60) Set according to the System Description parameter of the System >
Information page.
Client identifier (option 61) Set according to MAC Address parameter of the System >
Information.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
You can set the speed and duplex of the Ethernet connection of the Aastra unit. The following values are
available:
Table 56: Ethernet Ports Speed and Duplex Supported
Parameter Description
A half-duplex connection refers to a transmission using two separate channels for transmission and reception,
while a full-duplex connection refers to a transmission using the same channel for both transmission and
reception.
If unknown, set the variable to Auto so that the Aastra unit can automatically detect the network speed.
Caution: Whenever you force a connection speed / duplex mode, be sure that the other device and all
other intermediary nodes used in the communication between the two devices have the same configuration.
See “Speed and Duplex Detection Issues” on page 98 for more details.
The current speed and duplex configuration is displayed in the Network > Status page under the Ethernet
Ports Status section.
Value Meaning
100 Auto
200 Half10
300 Full10
400 Half100
500 Full100
13 VLAN Parameters
This chapter describes how to create and manage dynamic VLANs on the Aastra unit.
VLAN Configuration
A virtual LAN is a network of computers that behave as if they are connected to the same wire even though
they may actually be physically located on different segments of a LAN. You can add VLANs on the Ethernet
links of the Aastra unit. You can currently add or manage up to a maximum of 16 VLANs.
Caution: When working with VLANs, take care not to cut your access to the unit, for instance by putting
the Uplink on a VLAN to which your PC does not have access and then setting the management interface
to Uplink.
To add a VLAN:
1. In the web interface, click the Network link, then the VLAN sub-link.
2 3 5 4
2. Select the Ethernet link over which the VLAN interface is built in the Link drop-down menu.
3. Set the VLAN ID used by the VLAN interface in the Id field.
This is a 12 bit field in the 802.1Q tag carrying an ID that differentiates frames containing this ID
from frames containing different IDs or no 802.1Q tag at all.
To systems supporting Ethernet 802.1Q, frames containing the same VLAN ID are considered as
belonging to the same virtual LAN, and frames containing different IDs are considered as not
belonging to the same virtual LAN, even though they use the same physical LAN.
4. Click on the button.
5. Set the default user priority value the interface uses when tagging packets in the Default User
Priority field.
You can also set specific service class values in the Quality of Service page. See “Chapter 14 -
Local QoS (Quality of Service) Configuration” on page 115 for more details.
6. Click Submit if you do not need to set other parameters.
You can also delete an existing VLAN by clicking the corresponding button.
Once you have added a VLAN, you must select this VLAN on an interface to activate it. You can do
so in the Link column of the Interface Configuration section in the Network > Interfaces page
(“Interfaces Configuration” on page 100). The VLAN is listed with the following syntax:
Link.VLAN ID
For instance, if you have added VLAN 20 on the interface eth5, it is listed as follows:
eth5.20
This chapter describes how to configure the local QoS parameters. The local QoS tags packets sent from the
Aastra unit. It does not process nor classify packets coming from the network.
Introduction
QoS (Quality of Service) features enable network managers to decide on packet priority queuing. The Dgw
v2.0 application supports the Differentiated Services (DS) field and 802.1q taggings.
The Dgw v2.0 application supports the Real Time Control Protocol (RTCP), which is used to send packets to
convey feedback on quality of data delivery.
The Dgw v2.0 application does not currently support the Voice Band Data service class. It also does not
support RSVP (Resource Reservation Protocol).
Differentiated Services (DiffServ, or DS) is a protocol for specifying and controlling network traffic by class so
that certain types of traffic – for example, voice traffic, which requires a relatively uninterrupted flow of data,
might get precedence over other kinds of traffic.
DiffServ replaces the first bits in the ToS byte with a differentiated services code point (DSCP). It uses the
existing IPv4 Type of Service octet.
It is the network administrator’s responsibility to provision the Aastra unit with standard and correct values.
2
3
2. Set the default Differentiated Services value used by the unit for all generated packets in the Default
DiffServ (IPv4) field.
You can override this value by setting specific service class values. See “Specific Service Class
Configuration” on page 103 for more details.
This 8-bit value is directly set in the TOS field (2nd byte) of the header of transmitted IPv4 packets,
allowing you to use either DiffServ or TOS mapping.
The DiffServ value is 1 octet scalar ranging from 0 to 255. The DSCP default value should be
101110. This results in the DS field value of 10111000 (184d). This default value would result in a
value of “101” precedence bits, low delay, high throughput, and normal reliability in the legacy IP
networks (RFC 791, RFC 1812). Network managers of legacy IP networks could use the above-
mentioned values to define filters on their routers to take advantage of priority queuing. The default
value is based on the Expedited Forwarding PHB (RFC 2598) recommendation.
Note: RFC 3168 now defines the state in which to set the two least significant bits in the TOS byte. On the
other hand, this RFC only applies to TCP transmissions and the bits are thus set to “0” in the Aastra unit.
This has the following effects:
• The TOS values for UDP packets are the same as in the MIB.
• The TOS values for TCP packets are equal to the closest multiple of 4 value that is not greater than the
value in the MIB.
You can find references on DS field under the IETF working group DiffServ. For more information,
please refer to the following RFC documents:
• Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
(RFC 2474)
• An Architecture for Differentiated Services (RFC 2475)
• Assured Forwarding PHB Group (RFC 2597)
• An Expedited Forwarding PHB (RFC 2598)
3. Set the Default Traffic Class value used by the unit for all generated IPv6 packets in the Default
Traffic Class (IPv6) field.
Specific service class values may be set in the Service Classes table. See “Specific Service Class
Configuration” on page 103 for more details.
The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or
forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets.
4. Click Submit if you do not need to set other parameters.
IEEE 802.1q
The 802.1q standard recommends the use of the 802.1q VLAN tags for Ethernet frames traffic prioritization.
VLAN tags are 4-byte headers in which three bits are reserved for priority indication. The values of the priority
bits shall be provisioned.
The 802.1q standard comprises the 802.1p standard.
It is the network administrator’s responsibility to provision the Aastra unit with standard and correct values.
You can override the default value set in the DiffServ and 802.1q sections for each service class of the Aastra
unit:
Signalling
Voice
T.38
IP Sync (IP Sync is not available in IPv6)
See “Differentiated Services (DS) Field” on page 101 for more details.
2. Set the Default Traffic Class value used in IPv6 packets for each class in the Traffic Class (IPv6)
column.
The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or
forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets.
3. Set a specific user priority for each class in the User Priority column.
See “IEEE 802.1q” on page 103 for more details.
4. Click Submit if you do not need to set other parameters.
You can apply a bandwidth limitation on the network interfaces. The limitations are applied on raw data on the
physical link and not only on the payload of the packets. All headers, checksums and control bits (TCP, IP,
CRC, etc.) are considered in the actual bandwidth.
A bandwidth limitation is applied on a physical link and not on a high-level network interfaces. All high-level
network interfaces (including VLANs) using the same physical link are affected by a configured limitation. This
limitation is applied egress only (outgoing traffic).
If the NTC service is stopped, this section is not displayed in the QoS page. See “Chapter 4 - Services” on
page 53 on information on how to start the service. Starting the NTC service enables Traffic Shaping even if
bandwidth limitation is disabled.
Bandwidth limitation is an average of the amount of data sent per second. It is thus normal that the unit sends
a small burst of data after a period of silence.
Note that the NTC service sends packets on the physical link according to their respective priorities as
described below. Lower priority packets are dropped first.
Table 58: Physical Link Priorities
Priority Description
1 Highest priority. Packets originating from the unit with 802.1p priority set to 7.
2 Packets originating from the unit with 802.1p priority set to 6.
3 Packets originating from the unit with 802.1p priority set to 5.
4 Packets originating from the unit with 802.1p priority set to 4.
5 Packets originating from the unit with 802.1p priority set to 3.
6 Packets originating from the unit with 802.1p priority set to 2.
7 Packets originating from the unit with 802.1p priority set to 1.
8 Packets originating from the unit with 802.1p priority set to 0.
9 Lowest priority. Packets originating from another link interface (routed packets).
Packets that exceed the defined bandwidth are eventually dropped (when the buffers are exceeded). This
implies that data bursts can suffer a slight amount of packet loss. The different codecs configured and the
desired number of simultaneous channels should be taken into account when choosing a bandwidth limit to
prevent call drops, choppy voice or inconstant ptime. The NTC service can impact the execution of other
processes if the number of packets to process is too high. (High traffic and/or low limit).
This value must be set according to the upstream bandwidth limit of the network on this link. Set to
0 (disable) if the network bandwidth exceeds 40960 kbps or if it exceeds the effective limit of this
device.
The local firewall allows you to dynamically create and configure rules to filter packets. The traffic is analyzed
and filtered by all the rules configured.
Note: The Aastra unit’s local firewall settings do not support IPv6. See “IPv4 vs. IPv6” on page 85 for more
details.
Since this is a local firewall, rules apply only to incoming packets with the unit as destination.
Incoming packets for an IP communication established by the unit are always accepted (Example : If the
Aastra unit sends a DNS request, the answer will be accepted).
Rules priority is determined by their position in the table.
The maximum number of rules allowed in the configuration is 20.
Caution: Enabling the local firewall and adding rules has an impact on the Aastra unit’s overall
performance as the firewall requires additional processing. The more rules are enabled, the more overall
performance is affected. Furthermore, Aastra recommends to use a 30 ms packetization time when the
firewall is enabled (instead of a 20 ms ptime, for instance) in order to simultaneously use all the channels
available on the unit.
Partial Reset
When a partial reset is triggered and the firewall is enabled, the configuration is rolled back if it was being
modified. A new rule is then automatically applied in the firewall to allow access to the 'Rescue' interface.
However, if the firewall is disabled, the configuration is rolled back but no rule is added.
2. In the Local Firewall Configuration section, define the Default Policy drop-down menu.
Table 59: Default Policy Parameters
Parameter Description
Caution: Make sure there are some rules with the Action parameter set to Accept in the local firewall
BEFORE applying changes that set the default policy to Drop. If you do not comply with this warning, you
will lose contact with the unit and a partial or factory reset will be required.
Setting the default policy to Drop or adding a rule automatically enables the local firewall. Enabling
the local firewall may have a negative impact on performance.
• If you want to add a rule at the end of the existing rows, click the button at the
bottom right of the section.
Note: When you add a new rule, edit an existing rule, or delete a rule, you can see a yellow Yes in the
Config Modified section at the top of the window. It warns you that the configuration has been modified but
not applied (i.e., the Firewall section of the Status page differs from the Local Firewall). The Local Firewall
sub-menu is a working area where you build up a local firewall configuration. While you work in this area,
the configured parameters are saved but not applied (i.e., they are not used to filter incoming packets). The
yellow Yes flag warns you that the configuration has been modified but is not applied.
2. Set the current activation state for this rule in the corresponding Activation drop-down menu.
Table 60: Firewall Rule Activation State Parameters
Parameter Description
Parameter Description
address[/mask] Can either be a network IP address (using /mask) or one of the host
IP addresses. The mask must be a plain number specifying the
number of binary 1s at the left side of the network mask (a mask of
24 specifies a network mask of 255.255.255.0).
networkInterfaceName The value must already exist in the Interface Configuration table
/ (see “Interfaces Configuration” on page 100 for more details). The
interface name is case sensitive, hence it must be entered properly.
If the specified network interface is disabled or removed, the rule is
automatically disabled thus removed from the firewall. When the
network interface is enabled or added back, the rule is automatically
enabled and applied in the firewall.
Note: It is mandatory to use the suffix “/” to indicate that the network
address of this interface is used instead of the host address.
Parameter Description
Parameter Description
networkInterfaceName The host address of this interface is used. The value must already
exist in the Interface Configuration table (see “Interfaces
Configuration” on page 100 for more details). The interface name is
case sensitive, hence it must be entered properly.
If the specified network interface is disabled or removed, the rule is
automatically disabled thus removed from the firewall. When the
network interface is enabled or added back, the rule is automatically
enabled and applied in the firewall.
Parameter Description
Parameter Description
Note that if a connection is already established before creating a rule that rejects it, this connection
stays active despite the rule applied.
9. Click the Apply button to activate the enabled rules.
The current enabled rules applied are displayed in the Network > Status web page, Firewall section,
which contains the active configuration in the firewall. You can also see that the yellow Config
Modified Yes flag is cleared.
When the local firewall is enabled, it has an impact on the Aastra unit’s overall performance as the firewall
requires CPU power. You can disable the firewall if you do not need it, thus not impacting performance.
16 IP Routing Configuration
This chapter describes how to configure the IP Routing parameters of the Aastra unit.
IPv4 Forwarding
Creating/editing an IP routing rule
Moving an IP routing rule
Deleting an IP routing rule
IP routing examples
Managing IP Routing
The IP Routing service allows the Aastra unit to perform advanced routing based on the packet’s criteria
(source IP address and source Ethernet link), which allows the packet to be forwarded to a specific network.
You can create up to four advanced IP routes.
Note: The Aastra unit’s IP Routing settings do not support IPv6. See “IPv4 vs. IPv6 Availability” on page 85
for more details.
Packets matching a list of criteria should1 use advanced IP routes instead of routes present in the main routing
table of the unit.
IP Routing works together with the following services:
Network Firewall (“Chapter 17 - Network Firewall Configuration” on page 135)
NAT (“Chapter 18 - NAT Configuration” on page 141)
DHCP server (“Chapter 19 - DHCP Server Settings” on page 149)
Network Traffic Control (“Network Traffic Control Configuration” on page 118)
These services must be properly configured.
When the IP Routing service is started, IP routing is activated even if there is no configured rule (the Aastra
unit will forward received packets). If the IP Routing service is stopped, IP forwarding is disabled, this tab is
greyed out and the parameters are not displayed. See “Chapter 4 - Services” on page 53 on information on
how to start the service.
Caution: Enabling the IP routing service and adding rules has an impact on the Aastra unit’s overall
performance as IP routing requires additional processing. The more rules are enabled, the more overall
performance is affected. Furthermore, Aastra recommends to use a 30 ms packetization time when IP
routing is enabled (instead of a 20 ms ptime, for instance) in order to simultaneously use all the channels
available on the unit.
IPv4 Forwarding
IPv4 forwarding allows you to control the IPv4 forwarding feature and the Advanced IP Routes. When set to
Enabled, IPv4 Forwarding is enabled and the Advanced IP Routes are applied. When set to Disabled, IPv4
Forwarding is disabled and the Advanced IP Routes are not applied (the Advanced IP Routes section of the
IP Routing page is disabled).
1. A packet matching a route uses the custom routing table first and then the main routing table if no route in the custom routing table was
able to send the packet to the desired destination IP address.
3. Click the Submit & Apply button to update the Network > Status web page.
• If you want to add a rule at the end of the existing rows, click the button at the
bottom right of the section.
Note: When you add a new rule, edit an existing rule or delete a rule, you can see a yellow Yes in the Config
Modified section at the top of the window. It warns you that the configuration has been modified but not
applied (i.e., the Advanced IP Routes section of the Status page differs from the IP Routing page). The IP
Routing sub-menu is a working area where you build up a routing configuration. While you work in this area,
the configured parameters are saved but not applied (i.e., they are not used to route packets). The yellow
Yes flag warns you that the configuration has been modified but is not applied.
2. Set the required state for this rule in the corresponding Activation drop-down menu.
Table 65: IP Routing Rule Activation Parameters
Parameter Description
Syntax Description
Note: You can revert back to the configuration displayed in the Status web page at any time (including the
disabled rules) by clicking the Rollback button at the bottom of the page. All modified settings in the IP
Routing page will be lost.
• If you want to delete an existing route, click the button of the route you want to
move.
Protocol Description
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
You can define whether or not the Classless Static Route Option is enabled. Static routes can be configured
through the Classless Static Route Option for DHCPv4 (option 121) defined in RFC 3442.
If a static route to 0.0.0.0/0 is received through option 121 while a default router is also specified (see “Default
Gateway Configuration” on page 91 for more details), the route received through option 121 has priority.
The following values are available:
Table 68: DHCPv4 Classless Static Route Option Parameters
Parameter Description
Request The device requests the Classless Static Route Option 121.
None Routes received from the DHCP server are ignored.
To define define whether or not the Classless Static Route Option is enabled:
1. In the bniMIB, locate the DhcpClientGroup folder.
2. Set the dhcpClientClasslessStaticRouteOption variable with the proper behaviour.
You can also use the following line in the CLI or a configuration script:
bni.dhcpClientClasslessStaticRouteOption="Value"
Value Meaning
100 None
200 Request
The following are two examples of advanced IP routing that can be accomplished with the Aastra unit.
Forward Packets from the Lan1 Network to the Uplink Network with NAT
1. Create an IP routing rule so that the packets are routed (“Managing IP Routing” on page 113).
• Source IP: Lan1/
Remove this criterion if you want to forward all packets received on the lan link.
• Source Link: lan2
• Destination Network: Uplink
• Click Submit & Apply.
2. The source link name may vary depending on the unit model you have.
2. Create a NAT rule so that the forwarded packets going on the Uplink network use the correct source
IP address (“Creating/Editing a Source NAT Rule” on page 141).
• Type: SNAT
• Source IP: Lan1/
• Protocol: All
• New Address: Uplink
• Click Submit & Apply.
3. Create a Network Firewall rule to let established or related packets go through the unit (if the default
policy is not set to Accept) (“Managing the Network Firewall” on page 135).
• Connection State: Established or Related
• Action: Accept
4. Create a Network Firewall rule to let the packets pass from the Lan1 network to the Uplink network
(if the default policy is not set to Accept). All response packets will be accepted by the previous rule
(“Managing the Network Firewall” on page 135).
• Source IP: Lan1/
Use additional rules or set the default policy to Accept if you want to forward packets
received on the lan link with a source address that does not match the Lan1 subnet.
• Connection State: New
• Action: Accept
• Click Submit & Apply.
5. Create a Network Firewall rule to let the packets pass from the Uplink network to the Lan1 network
(if the default policy is not set to Accept). All response packets will be allowed by the previous rule
(“Managing the Network Firewall” on page 135).
• Destination IP: 192.168.0.11
• Destination Port: 80
• Protocol: TCP
• Action: Accept
• Click Submit & Apply.
The network firewall allows dynamically creating and configuring rules to filter packets forwarded by the unit.
Since this is a network firewall, rules only apply to packets forwarded by the unit. The traffic is analyzed and
filtered by all the rules configured.
Note: The Aastra unit’s network firewall settings do not support IPv6. See “IPv4 vs. IPv6 Availability” on
page 85 for more details.
If no rule matches the incoming packet, the default policy is applied. A rule's priority is determined by its index
in the table.
Rules using Network Names are automatically updated as the associated IP addresses and network mask are
modified.
If the Network Firewall service is stopped, all forwarded traffic is accepted, this tab is greyed out and the
parameters are not displayed. See “Chapter 4 - Services” on page 53 on information on how to start the
service.
The maximum number of rules allowed in the configuration is 20.
Caution: Enabling the network firewall and adding rules has an impact on the Aastra unit’s overall
performance as the firewall requires additional processing. The more rules are enabled, the more overall
performance is affected. Furthermore, Aastra recommends to use a 30 ms packetization time when the
firewall is enabled (instead of a 20 ms ptime, for instance) in order to simultaneously use all the channels
available on the unit.
2. In the Network Firewall Configuration section, define the default policy in the Default Policy drop-
down menu.
Table 70: Default Policy Parameters
Parameter Description
Setting the default policy to Drop or adding a rule automatically enables the network firewall.
Enabling the network firewall may have a negative impact on performance.
• If you want to add a rule at the end of the existing rows, click the button at the
bottom right of the section.
Note: When you add a new rule, edit an existing rule or delete a rule, you can see a yellow Yes in the Config
Modified section at the top of the window. It warns you that the configuration has been modified but not
applied (i.e., the Firewall section of the Status page differs from the Network Firewall page). The Network
Firewall page is a working area where you build up a network firewall configuration. While you work in this
area, the configured parameters are saved but not applied (i.e., they are not used to filter packets). The
yellow Yes flag warns you that the configuration has been modified but is not applied.
2. Set the required state for this rule in the corresponding Activation drop-down menu.
Table 71: Firewall Rule Activation Parameters
Parameter Description
Syntax Description
Syntax Description
Parameter Description
8. Set the corresponding Connection State drop-down menu with the connection state associated with
the incoming packet.
The connection state can be one of the following:
Table 75: Connection State Parameters
State Description
State Description
Parameter Description
Note that if a connection is already established before creating a rule that rejects it, this connection
stays active despite the rule applied.
10. Click the Apply button to activate the enabled rules.
The current enabled rules applied are displayed in the Network > Status web page, which contains
the active configuration in the network firewall. You can also see that the yellow Config Modified
Yes flag is cleared.
Note: You can revert back to the configuration displayed in the Network > Status web page at any time
(including the disabled rules) by clicking the Rollback button at the bottom of the page. All modified settings
in the Network > Network Firewall page will be lost.
When the network firewall is enabled, it has an impact on the Aastra unit’s overall performance as the firewall
requires additional processing. You can disable the firewall if you do not need it, thus not impacting
performance. To disable the network firewall, you must stop the NFW service in the System > Services page.
See “Chapter 4 - Services” on page 53 for more details on how to stop a service. All forwarded traffic is allowed
when the network firewall service is stopped.
18 NAT Configuration
This chapter describes how to configure the NAT parameters of the Aastra unit.
Creating/editing a Source NAT
Creating/editing a Destination NAT
Moving a NAT rule
Deleting a NAT rule
Introduction
Network Address Translation (NAT, also known as network masquerading or IP masquerading) rewrites the
source and/or destination addresses/ports of IP packets as they pass through a router or firewall. It is most
commonly used to connect multiple computers to the Internet (or any other IP network) by using one IP
address. This allows home users and small businesses to cheaply and efficiently connect their network to the
Internet. The basic purpose of NAT is to multiplex traffic from the internal network and present it to the Internet
as if it was coming from a single computer having only one IP address.
The Aastra unit’s NAT service allows the dynamic creation and configuration of network address translation
rules. Depending on some criteria, the packet matching the rule may see its source or destination address
modified.
There are two types of NAT rules:
Source rules: They are applied on the source address of outgoing packets.
Destination rules: They are applied on the destination address of incoming packets.
A rule's priority is determined by its index in the Source NAT or Destination NAT tables.
If the NAT service is stopped, this tab is greyed out and the parameters are not displayed. See “Chapter 4 -
Services” on page 53 on information on how to start the service.
The maximum number of rules allowed in the configuration is 10 of each Source NAT and Destination NAT.
Caution: Adding source or destination NAT rules has an impact on the Aastra unit’s overall performance
as the NAT requires additional processing. The more rules are enabled, the more overall performance is
affected. Furthermore, Aastra recommends to use a 30 ms packetization time when the NAT is enabled
(instead of a 20 ms ptime, for instance) in order to simultaneously use all the channels available on the unit.
Partial Reset
When a partial reset is triggered, the configuration is rolled back if it was being modified.
A new rule is then automatically applied in the source and in the destination NAT tables to prevent incorrect
rules from blocking access to the unit. If those rules are not the first priority, they are raised. If there are no
rules in the tables, the new rules are not added since there are no rules to override.
SNAT rules are executed after the routing decision, before the packet leaves the unit.
The web interface allows you to create a source NAT rule or modify the parameters of an existing one. The
following parameters must all match to apply a SNAT rule to a packet:
Source Address
Source Port
Destination Address
Destination Port
Protocol
When the above parameters all match, then a new source IP address/port is applied to the packet.
3 4 5 6 7 8 9
2. In the Source Network Address Translation Rules section of the NAT page, do one of the following:
• If you want to add a rule before an existing entry, locate the proper row in the table and
click the button of this row.
• If you want to add a rule at the end of the existing rows, click the button at the
bottom right of the section.
Note: When you add a new rule, edit an existing rule or delete a rule, you can see a yellow Yes in the Config
Modified section at the top of the window. It warns you that the configuration has been modified but not
applied (i.e., the Network Address Translation section of the Status page differs from the NAT page). The
NAT page is a working area where you build up a NAT configuration. While you work in this area, the
configured parameters are saved but not applied (i.e., they are not used in the NAT). The yellow Yes flag
warns you that the configuration has been modified but is not applied.
3. Set the required state for this rule in the corresponding Activation drop-down menu.
Table 77: Source NAT Rule Activation Parameters
Parameter Description
Syntax Description
Syntax Description
Syntax Description
networkInterfaceName/ The host address of this interface is used. The value must already
exist in the Interface Configuration table (see “Interfaces
Configuration” on page 100 for more details). The interface name
is case sensitive, hence it must be entered properly.
If the specified network interface is disabled or removed, the rule
is automatically disabled thus removed from the NAT. When the
network interface is enabled or added back, the rule is
automatically enabled and applied in the Source NAT. For
instance:
• Lan1/ (Lan1 network address)
Note: It is mandatory to use the suffix “/” to indicate that the
network address of this interface is used instead of the host
address.
Parameter Description
9. Enter the new address applied to the source of the packet in the New Address field.
Use the following syntax:
Table 81: New Address Syntax
Syntax Description
Note: You can revert back to the configuration displayed in the Status web page at any time (including the
disabled rules) by clicking the Rollback button at the bottom of the page. All modified settings in the NAT
page will be lost.
The web interface allows you to create a Destination NAT rule or modify the parameters of an existing one.
This creates a rule that allows remote computers (e.g., public machines on the Internet) to connect to a specific
computer within the private LAN, depending on the port used to connect. A destination NAT is also known as
port forwarding or virtual server.
DNAT rules are executed before the routing decision, as the packet enters the unit. Therefore it is important
to configure the Network Firewall (“Chapter 17 - Network Firewall Configuration” on page 135) with respect to
the DNAT rules. An example of this would be port forwarding where the DNAT changes the routed address of
a packet to a new IP address/port. The Network Firewall must also accept connection to this IP/port in order
for the port forwarding to work.
The following parameters must all match to apply a DNAT rule to a packet:
Source Address
Source Port
Destination Address
Destination Port
Protocol
When the above parameters all match, then a new destination IP address/port is applied to the packet.
• If you want to add a rule at the end of the existing rows, click the button at the
bottom right of the section.
Note: When you add a new rule, edit an existing rule, or delete a rule, you can see a yellow Yes in the
Config Modified section at the top of the window. It warns you that the configuration has been modified but
not applied (i.e., the Network Address Translation section of the Status page differs from the NAT page).
The NAT page is a working area where you build up a NAT configuration. While you work in this area, the
configured parameters are saved but not applied (i.e., they are not used in the NAT). The yellow Yes flag
warns you that the configuration has been modified but is not applied.
2. Set the required state for this rule in the corresponding Activation drop-down menu.
Table 82: Destination NAT Rule Activation Parameters
Parameter Description
Syntax Description
Syntax Description
Syntax Description
networkInterfaceName[/] The host address of this interface is used. The value must already
exist in the Interface Configuration table (see “Interfaces
Configuration” on page 100 for more details). The interface name
is case sensitive, hence it must be entered properly.
If the specified network interface is disabled or removed, the rule
is automatically disabled thus removed from the NAT. When the
network interface is enabled or added back, the rule is
automatically enabled and applied in the Destination NAT. For
instance:
• Lan1 (Lan1 IP address)
• Lan1/ (Lan1 network address)
Parameter Description
8. Enter the new address of the packet in the New Address field.
Use the following syntax:
Table 86: New Address Syntax
Syntax Description
Note: You can revert back to the configuration displayed in the Network > Status web page at any time
(including the disabled rules) by clicking the Rollback button at the bottom of the page. All modified settings
in the Network > NAT page will be lost.
The NAT rules sequence is very important because only one SNAT rule or one DNAT rule is applied on a
packet. Rules priority is determined by their position in the table. If you want the unit to try to match one rule
before another one, you must put that rule first.
You can delete a rule from the table in the web interface.
When the NAT is enabled, it has an impact on the Aastra unit’s overall performance as the NAT requires
additional processing. You can disable the NAT if you do not need it, thus not impacting performance. To
disable the NAT, you must stop the NAT service in the System > Services page. See “Chapter 4 - Services”
on page 53 for more details on how to stop a service.
This chapter describes how to configure the embedded DHCP server of the Aastra unit.
Introduction
The Aastra unit contains an embedded DHCP server that allocates IP addresses and provides leases to the
various subnets that are configured. These subnets could have PCs or other IP devices connected to the unit’s
LAN Ethernet connectors. These devices could be any combination of switches, PCs, IP phones, etc.
If the DHCP service is stopped, this tab is greyed out and the parameters are not displayed. See “Chapter 4 -
Services” on page 53 on information on how to start the service.
Note: The Aastra unit’s DHCP server settings do not support IPv6. See “IPv4 vs. IPv6” on page 85 for more
details.
Subnet Server
The DHCP server manages the hosts’ network configuration on a given subnet. Each subnet can be seen as
having a distinct DHCP server managing it, which is called a subnet server. To activate a subnet server for a
given network interface, the name of that network interface and the name of the subnet configuration must
match (the names are case sensitive). Only one subnet can be defined per network interface. The network
interface can be a physical interface or a logical interface (e.g., sub-interface using VLAN).
Leases
In order to assign leases, the subnet server draws from an IP address pool (or subnet scope) defined by a
start address and an end address. The subnet mask assigned to hosts is taken directly from the network
interface. All hosts on the same subnet share the same configuration. The maximum number of hosts
supported on a subnet is 254.
You can reserve IP addresses for specific hosts that are designated by their MAC address. Those addresses
are then removed from the pool of IP addresses that can be leased. Once a lease is assigned, it is removed
from the pool of IP addresses that can be leased for as long as the host keeps it.
Configuration Parameters
When an address is leased to a host, several network configuration parameters are sent to that host at the
same time according to the options found in the DHCP request. You can modify the configuration source of a
parameter. The following are the possible configuration sources:
Table 87: Parameter Configuration Sources
Source Description
Source Description
The following table lists the configuration parameters and their available configuration sources:
Table 88: Optional Parameter and Possible Configuration Sources
Configuration Sources
Parameter Name
Static Automatic Host Config Host Interface
Domain Name
Lease time
Default gateway
List of DNS servers
List of NTP servers
List of NBNS servers
The basic configuration parameters are available only on the specific subnets configuration.
3
4
5
4. Set the start and end IP addresses of the subnet range in the Start IP Address and End IP Address
fields.
These are the addresses that the DHCP server offers to the subnets of the Aastra unit. The Aastra
unit can offer up to 254 addresses. These addresses must be within the network interface’s subnet
or the subnet server will have an invalid configuration status.
5. Set the Automatic Configuration Interface drop-down menu with the network interface that provides
the automatic configuration (e.g.: DNS servers, NTP server, etc.) to all parameters of this subnet
that use the "Automatic" configuration source.
6. Click Submit if you do not need to set other parameters.
The Aastra unit DHCP server offers a lease time to its subnets. You can use a default lease time for all subnets
or define a lease time specific to one or more subnets.
1
2
2. Define the lease time (in seconds) given by the Aastra unit DHCP server in the Lease Time field.
3. Click Submit if you do not need to set other parameters.
The Aastra unit DHCP server offers a domain name to its subnets. You can use a default domain name for all
subnets or define a domain name specific to one or more subnets.
1
2
3
4
2. Define whether or not you want to override the domain name parameters set in the Default
configuration in the Subnet Specific Value drop-down menu.
This menu is available only in the specific subnets configuration.
3. If the domain name option is enabled, select the configuration source of the domain name
information in the Configuration Source drop-down menu.
Table 89: Domain Name Configuration Sources
Source Description
4. If the configuration source is Static, enter the static default domain name for all subnets in the
Domain Name field.
5. Click Submit if you do not need to set other parameters.
The Aastra unit DHCP server offers a default gateway (also called default router) to its subnets.
Note: The default gateway parameters are not available in the Default interface. You must access the
specific subnets configuration to set its parameters.
1
2
3
2. Select the configuration source of the default gateway information in the Configuration Source drop-
down menu.
Table 90: Default Gateway Configuration Sources
Source Description
Host Interface The default gateway is the host address within the client's subnet.
Static You manually enter the value.
3. If the configuration source is Static, enter the default gateway host name or IP address of the
subnet in the Default Gateway field.
4. Click Submit if you do not need to set other parameters.
DNS (Option 6)
The Aastra unit DHCP server offers up to four DNS addresses to its subnets. You can use the default DNS
addresses for all subnets or define static DNS addresses specific to one or more subnets.
1
2
3
2. Define whether or not you want to override the default values in the Subnet Specific drop-down
menu.
This menu is available only in the specific subnets configuration.
3. Select the configuration source of the DNS information in the Configuration Source drop-down
menu.
Table 91: DNS Configuration Sources
Source Description
Host The DNS servers are obtained from the host configuration.
Configuration
Automatic The DNS servers are automatically obtained from the network configured in the
Automatic Configuration Interface drop-down menu of this subnet (“DHCP
Basic Configuration” on page 137).
Static You manually enter the value.
4. If the configuration source is Static, enter the static addresses of up to four DNS servers in the
following fields:
• Primary DNS
• Secondary DNS
• Third DNS
• Fourth DNS
5. Click Submit if you do not need to set other parameters.
The Aastra unit DHCP server offers the addresses of up to four NTP (Network Time Protocol) servers to its
subnets. You can use the default NTP addresses for all subnets or define static DNS addresses specific to
one or more subnets.
1
2
3
2. Define whether or not you want to override the default values in the Subnet Specific drop-down
menu.
This menu is available only in the specific subnets configuration.
3. Select the configuration source of the NTP information in the Configuration Source drop-down
menu.
Table 92: NTP Configuration Sources
Source Description
Host The NTP servers are obtained from the host configuration.
Configuration
Automatic The NTP servers are automatically obtained from the network configured in the
Automatic Configuration Interface drop-down menu of this subnet (“DHCP
Basic Configuration” on page 137).
Static You manually enter the value.
4. If the configuration source is Static, enter the static addresses of up to four NTP servers in the
following fields:
• Primary NTP
• Secondary NTP
• Third NTP
• Fourth NTP
5. Click Submit if you do not need to set other parameters.
The NetBIOS Name Server (NBNS) protocol, part of the NetBIOS over TCP/IP (NBT) family of protocols, is
implemented in Windows systems as the Windows Internet Name Service (WINS). By design, NBNS allows
network peers to assist in managing name conflicts.
The Aastra unit DHCP server offers up to four NBNS addresses to its subnets. You can use the default NBNS
addresses for all subnets or define static NBNS addresses specific to one or more subnets.
1
2
2. Define whether or not you want to override the default values in the Subnet Specific drop-down
menu.
This menu is available only in the specific subnets configuration.
3. Enter the static addresses of up to four NBNS servers in the following fields:
• Primary NBNS
• Secondary NBNS
• Third NBNS
• Fourth NBNS
4. Click Submit if you do not need to set other parameters.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
The embedded DHCP server leases addresses to the hosts that request it. The address is assigned to a host
for a configurable amount of time (as defined in “Lease Time (Option 51)” on page 137). The DHCP server
can service all subnets on which it is enabled.
The static IP address is added to the Static Leases Configuration section, but not to the Current
Leases section.
4. Click Submit if you do not need to set other parameters.
20 POTS Configuration
This chapter describes how to configure the POTS (Plain Old Telephony System) line service, which allows
you to configure the analog specification of each line, as well as gateways-specific parameters.
POTS Status
Line Status
The Line Status table lists the link state of the FXS lines.
The General Configuration section allows you to select the detection/generation method of caller ID.
2
3
4
2. Select the detection/generation method of caller ID in the Caller ID customization drop-down menu.
This allows selecting the detection/generation method of caller ID. See “Caller ID Information” on
page 147 for more details.
Table 93: Caller ID Parameters
Parameter Description
Country Uses the default caller ID of the country defined in the Country section of the
Telephony > Misc page (“Country Configuration” on page 451).
EtsiDtmf ETSI 300 659-1 (DTMF string sent between the first and second ring).
EtsiFsk ETSI 300 659-1 (FSK (V.21) sent between the first and second ring).
3. Select the caller ID transmission method in the Caller ID Transmission drop-down menu.
It allows selecting the transmission type of the caller ID.
Table 94: Caller ID Transmission Parameters
Parameter Description
Country Uses the default caller ID of the country defined in the Country section of the
Telephony > Misc page (“Country Configuration” on page 451).
First Ring The caller ID is sent after the first ring.
Ring Pulse The caller ID is sent between a brief ring pulse and the first ring.
Line Reversal The caller ID is sent between a brief ring pulse and the first ring on an inverted
Ring Pulse polarity line.
DT-AS The caller ID is sent after the dual tone alerting state tone.
Line Reversal The caller ID is sent after the dual tone alerting state tone on an inverted
DT-AS polarity line.
No Ring Pulse The caller ID is sent before the first ring.
4. Determine the type of vocal information that can be obtained by dialing a pre-defined digit map in
the Vocal Unit Information drop-down menu.
When entering special characters on your telephone pad, the Aastra unit talks back to you with
relevant information.
Table 95: Caller ID Parameters
Parameter Description
Parameter Description
Caller ID Information
The caller ID is a generic name for the service provided by telephone utilities that supply information such as
the telephone number or the name of the calling party to the called subscriber at the start of a call. In call
waiting, the caller ID service supplies information about a second incoming caller to a subscriber already busy
with a phone call. However, note that caller ID on call waiting is not supported by all caller ID-capable
telephone displays.
In typical caller ID systems, the coded calling number information is sent from the central exchange to the
called telephone. This information can be shown on a display of the subscriber telephone set. In this case, the
caller ID information is usually displayed before the subscriber decides to answer the incoming call. If the line
is connected to a computer, caller information can be used to search in databases and additional services can
be offered.
The following basic caller ID features are supported:
Date and Time
Calling Line Identity
Calling Party Name
Visual Indicator (MWI)
Caller ID Generation
There are two methods used for sending caller ID information depending on the application and country-
specific requirements:
caller ID generation using DTMF signalling
caller ID generation using Frequency Shift Keying (FSK)
Note: The Dgw v2.0 Application does not support ASCII special characters higher than 127.
The displayed caller ID for all countries may be up to 20 digits for numbers and 50 digits for names.
DTMF Signalling
The data transmission using DTMF signalling is performed during or before ringing depending on the country
settings or endpoint configuration. The Aastra unit provides the calling line identity according to the following
standards:
Europe: ETSI 300 659-1 January 2001 (Annex B): Access and Terminals (AT); Analogue
access to the Public Switched Telephone Network (PSTN); Subscriber line protocol over the
local loop for display (and related) services; Part 1: On-hook data transmission.
FSK Generation
Different countries use different standards to send caller ID information. The Aastra unit is compatible with the
following widely used standards:
ETSI 300 659-1
Note: The compatibility of the Aastra unit is not limited to the above caller ID standards.
Continuous phase binary FSK modulation is used for coding that is compatible with:
BELL 202
ITU-T V.23
FXS Configuration
The FXS Configuration section allows you to define how a FXS endpoint behaves in certain conditions.
2
3
4
5
6
7
8
2. In the FXS Configuration section, set the Line Supervision Mode drop-down menu with the power
drop and line polarity used to signal the state of a line.
Power drop and polarity reversal are also called battery drop and battery reversal.
Table 97: Line Supervision Mode Parameters
Parameter Description
None Power drop or polarity reversal is not used to signal the state of the
line.
DropOnDisconnect Activates the Power Drop on Disconnect feature. A short power drop
is made at the end of a call when the call is disconnected by the
remote party.
The drop duration can be configured in the FXS Power Drop on
Disconnect Duration field (Step 5).
Parameter Description
ReversalOnIdle Activates the Polarity Reversal on Idle feature. The polarity of the line
is initially in reversed state. The polarity of the line returns to the
positive state when the user seizes the line or when the line rings for
an incoming call. The polarity of the line is reversed again when the
call is disconnected.
ReversalOnEstablished Activates the Polarity Reversal on Established option. The polarity of
the line is initially in the positive state. The polarity of the line is
reversed when the call is established and returns to the positive state
when the call is disconnected.
3. Set the Disconnect Delay field with the value used to determine whether or not call clearing occurs
as soon as the called user is the first to hang up a received call.
This parameter has no effect when you are acting as the calling party.
If you set the value to 0, the call is disconnected as soon as the called user hangs up the call.
If the value is greater than 0, that value is the amount of time, in seconds, the unit waits after the
called user hangs up before signalling the end of the call.
4. Set the Auto Cancel Timeout field with the time, in seconds, the endpoint rings before the call is
automatically cancelled.
Setting this variable to 0 disables the timeout. Calls will not be automatically cancelled and will ring
until the party answers.
5. Set the Inband Ringback drop-down menu to define whether or not the FXS endpoint needs to
generate a ringback for incoming ringing call.
Table 98: Inband Ringback Parameters
Parameter Description
Disable The FXS endpoint does not play local ringback to the remote party.
Enable The FXS endpoint plays local ringback to the remote party via the negotiated
media stream. The local ringback is generated only when the telephone is on-
hook. The FXS ports never play the local ringback for the call waiting.
6. Set the Shutdown Behavior drop-down menu with the FXS endpoint behavior when it becomes shut
down.
Table 99: FXS Shutdown Behavior Parameters
Parameter Description
Disabled A disabled tone is played when the user picks up the telephone and the FXS
Tone endpoint is shut down.
Power The loop current is interrupted when the FXS endpoint is shut down and no tone is
Drop played when the user picks up the telephone.
A FXS endpoint becomes shut down when the operational state of the endpoint becomes Disabled
and the Shutdown Endpoint When Operational State is 'Disable' And Its Usage State Is 'idle-
unusable' parameter of the SIP > Endpoints page is set to Enable. See “Administration” on page 68
for more details.
This parameter is not used by FXS endpoints used for bypass when the Activation column of the
FXS Bypass section is set to Endpoint Disabled. See “FXS Bypass” on page 167 for more details.
7. Set the Power Drop on Disconnect Duration field with the power drop duration, in milliseconds, that
is made at the end of a call when the call is disconnected by the remote party.
This value only has an effect when the Line Supervision Mode drop-down menu is set to
DropOnDisconnect.
8. Set the Service Activation drop-down menu with the method used by the user to activate
supplementary services such as call hold, second call, call waiting, call transfer and conference call.
Table 100: Service Activation Parameters
Parameter Description
The FXS Country Customization section allows you to override the current default country parameters of
certain features. Refer to “Appendix A - Country-Specific Parameters” on page 603 for the pre-defined values
for a specific country.
1
2
3
Parameter Description
2. Set the Country Override Loop Current field with the loop current generated by the FXS port in ma.
When a remote end-user goes on-hook, the Aastra unit signals the far end disconnect by performing
a current loop drop (< 1 mA) on the analog line. This current loop drop, also referred to as “Power
Denial” mode, is typically used for disconnect supervision on analog lines. The Aastra unit maintains
a current drop for one second (this value cannot be configured), then a busy tone is generated to
indicate the user to hang up. See the description for the FXS Line Supervision Mode drop-down
menu in “FXS Configuration” on page 148 for more details.
When one of its analog lines goes off-hook, the Aastra unit controls the endpoint in a fixed loop
current mode. When selecting a country (see “Country Configuration” on page 451 for more details),
each country has a default loop current value. However, you can override this value and define your
own loop current.
Note that the actual measured current may be different than the value you set, because it varies
depending on the DC impedance.
3. Set the Country Override Flash Hook Detection Range field.
This is the range in which the hook switch must remain pressed to perform a flash hook.
When selecting a country (see “Country Configuration” on page 451 for more details), each country
has a default minimum and maximum time value. However, you can override these values and
define your own minimum and maximum time within which pressing and releasing the plunger is
actually considered a flash hook.
The range consists of the minimal delay and maximal delay, in ms, separated by a “-”. The minimal
value allowed is 10 ms and the maximum value allowed is 1200 ms. The space character is not
allowed.
Flash hook can be described as quickly depressing and releasing the plunger in or the actual
handset-cradle to create a signal indicating a change in the current telephone session. Services
such as picking up a call waiting, second call, call on hold, and conference are triggered by the use
of the flash hook.
A flash hook is detected when the hook switch is pressed for a shorter time than would be required
to be interpreted as a hang-up.
Using the “flash” button that is present on many standard telephone handsets can also trigger a
flash hook.
4. Click Submit if you do not need to set other parameters.
1. In the potsMIB, specify the Calling Party Name of the caller ID (CLIP) when the calling party is
tagged as private in the FxsCallerIdPrivateCallingPartyName variable.
You can also use the following line in the CLI or a configuration script:
pots.FxsCallerIdPrivateCallingPartyName="Value"
21 SIP Gateways
This chapter describes how to add and remove SIP gateways in the Aastra unit.
Multiple SIP gateways may be used for a number of reasons, such as:
Redirecting ISDN calls to different SIP servers depending on the call.
Hunt calls across several gateways.
Adding a SIP gateway triggers a warning message if the total number of registrations configured reached the
defined limit. See “Number of Registrations” on page 293 for more details.
2 3 4 5 6
You can add a new gateway by clicking the button. The Aastra unit supports a maximum of 5
gateways.
You can delete an existing gateway by clicking the button.
2. If you are adding a new gateway, enter its name in the Name field.
The Dgw v2.0 Application supports only alphanumeric characters, “-”, and “_”.
3. Select the network interface on which the gateway listens for incoming SIP traffic in the Signaling
Network drop-down menu.
This value applies to all transports (e.g., UDP, TCP, etc.).
The LAN interface may be used as a SIP gateway to be bound on the LAN. However, there is no
routing between the LAN and the uplink interface.
4. Define the list of networks (separated by ",") to use for the media (voice, fax, etc.) stream in the
Media Networks field.
You can use the Media Networks Suggestion column’s drop-down menu to select between
suggested values, if any.
The value must match one of the "InterarfaceName" values in the "NetworkInterfacesStatus" table
of the BNI service. The order in the list defines the priority.
When the media stream is negotiated, the following rules apply:
• If the list of media networks is empty,the Aastra unit uses the IP address of the network
defined in the Signaling Network drop-down menu.
• Only active networks are used.
• Only the first active network of an IP address family (IPv4, IPv6) is used. All
subsequent networks of the same IP family are ignored.
Note: When generating an offer and multiple networks are available for the media, ANAT grouping (RFC
4091) is automatically enabled. When generating an answer, the ANAT grouping state is detected form the
offer.
5. Set the SIP port on which the gateway listens for incoming unsecure SIP traffic in the Port field.
This is used only when the UDP and/or TCP transports are enabled.
If two or more SIP gateways use the same port, only the first SIP gateway starts correctly. The
others are in error and not started. The SIP gateway is also in error and not started if the port is
already used.
The default value is 0. If you set the port to 0, the default SIP port 5060 is used.
Note: The port “0” is the equivalent to the “well known port”, which is 5060 in SIP. Using 0 and 5060 is not
the same. At the SIP packets level, if you set the port to 0, it will not be present in the SIP packet. If you set
the port to 5060, it will be present in the SIP packet. For example: “[email protected]” if the port is 0 and
“[email protected]:5060” if the port is 5060.
6. Set the SIP port on which the gateway listens for incoming secure SIP traffic in the Secure Port field.
This is used only when the TLS transport is enabled.
The default value is 0. If you set the port to 0, the default secure SIP port 5061 is used.
Note: The port “0” is the equivalent to the “well known port”, which is 5061 in SIP for TLS. Using 0 and 5061
is not the same. At the SIP packets level, if you set the port to 0, it will not be present in the SIP packet. If
you set the port to 5061, it will be present in the SIP packet. For example: “[email protected]” if the port is 0 and
“[email protected]:5061” if the port is 5061.
State Description
State Description
22 SIP Servers
This chapter describes how to configure the SIP server parameters of the Aastra unit.
Introduction
Server Description
Registrar Server Accepts REGISTER requests and places the information it receives in those
requests into the location service for the domain it handles.
Proxy Server An intermediary program that acts as both a server and a client for the purpose of
making requests on behalf of other clients. A proxy server primarily plays the role
of routing, which means its job is to ensure that a request is passed on to another
entity that can further process the request. Proxies are also useful for enforcing
policy and for firewall traversal. A proxy interprets, and, if necessary, rewrites
parts of a request message before forwarding it.
Outbound Proxy Server An intermediary entity that acts as both a server and a client for the purpose of
making requests on behalf of other clients. The outbound proxy receives all
outbound traffic and forwards it. Incoming traffic may or may not go through the
outbound proxy. The outbound proxy’s address is never used in the SIP packets,
it is only used as a physical network destination for the packets.
When the outbound proxy is enabled, the proxy is still used to create the To and
From headers, but the packets are physically sent to the outbound proxy.
Messaging Server Host A Messaging system host is a server that accepts MWI SUBSCRIBE requests
and places the information it receives in those requests into the location service
for the domain it handles.
The TLS Persistent Connections Status table allows you to browse the status of the TLS persistent
connections of the Aastra unit. These connections are associated with the SIP servers (outbound proxy,
registrar and home domain proxy). Note that this section is not displayed if there is no information to show.
Parameter Description
This section describes how to configure the IP address and port number of the SIP servers.
If any of the SIP servers parameters corresponds to a domain name that is bound to a SRV record, the
corresponding port must be set to 0 for the unit to perform DNS requests of type SRV (as per RFC 3263).
Otherwise, the unit will not use DNS SRV requests, but will rather use only requests of type A because it does
not need to be specified which port to use.
2
3
4
5
2. Enter the SIP registrar server static IP address or domain name and port number in the Registrar
Host field.
You must enter the information as IP address:Port number. For instance:
192.168.0.5:5060
3. Enter the SIP Proxy server static IP address or domain name and port number in the Proxy Host
field.
You must enter the information as IP address:Port number. For instance:
192.168.0.5:5060
4. Enter the SIP outbound proxy server static IP address or domain name and port number in the
Outbound Proxy Host field.
The outbound proxy is enabled if the IP address is valid (i.e., not 0.0.0.0:0). Setting the address to
0.0.0.0:0 or leaving the field empty disables the outbound proxy.
5. Enter the Messaging system host static IP address or domain name and port number in the
Messaging Server Host field.
If the host corresponds to a domain name that is bound to a SRV record, the port must be set to 0
for the unit to perform DNS SRV queries; otherwise only type A record lookups will be used.
You can define whether or not an endpoint needs to subscribe to a messaging system in “Endpoints
Registration” on page 289.
6. Click Submit if you do not need to set other parameters.
The Aastra unit allows you to have multiple SIP gateways (interfaces). You can configure each SIP gateway
to register to a specific registrar. You can also configure each SIP gateway to send all requests to an outbound
proxy. See “Chapter 24 - SIP Gateways” on page 277 for more details.
2. Enter the IP address or domain name and port number of the registrar server currently used by the
registration in the Registrar Host field.
You must enter the information as IP address:Port number. For instance:
192.168.0.5:5060
2. Enter the IP address or domain name and port number of the messaging server currently used by
the registration in the Proxy Host field.
You must enter the information as IP address:Port number. For instance:
192.168.0.5:5060
3. Enter the IP address or domain name and port number of the outbound proxy server currently used
by the registration in the Outbound Proxy Host field.
You must enter the information as IP address:Port number. For instance:
192.168.0.5:5060
The outbound proxy is enabled if the IP address is valid (i.e., not 0.0.0.0:0). Setting the address to
0.0.0.0:0 or leaving the field empty disables the outbound proxy.
4. If you do not need to set other parameters, do one of the following:
• To save your settings without refreshing the registration, click Submit.
• To save your settings and refresh the registration now, click Submit & Refresh
Registration.
2. Enter the IP address or domain name and port number of the proxy server currently used by the
registration in the Proxy Host field.
You must enter the information as IP address:Port number. For instance:
192.168.0.5:5060
3. Enter the IP address or domain name and port number of the outbound proxy server currently used
by the registration in the Outbound Proxy Host field.
You must enter the information as IP address:Port number. For instance:
192.168.0.5:5060
The outbound proxy is enabled if the IP address is valid (i.e., not 0.0.0.0:0). Setting the address to
0.0.0.0:0 or leaving the field empty disables the outbound proxy.
4. If you do not need to set other parameters, do one of the following:
• To save your settings without refreshing the registration, click Submit.
• To save your settings and refresh the registration now, click Submit & Refresh
Registration.
Keep Alive
You can select the method used to perform the SIP keep alive mechanism. With this mechanism, the Aastra
unit sends messages periodically to the server to ensure that it can still be reached.
1
2
3
Parameter Description
Parameter Description
SipOptions SIP OPTIONS are sent periodically for each gateway to the
corresponding server. Any response received from the
server means that it can be reached. No additional
processing is performed on the response. If no response is
received after the retransmission timer expires
(configurable via the Transmission Timeout field in “SIP
Interop” on page 312), the gateway considers the server as
unreachable. In this case, any call attempt through the
gateway is refused. SIP OPTIONS are still sent when the
server cannot be reached and as soon as it can be reached
again, new calls are allowed.
Ping A Ping is sent periodically for each gateway to the
corresponding server. The response received from the
server means that it is reachable. If no response is received
after the retransmission timer expires (configurable via the
Transmission Timeout field in “SIP Interop” on page 312),
the gateway considers the server as unreachable. In this
case, any call attempt through the gateway is refused. The
Pings are still sent when the server is unreachable and as
soon as it becomes reachable again, new calls are allowed.
2. Set the interval, in seconds, at which SIP Keep Alive requests using SIP OPTIONS or Ping are sent
to verify the server status in the Keep Alive Interval field.
3. Select the behaviour of the device when performing the keep alive action in the Keep Alive
Destination drop-down menu.
Table 106: SIP Keep Alive Destination Parameters
Parameter Description
First SIP Destination Performs the keep alive action through the first SIP
destination. This corresponds to the outbound proxy host
when specified, otherwise it is the proxy host.
Alternate Destination Performs the keep alive action through the alternate
destination target (see “SIP Gateway Specific Keep Alive
Destinations” on page 164 for more details).
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
You can specify the type of routing of the outbound proxy configured in “SIP Servers Configuration” on
page 160.
You can use two types of configuration:
Default configurations that apply to all the endpoints of the Aastra unit.
Specific configurations that override the default configurations.
You can define specific configurations for each endpoint in your Aastra unit. For instance, you could
enable a codec for all the endpoints of the Aastra unit and use the specific configuration parameters
to disable this same codec on one specific endpoint.
Using one or more specific parameter usually requires that you enable an override variable and set the specific
configuration you want to apply.
The following types are available:
Table 107: Outbound Proxy Router Status
Type Description
LooseRouter This is the most current method for SIP routing, as per RFC 3261, and will become the
standard behaviour once RFC 3261 compliance is achieved. See “Introduction” on
page 159 for details.
StrictRouter Pre-RFC 3261, RFC 2543 compatible SIP routing.
The initial route for all SIP requests contains the home domain proxy address (the Request-
URI). Requests are directed to the outbound proxy.
In other words, the Request-URI is constructed as usual, using the home domain proxy and
the user name, but is used in the route set. The Request-URI is filled with the outbound
proxy address.
Loose Router
A proxy is said to be loose routing if it follows the procedures defined in the RFC 3261 specification
(section 6) for processing of the Route header field. These procedures separate the destination of the
request (present in the Request-URI) from the set of proxies that need to be visited along the way
(present in the Route header field). A proxy compliant to these mechanisms is also known as a loose
router.
Type Description
NoRouteHea Removes the route header from all SIP packets sent to an outbound proxy. This does not
der modify persistent TLS connection headers.
Note: The Router header will not be removed from the SIP packets if the unit is configured
to use the TLS Fallback feature. This feature requires the information of the SIP Outbound
Proxy in the SIP packet to work correctly.
Value Meaning
100 LooseRouter
200 StrictRouter
300 NoRouteHeader
2. If you want to set a different routing type for one or more SIP gateways, set the following variables:
• gwSpecificproxyEnableConfig variable for the specific SIP gateway you want to
configure to enable.
• gwSpecificProxyOutboundType variable for the specific SIP gateway you want to
configure to the proper value.
You can also use the following lines in the CLI or a configuration script:
sipEp.gwSpecificProxy.EnableConfig[GatewayName="default"]="1"
sipEp.gwSpecificProxy.OutboundType[GatewayName="Specific_Gateway"]="Value"
where:
• Specific_Gateway is the name of the SIP gateway you want to configure.
• Value is the refresh router status as defined in Step 1.
23 SIP Registration
This chapter describes how to configure the registration parameters of the Aastra unit.
Endpoints Registration
Each endpoint of the Aastra unit has its own registration information. You can set information for each endpoint
such as its telephone number and friendly name.
Adding an endpoint registration triggers a warning message if the total number of registrations configured
reached the defined limit. See “Number of Registrations” on page 171 for more details.
2 3 4 5 6
2. In the Endpoints Registration and Subscription section of the Registrations page, enter a user name
for each endpoint in the User Name column.
The user name (such as a telephone number) uniquely identifies this endpoint in the domain. It is
used to create the Contact and From headers. The From header carries the permanent location (IP
address, home domain) where the endpoint is located. The Contact header carries the current
location (IP address) where the endpoint can be reached.
Contacts are registered to the registrar. This enables callers to be redirected to the endpoint’s
current location.
3. Enter another name for each endpoint in the Friendly Name column.
This is a friendly name for the endpoint. It contains a descriptive version of the URI and is intended
to be displayed to a user interface.
4. Define whether or not the endpoint registration needs to register to the registrar in the Register
column.
An endpoint configured to register (set to Enable) will become unavailable for calls from or to SIP
when not registered.
You can define the behaviour of an endpoint when it becomes unavailable in the
defaultRegistrationUnregisteredBehavior MIB variable.
5. Define whether or not the endpoint needs to subscribe to a messaging system in the Messaging
drop-down menu.
The current state of the subscription is displayed in the Endpoints Messaging Subscription Status
table.
Table 109: MWI Subscription State
State Description
Unsubscribed The unit/endpoint is not subscribed and never tries to subscribe. This case
occurs if the network interface used by the SIP gateway is not up or the unit/
endpoint is locked.
Subscribing The subscription is currently trying to subscribe.
Subscribed The subscription is successfully subscribed.
Refreshing The subscription is trying to refresh.
Unreachable The last subscription attempt failed because the messaging server is
unreachable.
AuthFailed The last subscription attempt failed because authentication was not
successful.
Rejected The last subscription attempt failed because the messaging server rejects
the subscription.
ConfigError The last subscription attempt failed because it was badly configured. Check
if the username and the messaging host are not empty.
InvalidResponse The received 200 OK response contact does not match the contact of the
messaging server, or the 200 OK response for an unsubscribe contains a
contact.
You can enter the address of the Messaging server in “SIP Servers Configuration” on page 282.
6. Select on which SIP gateway the user configuration is applied in the Gateway Name drop-down
menu.
You must have SIP gateways already defined. See “Chapter 24 - SIP Gateways” on page 277 for
more details. If you select all, the configuration applies to all gateways available.
7. If you do not need to set other parameters, do one of the following:
• To save your settings without refreshing the registration, click Submit.
• To save your settings and refresh the registration now, click Submit & Refresh.
Contact Domain
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
You can set the host part of the SIP contact field. If an empty string is specified, the listening IP address is
used.
Unit Registration
Unit registration is used to register a contact not directly related to endpoints. This is generally used to indicate
to a registrar the IP location of the Aastra unit when it is used as a gateway.
Adding a unit registration triggers a warning message if the total number of registrations configured reached
the defined limit. See “Number of Registrations” on page 171 for more details.
The user name (such as a telephone number) uniquely identifies this user in the domain.
You can add a new user by clicking the button.
You can delete an existing user by clicking the button.
2. Select on which SIP gateway the user configuration is applied in the Gateway Name drop-down
menu.
You must have SIP gateways already defined. See “Chapter 24 - SIP Gateways” on page 277 for
more details. If you select all, the configuration applies to all gateways available.
3. If you do not need to set other parameters, do one of the following:
• To save your settings without refreshing the registration, click Submit.
• To save your settings and refresh the registration now, click Submit & Refresh.
Registration Configuration
1
2
3
In SIP, a registration is valid for a period of time defined by the registrar. Once a unit is registered,
the SIP protocol requires the User Agent to refresh this registration before the registration expires.
Typically, this re-registration must be completed before the ongoing registration expires, so that the
User Agent's registration state does not change (i.e., remains 'registered').
For instance, if the parameter is set to 43 and the registration lasts one hour, the unit will send new
REGISTER requests 59 minutes and 17 seconds after receiving the registration acknowledgement
(43 seconds before the unit becomes unregistered).
Note: Normally, the Aastra unit cannot make or receive calls until the REGISTER has completed
successfully. Because the timeout for a SIP transaction in UDP is 32 seconds, it is possible to have an
ongoing re-REGISTER transaction at the same moment that the registration itself expires. This could
happen if the Default Registration Refresh Time field is set to a value lower than 32.
In that case, the user agent becomes unregistered, and will become registered again only when the re-
REGISTER request is answered with a positive response from the server. See “Gateway Specific
Registration Retry Time” on page 174 for a workaround if the unit cannot make calls during that period.
Setting this parameter to 0 means that the User Agent will fall into the 'unregistered' state BEFORE
sending the re-REGISTER requests.
This value MUST be lower than the value of the "expires" of the contact in the 200 OK response to
the REGISTER, otherwise the unit rapidly sends REGISTER requests continuously.
You can also set a different registration refresh time for one or more SIP gateways by using the MIB
parameters of the Aastra unit. See “Registration Refresh” on page 172 for more details.
2. Set the Proposed Expiration Value In Registration field with the suggested expiration delay, in
seconds, of a contact in the REGISTER request.
The SIP protocol allows an entity to specify the “expires” parameter of a contact in a REGISTER
request. The server can return this “expires” parameter in the 200 OK response or select another
“expires”. In the REGISTER request, the “expires” is a suggestion the entity makes.
The “expires” parameter indicates how long, in seconds, the user agent would like the binding to be
valid.
Available values are from 1 s to 86,400 s (one day).
This value does not modify the delay before a re-REGISTER.
• The delay is the “expires” of the contact in the 200 OK response to the REGISTER
request minus the value set in the Default Registration Refresh Time field.
• If the “expires” of the contact in the 200 OK response to the REGISTER is not present
or not properly formatted, then the delay is the default registration proposed expiration
value minus the value set in the Default Registration Refresh Time field.
Setting the parameter to 0 disables the expiration suggestion.
You can also set a different expiration delay for one or more SIP gateways by using the MIB
parameters of the Aastra unit. See “Registration Expiration” on page 173 for more details.
3. Set the Default Expiration Value in Registration field with the default registration expiration, in
seconds.
This value is used when the contact in a registration response contains no “expires” or the “expires”
is badly formatted. In this case, the delay before a re-REGISTER is the value set in this field minus
the value set in the Default Registration Refresh Time field (Step 1).
You can also set a different expiration value in registration for one or more SIP gateways by using
the MIB parameters of the Aastra unit. See “Expiration Value in Registration” on page 173 for more
details.
4. If you do not need to set other parameters, do one of the following:
• To save your settings without refreshing the registration, click Submit.
• To save your settings and refresh the registration now, click Submit & Refresh.
Number of Registrations
The Aastra unit limits the total number of registrations to 100. The total number of registrations is the sum of
all the endpoints and gateways (“SIP Gateways Configuration” on page 277) pairs. The Aastra unit supports
a maximum of 5 gateways. An endpoint configured with "All" gateways generates as many pairs as the number
of gateways. In a setup with 3 gateways, one endpoint configured with "All" as the gateway name counts for
3 in the total number of registrations.
The registrations are enabled gateway by gateway until the limit is reached. Endpoints Registrations are used
first, then Unit Registrations. The remaining registrations are not registered and do not appear in the status
table. If you click the Submit And Refresh button and the configured number of registrations exceeds the
defined limit, a warning is displayed on the web interface (as well as in the CLI and SNMP interfaces) and a
syslog notify (Level Error) is sent.
Adding a gateway or an endpoint triggers a warning message if the total number of registrations configured
reached the defined limit.
Let’s suppose for instance that we have the current SIP Gateways configuration and the following SIP
Registration configuration:
The following table describes how to compute the total number of registrations for this example:
Table 110: Number of Registrations Example
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
Registration Refresh
You can set the default registration refresh time in the web page (“Registration Configuration” on page 169),
but you can also set a different registration refresh time for one or more SIP gateways.
Registration Expiration
You can set the default registration proposed expiration value in the web page (“Registration Configuration”
on page 169), but you can also set a different registration refresh time for one or more SIP gateways.
You can also use the following lines in the CLI or a configuration script:
3. To set a different expiration value in registration for one or more SIP gateways, put the following
lines in the configuration script:
sipEp.gwSpecificRegistration.EnableConfig[GatewayName="Specific_Gateway"]="1"
sipEp.gwSpecificRegistration.ExpirationValue[GatewayName="Specific_Gateway"]="Va
lue"
where:
• Specific_Gateway is the name of the SIP gateway you want to configure.
• Value is the expiration value in registration value.
Value Description
disablePort When the endpoint is not registered, it is disabled. The user cannot make or receive calls.
Picking up the handset yields a fast busy tone, and incoming INVITEs receive a “403
Forbidden” response.
enablePort When the endpoint is not registered, it is still enabled. The user can receive and initiate
outgoing calls. Note that because the endpoint is not registered with a registrar, its public
address is not available to the outside world; the endpoint will most likely be unreachable
except through direct IP calling.
Value Meaning
0 disablePort
1 enablePort
3. If you want to set a different behaviour for one or more SIP gateways, set the following variables:
• gwSpecificRegistrationEnableConfig variable for the specific SIP gateway you
want to configure to enable.
• gwSpecificRegistrationUnregisteredBehavior variable for the specific SIP
gateway you want to configure to the proper value.
You can also use the following lines in the CLI or a configuration script:
sipEp.gwSpecificRegistration.EnableConfig[GatewayName="Specific_Gateway"]="1"
sipEp.gwSpecificRegistration.UnregisteredBehavior[GatewayName="Specific_Gateway"
]="Value"
where:
• Specific_Gateway is the name of the SIP gateway you want to configure.
• Value is one of the values described in Step 2.
Value Description
NoEffect The unit registrations state has no effect on the SIP gateway state.
DisableGate The SIP gateway goes in the 'unregistered' state when all unit registrations are not in the
way 'registered' state. The 'unregistered' state indicates some registrations that are mandatory
for this gateway failed.
Value Meaning
100 NoEffect
Value Meaning
200 DisableGateway
Value Description
Value Meaning
100 NoRegistration
200 EndpointRegistration
300 UnitRegistration
400 UnitAndEndpointRegistration
You can also use the following line in the CLI or a configuration script:
sipEp.registrationDelayOnInitialRegistrationReception="Value"
Note: The random algorithm applies individually to all registrations, meaning registrations order may not
follow their corresponding index.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
The User-Agent header field contains information about the user agent client originating the request. For
instance, the information of the User-Agent header could be something like the following:
User-Agent: Softphone Beta1.5
You can specify whether or not the Aastra unit sends this information when establishing a communication.
24 SIP Authentication
This chapter describes how to configure authentication parameters of the Aastra unit.
Caution: The SIP > Authentication page is not accessible if you have the User or Observer access right.
See “Users” on page 591 for more details.
Authentication Configuration
Authentication information allows you to add some level of security to the Aastra unit endpoints by setting user
names and passwords.
You can add four types of authentication information:
Table 117: Authentication Information
Authentication Description
endpoint-specific Applies only to challenges received for SIP requests related to a specific endpoint. For
instance, the registration associated with the endpoint in the user agent table or the
INVITE sent to initiate a call from the endpoint. You can define several user names and
passwords for each endpoint of the Aastra unit. An endpoint can thus register with
several different realms.
gateway-specific Applies only to challenges received for SIP requests on a specific SIP gateway. You can
define several user names and passwords for each endpoint of the Aastra unit. An
endpoint can thus register with several different realms.
unit Applies to all challenges received for SIP dialog. You can define several user names
and passwords for the Aastra unit. These user names and passwords apply to all
endpoints of the unit.
user name- Applies only to challenges for a context that uses a specific user name.
specific
The Authentication table may have between 20 and 100 rows. Each of these rows can either be associated
with the unit, a specific gateway, a specific endpoint, or a specific user name. If you have less than 20 rows,
the Aastra unit automatically adds new rows up to the minimum of 20.
When a challenge occurs (either 401 or 407), the first entry in the Authentication table that matches the user
name/password request is used to reply to the challenge. You can configure the use name and password in
the web interface. The order of the tried entries in the Authentication table is from the first row to the last row.
The challenge matches an authentication entry if the realm of the challenge matches the realm specified in
the Realm field or if the Validate Realm field is set to disable. For each entry matching certain criteria
(described below), the challenge is replied with the entry's user name and password. If no entry matches the
criteria, the authentication fails. To match the authentication request, the entry must also meet one of the
following criteria:
The challenge needs to be for a SIP request related to the endpoint specified in the Endpoint
column if the corresponding Apply To column is set to Endpoint.
The challenge needs to be for a SIP request performed on the SIP gateway specified in the
Gateway column if the corresponding Apply To column is set to Gateway.
The challenge needs to be for a context that uses the user name specified in the User Name
field if the corresponding Apply To column is set to Usename. The user name associated with
a context is:
• the user name of the FROM if the context sent the original SIP request, or
• the user name of the request URI if the context received the original SIP request
The challenge applies to a unit if the corresponding Apply To column is set to Unit.
• If you want to add an authentication entry at the end of the existing rows, click the
button at the bottom right of the Authentication section.
• If you want to add several authentication entries at the same time, enter the number of
entries you want to add in the Number of rows to add at the bottom of the page.
• If you want to edit a single authentication entry, locate the proper row in the table and
click the button.
• If you want to edit a several authentication entries of the current page at the same time,
click the Edit All Entries button at the bottom of the page.
This brings you to the proper Authentication panel.
3 4 5 6 7 8 9
3 4 5 6 7 8 9
3. Select which criterion to use for matching an authentication request with an authentication entry in
the Apply to column.
Table 120: Authentication Entity
Parameter Description
4. Enter a string that identifies an endpoint in other tables in the Endpoint column.
This field is available only if you have selected the Endpoint entity in the previous step for the
specific row.
5. Enter a string that identifies a SIP gateway in other tables in the Gateway column.
This field is available only if you have selected the Gateway entity in the Apply to column for the
specific row.
6. Select whether or not the current credentials are valid for any realm in the corresponding Validate
Realm drop-down menu.
Table 121: Realm Authentication Parameters
Parameter Description
Disable The current credentials are valid for any realm. The corresponding Realm field is
read-only and cannot be modified.
Enable The credentials are used only for a specific realm set in the corresponding Realm
field.
This chapter describes the SIP transport parameters you can set.
You can globally set the transport type for all the endpoints of the Aastra unit to either UDP (User Datagram
Protocol), TCP (Transmission Control Protocol), or TLS (Transport Layer Security).
The Aastra unit will include its supported transports in its registrations.
Please note that RFC 3261 states the implementations must be able to handle messages up to the maximum
datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers. However, the
maximum datagram packet size the Aastra unit supports for a SIP request or response is 5120 bytes excluding
the IP and UDP headers. This should be enough, as a packet is rarely bigger than 2500 bytes.
2
3
4
5
6
7 8 7 8 7 8
2. In the General Configuration section, enable or disable the transport registration in the Add SIP
Transport in Registration drop-down menu.
When enabled, the Aastra unit includes its supported transports in its registrations. It registers with
one contact for each transport that is currently enabled. Each of these contacts contains a
“transport” parameter.
This is especially useful for a system where there are no SRV records configured to use a
predefined transport order for receiving requests. When sending a request, the unit either follows
the SRV configuration, or, if not available, any transport parameter received from a redirection or
from a configured SIP URL.
3. Indicate whether or not the unit must include its supported transport in the Contact header in the
Add SIP Transport in Contact Header drop-down menu.
The supported transports are included in all SIP messages that have the Contact header, except
for the REGISTER message.
Available values are Enable and Disable. If you set the menu to Enable, the Aastra unit will send
SIP messages with the “transport” parameter in the Contact header set to:
• transport=tcp when TCP is enabled and UDP is disabled
• transport=udp when UDP is enabled and TCP disabled
• no transport parameter when both TCP and UDP are enabled
• transport=tls when secure transport (TLS) is selected
4. Define the base port used to establish TLS persistent connections with SIP servers when the TLS
transport is enabled in the Persistent TLS Base Port field.
5. Set the time interval, in seconds, before retrying the establishment of a TLS persistent connection
in the Persistent TLS Retry Interval field.
This is the interval that the Aastra unit waits before retrying periodically to establish a TLS persistent
connection using a single IP address or a FQDN. This timer is started when a TLS persistent
connection goes down or fails to connect to the destination. The TLS persistent connect timeout
applies only to TLS persistent connections.
When the destination is a single IP address and the TLS persistent connection goes down or fails
to establish, the timer is started. When the timer expires, the Aastra unit attempts to re-establish the
TLS persistent connection.
When the destination is a FQDN and the TLS persistent connection goes down or fails to establish
with the higher priority target received from a DNS answer, the timer is started and the lower priority
targets are attempted. When the timer expires, a new DNS request is sent and depending on the
DNS answer, the Aastra unit retries to establish the TLS persistent connection with the higher
priority target. The timer is unique for all TLS persistent connections using the same FQDN. This
means that the timer is not restarted when a connection using a lower priority target fails while a
connection using a higher priority target has already failed.
6. In the TLS Trusted Certificate Level field, define how a peer certificate is considered trusted for a
TLS connection.
Table 122: Certificate Trust Level for TLS Connections Parameters
Parameter Description
Locally A certificate is considered trusted when the certificate authority (CA) that signed the
Trusted peer certificate is present in the Others Certificates table (see “Chapter 46 -
Certificates Management” on page 557 for more details). The certificate revocation
status is not verified.
Table 122: Certificate Trust Level for TLS Connections Parameters (Continued)
Parameter Description
OCSP A certificate is considered trusted when it is locally trusted and is not revoked by its
Optional certificate authority (CA). The certificate revocation status is queried using the
Online Certificate Status Protocol (OCSP). If the OCSP server is not available or
the verification status is unknown, the certificate is considered trusted.
OCSP A certificate is considered trusted when it is locally trusted and is not revoked by its
Mandatory certificate authority (CA). The certificate revocation status is queried using the
Online Certificate Status Protocol (OCSP). If the OCSP server is not available or
the verification status is unknown, the certificate is considered not trusted.
7. Set the TCP Connect Timeout field with the maximum time, in seconds, the unit should try to
establish a TCP connection to SIP hosts.
This timeout value is useful to have a faster detection of unreachable remote hosts. This timer can
also affect the TLS connection establishment time.
8. In the Protocol Configuration section, enable or disable the UDP, TCP, and TLS transport type to
use in their corresponding drop-down menu.
UDP and TCP are mutually exclusive with TLS. Activating TLS automatically disables these
unsecure protocols.
The successful configuration of a secure transport requires a little more than the activation of the
TLS protocol itself. You need to:
• synchronize the time in the unit (see “Time Configuration” on page 94 & “SNTP
Configuration” on page 93 for more details).
• install the security certificates used to authenticate the server to which you will connect
(see “Chapter 46 - Certificates Management” on page 557 for more details).
• Use secure media (see “Security” on page 201 for more details).
• configure the unit so that a “transport=tls” parameter is added to the Contact header of
your SIP requests (see Step 3).
Caution: If you have enabled Secure RTP (SRTP) on at least one line, it is acceptable to have the secure
SIP transport (TLS) disabled for testing purposes. However, you must never use this configuration in a
production environment, since an attacker could easily break it. Enabling TLS for SIP Transport is strongly
recommended and is usually mandatory for security interoperability with third-party equipment.
9. Set the priority order of each transport type in the corresponding QValue field.
A qvalue parameter is added to each contact. The qvalue gives each transport a weight, indicating
the degree of preference for that transport. A higher value means higher preference.
The format of the qvalue string must follow the RFC 3261 ABNF (a floating point value between
0.000 and 1.000). If you specify an empty string, no qvalue is set in the contacts.
10. Click Submit if you do not need to set other parameters.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
Parameter Description
disable The SIP signalling over UDP uses a randomly-generated originating port. ICMP errors are
processed correctly.
enable The SIP signalling sent over UDP originates from the same port as the port on which the user
agent is listening. ICMP messages are not processed, which means that unreachable targets
will take longer to detect.
Value Meaning
0 disable
1 enable
2. Restart the SipEp service by accessing the scmMIB and setting the serviceCommandsRestart
variable for the SipEp service to restart.
You can also use the following line in the CLI or a configuration script:
scm.serviceCommands.Restart[Name=SipEp]="10"
Parameter Description
disable The Aastra unit does not require TLS clients to provide their host certificate for the connection
to be allowed. This is the default value.
enable The TLS clients must provide their host certificate for the connection to be allowed. In this case,
the level of security used to validate the host certificate is TrustedCertificate, whatever the
value set in the Certificate Validation drop-down menu of the TLS Interop section ( SIP >
Interop web page). See “TLS Interop” on page 318 for more details.
Value Meaning
0 disable
1 enable
Parameter Description
disable The DNS SRV request is sent directly with the SIP transport in SIP URI as recommended in
RFC 3263, section 4.1.
enable A DNS NAPTR request is sent to obtain the DNS record associated with SIP over TLS. An SRV
request is performed afterward. If no SIP over TLS entry is returned, the call fails.
Value Meaning
0 disable
1 enable
26 Interop Parameters
This chapter describes the interop parameters that allow the Aastra unit to properly work, communicate, or
connect with specific IP devices.
This section describes the unit’s behaviour after receiving an error to a SIP INVITE for T.38 fax.
2. In the Behavior on T.38 INVITE Not Accepted section, for each of 406, 415, 488, and 606 SIP code,
set the behaviour after receiving the code in the error response to an INVITE for T.38 fax in the
corresponding Behavior drop-down menu.
Table 129: Behavior on T.38 INVITE Not Accepted Parameters
Behavior Description
SIP Interop
This section describes the SIP interop parameters of the Aastra unit
Parameter Description
disable The “x-Siemens-Call-Type” header is not added to the SIP packets sent by the
unit.
enable The “x-Siemens-Call-Type” header is added to the SIP packets sent by the unit, and
assigned the value “ST-secure”, as soon as secure transport and secure payload
are being used. If secure transport or secure payload are not used, the header is
not added.
1
2
3
4
5
6
7
8
2. Select the username to use when the username is empty or undefined in the Default Username
Value drop-down menu.
Table 131: Default Username Value
Parameter Description
3. Define the behaviour of the Aastra unit when answering a SIP OPTIONS request in the OPTIONS
Method Support drop-down menu.
Table 132: OPTIONS Method Support Parameters
Parameter Description
None The Aastra unit responds with an error 405 Method not
allowed.
AlwaysOK The Aastra unit responds with a 200 OK regardless of the
content of the OPTIONS request.
4. Define whether or not the SIP OPTIONS requests should be ignored when all endpoints are
unusable in the Ignore OPTONS on no usable endpoints drop-down menu.
Table 133: Ignore SIP Options Parameters
Parameter Description
Note that this feature may be influenced by whether or not you have enabled the Monitor Link State
parameter. For more information:
• ISDN PRI interface: “PRI Configuration” on page 184
• ISDN BRI interface: “BRI Configuration” on page 195
• R2 PRI interface: “R2 Channel Associated Signaling” on page 224
5. Set the value of the user parameter in SIP URIs sent by the unit in the SIP URI User Parameter
Value field.
If you leave the field empty, the parameter is not added.
E.g : sip:[email protected];user=InteropSipUriUserParameterValue
Note that when the Map Plus To TON International drop-down menu is set to Enable, the
parameter's value might be overwritten (“Misc Interop” on page 196).
6. Set the Behavior On Machine Detection drop-down menu with the SIP device’s behavior when a
machine (fax or modem) is detected during a call.
Table 134: Behavior on Machine Detection Parameters
Parameter Description
Re-INVITE On Fax T38 Only A SIP re-INVITE is sent only on a fax detection and T.38
is enabled.
Re-INVITE On No Negotiated Data A SIP re-INVITE is sent on a fax or modem detection if no
Codec data codec was previously negotiated in the original SDP
negotiation. In the case where at least one data codec
was previously negotiated in the SDP negotiation, the
device switches silently to a data codec without sending a
SIP re-INVITE. Note sthat if there is no data codec
enabled on the device, no SIP re-INVITE is sent and the
call is dropped by sending a BYE.
Re-INVITE Unconditional A SIP re-INVITE is sent with data codecs upon detection
of a fax or modem even if a data codec was negotiated in
the initial offer-answer. The T.38 codec is offered if it is
enabled and a fax is detected.
See “Data Codec Selection Procedure” on page 221 for more details on the procedure the Aastra
unit follows when selecting data codec.
7. Set the Registration Contact Matching field with the matching behaviour for the contact header
received in positive responses to REGISTER requests sent by the unit.
Table 135: Registration Contact Matching Parameters
Parameter Description
Strict Matches the complete contact's SIP URI including any URI parameters, if any, as
per RFC 3261 sections '10.2.4 Refreshing Bindings' and '19.1.4 URI Comparison'.
The contact's SIP URI of a 2XX positive response MUST match the contact's SIP
URI of the REGISTER request.
IgnoreUriP Matches the username and the host port part of the contact's SIP URI. All URI
arams parameters are ignored.
8. Set the Transmission Timeout field with the time to wait for a response or an ACK before
considering a transaction timed out.
This corresponds to timers B, F and H for all transport protocols and timer J for UDP. These timers
are defined in section A of RFC 3261.
This timeout affects the number of retransmissions. Retransmissions continue to follow the timing
guidelines described in RFC 3261.
If a DNS SRV answer contains more than one entry, the Aastra unit will try these entries if the entry
initially selected does not work. You can configure the maximum time, in seconds, to spend waiting
for answers to messages, from a single source. Retransmissions still follow the algorithm proposed
in RFC 3261, but the total wait time can be overridden by using this feature.
For example, if you are using DNS SRV and more than one entry are present, this timeout is the
time it takes before trying the second entry.
Available values are from 1 to 32 seconds.
9. Click Submit if you do not need to set other parameters.
SDP Interop
This section describes the SDP interop parameters of the Aastra unit.
Parameter Description
All Common - Local When generating an answer to an offered session, all common codecs
Priority are listed in the local order of priority. The local priority is defined for each
codec in the Telephony > CODECS page – by clicking the button of
each codec and looking in the Voice Priority and Data Priority fields. See
“Chapter 14 - Voice & Fax Codecs Configuration” on page 181 for more
details.
First Common - When generating an answer to an offered session, only the first common
Local Priority codec with the higher local priority is listed. The local priority is defined
for each codec in the Telephony > CODECS page – by clicking the
button of each codec and looking in the Voice Priority and Data Priority
fields. See “Chapter 14 - Voice & Fax Codecs Configuration” on
page 181 for more details.
All Common - Peer When generating an answer to an offered session, all common codecs
Priority are listed. The codecs order is the same as in the peer offer.
First Common - When generating an answer to an offered session, only the first common
Peer Priority codec is listed. The codecs order is the same as in the peer offer.
1
2
3
4
5
6
7
8
2. Select whether or not the Aastra unit requires strict adherence to RFC 3264 when receiving an
answer from the peer when negotiating capabilities for the establishment of a media session in the
Enforce Offer Answer Model drop-down menu.
The following values are available:
Table 137: Offer/Answer Model Parameters
Parameter Description
Parameter Description
Enable The following guidelines from the Offer-Answer Model must be strictly
followed. An answer must:
• Include at least one codec from the list that the Aastra unit sent in
the offer.
• Contain the same number of media lines that the unit put in its offer.
Otherwise, the answer is rejected and the unit ends the call. This is the default
value.
3. Define the behaviour of the Aastra unit when receiving less media announcements in the response
than in the offer in the Allow Less Media In Response drop-down menu.
The following values are available:
Table 138: Less Media Announcements Parameters
Parameter Description
Disable The Aastra unit rejects the response with less media announcements than in
the offer.
Enable The Aastra unit tries to find matching media when the response contains less
media announcement than in the offer. This is a deviation from the Offer/
Answer model.
4. Define the behaviour of the Aastra unit when receiving a SDP answer activating a media that had
been previously deactivated in the offer in the Allow Media Reactivation in Answer drop-down
menu.
Table 139: Media Reactivation Parameters
Parameter Description
5. In the Multiple Active Media part, define the behaviour of the Aastra unit when offering media or
answering to a media offer with audio and image negotiation in the Allow Audio and Image
Negotiation drop-down menu.
Table 140: Audio and Image Negotiation Parameters
Parameter Description
6. Define the behaviour of the Aastra unit when answering a request offering more than one active
media in the Allow Multiple Active Media in Answer drop-down menu.
Figure 79: Allow Multiple Active Media in Answer
Parameter Description
disable The answer contains only one active media. The media specified as active
in the answer is the top-most matching one in the offer. Other media are
set to inactive.
enable Each matching active media in the offer is specified as active in the
answer. Other media are set to inactive
7. In the Other part, define how to set the direction attribute and the connection address in the SDP
when answering a hold offer with the direction attribute “sendonly” in the On Hold SDP Stream
Direction in Answer drop-down menu.
The following parameters are supported:
Table 141: “sendonly” Direction Attribute
Parameter Description
inactive The stream is marked as inactive and if the stream uses IPv4, the
connection address is set to '0.0.0.0'.
revconly If the stream is currently active or receive only, it is marked as recvonly
and the connection address is set to the IP address of the unit.
If the stream is currently send only or inactive, it is marked as inactive
and if the stream uses IPv4, the connection address is set to '0.0.0.0'.
This method is in conformance with RFC 3264.
Note: If you are experiencing media negotiation problems (because the Aastra unit sends a BYE after
receiving a 200 OK), try to set the Enforce Offer Answer Model value to Disable and the Allow Less Media
In Response value to Enable.
TLS Interop
This section describes the TLS interop parameters of the Aastra unit.
Note: This parameter has no effect on the TLS client authentication when the unit is acting as a TLS server
(see the interopTlsClientAuthenticationEnable variable in “TLS Client Authentication” on page 308).
Parameter Description
No Validation No validation of the peer certificate is performed. All TLS connections are
accepted without any verification. Note that at least one certificate must be
returned by the peer even if no validation is made. This option provides no
security and should be restricted to a lab use only.
Trusted Allows a TLS connection only if the peer certificate is trusted. A certificate is
Certificate considered trusted when the certificate authority (CA) that signed the peer
certificate is present in the Management > Certificates page (“Chapter 46 -
Certificates Management” on page 557). This option provides a minimum level
of security and should be restricted to a lab use only.
Dns Srv Allows a TLS connection if the peer certificate is trusted and contains a known
Response host name. A known host name can be the FQDN or IP address configured as
the SIP server, or can also be returned by a DNS SRV request. In this case,
the match is performed against the DNS response name. If it matches either
one of the Subject Alternate Name (SAN) or Common Name (CN) in the peer
certificate, the connection is allowed. This option provides an acceptable level
of security, but not as good as Host Name.
HostName Allows a TLS connection if the peer certificate is trusted and contains a known
host name. A known host name can only be the FQDN or IP address
configured as the SIP server. If it matches either one of the Subject Alternate
Name (SAN) or Common Name (CN) in the peer certificate, the connection is
allowed. This option provides the highest level of security.
Misc Interop
1
2
3
4
2. Define the Ignore Plus in Username drop-down menu as to whether or not the plus (+) character is
ignored when attempting to match a challenge username with usernames in the Authentication
table.
Table 143: Ignore Plus (+) Character in Username Parameters
Parameter Description
Enable The plus (+) character is ignored when attempting to match a username in the
authentication table.
Disable The plus (+) character is not ignored when attempting to match a username in the
authentication table.
3. Select whether or not the pound character (#) must be escaped in the username part of a SIP URI
in the Escape Pound (#) in SIP URI Username drop-down menu.
Table 144: Escape Pound Parameters
Parameter Description
4. Select the format of the escaped characters to be used in all SIP headers in the Escape Format
drop-down menu.
Table 145: Escape Format Parameters
Parameter Description
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
The interop parameters allow the Aastra unit to properly work, communicate, or connect with specific IP
devices.
You can also use the following line in the CLI or a configuration script:
sipEp.interopCallWaitingSipInfoPrivateNumberCriteria="Value"
For example, the value "(Anonymous|anonymous)" would define a calling number that is either
"Anonymous" or "anonymous" as private. The regular expression symbols to match the beginning
and end of the number are implicit and do not need to be specified. See “Regular Expressions” on
page 463 for more details.
The variable is effective only if the Default Hook-Flash Processing parameter of the SIP > Misc page
is set to TransmitUsingSignalingProtocol (see “General Configuration” on page 417 for more
details).
Max-Forwards Header
Standards Supported • RFC 3261: SIP: Session Initiation Protocol
Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists
of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request
reaches its destination, it is rejected with a “483 (Too Many Hops)” error response. The Max-Forwards SIP
header is always present and the default value is 70.
The Aastra unit can provide the direction attribute and the meaning of the connection address “0.0.0.0” sent
in the SDP when an endpoint is put on hold.
The following parameters are supported:
Table 146: Direction Attributes
Parameter Description
inactive The stream is put on hold by marking it as inactive. This is the default value. This setting
should be used for backward compatibility issues.
sendonly The stream is put on hold by marking it as sendonly. This method allows the Aastra unit to
be in conformance with RFC 3264.
Value Meaning
100 inactive
Value Meaning
200 sendonly
Direction Attribute
Standards Supported • RFC 2543: SIP: Session Initiation Protocol
• RFC 3264: An Offer/Answer Model with Session Description
Protocol (SDP)
You can define if the SDP direction attribute is supported by the unit.
This variable applies only when the negotiated media uses an IPv4 address. The application always behaves
as if this variable is set to Enable for media using an IPv6 address.
The following parameters are supported:
Table 148: SDP Direction Attribute
Parameter Description
disable No direction attribute is present in the SDP sent by the Aastra unit.
The Aastra unit ignores any direction attribute found in the SDP received from the peer.
The method to put a session on hold is in conformance with RFC 2543.
enable The Aastra unit always sends the direction attribute in the SDP of an initiated call. For
all other SDP messages sent by the unit, refer to “Enable/Disable SDP Detect Peer
Direction Attribute Support” on page 199.
If present in the SDP, the direction attribute is preferred over the connection address to
transmit session modification information.
This method is in conformance with RFC 3264.
Value Meaning
0 disable
1 enable
Parameter Description
disable The Aastra unit always sends the direction attribute in the SDP without autodetection of
peer support.
enable The initial handshake determines if the peer supports the direction attribute. The
direction attribute will be present when the peer supports it.
Value Meaning
0 disable
1 enable
Parameter Description
HoldAddress The connection address sent in the SDP is '0.0.0.0' if the media uses an IPv4 address.
This method is described by RFC 2543.
MediaAddress The connection address sent in the SDP is the listening address.
Value Meaning
100 HoldAddress
200 MediaAddress
You can define how to set the direction attribute in the SDP when answering a hold offer with the direction
attribute 'sendonly'.
The following parameters are supported:
Table 154: “sendonly” Direction Attribute
Parameter Description
inactive The stream is marked as inactive and if the stream uses an IPv4
address, the connection address is set according to the
InteropOnHoldSdpConnectionAddress variable (“On Hold SDP
Connection Address” on page 200).
revconly If the stream is currently active or receive only, it is marked as recvonly
and the connection address is set to the IP address of the unit.
If the stream is currently send only or inactive, it is marked as inactive
and the connection address is set according to the
InteropOnHoldSdpConnectionAddress variable (“On Hold SDP
Connection Address” on page 200).
This method is in conformance with RFC 3264.
Value Meaning
100 inactive
200 Recvonly
You can define the preferred location where the stream direction attribute is set.
The following parameters are supported:
Table 156: SDP Direction Attribute Level
Parameter Description
MediaOrSessionLevel If every media have the same direction, the stream direction attribute is
only present at session level.
Otherwise, the stream direction attribute is only present at media level.
Parameter Description
MediaAndSessionLevel If every media have the same direction, the stream direction attribute is
present both at session level and media level.
Otherwise, the stream direction attribute is only present at media level.
Value Meaning
100 MediaOrSessionLevel
200 MediaAndSessionLevel
Parameter Description
Disable The local ring is not started on a '18x Provisional' response without SDP, with one
exception: the '180 Ringing' without SDP will start the local ring if the media stream is
not already established.
LocalRingWhenNo : The local ring is started on any '18x Provisional' response without SDP if the media
EstablishedMediaS stream is not already established.
tream
LocalRingAlways The local ring is always started on any '18x Provisional' response without SDP.
Value Meaning
0 disable
1 LocalRingWhenNoEstablishedMediaStream
Value Meaning
2 LocalRingAlways
Session ID and Session Version Number in the Origin Field of the SDP
You can define the maximum length of the session ID and the session version number in the origin line (o=)
of the SDP. This allows the Aastra unit to be compatible with 3rd party vendor equipment.
The following parameters are supported:
Table 158: Maximum Length Parameters
Length Description
max-32bits The session ID and the session version number are represented with a 32 bit integer.
They have a maximum length of 10 digits.
max-64bits The session ID and the session version number are represented with a 64 bit integer.
They have a maximum length of 20 digits. This is the default value.
To set the maximum length of the session ID and the session version number:
1. In the sipEpMIB, set the interopSdpOriginLineSessionIDAndVersionMaxLength variable with
the proper length.
You can also use the following line in the CLI or a configuration script:
sipEp.interopSdpOriginLineSessionIdAndVersionMaxLength="Value"
where Value may be as follows:
Table 159: Maximum Length Values
Value Meaning
100 max-32bits
200 max-64bits
You can configure the Aastra unit to always use the same DNS SRV record for a SIP call ID. As a result, a call
or registration always uses the same destination until the destination is unreachable or the unit receives a
different DNS SRV result.
The following parameters are supported:
Table 160: DNS SRV Record Lock Parameters
Length Description
Value Meaning
0 disable
1 enable
Length Description
enable The RTP port is opened after the initial INVITE has been sent, without waiting for a provisional or
final response with SDP to be received. No local ring is generated. This conforms to section 5.1 of
RFC 3264.
disable The RTP port is opened only after a response with SDP is received.
Warning: Do not enable this feature unless the server supports early RTP (or early media). Failing so
prevents any ringing to be heard for outgoing calls.
Value Meaning
0 disable
1 enable
Length Description
enable The FQDN in the top-most route header is replaced by the IP address of the packet's destination
if the FQDN matches the gateway's configured outbound proxy.
disable The route header is not modified.
Value Meaning
0 disable
1 enable
Parameter Description
Rfc3261 Follows the method described in RFC 3261 (section 8.1.1.7). The branch value in the topmost
via of the ACK request to a 2XX response MUST be different than the one of the INVITE.
Rfc3261Wi Follows the method described in RFC 3261 (section 8.1.1.7) but enables the handling of ACK
thoutAck requests (for 2XX responses) that have the same branch value in the topmost via as the
INVITE.
Value Meaning
100 Rfc3261
200 Rfc3261WithoutAck
Parameter Description
Enable The Require Header is ignored and no validation about these options-tags is performed.
Disable The Require Header options-tags are validated and, when an option-tag is not supported, a
420 (Bad Extension) response is sent.
The supported options-tags are:
• * 100rel
• * replaces
• * timer
Value Meaning
0 disable
1 enable
Parameter Description
Value Meaning
100 Send180Ringing
200 Send183WithSdp
Parameter Description
Value Meaning
100 TemporarilyUnavailable
200 BusyHere
Parameter Description
UnsupportedMediaType The SIP error code 415 'Unsupported Media Type' is returned if the Content-
Type is invalid; the payload is missing or the SDP content is invalid.
NotAcceptableHere The SIP error code 488 'Not Acceptable Here' is returned if the SDP content is
invalid.
Value Meaning
415 UnsupportedMediaType
488 NotAcceptableHere
Macro Description
Parameter Description
UnsupportedMediaType The unit responds with the SIP error code 415 'Unsupported Media Type'.
Ok The unit responds with a 200 OK.
Value Meaning
200 Ok
415 UnsupportedMediaType
Unsupported Content-Type
You can define the behaviour of the Aastra unit upon reception of a SIP packet containing multiple
unsupported Content-Type in the payload.
The following parameters are supported:
Table 171: Unsupported Content-Type Parameters
Parameter Description
Note: When ignored, unsupported Content-Type are treated as if they were not present in the packet.
Value Meaning
100 Reject
200 Allow
300 Ignore
The penalty box feature is used when a given host FQDN resolves to a non-responding address. When the
address times out, it is put into the penalty box for a given amount of time. During that time, the address in
question is considered as “non-responding” for all requests.
This feature is most useful when using DNS requests returning multiple or varying server addresses. It makes
sure that, when a host is down, users wait a minimal amount of time before trying a secondary host.
When enabled, this feature takes effect immediately on the next call attempt.
The penalty box feature is applied only when using UDP or TCP connections established with a FQDN. A
similar penalty box feature for the TLS persistent connections is available via the TLS Persistent Retry Interval
parameter. See “SIP Transport Type” on page 305 for more details.
Note: It is not the destination itself that is placed in the penalty box, but the combination of address, port
and transport. When a host is in the penalty box, it is never used to try to connect to a remote host unless it
is the last choice for the Aastra unit and there are no more options to try after this host.
Let’s say for instance that the Aastra unit supports both the UDP and TCP transports. It tries to reach endpoint
“B” for which the destination address does not specify a transport and there is no DNS SRV entry to specify
which transports to use in which order. It turns out that this endpoint “B” is also down. In this case, the Aastra
unit first tries to contact endpoint “B” via UDP. After a timeout period, UDP is placed in the penalty box and the
unit then tries to contact endpoint “B” via TCP. This fails as well and TCP is also placed in the penalty box.
Now, let’s assume endpoint “B” comes back to life and the Aastra unit tries again to contact it before UDP and
TCP are released from the penalty box. First, the unit tries UDP, but it is currently in the penalty box and there
is another transport left to try. The Aastra unit skips over UDP and tries the next target, which is TCP. Again,
TCP is still in the penalty box, but this time, it is the last target the Aastra unit can try, so penalty box or not,
TCP is used all the same to try to contact endpoint “B”.
There is a problem if endpoint “B” only supports UDP (RFC 2543-based implementation). Endpoint “B” is up,
but the Aastra unit still cannot contact it: with UDP and TCP in the penalty box, the unit only tries to contact
endpoint “B” via its last choice, which is TCP.
The same scenario would not have any problem if the penalty box feature was disabled. Another option is to
disable TCP in the Aastra unit, which makes UDP the only possible choice for the unit and forces to use UDP
even if it is in the penalty box.
You must fully understand the above problem before configuring this feature. Mixing endpoints that do not
support the same set of transports with this feature enabled can lead to the above problems, so it is suggested
to either properly configure SRV records for the hosts that can be reached or be sure that all hosts on the
network support the same transport set before enabling this feature.
2
3
2. In the Penalty Box section, enable the SIP penalty box feature by selecting Enable in the Penalty
Box Activation drop-down menu.
The penalty box is always “active”. This means that even if the feature is disabled, IP addresses are
marked as invalid, but they are still tried. This has the advantage that when the feature is enabled,
IP addresses that were already marked as invalid are instantly put into the penalty box.
3. Set the amount of time, in seconds, that a host spends in the penalty box in the Penalty Box Time
field.
Changing the value does not affect IP addresses that are already in the penalty box. It only affects
new entries in the penalty box.
4. Click Submit if you do not need to set other parameters.
Error Mapping
Standards Supported • RFC 3398: Integrated Services Digital Network (ISDN) User
Part (ISUP) to Session Initiation Protocol (SIP) Mappinga
a. Only the ISDN to SIP error mapping is supported.
You can override the default mapping of error causes defined in RFC 3398.The web interface offers two
sections:
The SIP To Cause Error Mapping section allows you to override the default mapping for SIP
You can also map any other custom code between 400 and 699.
The following standard ISDN cause numbers specified in Q.931 are available:
Resource unavailable:
Protocol error
34: No circuit/channel available.
96: Mandatory information element is missing.
38: Network out of order.
97: Message type non-existent or not
41: Temporary failure.
implemented.
42: Switching equipment congestion.
98: Message not compatible with call state or
43: Access information discarded. message type non-existent or not implemented.
44: Requested circuit/channel not available. 99: Information element non-existent or not
47: Resource unavailable, unspecified. implemented.
100: Invalid information element contents.
Service or option not available: 101: Message not compatible with call state.
55: Incoming calls barred within CUG. 102: Recovery on time expiry.
57: Bearer capability not authorized. 111: Protocol error, unspecified.
58: Bearer capability not presently available. Interworking
63: Service or option not available, unspecified. 127: Interworking, unspecified
You can also map any other custom code between 1 and 127.
This brings you to the Configure New SIP To Cause Error Mapping panel.
2. Enter the SIP code in the SIP Code field, then the corresponding ISDN cause number in the Cause
column.
You can use the Suggestion column’s drop-down menu to select between available code values.
3. Click Submit.
This brings you back to the main Misc web page.
You can delete an existing row by clicking the button.
You can modify the Cause value by typing a new code in the field. See “SIP To Cause Default Error
Mapping” on page 215 for the default mappings as per RFC 3398.
4. Click Submit if you do not need to set other parameters.
This brings you to the Configure New Cause To SIP Error Mapping panel.
2. Enter the ISDN cause number in the Cause column, then the corresponding SIP code in the SIP
Code field.
You can use the Suggestion column’s drop-down menu to select between available code values.
3. Click Submit.
This brings you back to the main Misc web page.
You can delete an existing row by clicking the button.
You can modify the SIP Code value by typing a new code in the field. See “Cause To SIP Default
Error Mapping” on page 217 for the default mappings as per RFC 3398.
4. Click Submit if you do not need to set other parameters.
Normal Event
1 unallocated number 404 Not Found
2 no route to network 404 Not Found
3 no route to destination 404 Not Found
16 normal call clearing --- BYE or CANCEL
17 user busy 486 Busy Here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable
Resource Unavailable
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
Additional Headers
You can define whether or not the Aastra unit uses additional SIP headers.
1
2
Parameter Description
None Silently ignores any incoming reason headers and does not
send the reason header.
SendQ850 Silently ignores incoming reason codes and sends the SIP
reason code when the original Q.850 code is available. The
reason code sent is not affected by the entries in the Error
Mapping SIP To Cause table.
ReceiveQ850 Uses the incoming Q.850 reason cause header. When
received, the reason code supersedes any entrie s in the
Error Mapping SIP To Cause table.
SendReceiveQ850 Uses the incoming Q.850 reason cause header and sends
the SIP reason code when the original Q.850 code is
available. When received, the reason code supersedes any
entries in the Error Mapping SIP To Cause table. The
reason code sent is not affected by the entries in the Error
Mapping SIP To Cause table.
2. Select how the Referred-By header is used when participating in a transfer in the Referred-By
Support drop-down menu.
Table 176: Referred-By Support Parameters
Parameter Description
PRACK
The Aastra unit supports reliable provisional responses (PRACK) as per RFC 3262. You can define this
support when acting as a user agent client and when acting as a user agent server.
The Aastra unit supports the UPDATE as per RFC 3311; however, its support is limited to reception.
1
2
Parameter Description
Receiving an UPDATE request to negotiate “early media” is supported only if you have selected
Supported.
2. Define the support of RFC 3262 (PRACK) when acting as user agent client in the UAC PRACK
Support drop-down menu.
Table 178: PRACK User Agent Client Parameters
Parameter Description
Parameter Description
Value Description
InterpretFirst Only the first provisional answer is interpreted. Following responses do not change the
state of the call and the SDP is ignored if present.
InterpretAll Each forked provisional response received by the unit is interpreted replacing the previous
one. If the response contains SDP, it replaces previous answers if any.
Value Meaning
100 InterpretFirst
200 InterpretAll
Session Refresh
This section allows you to define session refresh and session timers parameters. Session timers apply to the
whole unit.
1
2
1
2
Disabling this service is not recommended since it will make 'dead' calls impossible to detect.
See “Background Information” on page 222 for more details.
2. Set the session timer minimum expiration delay, in seconds, in the Minimum Expiration Delay (s)
field.
This is the minimum value, in seconds, for the periodical session refreshes. It must be equal to or
smaller than the maximum value. This value is reflected in the Min-SE header.
The Min-SE value is a threshold under which proxies and user agents on the signalling path are not
allowed to go. Increasing the minimum helps to reduce network traffic, but also makes “dead” calls
longer to detect.
3. Set the session timer maximum expiration delay, in seconds, in the Maximum Expiration Delay (s)
field.
This is the suggested maximum time, in seconds, for the periodical session refreshes. It must be
equal to or greater than the minimum value. This value is reflected in the Session-Expires header.
Increasing the maximum helps to reduce network traffic, but also makes “dead” calls longer to
detect.
Note: When the Maximum Expiration Delay value is lower than the Minimum Expiration Delay value, the
minimum and maximum expiration delay values in INVITE packets are the same as the value set in the
Minimum Expiration Delay field.
4. Select the method used for sending Session Refresh Requests in the Use UPDATE for Session
Refresh parameter.
Table 181: UPDATE for Session Refresh Parameters
Parameter Description
ReInvite Session Refresh Requests are sent with the INVITE method.
Update Session Refresh Requests are sent with the UPDATE
method.
Session Refresh Requests can be received via both methods, regardless of how this parameter is
configured.
5. Click Submit if you do not need to set other parameters.
Background Information
The following explains how the session timers are used.
A successful response (200 OK) to this refresh request indicates that the peer is still alive and reachable. A
timeout to this refresh request may mean that there are problems in the signalling path or that the peer is no
longer available. In that case, the call is shut down by using normal SIP means.
You can define whether or not to override the SIP domain used.
1
2
You can set the SIP transfer method when an endpoint is acting as the transferor in a blind transfer scenario.
Parameter Description
Semi Attended When blind transfer is invoked by the transferor, the device
sends immediately a REFER (it does not wait for the
reception of the 200OK response). This allows the call
transfer to be executed before the transfer-target answers.
The transferee and the target are then connected together
early and the transferee can hear the ringback from the
target until the target answers.
Semi Attended Confirmed When blind transfer is invoked by the transferor, the device
waits for reception of the 200 OK from the transfer-target
before sending a REFER to the transferee.
Semi Attended Cancelled This method is similar to the Semi Attended Transfer
method except that the INVITE sent to the transfer-target is
cancelled when the blind transfer is invoked before
receiving a 200OK (INVITE). In case where the transferor
receives a 200OK (INVITE) from the transfer-target before
receiving of a 487 Request Terminated, the transfer stays
ongoing and it behaves as a Semi Attended Confirmed
Transfer.
Diversion Configuration
Note: The Diversion feature is not available in the NI2 and QSIG signalling protocols. See “PRI
Configuration” on page 184 for more details on how to configure the signalling protocol.
Parameter Description
Parameter Description
Diversion Header The SIP gateway supports the SIP header 'Diversion' (RFC
5806) in received and sent INVITEs, as well as in 302
messages.
DNS Configuration
Parameter Description
The Aastra unit supports receiving event handling Notifications to start a remote reboot or a sync of
configuration for specific endpoint(s). The event handling Notifications "reboot" or "check-sync" is not
specified in an Allow-Events header. The Aastra unit supports the Notify without subscription.
It is recommended to use these event handling notifications only when the SIP transport is secure (TLS) or
when the firewall filters the requests sent to the unit.
Parameter Description
Parameter Description
2. Set the CheckSync column of each available gateway to define whether or not the SIP gateway can
transfer and run a configuration file via a SIP NOTIFY Event.
This specifies whether a transfer script via a SIP NOTIFY message event is supported or not for a
specific SIP gateway.
Table 186: CheckSync Event Handling Parameters
Parameter Description
Messaging Subscription
The Aastra unit allows you to add the username in the Request-URI of SUBSCRIBEs it sends.
Parameter Description
Enable The unit adds the username in the Request-URI of sent MWI
SUBSCRIBE requests.
Disable No username in Request-URI of MWI SUBSCRIBE
requests sent by the unit.
This chapter describes the voice and fax codec configuration parameters.
Codec descriptions.
How to enable and disable the codecs.
How to set the individual codecs’ parameters.
Codec Descriptions
The Aastra unit supports several voice and fax codecs. It also supports unicast applications, but not multicast
ones. All voice transport is done over UDP.
All the endpoints of the Aastra unit can simultaneously use the same codec (for instance, G.711 PCMA), or a
mix of any of the supported codecs. Set and enable these codecs for each endpoint.
Table 188: Codecs Comparison
The audio data is encoded as 8 bits per sample, after logarithmic scaling.
Table 189: G.711 Features
Feature Description
Feature Description
G.723.1
Standards Supported • ITU-T Recommendation G.723.1a
a. This codec is not available on the Aastra Series models.
Dual-rate speech coder for multimedia communications transmitting at 5.3 kbit/s and 6.3 kbit/s. This
Recommendation specifies a coded representation that can be used to compress the speech signal
component of multi-media services at a very low bit rate. The audio is encoded in 30 ms frames.
A G.723.1 frame can be one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s frame), or 4 octets.
These 4-octet frames are called SID frames (Silence Insertion Descriptor) and are used to specify comfort
noise parameters.
Table 190: G.723.1 Features
Feature Description
G.726
Standards Supported • ITU-T Recommendation G.726: 40, 32, 24, 16 kbit/s adaptive
differential pulse code modulation (ADPCM)
Algorithm recommended for conversion of a single 64 kbit/s A-law or U-law PCM channel encoded at 8000
samples/s to and from a 40, 32, 24, or 16 kbit/s channel. The conversion is applied to the PCM stream using
an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique.
Table 191: G.726 Features
Feature Description
Feature Description
G.729
Standards Supported • ITU-T Recommendation G.729
Coding of speech at 8 kbit/s using conjugate structure-algebraic code excited linear prediction (CS-ACELP).
For all data rates, the sampling frequency (and RTP timestamp clock rate) is 8000 Hz.
A voice activity detector (VAD) and comfort noise generator (CNG) algorithm in Annex B of G.729 is
recommended for digital simultaneous voice and data applications; they can be used in conjunction with G.729
or G.729 Annex A. A G.729 or G.729 Annex A frame contains 10 octets, while the G.729 Annex B comfort
noise frame occupies 2 octets.
The Aastra unit supports G.729A and G.729AB for encoding and G.729, G.729A and G.729AB for decoding.
Table 192: G.729 Features
Feature Description
Clear Mode
Standards Supported • RFC 4040: RTP Payload Format for a 64 kbit/s Transparent
Call
The Clear Mode codec is similar to the G.711 codec but without any modification of the 64 kbit/s payload (no
encoding or decoding). The Clear Mode codec thus does not have echo cancellation and a fix jitter buffer.
Clear Mode is a method to carry 64 kbit/s channel data transparently in RTP packets. This codec always uses
the RTP transport.
Table 193: Clear Mode Features
Feature Description
Clear Channel
Standards Supported • RFC 4040: RTP Payload Format for a 64 kbit/s Transparent
Call
The Clear Channel codec is similar to the G.711 codec but without any modification of the 64 kbit/s payload
(no encoding or decoding). The Clear Channel codec thus does not have echo cancellation and a fix jitter
buffer. Clear Channel is a method to carry 64 kbit/s channel data transparently in RTP packets. The Clear
Channel codec follows the specification of RFC 4040 and uses the “X-CLEAR-CHANNEL” mime type instead
of the “CLEARMODE” mime type.
This codec always uses the RTP transport.
Table 194: Clear Channel Features
Feature Description
The Clear Channel codec is similar to the G.711 codec but without any modification of the 64 kbit/s payload
(no encoding or decoding). The X-CCD Clear Channel codec thus does not have echo cancellation and a fix
jitter buffer. The X-CCD Clear Channel is a method to carry 64 kbit/s channel data transparently in RTP
packets. The Clear Channel codec follows the specification of RFC 4040 and uses the “X-CCD” mime type
instead of the “CLEARMODE” mime type.
This codec always uses the RTP transport.
Table 195: X-CCD Clear Channel Features
Feature Description
Packetization time Range of 10 ms to 100 ms with increments of 1 ms. See “X-CCD Clear
Channel Codec Parameters” on page 246 for more details.
Voice Activity Detection (VAD) N/A
Comfort noise N/A
Payload type Configurable as per “X-CCD Clear Channel Codec Parameters” on
page 246.
Available for voice Yes
Available for fax Yes
Available for modem Yes
T.38
Standards Supported • ITU-T Recommendation T.38 version 0
T.38 fax relay is a real-time fax transmission; that is, two fax machines communicating with each other as if
there were a direct phone line between the two. T.38 is called a fax relay, which means that instead of sending
inband fax signals, which implies a loss of signal quality, it sends those fax signals out-of-band in a T.38
payload, so that the remote end can reproduce the signal locally.
Table 196: T.38 Features
Feature Description
T.38 is an unsecure protocol, thus will not be used along with secure RTP (SRTP), unless the Allow Unsecure
T.38 with Secure RTP parameter has been set to Enable. See “Chapter 32 - Security” on page 377 for more
details.
Codec Parameters
The Codec section allows you to enable or disable the codecs of the Aastra unit, as well as access the codec-
specific parameters.
3 4 5 6
2. Select to which endpoint (interface) you want to apply the changes in the Select Endpoint drop-
down menu at the top of the window.
You have the choice between Default and the interfaces of your Aastra unit. The number of
interfaces available vary depending on the Aastra unit model you have.
You can also perform this operation in the codec-specific pages.
3. Select whether or not you want to override one or more of the available default codecs parameters
in the Endpoint Specific column of the corresponding codec(s).
This column is available only in the specific endpoints configuration.
You can also perform this operation in the codec-specific pages.
4. Enable one or more codecs for voice transmission by selecting Enable in the Voice column of the
corresponding codec(s).
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
VAD defines how the Aastra unit sends information pertaining to silence. This allows the unit to detect when
the user talks, thus avoiding to send silent RTP packets. This saves on network resources. However, VAD
may affect packets that are not really silent (for instance, cut sounds that are too low). VAD can thus slightly
affect the voice quality.
1
2
2. Enable the G.711 and G.726 Voice Activity Detection (VAD) by selecting the proper setting in the
Enable (G711 and G726) drop-down menu.
Table 197: G.711/G.726 VAD Settings
Setting Description
The difference between transparent and conservative is how “aggressive” the algorithm considers
something as an inactive voice and how “fast” it stops the voice stream. A setting of conservative is
a little bit more aggressive to react to silence compared to a setting of transparent.
3. Click Submit if you do not need to set other parameters.
The following are the G.711 codec parameters you can set. There are two sections for G.711:
G.711 a-law
G.711 u-law
These sections use the same parameters, so only one of them is described below.
3
4
5
6
7
8
3. Select whether or not you want to override the G.711 parameters set in the Default configuration in
the Use Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the G.711 codec for voice transmission by selecting Enable in the Voice Transmission drop-
down menu.
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
5. Set the default priority for voice in the Voice Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
6. Enable the G.711 codec for data transmission by selecting Enable in the Data Transmission drop-
down menu.
This indicates if the codec can be selected for data transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
7. Set the default priority for data in the Data Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
8. Select the minimum and maximum packetization time values for the codec in the Minimum
Packetization Time and Maximum Packetization Time drop-down menus.
The packetization time (also called packetization period or ptime) is the duration, in ms, of the voice
packet. The range is from 10 ms to 30 ms with increments of 10 ms.
For the reception, the range is extended from 10 ms to 100 ms with increments of 1 ms only if the
stream is not encrypted (SRTP).
9. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
The following are the G.723 codec parameters you can set.
Note that the G.723 codec is not available on the Asatra TA7102i Series models.
3
4
5
6
7
3. Select whether or not you want to override the G.723 parameters set in the Default configuration in
the Use Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the G.723 codec for voice transmission by selecting Enable in the Voice Transmission drop-
down menu.
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
5. Set the default priority for voice in the Voice Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
6. Select the G.723 bit rate in the Bit Rate drop-down menu.
You have the following choices:
• 53 Kbs
• 63 Kbs
7. Select the minimum and maximum packetization time values for the codec in the Minimum
Packetization Time and Maximum Packetization Time drop-down menus.
The packetization time (also called packetization period or ptime) is the duration, in ms, of the voice
packet. The range is from 30 ms to 60 ms with increments of 30 ms.
For the reception, the range is extended from 30 ms to 120 ms with increments of 30 ms only if the
kstream is not encrypted (SRTP).
8. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
The following are the G.726 codecs parameters you can set. There are four sections for G.726:
G.726 16 Kbps
G.726 24 Kbps
G.726 32 Kbps
G.726 40 Kbps
These sections offer almost the same parameters, except that you cannot use the G.726 16 Kbps and
G.726 24 Kbps codecs for fax transmission.
3
4
5
6
7
8
9
3. Select whether or not you want to override the G.726 parameters set in the Default configuration in
the Use Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the corresponding G.726 codec for voice transmission by selecting Enable in the Voice
Transmission drop-down menu.
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
5. Set the default priority for voice in the Voice Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
6. Enable the codec for data transmission by selecting Enable in the Data Transmission drop-down
menu.
This indicates if the codec can be selected for data transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
This menu is not available for the G.726 16 Kbps and G.726 24 Kbps codecs.
You can also perform this operation in the main CODEC section.
7. Set the default priority for data in the Data Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
This field is not available for the G.726 16 Kbps and G.726 24 Kbps codecs.
8. Set the G.726 actual RTP dynamic payload type used in an initial offer in the Payload Type field.
The payload types available are as per RFC 3551. The values range from 96 to 127. The default
values are as follows:
Table 198: G.726 Default Payload Type
9. Select the minimum and maximum packetization time values for the G.726 codec in the Minimum
Packetization Time and Maximum Packetization Time drop-down menus.
The packetization time (also called packetization period or ptime) is the duration, in ms, of the voice
packet. The range is from 10 ms to 30 ms with increments of 10 ms.
For the reception, the range is extended from 10 ms to 100 ms with increments of 1 ms only if the
stream is not encrypted (SRTP).
10. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
The following are the G.729 codec parameters you can set.
3
4
5
6
7
3. In the G.729 section, select whether or not you want to override the G.729 parameters set in the
Default configuration in the Use Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the G.729 codec for voice transmission by selecting Enable in the Voice Transmission drop-
down menu.
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
5. Set the default priority for voice in the Voice Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
6. Select the minimum and maximum packetization time values for the codec in the Minimum
Packetization Time and Maximum Packetization Time drop-down menus.
The packetization time (also called packetization period or ptime) is the duration, in ms, of the voice
packet. The range is from 20 ms to 80 ms with increments of 10 ms.
For reception, the range is extended from 10 ms to 100 ms with increments of 10 ms only if the
stream is not encrypted (SRTP).
7. Select the G.729 Voice Activity Detection (VAD) in the Built-in Voice Activity Detection (VAD) drop-
down menu.
Table 199: G.729 VAD
Parameter Description
VAD defines how the Aastra unit sends information pertaining to silence. This allows the unit to
detect when the user talks, thus avoiding to send silent RTP packets. This saves on network
resources. However, VAD may affect packets that are not really silent (for instance, cut sounds that
are too low). VAD can thus slightly affect the voice quality.
G.729 has a built-in VAD in its Annex B version. It is recommended for digital simultaneous voice
and data applications and can be used in conjunction with G.729 or G.729 Annex A. A G.729 or
G.729 Annex A frame contains 10 octets, while the G.729 Annex B frame occupies 2 octets. The
CN packets are sent in accordance with annex B of G.729.
8. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
The following are the Clear Mode codec parameters you can set.
3
4
5
6
7
8
9
3. Select whether or not you want to override the Clear Mode parameters set in the Default
configuration in the Use Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the Clear Mode codec for voice transmission by selecting Enable in the Voice Transmission
drop-down menu.
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
5. Set the default priority for voice in the Voice Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
6. Enable the Clear Mode codec for data transmission by selecting Enable in the Data Transmission
drop-down menu.
This indicates if the codec can be selected for data transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
7. Set the default priority for data in the Data Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
8. Set the Clear Mode RTP dynamic payload type used in an initial offer in the Payload Type field.
The payload types available are as per RFC 3551. The values range from 96 to 127. The default
value is 125.
9. Select the minimum and maximum packetization time values for the codec in the Minimum
Packetization Time and Maximum Packetization Time drop-down menus.
The packetization time (also called packetization period or ptime) is the duration, in ms, of the voice
packet. The range is from 10 ms to 30 ms with increments of 10 ms.
For the reception, the range is extended from 10 ms to 100 ms with increments of 1 ms only if the
stream is not encrypted (SRTP).
10. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
The following are the Clear Channel codec parameters you can set.
3
4
5
6
7
8
9
3. Select whether or not you want to override the Clear Channel parameters set in the Default
configuration in the Use Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the Clear Channel codec for voice transmission by selecting Enable in the Voice
Transmission drop-down menu.
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
5. Set the default priority for voice in the Voice Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
6. Enable the Clear Channel codec for data transmission by selecting Enable in the Data
Transmission drop-down menu.
This indicates if the codec can be selected for data transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
7. Set the default priority for data in the Data Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
8. Set the Clear Channel RTP dynamic payload type used in an initial offer in the Payload Type field.
The payload types available are as per RFC 3551. The values range from 96 to 127. The default
value is 125.
9. Select the minimum and maximum packetization time values for the codec in the Minimum
Packetization Time and Maximum Packetization Time drop-down menus.
The packetization time (also called packetization period or ptime) is the duration, in ms, of the voice
packet. The range is from 10 ms to 30 ms with increments of 10 ms.
For the reception, the range is extended from 10 ms to 100 ms with increments of 1 ms only if the
stream is not encrypted (SRTP).
10. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
The following are the X-CCD Clear Channel codec parameters you can set.
3
4
5
6
7
8
9
3. Select whether or not you want to override the X CCD parameters set in the Default configuration
in the Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the X CCD codec for voice transmission by selecting Enable in the Voice Transmission
drop-down menu.
This indicates if the codec can be selected for voice transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
5. Set the default priority for voice in the Voice Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
6. Enable the X CCD codec for data transmission by selecting Enable in the Data Transmission drop-
down menu.
This indicates if the codec can be selected for data transmission. If enabled, this codec is listed as
supported for this specific endpoint. Otherwise, it is ignored.
You can also perform this operation in the main CODEC section.
7. Set the default priority for data in the Data Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: The codec used is also related to the SIP negotiation. The priority order affects the SIP negotiation,
which decides on the codec to use.
8. Set the X CCD RTP dynamic payload type used in an initial offer in the Payload Type field.
The payload types available are as per RFC 3551. The values range from 96 to 127. The default
value is 125.
9. Select the minimum and maximum packetization time values for the codec in the Minimum
Packetization Time and Maximum Packetization Time drop-down menus.
The packetization time (also called packetization period or ptime) is the duration, in ms, of the voice
packet. The range is from 10 ms to 30 ms with increments of 10 ms.
10. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
Fax Parameters
The Aastra unit handles G3 fax transmissions at speeds up to 14.4 kbps. Automatic fax mode detection is
standard on all endpoints. Real-Time Fax Over UDP with the T.38 protocol stack is also available.
A fax call works much like a regular voice call, with the following differences:
1. The fax codec may be re-negotiated by using a re-INVITE.
2. The goal of the re-INVITE is to allow both user agents to agree on a fax codec, which is either:
a. Clear channel (G.711 or G.726) without Echo Cancellation nor Silence Suppression
(automatically disabled).
b. T.38.
3. Upon fax termination, if the call is not BYE, the previous voice codec is recovered with another re-
INVITE.
All endpoints of the Aastra unit can simultaneously use the same codec (for instance, T.38), or a mix of any
of the supported codecs. Set and enable these codecs for each endpoint.
INVITE
[…] […]
m=audio 5004 RTP/AVP 18 0 13 m=audio 5006 RTP/AVP 18 0 13
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
200 OK
Ringing/Trying
ACK
User User
Agent RTP=PCMU (Echo Cancellation + Silence Suppression = disabled)
Agent
#1 #2
No re-INVITE!!
There is no need for a re-INVITE since the far end already supports the
data codec (PCMU).
When your SDP capabilities are inserted in a SIP packet, it implies that
you can receive any of these capabilities at any given time without notice.
In this case, both ends should switch to clear channel automatically upon
detection of the fax transmission.
Fax is terminated
BYE
200 OK
DSP Limitation
The Aastra unit currently suffers from a limitation of its DSP. Because of this limitation, the voice does not
switch back to the original negotiated codec after a clear channel fax is performed.
The Aastra unit cannot detect the end of a clear channel fax, which means that the unit cannot switch back to
the original negotiated codec if this codec was not a clear channel codec, e.g., a session established in G.729.
When the unit detects a fax, it automatically switches to a negotiated clear channel codec such as PCMU (if
there is no T.38 or if T.38 negotiation failed). Once the fax is terminated, the Aastra unit is not notified by the
DSP. The unit thus stays in the clear channel codec and does not switch back to G.729.
T.38 Fax
The Aastra unit can send faxes in T.38 mode over UDP. T.38 is used for fax if both units are T.38 capable;
otherwise, transmission in clear channel over G.711 as defined is used (if G.711 µ-law and/or G.711 A-law are
enabled). If no clear channel codecs are enabled and the other endpoint is not T.38 capable, the fax
transmission fails.
Caution: The Aastra unit opens the T.38 channel only after receiving the “200 OK” message from the peer.
This means that the Aastra unit cannot receive T.38 packets before receiving the “200 OK”. Based on RFC
3264, the T.38 channel should be opened as soon as the unit sends the “INVITE” message.
The quality of T.38 fax transmissions depends upon the system configuration, type of call control system used,
type of Aastra units deployed, as well as the model of fax machines used. Should some of these conditions
be unsatisfactory, performance of T.38 fax transmissions may vary and be reduced below expectations.
Note: Aastra recommends not to use a fax that does not send a CNG tone. If you use such a fax to send a
fax communication to the public network, this might result in a communication failure.
INVITE
[…] […]
m=audio 5004 RTP/AVP 0 18 4 8 13 m=audio 5006 RTP/AVP 0 18 4 8 13
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000 a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
200 OK
Ringing/Trying
ACK
Fax is terminated
INVITE
[…] […]
m=audio 5004 RTP/AVP 0 18 4 8 13 m=audio 5006 RTP/AVP 0 18 4 8 13
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000 a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
200 OK
Trying
ACK
BYE
200 OK
4
5
6
7
8
9
10
3. In the T.38 section, select whether or not you want to override the T.38 parameters set in the Default
configuration in the Use Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
You can also perform this operation in the main CODEC section.
4. Enable the T.38 codec by selecting Enable in the Enable drop-down menu.
You can also perform this operation in the main CODEC section.
5. Set the default priority for fax in the Priority field.
This sets the priority between different codecs. Codecs with a higher priority are used first, a priority
of 0 being the lowest priority. For instance, a codec with priority 3 is used before a codec with priority
2. The maximum priority is 10.
The Aastra unit uses an internal order for codecs with the same priority.
Note: Currently, the only T.38 priority accepted is 10. Priority between 1 and 9 is refused.
6. Set the number of redundancy packets sent with the current packet in the Redundancy Level field.
This is the standard redundancy offered by T.38. Available values range from 1 to 5. Please see
step 7 for additional reliability options for T.38.
7. Set the T.38 input signal detection threshold in the Detection Threshold drop-down menu.
Lowering the threshold allows detecting lower amplitude fax signals. The following values are
available:
• Default: (-26 dB)
• Low: (-31 dB)
• Lowest: (-43 dB)
8. For additional reliability, define the number of times T.38 packets are retransmitted in the Frame
Redundancy Level field.
This field is available only in the default endpoint configuration.
This only applies to the T.38 packets where the PrimaryUDPTL contains the following T.38 data
type:
• HDLC_SIG_END,
• HDLC_FCS_OK_SIG_END,
• HDLC_FCS_BAD_SIG_END and
• T4_NON_ECM_SIG_END
9. Define whether or not the Aastra unit sends no-signal packets during a T.38 fax transmission in the
No Signal drop-down menu.
This menu is available only in the default endpoint configuration.
When enabled, the unit ensures that, during a T.38 fax transmission, data is sent out at least every
time the No Signal Timeout delay expires. The Aastra unit sends no-signal packets if no meaningful
data have been sent for a user-specified period of time.
10. Set the period, in seconds, at which no-signal packets are sent during a T.38 transmission in the No
Signal Timeout field.
This field is available only in the default endpoint configuration.
No-signal packets are sent out if there are no valid data to send.
11. Click Submit if you do not need to set other parameters.
You can also access the specific parameters of another codec by selecting the codec in the Select
CODEC drop-down menu at the top of the page.
Voice /
Voiceband
data call
Complete fax/modem codec
selection procedure .
Tones are detected on the telephony ports except for
the CED, which can also be detected on the IP side CNG tone No CED tone V.21 tone
No No Continue call
detected? detected? detected?
Yes
Yes
Evaluate Yes
BehaviorOnCed
ToneDetection
Passthrough
Stop sending Faxmode
voice codec. Start T.38 is
Yes
buffering T.38 enabled?
packets
Current voice
Send a re-INVITE Continue call with
No codec is data - Yes
for T.38 current codec
capable?
No
Evaluate
BehaviorOnT38Invite List of
T.38 accepted negotiated Switch to highest
No NotAccepted.Behavior
by peer? codecs negotiated priority
according to error Yes
code contains a data codec and
data-capable continue call
Yes codec?
ReInviteForClear
ChannelOnly (default) No
Start sending T.38
packets Switch to highest
configured priority G.711
data codec
At least one data (PCMU if all disabled )
codec is enabled
on the device ? ReInviteOn
Continue T.38 fax NoNegotiated
DataCodec
No Evaluate
ReEstablish interopB ehavior ReInviteOn
Yes Audio Continue call
DropCall OnMachine FaxT38Only
Detection
UsePrevious
MediaNegiciation
Send SIP re- Disable fax/modem detection
INVITE for data- and send SIP re-INVITE for
capable codecs voice -capable codecs
New codec
Terminate call No accepted by
peer ?
Yes
Switch to
Restore the previouly
selected data
used voice codec and
codec and
continue call
continue call
29 Security
This chapter describes how to properly configure the security parameters of the Aastra unit.
Standards Supported • RFC 3711: The Secure Real-time Transport Protocol (SRTP)
(Supports only the AES-CM encryption)
• RFC 3830: MIKEY: Multimedia Internet KEYing (Compliant
for method Pre-Shared Key only)
• RFC 4567: Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)
• RFC 4568: SDES: Security Descriptions for Media Streams
Introduction
You can define security features on the Aastra unit. This section applies to media security parameters.
Applying security on the Aastra unit involves several steps:
Properly set the time on the Aastra unit by configuring a valid SNTP server (“SNTP
Configuration” on page 93) and time zone (“Time Configuration” on page 94).
Transfer a valid CA certificate into the Aastra unit (“Chapter 46 - Certificates Management” on
page 557).
Use secure signalling by enabling the TLS transport protocol (“Chapter 28 - SIP Transport
Parameters” on page 305).
Caution: If you enable Secure RTP (SRTP) on at least one line, it is acceptable to have the secure SIP
transport (TLS) disabled for testing purposes. However, you must never use this configuration in a
production environment, since an attacker could easily break it. Enabling TLS for SIP Transport is strongly
recommended and is usually mandatory for security interoperability with third-party equipments.
Caution: When using a codec other than G.711, enabling Secure RTP (SRTP) has an impact on the Aastra
unit’s overall performance as SRTP requires CPU power. The more lines use SRTP, the more overall
performance is affected. See also “DSP Limitation” on page 429 for more details on resources limitations
with SRTP and conferences.
Security Parameters
The Security section allows you to secure the RTP stream (media) of the Aastra unit.
Since the SRTP encryption and authentication needs more processing, the number of calls that the Aastra unit
can handle simultaneously may be reduced, depending of the codecs enabled. You could set the Aastra unit
not to impact the number of simultaneous calls by enabling only G.711 codecs and disabling every other voice
or data codec, even T.38.
The Aastra unit supports the MIKEY protocol using pre-shared keys (MIKEY-PS) or the SDES protocol for
negotiating SRTP keys.
4
5
6
2. Select to which endpoint (interface) you want to apply the changes in the Select Endpoint drop-
down menu at the top of the window.
You have the choice between Default and the interfaces of your Aastra unit. The number of
interfaces available vary depending on the Aastra unit model you have.
3. Select whether or not you want to override one or more of the available default security parameters
in the Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
4. In the Security section of the Security page, select the RTP payload mode in the Mode drop-down
menu.
The unit relies on these modes when negotiating an audio stream.
Table 200: Default RTP Mode
Mode Description
Unsecure The Aastra unit supports only unsecure RTP. It rejects secure RTP
offers it receives.
Secure The Aastra unit supports only secure RTP. It rejects unsecure RTP
offers it receives.
Secure with fallback The Aastra unit supports both secure and unsecure RTP. It prioritizes
secure RTP but permits unsecure RTP fallback when the remote peer
does not support security.
The TLS SIP transport must usually be enabled for secure audio negotiation via SDP (refer to the
Caution box above). See “Chapter 28 - SIP Transport Parameters” on page 305 for more details.
The RTP mode is reflected in the SIP/SDP payload, with a RTP/AVP for unsecure RTP, and a RTP/
SAVP for secure RTP.
The following basic rules apply when sending units capabilities via SDP:
• When the RTP mode is set to Unsecure, the Aastra unit offers/answers with only one
active RTP/AVP audio stream. Any other audio stream present in the offer is disabled
in the answer.
• When the RTP mode is set to Secure, the Aastra unit offers/answers with only one
active RTP/SAVP audio stream. Any other audio stream present in the offer is disabled
in the answer.
• When the RTP mode is set to Secure with fallback, the Aastra unit offers one RTP/AVP
and one RTP/SAVP audio streams. The unit answers with only the most secure stream.
• If the remote unit answers to an offer with both RTP/AVP and RTP/SAVP streams
enabled, a new offer is sent with only RTP/SAVP enabled.
5. Select the key management protocol for SRTP in the Key Management drop-down menu.
Table 201: Key Management Protocol
Protocol Description
Encryption Description
Mode Description
Parameter Description
disable Accept packets from all sources. This is the default value.
enable Silently discard incoming RTP packets with source address and port differing from the
destination address and port of outgoing packets.
Value Meaning
0 disable
1 enable
The Aastra unit collects meaningful statistics that can be read via the web interface. This chapter describes
how to read and configure the RTP statistics.
Note that the RTP statistics are also available via SNMP and CLI.
Statistics Displayed
Octets Tx Number of octets transmitted during the Number of octets transmitted during the
connection. collection period. This value is obtained by
cumulating the octets transmitted in all
connections that were active during the
collection period.
Octets Rx Number of octets received during the Number of octets received during the
connection. collection period. This value is obtained by
cumulating the octets received in all
connections that were active during the
collection period.
Packets Tx Number of packets transmitted during the Number of packets transmitted during the
connection. collection period. This value is obtained by
cumulating the packets transmitted in all
connections that were active during the
collection period.
Packets Rx Number of packets received during the Number of packets received during the
connection. collection period. This value is obtained by
cumulating the packets received in all
connections that were active during the
collection period.
Packets Lost Number of packets lost during the Number of packets lost during the collection
connection. This value is obtained by period. This value is obtained by cumulating
substracting the expected number of the packets lost in all connections that were
packets based on the sequence number active during the collection period.
from the number of packets received.
Min. Jitter Minimum interarrival time, in ms, during the Minimum interarrival time, in ms, during the
connection. All RTP packets belonging to collection period. This value is the lowest
the connection and received at the RTP interarrival jitter for all connections that were
level are considered in the calculation. active during the collection period.
Max. Jitter Maximum interarrival time, in ms, during the Maximum interarrival time, in ms, during the
connection. All RTP packets belonging to collection period. This value is the highest
the connection and received at the RTP interarrival jitter for all connections that were
level are considered in the calculation. active during the collection period.
Avg. Jitter Average interarrival time, in ms, during the Average interarrival time, in ms, during the
connection. All RTP packets belonging to collection period. This value is the weighted
the connection and received at the RTP average of the interarrival jitter for all
level are considered in the calculation. connections that were active during the
collection period. For each connection, the
total jitter of packets received during the
collection period and the total number of
packets received during the collection period
are used in the weighted average
calculation.
Min. Latency Minimum latency, in ms, during the Minimum latency, in ms, during the
connection. The latency value is computed collection period. This value is the lowest
as one half of the round-trip time, as latency for all connections that were active
measured through RTCP. during the collection period.
Max. Latency Maximum latency, in ms, during the Maximum latency, in ms, during the
connection. The latency value is computed collection period. This value is the highest
as one half of the round-trip time, as latency for all connections that were active
measured through RTCP. during the collection period.
Avg. Latency Average latency, in ms, during the Average latency, in ms, during the collection
connection. The latency value is computed period. This value is the weighted average
as one half of the round-trip time, as of the latency for all connections that were
measured through RTCP. active during the collection period. For each
connection, the total latency of packets
received during the collection period and the
total number of packets received during the
collection period are used in the weighted
average calculation.
Statistics Configuration
You can define how to collect the statistics. The statistics are sent as syslog messages, so you must properly
set the syslog information before setting the statistics. You must set the Media IP Transport (MIPT) service to
the Info or Debug level. See “Syslog Daemon Configuration” on page 71 for more details on how to configure
the Syslog.
2
3
4
2. Set the Collection Period field with the collection period duration in minutes.
Putting a value of 0 disables the collection period statistics feature.
3. Set the End-of-Connection Notification drop-down menu with the proper behaviour.
Table 206: End-of-Connection Notification
Parameter Description
4. Set the End-of-Period Notification drop-down menu with the proper behaviour.
Table 207: End-of-Period Notification
Parameter Description
Channel Statistics
This section describes how to access data available only in the MIB parameters of the Aastra unit. You can
display these parameters as follows:
by using a MIB browser
by using the CLI
The channel statistics are cumulated RTP statistics for all calls using a specific channel of a telephony
interface. Statistics are updated at the end of each call.
The statistics are associated to the channel in use at the end of the call. In some cases, such as in hold/resume
scenarios, the channel assignment may change during a call. This can result in discrepancies between the
RTP statistics and the actual usage of the telephony interface.
The following are the channel statistics the Aastra unit keeps.
Table 208: Channel Statistics
This chapter describes how to configure parameters that apply to all codecs.
The Jitter Buffer section allows you to configure parameters to reduce jitter buffer issues.
3
4
5
6
7
8
9
10
2. Select to which endpoint (interface) you want to apply the changes in the Select Endpoint drop-
down menu at the top of the window.
You have the choice between Default and the interfaces of your Aastra unit. The number of
interfaces available vary depending on the Aastra unit model you have.
3. In the Jitter Buffer section, if you have selected a specific endpoint, select whether or not you want
to override the jitter buffer parameters set in the Default configuration in the Endpoint Specific drop-
down menu.
This menu is available only in the specific endpoints configuration.
4. Select the jitter buffer level in the Level drop-down menu.
Jitter is an abrupt and unwanted variation of one or more signal characteristics, such as the interval
between successive pulses or the frequency or phase of successive cycles. An adaptive jitter buffer
usually consists of an elastic buffer in which the signal is temporarily stored and then retransmitted
at a rate based on the average rate of the incoming signal.
Table 209: Jitter Buffer Levels
Level Description
Optimize Latency The jitter buffer is set to the lowest effective value to minimize the latency.
Voice cut can be heard if the network is not optimal. The predefined values
are as follows:
• Minimum value: 10 ms
• Maximum value: 40 ms
Normal The jitter buffer tries to find a good compromise between the latency and the
voice quality. This setting is recommended in private networks. The
predefined values are as follows:
• Minimum value: 30 ms
• Maximum value: 90 ms
Optimize Quality The jitter buffer is set to a high value to minimize the voice cuts at the cost of
high latency. This setting is recommended in public networks. The
predefined values are as follows:
• Minimum value: 50 ms
• Maximum value: 125 ms
Fax / Modem The jitter buffer is set to maximum. The Fax/Modem transmission is very
sensitive to voice cuts but not to latency, so the fax has a better chance of
success with a high buffer. The predefined values are as follows:
• Minimum value: 70 ms
• Maximum value: 135 ms
Custom The jitter buffer uses the configuration of the Minimum and Maximum
variables (Steps 4 and 5).
5. If you have selected the Custom level, define the target jitter buffer length in the Minimum field of
the Voice Call part.
The adaptive jitter buffer attempts to hold packets to the minimal holding time. This is the minimal
delay the jitter buffer adds to the system. The minimal jitter buffer is in ms and must be equal to or
smaller than the maximal jitter buffer.
Values range from 0 ms to 135 ms. The default value is 30 ms. You can change values by
increments of 1 ms, but Aastra recommends to use multiples of 5 ms. The minimal jitter buffer
should be a multiple of ptime.
It is best not to set the minimal jitter value below the default value. Setting a minimal jitter buffer
below 5 ms could cause an error. Jitter buffer adaptation behaviour varies from one codec to
another. See “About Changing Jitter Buffer Values” on page 265 for more details.
6. If you have selected the Custom level, define the maximum jitter buffer length in the Maximum field
of the Voice Call part.
This is the highest delay the jitter buffer is allowed to introduce. The jitter buffer length is in ms and
must be equal to or greater than the minimum jitter buffer.
Values range from 0 ms to 135 ms. The default value is 125 ms. You can change values by
increments of 1 ms, but Aastra recommends to use multiples of 5 ms. The maximal jitter buffer
should be a multiple of ptime.
The maximum jitter buffer value should be equal to the minimum jitter buffer value + 4 times the
ptime value. Let’s say for instance that:
• Minimum jitter buffer value is 30 ms
• Ptime value is 20 ms
The maximum jitter buffer value should be: 30 + 4x20 = 110 ms
7. If you have selected the Custom level, define the voiceband data custom jitter buffer type in the
Playout Type drop-down menu of the Data Call part.
This is the algorithm to use for managing the jitter buffer during a call. The Nominal field value
serves as the delay at the beginning of the call and might be adapted afterwards based on the
selected algorithm.
Table 210: Voiceband Data Custom Jitter Buffer Type
Level Description
Adaptive The nominal delay varies based on the estimated packet jitter. Playout
Immediately adjustment is done immediately when the actual delay goes out of bounds of
a small window around the moving nominal delay.
Adaptive Silence The nominal delay varies based on the estimated packet jitter. Playout
adjustment is done based on the actual delay going out of bounds of a small
window around the moving nominal delay. The adjustment is deferred until
silence is detected (either from playout buffer underflow or by analysis of
packet content). Playout adjustment is also done when overflow or
underflow events occur.
Fixed The nominal delay is fixed to the value of the Nominal field value and does
not change thereafter. Playout adjustment is done when overflow or
underflow events occur.
8. If you have selected the Custom level, define the voiceband data jitter buffer minimal length (in
milliseconds) in the Minimum field of the Data Call part.
The voiceband data jitter buffer minimal length is the delay the jitter buffer tries to maintain. The
minimal jitter buffer MUST be equal to or smaller than the voiceband data maximal jitter buffer.
The minimal jitter buffer should be a multiple of ptime.
This value is not available when the Playout Type drop-down menu is set to Fixed.
9. If you have selected the Custom level, define the voiceband data custom jitter buffer nominal length
in the Nominal field of the Data Call part.
The jitter buffer nominal length (in milliseconds) is the delay the jitter buffer uses when a call begins.
The delay then varies depending on the type of jitter buffer.
In adaptive mode, the nominal jitter buffer should be equal to (voice band data minimal jitter buffer
+ voice band data maximal jitter buffer) / 2.
10. If you have selected the Custom level, define the default voiceband data custom jitter buffer
maximal length in the Maximum field of the Data Call part.
The jitter buffer maximal length (in milliseconds) is the highest delay the jitter buffer is allowed to
introduce. The maximal jitter buffer MUST be equal to or greater than the minimal jitter buffer.
The maximal jitter buffer should be a multiple of ptime.
The maximal jitter buffer should be equal to or greater than voiceband data minimal jitter buffer + (4
* ptime) in adaptive mode.
See “About Changing Jitter Buffer Values” on page 265 for more details.
11. Click Submit if you do not need to set other parameters.
ONLY if the end-to-end delay measured matches the target jitter value.
For instance, if the target jitter value is 50 ms, the maximum jitter is 300 ms and the delay measured
is 260 ms, it would serve nothing to reduce the target jitter. However, if the target jitter value is
100 ms and the measured delay is between 100 ms and 110 ms, then you can lower the target jitter
from 100 ms to 30 ms.
Parameter Description
Disable The call is started in voice mode. A fax/modem tone detection triggers a transition from voice
to voiceband data according to the configuration in the Machine Detection Group
(“Miscellaneous Media Parameters” on page 263).
Enable The call is started in voiceband data mode.
Value Method
0 Disable
1 Enable
The DTMF Transport section allows you to set the DTMF transport parameters of the Aastra unit.
2
3
4
3. Select the DTMF transport type in the Transport Method drop-down menu.
The following choices are available:
Table 213: DTMF Transport Type Parameters
In-band The DTMFs are transmitted like the voice in the RTP
stream.
Out-of-band using RTP The DTMFs are transmitted as per RFC 2833. This
parameter also works with SRTP.
Out-of-band using SIP The DTMFs are transmitted as per draft-choudhuri-sip-info-
digit-00.
Signaling protocol Dependant The signalling protocol has the control to select the DTMF
transport mode. The SDP body includes both RFC 2833
and draft-choudhuri-sip-info-digit-00 in that order of
preference.
4. If you have selected the Out-of-band using SIP transport method, select the method used to
transport DTMFs out-of-band over the SIP protocol in the SIP Transport Method drop-down menu.
This menu is available only in the default endpoint configuration.
Table 214: DTMF Out-of-Band Transport Methods
Method Description
DTMF out-of-band
Certain compression codecs such as G.723.1 and G.729 effectively distort voice because they lose
information from the incoming voice stream during the compression and decompression phases. For
normal speech this is insignificant and becomes unimportant. In the case of pure tones (such as DTMF)
this distortion means the receiver may no longer recognize the tones. The solution is to send this
information as a separate packet to the other endpoint, which then plays the DTMF sequence back by re-
generating the true tones. Such a mechanism is known as out-of-band DTMF. The Aastra unit receives
and sends out-of-band DTMFs as per ITU Q.24. DTMFs supported are 0-9, A-D, *, #.
Method Description
Info DTMF Relay Transmits DTMFs by using a custom method. This custom
method requires no SDP negotiation and assumes that the other
peer uses the same method.
It uses a SIP INFO message with a content of type application/
dtmf-relay. The body of the message contains the DTMF
transmitted and the duration of the DTMF:
Signal= 1
Duration= 160
When transmitting, the duration is the one set in the
interopDtmfTransportDuration variable (see “DTMF
Transport over the SIP Protocol” on page 268).
When receiving, the duration of the DTMF received is not used
and the DTMF is played for 100 ms.
DTMFs are transmitted one at a time.
Available digits are “0123456789ABCD*#”. The Aastra unit also
supports the “,;p” characters when receiving DTMFs.
5. If you have selected the Out-of-band using RTP transport method, set the payload type in the
Payload Type field.
You can determine the actual RTP dynamic payload type used for the “telephone-event” in an initial
offer. The payload types available are as per RFC 1890. Available values range from 96 to 127.
6. Click Submit if you do not need to set other parameters.
DTMF Detection
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
The default DTMF detection parameters of the Aastra unit may sometimes not be enough to properly detect
the DTMFs. This section describes how to set additional DTMF detection parameters.
DTMF Frequencies
The DTMF keypad is laid out in a 4x4 matrix, with each row representing a low frequency, and each column
representing a high frequency. For example, pressing a single key (such as '1') sends a sinusoidal tone of the
two frequencies (697 Hz and 1209 Hz). When the unit is configured to send DTMFs out-of-band, its DSP
detects these DTMFs, removes them from the RTP stream, and sends them out-of-band.
Table 215: DTMF Keypad Frequencies
697 1 2 3 A
770 4 5 6 B
852 7 8 9 C
941 * 0 # D
Value Method
100 CheckSr Enables the Step Rise criteria and disables the Confirm DTMF SNR
criteria.
The Step Rise criteria compares the current frame energy to the high
frequency power of the previous frame. If the current frame energy is high
enough, then it passes the test, further validating the DTMF.
Disabling the Step Rise criteria may result in deteriorated talk-off
performance, but increases the detection of malformed DTMF.
200 ConfirmSnr Enable the Confirm DTMF SNR criteria and disable the Step Rise criteria.
The Confirm DTMF SNR criteria is an additional Signal-to-noise ratio test
performed before a confirmed DTMF report is sent to finally validate the
DTMF.
Parameter Description
disable Keep using the initial payload type. This is the default value.
enable Use the RFC 2833 payload type found in the received answer.
Value Meaning
0 disable
1 enable
The Machine Detection section allows you to set the tone detection parameters of the Aastra unit.
2
3
4
5
6
3. Select whether or not you want to enable fax calling tone (CNG tone) detection in the CNG Tone
Detection drop-down menu.
Table 218: CNG Tone Detection Settings
Setting Description
Enable Upon recognition of the CNG tone, the unit switches the communication from
voice mode to fax mode and the CNG is transferred by using the preferred fax
codec.
Note: This option allows for quicker fax detection, but it also increases the risk
of false detection.
Disable The CNG tone does not trigger a transition from voice to data and the CNG is
transferred in the voice channel.
Note: With this option, faxes are detected later, but the risk of false detection
is reduced.
4. Select whether or not you want to enable CED tone detection in the CED Tone Detection drop-down
menu.
Table 219: CNG CED Detection Settings
Setting Description
Enable Upon recognition of the CED tone, the unit behaves as defined in the
Behavior on CED Tone Detection parameter Step 6).
Disable The CED tone does not trigger a transition to fax or voiceband data mode.
The CED is transferred in the voice channel.
5. Select whether or not you want to enable fax V.21 modulation detection in the V.21 Modulation
Detection drop-down menu.
Table 220: V.21 Modulation Detection Settings
Setting Description
Enable Upon recognition of the V.21 modulation tone, the unit switches the
communication from voice mode to fax mode and the signal is transferred by
using the preferred fax codec.
Disable The V.21 modulation does not trigger a transition from voice to data and the
signal is transferred in the voice channel.
6. Define the behaviour of the unit upon detection of a CED tone in the Behavior on CED Tone
Detection drop-down menu.
Table 221: CED Tone Detection Settings
Setting Description
Passthrough The CED tone triggers a transition from voice to voice band data and is
transferred in the voice channel.. Use this setting when any kind of analog
device (i.e.: telephone, fax or modem) can be connected to this port.
Fax Mode Upon detection of a CED tone, the unit switches the communication from
voice mode to fax mode and the CED is transferred by using the preferred fax
codec. Only a fax can then be connected to this port.
Note: This parameter has no effect if the CED Tone Detection parameter is set to Disabled.
The Base Ports section allows you to set the ports that the Aastra unit uses for different transports.
This section is available only in the default endpoint configuration.
2
3
4
3. Set the UDP port number you want to use as SRTP/SRTCP base port in the SRTP field.
The SRTP/SRTCP ports are allocated starting from this base port.
SRTP ports number are even and SRTCP ports number are odd.
The default SRTP/SRTCP base port is 5004. For instance, assuming that the base port is defined
on 5004, if there is currently no ongoing call and there is an incoming or outgoing call, the unit uses
the SRTP/SRTCP ports 5004 and 5005.
Using the same base port for RTP/RTCP and SRTP/SRTCP does not conflict.
Note that if the media transport is set to “Secure with fallback” (“Chapter 32 - Security” on page 377),
both RTP and SRTP base ports are used at the same time when initiating an outgoing call. If there
is currently no call and the default base ports are used, the RTP port is 5004 and the SRTP port is
the next available port starting from the base port, which is 5006.
4. Set the port number you want to use as T.38 base port in the T.38 field.
The T.38 ports are allocated starting from this base port.
The default T.38 base port is 6004. For instance, assuming that the base port is defined on 6004 if
there is currently no ongoing call and there is an incoming or outgoing call, the unit uses the T.38
port 6005.
This menu is available only in the default endpoint configuration.
5. Click Submit if you do not need to set other parameters.
This chapter describes how to configure and use the DTMF maps of the Aastra unit.
Standards Supported • RFC 2705: Media Gateway Control Protocol (MGCP) Version
1.0, section 3.4 (Formal syntax description of the protocol).
Introduction
A DTMF map (also called digit map or dial map) allows you to compare the number users just dialed to a string
of arguments. If they match, users can make the call. If not, users cannot make the call and get an error signal.
It is thus essential to define very precisely a DTMF map before actually implementing it, or your users may
encounter calling problems.
Because the Aastra unit cannot predict how many digits it needs to accumulate before transmission, you could
use the DTMF map, for instance, to determine exactly when there are enough digits entered from the user to
place a call.
Syntax
The permitted DTMF map syntax is taken from the core MGCP specification, RFC 2705, section 3.4:
DigitMap = DigitString / '(' DigitStringList ')'
DigitStringList = DigitString 0*( '|' DigitString )
DigitString = 1*(DigitStringElement)
DigitStringElement = DigitPosition ['.']
DigitPosition = DigitMapLetter / DigitMapRange
DigitMapLetter = DIGIT / '#' / '*' / 'A' / 'B' / 'C' / 'D' / 'T'
DigitMapRange = 'x' / '[' 1*DigitLetter ']'
DigitLetter ::= *((DIGIT '-' DIGIT ) / DigitMapLetter)
Where “x” means “any digit” and “.” means “any number of”.
For instance, using the telephone on your desk, you can dial the following numbers:
Table 222: Number Examples
Number Description
0 Local operator
00 Long distance operator
xxxx Local extension number
8xxxxxxx Local number
#xxxxxxx Shortcut to local number at other corporate sites
91xxxxxxxxxx Long distance numbers
Number Description
The solution to this problem is to load the Aastra unit with a DTMF map that corresponds to the dial plan.
A Aastra unit that detects digits or timers applies the current dial string to the DTMF map, attempting a match
to each regular expression in the DTMF map in lexical order.
If the result is under-qualified (partially matches at least one entry in the DTMF map), waits for
more digits.
If the result matches, dials the number.
If the result is over-qualified (i.e., no further digits could possibly produce a match), sends a fast
busy signal.
Special Characters
DTMF maps use specific characters and digits in a particular syntax.
Table 223: DTMF Map Characters
Character Use
Note: Enclose the DTMF map in parenthesis when using the “|” option.
Note: When making the actual call and dialing the number, the Aastra unit automatically removes the “T”
found at the end of a dialed number, if there is one (after a match). This character is for indication purposes
only.
See “General DTMF Maps Parameters” on page 282 for more details.
Example
Table 222 on page 279 outlined various call types one could make. All these possibilities could be covered in
one DTMF map:
(0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|91xxxxxxxxxx|9011x.T)
The following are the general DTMF maps parameters you can set.
2 3 4 5
2. In the General Configuration section, define the time, in milliseconds (ms), between the start of the
dial tone and the receiver off-hook tone, if no DTMF is detected, in the First DTMF Timeout field.
Values range from 1000 ms to 180000 ms. The default value is 20000 ms.
If you want to set a different First DTMF Timeout value for one or more endpoints, click the Edit
Endpoints button (see “Configuring Timeouts per Endpoint” on page 283 for more details).
3. Define the value, in milliseconds (ms), of the “T” digit in the Inter Digit Timeout field.
The “T” digit expresses a time lapse between the detection of two DTMFs. Values range from 500
ms to 10000 ms. The default value is 4000 ms.
If you want to set a different Inter Digit Timeout value for one or more endpoints, click the Edit
Endpoints button (see “Configuring Timeouts per Endpoint” on page 283 for more details).
4. Define the total time, in milliseconds (ms), the user has to dial the DTMF sequence in the
Completion Timeout field.
The timer starts when the dial tone is played. When the timer expires, the receiver off-hook tone is
played. Values range from 1000 ms to 180000 ms. The default value is 60000 ms.
If you want to set a different Completion Timeout value for one or more endpoints, click the Edit
Endpoints button (see “Configuring Timeouts per Endpoint” on page 283 for more details).
5. In the DTMF Maps Digit Detection (FXO/FXS) drop-down menu, define when a digit is processed
through the DTMF maps.
This parameters is available only when the unit has FXS or FXO ports.
Table 224: DTMF Maps Digit Detection Parameters
Parameter Description
When Digits are processed as soon as they are pressed. This can lead to a digit leak in
Pressed the RTP at the beginning of a call if the voice stream is established before the last
digit is released.
When Digits are processed only when released. This option increases the delay needed
Released to match a dialed string to a DTMF map. There is also an impact on the First DTMF
Timeout, Inter Digit Timeout and Completion Timeout parameters since the timers
are stopped at the end of a digit instead of the beginning.
2. Set the Override drop-down menu for the endpoint you want to set to Enable.
3. Change the value of one or more timeouts as required.
4. Repeat for each endpoint that you want to modify.
5. Click Submit when finished.
You can create/edit ten DTMF maps for the Aastra unit. DTMF map rules are checked sequentially. If a
telephone number potentially matches two of the rules, the first rule encountered is applied.
3. Select the entity to which apply the allowed DTMF map in the Apply to column.
Table 225: DTMF Map Entity
Parameter Description
4. Enter a string that identifies an endpoint in other tables in the Endpoint column.
This field is available only if you have selected the Endpoint entity in the previous step for the
specific row.
You can specify more than one endpoint. In that case, the endpoints are separated with a comma
(,). You can use the Suggestions column’s drop-down menu to select between suggested values, if
any.
5. Define the DTMF map string that is considered valid when dialed in the DTMF Map column.
The string must use the syntax described in “DTMF Maps Configuration” on page 279. A DTMF map
string may have a maximum of 64 characters.
6. Enter the DTMF transformation to apply to the signalled DTMFs before using it as call destination
in the Transformation column.
The following are the rules you must follow; “x” represents the signalled number.
• Add before “x” the DTMF to prefix or/and after “x” the suffix to add. Characters
“0123456789*# ABCD” are allowed.
• Use a sequence of DTMFs between “{}” to remove a prefix/suffix from the dialed
number if present. Use before “x” to remove a prefix and after “x” to remove a suffix.
Characters “0123456789*#ABCD” are allowed.
• Use a number between “()” to remove a number of DTMFs. Use before “x” to remove
DTMFs at the beginning of the number and after “x” to remove DTMFs at the end.
Characters “0123456789” are allowed.
The transformations are applied in order from left to right.
The following table gives an example with “18195551111#” as signalled number.
Table 226: DTMF Map Transformation Examples
7. Define the target to use when the DTMF map matches in the Target column.
This allows associating a target (FQDN) with a DTMF map. This defines a destination address to
use when the DTMF map matches. This address is used as destination for the INVITEs in place of
the “home domain proxy”. This is useful for such features as the speed dial and emergency call.
The default target is used when the value is empty.
The dialed DTMFs are not used if the target contains a user name.
A refused DTMF map forbids to call specific numbers; for instance, you want to accept all 1-8xx numbers
except 1-801. You can create/edit ten refused DTMF maps for the Aastra unit.
A refused DTMF map applies before an allowed DTMF map.
3. Select the entity to which apply the refused DTMF map in the Apply to column.
Table 227: DTMF Map Entity
Parameter Description
4. Enter a string that identifies an endpoint in other tables in the Endpoint column.
This field is available only if you have selected the Endpoint entity in the previous step for the
specific row.
You can specify more than one endpoint. In that case, the endpoints are separated with a comma
(,). You can use the Suggestions column’s drop-down menu to select between suggested values, if
any.
5. Define the DTMF map string that is considered valid when dialed in the DTMF Map column.
The string must use the syntax described in “DTMF Maps Configuration” on page 279. A DTMF map
string may have a maximum of 64 characters.
6. Click Submit if you do not need to set other parameters.
Note: This web page is available only on the following models: TA7102i
You can automatically forward the incoming calls of your users to a pre-determined target if they are already
on the line. The user does not have any feedback that a call was forwarded.
You can enable the Call Forward On Busy feature in two ways:
By allowing the user to configure the call forward activation and its destination via the handset
(Steps 4-6).
By manually enabling the service (Steps 7-8).
3
4
5
6
7
8
2. Select to which endpoint you want to apply the changes in the Select Endpoint drop-down menu at
the top of the window.
You have the choice between Default and all FXS endpoints your Aastra unit has.
3. In the Call Forward On Busy section, define whether or not you want to override the Call Forward
On Busy parameters set in the Default configuration in the Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
4. Enable the Call forward configuration via handset service by setting the Allow Activation via
Handset drop-down menu to Enable.
You also need to configure the activation and deactivation DTMF maps (steps 5 and 6).
If you select Disable, this does not disable the call forward, but prevents the user from activating or
deactivating the call forward service. The user will not be able to use the digits used to activate and
deactivate the call forward service.
5. Define the digits that users must dial to start the service in the DTMF Map Activation field.
This field is available only in the Default configuration.
For instance, you could decide to put “*72” as the sequence to activate the service. This sequence
must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps Configuration”
on page 401). Dialing this DTMF map does not have any effect unless the service’s status is
“enabled”.
The activating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
6. Define the digits that users must dial to stop the service in the DTMF Map Deactivation field.
This field is available only in the Default configuration.
For instance, you could decide to put “*73” as the sequence to deactivate the service. This
sequence must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps
Configuration” on page 401). Dialing this DTMF map does not have any effect unless the service’s
status is “enabled”.
The deactivating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
7. Set the call forward service in the Activation field to Inactive or Active.
Table 228: Activation State
State Description
Inactive The call forward service is not available on the telephone connected to the specific
endpoint. A call to this endpoint is not forwarded if the endpoint is busy.
Active The call forward service is available on the telephone connected to the specific
endpoint. A call to the endpoint is forwarded to the specified destination if the
endpoint is busy. You must define the call forward destination in the Forwarding
Address field (Step 8). The call forward service behaves as if it is inactive if the
Forwarding Address is empty.
To let the user activate or deactivate this service with his or her handset, see steps 4, 5, and 6. In
that case, the field is automatically updated to reflect the activation status.
8. Define the address to which forward incoming calls in the Forwarding Address field.
Accepted formats are:
• telephone numbers (5551111)
• SIP URLs such as ”scheme:user@host”. For instance, “sip:[email protected]”.
This string is used literally, so cosmetic symbols (such as the dash in “555-xxxx”) should not be
present.
9. Click Submit if you do not need to set other parameters.
To forward calls:
1. Take the receiver off-hook.
2. Wait for the dial tone.
3. Dial the sequence implemented to activate the call forward on busy service.
This sequence could be something like *72.
4. Wait for the stutter dial tone (three “beeps”) followed by the dial tone.
5. Dial the number to which you want to forward your calls. Dial any access code if required.
6. Wait for three “beeps” followed by a silent pause.
The call forward is established.
7. Hang up your telephone.
You can forward the incoming calls of your users to a pre-determined target if they do not answer their
telephone before a specific amount of time. The user does not have any feedback that a call was forwarded.
You can enable the Call Forward On Busy feature in two ways:
By allowing the user to configure the call forward activation and its destination via the handset
(Steps 3-5).
By manually enabling the service (Steps 6-8).
2
3
4
5
6
7
8
3. Enable the Call forward configuration via handset service by setting the Allow Activation via
Handset drop-down menu to Enable.
You also need to configure the activation and deactivation DTMF maps (steps 4 and 5).
If you select Disable, this does not disable the call forward, but prevents the user from activating or
deactivating the call forward service. The user will not be able to use the digits used to activate and
deactivate the call forward service.
4. Define the digits that users must dial to start the service in the DTMF Map Activation field.
This field is available only in the Default configuration.
For instance, you could decide to put “*74” as the sequence to activate the service. This sequence
must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps Configuration”
on page 401). Dialing this DTMF map does not have any effect unless the service’s status is
“enabled”.
The activating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
5. Define the digits that users must dial to stop the service in the DTMF Map Deactivation field.
This field is available only in the Default configuration.
For instance, you could decide to put “*75” as the sequence to deactivate the service. This
sequence must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps
Configuration” on page 401). Dialing this DTMF map does not have any effect unless the service’s
status is “enabled”.
The deactivating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
6. Define the time, in milliseconds, the telephone keeps ringing before the call forwarding activates in
the Timeout field.
7. Set the status of the service in the Activation field to Inactive or Active.
Table 229: Activation State
State Description
Inactive The call forward service is not available on the telephone connected to the specific
endpoint. A call to this endpoint is not forwarded if the endpoint is busy.
Active The call forward service is available on the telephone connected to the specific
endpoint. A call to the endpoint is forwarded to the specified destination if the
endpoint is busy. You must define the call forward destination in the Forwarding
Address field (Step 8). The call forward service behaves as if it is inactive if the
Forwarding Address is empty.
To let the user activate or deactivate this service with his or her handset, see steps 3, 4, and 5. In
that case, the field is automatically updated to reflect the activation status.
8. Define the address to which forward incoming calls in the Forwarding Address field.
Accepted formats are:
• telephone numbers (5551111)
• SIP URLs such as ”scheme:user@host”. For instance, “sip:[email protected]”.
This string is used literally, so cosmetic symbols (such as the dash in “555-xxxx”) should not be
present.
9. Click Submit if you do not need to set other parameters.
To forward calls:
1. Take the receiver off-hook.
2. Wait for the dial tone.
3. Dial the sequence implemented to activate the call forward on no answer service.
This sequence could be something like *74.
4. Wait for the transfer tone (three “beeps”) followed by the dial tone.
5. Dial the number to which you want to forward your calls. Dial any access code if required.
6. Wait for three “beeps” followed by a silent pause.
The call forward is established.
7. Hang up your telephone.
The Call Forward Unconditional feature allows users to forward all of their calls to another extension or line.
You can enable the Call Forward On Busy feature in two ways:
By allowing the user to configure the call forward activation and its destination via the handset
(Steps 3-5).
By manually enabling the service (Steps 6-7).
2
3
4
5
6
7
3. Enable the Call forward configuration via handset service by setting the Allow Activation via
Handset drop-down menu to Enable.
You also need to configure the activation and deactivation DTMF maps (steps 4 and 5).
If you select Disable, this does not disable the call forward, but prevents the user from activating or
deactivating the call forward service. The user will not be able to use the digits used to activate and
deactivate the call forward service.
4. Define the digits that users must dial to start the service in the DTMF Map Activation field.
This field is available only in the Default configuration.
For instance, you could decide to put “*76” as the sequence to activate the service. This sequence
must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps Configuration”
on page 401). Dialing this DTMF map does not have any effect unless the service’s status is
“enabled”.
The activating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
5. Define the digits that users must dial to stop the service in the DTMF Map Deactivation field.
This field is available only in the Default configuration.
For instance, you could decide to put “*77” as the sequence to deactivate the service. This
sequence must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps
Configuration” on page 401). Dialing this DTMF map does not have any effect unless the service’s
status is “enabled”.
The deactivating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
6. Set the status of the service in the Activation field to Inactive or Active.
Table 230: Activation State
State Description
Inactive The call forward service is not available on the telephone connected to the specific
endpoint. A call to this endpoint is not forwarded if the endpoint is busy.
Active The call forward service is available on the telephone connected to the specific
endpoint. A call to the endpoint is forwarded to the specified destination if the
endpoint is busy. You must define the call forward destination in the Forwarding
Address field (Step 7). The call forward service behaves as if it is inactive if the
Forwarding Address is empty.
To let the user activate or deactivate this service with his or her handset, see steps 3, 4, and 5. In
that case, the field is automatically updated to reflect the activation status.
7. Define the address to which forward incoming calls in the Forwarding Address field.
Accepted formats are:
• telephone numbers (5551111)
• SIP URLs such as ”scheme:user@host”. For instance, “sip:[email protected]”.
This string is used literally, so cosmetic symbols (such as the dash in “555-xxxx”) should not be
present.
8. Click Submit if you do not need to set other parameters.
To forward calls:
1. Take the receiver off-hook.
2. Wait for the dial tone.
3. Dial the sequence implemented to activate the call forward unconditional service.
This sequence could be something like *76.
4. Wait for the stutter dial tone (three “beeps”) followed by the dial tone.
5. Dial the number to which you want to forward your calls. Dial any access code if required.
6. Wait for three “beeps” followed by a silent pause.
The call forward is established.
7. Hang up your telephone.
34 Telephony Services
Configuration
General Configuration
The General Configuration sub-section of the Services Configuration section allows you to define the Hook
Flash Processing feature.
Note: Performing a flash hook and pressing the flash button means the same thing. However, not all
telephone models have a flash button.
3
4
2. Select to which endpoint you want to apply the changes in the Select Endpoint drop-down menu at
the top of the window.
You have the choice between Default and the interfaces of your Aastra unit. The number of
interfaces available vary depending on the Aastra unit model you have.
3. In the General Configuration sub-section, define whether or not you want to override the general
services parameters set in the Default configuration in the Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
4. Select how to process hook-flash detection in the Hook Flash Processing drop-down menu.
Hook flash processing allows hook flash signals to be transported over the IP network allowing to
use advanced telephony services. Users normally press the “flash” button of the telephone during
a call in progress to put this call on hold, transfer it, or even initiate a conference call.
You can define whether these subscriber services are handled by the unit or delegated to a remote
party. If services are to be handled by a remote party, a SIP INFO message is sent to transmit the
user's intention.
Setting Definition
Process Locally The hook-flash is processed locally. The actual behaviour of the “flash”
button depends on which endpoint services are enabled for this
endpoint.
Transmit Using The hook-flash is processed by a remote party. The hook-flash event is
Signaling Protocol carried by a signaling protocol message. The actual behaviour of the
“flash” button depends on the remote party.
The hook-flash event is relayed as a SIP INFO message as described
in RFC 2976.
Automatic Call
The automatic call feature allows you to define a telephone number that is automatically dialed when taking
the handset off hook.
When this service is enabled, the second line service is disabled but the call waiting feature is still functional.
The user can still accept incoming calls.
2
3
4
3. Enable the service by setting the Automatic Call Activation drop-down menu to Enable.
4. Define the string to dial when the handset is taken off hook in the Automatic Call Target field.
Accepted formats are:
• telephone numbers (5551111)
• SIP URLs such as ”scheme:user@host”. For instance, “sip:[email protected]”.
This string is used literally, so cosmetic symbols (such as the dash in “555-xxxx”) should not be
present.
5. Click Submit if you do not need to set other parameters.
Call Completion
Standards Supported • RFC 4235: An INVITE-Initiated Dialog Event Package for the
Session Initiation Protocol (SIP)a
• draft draft-poetzl-bliss-call-completion-00b
a. Implemented in client mode only and used for the call completion.
b. Implement the solution 1 in 5.1.
The call completion service allows you to configure the Completion of Calls on No Reply (CCNR) and
Completion of Calls to Busy Subscriber (CCBS) features.
CCBS allows a caller to establish a call with a “busy” callee as soon as this callee is available to take the call.
It is implemented by monitoring the activity of a UA and look for the busy-to-idle state transition pattern.
CCNR allows a caller to establish a call with an “idle” callee right after this callee uses his phone. It is
implemented by monitoring the activity of a UA and look for the idle-busy-idle state transition pattern.
The information about the call completion is not kept after a restart of the EpServ service. This includes the
call completion activation in the Pots service and the call completion monitoring in the SipEp service.
2. In the Call Completion sub-section, define whether or not you want to override the call completion
parameters set in the Default configuration in the Endpoint Specific drop-down menu.
This menu is available only in the specific endpoints configuration.
3
4
5
6
7
8
9
10
11
12
13
3. Enable or disable the (CCBS) service by selecting the proper value in the Allow CCBS Activation
Via Handset drop-down menu.
You also need to configure the activation and deactivation DTMF maps (steps 4 and 7).
4. If the CCBS service is enabled, define the digits that users must dial to start the service in the CCBS
DTMF Map Activation field.
This field is available only in the Default configuration.
You can use the same code in the CCNR DTMF Map Activation field.
For instance, you could decide to put “*92” as the sequence to activate the service. This sequence
must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps Configuration”
on page 401). Dialing this DTMF map does not have any effect unless the service’s status is
“enabled”.
The activating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
5. Enable or disable the (CCNR) service by selecting the proper value in the Allow CCNR Activation
Via Handset drop-down menu.
You also need to configure the activation and deactivation DTMF maps (steps 6 and 7).
6. If the CCNR service is enabled, define the digits that users must dial to start the service in the CCNR
DTMF Map Activation field.
This field is available only in the Default configuration.
You can use the same code in the CCBS DTMF Map Activation field.
For instance, you could decide to put “*93” as the sequence to activate the service. This sequence
must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps Configuration”
on page 401). Dialing this DTMF map does not have any effect unless the service’s status is
“enabled”.
The activating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
7. Define the digits that users must dial to stop the CCBS and CCNR services in the DTMF Map
Deactivation field.
This field is available only in the Default configuration.
For instance, you could decide to put “*94” as the sequence to deactivate the services. This
sequence must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps
Configuration” on page 401). Dialing this DTMF map does not have any effect unless the service’s
status is “enabled”.
The deactivating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
8. Define the delay, in minutes, after the call completion activation to automatically deactivate the call
completion if the call is not completed in the Expiration Timeout field.
Method Desciption
Monitoring Only The call completion only uses the monitoring method to detect that the
destination is ready to complete the call.
Monitoring And Polling The call completion only uses the monitoring method to detect that the
destination is ready to complete the call. The polling mechanism is used
if the call completion destination cannot be monitored.
Parameter Description
None The progress message with early media is not considered as a busy or a ringing
response.
CCBS The progress message with early media is interpreted as a busy response and the
CCBS can be activated on the call.
CCNR The progress message with early media is interpreted as a ringing response and
the CCNR can be activated on the call.
Call Transfer
The Call Transfer service offers two ways to transfer calls:
Blind Transfer
Attended Transfer
2
3
4
3. Enable the Blind Transfer service by setting the Blind Transfer Activation drop-down menu to
Enable.
The blind call transfer service is sometimes called Transfer without Consultation or Unattended
Transfer. It allows a user to transfer a call on hold to a still ringing (unanswered) call. The individual
at the other extension or telephone number does not need to answer to complete the transfer.
The call hold and second call services must be enabled for this service to work. See “Call Hold” on
page 311 and “Second Call” on page 311.
4. Enable the Attended Transfer service by setting the Attended Transfer Activation drop-down menu
to Enable.
The attended call transfer service is sometimes called Transfer with Consultation. It allows a user
to transfer a call on hold to an active call. The individual at the other extension or telephone number
must answer to complete the transfer.
The call hold and second call services must be enabled for this service to work. See “Call Hold” on
page 311 and “Second Call” on page 311.
5. Click Submit if you do not need to set other parameters.
Note: If the number to which you want to transfer the call is busy or does not answer, perform a Flash-Hook.
The busy tone or ring tone is cancelled and you are back with the first call.
Call Waiting
The call waiting tone indicates to an already active call that a new call is waiting on the second line.
Your users can activate/deactivate the call waiting tone for their current call. This is especially useful when
transmitting faxes. The user that is about to send a fax can thus deactivate the call waiting tone to ensure that
the fax transmission will not be disrupted by an unwanted second call. When the fax transmission is completed
and the line is on-hook, the call waiting tone is automatically reactivated.
2
3
4
3. Enable the service by setting the Call Waiting Activation drop-down menu to Enable.
This permanently activates the call waiting tone. When receiving new calls during an already active
call, a special tone is heard to indicate that a call is waiting on the second line. The user can then
answer that call by using the “flash” button. The user can switch between the two active calls by
using the “flash” button.
The call hold service must be enabled for this service to work. See “Call Hold” on page 311.
If the user is exclusively using faxes, select Disable to permanently disable the call waiting tone.
4. Define the digits that users must dial to disable the Call Waiting tone in the Cancel DTMF Map field.
This field is available only in the Default configuration.
This allows a user who has call waiting enabled to disable that service on the next call only. If, for
any reason, the user wishes to undo the cancel, unhook and re-hook the telephone to reset the
service.
For instance, you could decide to put “*76” as the sequence to disable the call waiting tone. This
sequence must be unique and follow the syntax for DTMF maps (see “Chapter 35 - DTMF Maps
Configuration” on page 401). Dialing this DTMF map does not have any effect unless the service’s
status is “enabled”.
The deactivating sequence is set for all the endpoints of the Aastra unit. You cannot have a different
sequence for each endpoint.
5. Click Submit if you do not need to set other parameters.
--boundary1
Content-Type: application/vnd.3gpp.cw+xml
Content-Disposition: render;handling=optional
<?xml version="1.0"?>
<ims-cw xmlns="urn:3gpp:ns:cw:1.0">
<communication-waiting-indication/>
</ims-cw>
--boundary1
Content-Type: application/sdp
[...]
--boundary1--
The 180 Ringing response to this may contain a special header :
Alert-Info: <urn:alert:service:call-waiting>
that is appended if all of the following are true :
1. The INVITE contained the <communication-waiting-indication/> 3GPP option.
2. The destination endpoint supports call waiting.
3. The call waiting feature is enabled for this endpoint.
4. The endpoint is currently in an active state (not ringing, not on hold, not on hook).
There are no variables to control this behaviour, it is always activated.
This header could be used by the server to notify the 2nd caller that the destination is currently busy
in a call but was notified of this new incoming call.
Conference
The Conference Call service allows a user to link two or more calls together to form a single conversation,
called a conference.
Only 3-way conferences are currently supported.
A participant of the conference can put the conference on hold and attempt other calls. This
participant may then rejoin the conference at a later time by unholding it. The participant who
initiated the conference cannot put it on hold.
You must enable the call hold, second call and attended call transfer services for this service to work. See
“Call Hold” on page 311, “Second Call” on page 311, and “The Call Transfer service offers two ways to transfer
calls:” on page 301.
The following is a conference call flow example:
Flash Hook
INVITE (HOLD)
Trying /200 OK
ACK
INVITE (G.729 )
Trying/Ringing/200 OK
ACK
Flash Hook
Trying200 OK
ACK
INVITE (UNHOLD-G.729 )
Trying/200 OK
ACK
3-way Conference Call Established
DSP Limitation
The Aastra Ta7102i model suffer from a limitation of their DSPs. When using a codec other than G.711,
enabling Secure RTP (SRTP) and/or using conferences has an impact on the Aastra unit’s overall
performance as SRTP and conferences require CPU power. That is the reason why there is a limitation on the
lines that can be used simultaneously, depending on the codecs enabled and SRTP. This could mean that a
user picking up a telephone on these models may not have a dial tone due to lack of resources in order to not
affect the quality of ongoing calls. See “Security” on page 201 for more details on SRTP limitations.
The DSPs offer channels as resources to the Aastra unit. The Aastra unit is limited to two conferences per
DSP.
Please note that:
One FXS line requires one channel.
Each conference requires one additional channel
The TA7102i has one DSP
A total of eight channels per DSP are available when using unsecure communication, to be used between the
FXS lines and up to two conferences.
A total of six channels per DSP are available when using SRTP, to be used between the FXS lines and up to
two conferences.
You must enable this service before your users can use it.
2
3
3. Enable the service by setting the Conference Activation drop-down menu to Enable.
4. Click Submit if you do not need to set other parameters.
Standards Supported • RFC 4579: Session Initiation Protocol (SIP) - Call Control -
Conferencing for User Agentsa
a. Partially compliant. Only call flows of sections 5.4 and 5.6 are supported. RFC 4575 is not supported.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
The Aastra unit can use an external server to mix the media of the conference. This conference type requires
the configuration of an external server. Using this type of conference does not affect the number of
simultaneous calls supported. You can use this feature only if the Conference service is enabled (see
“Enabling the Conference Call Feature” on page 305 for more details).
You can use two types of configuration:
Default configurations that apply to all the endpoints of the Aastra unit.
Specific configurations that override the default configurations.
You can define specific configurations for each endpoint in your Aastra unit. For instance, you could
enable a codec for all the endpoints of the Aastra unit and use the specific configuration parameters
to disable this same codec on one specific endpoint.
Using one or more specific parameter usually requires that you enable an override variable and set the specific
configuration you want to apply.
100 Local The media of the conference is locally mixed by the unit. This
conference type does not require any special support of the call peer
or server. Using this type of conference can reduce the number of
simultaneous calls supported.
200 ConferenceSer The unit uses an external server to mix the media of the conference.
ver This conference type requires the configuration of an external server
(See Step 3). Using this type of conference does not affect the number
of simultaneous calls supported.
In Local mode, the number of participants is limited to the unit's model capacity. In
ConferenceServer mode, the number of participants is limited by the server's capacity.
2. If you want to set a different conference type for one or more endpoints, set the following variables:
• epSpecificConferenceEnableConfig variable for the specific endpoint you want to
configure to enable.
• epSpecificConferenceType variable for the specific endpoint you want to configure to
the proper value.
You can also use the following lines in the CLI or a configuration script:
EpServ.epSpecificConference.EnableConfig[Id="Specific_Endpoint"]="1"
EpServ.epSpecificConference.Type[Id="Specific_Endpoint"]="Type"
where:
• Specific_Endpoint is the number of the endpoint you want to configure.
• Value is the type as defined in Step 1.
3. If you have set the Conference type to ConferenceServer, in the SipEpMIB, set the
defaultConferenceType variable with the URI used in the request-URI of the INVITE sent to the
conference server as defined in RFC 4579.
You can also use the following line in the CLI or a configuration script:
SipEp.DefaultStaticConferenceServerUri="URI"
4. If you want to set a different URI for one or more endpoints, set the following variables:
• GwSpecificConferenceEnableConfig variable for the specific endpoint you want to
configure to enable.
• GwSpecificConferenceServerUri variable for the specific endpoint you want to
configure to the proper value.
You can also use the following lines in the CLI or a configuration script:
EpServ.GwSpecificConference.EnableConfig[Id="Specific_Endpoint"]="1"
EpServ.GwSpecificConference.ServerUri[Id="Specific_Endpoint"]="URIValue"
where:
• Specific_Endpoint is the number of the endpoint you want to configure.
• URIValue is the URI you want to use.
automatically called upon picking up the phone and after waiting for the configurable number
of seconds without dialling.
When the user starts dialing but does not complete a valid number before the timeout set in the
Delayed Hotline Condition drop-down menu expires.
The condition on which the delayed hotline is activated is configurable. This feature thus places an automatic
call whenever the Delayed Hotline Condition timeout expires. It could be used as an alternative to the
emergency number (for instance, the 911 number in North America).
2
3
3. Enable the service by setting the Delayed Hotline Activation drop-down menu to Enable.
When the feature is disabled, a user picking up the phone but not pressing any telephone keys
hears the Receiver Off-Hook tone after the amount of time specified in the
digitMapTimeoutFirstDigit variable.
4. Click Submit if you do not need to set other parameters.
Parameter Description
Parameter Description
Dialing an IP Address
For instance, let’s say you want to reach a one-line access device or another LAN endpoint such as
an IP Phone with the IP address 192.168.0.23. You must then dial the following digits:
**192*168*0*23*
4. If you need to specify the phone number of a specific line, dial “#” to terminate the IP address.
5. Dial the telephone number of the specific line you want to reach.
For example, let’s say you want to reach the telephone connected to Line 2 of the Aastra unit with
the IP address 192.168.0.23. The phone number assigned to Line 2 of this Aastra unit is 1234. You
must then dial the following digits:
**192*168*0*23#1234
In this case, the Aastra unit sends an INVITE [email protected].
Call Hold
The Call Hold service allows the user to temporarily put an existing call on hold, usually by using the “flash”
button of the telephone. The user can resume the call in the same way.
You must enable this service for the following services to work properly:
Call Waiting
Second Call
Blind Transfer
Attended Transfer
Conference
2
3
3. Enable the service by setting the Hold Activation drop-down menu to Enable.
4. Click Submit if you do not need to set other parameters.
Second Call
The Second Call service allows a user with an active call to put the call on hold, and then initiate a new call on
a second line. This service is most useful with the transfer and conference services.
The call hold service must be enabled for this service to work. See “Call Hold” on page 311.
You must enable this service for the following services to work properly:
Blind Transfer
Attended Transfer
Conference
2
3
3. Enable the service by setting the Second Call Activation drop-down menu to Enable.
4. Click Submit if you do not need to set other parameters.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
The Message Waiting Indicator (MWI) service alerts the user when new messages have been recorded on a
voice mailbox. It is enabled by default.
After the message is recorded, the server sends a message (SIP NOTIFY request) to the Aastra unit listing
how many new and old messages are available. The Aastra unit alerts the user of the new message in two
different ways:
The telephone’s LED blinks (if present). A FSK signal is sent on the FXS line.
A message waiting stutter dial tone replaces the normal dial tone when the user picks up the
FXS line.
Note: The message waiting state does not affect the Second Call feature. When in an active call,
performing a flash-hook to get access to the second line plays the usual dial tone.
The Aastra unit supports to receive SIP MWI notifications via SIP NOTIFY requests as defined in RFC 3842
but with the following limitations/diversions:
In addition to the SIP event string "message-summary" (RFC 3842), the string "simple-
message-summary" is accepted. The significations of those strings are identical.
In addition to the SIP content type string "simple-message-summary" (RFC 3842), the string
"message-summary" is accepted. The significations of those strings are identical.
Support of message-summary is not advertised in the SIP REGISTER.
Note that received SIP NOTIFY with an event different than "message-summary" or "simple-message-
summary" is not interpreted as a valid MWI notification.
You can use two types of configuration:
Default configurations that apply to all the endpoints of the Aastra unit.
Specific configurations that override the default configurations.
You can define specific configurations for each endpoint in your Aastra unit. For instance, you could
enable a codec for all the endpoints of the Aastra unit and use the specific configuration parameters
to disable this same codec on one specific endpoint.
Using one or more specific parameter usually requires that you enable an override variable and set the specific
configuration you want to apply.
2. If you want to set a different activation for one or more endpoints, set the following variables:
• fxsSpecificMessageWaitingIndicatorEnableConfig variable for the specific
endpoint you want to configure to enable.
• fxsSpecificMessageWaitingIndicatorActivation variable for the specific endpoint
you want to configure to the proper value.
You can also use the following lines in the CLI or a configuration script:
pots.fxsSpecificMessageWaitingIndicator.EnableConfig[Id="Specific_Endpoint"]="1"
pots.fxsSpecificMessageWaitingIndicator.Activation[Id="Specific_Endpoint"]="Valu
e"
where:
• Specific_Endpoint is the number of the endpoint you want to configure.
• Value is the activation as defined in Step 1.
100 Fsk A FSK signal is sent to activate the VMWI on the phone.
200 FskAndVoltage Both FSK signal and high voltage signal are used to activate the VMWI
on the phone.
Note: This parameter applies only to the following models: TA7102i
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
You can override the set of services that are activated during an emergency call.
100 NoOverride The set of services for emergency calls remains the same as
configured.
200 NoServices Ignores any service requiring a flash-hook. Call waiting and all other
related services are deactivated.
Call Statistics
This section describes how to access data available only in the MIB parameters of the Aastra unit. You can
display these parameters as follows:
by using a MIB browser
by using the CLI
The following are the call statistics the Aastra unit keeps. Statistics are updated at the end of each call.
Table 239: Call Statistics
tables. On endpoints with multiple channels, the channel number must be appended at
the end of the endpoint name, separated with a dash.
You can also use the following line in the CLI:
set epServ.callStatistics[EplId=callStatisticsEpId].Reset=Reset
Examples:
Slot3/E1T1-12 refers to endpoint Slot3/E1T1, channel 12.
Phone-Fax1 refers to FXS endpoint Phone-Fax1 on a 4102s.
Port06 refers to FXS endpoint Port06 on 4108/4116/4124.
No channel number is appended to FXS endpoint strings because FXS lines do not support multiple
channels.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
You can define how to route priority calls including emergency calls.
100 Normal Sends the call using normal SIP call routing to the outbound proxy (if
defined) and to the target host (usually the SIP server).
200 SkipOutbound Sends the call directly to the configured server skipping the outbound
Proxy proxy.
This chapter describes how to override the pattern for a specific tone defined for the selected country (see
“Appendix A - Country-Specific Parameters” on page 603 for more details). It covers the following topics:
Current Tone Definition
Tone Override
The Tone Customization page allows you to both see the current definition and override the pattern of the
following tones:
Busy Message Waiting
Call Waiting Preemption
Confirmation Reorder
Congestion Ringback
Dial Receiver Off Hook (ROH)
Hold Special Information Tone (SIT)
Intercept Stutter
This includes the number of frequencies used, the tone value in Hertz (Hz), its power in dBm, as well as the
states configured.
2. Select the proper tone to see in the Select Tone drop-down menu at the top of the window.
The Current Tone Definition and Current Tone States sections describe the current definition of the
selected tone.
Tone Override
You can override the pattern for a specific tone. This is done in two sections:
Table 241: Tone Override Sections
State Description
Overridden Tone Definition Allows you to define up to four frequencies (F1 to F4). You must enter at least
one frequency.
Overridden Tone States Description of the tone state. You can define up to eight states. You must
enter at least one state.
2 3
4
5 6 7 8 9
• You can use the current values of the selected tone as a starting point for your
customization by clicking the Copy Current Tone Definition to Overridden button.
• You can clear all override fields by clicking the Reset Overridden Values button.
2. In the Overridden Tone Definition section, define the value of the proper Frequency used in the
corresponding Value field.
The value is in Hz. The range is from 10 Hz to 4000 Hz.
Note: You can use only two frequencies for the Call Waiting tone.
3. Define the power level of the proper Frequency in dBm in the corresponding Power field.
The range is from -99 dBm to 3 dBm.
4. If applicable, enter a value for the loop counter in the Loop Count field.
The range is from 2 to 128. This value will be used in Step 8.
Note: You can use only one loop count for the Call Waiting tone.
5. In the Overridden Tone States section, set the corresponding On/Off drop-down menu with the
proper value for each state.
• To add a state, click the button at the bottom of the Overridden Tone States section.
• To remove a state, click the button at the bottom of the Overridden Tone States
section. This removes the last state in the list.
6. For the On states, select the frequency to play in the corresponding Frequencies column.
The frequencies defined in the Overridden Tone Definition section are listed as clickable buttons.
You can use from one to four frequencies. A blue button indicates that the frequency is selected.
7. Set the corresponding Duration field with the number of times, in ms, to perform the action of the
state.
The range is from 10 ms to 56000 ms. The tone stays indefinitely in the state (continuous) if no time
is specified.
8. In the corresponding Loop drop-down menu, select whether or not to stop looping between states
after a number of loops defined in Step 4.
When the number of loops is reached, the next state is s(n+1) for the state s(n) instead of the state
defined in the Next State drop-down menu.
9. In the corresponding Next State drop-down menu, select the next tone state to use when the time
has elapsed.
This value is not available if the Duration field is empty.
10. Click Submit if you do not need to set other parameters.
This chapter describes how to configure the Music on Hold (MoH) parameters.
MP3 file download server setup.
Music on Hold configuration.
Standards Supported • RFC 1350: The TFTP Protocol (Revision 2) (client-side only)
• RFC 2616: Hypertext Transfer Protocol - HTTP/1.1 (client-
side only)
To download a MP3 file, you may need to setup the following applications on your computer:
TFTP server with proper root path
HTTP server with proper root path
The Music on Hold sub-page of the Telephony page allows you to configure the music (in the form of an MP3
file) that plays when a local user has been put on hold. Note that transfers exceeding 5 minutes are cancelled.
3
4
5
2. In the Music On Hold Configuration section, indicate whether or not the unit should play music when
being put on hold in the Streaming drop-down menu.
When enabled, music is played toward the telephony side when being put on hold from the network
side.
3. In the Transfer Configuration section, enter the URL to the MP3 file to use in the URL field.
This file is loaded when the Aastra unit starts and reloaded every time the Reload Interval value
elapses (see Step 5). It must be smaller than 1024 Kilobytes unless otherwise specified in a
customer profile.
The MP3 file downloaded must be encoded with a sampling rate of 8000 Hz (only available through
MPEG version 2.5) and in mono channel mode. All other types of file will be rejected. The decoding
output will be in mono channel mode, with a sample rate of 8000 Hz and with 8 bits per sample.
You can use the following supported protocols to transfer the file:
• HTTP: HyperText Transfer Protocol.
• TFTP: Trivial File Transfer Protocol.
URLs using any other transfer protocol are invalid.
Note: The HTTP protocol does not support spaces between characters in the URL.
Caution: The User Name and Password fields are not accessible if you have the User or Observer access
right. See “Users” on page 591 for more details.
5. Set the time, in hours, between attempts to load the MP3 file in the Reload Interval field.
If you enter the value 0, this means that the unit loads the file only once at unit startup. Any other
value between 1 and 6000 is the number of hours between automatic reloads of the file. When a
manual file download is triggered, the counter is not reset so the next reload will happen at the same
time.
6. If you do not need to set other parameters, do one of the following:
• To save your settings without transferring the MP3 file, click Submit.
• To save your settings and transfer the MP3 file now, click Submit & Transfer Now.
• To save your settings and stop a file transfer in progress, click Submit & Cancel
Transfer.
37 Country Parameters
Configuration
Country Configuration
The Misc sub-page of the Telephony page allows you to configure the country in which the unit is located.
2. In the Country section, select the country in which the Aastra unit is located in the Country Selection
drop-down menu.
It is very important to set the country in which the unit is used because a number of parameter
values are set according to this choice, such as tones, rings, impedances, and line attenuations.
See “Appendix A - Country-Specific Parameters” on page 603 for more information on these
country-specific settings.
3. Click Submit if you do not need to set other parameters.
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
Caution: Use these settings with great care. Aastra recommends not to modify the user gain variables
unless absolutely necessary because default calibrations may no longer be valid.
Modifying user gains may cause problems with DTMF detection and voice quality – using a high user gain
may cause sound saturation (the sound is distorted). Furthermore, some fax or modem tones may no longer
be recognized. The user gains directly affect the fax communication quality and may even prevent a fax to
be sent.
You can compensate with the user gain if there is no available configuration for the country in which the Aastra
unit is located. Because the user gain is in dB, you can easily adjust the loss plan, e.g., if you need an
additional 1 dB for analog to digital, put 1 for user gain output.
You can use two types of configuration as described in “Default vs. Specific Configurations” on page 326.
You can also use the following line in the CLI or a configuration script:
telIf.defaultCountryCustomizationUserGainOutputOffset="Value"
Values range from -12 dB to +12 dB. However, going above +6 dB may introduce clipping/distortion
depending on the country selected.
3. If you want to set a different output gain offset for one or more interfaces, set the following variables:
• specificCountryCustomizationUserGainEnableConfig variable for the specific
interface you want to configure to enable.
• specificCountryCustomizationUserGainOutputOffset variable for the specific line
you want to configure.
You can also use the following lines in the CLI or a configuration script:
telIf.specificCountryCustomizationUserGain.EnableConfig[InterfaceId="Interface"]
="1"
telIf.specificCountryCustomizationUserGain.OutputOffset[InterfaceId="Interface"]
="Value"
where:
• Interface is the name of the interface you want to configure (for instance, Slot2/Pri1).
• Value is the output gain offset.
4. Define the default user input gain offset in dB (from digital to analog) in the
defaultCountryCustomizationUserGainInputOffset variable.
You can also use the following line in the CLI or a configuration script:
telIf.defaultCountryCustomizationUserGainInputOffset="Value"
Values range from -12 dB to +12 dB. However, going above +6 dB may introduce clipping/distortion
depending on the country selected.
5. If you want to set a different input gain offset for one or more interfaces, set the following variables:
• specificCountryCustomizationUserGainEnableConfig variable for the specific
interface you want to configure to enable.
• specificCountryCustomizationUserGainInputOffset variable for the specific line
you want to configure.
You can also use the following lines in the CLI or a configuration script:
telIf.specificCountryCustomizationUserGain.EnableConfig[InterfaceId="Interface"]
="1"
telIf.specificCountryCustomizationUserGain.InputOffset[InterfaceId="Interface"]=
"Value"
where:
• Interface is the name of the interface you want to configure (for instance, Slot2/Pri1).
• Value is the input gain offset.
6. Restart the TelIf service by accessing the scmMIB and setting the serviceCommandsRestart
variable for the TelIf service to restart.
You can also use the following line in the CLI or a configuration script:
scm.serviceCommands.Restart[Name=TelIf]="10"
Dialing Settings
Dialing settings allow you to configure how the Aastra unit dials numbers.
When selecting a country (see “Country Configuration” on page 325 for more details), each country has default
dialing settings. However, you can override these values and define your own dialing settings.
You can use two types of configuration as described in “Default vs. Specific Configurations” on page 326.
telIf.specificCountryCustomizationDialing.EnableConfig[InterfaceId="Interface"]=
"1"
telIf.specificCountryCustomizationDialing.Override[InterfaceId="Interface"]="1"
where Interface is the name of the interface you want to configure (for instance, Slot2/Pri1).
4. Set an inter-digit dial delay in the defaultCountryCustomizationDialingInterDtmfDialDelay
variable.
You can also use the following line in the CLI or a configuration script:
telIf.defaultCountryCustomizationDialing.InterDtmfDialDelay="Value"
This is the delay, in milliseconds (ms), between two DTMFs when dialing the destination phone
number. Values range from 50 ms to 600 ms.
5. If you want to set a different inter-digit dial delay for one or more interfaces, set the following
variables:
• specificCountryCustomizationDialingEnableConfig variable for the specific
interface you want to configure to enable.
• specificCountryCustomizationDialingInterDtmfDialDelay variable for the
specific interface you want to configure.
You can also use the following lines in the CLI or a configuration script:
telIf.specificCountryCustomizationDialing.EnableConfig[InterfaceId="Interface"]=
"1"
telIf.specificCountryCustomizationDialing.InterDtmfDialDelay[InterfaceId="Slot3/
Bri3"]="Value"
where Interface is the name of the interface you want to configure (for instance, Slot2/Pri1).
6. Set the DTMF duration value in the defaultCountryCustomizationDialingDtmfDuration
variable.
You can also use the following line in the CLI or a configuration script:
telIf.defaultCountryCustomizationDialing.DtmfDuration="Value"
This is the duration, in milliseconds (ms), a DTMF is played when dialing the destination phone
number. Values range from 50 ms to 600 ms.
7. If you want to set a different DTMF duration value for one or more interfaces, set the following
variables:
• specificCountryCustomizationDialingEnableConfig variable for the specific
interface you want to configure to enable.
• specificCountryCustomizationDialingDtmfDuration variable for the specific
interface you want to configure.
You can also use the following lines in the CLI or a configuration script:
telIf.specificCountryCustomizationDialing.EnableConfig[InterfaceId="Interface"]=
"1"
telIf.specificCountryCustomizationDialing.DtmfDuration[InterfaceId="Interface"]=
"Value"
8. Set the delay, in milliseconds, between two MFR1s when dialing on the interface in the
DefaultCountryCustomizationDialingInterMfR1DialDelay variable.
See “Chapter 23 - E&M CAS Configuration” on page 253 for more details on MFR1 signalling.
You can also use the following line in the CLI or a configuration script:
9. Set the delay, in milliseconds, between two MFR1s when dialing on the interface by putting the
following line in the configuration script:
telIf.defaultCountryCustomizationDialing.InterMfR1DialDelay="Value"
Values range from 50 ms to 600 ms.
10. If you want to set a different delay value for one or more interfaces, set the following variables:
telIf.specificCountryCustomizationDialing.EnableConfig[InterfaceId="Interface"]=
"1"
telIf.specificCountryCustomizationDialing.InterMfR1DialDelay[InterfaceId="Interf
ace"]="Value"
11. Set the duration, in milliseconds, of a MFR1 when dialling on the interface in the
DefaultCountryCustomizationDialingMfR1Duration variable.
See “Chapter 23 - E&M CAS Configuration” on page 253 for more details on MFR1 signalling.
You can also use the following line in the CLI or a configuration script:
12. Set the duration, in milliseconds, of a MFR1 when dialing on the interface by putting the following
line in the configuration script:
telIf.DefaultCountryCustomizationDialing.MfR1Duration="Value"
Values range from 50 ms to 600 ms.
13. If you want to set a different duration value for one or more interfaces, set the following variables:
telIf.specificCountryCustomizationDialing.EnableConfig[InterfaceId="Interface"]=
"1"
telIf.specificCountryCustomizationDialing.MfR1Duration[InterfaceId="Interface"]=
"Value"
14. Restart the TelIf service by accessing the scmMIB and setting the serviceCommandsRestart
variable for the TelIf service to restart.
You can also use the following line in the CLI or a configuration script:
scm.serviceCommands.Restart[Name=TelIf]="10"
Call detail record (CDR) in VoIP contains information about recent system usage such as the identities of
sources (points of origin), the identities of destinations (endpoints), the duration of each call, the total usage
time in the billing period and many others.
The Misc sub-page of the Telephony page allows you to configure the CDR parameters.
1
2
3
2. Specify the format of the syslog Call Detail Record in the Syslog Format field.
The formal syntax description of the protocol is as follows:
Precision=DIGIT
Width=DIGIT
MacroId=(ALPHA / "_")
Macro=%[Width]|[.Precision]|[Width.Precision]MacroId
The Width field is the minimum width of the converted argument. If the converted argument has
fewer characters than the specified field width, then it is padded with spaces. If the converted
argument has more characters than the specified field width, the field width is extended to whatever
is required.
The Precision field specifies the maximum number of characters to be printed from a string.
Examples :
sipid=SipUser001
CDR Log: %sipid --> CDR Log : SipUser001
CDR Log: %15sipid --> CDR Log : SipUser001
CDR Log: %15.5sipid --> CDR Log : SipUs
CDR Log: %.5sipid --> CDR Log : SipUs
Call Detail Record predefined macros.
Control characters:
Table 242: Control Character
Character Value
%% %
\n Split message
Macro Value
%id CDR ID. The CDR ID is unique. The ID is incremented by one each time it is
represented in a CDR record
%sipid SIP call ID. Blank if no SIP interface was used during the call.
%ocgnum Original calling number. Calling number as received by the unit.
%cgnum Calling number. Calling number after manipulation by the call router.
Macro Value
Macro Value
3. Set the Syslog facility used by the unit to route the Call Detail Record messages in the Syslog
Facility field.
The application can use Local0 through Local7.
4. Click Submit if you do not need to set other parameters.
Introduction
The Aastra unit’s call router allows you to route calls between interfaces. Based on a set of routing criteria, the
call router determines the destination (interface) for every incoming call. The forwarding decisions are based
on the following tables:
Table 244: Call Router Table Types
Table Description
Routing The routing table contains one or more routes. Each route associates a destination to a call
that matches a set of criteria. See “Routes” on page 353 for more details.
Mapping The mapping table contains one or more mapping types and expressions. A mapping
modifies call properties such as the calling and called party numbers according to the network
requirements. These mappings are specifically called within a route. See “Mappings” on
page 358 for more details.
Call Call signalling specifies how to set up a call to the destination Aastra unit or 3rd party
Signalling equipment. Call signalling properties are assigned to a route and used to modify the
behaviour of the call at the SIP protocol level. See “Signalling Properties” on page 368 for
more details.
SIP A SIP headers translation overrides the default value of SIP headers in an outgoing SIP
Headers message. See “SIP Headers Translations” on page 372 for more details.
Translation
Call A call properties translation overrides the default value of call properties in an incoming SIP
Properties message. See “Call Properties Translations” on page 376 for more details.
Translation
Table Description
Hunt The hunt table contains one or more hunt entries, each with a set of possible destinations. A
hunt tries the destinations until one of the configured destinations accepts the call. See “Hunt
Service” on page 379 for more details.
SIP The SIP Redirects table allows configuring of SIP redirections that can be used as Route
Redirects destinations. When the Route source is a SIP interface, incoming SIP Invites are replied with
a 302 “Moved Temporarily” SIP response. See “SIP Redirects” on page 387 for more details.
When a new call comes from one of the Aastra unit interfaces, it is redirected to the routing table. The following
figure illustrates the Aastra unit call router:
Call Router
Signalling Mapping 1
Properties 1
Hunt 1
Translation 1
(SIP Headers or
call properties)
Limitations
The call routing service has the following limitations:
A call coming from a SIP interface cannot be routed to another SIP interface. When that occurs,
the call automatically fails.
A call automatically fails if it is redirected to a route or hunt more than 10 times.
Maximum number of Routes: 40
Maximum number of Mapping Types: 40
Maximum number of Mapping Expressions: 100
Maximum number of Hunts: 40
Maximum number of Signaling Properties: 40
Maximum number of SIP Header Translations: 100
Maxium number of Call Properties Translations: 100
Regular Expressions
Standards Supported • IEEE Std 1003.1-2001: IEEE Standard for Information
Technology---Portable Operating System Interface (POSIX®)
Some of the routing types described in “Routing Type” on page 338 require that you enter them following the
regular expression syntax. A regular expression is a string used to find and replace strings in other large
strings. The Aastra unit uses regular expressions to enter a value in several routing types, often by using
wildcard characters. These characters provide additional flexibility in designing call routing and decrease the
need for multiple entries in configuring number ranges.
The expression cannot begin by “^”, it is implicit in the expression. The following table shows some of the
wildcard characters that are supported:
Table 245: Regular Expressions Wildcards
Character Description
. Single-digit place holder. For instance, 555 .... matches any dialed number beginning with
555, plus at least four additional digits. Note that the number may be longer and still match.
* Repeats the previous digit 0, 1, or more times. For instance, in the pattern:
1888*1
the pattern matches:
1881, 18881, 188881, 1888881
Note: If you are trying to handle the asterisk (*) as part of a dialed number, you must use \*.
[] Range of digits.
• A consecutive range is indicated with a hyphen (-), for instance, [5-7].
• A nonconsecutive range is indicated without a delimiter, for instance, [58].
• Both can be used in combination, for instance [5-79], which is the same as
[5679].
You may place a (^) symbol right after the opening bracket to indicate that the specified range
is an exclude list. For instance, [^01] specifies the same range as [2-9].
Note: The call router only supports single-digit ranges. You cannot specify the range of
numbers between 99 and 102 by using [99-102].
() Indicates a pattern (also called group), for instance, 555(2525). It is used when replacing a
number in a mapping. See “Groups” on page 337 for more details.
? Matches 0 or 1 occurrence of the previous item. For instance, 123?4 matches both 124 and
1234.
+ Repeats the previous digit one or more time. For instance 12+345 matches 12345, 122345,
etc. (but not 1345). If you use the + at the end of a number, it repeats the last number one or
more times. For instance: 12345+ matches, 12345, 123455, 1234555, etc.
| Indicates a choice of matching expressions (OR).
The matching criterion implicitly matches from the beginning of the string, but not necessarily up to the end.
For instance, 123 will match the criterion 1, but it will not match the criterion 2.
If you want to match the whole string, you must end the criterion with “$”. For instance, 123 will not match the
criterion 1$ and will match the criterion 123$.
Note: You can use the “<undefined>” string if you want to match a property that is not defined.
You can also use the macro “local_ip_port“ to replace the properties by the local IP address and port of the
listening network of the SIP gateway used to send the INVITE.
Groups
A group is placed within parenthesis. It is used when replacing a string in a mapping. You can use up to nine
groups (defined by “\1” to “\9”) and matching is not case sensitive. “\0” represents the whole string. Lets say
for instance you have the following string:
9(123(45)6)
The following describes how the groups are replaced in a properties manipulation:
Table 246: Groups Replacement Example
Replacement Result
\0 9123456
\1 123456
\2 45
\3
Routing Type
Standards Supported • ITU-T Recommendation Q.931: ISDN user-network interface
layer 3 specification for basic call control
The following sub-sections list the available routing types of the call router and their supported values. The
routing types that offer choices use the choices as defined in the Q.931 standard. Q.931 is ISDN’s connection
control protocol, roughly comparable to TCP in the Internet protocol stack. The values may also be a special
tag, as described in “Special Tags” on page 344.
Table 247: Routing Types Locations
Diverting Party Number Type “Last / Original Diverting Party Number Type” on page 343
Diverting Public Type Of Number “Last / Original Diverting Public Type Of Number” on page 343
Diverting Pivate Type Of Number “Last / Original Diverting Private Type Of Number” on page 343
Diverting Number Presentation “Last / Original Diverting Number Presentation” on page 344
SIP Privacy Type “SIP Privacy Type” on page 344
Aastra recommends to carefully define the routing requirements and restrictions that apply to your installation
before starting the routing configuration. This will help you determine the types of routing you need. When this
is done, define the routes and mappings, as well as the hunts that you need to fulfil these requirements. You
may need several entries of the same type to achieve your goals.
See also “Call Properties Parameters” on page 344 for a description of the parameters used by the various
routing types and interfaces of the call router.
Value Description
Note: The called type of number is set to international if the To username is an E.164 with the prefix “+”.
The calling type of number is set to international if the From username is an E.164 with the prefix “+”.
available:
Table 249: Numbering Plan Indicator Values
Value Description
Calling PI
Presentation indicator of the calling party number. The following values are available:
Table 250: Presentation Indicator Values
Value Description
You may want to remove the calling party number when the user sets the presentation indicator to restricted.
To achieve this, route restricted calls to a mapping that sets the Calling E164 to an empty string.
Calling SI
Screening indicator of the calling party number. The following values are available:
Table 251: Screening Indicator Values
Value Description
not- The user provides the calling party number but the number is not screened by the network.
screened Thus the calling party possibly sends a number that it does not own.
passed The calling party number is provided by the user and it passes screening.
failed The calling party number is set by the user and verification of the number failed.
network The originating network provides the number in the calling party number parameter.
You may want to remove the calling party number when it is not screened or screening failed. To do so, route
these calls to a mapping that sets the Calling E164 to an empty string. If you want to drop calls when the calling
party number is not screened or screening failed, use the Calling Si as criteria for the route.
Calling ITC
The information transfer capability field of the bearer capability information element in the ISDN setup
message. The following values are available:
Table 252: Information Transfer Capability Values
Value Description
The Aastra unit currently supports the following Information Transfer Capabilities when receiving calls to and
from the ISDN (named as in Q.931, 05/98):
Speech
Unrestricted Digital Information
3.1 kHz Audio
Those are respectively referenced as Speech, Unrestricted and 3.1 kHz in the call routing configuration.
When initiating calls towards the ISDN, the Aastra unit uses the calling ITC value if it is one of the three listed
above. If none is set, it uses 3.1 kHz Audio. If the calling ITC set by the call router is different from the three
listed above, the call is rejected.
Note: Terminals connected to analog extensions (e.g. of a PBX) do not supply information transfer
capability values in their call setup. The configuration of the analog port on the Terminal Adapter, NT or PBX
is thus responsible to insert this value. The configuration of this value is however often omitted or wrong.
The ITC value may therefore not be a reliable indication to differentiate between analogue speech, audio or
Fax Group 3 connections. Furthermore, calls from SIP interfaces do not differentiate between bearer
capabilities. They always set the information transfer capability property to 3.1Khz.
Date/Time
Day of week and time period and/or date and time period. The following are the accepted formats:
Table 253: Date/Time Accepted Formats
Format Description
Many of the formats above can be concatenated to form one expression. They must be separated by |. For
instance: 25.12.2006 | SUN.
This is the last or original diverting reason in ISDN setup and SIP INVITE messages. The following values are
available:
Table 254: Diverting Reason Values
Value Description
Refer to “You can set the SIP transfer method when an endpoint is acting as the transferor in a blind transfer
scenario.” on page 345 to select the SIP method used to receive/send call diversion information in an INVITE.
Value Description
Value Description
Value Description
unknown Unknown.
leg2-reg Leg2 reg.
leg1-reg Leg1 reg.
Value Description
Value Description
Value Description
Special Tags
You can use the following special tags as routing types values.
Table 260: Special Tags
Tag Description
This section describes the information the call router uses for the various SIP fields.
Table 261: Call Properties to SIP
To The Aastra unit uses the calling URI to populate the To field if not undefined.
Otherwise, the unit does the following:
• Uses the called Name for the friendly name if not undefined.
• Uses the called SipUsername for the user name if not empty or
undefined; otherwise, uses the called E164 for the username. If it is
empty or undefined, the Aastra unit rather uses the value defined in
the Default Username Value field of the SIP > Interop > SIP Interop
parameters as username (see “SIP Interop” on page 312 for more
details). The unit uses the called Phone Context for the user's
'phone-context' parameter if not empty. If a 'phone-context'
parameter is added, the URI parameter 'user' is also automatically
added. Its value is defined in the SIP URI User Parameter Value
field of the SIP > Interop > SIP Interop parameters. If empty, then
the value 'phone' is used
• Uses the called Host for the host if not undefined, otherwise uses the
configured home domain proxy host.
• Prefixes the user name with “+” and adds the URI parameter “user”
with the value “phone” if the called TON is “international”.
• If there is no URI parameter “user” yet and the SIP URI User
Parameter Value field of the SIP > Interop > SIP Interop parameters
is not empty, then the parameter is added with the value defined by
the field.
From The Aastra unit uses the called URI to populate the From field if not undefined.
Otherwise, the unit does the following:
• Uses the calling Name for the friendly name if not undefined.
• Uses the calling SipUsername for the user name if not empty or
undefined; otherwise, uses the calling E164 for the username. If it is
empty or undefined, the Aastra unit rather uses the value defined in
the Default Username Value field of the SIP > Interop > SIP Interop
parameters as username (see “SIP Interop” on page 312 for more
details).The unit uses the calling Phone Context for the user's
'phone-context' parameter if not empty. If a 'phone-context'
parameter is added, the URI parameter 'user' is also automatically
added. Its value is defined in the SIP URI User Parameter Value
field of the SIP > Interop > SIP Interop parameters. If empty, then
the value 'phone' is used.
• Uses the calling Host for the host if not undefined, otherwise uses
the configured home domain proxy host.
• Prefixes the user name with “+” and adds the URI parameter “user”
with the value “phone” if the calling TON is “international”.
• If there is no URI parameter “user” yet and the SIP URI User
Parameter Value field of the SIP > Interop > SIP Interop parameters
is not empty, then the parameter is added with the value defined by
the field.
Request URI The Aastra unit uses the same information as the To field.
Contact The Aastra unit uses the same information as the From field, but with the
current IP address/port for the host.
Diversion A Diversion header is added if the Last Diverting E.164 property is present and
not empty. This Diversion header is constructed as follows:
• The username of the URI is set to the value of the Last Diverting
E.164 property.
• The host of the URI is set to the configured home domain proxy host.
• The reason field is set according to value of the Last Diverting
Reason property:
• cfu: "unconditional"
• cfb: "user-busy"
• cfnr: "no-answer"
• All other values or when undefined: "unknown'.
• The field counter is set to the value of DivertingCounter if the
Original Diverting E.164 property is set to empty or undefined,
otherwise it is set to DivertingCounter -1.
A second Diversion header is added if the Last Diverting E.164 and Original
Diverting E.164 properties are present and not empty. This Diversion header is
constructed as follows:
• The username of the URI is set to the value of the Original Diverting
E.164 property.
• The host of the URI is set to the configured home domain proxy host.
• The reason field is set according to the value of the Original
Diverting Reason property:
• cfu: "unconditional"
• cfb: "user-busy"
• cfnr: "no-answer"
• All other values or when undefined: "unknown'.
The field counter is set to 1.
This section describes the information the call router uses for the various ISDN information elements.
Table 263: Call Properties to ISDN
Bearer Capabilities If valid, the calling ITC is used to fill the “information transfer capability” (octet 3
[5:1]). Otherwise, the ITC is set to “3.1 kHz audio”. If more than one bearer
capability information elements is provided in a prioritized list, they all receive
the same ITC. This information element is included in the SETUP message
only for outgoing calls.
Calling Party Number Uses the calling E164 to fill the field “number digits” (octet 4).
Uses the calling TON to fill the field “type of number” (octet 3 [7:5]).
Uses the calling PI to fill the field “presentation indicator” (octet 3a [7:6).
Uses the calling SI to fill the field “screening indicator” (octet 3a [2:1]).
Uses the calling NPI to fill the field “numbering plan identification” (octet 3
[4:1]).
Called Party Number Uses the called E164 to fill the field “number digits” (octet 4).
Uses the called TON to fill the field “type of number” (octet 3 [7:5]).
Uses the called NPI to fill the field “numbering plan identification” (octet 3 [4:1]).
Display Uses the calling E164 to fill the field “display information” (octet 3).
Called Bearer Channel The called bearer channel is used to select a specific ISDN bearer channel for
an outgoing ISDN call.
Calling Name Field “display information” (octet 3) of the Display information element, if
included in the SETUP Q.931 message.
Called E164 Field “number digits” (octet 4) of the called party information element included
in the SETUP Q.931 message.
Calling E164 Field “number digits” (octet 4) of the calling party information element included
in the SETUP Q.931 message.
Called TON Field “type of number” (octet 3 [7:5]) of the called party information element
included in the SETUP Q.931 message.
Calling TON Field “type of number” (octet 3 [7:5]) of the calling party information element
included in the SETUP Q.931 message.
Calling PI Field “presentation indicator” (octet 3a [7:6) of the calling party information
element included in the SETUP Q.931 message.
Calling SI Field “screening indicator” (octet 3a [2:1]) of the calling party information
element included in the SETUP Q.931 message.
Calling ITC Field “information transfer capability” (octet 3 [5:1]) of the bearer capability
information element included in the SETUP Q.931 message.
Called NPI Field “numbering plan identification” (octet 3 [4:1]) of the called party
information element included in the SETUP Q.931 message.
Calling NPI Field “numbering plan identification” (octet 3 [4:1]) of the calling party
information element included in the SETUP Q.931 message.
Calling Bearer Channel Represents the ISDN bearer channel on which the ISDN call is received.
All others The property is undefined.
Caller ID Description
Number If the PI property is present and not set to "allowed", the number is "P".
Otherwise, the number is set to the value of the E164 property (truncated to the
first 20 characters). See “Auto-Routing” on page 517 for details.
Name If the PI property is present and not set to "allowed", the name is "Anonymous".
Otherwise, the name is set to the value of the Name property (truncated to the
first 50 characters). See “Auto-Routing” on page 517 for details.
Caller ID Description
Calling E164 If the auto routing is enabled and the E164 field of the Call Router > Auto-
routing page is not empty (see “Auto-Routing” on page 517 for details), the
value of the E164 field. Otherwise, the property is not present.
Calling Name If the auto routing is enabled and the Name field of the Call Router > Auto-
routing page is not empty (see “Auto-Routing” on page 517 for details), the
value of the Name field. Otherwise, the property is not present.
Calling SIP Username If the auto routing is enabled and the SIP Username field of the Call Router >
Auto-routing page is not empty (see “Auto-Routing” on page 517 for details),
the value of the SIP Username field. Otherwise, the property is not present.
Called E164 For automatic calls, the E.164 defined in the Automatic Call Target field of the
Telephony > Services page (see “Automatic Call” on page 419 for more
details).
For other calls, the dialed digit after the transformation defined in the
Transformation field of the Allowed DTMF Map section (Telephony > DTMF
Maps page – see “Allowed DTMF Maps” on page 405 for more details).
Called Name For automatic calls, the name specified in the Automatic Call Target field of the
Telephony > Services page (see “Automatic Call” on page 419 for more
details). The property is not present if the target address does not contain a
name.
For other calls, the property is not present.
Caller ID Description
Called Host For automatic calls, the host specified in the the Automatic Call Target field of
the Telephony > Services page (see “Automatic Call” on page 419 for more
details). The property is not present if the target address does not contain a
host.
For other calls, the host defined in the Target field of the Allowed DTMF Map
section (Telephony > DTMF Maps page – see “Allowed DTMF Maps” on
page 405 for more details). The property is not present if the target host is not
configured for the matching DTMF map.
Caller ID Description
Caller ID Description
Calling E164 If the caller ID is detected, the numbers provided by the caller ID.
If the auto routing is enabled and the E164 field of the Call Router > Auto-
routing page is not empty (see “Auto-Routing” on page 517 for details), the
value of the E164 field. Otherwise, the property is not present.
Calling Name If the caller ID is detected, the name provided by the caller ID.
If the auto routing is enabled and the Name field of the Call Router > Auto-
routing page is not empty (see “Auto-Routing” on page 517 for details), the
value of the Name field. Otherwise, the property is not present.
Calling SIP Username If the caller ID is detected, the property is not present.
If the auto routing is enabled and the SIP Username field of the Call Router >
Auto-routing page is not empty (see “Auto-Routing” on page 517 for details),
the value of the SIP Username field. Otherwise, the property is not present.
Called E164 For automatic calls, the E.164 defined in the Automatic Call Target field of the
Telephony > Services page (see “Automatic Call” on page 419 for more
details).
For other calls, the dialed digit after the transformation defined in the
Transformation field of the Allowed DTMF Map section (Telephony > DTMF
Maps page – see “Allowed DTMF Maps” on page 405 for more details).
Called Name For automatic calls, the name specified in the Automatic Call Target field of the
Telephony > Services page (see “Automatic Call” on page 419 for more
details). The property is not present if the target address does not contain a
name.
For other calls, the property is not present.
Caller ID Description
Called Host For automatic calls, the host specified in the the Automatic Call Target field of
the Telephony > Services page (see “Automatic Call” on page 419 for more
details). The property is not present if the target address does not contain a
host.
For other calls, the host defined in the Target field of the Allowed DTMF Map
section (Telephony > DTMF Maps page – see “Allowed DTMF Maps” on
page 405 for more details). The property is not present if the target host is not
configured for the matching DTMF map.
PI (calling) Network-side:
Note that the calling PI, SI, TON and NPI are present in Calling Party information elements in SETUP
messages sent by the network-side only when CLIP is enabled. They should always be present in messages
sent by the user-side. See “Chapter 21 - ISDN Configuration” on page 177 for more details on CLIP.
Routes
The routing table contains one or more routes. These routes forward an incoming or outgoing call to another
route, interface, or hunt based on a specific call property such as the called party number. It may also use a
mapping to modify the call setup message of a call and a signalling property to modify the behaviour of the
call at the SIP protocol level.
Once the call router finds a route that matches, it does not check the other routes, even if some of them may
still match. The routes sequence is thus very important. The call router follows the routing table rows (routes)
as they are entered in the web interface. If you want the call router to try to match one row before another one,
you must put that row first.
When a call arrives, the call router proceeds as follows:
1. It examines the call property as specified with the routes.
To select a route, the call must match all three of the Source, Properties Criteria, and Expression
Criteria parameters.
2. It selects the first matching route in the list of routes.
Note: You can revert back to the configuration displayed in the Call Router > Status web page at any time
by clicking the Rollback button at the bottom of the page. All modified settings in the Call Router > Route
Config page will be lost.
Creating/Editing a Route
The web interface allows you to create a route or modify the parameters of an existing one.
• If you want to add a route at the end of the existing rows, click the button at the
bottom right of the Route section.
• If you want to edit an existing route, locate the proper row in the table and click the
button.
This brings you to the Configure Route panel.
4
5
6
7
8
9
4. Enter one or more sources to compare with the call and match in order to select the route in the
Source field.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
A source may be:
• route-name: The call uses the route name.
• sip-name: The call comes from the SIP interface name.
• isdn-name: The call comes from the ISDN interface name.
• r2-name: The call destination is set to the R2 interface name.
• e&m-name: The call comes from the E&M interface name.
• fxs-name: The call destination is set to the FXS interface name.
• fxo-name: The call destination is set to the FXO interface name.
If you want to use multiple sources, you must separate them by commas.
For instance, if you want to route calls that come from the SIP interface “default”, enter the following
value:
sip-default
If you want to route calls that come from the SIP interfaces “default” and “other”, enter the following
value:
sip-default,sip-other
Keep in mind that to select a route, the call must match all three of the Source, Properties Criteria,
and Expression Criteria parameters.
5. Select a call property to compare with the call and match in order to select the route in the Properties
Criteria drop-down menu.
The call router offers several different routing types. Each type specifies which call property the call
router examines.
Table 270: Routing Types
Type Description
Called E164 Routes calls based on the called party E.164 number.
Calling E164 Routes calls based on the calling party E.164 number.
Called TON Routes calls based on the called party type of number.
Calling TON Routes calls based on the calling party type of number.
Called NPI Routes calls based on the called party numbering plan indicator.
Calling NPI Routes calls based on the calling party numbering plan indicator.
Called Name Routes calls based on the display name of the called party.
Calling Name Routes calls based on the display name of the calling party.
Called Host Routes calls based on the signalling IP address or domain name.
Calling Host Routes calls based on the signalling IP address or domain name.
Called URI Routes calls based on the To-URI.
Calling URI Routes calls based on the From-URI.
Calling PI Routes calls based on the presentation indicator.
Calling SI Routes calls based on the screening indicator.
Calling ITC Routes calls based on the information transfer capability.
Date/Time Routes calls based on the date and/or time the call arrived at the call router. A
link called Time criteria editor appears on the right of the Expression criteria
field. Use it to easily configure the Date/Time type.
Type Description
Called Phone Routes calls based on the called party phone context.
Context
Calling Routes calls based on the calling party phone context.
Phone
Context
Called SIP Routes calls based on the called party SIP username.
Username
Calling SIP Routes calls based on the calling SIP username.
Username
Called Routes calls based on the called bearer channel properties.
Bearer
Channel
Calling Routes calls based on the calling bearer channel properties.
Bearer
Channel
Calling SIP Routes calls based on the calling SIP privacy properties.
Privacy
Keep in mind that to select a route, the call must match all three of the Source, Properties Criteria,
and Expression Criteria parameters.
6. Enter the expression (related to the call properties selected in the previous step) to compare with
the call and match in order to select the route in the Expression Criteria field.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
See “Routing Type” on page 338 for a list of available values for each call property.
For instance, if the property is Calling TON, you could instruct the call router to look for the following
expression:
international
If you have selected the Date/Time property in the above step, you can click the Time criteria
editor link and use the editor to easily configure the Date/Time parameters.
• Select between the Day-Time or Time-Period settings in the Select Criteria Type drop-
down menu. If you select Time-Period, the editor changes as follows:
• Select or enter the parameters you want, then click the Add to List button. If a
parameter is invalid (for instance, the end date is inferior to the start date), it is
displayed in red in the Time Criteria List field.
• To remove an existing parameter, select it in the Time Criteria List field, then click the
Remove Selected button.
• To update an existing parameter, select it in the Time Criteria List field, then click the
Update Selected button.
• To remove all parameters, click the Clear Parameters button.
• When done, click the Submit button.
Keep in mind that to select a route, the call must match all three of the Source, Properties Criteria,
and Expression Criteria parameters.
7. If applicable, enter the name of mappings to apply to the call in the Mappings field.
You can enter more than one mapping by separating them with commas. These mappings are
executed in sequential order.
You can use the Suggestion column’s drop-down menu to select an existing mapping, if any.
The manipulations are executed before sending the call to the new destination. See “Mappings” on
page 358 for more details.
If you leave this field empty, no mapping is required.
8. Select the call signalling property of the route used to modify the behaviour of the call at the SIP
protocol level in the Call Signaling drop-down menu.
You must set call signaling properties as defined in “Signalling Properties” on page 368. You can
use the Suggestion column’s drop-down menu to select between existing properties, if any.
9. Select the destination of the call when it matches in the Destination field.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
The destination can be:
• route-name: The call destination is set to the route name.
• hunt-name: The call destination is set to the hunt name.
• sip-name: The call destination is set to the SIP interface name.
• isdn-name: The call destination is set to the ISDN interface name.
• r2-name: The call destination is set to the R2 interface name.
• e&m-name: The call destination is set to the E&M interface name.
• fxs-name: The call destination is set to the FXS interface name.
• fxo-name: The call destination is set to the FXO interface name.
• SipRedirect-name: When the Route source is a SIP interface, incoming SIP Invites are
replied with a 302 'Moved Temporarily' SIP response. See “SIP Redirects” on page 387
or more details.
For instance, if you want to route calls to the hunt “CallCenter”, enter the following:
hunt-CallCenter
Examples
The following are some examples of routes:
Moving a Route
Once the call router finds a routing entry that matches, it does not check the other entries, even if some of
them may still match. The routes sequence is thus very important. The call router follows the routing table rows
as they are entered in the web interface. If you want the call router to try to match one row before another one,
you must put that row first.
Deleting a Route
You can delete a routing row from the table in the web interface.
Mappings
Mapping entries modify the call setup message of a call. They thus influence the routing decision and/or the
setup message leaving the call router. They are specifically called within a route.
Like the routing table, the mapping table finds the first matching entry. It then executes it by manipulating a
call property. A mapping always examines one call property and changes another property.
The call router executes all mapping entries that match by following the mapping table rows as they are
entered in the web interface. If you want the call router to try to match one row before another one, you must
put that row first.
Note: You can revert back to the configuration displayed in the Call Router > Status web page at any time
by clicking the Rollback button at the bottom of the page. All modified settings in the Call Router > Route
Config page will be lost.
• If you want to add a mapping type entry at the end of the existing rows, click the
button at the bottom right of the Mapping Type section.
• If you want to edit an existing entry, locate the proper row in the table and click the
button.
This brings you to the Configure Mapping Type panel.
4
5
6
• If you want to add a mapping expression entry before an existing entry, locate the
proper row in the table and click the button of this row.
• If you want to add a mapping expression entry at the end of the existing rows, click the
button at the bottom right of the Mapping Expression section.
• If you want to edit an existing entry, locate the proper row in the table and click the
button.
This brings you to the Configure Mapping Expression panel.
4
5
6
7
Calling Name Selects an entry based on the display name of the calling party. You can use
wildcards to summarize entries as per “Called / Calling Name” on page 340.
TON If the Transformation value of the Mapping Type part is also a generic property,
this is applied to both this Calling TON and Called TON property.
Called TON Selects an entry based on the called party type of number as per “Called /
Calling TON” on page 339.
Calling TON Selects an entry based on the calling party type of number as per “Called /
Calling TON” on page 339.
NPI If the Transformation value of the Mapping Type part is also a generic property,
this is applied to both this Calling NPI and Called NPI property.
Called NPI Selects an entry based on the called party numbering plan indicator as per
“Called / Calling NPI” on page 339.
Calling NPI Selects an entry based on the calling party numbering plan indicator as per
“Called / Calling NPI” on page 339.
Host If the Transformation value of the Mapping Type part is also a generic property,
this is applied to both this Calling Host and Called Host property.
Called Host Selects an entry based on the remote signalling IP address or domain name of
the destination VoIP peer. You can use wildcards to summarize entries as per
“Called / Calling Host” on page 340.
Calling Host Selects an entry based on the remote signalling IP address or domain name of
the originating VoIP peer. You can use wildcards to summarize entries as per
“Called / Calling Host” on page 340.
Calling PI Selects an entry based on the presentation indicator as per “Calling PI” on
page 340.
Calling SI Selects an entry based on the screening indicator as per “Calling SI” on
page 340.
Calling ITC Selects an entry based on the information transfer capability as per “Calling ITC”
on page 341.
URI If the Transformation value of the Mapping Type part is also a generic property,
this is applied to both this Calling URI and Called URI property.
Called URI Selects an entry based on the called SIP URI properties. You can use wildcards
to summarize entries as per “Called / Calling URI” on page 340.
Calling URI Selects an entry based on the calling SIP URI properties. You can use wildcards
to summarize entries as per “Called / Calling URI” on page 340.
Date/Time Selects an entry based on the date and/or time the call arrived at the call router
as per “Date/Time” on page 341.
Phone Selects an entry based on the called or calling phone context properties as per
Context “Called / Calling Phone Context” on page 342.
Called Phone Selects an entry based on the called phone context properties as per “Called /
Context Calling Phone Context” on page 342.
Calling Selects an entry based on the calling phone context properties as per “Called /
Phone Calling Phone Context” on page 342.
Context
SIP Selects an entry based on the called or calling SIP username properties as per
Username “Called / Calling SIP Username” on page 342.
Called SIP Selects an entry based on the called SIP username properties as per “Called /
Username Calling SIP Username” on page 342.
Calling SIP Selects an entry based on the calling SIP username properties as per “Called /
Username Calling SIP Username” on page 342.
Last Selects an entry based on the last diverting reason properties as per “Last /
Diverting Original Diverting Reason” on page 342.
Reason
Last Selects an entry based on the last diverting E.164 properties as per “Last /
Diverting Original Diverting E.164” on page 343.
E164
Last Selects an entry based on the party number type of the last diverting number
Diverting properties as per “Last / Original Diverting Party Number Type” on page 343.
Party
Number Type
Last Selects an entry based on the public type of number of the last diverting number
Diverting properties as per “Last / Original Diverting Public Type Of Number” on page 343.
Public Type
Of Number
Last Selects an entry based on the private type of numbekr of the last diverting
Diverting number properties as per “Last / Original Diverting Private Type Of Number” on
Private Type page 343.
Of Number
Last Selects an entry based on the presentation of the last diverting number
Diverting properties as per “Last / Original Diverting Number Presentation” on page 344.
Number
Presentation
OriginalDiver Selects an entry based on the original diverting reason properties as per “Last /
tingReason Original Diverting Reason” on page 342.
OriginalDiver Selects an entry based on the original diverting E.164 properties as per “Last /
tingE164 Original Diverting E.164” on page 343.
Original Selects an entry based on the party number type of the original diverting number
Diverting properties as per “Last / Original Diverting Party Number Type” on page 343.
Party
Number Type
Original Selects an entry based on the public type of number of the original diverting
Diverting number properties as per “Last / Original Diverting Public Type Of Number” on
Public Type page 343.
Of Number
Called Selects an entry based on the called bearer channel properties as per “Called /
Bearer Calling SIP Username” on page 342.
Channel
Calling Selects an entry based on the calling bearer channel properties as per “Called /
Bearer Calling SIP Username” on page 342.
Channel
Calling SIP Selects an entry based on the calling SIP privacy properties as per “SIP Privacy
Privacyl Type” on page 344.
If you are editing a Date/Time property, you can click the Time criteria editor link and use the editor
to easily configure the Date/Time parameters.
• Select between the Day-Time or Time-Period settings in the Select Criteria Type drop-
down menu. If you select Time-Period, the editor changes as follows:
• Select or enter the parameters you want, then click the Add to List button. If a
parameter is invalid (for instance, the end date is inferior to the start date), it is
displayed in red in the Time Criteria List field.
• To remove an existing parameter, select it in the Time Criteria List field, then click the
Remove Selected button.
• To update an existing parameter, select it in the Time Criteria List field, then click the
Update Selected button.
• To remove all parameters, click the Clear Parameters button.
• When done, click the Submit button.
6. Enter the transformation (related to this specific output type) to apply in the Transformation field.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
If the transformation is to replace part of an expression, it can use the matched group of the criteria.
“\0” will be replaced by the whole criteria capability and “\1” to “\9” by the matched group. See
“Groups” on page 337 for more details.
See “Routing Type” on page 338 for a list of available transformation values.
Table 272: Output Type Transformation
E164 If the Criteria value of the Mapping Type part is also a generic property, this is
applied to both the Calling E164 and Called E164 properties.
Called E164 Modifies the called party E.164 number as per “Called / Calling E164” on
page 339.
Calling E164 Modifies the calling party E.164 number as per “Called / Calling E164” on
page 339.
Name If the Criteria value of the Mapping Type part is also a generic property, this is
applied to both the Calling Name and Called Name properties.
Called Name Sets the display name of the called party as per “Called / Calling Name” on
page 340.
Calling Name Sets the display name of the calling party as per “Called / Calling Name” on
page 340.
TON If the Criteria value of the Mapping Type part is also a generic property, this is
applied to both the Calling TON and Called TON properties.
Called TON Sets the called party type of number as per “Called / Calling TON” on page 339.
Calling TON Sets the calling party type of number as per “Called / Calling TON” on page 339.
NPI If the Criteria value of the Mapping Type part is also a generic property, this is
applied to both the Calling NPI and Called NPI properties.
Called NPI Sets the called party numbering plan indicator as per “Called / Calling NPI” on
page 339.
Calling NPI Sets the calling party numbering plan indicator as per “Called / Calling NPI” on
page 339.
Host If the Criteria value of the Mapping Type part is also a generic property, this is
applied to both the Calling Host and Called Host properties.
Called Host Sets the remote IP address or domain name of the destination VoIP peer as per
“Called / Calling Host” on page 340.
Calling Host Sets the remote IP address or domain name of the originating VoIP peer as per
“Called / Calling Host” on page 340.
Calling PI Sets the presentation indicator as per “Calling PI” on page 340.
Calling SI Sets the screening indicator as per “Calling SI” on page 340.
Calling ITC Sets the information transfer capability as per “Calling ITC” on page 341.
URI If the Criteria value of the Mapping Type part is also a generic property, this is
applied to both the Calling URI and Called URI properties.
Called URI Sets the called URI as per “Called / Calling URI” on page 340.
Calling URI Sets the calling URI as per “Called / Calling URI” on page 340.
Phone If the Criteria value of the Mapping Type part is also a generic property, this is
Context applied to both the Calling Phone Context and Called Phone Context properties.
Called Phone Sets the called Phone Context as per “Called / Calling Phone Context” on
Context page 342.
Calling Sets the calling Phone Context as per “Called / Calling Phone Context” on
Phone page 342.
Context
SIP If the Criteria value of the Mapping Type part is also a generic property, this is
Username applied to both the Calling SIP Username and Called SIP Username properties.
Called SIP Sets the called SIP Username as per “Called / Calling SIP Username” on
Username page 342.
Calling SIP Sets the calling SIP Username as per “Called / Calling SIP Username” on
Username page 342.
Last Sets the last diverting reason properties as per “Last / Original Diverting
Diverting Reason” on page 342.
Reason
Last Sets the last diverting E.164 properties as per “Last / Original Diverting E.164”
Diverting on page 343.
E164
Last Sets the party number type of the last diverting number properties as per “Last /
Diverting Original Diverting Party Number Type” on page 343.
Party
Number Type
Last Sets the public type of number of the last diverting number properties as per
Diverting “Last / Original Diverting Public Type Of Number” on page 343.
Public Type
Of Number
Last Sets the private type of number of the last diverting number properties as per
Diverting “Last / Original Diverting Private Type Of Number” on page 343.
Private Type
Of Number
Last Sets the presentation of the last diverting number properties as per “Last /
Diverting Original Diverting Number Presentation” on page 344.
Number
Presentation
Original Sets the original diverting reason properties as per “Last / Original Diverting
Diverting Reason” on page 342.
Reason
Original Sets the original diverting E.164 properties as per “Last / Original Diverting
Diverting E.164” on page 343.
E164
Original Sets the party number type of the original diverting number properties as per
Diverting “Last / Original Diverting Party Number Type” on page 343.
Party
Number Type
Original Sets the public type of number of the original diverting number properties as per
Diverting “Last / Original Diverting Public Type Of Number” on page 343.
Public Type
Of Number
Original Sets the private type of number of the original diverting number properties as per
Diverting “Last / Original Diverting Private Type Of Number” on page 343.
Private Type
Of Number
Original Sets the Presentation of the original diverting number properties as per “Last /
Diverting Original Diverting Number Presentation” on page 344.
Number
Presentation
Called Sets the called bearer channel properties as per “Called / Calling SIP
Bearer Username” on page 342.
Channel
Calling Sets the calling bearer channel properties as per “Called / Calling SIP
Bearer Username” on page 342.
Channel
Debug Reserved for debug configuration.
Examples
The following are some examples of mappings:
Signalling Properties
Standards Supported • RFC 3323: A Privacy Mechanism for the Session Initiation
Protocol (SIP) (only supports 'none' as Privacy level)
• RFC 3325: Private Extensions to the Session Initiation
Protocol (SIP) for Asserted Identity within Trusted Networks
(supports 'id' as Privacy level. Accept/send P-Asserted-
Identity and P-Preferred-Identity.)
Call signalling specifies how to set up a call to the destination Aastra unit or 3rd party equipment. Call signalling
properties are assigned to a route and used to modify the behaviour of the call at the SIP protocol level.
Signaling Properties are applied after mappings rules.
Like the routing table, the signalling properties table finds the first matching entry. It then executes it by
modifying the behaviour of the call.
Note: You can revert back to the configuration displayed in the Call Router > Status web page at any time
by clicking the Rollback button at the bottom of the page. All modified settings in the Call Router > Route
Config page will be lost.
• If you want to add a signalling property entry at the end of existing rows, click the
button at the bottom right of the Signaling Properties section.
• If you want to edit an existing entry, locate the proper row in the table and click the
button.
This brings you to the Configure Signaling Properties panel.
4
5
6
7
8
9
10
11
12
Parameter Description
Enable The unit can send a SDP in the provisional response 180. Thus when the ISDN
peer sends an alerting with indication to open the voice (or if the voice is already
opened), the unit sends a 180 with SDP. This is the default value.
Disable A SIP 183 with SDP is sent instead of a 180 with SDP. This does not affect the 180
without SDP. This is useful if your proxy has issues receiving 180 with SDP
messages.
The SIP 183 with SDP replacing the SIP 180 with SDP is not sent if a 183 with
SDP has already been sent.
9. Define whether or not to enable the 183 without SDP allowed feature in the Allow 183 No SDP drop-
down menu.
Table 274: 183 without SDP Parameters
Parameter Description
Enable When enabled, the unit sends a 183 without SDP upon receiving an ISDN
progress indicator without any indication to open a voice stream. This is the default
value.
Disable When disabled, nothing is sent instead of a 183 without SDP. This does not affect
the 183 with SDP. This is useful if your proxy has issues receiving 183 without
SDP messages.
10. Set the privacy level of the call in the Privacy drop-down menu.
Table 275: Privacy Levels
Level Description Effects on incoming SIP call Effects on outgoing SIP call
Level Description Effects on incoming SIP call Effects on outgoing SIP call
11. Enter the name of one or more SIP headers translation to apply to the call in the SIP Headers
Translations field.
You must define SIP headers translations as defined in “SIP Headers Translations” on page 372.
You can use the Suggestion column’s drop-down menu to select between existing translations, if
any.
You can enter more than one translation. In that case, the translations are separated with “,” and
are executed in sequential order.
12. Enter the name of one or more call properties translation to apply to the call in the Call Properties
Translations field.
You must set call properties translations as defined in “Call Properties Translations” on page 376.
You can use the Suggestion column’s drop-down menu to select between existing translations, if
any.
You can enter more than one translation. In that case, the translations are separated with “,” and
are executed in sequential order.
13. Click the Submit button.
This brings you back to the main Call Router > Route Config web page.
You can see a yellow Yes in the Config Modified section at the top of the window. It warns you that
the configuration has been modified but not applied (i.e., the Call Router > Status differs from the
Call Router > Route Config). The Route Config sub-menu is a working area where you build up a
Call Router configuration. While you work in this area, the configured parameters are saved but not
applied (i.e., they are not used to process incoming calls). The yellow Yes flag warns you that the
configuration has been modified but is not applied.
14. Click the Apply button to enable the signalling property entry.
The current properties applied are displayed in the Call Router > Status web page. You can also
see that the yellow Config Modified Yes flag is cleared.
Examples
The following are some examples of signalling properties:
A SIP Headers Translation overrides the default value of SIP headers in an outgoing SIP message. It modifies
the SIP headers before the call is sent to its destination.
Like the routing table, the SIP headers translation table finds the first matching entry. It then executes it by
modifying the behaviour of the call.
Note: You can revert back to the configuration displayed in the Call Router > Status web page at any time
by clicking the Rollback button at the bottom of the page. All modified settings in the Call Router > Route
Config page will be lost.
• If you want to add a SIP headers translation at the end of existing rows, click the
button at the bottom right of the SIP Headers Translations section.
• If you want to edit an existing entry, locate the proper row in the table and click the
button.
This brings you to the Configure SIP Headers Translation panel.
4
5
6
7
4. Enter the name of the SIP headers translation in the Name field.
5. Set which SIP header is modified by this translation in the SIP Header drop-down menu.
Table 276: SIP Headers
From Header (Host Part) Host part of the From header's URI.
From Header (User Part) User part of the From header's URI.
Identity Header (Host Part) Host part of the Identity header's URI.
Identity Header (User Part) User part of the Identity header's URI.
Identity Header (Phone Number) Phone number in the Identity header's tel URL.
Request Line (Host Part) Host part of the Request line's URI.
Request Line (User Part) User part of the Request line's URI.
To Header (Host Part) Host part of the To header's URI.
To Header (User Part) User part of the To header's URI.
6. Set what information is used to build the selected SIP header in the Built From drop-down menu.
Table 277: Built From Information
7. If you have selected Fix Value in the Built From drop-down menu, enter a fix value to be inserted
in the SIP header in the Fix Value field.
For instance, you could hide the caller’s name in a SIP message by using the From Header (User
Part) SIP header and entering “anonymous” in the Fix Value field.
8. Click the Submit button.
This brings you back to the main Call Router > Route Config web page.
You can see a yellow Yes in the Config Modified section at the top of the window. It warns you that
the configuration has been modified but not applied (i.e., the Call Router > Status differs from the
Call Router > Route Config). The Route Config sub-menu is a working area where you build up a
Call Router configuration. While you work in this area, the configured parameters are saved but not
applied (i.e., they are not used to process incoming calls). The yellow Yes flag warns you that the
configuration has been modified but is not applied.
9. Click the Apply button to enable the SIP headers translation entry.
The current properties applied are displayed in the Call Router > Status web page. You can also
see that the yellow Config Modified Yes flag is cleared.
Example
A Call Properties Translation overrides the default value of call properties in an incoming SIP message. It
modifies the call properties before the call is sent to its destination.
Like the routing table, the call properties translation table finds the first matching entry. It then executes it by
modifying the behaviour of the call.
Note: You can revert back to the configuration displayed in the Call Router > Status web page at any time
by clicking the Rollback button at the bottom of the page. All modified settings in the Call Router > Route
Config page will be lost.
• If you want to add a call properties translation at the end of existing rows, click the
button at the bottom right of the Call Properties Translations section.
• If you want to edit an existing entry, locate the proper row in the table and click the
button.
This brings you to the Configure Call Properties Translation panel.
4
5
6
7
4. Enter the name of the call properties translation in the Name field.
5. Set which call property is modified by this translation in the Call Property drop-down menu.
Table 278: Call Properties
6. Set what information is used to build the selected call property in the Built From drop-down menu.
Table 279: Built From Information
7. If you have selected Fix Value in the Built From drop-down menu, enter a fix value to be inserted
in the call property in the Fix Value field.
For instance, you could hide the callee’s name in a SIP message by using the From Header (User
Part) SIP header and entering “anonymous” in the Fix Value field.
8. Click the Submit button.
This brings you back to the main Call Router > Route Config web page.
You can see a yellow Yes in the Config Modified section at the top of the window. It warns you that
the configuration has been modified but not applied (i.e., the Call Router > Status differs from the
Call Router > Route Config). The Route Config sub-menu is a working area where you build up a
Call Router configuration. While you work in this area, the configured parameters are saved but not
applied (i.e., they are not used to process incoming calls). The yellow Yes flag warns you that the
configuration has been modified but is not applied.
9. Click the Apply button to enable the call properties translation entry.
The current properties applied are displayed in the Call Router > Status web page. You can also
see that the yellow Config Modified Yes flag is cleared.
Example
The following is an example of call properties translations:
Hunt Service
Routes and mappings only manipulate address properties of a call. The hunt service hunts an incoming call
to multiple interfaces. It accepts a call routed to it by a route or directly from an interface and creates another
call that is offered to one of the configured destination interfaces. If this destination cannot be reached, the
hunt tries another destination until one of the configured destinations accepts the call. When an interface
accepts a call, the interface hunting is complete and the hunt service merges the original call with the new call
to the interface that accepted the call.
The hunt sequence is very important. The call router follows the hunt rows as they are entered in the web
interface. If you want the call router to try to match one row before another one, you must put that row first.
Note: You can revert back to the configuration displayed in the Call Router > Status web page at any time
by clicking the Rollback button at the bottom of the page. All modified settings in the Call Router > Route
Config page will be lost.
Creating/Editing a Hunt
The web interface allows you to create a hunt or modify the parameters of an existing one.
• If you want to add a hunt entry at the end of existing rows, click the button at the
bottom right of the Hunt section.
• If you want to edit an existing entry, locate the proper row in the table and click the
button.
This brings you to the Configure Hunt panel.
6
7
8
After this timeout has elapsed, the next destination is tried when the current destination does not
answer. This feature is useful to ensure a minimal time of response and fallback to other
destinations. Some interfaces (e.g. SIP, which has a default timeout of 32 seconds) may wait an
arbitrary long time until an answer is returned.
Note: This parameter is not applicable if the selection algorithm Simultaneous is used (see Step 6).
Setting the field to 0 disables the timeout, which means that the call router waits indefinitely for the
interface to respond. This does not affect the internal interface timeouts (the ISDN timeout as
defined in ITU norms or the SIP transmission timeout) that will eventually stop the call and the call
router will try another destination.
Example:
You want a call from ISDN to SIP to fallback to another ISDN interface when the SIP destination
cannot be contacted within 5 seconds.
You thus create a hunt with the following destinations in order:
sip-[gateway name], isdn-[fallback interface]
and set the timeout to 5. The Selection Algorithm drop-down menu must be set to Sequential to
always try the SIP destination first.
The Aastra unit has the following behaviour if the SIP transmission timeout has the default value
(32 seconds):
a. A new call comes from an ISDN interface and the call router sets the destination of the call to
the isdn-to-sip hunt.
b. The call router starts the hunt timeout (5 s) and tries the first destination sip-default.
c. The SIP interface performs a DNS query to resolve the server name. The DNS result returns
server A and server B.
d. The SIP interface sends an INVITE to the server A.
e. The hunt timeout elapses, so the call router cancels the call to the SIP interface and tries the
second destination isdn-Slot3/Bri2. The hunt timeout is restarted.
f. The SIP interface continues to send the INVITE retransmission until the SIP transmission
timeout elapses. RFC 3261 states that an INVITE request cannot be cancelled until the
destination sends a response. If the destination responds before the SIP transmission timeout
elapses, a CANCEL or BYE request is sent. The SIP interface will not try to use the server B
location.
The Aastra unit has the following behaviour if the SIP transmission timeout is set to 3 seconds:
a. A new call comes from an ISDN interface and the call router sets the destination of the call to
the isdn-to-sip hunt.
b. The call router starts the hunt timeout (5 s) and tries the first destination sip-default.
c. The SIP interface performs a DNS query to resolve the server name. The DNS result returns
server A and server B.
d. The SIP interface sends an INVITE to the server A.
e. A SIP transmission timeout occurs after 4 seconds and the SIP interface sends an INVITE to
the server B.
f. The hunt timeout elapses, so the call router cancels the call to the SIP interface and tries the
second destination isdn-Slot3/Bri2. The hunt timeout is restarted.
g. The SIP interface continues to send the INVITE retransmission until the SIP transmission
timeout elapses. RFC 3261 states that an INVITE request cannot be cancelled until the
destination sends a response. If the destination responds before the SIP transmission timeout
elapses, a CANCEL or BYE request is sent.
Note: The maximal response time of a SIP interface is the transmission timeout total of all SIP destination
locations + the DNS query time.
The SIP transmission timeout can be set in the Transmission Timeout field of the SIP Interop
section, SIP > Interop page (“SIP Interop” on page 312).
8. Select call rejection causes to continue the hunt in the Causes field.
When an interface has a problem placing a call to the final destination, it drops the call by specifying
a drop cause based on Q.850 ISUP drop causes. Separate the causes with commas.
See “Call Rejection (Drop) Causes” on page 382 for a list of drop causes.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
Note: This parameter is not applicable if the selection algorithm Simultaneous is used (see Step 6).
Examples
The following are some examples of hunts:
Note: You can use any custom code between 1 and 127.
Normal Event
The following table lists all normal events drop causes. These causes are used to drop the original call.
Table 280: Normal Event Drop Causes
# Cause Description
1 Unassigned The calling user requested a destination that cannot be reached because
(unallocated) number the number is unassigned.
2 No route to specified The destination is asked to route the call through an unrecognized network.
transit network This may mean that:
• The wrong transit network code was dialed.
• The transit network does not serve this equipment.
• The transit network does not exist.
3 No route to destination The called party cannot be reached because the network through which the
call has been routed does not serve the destination address.
6 Channel unacceptable The sending entity cannot accept the channel most recently identified for
use in this call.
7 Call awarded and The user has been awarded the incoming call, which is being connected to a
being delivered in an channel already established to that user for similar calls.
established channel
16 Normal call clearing The call is being cleared because one of the users involved with the call has
requested that the call be cleared (usually, a call participant hung up).
17 User busy The called party is unable to accept another call because all channels are in
use. It is noted that the user equipment is compatible with the call.
18 No user responding The called party does not respond to a call establishment message with
either an alerting or connect indication within the time allotted. The number
that is being dialed has an active D-channel, but the far end chooses not to
answer.
19 User alerting, no The called party has been alerted but does not respond with a connect
answer indication within the time allotted.
21 Call rejected The remote equipment can accept the call but rejects it for an unknown
reason, although it could have accepted it because the equipment sending
this cause is neither busy nor incompatible.
22 Number changed The called number indicated by the calling party is no longer assigned.
26 Non-selected user The user has not been awarded the incoming call.
clearing
27 Destination out of The destination indicated by the user cannot be reached because the
order destination's interface is not functioning correctly. This can be a temporary
condition, but it could last for an extended period.
28 Invalid number format The called party cannot be reached because the called party number is not
(incomplete number) in a valid format or is not complete.
29 Facility rejected The network cannot provide the facility requested by the user.
30 Response to STATUS The STATUS message is generated in direct response to receiving a
ENQUIRY STATUS ENQUIRY message.
31 Normal, unspecified Reports a normal event only when no other cause in the normal class
applies.
Resource Unavailable
The following table lists all resource unavailable drop causes. These causes are used to hunt the next
destination.
Table 281: Resource Unavailable Drop Causes
# Cause Description
# Cause Description
57 Bearer capability not The user has requested a bearer capability that is implemented on the
authorized equipment but the user is not authorized to use it.
58 Bearer capability not The user has requested a bearer capability that is implemented by the
presently available equipment and is currently unavailable.
63 Service or option not The network or remote equipment cannot provide the requested service
available, unspecified option for an unspecified reason.
# Cause Description
65 Bearer capability not The remote equipment does not support the requested bearer capability.
implemented
66 Channel type not The remote equipment does not support the requested channel type.
implemented
69 Requested facility not The remote equipment does not support the requested supplementary
implemented service.
# Cause Description
70 Only restricted digital The calling party has requested an unrestricted bearer service but the
information bearer remote equipment only supports the restricted version of the requested
capability is available bearer capacity.
79 Service or option not The network or remote equipment cannot provide the requested service
implemented, option for an unspecified reason. This can be a subscription problem.
unspecified
Invalid Message
The following table lists all invalid message drop causes. These causes are used to drop the original call.
Table 284: Invalid Message Drop Causes
# Cause Description
81 Invalid call reference The remote equipment has received a message with a call reference that is
value not currently in use on the user-network interface.
82 Identified channel Indicates a call attempt on a channel that is not configured.
does not exist
83 A suspended call Attempted to resume a call with a call identity that differs from the one in use
exists, but this call for any presently suspended calls.
identity does not
84 Call identity in use The network has received a call suspended request containing a call identity
that is already in use for a suspended call.
85 No call suspended The network has received a call resume request containing a call identity
information element that does not indicate any suspended call.
86 Call having the The network has received a call identity information element indicating a
requested call identity suspended call that has in the meantime been cleared while suspended.
has been cleared
88 Incompatible The remote equipment has received a request to establish a call with
destination compatibility attributes that cannot be accommodated.
91 Invalid transit network Received a transit network identification of an incorrect format was received.
selection
95 Invalid message, Received an invalid message event.
unspecified
Protocol Error
The following table lists all protocol error drop causes. These causes are used to drop the original call.
Table 285: Protocol Error Drop Causes
# Cause Description
96 Mandatory information The remote equipment has received a message that is missing an
element is missing information element (IE). This IE must be present in the message before the
message can be processed.
97 Message type non- The remote equipment has received a message with a missing information
existent or not element that must be present in the message before the message can be
implemented processed.
# Cause Description
98 Message not The remote equipment has received a message that is not allowed while in
compatible with call the current call state.
state or message type
non-existent or not
implemented
99 Information element The remote equipment has received a message that includes information
non-existent or not elements or parameters that are not recognized.
implemented
100 Invalid information The remote equipment has received a message that includes invalid
element contents information in the information element or call property.
101 Message not Received an unexpected message that is incompatible with the call state.
compatible with call
state
102 Recovery on time A procedure has been initiated by the expiration of a timer in association
expiry with error handling procedures.
111 Protocol error, An unspecified protocol error with no other standard cause occurred.
unspecified
Interworking
The following table lists all interworking drop causes. These causes are used to drop the original call.
Table 286: Interworking Drop Causes
# Cause Description
127 Interworking, An event occurs, but the network does not provide causes for the action it
unspecified takes. The precise problem is unknown.
Moving a Hunt
The hunt sequence is very important. The call router follows the hunt rows as they are entered in the web
interface. If you want the call router to try to match one row before another one, you must put that row first.
Deleting a Hunt
You can delete a hunt row from the table in the web interface.
SIP Redirects
The SIP Redirect allows SIP redirections to be configured. These SIP Redirect entries can be used as
destinations in route rules. This type of destination is valid only when the Source of the route rule is a SIP
interface.
When a route rule is configured with a SIP Redirect destination, incoming SIP Invites are replied with a 302
"Moved Temporarily" SIP response.
Note: You can revert back to the configuration displayed in the Call Router > Status web page at any time
by clicking the Rollback button at the bottom of the page. All modified settings in the Call Router > Route
Config page will be lost.
• If you want to add a SIP Redirect entry at the end of existing rows, click the button
at the bottom right of the SIP Redirects section.
• If you want to edit an existing entry, locate the proper row in the table and click the
button.
This brings you to the Configure SIP Redirect panel.
4
5
This brings you back to the main Call Router > Route Config web page.
You can see a yellow Yes in the Config Modified section at the top of the window. It warns you that
the configuration has been modified but not applied (i.e., the Call Router > Status differs from the
Call Router > Route Config). The Route Config sub-menu is a working area where you build up a
Call Router configuration. While you work in this area, the configured parameters are saved but not
applied (i.e., they are not used to process incoming calls). The yellow Yes flag warns you that the
configuration has been modified but is not applied.
7. In the main Call Routing Config web page, click the Apply button to enable the SIP Redirect.
The current SIP Redirects applied are displayed in the Call Router > Status web page. You can also
see that the yellow Config Modified Yes flag is cleared.
Examples
The following are some examples of SIP Redirects:
Configuration Examples
The following are examples of configuration you could do with the call router.
39 Auto-Routing Configuration
Auto-Routing
The auto-routing feature is an aid to call routing configuration. When this feature is enabled, routing rules are
automatically generated for all endpoints marked as "Auto-routable". For each auto-routable endpoint, two
rules are generated and added to the Call Router: one directing incoming calls from the associated auto-
routing SIP gateway to the endpoint, and one sending outgoing calls from the endpoint to the associated auto-
routing SIP gateway.
The auto-routing routes are not displayed in the Route Configuration page because you cannot edit them.
They are however listed in the Status page and are attributed a type:
User: the route has been manually entered by the user.
Auto: this is an auto-routing route.
Note: Auto-routing can only be used if the username of the endpoint is an E.164 string and the username
part of the request-URI of the received INVITE can be converted into an E.164. See “Manual Routing” on
page 394 for more details.
To activate auto-routing:
1. In the web interface, click the Call Router link, then the Auto-routing sub-link.
2
3
4
5
6
7
2. In the top section, set the Auto-routing drop-down menu with the proper behaviour.
If you select Enable, routes are automatically added to the Route Table in order to connect the
endpoints marked as eligible for auto-routing (see Step 3) and the designated SIP gateway (see
Step 4). These automatic routes are displayed in the Call Router > Status page, but do not show up
in the Call Router > Route Configuration page.
3. Select the type of criteria to use to create automatic rules from SIP to the telephony endpoints in the
Criteria Type drop-down menu.
Table 287: Criteria Types
Parameter Description
4. Set the Incoming Mappings field with the name of the properties manipulations associated with the
route from the SIP gateway to the endpoint.
You can specify more than one mapping by separating them with ','. They are executed in sequential
order. See “Mappings” on page 484 for more details.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
5. Set the Outgoing Mappings field with the name of the properties manipulations associated with the
route from the endpoint to the SIP gateway.
You can specify more than one mapping by separating them with ','. They are executed in sequential
order. See “Mappings” on page 484 for more details.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
6. Set the Incoming Signaling Properties field with the name of the signaling properties associated with
the route from the SIP gateway to the endpoint.
See “Signalling Properties” on page 494 for more details.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
7. Set the Outgoing Signaling Properties field with the name of the signaling properties associated with
the route from the endpoint to the SIP gateway.
See “Signalling Properties” on page 494 for more details.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
8. Click the Submit button to enable auto-routing.
The current routes applied are displayed in the Call Router > Status web page. They are added at
the end of the routes that are already present, if any. This ensures that the user-defined routes
always have precedence over the automatic routes when both types of routes apply to the same
endpoint.
Endpoints Auto-Routing
This section allows you to link an endpoint to several SIP gateways.
2
3
4
2. Select whether or not automatic routes are generated for the endpoint when auto-routing is enabled
in the Auto-routable drop-down menu.
Table 288: Auto-routable Parameters
Parameter Description
Enable Automatic routes allowing incoming and outgoing calls to and from
the endpoint are added to the Route Table when auto-routing is
enabled.
Disable Automatic route generation is turned off for this endpoint.
HardwareDependent Automatic routes are generated if the endpoint belongs to an FXS
interface.
3. Select the SIP gateways to use as the destination of outgoing calls and the source of incoming calls
when generating auto-routing rules in the Auto-routing Gateway drop-down menu.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
If you leave the field blank, it is the same as disabling the auto-routing feature.
More than one SIP gateway can be defined. The SIP gateways names are separated by comas.
Example:
gw1,gw2,gw3
When one SIP gateway is defined:
• A route is automatically created from the SIP gateway to the telephony interface.
• A route is automatically created from the telephony interface to the SIP gateway if the
Auto-routing Destination field is empty. Otherwise, the destination of the route uses the
destination defined in the Auto-routing Destination field.
When several SIP gateways are defined:
• Routes are automatically created from each defined SIP gateway to the telephony
interface.
• A route is automatically created from the telephony interface to the destination defined
in the Auto-routing Destination field. No route is created if the destination is left empty.
If available, two additional parameters are displayed:
• If an endpoint has a telephone number that is associated with it, it is displayed in the
corresponding E164 column. This is the User Name field as configured in the SIP >
Registration page as long as the name follows the E.164 syntax.
• If an endpoint has a friendly name that is associated with it, it is displayed in the
corresponding Name column. This is the Friendly Name field as configured in the SIP >
Registration page.
Pleas note that routes are created only if a user name is associated with the telephony endpoint in
the registration table. See “Endpoints Registration” on page 289 for more details.
4. Set the destination to use for the routes from the telephony interface in the Auto-routing Destination
field.
You can use the Suggestion column’s drop-down menu to select between suggested values, if any.
The destination can be:
• route-name: The route destination is set to the route name.
• hunt-name: The route destination is set to the hunt name.
• sip-name: The route destination is set to the SIP interface name.
• isdn-name: The route destination is set to the ISDN interface name.
• r2-name: The route destination is set to the R2 interface name.
• e&m-name: The route destination is set to the E&M interface name.
• fxs-name: The route destination is set to the FXS interface name.
• fxo-name: The route destination is set to the FXO interface name.
5. You can copy the configuration of the selected endpoint to one or more endpoints of the Aastra unit
in the Apply to the Following Endpoints section at the bottom of the page. You can select specific
endpoints by checking them, as well as use the Check All or Uncheck All buttons.
6. When you are finished, you have the choice to:
• Click the Submit button to enable auto-routing.
The current routes applied are displayed in the Call Router > Status web page. They are
added at the end of the routes that are already present, if any. This ensures that the
user-defined routes always have precedence over the automatic routes when both types
of routes apply to the same endpoint.
• Click the Submit & Create Hunt button to perform a submit action and go to the hunt
creation page. This option is available only if the destination is set to an unexisting
hunt.
• Click the Submit & Edit Hunt button to perform a submit action and go to the hunt
edition page. This option is available only if the destination is set to an existing hunt.
• Click the Submit & Create Route button to perform a submit action and go to the route
creation page. This option is available only if the destination is set to an unexisting
route.
• Click the Submit & Edit Route button to perform a submit action and go to the route
edition page. This option is available only if the destination is set to an existing route.
Manual Routing
Auto-routing can only be used if the username of the endpoint is an E.164 string and the username part of the
request-URI of the received INVITE can be converted into an E.164.
The conversion of a username into an E.164 follows these rules:
The prefix “+” is removed. Note that if the Map Plus To TON International drop-down menu is
set to Enable, the call property ‘type of number’ is set to ‘international’. See “Misc Interop” on
page 319 for more details.
The visual separator “-” is removed.
The username parameter is removed. The username parameter is a suffix beginning with “;”.
All remaining characters need to be “0123456789*#abcdABCD”.
Examples of conversion:
5551234 --> 5551234
#20 --> #20
555-1234 --> 5551234
+1-819-555-1234 --> 18195551234
5551234;parameter --> 5551234
5551234_parameter --> cannot convert
To use a username not compatible with E.164, you must disable the auto-routing and use manual routes.
Figure 187 gives an example of manual routes for an endpoint using “5550001_paramter” as user.
40 Configuration Script
This chapter describes the configuration script download feature, which allows updating the Aastra unit
configuration by transferring a configuration script from a remote server or from the local file system. The
Aastra unit is the session initiator, which allows NAT traversal. You can also configure the Aastra unit to
automatically update its configuration.
You can also generate a configuration script from the running configuration of the Aastra unit.
Configuration scripts are files containing textual commands that are sent over the network to a Aastra unit.
Upon receiving the file, the unit executes each command line in sequence. Script commands can assign
values to configuration variables, or execute configuration commands. See “Creating a Configuration Script”
on page 414 for more details on how to create a configuration script.
Scripts are written by the system administrator and can be used to accomplish various tasks, such as
automating recurrent configuration tasks or batch-applying configuration settings to multiple devices. Scripts
can be executed once or periodically at a specified interval. They can also be scheduled to execute when the
Aastra unit restarts.
This chapter describes the following:
Configuration script server setup.
Configuration script server parameters.
Configuration download procedure.
Generating a configuration script from the running configuration.
Automatic configuration update parameters.
How to create a configuration script from scratch.
To download a configuration script, you may need to setup the following applications on your computer:
TFTP server with proper root path
SNTP server properly configured
HTTP server with proper root path
HTTPS server with proper root path
Note: The Aastra unit hardware does not include a real time clock. The unit uses the SNTP client to get and
set its clock. As certain services need correct time to work properly (such as HTTPS), you should configure
your SNTP client with an available SNTP server in order to update and synchronise the local clock at boot
time.
When you perform a configuration script download that requires authentication or privacy by using the HTTP
over the Transport Layer Security (TLS) protocol (HTTPS), you must install a HTTPS server running on the
PC designated as the server host. It is assumed that you know how to set the root path and SSL/TLS security
configuration. If not, refer to your HTTPS server’s documentation.
Caution: You must have a time server SNTP that is accessible and properly configured, or the automatic
configuration update feature may not work properly. It is assumed that you know how to configure your
SNTP server. If not, refer to your SNTP server’s documentation. You can also refer to “SNTP Configuration”
on page 93 for more details on how to configure the Aastra unit for a SNTP server.
When two peers establish a HTTPS connection, they negotiate and decide on a cipher suite to use for data
encryption. The client suggests a list of cipher suites and the server selects one that it supports. Some cipher
suites are more secured than others. The Aastra unit acts as a client.
The Aastra unit suggests a wide range of cypher suites, which includes cipher suites that are not very secure.
The final choice rests with the server and it is thus possible that the transfer uses a SSL/TLS link that is not
very secure.
Aastra recommends to use cipher suites based on the RSA key exchange mechanism, because the Diffie-
Hellman key exchange mechanism introduces a noticeable delay in the HTTPS session establishment.
Furthermore, Aastra recommends using cipher suites based on the following SSL/TLS algorithms:
Table 289: Suggested Secure Parameters
The following six recommended cipher suites are based on the algorithms of Table 289:
Table 290: Recommended Cipher Suites
ID Name
0x0035 TLS_RSA_WITH_AES_256_CBC_SHA
0x0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0x000a TLS_RSA_WITH_3DES_EDE_CBC_SHA
0x0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0x002f TLS_RSA_WITH_AES_128_CBC_SHA
0x0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Certificates
The Aastra unit contains embedded security certificates formatted as per ITU x.509 and RFC 3280. The
certificates are factory-installed. You can also add new certificates as described in “Chapter 46 - Certificates
Management” on page 557.
When contacting a HTTPS server, the Aastra unit establishes a TLS connection by (among others):
negotiating cipher suites
checking the server certificates validity (dates)
The Aastra unit then checks the server’s identity by validating the host name used to contact it against the
information found in the server’s certificate, as described in RFC 2818, section 3.1.
If any of the above does not succeed, the Aastra unit refuses the secure connection. To help detect such
errors, you can increase the syslog messages level.
You can generate a configuration script from the running configuration of the Aastra unit and export it.
You can export the configuration in two ways:
To a URL you specify with one of the supported transfer protocols.
By directly downloading the exported script via your web browser. This option uses the
protection provided by your web browser (it is protected if you log on to the unit via HTTPS).
2
3
4
5
2. Select the content to export in the generated configuration script in the Content drop-down menu.
Table 291: Exported Configuration Script Content
Parameter Description
3. Set the Service Name field with the name of the service from which to export configuration.
You can use the Suggestion drop-down menu to select one of the available services. You can use
the special value All to export the configuration of all services.
4. Set the Send To URL field with the URL where to send the exported configuration script.
The URL should follow this format:
protocol://[user[:password]@]hostname[:port]/[path/]filename
The brackets [ ] denote an optional parameter.
The filename may contain a %mac% macro that is substituted by the MAC address of the unit at the
moment of sending the configuration script. For instance, the “%mac%.cfg” value for a Aastra unit
with MAC address “0090f12345ab” will be “0090f12345ab.xml”.
The filename may contain macros that are substituted at the moment of sending the configuration
script. The supported macros are:
Caution: The Privacy Key field is not accessible if you have the User or Observer access right. See “Users”
on page 591 for more details.
The key is encoded in hexadecimal notation. You can thus use characters in the range 0-9, A-F,
and a-f. All other characters are not supported.
The maximum key length is 64 characters, which gives a binary key of 32 bytes (256 bits). It is the
maximum key size supported by the MxCryptFile application.
For instance, a 32-bit key could look like the following: A36CB299.
If the field is empty, the configuration script is not encrypted.
To decrypt the exported configuration script, you must use the MxCryptFile application. MxCryptFile
is a command line tool that encrypts or decrypts files to be exchanged with the Aastra unit. Contact
your sales representative for more details.
6. Initiate the configuration scripts exportation by clicking the Submit & Export Now button at the
bottom of the page.
The Aastra unit immediately generates and transfers a configuration script based on the export
settings set in the previous steps.
Parameter Description
3
1
2. If required, set the Privacy Key field with the key used to encrypt the configuration script to export.
Caution: The Privacy Key field is not accessible if you have the User or Observer access right. See “Users”
on page 591 for more details.
The key is encoded in hexadecimal notation. You can thus use characters in the range 0-9, A-F,
and a-f. All other characters are not supported.
The maximum key length is 64 characters, which gives a binary key of 32 bytes (256 bits). It is the
maximum key size supported by the MxCryptFile application.
For instance, a 32-bit key could look like the following: A36CB299.
If the field is empty, the configuration script is not encrypted.
To decrypt the exported configuration script, you must use the MxCryptFile application. MxCryptFile
is a command line tool that encrypts or decrypts files to be exchanged with the Aastra unit. Contact
your sales representative for more details.
3. Click the Export & Download button.
1
2
3
4
5
6
7
8
2. Set the name of the specific configuration script to download in the Specific File Name field.
This script should be used to update the configuration of a single unit. The script name is case
sensitive hence it must be entered properly.
If you select File in the Transfer Protocol drop-down menu (Step 4), this means that you can select
a script located in the unit’s persistent file system. You can use the Suggestion drop-down menu to
select one of the available scripts in the file system.
To see the content of the unit’s file system persistent memory, go to the File Manager (“Chapter 50
- File Manager” on page 597). All installed configuration scripts/images are listed.
This field may contain a macro that is substituted by the actual value when downloading the
configuration script. The Aastra unit supports the %mac% macro, which will be substituted by the
MAC address of the unit. For instance, the “%mac%.xml” value for a Aastra unit with MAC address
“0090f12345ab” will be “0090f12345ab.xml”.
This field may contain some macros that are substituted by the actual value when downloading the
configuration script. The supported macros are:
• %mac% - the MAC address of the unit
• %version% - the MFP version of the unit
• %product% - the Product name of the unit.
• %productseries% - the Product series name of the unit.
For instance, the “%mac%.xml” value for a Aastra unit with MAC address “0090f12345ab” will be
“0090f12345ab.xml”.
If the variable is empty (after macro substitution), the Aastra unit does not download the specific
configuration script.
3. Set the path of the directory where the configuration scripts are located in the Location field.
The path is case sensitive hence it must be entered properly. It is relative to the root of the
configuration scripts server. Use the “/” character when defining the path to indicate sub-directories.
This field may contain some macros that are substituted by the actual value when downloading the
configuration script. The supported macros are:
• %mac% - the MAC address of the unit
• %version% - the MFP version of the unit
• %product% - the Product name of the unit.
• %productseries% - the Product series name of the unit.
For instance, the “%mac%.xml” value for a Aastra unit with MAC address “0090f12345ab” will be
“0090f12345ab.xml”.
The path differs depending on the transfer protocol selected (see Step 5).
Let’s consider the following example for all protocols except File:
• The directory that contains the configuration script is called: Config_Script.
c:/root/download Config_Script
c:/ root/download/Config_Script
c:/root download/Config_Script
4. Set the transfer protocol to transfer the configuration scripts in the Transfer Protocol field.
You can select from five different transfer protocols:
• HTTP: HyperText Transfer Protocol.
• HTTPS: HyperText Transfer Protocol over Transport Layer Security.
• TFTP: Trivial File Transfer Protocol.
• FTP: File Transfer Protocol. Note that the Aastra unit FTP client does not support the
EPSV command.
Note: The configuration script download via TFTP can only traverse NATs of types “Full Cone” or
“Restricted Cone”. If the NAT you are using is of type “Port Restricted Cone” or “Symmetric”, the script
transfer will not work.
• File: Complete path to a configuration image in a storage device. You can view and
manage all files created with the File transfer protocol by using the File Manager. See
“File Manager” on page 597 for more details.
HTTP and HTTPS support basic or digest authentication mode as described in RFC 2617. HTTPS
requires a valid certificate.
If you have selected HTTP or HTTPS, please note that your server may activate some caching
mechanism for the script download. This mechanism caches the initial script download for later
processing, thus preventing changes or update of the original script. This can cause strange
problems if you want to edit a configuration script to modify values and upload it immediately. The
result will still return the original script and not the new one.
5. If your server requires authentication when downloading the configuration script, set the following:
• The user name in the User Name field.
• The password in the Password field.
Caution: The User Name and Password fields are not accessible if you have the User or Observer access
right. See “Users” on page 591 for more details.
6. Set the static configuration scripts server IP address or domain name and port number in the Host
Name field.
This is the current address of the PC that hosts the configuration scripts.
Use the special port value zero to indicate the protocol default. For instance, the TFTP default port
is 69, the HTTP default port is 80, and the HTTPS default port is 443.
The default value is 0.0.0.0:0.
7. Set the key used to decrypt configuration scripts when they are encrypted in the Privacy key field.
Caution: The Privacy Key field is not accessible if you have the User or Observer access right. See “Users”
on page 591 for more details.
You can secure the exchange of configuration scripts between the server and the Aastra unit. A
privacy key allows the unit to decrypt a previously encrypted configuration script.
To encrypt a configuration script, you must use the MxCryptFile application. MxCryptFile is a
command line tool that encrypts files before sending them to the Aastra unit. Contact your sales
representative for more details.
The key is encoded in hexadecimal notation. You can thus use characters in the range 0-9, A-F,
and a-f. All other characters are not supported.
Each character encodes 4 bits and the maximum key length is 112 characters, which gives a binary
key of 56 bytes. It is the maximum supported by the MxCryptFile application.
For instance, a 32-bit key could look like the following: A36CB299.
This key must match the key used for the encryption of the relevant configuration script.
If the field is empty, the configuration script is not decrypted by the unit and the configuration update
fails.
Encryption is auto-detected.
8. Define whether or not to allow the execution of a script even if it is identical to the last executed script
in the Allow Repeated Execution drop-down menu.
Table 295: Allow Repeated Execution Parameters
Parameter Description
The script retry mechanism is not enabled for the DHCP triggered scripts (see “DHCPv4 Auto-
Provisioning” on page 412 for more details).
9. Do one of the following:
3
1
2. If required, set the key used to decrypt configuration scripts when they are encrypted in the Privacy
key field.
You can secure the exchange of configuration scripts between the server and the Aastra unit. A
privacy key allows the unit to decrypt a previously encrypted configuration script.
To encrypt a configuration script, you must use the MxCryptFile application. MxCryptFile is a
command line tool that encrypts files before sending them to the Aastra unit. Contact your sales
representative for more details.
The key is encoded in hexadecimal notation. You can thus use characters in the range 0-9, A-F,
and a-f. All other characters are not supported.
Each character encodes 4 bits and the maximum key length is 112 characters, which gives a binary
key of 56 bytes. It is the maximum supported by the MxCryptFile application.
For instance, a 32-bit key could look like the following: A36CB299.
This key must match the key used for the encryption of the relevant configuration script.
If the field is empty, the configuration script is not decrypted by the unit and the configuration update
fails.
Encryption is auto-detected.
3. Click the Upload & Execute button.
The following steps explain how to download configuration scripts from the web interface.
Note: The configuration download via TFTP can only traverse NATs of types “Full Cone” or “Restricted
Cone”. If the NAT you are using is of type “Port Restricted Cone” or “Symmetric”, the file transfer will not
work.
This section describes how to configure the Aastra unit to automatically update its configuration. This update
can be done:
Every time the Aastra unit restarts.
At a specific time interval you can define.
NAT Variations
NAT treatment of UDP varies among implementations. The four treatments are:
• Full Cone: All requests from the same internal IP address and port are mapped to the same
external IP address and port. Furthermore, any external host can send a packet to the internal
host by sending a packet to the mapped external address.
• Restricted Cone: All requests from the same internal IP address and port are mapped to the
same external IP address and port. Unlike a full cone NAT, an external host (with IP address
X) can send a packet to the internal host only if the internal host had previously sent a packet
to IP address X.
• Port Restricted Cone: Similar to a restricted cone NAT, but the restriction includes port
numbers. Specifically, an external host can send a packet, with source IP address X and
source port P, to the internal host only if the internal host had previously sent a packet to IP
address X and port P.
• Symmetric: All requests from the same internal IP address and port, to a specific destination
IP address and port, are mapped to the same external IP address and port. If the same host
sends a packet with the same source address and port, but to a different destination, a
different mapping is used. Furthermore, only the external host that receives a packet can send
a UDP packet back to the internal host.
For more details on NAT treatments, refer to RFC 3489.
To set the automatic update every time the Aastra unit restarts:
1. Set the configuration scripts parameters as defined in “Executing Configuration Scripts Settings” on
page 405.
2. Place the configuration scripts to download on the computer hosting the configuration scripts server.
These scripts must be in a directory under the root path.
3. In the Automatic Script Execution section of the Configuration Scripts page, select Enable in the
Execute on Startup drop-down menu.
The automatic configuration update will be performed each time the Aastra unit restarts.
The unit configuration is only updated if at least one parameter value defined in the downloaded
configuration scripts is different from the actual unit configuration.
4. Click Submit if you do not need to set other parameters.
3
4
5
6
4. Select the time base for configuration updates in the Time Unit drop-down menu.
Table 296: Time Unit Parameters
Parameter Description
You can specify the x value in the Period field (see Step 5).
5. Set the waiting period between each configuration update in the Period field.
Available values are from 1 to 60. The time unit for the period is specified in the Time Unit field (see
Step 4).
6. If you have selected Days in Step 4, set the time of the day when to initiate a configuration update
in the Time of Day field.
The time of the day is based on the Static Time Zone field of the Network - Host page (see “Time
Configuration” on page 94 for more details).
You must have a time server SNTP that is accessible and properly configured or the automatic
configuration update feature may not work properly. It is assumed that you know how to configure
your SNTP server. If not, refer to your SNTP server’s documentation.
Note: The Aastra unit hardware does not include a real time clock. The unit uses the SNTP client to get and
set its clock. As certain services need correct time to work properly (such as HTTPS), you should configure
your SNTP client with an available SNTP server in order to update and synchronise the local clock at boot
time.
The configuration scripts are downloaded at the first occurrence of this value and thereafter at the
period defined by the Period field. Let’s say for instance the automatic unit configuration update is
set with the time of day at 14h00 and the update period at every 2 days.
• If the automatic update is enabled before 14h00, the first update will take place the
same day at 14h00, the second update two days later at the same hour, and so on.
• If the automatic update is enabled after 14h00, the first update will take place the day
after at 14h00, the second download two days later at the same hour, and so on.
Available values are -1, and from 0 to 23.
When setting the variable to -1, the time of the day at which the Aastra unit first downloads the
configuration scripts is randomly selected.
7. Click Submit if you do not need to set other parameters.
DHCPv4 Auto-Provisioning
Note: This feature does not support IPv6. See “IPv4 vs. IPv6 Availability” on page 85 for more details.
You can configure the Aastra unit to automatically download new configuration scripts upon receiving options
66 (tftp-server) or 67 (bootfile) in a DHCPv4 answer. A DHCP answer includes both Bound and Renew.
The contents of the option 66 or 67 defines which script to download. The unit’s configuration is not used to
download the script. This allows the unit, for instance, to download a script from a server after a factory reset
and to reconfigure itself without a specific profile.
The syntax of options 66 and 67 is as follows:
[FileType] = [protocol]://[username] :[password]@[fqdn server]/[path]
For instance:
Script=https://admin :[email protected]/Mx3000config/%mac%.cfg
The Aastra unit supports only the Script file type for now.
The following is an example of a valid option 67 (Bootfile):
Option: (t=67, l=53) Bootfile name = "Script=http://192.168.50.1/digest/
%mac%__2.0.6.84.cfg"
Option: (67) Bootfile name
Length: 53
Value: 5363726970743D687474703A2F2F3139322E31136382E3530...
When enabled, the DHCPv4 options tftp-server (option 66) and bootfile (option 67) are used to
download a configuration script. If this configuration script is identical to the last executed script, it
will not be run again. The script retry mechanism is not enabled for the DHCPv4 triggered scripts
(see “Executing Configuration Scripts Settings” on page 405 for more details).
If the two options are received, both scripts are executed independently. The script defined by the
tftp-server (option 66) option is executed first.
If you are using HTTPS to transfer scripts, you must have a time server SNTP that is accessible and
properly configured. It is assumed that you know how to configure your SNTP server. If not, refer to
your SNTP server’s documentation.
Note: The Aastra unit hardware does not include a real time clock. The unit uses the SNTP client to get and
set its clock. As certain services need correct time to work properly (such as HTTPS), you should configure
your SNTP client with an available SNTP server in order to update and synchronise the local clock at boot
time.
When a DHCPv4 download script is configured in HTTPS, the script execution is deferred and a 30
seconds timer is started to let enough time for the NTP synchronization.
This timer is independent for each HTTPS script launched. If, for instance, a DHCPv4 answer has
both option 66 and 67 configured in HTTPS and if the Update on Restart feature is used, up to 1
min 30 seconds can pass before any other operation such as backup, restore, script execution can
be processed.
Once the NTP synchronization is established, the deferred scripts are started immediately one after
the other, ending the timer.
When synchronization is already established, there is no timer, even in HTTPS.
2. Click Submit if you do not need to set other parameters.
Number of Retries
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
When using the automatic configuration update (on restart or at a specific interval), the Aastra unit may
encounter a problem upon restarting the unit (such as a DHCP server problem) that prevents the update to
succeed. You can define a maximum number of attempts to retry a script transfer until it succeeds when it fails
upon an automatic transfer on restart or automatic periodic transfer. The retries are only attempted if the server
is unreachable. Unreachable port or file not found errors don't trigger the retry mechanism.The time interval
between each retry is 30 seconds.
Configuration scripts are text files that contain command lines interpreted by the Aastra unit. Most commands
contained in a script assign values to configuration variables. Script commands can also execute configuration
commands. This configuration script can then be downloaded into the Aastra unit as described in the current
chapter.
Writing configuration scripts requires a bit of knowledge about the Aastra unit’s configuration variables tree
structure. Each parameter that is accessed via the unit's web interface maps to a variable in the configuration
tree. For detailed information on these mappings, please refer to “Appendix D - Web Interface – SNMP
Variables Mapping” on page 641.
Configuration scripts use the Aastra proprietary scripting language, as described in “Appendix B - Scripting
Language” on page 627.
Refer to “Appendix B - Scripting Language” on page 627 for samples of configurations you can use in a
configuration script. The samples include the configuration required to perform a basic call between an ISDN
telephone and an analog telephone. These samples may also be used in the Aastra unit Command Line
Interface.
41 Configuration Backup/Restore
This chapter describes the configuration backup/restore feature, which allows you to backup (upload) all the
SNMP (MIB) and Web configuration of the Aastra unit into a configuration image file located on a remote
server or to the local file system.
This chapter describes the following:
Configuration backup download server setup.
Backup/restore configuration parameters.
To backup/restore a configuration image, you may need to setup the following applications on your computer:
TFTP server with proper root path
SNTP server properly configured
HTTP server with proper root path
HTTPS server with proper root path
Note: The Aastra unit hardware does not include a real time clock. The unit uses the SNTP client to get and
set its clock. As certain services need correct time to work properly (such as HTTPS), you should configure
your SNTP client with an available SNTP server in order to update and synchronise the local clock at boot
time.
When you perform a configuration backup/restore that requires authentication or privacy by using the HTTP
over the Transport Layer Security (TLS) protocol (HTTPS), you must install a HTTPS server running on the
PC designated as the server host. It is assumed that you know how to set the root path and SSL/TLS security
configuration. If not, refer to your HTTPS server’s documentation.
When two peers establish a HTTPS connection, they negotiate and decide on a cipher suite to use for data
encryption. The client suggests a list of cipher suites and the server selects one that it supports. Some cipher
suites are more secured than others. The Aastra unit acts as a client.
The Aastra unit suggests a wide range of cypher suites, which includes cipher suites that are not very secure.
The final choice rests with the server and it is thus possible that the transfer uses a SSL/TLS link that is not
very secure.
Aastra recommends to use cipher suites based on the RSA key exchange mechanism, because the Diffie-
Hellman key exchange mechanism introduces a noticeable delay in the HTTPS session establishment.
Furthermore, Aastra recommends using cipher suites based on the following SSL/TLS algorithms:
Table 297: Suggested Secure Parameters
The following six recommended cipher suites are based on the algorithms of Table 297:
Table 298: Recommended Cipher Suites
ID Name
0x0035 TLS_RSA_WITH_AES_256_CBC_SHA
0x0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0x000a TLS_RSA_WITH_3DES_EDE_CBC_SHA
0x0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0x002f TLS_RSA_WITH_AES_128_CBC_SHA
0x0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Certificates
The Aastra unit contains embedded security certificates formatted as per ITU x.509 and RFC 3280. The
certificates are factory-installed. You can also add new certificates as described in “Chapter 46 - Certificates
Management” on page 557.
When contacting a HTTPS server, the Aastra unit establishes a TLS connection by (among others):
negotiating cipher suites
checking the server certificates validity (dates)
The Aastra unit then checks the server’s identity by validating the host name used to contact it against the
information found in the server’s certificate, as described in RFC 2818, section 3.1.
If any of the above does not succeed, the Aastra unit refuses the secure connection. To help detect such
errors, you can increase the syslog messages level.
Backup/Restore Configuration
This section describes how to set the backup/restore configuration parameters and some related files (e.g.
certificates). You can restore this configuration in case the Aastra unit loses it for any reason or to clone a unit
with the configuration of another unit. The configuration backup images are in XML format and may be
encrypted or in clear text.
Note: The files under the File service are not included in the backup process. In the same way, the restore
process will not remove any file under the File service.
Please note that you can use a backup file from an older firmware version and use it in a unit with a more
recent firmware version. However, a backup file from a newer firmware version than the one actually in the
unit cannot be used for a restore operation on the unit. For instance, let’s say you perform the following
backups:
In firmware v1.1r4.1, you make the backup “Backup_X1”.
In firmware v1.1r4.2 you make the backup “Backup_X2”
Application v1.1r4.2 is more recent than v1.1r4.1. The following table describes the various scenarios
possible.
Table 299: Backup Matrix
Not
Scenario Supported
Supported
2
3
4
5
6
8
9
2. Set the name of the configuration image in which you want to backup or from which you want to
restore the Aastra unit configuration in the File Name field.
The file name is case sensitive hence it must be entered properly. Make sure to write the file
extension.
If you select File in the Transfer Protocol drop-down menu (Step 5), this means that you can select
an image located in the unit’s persistent file system. You can use the Suggestion drop-down menu
to select one of the available images in the file system.
To see the content of the unit’s file system persistent memory, go to the File Manager (“Chapter 50
- File Manager” on page 597). All installed configuration scripts/images are listed.
This field may contain a macro that is substituted by the actual value when backing up or restoring
the unit's configuration. The Aastra unit supports the %mac% macro, which will be substituted by
the MAC address of the unit. For instance, the “%mac%.bkp” value for a Aastra unit with MAC
address “0090F12345AB” will be “0090F12345AB.bkp”.
This field may contain macros that are substituted by the actual value when backing up or restoring
the unit's configuration. The supported macros are:
• %mac% - the MAC address of the unit.
• %version% - the MFP version of the unit.
• %product% - the Product name of the unit.
• %productseries% - the Product series name of the unit.
For instance, the “%mac%.bkp” value for a Aastra unit with MAC address “0090F12345AB” will be
“0090F12345AB.bkp”.
3. Select a transfer protocol to transfer a configuration image in the Transfer Protocol drop-down
menu.
You can select from five different transfer protocols:
• HTTP: HyperText Transfer Protocol.
• HTTPS: HyperText Transfer Protocol over Transport Layer Security.
• TFTP: Trivial File Transfer Protocol.
• FTP: File Transfer Protocol. Note that the Aastra unit FTP client does not support the
EPSV command.
• File: Complete path to a configuration image in the Aastra unit’s onboard storage
space. You can view and manage all files created with the File transfer protocol by
using the File Manager. See “File Manager” on page 597 for more details.
Note: The configuration image backup via TFTP can only traverse NATs of types “Full Cone” or “Restricted
Cone”. If the NAT you are using is of type “Port Restricted Cone” or “Symmetric”, the transfer will not work.
HTTP and HTTPS support basic or digest authentication mode as described in RFC 2617. HTTPS
requires a valid certificate.
The backup operation currently supports the following protocols:
• TFTP
• FTP
• File
The restore operation supports all the transfer protocols.
If you have selected HTTP or HTTPS, please note that your server may activate some caching
mechanism for the configuration image transfer. This mechanism caches the initial configuration
image transfer for later processing, thus preventing changes or update of the original image. This
can cause strange problems if you want to edit a configuration image to modify values and upload
it immediately. The result will still return the original image and not the new one.
4. Set the configuration backup/restore server hostname or FQDN and IP port in the Host Name field.
This is the current address and port number of the PC that hosts the configuration image file. Use
the special port value 0 to indicate the protocol default. For instance, the TFTP default port is 69
and the HTTP default port is 80.
The default value is 0.0.0.0:0.
NAT Variations
NAT treatment of UDP varies among implementations. The four treatments are:
• Full Cone: All requests from the same internal IP address and port are mapped to the same
external IP address and port. Furthermore, any external host can send a packet to the internal
host by sending a packet to the mapped external address.
• Restricted Cone: All requests from the same internal IP address and port are mapped to the
same external IP address and port. Unlike a full cone NAT, an external host (with IP address
X) can send a packet to the internal host only if the internal host had previously sent a packet
to IP address X.
• Port Restricted Cone: Similar to a restricted cone NAT, but the restriction includes port
numbers. Specifically, an external host can send a packet, with source IP address X and
source port P, to the internal host only if the internal host had previously sent a packet to IP
address X and port P.
• Symmetric: All requests from the same internal IP address and port, to a specific destination
IP address and port, are mapped to the same external IP address and port. If the same host
sends a packet with the same source address and port, but to a different destination, a
different mapping is used. Furthermore, only the external host that receives a packet can send
a UDP packet back to the internal host.
For more details on NAT treatments, refer to RFC 3489.
5. Set the path of the directory where the configuration image is located in the Location field.
The path is case sensitive hence it must be entered properly. It is relative to the root of the
configuration transfer server. Use the “/” character when defining the path to indicate sub-
directories.
This field may contain some macros that are substituted by the actual value when downloading the
configuration script. The supported macros are:
• %mac% - the MAC address of the unit
• %version% - the MFP version of the unit
• %product% - the Product name of the unit.
• %productseries% - the Product series name of the unit.
For instance, the “%mac%.xml” value for a Aastra unit with MAC address “0090f12345ab” will be
“0090f12345ab.xml”.
The path differs depending on the transfer protocol selected (see Step 4).
Let’s consider the following example for all protocols except File:
• The directory that contains the configuration image is called: Config_Image.
• This directory is under C:/Root/Download.
Table 300: Path Configurations Example
c:/root/download Config_Image
c:/ root/download/Config_Image
c:/root download/Config_Image
When the Transfer Protocol is set to File, you may prefix the path by one of the following to indicate
storage media:
• Persistent: for onboard persistent storage. The configuration image is saved into the
persistent file system of the Aastra unit (in flash memory). This is the default value.
• Volatile: for onboard non-persistent storage. The configuration image is saved into the
non-persistent RAM memory of the Aastra unit. All information is lost the next time the
unit restarts.
Table 301: Path Configurations Example (File)
Caution: The User Name and Password fields are not accessible if you have the User or Observer access
right. See “Users” on page 591 for more details.
7. Define the Backup Content drop-down menu with the information to include in the backup.
Table 302: Backup Content Parameters
Parameter Description
Parameter Description
Caution: The Privacy key field is not accessible if you have the User or Observer access right. See “Users”
on page 591 for more details.
The key is encoded in hexadecimal notation. You can thus use characters in the range 0-9, A-F. All
other characters are not supported.
Each character encodes 4 bits of the key. For instance, a 32-bit key requires 8 characters.
• If you enter too many bits, the key is truncated to the first 448 bits.
• If you do not enter enough bits, the key is padded with zeros.
For instance, a 32-bit key could look like the following: A36CB299.
This key must match the key used for the encryption of the configuration image. If the variable is
empty, the configuration image is not decrypted.
10. Do one of the following:
• To save your settings without performing a backup/restore, click Submit.
• To save your settings and perform a backup now, click Submit & Backup Now.
• To save your settings and perform a restore now, click Submit & Restore Now.
3
1
2
42 Firmware Download
This chapter describes how to install, uninstall and update software components on the Aastra unit by using
the web interface, according to a supplied Firmware Pack selection.
Note: If you have backed up the configuration of your unit, Aastra recommends that you perform a new
backup every time you upgrade the firmware pack of the unit to avoid restore issues.
A firmware pack file is a regular zip file that contains the modules and features to install on the Aastra unit.
When unzipping a firmware pack, the contents is extracted according to a pre-defined tree architecture. This
creates a directory that contains the files required for the Aastra unit to properly update its firmware. The
firmware pack contains all the modules to install. When performing the upgrade operation, the Aastra unit
checks the modules versions of the firmware pack against its own modules versions and installs only the
modules that have changed.
Note: The currently installed firmware pack is only required when downgrading.
To download a firmware pack, you may need to setup the following applications on your computer:
TFTP server with proper root path
SNTP server properly configured
MIB browser (with the current Aastra unit MIB tree)
Firmware pack zip file
HTTP server with proper root path
Note: The Aastra unit hardware does not include a real time clock. The unit uses the SNTP client to get and
set its clock. As certain services need correct time to work properly (such as HTTPS), you should configure
your SNTP client with an available SNTP server in order to update and synchronise the local clock at boot
time.
When you perform a firmware pack update that requires authentication or privacy by using the HTTP over the
Transport Layer Security (TLS) protocol (HTTPS), you must install a HTTPS server running on the PC
designated as the update files server. It is assumed that you know how to set the root path and set the SSL/
TLS security configuration. If not, refer to your HTTPS server’s documentation.
When two peers establish a HTTPS connection, they negotiate and decide on a cipher suite to use for data
encryption. The client suggests a list of cipher suites and the server selects one that it supports. Some cipher
suites are more secured than others. The Aastra unit acts as a client.
The Aastra unit suggests a wide range of cypher suites, which includes cipher suites that are not very secure.
The final choice rests with the server and it is thus possible that the transfer uses a SSL/TLS link that is not
very secure.
Aastra recommends to use cipher suites based on the RSA key exchange mechanism, because the Diffie-
Hellman key exchange mechanism introduces a noticeable delay in the HTTPS session establishment.
Furthermore, Aastra recommends using cipher suites based on the following SSL/TLS algorithms:
Table 304: Suggested Secure Parameters
The following six recommended cipher suites are based on the algorithms of Table 304:
Table 305: Recommended Cipher Suites
ID Name
0x0035 TLS_RSA_WITH_AES_256_CBC_SHA
0x0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0x000a TLS_RSA_WITH_3DES_EDE_CBC_SHA
0x0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0x002f TLS_RSA_WITH_AES_128_CBC_SHA
0x0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Certificates
The Aastra unit contains embedded security certificates formatted as per ITU x.509 and RFC 3280. The
certificates are factory-installed. You can also add new certificates as described in “Chapter 46 - Certificates
Management” on page 557.
When contacting a HTTPS server, the Aastra unit establishes a TLS connection by (among others):
negotiating cipher suites
checking the server certificates validity (dates)
Caution: You must have a time server SNTP that is accessible and properly configured. It is assumed that
you know how to configure your SNTP server. If not, refer to your SNTP server’s documentation. You can
also refer to “SNTP Configuration” on page 93 for more details on how to configure the Aastra unit SNTP
client.
The Aastra unit then checks the server’s identity by validating the host name used to contact it against the
information found in the server’s certificate, as described in RFC 2818, section 3.1.
If any of the above does not succeed, the Aastra unit refuses the secure connection. To help detect such
errors, you can increase the syslog messages level.
This section allows you to define the firmware pack version and name(s) to properly download them.
4
5
2. In the Firmware Packs Installed section of the Firmware Upgrade page, click one of the available
buttons if required:
Table 306: Available Buttons
Button Description
Factory Reset You can apply a factory reset to the current unit by clicking the Factory Reset
button. See “Factory Reset” on page 16 for more details.
Rollback You can revert back to the previously installed MFP found in the recovery bank
at any time by clicking the Rollback button. If the recovery bank contains a
MFP that can be used, it is displayed in the Bank column of the Firmware
Packs Installed section. When a rollback is performed, the configuration of the
MFP in the recovery bank applies. The current configuration is lost. The
Rollback button is displayed only if the current bank's application and the
recovery bank's application both support the rollback mechanism and have
been both installed from an application supporting the rollback. Otherwise, the
Rollback button is not displayed.
Note: This feature does not apply to the Aastra TA7102i model.
3. In the Firmware Packs Configuration section of the Firmware Upgrade page, enter the version of
the firmware pack to install in the Version field.
Currently, you cannot install two firmware packs with different versions.
4. Set the Automatic Restart Enable drop-down menu with whether or not to automatically restart the
system when needed for completing a firmware update operation.
You can also set a grace delay in the next step.
5. If automatic restart is enabled, set the Automatic Restart Grace Delay field with the grace delay, in
minutes, that the unit waits for all telephony calls to be terminated before the automatic restart can
occur.
The maximum value is set to 10080 minutes (7 days).
During that delay, it is impossible to make new calls but calls in progress are not terminated. When
all calls are completed, then the unit restarts.
You can also set a services restart grace period as described in “Graceful Restart of Services” on
page 56.
6. Enter the name of up to five firmware packs to install in the Firmware Pack fields.
You can install several firmware packs at the same time. In that case, enter the firmware pack
names in different rows of the table.
When extracting the content of the ZIP file, available firmware packs are listed as directories under
the xxx/FirmwarePacks directory.
Transfer Configuration
The following describes how to configure the transfer parameters required to perform a firmware update.
1
2
3
4
c:/root/download N/A
c:/ root/download
c:/root download
Caution: The User Name and Password fields are not accessible if you have the User or Observer access
right. See “Users” on page 591 for more details.
Certificate Validation
This section describes configuration that is available only in the MIB parameters of the Aastra unit. You can
configure these parameters as follows:
by using a MIB browser
by using the CLI
by creating a configuration script containing the configuration variables
When downloading a MFP from an HTTPS server, you can define the level of security to use when validating
the server's certificate.
Table 308: Certificate Validation Parameters
Parameter Description
NoValidation Allow a connection to the server without validating its certificate. The only condition is to
receive a certificate from the server. This option provides partial security and should be
selected with care.
HostName Allow a connection to the server by validating its certificate is trusted and valid. The
validations performed on the certificate include the expiration date and that the Subject
Alternate Name (SAN) or Common Name (CN) matches the FQDN or IP address of the
server.
Value Meaning
100 NoValidation
200 HostName
The following describes how to update the firmware pack of the Aastra unit.
Caution: Aastra recommends to close and re-open your Web browser after a reboot that installs a firmware
update. This is because your browser may activate a caching mechanism for some files. This mechanism
caches some of the files to improve performance. This may cause problems when the cached files change
in the Aastra unit after a firmware update and the web pages are no longer compatible with the cached files.
When the Aastra unit initiates a firmware pack update, the LEDs indicate the status of the process.
Table 310: LED States in Firmware Pack Update
Firmware pack downloading All LEDs are cycling from left to right, individually blinking 1 Hz, 33%
and writing duty.
Warning: Do not turn the Aastra unit off while in this state.
Firmware pack download failed All LEDs are blinking at 3 Hz, 50% duty. One LED out of two has a 180
degree phase. This pattern lasts for 8 seconds.
You can also view the firmware pack update status in the Status section of the Firmware Upgrade page.
Note: When the firmware pack update fails, the Aastra unit tries to download the firmware three times. In
some cases, the unit may also restart.
Many network switches use the Spanning Tree Protocol (STP) to manage Ethernet ports activity. When a
firmware pack update occurs, the Ethernet connector of the Aastra unit may switch off. This shutdown may
trigger these network switches to shutdown the matching Ethernet port for at least one minute. This shutdown
on the switch side can prevent firmware pack update.
To prevent this, the Aastra unit supports the STP. However, this management has a potential time cost. It may
appear from time to time that firmware pack updates take more time. This is normal.
When using the unit, Aastra recommends to disable the Spanning Tree Protocol on the network to which the
unit is connected.
43 Certificates Management
This chapter describes how to transfer and manage certificates into the Aastra unit.
Standards Supported • RFC 3280: Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile
Introduction
The Aastra unit uses digital certificates, which are a collection of data used to verify the identity of the holder
or sender of the certificate.
The certificates contain the following information:
certificate name
issuer and issued to names
Validity period (the certificate is not valid before or after this period)
Usage of the certificate (Identifies in which role or context a certificate can be used by the host
it authenticates).
• TlsClient: The certificate identifies a TLS client. A host authenticated by this kind of
certificate can act as a client in a SIP over TLS connection when mutual authentication
is required by the server.
• TlsServer: The certificate identifies a TLS server. A host authenticated by this kind of
certificate can serve files or web pages using the HTTPS protocol or can act as a
server in a SIP over TLS connection.
whether or not the certificate is owned by a CA (Certification Authority)
The Aastra unit uses two types of certificates:
Table 311: Certificates Types
Type Description
Host Certificates used to certify the unit (e.g.: a web server with HTTPS requires a host
certificate).
Others Any other certificate including trusted CA certificates used to certify peers (e.g.: a SIP
server with TLS).
The transferred certificate must be in Privacy Enhanced Mail (PEM) (host or others) or Distinguished Encoding
Rules (DER) (others) format. When transferring a host certificate, the certificate must be appended to the
private key to form one PEM file. The private key must not be encrypted.
You can transfer a certificate by using the HTTP or HTTPS protocol, but Aastra recommends to use HTTPS.
To access the unit via HTTPS, your browser must support RFC 2246 (TLS 1.0). The latest version of Microsoft
Internet Explorer supports HTTPS browsing.
Managing Certificates
You can view certificates information and you can delete certificates.
2
3
The Host Certificates section contains the certificates used to certify the unit. The Others
Certificates section contains any other certificate used to certify peers.
2. If applicable, delete a certificate in the Host Certificates or Others Certificates sections by clicking
the button of the certificate you want to delete.
3. If applicable, delete a certificate in the Other Certificates section by clicking the button of the
certificate you want to delete.
4. Click Submit if you do not need to set other parameters.
Certificate Authorities
Note: The default empty value means that the OCSP URL present in the certificate to verify will be used
for checking its revocation status.
The following steps explain how to transfer (add) a certificate from the web interface.
To upload a certificate:
1. If you are currently using an unsecure HTTP access, the Certificate Upload Through Web Browser
section is disabled. This is to avoid transferring a certificate in clear text. To enable the section,
access the secure site by clicking the Activate unsecure certificate transfer through web browser
link at the top of the window.
2. In the Certificate Upload Through Web Browser section of the Certificates page, select the type of
the certificate in the Type drop-down menu.
Before transferring the certificate, you must indicate whether this is a Host or Others certificate.
2 3 4
Value Description
FileUrl URL to a Certificate file that is loaded upon executing the execution of Download
command. The transfer protocols supported are:
• HTTP
• HTTPS
• TFTP
• FTP
Examples of valid URLS:
• http://www.myserver.com/Cert_MxDefault001.der
• tftp://myserver.com:69/myfolder/Cert_MxDefault001.der
When the port is not included in the URL, the default port for the chosen protocol is
used.
This field may contain some macros that are substituted by the actual value at the
moment of fetching the configuration script. The supported macros are:
• %mac% - the MAC address of the unit.
• %product% - the Product name of the unit.
UserName When authentication is required by the remote file server, this variable is used as
the username.
Password When authentication is required by the remote file server, this variable is used as
the password.
Type Type of certificate to transfer.
• Host: Certificate used to certify the host system.
• Other: Remote systems certificates and issuers certificates.
The Host Certificate Associations section allows you to define which services can use the host certificates.
Parameter Description
Parameter Description
44 SNMP Configuration
This chapter describes how to set the SNMP parameters of the Aastra unit.
Introduction
All parameters available in the Aastra unit web interface may also be configured via SNMP. The Aastra unit
SNMP feature offers the following options:
Password-protected access
Remote management
Simultaneous management
The Aastra unit SNMP feature allows you to configure all the MIB services by using a SNMP browser to contact
the MIBs of the Aastra unit. It is assumed that you have basic knowledge of TCP/IP network administration.
Note: The Aastra unit’s SNMP settings do not support IPv6. See “IPv4 vs. IPv6 Availability” on page 85 for
more details.
You can use the MIB browser built in the Aastra’ Unit Manager Network.
You can also use any third-party SNMP browser or network management application running the SNMP
protocol to monitor and configure the Aastra unit. However, the information may not be presented in the same
manner depending on the SNMP browser used.
Locate the proper parameter to modify and change (SET) its value.
The SNMP Configuration section allows you to configure the SNMPv3 privacy information that allows securing
the Aastra unit, as well as defining where the Aastra unit must send traps.
4
5
6
7
2. Set the SNMP Listening Port field with the port number on which the SNMP service listens for
incoming SNMP requests.
The default value is 161.
3. Specify with which SNMP version a user can connect to the system by setting one of the following
drop-down menus to enable:
Table 314: SNMP Versions
Caution: It is possible to disable all three versions of SNMP on the Aastra unit. If you do so, you will no
longer be able to access the unit in SNMP. To recover from this situation, you must perform a factory reset
procedure.
Note: Please note that a “public” user might be granted (unsecure) access by using SNMPv1 or SNMPv2,
while an “admin” user should rather be granted a SNMPv3 access. Furthermore, access for users in
SNMPv3 will require authentication and could be done with or without privacy according to the unit’s
configuration. This means that the unit does not grant an SNMPv3 access without authentication and
privacy.
4. If SNMPv3 is enabled, set the Authentication Protocol drop-down menu with the authentication
protocol to use with SNMPv3.
Table 315: SNMP Authentication Protocol
Protocol Description
Caution: The Authentication Protocol field is not accessible if you have the User or Observer access right.
See “Users” on page 591 for more details.
SNMPv3 will grant access to all users who are configured in the unit and have a password with 8
characters or more (in the AAA service as described in “Chapter 49 - Access Control Configuration”
on page 591).
5. If SNMPv3 is enabled, set the privacy protocol to use with SNMPv3 in the Privacy Protocol drop-
down menu.
Table 316: SNMP Privacy Protocol
Protocol Description
None No encryption is used. The Privacy Password parameter is ignored. This is the
default value.
DES DES encryption is used.
Caution: The Privacy Protocol field is not accessible if you have the User or Observer access right. See
“Users” on page 591 for more details.
6. If you are using the DES privacy, set the password to use in the Privacy Password field.
Caution: The Privacy Password field is not accessible if you have the User or Observer access right. See
“Users” on page 591 for more details.
7. Set the Community field with the string to use for the community field of SNMPv1 and SNMPv2
read-write commands and traps.
This field must not be empty.
The use of a community name provides context for agents receiving requests and initiating traps.
An SNMP agent won't respond to a request from a management system outside its configured
community.
The community name field may influence the AAA user name that will be used by the Aastra for
non-authenticated SNMP access (SNMPv1 and SNMPv2). See “Additional SNMP Parameters” on
page 441 for more information.
8. Specify that traps can be sent by setting the Enable SNMP Traps drop-down menu to enable.
There are five conditions that the Aastra unit checks before sending a trap:
• The traps are enabled.
• The destination address is valid.
• The NetSnmp Agent is ready.
• The destination address is reachable according to the routing table.
• The appropriate physical link is up.
If all of those conditions are true, then the Aastra unit sends the traps. If any of those conditions is
false, the Aastra unit waits (1 second) and retries until it succeeds. Even if the traps are delayed,
they will be sent with the appropriate timestamp when all the conditions are met.
Furthermore, the SNMP version(s) currently enabled (see Step 2 for more details) define which type
of trap may be sent.
Table 317: Trap Type Sent vs SNMP Version Enabled
Enabled
Enabled
Enabled Enabled
Enabled
Enabled Enabled
Enabled Enabled
Enabled Enabled Enabled
Note: You can also enable the traps via the CLI. See “Chapter 2 - Command Line Interface (CLI)” on
page 19 for details on how to work with the CLI.
Trap Description
coldStart A coldStart(0) trap means that the sending protocol entity is reinitializing
itself so that the agent's configuration or the protocol entity
implementation may be altered.
This trap is sent prior to a reboot that follows a firmware update, a
backup restoration or a default settings application. Note that if the unit is
shut down unexpectedly (power failure, power switch), this trap is not
emitted.
When the unit reboots because of a firmware upgrade, no coldStart traps
are sent before this reboot. In that specific case, a coldStart trap is sent
after the reboot if the installation scripts succeeded.
warmStart A warmStart(1) trap means that the sending protocol entity is reinitializing
itself so that neither the agent configuration nor the protocol entity
implementation is altered.
This trap is sent prior to all other reboots. Note that if the unit is shut
down unexpectedly (power failure, power switch), this trap is not emitted.
When the unit reboots because of a firmware upgrade, no warmStart
traps are sent before this reboot. In that specific case, a warmStart trap is
sent after the reboot if the installation scripts failed.
linkDown A linkDown(2) trap means that the SNMPv2 entity acting in an agent role
has detected that the ifOperStatus object for one of its communication
links is about to enter the down state from some other state. This other
state is indicated by the included value of ifOperStatus.
The Trap-PDU of type linkDown includes ifIndex, ifAdminStatus,
ifOperStatus (as of RFC 2233) of the interface that generated the trap.
Trap Description
linkUp A linkUp(3) trap means that the SNMPv2 entity, acting in an agent role,
has detected that the ifOperStatus object for one of its communication
links left the down state and transitioned into some other state (but not
into the notPresent state). This other state is indicated by the included
value of ifOperStatus.
The Trap-PDU of type linkUp includes ifIndex, ifAdminStatus,
ifOperStatus (as of RFC 2233) of the interface that generated the trap.
authenticationFailure An authenticationFailure(4) trap means that the sending protocol entity is
the addressee of a protocol message that is not properly authenticated.
This trap is sent when an authentication failure occurs from the Web, CLI
or SNMP interface.
9. If the traps are enabled, set the Trap Destination (s) field with the addresses/FQDNs and ports
where to send traps.
You can specify up to 5 destinations by using a comma between them (comma is not authorized
within a FQDN). The port numbers are optional. Note that the traps are sent simultaneously to all
destinations.
Example:
trapdest.com:2345, 123.45.67.89
The default value is 192.168.10.10:162.
10. Click Submit if you do not need to set other parameters.
A user name can be added to be used by the SNMP v1/v2 to access the configuration.
For non-authenticated access (SNMPv1 and SNMPv2), the Aastra will use the AAA user name from the
SnmpUser variable if it is not empty. If empty, the community name is used as the AAA user name.
Caution: If the provided SNMP user name does not exist in the AAA.UsersStatus table or if the SNMP
user name is empty and the community name does not exist in the AAA.UsersStatus table, the SNMP
access will fail.
Partial Reset
When a partial reset is triggered, the following parameters are affected:
Listening Port: Default value 161.
Enable SNMPv1: Default value disable.
Enable SNMPv2: Default value disable.
SNMP Statistics
This chapter describes how to set the Access Control parameters of the Aastra unit.
Standards Supported • RFC 2617: HTTP Authentication: Basic and Digest Access
Authentication
• RFC 2865: Remote Authentication Dial In User Service
(RADIUS)
• RFC 2866: RADIUS Accounting
Caution: The Access Control page is not accessible if you have the User or Observer access right. See
“Users” on page 443 for more details.
Users
The Users section allows you to manage the users that can access the web interface. You can add a maximum
of 10 users.
To manage users:
1. In the web interface, click the Management link, then the Access Control sub-link.
2. If you want to add a new user, enter its name in the blank User Name field in the bottom left of the
window, enter the corresponding password in the blank Password field, then click the button.
The name is case-sensitive.
3. If you want to delete an existing user, click the corresponding button.
If you delete all users in the table, the profile’s default user(s) will be used upon unit restart.
Note: A system restart is required to completely remove the user. The current activities of this user are not
terminated on removal.
4. If you want to change the password of an existing user, type it in the corresponding Password field.
The password is case sensitive. All characters are allowed.
5. Define the access rights template applying to a user in the corresponding Access Rights drop-down
menu.
Admin User is allowed to read and modify all variables of the unit.
User User is allowed to read and modify all variables except passwords and secrets.
Observer User is only allowed to read variables that are not passwords or secrets.
See “Access Rights Description” on page 447 for mode details on the various operations allowed
with each access right.
6. Click Submit if you do not need to set other parameters.
Partial Reset
When a partial reset is triggered, the password and access rights reset back to the default value (see “Partial
Reset” on page 15 for more details).
The Services Access Control Type section allows you to define the type of authentication and accounting to
use for the CLI, SNMP, and Web services.
Authentication provides a way of identifying a user, typically by having the user enter a valid user name and
valid password before access is granted.
Accounting measures the resources a user consumes during access. This can include the amount of system
time or the amount of data a user has sent and/or received during a session.
Type Description
Local Incoming authentication attempts are validated against the user names and
passwords stored in the Local Users table (see “Users” on page 443 for more
details).
Radius Incoming authentication attempts are validated against the first responding
Radius server configured in the Radius Servers section (“Radius Servers” on
page 445). When no server is configured or the servers are unreachable, an
authentication attempt of type Local is performed against the user names and
passwords stored in the Local Users table (see “Users” on page 443 for more
details).
Note: This type is not available for the SNMP interface.
2. Set the accounting type a service uses in the corresponding Accounting Type column.
Accounting starts once users are successfully authenticated and stops when their session is over.
Table 322: Accounting Types
Type Description
Partial Reset
When a partial reset is triggered, the Radius authentication is disabled (see “Partial Reset” on page 15 for
more details).
Radius Servers
The Radius Servers section allows you to define up to three Radius servers. It also allows you to define
authentication server and accounting server information, for the CLI, SNMP, and Web services.
Note: The Aastra unit’s Radius server settings do not support IPv6. See “IPv4 vs. IPv6” on page 85 for more
details.
Radius Authentication occurs when the Authentication Type column of the Services Access Control Type
section (“Services Access Control Type” on page 444) is set to Radius for the service from which the
authentication request is coming. You can configure up to three Radius servers for each service listed in the
Select a Service drop-down menu. The first authentication attempt is sent to the Radius server with the highest
priority, which is set in the Priority column (1 being the highest priority). When authentication fails or the
request reaches the timeout set in the Server Request Timeout field, the next server with the highest priority
is used. When all servers have failed to reply or no servers are configured for the service asking for
authentication, authentication is attempted against local user names and passwords as a fallback strategy.
Radius authentication is available for the CLI and Web services.
Radius Accounting is enabled by setting the Accounting Type column of the Services Access Control Type
section (“Services Access Control Type” on page 444) to Radius for one or more services. When such a
configuration is set, accounting requests made through those services are forwarded to a Radius server
configured in the Radius Servers section. You can configure up to three Radius servers for each service listed
in the Select a Service drop-down menu. The first accounting request is sent to the Radius server with the
highest priority, which is set in the Priority column (1 being the highest priority). When the accounting request
fails or the request reaches the timeout set in the Server Request Timeout field, the next server with the
highest priority is used. The CLI, Web, and SNMP services can use the accounting functionality.
2
3
4
5
6
7
3. Set the secret key shared between the Radius server and the unit in the corresponding Server
Secret field.
The Authentication Secret key must be the same as the secret key stored on the corresponding
Radius authentication server.
4. In the Accounting part, set the host name and port of a Radius server used for accounting requests
in the corresponding Host field.
You can configure up to three Radius servers with a different priority.
5. Set the secret key shared between the Radius server and the unit in the corresponding Server
Secret field.
The Accounting Secret key must be the same as the secret key stored on the corresponding Radius
accounting server.
6. Set the Server Request Timeout field with the maximum time, in milliseconds, the unit waits for a
reply from a Radius server.
This parameter applies to all services. Upon reaching the timeout, the request is sent to the next
configured server.
7. Define the access rights template applying to a user in the corresponding Radius Users Access
Rights drop-down menu.
This parameter applies to all services. You have the following choices:
Table 323: Radius Users Access Rights
Admin User is allowed to read and modify all variables of the unit.
User User is allowed to read and modify all variables except passwords and secrets.
Observer User is only allowed to read variables that are not passwords or secrets.
See “Access Rights Description” on page 447 for mode details on the various operations allowed
with each access right.
8. Click Submit if you do not need to set other parameters.
You have three templates of rights from which you can select the permissions given to each user allowed in a
unit (see “Users” on page 443 and “Radius Servers” on page 445).
The following table describes the various operations allowed with each access right.
Table 324: Access Rights Description
46 File Manager
File Manager
The File page allows you to view and delete the files you have created with the File transfer protocol, for
instance, a configuration backup..
Note: The files under the File service are not included in the backup process. In the same way, the restore
process will not remove any file under the File service.
Partial Reset
When a partial reset is triggered, the user-defined presets are deleted.
47 Miscellaneous
This chapter describes how to set various parameters used to manage the Aastra unit.
The Miscellaneous page allows you to specify which one of the existing network interfaces is used to manage
the Aastra unit.
2. Select which one of the existing network interfaces is used to manage the device in the Network
Interface drop-down menu.
The management services (typically Web and/or SNMP) can be reached through this network
interface.
Before the system management services can be used, they need to be bound (or linked) to a
physical port of your Aastra unit.
The special value "All" means to bind all network interfaces.
3. Click Submit if you do not need to set other parameters.
Partial Reset
When a partial reset is triggered, the Management Interface reverts back to its default value.
A Country-Specific Parameters
The following parameters differ depending on the country in which you are.
Definitions
Term Description
Stutter Dial Tone Notifies the user that they have a voice mail message when the phone
does not or cannot have a message-waiting light.
Receiver Off Hook (ROH) Tone Indicates that the telephone is not hung up correctly.
Message Waiting Indicator Tone Indicates there is a message waiting somewhere for the owner of the
phone
Network Congestion Tone Indicates that all switching paths are busy, all toll trunks are busy, or
there are equipment blockages.
Intercept Tone Indicates that you have dialed incorrectly or that the feature you've
requested is not available on your terminal.
Preemption Tone In military telephone systems, a distinctive tone that is used to indicate
to connected users, i.e., subscribers, that their call has been
preempted by a call of higher precedence.
Reorder Tone Indicates that all switching paths are busy, all toll trunks are busy, there
are equipment blockages, the caller dialled an unassigned code, or the
digits dialled got messed up along the way.
Conventions
The following conventions apply to this Appendix.
Frequencies
Symbol “*” means modulated. For instance: 425 Hz * 25 means 425 Hz modulated at 25 Hz.
Symbol “+” means added. For instance: 425 Hz + 330 Hz means that both 425 Hz and 330 Hz
Impedance
Impedance is the apparent resistance, in an electric circuit, to the flow of an alternating current, analogous to
the actual electrical resistance to a direct current, being the ratio of electromotive force to the current.
When representing an impedance, the following applies:
Symbol “//” means parallel.
Symbol “+” means serial.
Furthermore, there are two types of impedances:
Input Impedance
Terminal Balance Return Loss (TBRL) Impedance
Input Impedance
Impedance of the Aastra at the Tip and Ring wires.
Line Attenuation
Values are given in dBr (deciBel relative):
A “+” for input means that the digital side is attenuated by x decibels relative to the analog side.
A “+” for output means that the analog side is amplified by x decibels relative to the digital side.
A “-” for input means that the digital side is amplified by x decibels relative to the analog side.
A “-” for output means that the analog side is attenuated by x decibels relative to the digital side.
On-Off Sequences
Values in bold are “on” cycles, where tones are audible. Values in normal style are “off” cycles, where tones
are not audible. When not otherwise specified, sequences repeat forever. A “x” symbol means that the
sequences between parenthesis is repeated x times. The next cycle(s) repeat forever, unless otherwise
specified. Values are in seconds.
For instance:
3*(0.1 – 0.1) then 0.6 – 1.0 - 0.2 – 0.2
means that the 0.1s on and 0.1s off sequence is repeated 3 times, afterwards the 0.6s on, 1.0s off, 0.2s on
and 0.2s off sequence repeats forever.
Australia
Australia 1
The following parameters apply if you have selected Australia 1 as location.
Table 326: Australia 1 Parameters
Call Waiting Tone 425 Hz 0.2 - 0.2, 0.2 - 4.4, 0.2 - 0.2, 0.2 - 4.4 -23 dBm
Message Waiting Indicator Tone 425 Hz (0.1 - 0.04)x72, CONTINUOUS -18 dBm
400 Hz (0.1 - 0.04)x72, CONTINUOUS -24 dBm
450 Hz (0.1 - 0.04)x72, CONTINUOUS -24 dBm
Network Congestion Tone 425 Hz 0.38 - 0.38, 0.38 - 0.38 -13 dBm
425 Hz 0.38 - 0.38, 0.38 - 0.38 -23 dBm
Loop Current 30 ma
Tbrl-Impedance 600 Ω
Australia 2
The following parameters apply if you have selected Australia 2 as location.
Table 327: Australia 2 Parameters
Call Waiting Tone 425 Hz 0.2 - 0.2, 0.2 - 4.4, 0.2 - 0.2, 0.2 - 4.4 -23 dBm
Message Waiting Indicator Tone 425 Hz (0.1 - 0.04)x72, CONTINUOUS -18 dBm
400 Hz (0.1 - 0.04)x72, CONTINUOUS -24 dBm
450 Hz (0.1 - 0.04)x72, CONTINUOUS -24 dBm
Network Congestion Tone 425 Hz 0.38 - 0.38, 0.38 - 0.38 -13 dBm
425 Hz 0.38 - 0.38, 0.38 - 0.38 -23 dBm
Loop Current 30 ma
Austria
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 450 Hz (0.1 – 0.1) x 10, CONTINUOUS -20 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 950 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
Loop Current 30 ma
Tbrl-Impedance 600 Ω
Brazil
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10, CONTINUOUS -15 dBm
Receiver Off Hook (ROH) Tone 425 Hz 0.25 – 0.25 -10 dBm
Special Information Tone 950 Hz 0.33 - 0.03 - 0.33 - 0.03 - 0.33 - 1.0 -15 dBm
1400 Hz 0.33 - 0.03 - 0.33 - 0.03 - 0.33 - 1.0 -15 dBm
1800 Hz 0.33 - 0.03 - 0.33 - 0.03 - 0.33 - 1.0 -15 dBm
Loop Current 30 ma
Tbrl-Impedance 800 Ω // 50 nF
China
Call Waiting Tone 450 Hz 0.4 – 4.0, 0.4 – 4.0 -20 dBm
Receiver Off Hook (ROH) Tone 950 Hz 5.0 – 5.0 – 5.0 – 5.0 -25 dBm
950 Hz 5.0 – 5.0 – 5.0 – 5.0 -16 dBm
950 Hz 5.0 – 5.0 – 5.0 – 5.0 -8 dBm
950 Hz 5.0 – 5.0 – 5.0 – 5.0 -6 dBm
Reorder Tone 450 Hz 0.1 – 0.1, 0.1 – 0.1, 0.1 – 0.1, 0.4 – 0.4 -10 dBm
Special Information Tone 950 Hz 0.33 - 0.33 - 0.33 - 1.0 -10 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -10 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -10 dBm
Loop Current 30 ma
Tbrl-Impedance 600 Ω
Czech Republic
The following parameters apply if you have selected Czech Republic1 as location.
Table 331: Czech Republic1 Parameters
Call Waiting Tone 425 Hz 2.0 – 0.33, 10.0 – 0.33, 10.0 -11 dBm
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10, 0.33 – 0.33, 0.66 – 0.66 -12 dBm
Receiver Off Hook (ROH) Tone 425 Hz 0.17 – 0.17 -12 dBm
Special Information Tone 950 Hz 0.33 - 0.33 - 0.33 - 1.0 -12 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -12 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -12 dBm
Stutter Dial Tone 425 Hz (0.17 – 0.17) x 3, 0.66 – 0.66 -12 dBm
Loop Current 30 ma
France
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 440 Hz (0.1 – 0.1) x 10, CONTINUOUS -17 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 950 Hz 0.3 - 0.03 - 0.3 - 0.03 - 0.3 - 1.0 -20 dBm
1400 Hz 0.3 - 0.03 - 0.3 - 0.03 - 0.3 - 1.0 -20 dBm
1800 Hz 0.3 - 0.03 - 0.3 - 0.03 - 0.3 - 1.0 -20 dBm
Loop Current 30 ma
Tbrl-Impedance 600 Ω
Germany
Germany 1
The following parameters apply if you have selected Germany 1 as location.
Table 333: Germany 1 Parametersa
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10, CONTINUOUS -16 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 900 Hz 0.33 - 0.33 - 0.33 - 1.0 -16 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -16 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -16 dBm
Loop Current 30 ma
Germany 2
The following parameters apply if you have selected Germany 2 as location.
Table 334: Germany 2 Parameters
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10, CONTINUOUS -13 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -16 dBm
Special Information Tone 900 Hz 0.33 - 0.33 - 0.33 - 1.0 -13 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -13 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -13 dBm
Loop Current 30 ma
Israel2
Call Waiting Tone 400 Hz 0.5 – 10.0, 0.5 – 10.0 -16 dBm
Confirmation Tone 400 Hz 0.17 – 0.34, 0.14 – 0.14, End -14 dBm
Message Waiting Indicator Tone 400 Hz (0.16 – 0.16) x 10, CONTINUOUS -14 dBm
Receiver Off Hook (ROH) Tone 1440+2060+2452+2600 Hz 0.12 – 0.1 -14 dBm
Loop Current 30 ma
Tbrl-impedance 600 Ω
Italy
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10, 0.2 – 0.2, 0.6 – 1.0 -13 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 950 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
Stutter Dial Tone 425 Hz (0.1 – 0.1) x 3, 0.2 – 0.2, 0.6 – 1.0 -13 dBm
Loop Current 30 ma
Tbrl-impedance 750 Ω // 18 nF
Japan
Call Waiting Tone 400 Hz 2.0 - 0.3, 10.0 - 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 400 Hz (0.1 - 0.1)x10, CONTINUOUS -13 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Loop Current 30 ma
Mexico
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10 CONTINUOUS -14 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 900 Hz 1.0 - 1.0 - 1.0 - 1.0 -14 dBm
1400 Hz 1.0 - 1.0 - 1.0 - 1.0 -14 dBm
1800 Hz 1.0 - 1.0 - 1.0 - 1.0 -14 dBm
Loop Current 30 ma
Tbrl-impedance 600 Ω
North America
The following parameters apply if you have selected North America as location.
North America 1
The following parameters apply if you have selected North America 1 as location.
Table 339: North America 1 Parameters
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 350+440 Hz (0.1 – 0.1) x 10, CONTINUOUS -17 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 950 Hz 0.33 - 0.33 - 0.33 - 1.0 -14 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0
1800 Hz 0.33 - 0.33 - 0.33 - 1.0
Loop Current 30 ma
Spain
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10, CONTINUOUS -10 dBm
Network Congestion Tone 425 Hz 0.2 – 0.2, 0.2 – 0.2, 0.2 – 0.6 -13 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 950 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -20 dBm
Loop Current 30 ma
Switzerland
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 425 Hz (0.1 – 0.1) x 10, CONTINUOUS -8 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 950 Hz 0.33 - 0.33 - 0.33 - 1.0 -13 dBm
1400 Hz 0.33 - 0.33 - 0.33 - 1.0 -13 dBm
1800 Hz 0.33 - 0.33 - 0.33 - 1.0 -13 dBm
Loop Current 30 ma
The following parameters apply if you have selected United Arab Emirates as location.
Call Waiting Tone 425 Hz (0.2 – 12.0, 0.2 –12.0)x2 End -13 dBm
Message Waiting Indicator Tone 350+440 Hz (0.1 – 0.1) x 10 CONTINUOUS -13 dBm
Network Congestion Tone 400 Hz 0.4 – 0.35, 0.23 – 0.53 -13 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz (0.1 – 0.1) -19 dBm
Special Information Tone 950 Hz 0.33 – 0.33, 0.33 – 1.0 -13 dBm
1400 Hz 0.33 – 0.33, 0.33 – 1.0 -13 dBm
1800 Hz 0.33 – 0.33, 0.33 – 1.0 -13 dBm
Loop Current 30 ma
Tbrl-impedance 600 Ω
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 –0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 350+440 Hz (0.1 – 0.1) x 10 CONTINUOUS -22 dBm
Network Congestion Tone 400 Hz 0.4 – 0.35, 0.23 – 0.53 -19 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz (0.1 – 0.1) -19 dBm
Special Information Tone 950 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
1400 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
1800 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
Loop Current 30 ma
Tbrl-impedance 600 Ω
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 –0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 350+440 Hz (0.1 – 0.1) x 10 CONTINUOUS -22 dBm
Network Congestion Tone 400 Hz 0.4 – 0.35, 0.23 – 0.53 -19 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz (0.1 – 0.1) -19 dBm
Special Information Tone 950 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
1400 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
1800 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
Loop Current 30 ma
Tbrl-impedance 600 Ω
UK
The following parameters apply if you have selected the United Kingdom as location.
Table 345: UK Parameters
Call Waiting Tone 440 Hz 2.0 – 0.3, 10.0 – 0.3, 10.0 -17 dBm
Message Waiting Indicator Tone 350+440 Hz (0.1 – 0.1) x 10, CONTINUOUS -22 dBm
Network Congestion Tone 400 Hz 0.4 – 0.35, 0.23 – 0.53 -19 dBm
Receiver Off Hook (ROH) Tone 1400+2060+2450+2600 Hz 0.1 – 0.1 -19 dBm
Special Information Tone 950 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
1400 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
1800 Hz 0.33 – 0.33, 0.33 – 1.0 -19 dBm
Loop Current 30 ma
B Scripting Language
This appendix describes the Aastra proprietary scripting language. It also lists a few configuration samples
that can be pasted or typed into the CLI (see “Chapter 2 - Command Line Interface (CLI)” on page 11 for more
details) or downloaded into the Aastra via the Configuration Script feature (see“Chapter 40 - Creating a
Configuration Script” on page 414.
You can substitute the values listed in these examples with your own values. When enums are involved, refer
to the MIB structure with a MIB browser to determine the actual value you need to insert. You can also refer
to the Configuration Reference Guide, which lists all the parameters, tables, and commands available in the
Aastra.
This appendix covers the following topics:
General Scripting Language Syntax
Assigning scalar values
Assigning table cell values
Executing commands
Variable Values (Enums)
Call Router Specific Information
Examples
The Aastra proprietary scripting language can be used to assign values to configuration variables and execute
configuration commands. The scripting language may be used when creating configuration scripts and when
working with the Command Line Interface (“Chapter 2 - Command Line Interface (CLI)” on page 11).
Using the scripting language requires a bit of knowledge about the Aastra’s configuration variables tree
structure.
The scripting language uses the following general syntax:
[keyword] [Context_Name [separator expression [operator constant]]] [#comment]
All specific syntaxes in this Appendix are derived from this general syntax.
Note that the brackets ([ and ]) are used to mark optional arguments. They are not part of the syntax.
Table 346: Scripting Language Syntax
keyword A token that defines the type of operation to execute on expression or the type of data to
retrieve from expression. Currently, only the set keyword is supported, which assigns
value of constant to expression.
Context_Name Defines to which service the following expression belongs. For instance, the
Configuration Manager context is Conf, the Firmware Pack Updater context is Fpu, and
the Host Configuration context is Hoc.
separator Delimiter defined as “.” (dot).
Supported Characters
When using the scripting language, the following ASCII codes are supported:
10 LF, line feed 62 >, greater than 94 ^, caret
13 CR, carriage return 63 ?, question mark 95 _, underscore
32 space 64 @, commercial at 96 `, back quote
33 !, exclamation mark 65 A 97 a
34 ", double quote 66 B 98 b
35 #, hash 67 C 99 c
36 $, dollar 68 D 100 d
37 %, percent 69 E 101 e
38 &, ampersand 70 F 102 f
39 ', quote 71 G 103 g
40 (, open parenthesis 72 H 104 h
41 ), close parenthesis 73 I 105 i
42 *, asterisk 74 J 106 j
43 +, plus 75 K 107 k
44 ,, comma 76 L 108 l
45 -, minus 77 M 109 m
46 ., full stop 78 N 110 n
47 /, oblique stroke 79 O 111 o
48 0, zero 80 P 112 p
49 1 81 Q 113 q
50 2 82 R 114 r
51 3 83 S 115 s
52 4 84 T 116 t
53 5 85 U 117 u
54 6 86 V 118 v
55 7 87 W 119 w
56 8 88 X 120 x
57 9 89 Y 121 y
58 :, colon 90 Z 122 z
59 ;, semicolon 91 [, open square bracket 123 {, open curly bracket
60 <, less than 92 \, backslash 124 |, vertical bar
61 =, equals 93 ], close square bracket 125 }, close curly bracket
126 ~, tilde
& : &
The following is a sample script command assigning a value to a scalar configuration variable:
Service_Name.Scalar_Name=value
Command Description
Service_Name Defines which service should process the expression. For instance, the
Configuration Manager context is Conf, the Firmware Pack Updater context is
Fpu, and the Host Configuration context is Hoc.
Scalar_Name Name of the specific variable to which assign a value.
value A textual string or a number to assign to the argument.
When you want to get the value of a specific table cell or set the value of a specific table cell, you must follow
a particular syntax:
[get]Service_Name.Table_Name[Index=key].Column_Name
[set]Service_Name.Table_Name[Index=key].Column_Name=<value>
Command Description
Service_Name Defines which service should process the expression. For instance, the
Configuration Manager context is Conf, the Firmware Pack Updater context is
Fpu, and the Host Configuration context is Hoc.
Table_Name Name of the table that contains the cell.
index=key List of index values identifying the row on which the cell is located. The list of
indexes is in the name=value form, separated by spaces and enclosed within
brackets. The index is always the first column of a table.
Column_Name Name of the column that contains the cell.
value A textual string or a number to assign to the argument.
Interface3 400 cd
10.1.1.3
a. This enum means “disabled”
If you want to get the IP address value of Interface 3, you would have to enter the following command:
get Bni.NetworkInterfacesStatus[InterfaceName=Interface3].IpAddr
Executing Commands
Configuration commands are used to make the Aastra perform actions such as restarting the unit, restarting
a service, refreshing its SIP registration, etc.
There are two types of commands you can execute:
Normal Commands
Row Commands
Normal Commands
The normal command feature has the following syntax:
Service_Name.Command_Name arg1=value1 –b arg2=[value2 value3 value4]
Command Description
Service_Name Defines which service should process the command. For instance, the
Configuration Manager context is Conf, the Firmware Pack Updater context is
Fpu, and the Host Configuration context is Hoc.
Command_Name The command to execute.
argn Name of the argument for which you want to assign a value. Three types of
arguments are allowed:
• flags (beginning with ‘-‘, without anything else, for instance, “-b” in the
command syntax above). Flags are optional.
• scalar arguments (with mandatory ‘=’ and following value). They are
mandatory unless they have a default value, in which case they are
optional.
• vector arguments (with mandatory ‘=’ and following a list of values
enclosed within brackets and separated by spaces). They are
mandatory unless they have a default value, in which case they are
optional.
The number and types of arguments depend on the specific command you are
using.
valuen A textual string or a number to assign to the argument.
Double Quotes
You must use double quotes when the text parameter contains special characters such as dot or "#". For
instance, entering the following command results in a bad command:
Conf.BackupImage FileName=test.cfg Location=config TransferProtocol=400
TransferUsername=Usr1 TransferPassword=Pwd1 TransferSrvHostname=192.168.6.3
You must enclose each text parameter that contains special characters such as dot or "#" with double quotes.
In the above example, you must enclose FileName=test.cfg and TransferSrvHostname=192.168.6.3 in double
quotes:
Conf.BackupImage FileName="test.cfg" Location=config TransferProtocol=400
TransferUsername=Usr1 TransferPassword=Pwd1 TransferSrvHostname="192.168.6.3"
Row Commands
Row commands appear as table cells and allow you to perform an action on a specific row of the relevant table.
Row commands are available in several services of the Aastra. For instance, the Call Router service uses the
Up, Down, Insert, and Delete commands in its various tables.
The row command feature has the following syntax:
Context_Name.Table_Name[index1=value1 index2=value2].Row_Command=execute_value
Command Description
Context_Name Defines which service should process the command. For instance, the
Configuration Manager context is Conf, the Firmware Pack Updater context is
Fpu, and the Host Configuration context is Hoc.
Table_Name Table where the row command is located.
indexn=valuen List of index values identifying the row on which to execute the command. The
list of indexes is in the name=value form, separated by spaces and enclosed
within brackets. The index is always the first column of a table. See “Assigning
Table Cell Values” on page 479 for more details.
Row_Command The row command to execute.
execute_value Numerical value of the enum.
For instance, the following executes the service Dhcp’s StaticLeases Delete row command on one of the
table’s rows. The StaticLeases table only has one index column: the MacAddress column. The Delete row
command is an enum that has two possible values: noOp (0) and delete (10). The command is executed by
assigning the execute value (10) to the Delete cell.
Dhcp.StaticLeases[MacAddress="0090F8001234"].Delete=10
DeleteAllRows Command
The DeleteAllRows command is a table command that you can use to delete all rows of a specific table to start
anew. You can use it as follows:
Service_Name.Table_Name.DeleteAllRows
A valid command would be:
CRout.MappingExpression.DeleteAllRows
The scripting language represents enums with their numeric value, and not their textual value. For instance,
the TFTP transfer protocol values available are as follows:
100
200
300
400
500
This does not mean much. By looking into the MIB structure of the Aastra with a MIB browser or requesting
help on the variable in the CLI, you will be able to determine that the values really mean the following:
100: HTTP
200: HTTPS
300: TFTP
400: FTP
500: FILE
When working with call router parameters, you must be aware of the following:
You must prefix the name of a route with “route-”, for instance: route-isdn_sip.
You must prefix the name of a SIP interface with “sip-”, for instance: sip-default.
You must prefix the name of an ISDN interface with “isdn-”, for instance: isdn-default.
You must prefix the name of a hunt with “hunt-”, for instance: hunt-hunt1.
Examples
This section gives a few configuration samples that can be used both in the CLI or as part of a configuration
script.
Management Functions
The following sections describe how to perform some useful management functions such as a configuration
backup/restore and changing the default user password.
Debugging
The following sections allow you to enable two useful debugging tools of the Aastra: syslog messages and
PCM traces.
Enabling Syslog
This example assumes that you run a syslog server at address 192.168.3.4.
Nlm.SyslogRemoteHost=”192.168.3.4”
Cli.MinSeverity=300
Bni.MinSeverity=400
Hoc.MinSeverity=500
This appendix describes the MTU (Maximum Transmission Unit) requirements of the Aastra.
What is MTU?
The Maximum Transmission Unit (MTU) is a parameter that determines the largest packet than can be
transmitted by an IP interface (without it needing to be broken down into smaller units). Each interface used
by TCP/IP may have a different MTU value specified.
The MTU should be larger than or equal to the largest packet you wish to transmit unfragmented. Note that
this only prevents fragmentation locally. Some other link in the path may have a smaller MTU: the packet will
be fragmented at that point, although some routers may refuse packets larger than their MTU.
Aastra’s MTU
The Aastra’s MTU is 1500 bytes, which is the Ethernet typical value.
The implementation of the IEEE Standard 802.1q in the Aastra may have a minor problem because of
hardware limitations.
802.1q increases the Ethernet frame header by 4 bytes, adding a Virtual LAN ID and a user_priority. This is
useful to limit broadcasts that cross bridges, and it may also prioritize frames in the queuing algorithm of
switches. However, it also increases the maximum possible size of Ethernet frames from 1518 to 1522 bytes,
and this might not be handled adequately by every hardware.
A workaround is available for PCs running Windows to avoid sending 1522 bytes packets (note that this
happens only in special and rare cases). The workaround is to reduce the MTU of the interface (the one that
sends packets with 802.1q framing) by 4 bytes.
1. Use the registry editor (regedt32) and go to the key:
Windows 2000 and later:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
\<ethernet adapter>
Windows NT4 and 98:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ethernet
adapter>\Parameters\Tcpip
where <Ethernet adapter> can be found by using the command “ipconfig /all”.
2. Add (or modify) a value named MTU of type REG_DWORD. Set it to 1496 (instead of 1500), in
decimal. Restart the computer to have those changes in effect.
In Windows 2000 and later this value is under the following key:
• Key: Tcpip\Parameters\Interfaces\ID for Adapter2
All parameters available in the Aastra web interface may also be configured via SNMP. The Aastra SNMP
feature offers the following options:
Password-protected access
Remote management
Simultaneous management
This Appendix lists the mapping between the web interface fields and the corresponding SNMP variables of
the Aastra.
System Page
Information Sub-Page
System Time currentTimeSystem Current date and time system configured in the unit.
Services Sub-Page
System Service
User Service
Graceful Delay (min) graceDelay The delay (in minutes) allowed for telephony calls to be all
completed.
CancelRestartRequiredServices (command) Cancels the restart during the grace delay period.
Hardware Sub-Page
Unit Configuration portsConfiguration Configures how each port provides a link interface.
Clock Reference physicalLinkClockMode A port can either generate the clocking for the line or accept
the clock from the line.
Clock Reference physicalLinkClockMode A port can either generate the clocking for the line or accept
the clock from the line.
Clock Reference physicalLinkClockMode Indicates the preferred synchronisation source to use for the
internal clock of this digital card.
Endpoints Sub-Page
Operational unitOpState The operational state of the unit reflects the unit's internal
state.
Usage unitUsageState The usage state of the unit indicates its running state.
Administration Section
Disable Unit When No unitDisabledWhenNoGatewayReadyEnable Indicates if the unit operational state is automatically set to
Gateways Are In State disable when all signaling gateways are not ready.
Ready
Syslog Sub-Page
Field Name SNMP Variable Description
Remote Host syslogRemoteHost Host name and port number of the device that archives log
entries.
Diagnostic Traces diagnosticTracesEnable Enables traces allowing the Technical Assistance Centre to
further assist in resolving some issues.
Events Sub-Page
Field Name SNMP Variable Description
Action eventsAction Action to apply to the system event if the criteria matches.
Maximum Number of LocalLogMaxNbEntries Maximum number of entries that the local log can contain.
Entries When adding a new entry while the local log is full, the
oldest entry is erased to make room for the new one.
Number of Error LocalLogNbErrorEntries Current number of error entries in the local log.
Entries
Number of Critical LocalLogNbCriticalEntries Current number of critical entries in the local log.
Entries
Local Time LocalTime Local date and time at which the log entry was inserted.
Format is YYYY-MM-DD HH:MM:SS.
Service Name ServiceTextkey Textual identifier of the service that issued the log entry.
Service Key ServiceNumkey Numerical identifier of the service that issued the log entry.
Network Page
Status Sub-Page
Link networkInterfaceStatusLinkName Name of the link interface associated with the network
interface.
IP Address networkInterfacesStatusIpAddr Current address and network mask of the network interface.
Connection Uptime networkInterfacesConnectionUptime The time, in seconds, for which this IP interface has been
connected.
VLAN Override netorknterfacesStatusVlanOverrideEnable Indicates if the VLAN ID of the current network interface has
been overridden by the values received from the LLDP
protocol.
General Configuration
IPv4 Default Gateway defaultRoutersInfoDefaultRouter Indicates the subnet's current default gateway.
IPv6 Default Gateway defaultRoutersInfoDefaultRouter Indicates the subnet's current default gateway.
DNS Configuration
SNTP Configuration
Primary SNTP Host sntpServersInfoHostName1 Indicates the subnets' first NTP server.
Secondary SNTP Host sntpServersInfoHostName2 Indicates the subnets' second NTP server.
Third SNTP Host sntpServersInfoHostName3 Indicates the subnets' third NTP server.
Fourth SNTP Host sntpServersInfoHostName4 Indicates the subnets' fourth NTP server.
Source Address advancedIpRoutesStatusSourceAddress Source address[/mask] criteria used to match the rule.
Source Link advancedIpRoutesStatusSourceLink Source link criteria used to match the rule.
Firewall Section
Source Port networkRulesStatusSourcePort Source port[-port] criteria an incoming packet must have to
match this rule.
Destination Port networkRulesStatusDestinationPort Destination port[-port] criteria an incoming packet must have
to match this rule.
Protocol networkRulesStatusProtocol Protocol criteria an incoming packet must have to match this
rule.
Connection State networkRulesStatusConnectionState Connection state associated with the incoming packet.
Source Port sNatRulesStatusSourcePort Source port[-port] criteria an incoming packet must have to
dNatRulesStatusSourcePort match this rule.
Destination Port sNatRulesStatusDestinationPort Destination port[-port] criteria an incoming packet must have
dNatRulesStatusDestinationPort to match this rule.
Protocol sNatRulesStatusProtocol Protocol criteria an incoming packet must have to match this
dNatRulesStatusProtocol rule.
New Address sNatRulesStatusNewAddress New address[:port] applied to the source of the packet.
dNatRulesStatusNewAddress
Host Sub-Page
Automatic IPv4 config automaticConfigurationInterface The network interface that provides the automatic
source network: configuration used by the unit (e.g.: Default gateway, DNS
servers, NTP server, etc.).
Automatic IPv6 config ipv6AutomaticConfigurationInterface The network interface that provides the IPv6 automatic
source network configuration (Default Router, domain name, DNS servers
and NTP server) used by the unit.
IPv4
IPv6
Synchronization Period sntpSynchronizationPeriod Time interval between system time synchronization cycles.
Synchronization Period sntpSynchronizationPeriodOnError Time interval between retries after an unsuccessful request
On Error to the SNTP server.
Static Time Zone staticTimeZone Specifies the time zone in which the system is located.
Interfaces Sub-Page
Link networkInterfacesLinkName Name of the link interface associated with the network
interface.
Static IP Address networkInterfacesStaticIpAddr IPv4 address and network mask of the network interface.
Static Default Router networkInterfacesStaticDefaultRouter IPv4 address of the default gateway for the network
interface when the ConnectionType is set to ipStatic.
Service Name pppServiceName Name of the service requested to the access concentrator
when establishing the next PPPoE connection.
User Name pppIdentity Name that identifies the system to the PPP peer during the
authentication process.
Password pppSecret Secret that identifies the system to the PPP peer during the
authentication process.
Network Interface NetworkInterface The network interface name on which LLDP should be
enabled.
Override Network OverrideNetworkPolicyEnable Enables the LLDP-MED protocol override of the VLAN ID,
Policy User Priority and DiffServ values.
Certificate Validation eapCertificationValidation Level of validation used by the device to authenticate the
IEEE 802.1x EAP-TLS peer's certificate. This variable
controls also the criteria used to select the host certificate
sent during the authentitication handshake
VLAN Sub-Page
Field Name SNMP Variable Description
Link vlanLinkName Name of the Ethernet link over which the VLAN interface is
built.
Default User Priority vlanDefaultUserPriority Default User Priority value the interface uses when tagging
packets.
vlanDelete Deletes the VLAN interface and removes it from the system.
Config Modified configModifiedStatus Shows whether the configuration of the local firewall was
modified without being applied.
Default Policy defaultPolicy Action taken when a packet doesn't match any rules.
IP Routing Sub-Page
Field Name SNMP Variable Description
Config Modified configModifiedStatus Shows whether or not the Network Address Translation
configuration has been modified without being applied.
Source Address advancedIpRoutesSourceAddress Specifies the source IP address criteria an incoming packet
must have to match this rule.
Source Link advancedIpRoutesSourceLink Specifies the source link criteria an incoming packet must
have to match this rule.
Gateway staticIpRoutesGateway Specifies the IP address of the gateway used by the route.
insertStaticIpRoute (command) Inserts a new row at the end of the StaticIpRoutes table.
Config Modified configModifiedStatus Shows whether the configuration of the network firewall was
modified without being applied.
Default Policy defaultPolicy Action taken when a packet does not match any rules.
Connection State networkRulesConnectionState Connection state associated with the incoming packet.
NAT Sub-Page
Field Name SNMP Variable Description
Config Modified configModifiedStatus Shows whether or not the Network Address Translation
configuration has been modified without being applied.
New Address sNatRulesNewAddress New address applied to the destination of the packet.
New Address dNatRulesNewAddress New address applyed to the destination of the packet.
Lease Time leaseTimesInfoDefault Indicates the subnet's current default lease time in seconds.
DNS (Option 6)
Primary SNTP Host ntpServersInfoNtp1 Indicates the subnets' first NTP server.
Secondary SNTP Host ntpServersInfoNtp2 Indicates the subnets' second NTP server.
Third SNTP Host ntpServersInfoNtp3 Indicates the subnets' third NTP server.
Fourth SNTP Host ntpServersInfoNtp4 Indicates the subnets' fourth NTP server.
Automatic subnetsAutomaticConfigurationInterface Interface that will provide the automatic configuration to this
Configuration Interface subnet.
Subnet Specific specificLeaseTimesEnableConfig Defines the lease time configuration to use for a specific
subnet.
Lease Time defaultLeaseTime Specifies the lease time (in seconds) default setting for all
specificLeaseTimesLeaseTime subnets.
Specifies the subnet's specific lease time in seconds.
Subnet Specific specificDomainNamesEnableConfig Defines the domain name configuration to use for this
specific subnet.
Domain Name defaultStaticDomainName Default static domain name for all subnets.
specificDomainNamesStaticName Static Domain Name Configuration.
DNS (Option 6)
Subnet Specific specificDnsServersEnableConfig Defines the DNS servers configuration to use for a specific
subnet.
Configuration Source defaultDnsServersConfigSource Default configuration source for the DNS servers of all
specificDnsServersConfigSource subnets.
DNS servers specific configuration source for the subnet.
Primary DNS specificDnsServersStaticDns1 IP address of the first DNS server of the subnet.
Secondary DNS: specificDnsServersStaticDns2 IP address of the second DNS server of the subnet.
Third DNS specificDnsServersStaticDns3 IP address of the third DNS server of the subnet
Fourth DNS specificDnsServersStaticDns4 IP address of the fourth DNS server of the subnet.
Subnet Specific specificNtpServersEnableConfig Defines the NTP servers configuration to use for a specific
subnet.
Configuration Source defaultNtpServersConfigSource Default configuration source for the NTP servers of all
specificNtpServersConfigSource subnets.
NTP servers specific configuration source for the subnet.
Primary NTP specificNtpServersStaticNtp1 IP address of the first NTP server of the subnet.
Secondary NTP specificNtpServersStaticNtp2 IP address of the second NTP server of the subnet.
Third NTP specificNtpServersStaticNtp3 IP address of the third NTP server of the subnet.
Fourth NTP specificNtpServersStaticNtp4 IP address of the fourth NTP server of the subnet.
Subnet Specific specificNbnsServersEnableConfig Defines the NBNS servers configuration to use for a specific
subnet.
Primary NBNS specificNbnsServersStaticNbns1 IP address of the first NBNS server of the subnet.
Secondary NBNS specificNbnsServersStaticNbns2 IP address of the second NBNS server of the subnet.
Third NBNS specificNbnsServersStaticNbns3 IP address of the third NBNS server of the subnet.
Fourth NBNS specificNbnsServersStaticNbns4 IP address of the fourth NBNS server of the subnet.
QoS Sub-Page
Differentiated Service Field Configuration Section
Field Name SNMP Variable Description
Default DiffServ (IPv4) defaultDiffServ Default Differentiated Services value used by the unit for all
generated packets.
Default Traffic Class defaultTrafficClass Default Traffic Class value used by the unit for all generated
(IPv6) IPv6 packets.
Default User Priority ethernet8021QTaggingDefaultUserPriority Default User Priority value the interface uses when tagging
packets.
DiffServ (IPv4) serviceClassesDiffServ Differentiated Services value for a specific service class.
Traffic Class (IPv6) serviceClassesTrafficClass Default Traffic Class value used in IPv6 packets.
Physical Link linkBandwidthControlLinkName Name of the Ethernet link over which the bandwidth
limitation is applied.
Egress Limit linkBandwidthControlEgressLimit Indicates the bandwidth limitation for the selected link
interface.
POTS Page
Status Sub-Page
State lineState The current call control state for this channel.
Config Sub-Page
Caller ID Transmission CallerIdTransmission Allows selecting the transmission type of the caller ID.
Vocal Unit Information VocalUnitInformation Determines whether or not the unit's IP or MAC address or
firmware version number can be acquired using the *#*0,
*#*1, and *#*8 digit maps respectively.
Line Supervision Mode fxsLineSupervisionMode Determines how the power drop and line polarity are used to
signal the state of a line.
Disconnect Delay fxsDisconnectDelay Determines whether or not call clearing occurs as soon as
the called user is the first to hang up a received call.
Auto Cancel Timeout fxsDefaultAutoCancelTimeout Time, in seconds, the endpoint rings before the call is
automatically cancelled.
Inband Ringback fxsInbandRingback Determines whether or not the FXS endpoint needs to
generate a ringback for incoming ringing call.
Shutdown Behavior fxsShutdownBehavior Determines the FXS endpoint behavior when it becomes
shut down.
Power Drop on fxsPowerDropOnDisconnectDuration Determines the power drop duration that is made at the end
Disconnect Duration of a call when the call is disconnected by the remote party.
Service Activation FxsServiceActivation Selects the method used by the user to activate
supplementary services like call hold, second call, call
waiting, call transfer and conference call.
Country Override Loop fxsCountryCustomizationLoopCurrent Loop current generated by the FXS port in ma.
Current
Country Override Flash fxsCountryCustomizationFlashHookDetectionR The range in which the hook switch must remain pressed to
Hook Detection Range ange perform a flash hook.
Activation DTMF Map fxsBypassActivationDtmfMap Specifies the DTMFs to signal to enable the bypass.
Deactivation Timeout fxsBypassDeactivationTimeout Specifies the delay to wait before deactivating the bypass
after an on hook if the bypass is activated on demand.
SIP Page
Gateways Sub-Page
Network Interface gatewayStatusNetworkInterface Network on which the gateway listens for incoming SIP
traffic.
Port gatewayStatusPort Port on which the gateway listens for incoming unsecure
SIP traffic.
Secure Port gatewayStatusSecurePort Port on which the gateway listens for incoming secure SIP
traffic.
Name gatewayName Name of the SIP gateway. It identifies the gateway in other
tables.
Network Interface gatewayNetworkInterface Network on which the gateway listens for incoming SIP
traffic.
Port gatewayPort Port on which the gateway listens for incoming unsecure
SIP traffic.
Secure Port gatewayStatusSecurePort Port on which the gateway listens for incoming secure SIP
traffic.
Servers Sub-Page
Field Name SNMP Variable Description
Local Port tlsPersistentConnectionStatusLocalPort Local port used by the TLS persistent connection.
Configured Remote tlsPersistentConnectionStatusRemoteHost The remote host used to establish the TLS persistent
Host connection.
Remote IP Address tlsPersistentConnectionStatusRemoteAddress The resolved IP address of the remote host used to
establish the TLS persistent connection.
Outbound Proxy Host defaultStaticProxyOutboundHost SIP outbound proxy server FQDN and port.
Gateway Name gwSpecificRegistrationGatewayName String that identifies a SIP gateway in other tables.
Gateway Specific gwSpecificRegistrationEnableConfig Defines the configuration to use for a specific SIP gateway.
Registrar Host gwSpecificRegistrationServerHost SIP registrar server FQDN and port for a specific SIP
gateway.
Gateway Name gwSpecificProxyGatewayName String that identifies a SIP gateway in other tables.
Gateway Specific gwSpecificProxyEnableConfig Defines the configuration to use for a specific SIP gateway.
Proxy Host gwSpecificProxyHomeDomainHost SIP proxy server FQDN and port for a specific SIP gateway.
Outbound Proxy Host gwSpecificProxyOutboundHost SIP outbound proxy server FQDN and port for a specific SIP
gateway.
Keep Alive Method sipKeepAliveMethod Method used to perform the SIP keep alive.
Keep Alive Interval sipKeepAliveInterval Defines the interval, in seconds, at which SIP OPTIONS are
sent to verify the server status.
Keep Alive Destination sipKeepAliveDestination Determines the behaviour of the device when performing
the keep alive action.
Gateway Name gwKeepAliveAlternateDestinationGatewayNam String that identifies a SIP gateway in other tables.
e
Alternate Target gwKeepAliveAlternateDestinationAlternateDesti Alternate destination target server FQDN and port for a
nation specific SIP gateway.
Registrations Sub-Page
Registrar registrationStatusRegistrar The host of the registrar currently used by the registration.
Gateway Name mwiStatusGatewayName The SIP gateway used for this subscription.
Messaging Host mwiStatusMessagingHost Messaging server FQDN and port used to subscribe the
event state.
Registrar registrationStatusRegistrar The host of the registrar currently used by the registration.
User Name userAgentUserName String that uniquely identifies this endpoint in the domain.
Gateway Name userAgentGatewayName Selects on which SIP gateway the user configuration is
applied.
User Name registrationUsersUsername String that uniquely identifies this user in the domain.
Gateway Name registrationUsersGatewayName Selects on which SIP gateway the user configuration is
applied.
Default Registration defaultRegistrationRefreshTime Defines the time, relative to the end of the registration, at
Refresh Time which a registered unit will begin updating its registration.
Authentication Sub-Page
Field Name SNMP Variable Description
Validate Realm authenticationValidateRealm Defines whether or not the current credentials are valid for
any realm.
User Name authenticationUserName String that uniquely identifies this entity in the realm.
Transport Sub-Page
Add SIP Transport in transportConfigRegistrationEnable Indicates whether or not the SIP Gateway must include its
Registration supported transports in its registrations.
Add SIP Transport in transportConfigContactEnable Indicates whether or not the SIP Gateway must include its
Contact Header supported transport in all SIP messages that have the
contact header, except for the REGISTER message.
Persistent TLS Base transportTlsPersistentBasePort Base port used to establish TLS persistent connections with
Port SIP servers when the TLS transport is enabled.
Persistent TLS Retry transportTlsPersistentRetryInterval Time interval before retrying the establishment of a TLS
Interval persistent connection.
TLS Trusted Certificate transportTlsCertificateTrustLevel Defines how a peer certificate is considered trusted for a
Level TLS connection.
TCP Connect Timeout interopTcpConnectTimeout Defines the maximum time, in seconds, the unit should try to
establish a TCP or TLS connection to SIP hosts.
Interop Sub-Page
SIP Error Code behaviorOnT38InviteNotAcceptedSipErrorCode SIP code in the error response to an INVITE for T.38 fax.
Behavior behaviorOnT38InviteNotAcceptedBehavior Behavior of the device when receiving a SIP error response
to an INVITE for T.38 fax.
Secure Header interopSiemensTransportHeaderEnable Add the 'x-Siemens-Call-Type' header to the SIP packets.
Default Username interopDefaultUsernameValue Username to use when the username is empty or undefined.
Value
OPTIONS Method interopSipOptionsMethodSupport Determines the behaviour of the device when answering a
Support SIP OPTIONS request.
Ignore OPTONS on no InteropIgnoreSipOptionsOnNoUsableEndpoints Determines whether or not the SIP OPTIONS requests
usable endpoints should be ignored when all endpoints are unusable.
Behavior On Machine InteropBehaviorOnMachineDetection Specifies the SIP device behavior when a machine is
Detection detected during a call.
Registration Contact InteropRegistrationContactMatching Specifies the matching behaviour for the contact header
Matching received in positive responses to REGISTER requests sent
by the unit.
Transmission Timeout interopTransmissionTimeout Changes the time to wait for a response or an ACK before
considering a transaction timed out.
Answer Codec answerCodecNegotiation Defines the codec negotiation rule when generating a SDP
Negotiation answer.
Enforce Offer Answer interopEnforceOfferAnswerModel Determines whether or not the unit requires strict adherence
Model to RFC 3264 from the peer when negotiating capabilities for
the establishment of a media session.
Allow Less Media in interopAllowLessMediaInResponse Selects whether or not the unit enables the mapping
Response between the "+" prefix of the username and the "type of
number" property.
Allow Media interopAllowMediaReactivationInAnswer Determines the unit behaviour when receiving a SDP
Reactivation in Answer answer activating a media that had been previously
deactivated in the offer.
Allow Audio and Image interopAllowAudioAndImageNegotiation Determines the unit behaviour when offering media or
Negotiation answering to a media offer with audio and image
negotiation.
Allow Multiple Active interopAllowMultipleActiveMediaInAnswer Determines the behaviour of the device when answering a
Media in Answer request offering more than one active media.
Other
On Hold SDP Stream interopOnHoldSdpStreamDirection Define how to set the direction attribute and the connection
Direction in Answer address in the SDP when answering a hold offer with the
direction attribute “sendonly”.
Certificate Validation InteropTlsCertificateValidation Specifies which level of security is used to validate the peer
certificate.
Map Plus to TON interopMapPlusToTonInternational Defines the behaviour of the unit when receiving less media
International announcements in the response than in the offer.
Ignore Plus in interopIgnorePlusInUsername Determines whether or not the plus character (+) is ignored
Username when attempting to match a challenge username with
usernames in the Authentication table.
Escape Pound (#) in interopEscapePoundInSipUriUsername Determines whether or not the pound character (#) must be
SIP URI Username escaped in the username part of a SIP URI.
Misc Sub-Page
Penalty Box Activation penaltyBoxEnable Indicates whether the unit uses the penalty box feature.
Penalty Box Time penaltyBoxTime Amount of time that a host spends in the penalty box.
Reason Header ReasonHeaderSupport Indicates whether or not the unit uses the SIP reason
Support header.
Referred-By Support ReferredByHeader Indicates how the Referred-By header is used when
participating in a transfer.
PRACK Section
UAS PRACK Support uasPrackSupport Determines the support of RFC 3262 (PRACK) when acting
as as user agent server.
UAC PRACK Support uacPrackSupport Determines the support of RFC 3262 (PRACK) when acting
as as user agent client.
Minimum Expiration defaultSessionTimerMinimumExpirationDelay Minimum value for the periodical session refreshes.
Delay (s)
Maximum Expiration defaultSessionTimerMaximumExpirationDelay Suggested maximum time for the periodical session
Delay (s): refreshes.
Session Refresh sessionRefreshRequestMethod Selects the method used for sending Session Refresh
Request Method Requests.
Gateway Name gatewayName Name of the SIP gateway. It identifies the gateway in other
tables.
SIP Domain Override gatewayDomain Controls whether or not to override the SIP domain used.
Blind Transfer Method BlindTransferMethod Selects the SIP method to use in a blind transfer scenario.
Diversion Section
Method diversionConfigMethod Selects the SIP method used to receive/send call diversion
information in an INVITE.
Gateway Name gwEventHandlingGatewayName String that identifies a SIP gateway in other tables.
Username in Request- defaultUsernameInRequestUriEnable Indicates whether or not the unit adds the username in the
URI gwSpecificMwiUsernameInRequestUriEnable request URI of MWI SUBSCRIBE requests.
Gateway Name GatewayName String that identifies a SIP gateway in other tables.
AOC-D Support AocDSupport Specifies whether AOC (D)uring a call is supported for a
specific SIP gateway.
AOC-E Support AocESupport Specifies whether AOC at the (E)nd of a call is supported for
a specific SIP gateway.
Media Page
CODECS Sub-Page
Field Name SNMP Variable Description
CODEC Section
epSpecificCodecG711AlawEnableConfig
epSpecificCodecG711MulawEnableConfig
epSpecificCodecG723EnableConfig
epSpecificCodecG726r16kbpsEnableConfig
epSpecificCodecG726r24kbpsEnableConfig
epSpecificCodecG726r32kbpsEnableConfig
epSpecificCodecG726r40kbpsEnableConfig
Endpoint Specific Configuration to use for a specific endpoint.
epSpecificCodecG729EnableConfig
epSpecificCodecT38EnableConfig
epSpecificCodecClearModeEnableConfig
epSpecificCodecClearChannelEnableConfig
epSpecificCodecXCCDEnableConfig
defaultCodecG711AlawVoiceEnable
epSpecificCodecG711AlawVoiceEnable
defaultCodecG711MulawVoiceEnable
epSpecificCodecG711MulawVoiceEnable
defaultCodecG723VoiceEnable
epSpecificCodecG723VoiceEnable
defaultCodecG726r16kbpsVoiceEnable
epSpecificCodecG726r16kbpsVoiceEnable
defaultCodecG726r24kbpsVoiceEnable
epSpecificCodecG726r24kbpsVoiceEnable
defaultCodecG726r40kbpsVoiceEnable
epSpecificCodecG726r40kbpsVoiceEnable
defaultCodecG729VoiceEnable
epSpecificCodecG729VoiceEnable
defaultCodecClearModeVoiceEnable
epSpecificCodecClearModeVoiceEnable
defaultCodecClearChannelVoiceEnable
epSpecificCodecClearChannelVoiceEnable
defaultCodecXCCDVoiceEnable
epSpecificCodecXCCDVoiceEnable
defaultCodecG711AlawDataEnable
epSpecificCodecG711AlawDataEnable
defaultCodecG711MulawDataEnable
epSpecificCodecG711MulawDataEnable
defaultCodecG726r32kbpsDataEnable
epSpecificCodecG726r32kbpsDataEnable
defaultCodecG726r40kbpsDataEnable
epSpecificCodecG726r40kbpsDataEnable Indicates whether the codec can be selected for data
Data
transmission.
defaultCodecT38DataEnable
epSpecificCodecT38DataEnable
defaultCodecClearModeDataEnable
epSpecificCodecClearModeDataEnable
defaultCodecClearChannelDataEnable
epSpecificCodecClearChannelDataEnable
defaultCodecXCCDDataEnable
epSpecificCodecXCCDDataEnable
Mapping Type defaultCodecVsBearerCapabilitiesMappingMap The ITC value to be set in the outgoing SETUP when the
pingType incoming INVITE's priority codec matches
defaultCodecVsBearerCapabilitiesMappingCodec.
Voice Transmission defaultCodecG711AlawVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG711AlawVoiceEnable transmission.
Voice Priority defaultCodecG711AlawVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG711AlawVoicePriority
Data Transmission defaultCodecG711AlawDataEnable Indicates whether the codec can be selected for data
epSpecificCodecG711AlawDataEnable transmission.
Data Priority defaultCodecG711AlawDataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecG711AlawDataPriority
Voice Transmission defaultCodecG711MulawVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG711MulawVoiceEnable transmission.
Voice Priority defaultCodecG711MulawVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG711MulawVoicePriority
Data Transmission defaultCodecG711MulawDataEnable Indicates whether the codec can be selected for data
epSpecificCodecG711MulawDataEnable transmission.
Data Priority defaultCodecG711MulawDataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecG711MulawDataPriority
G.723 Section
Voice Transmission defaultCodecG723VoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG723VoiceEnable transmission.
Voice Priority defaultCodecG723VoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG723VoicePriority
Voice Transmission defaultCodecG726r16kbpsVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG726r16kbpsVoiceEnable transmission.
Voice Priority defaultCodecG726r16kbpsVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG726r16kbpsVoicePriority
Payload Type defaultCodecG726r16kbpsPayloadType RTP dynamic payload type used in an initial offer.
epSpecificCodecG726r16kbpsPayloadType
Voice Transmission defaultCodecG726r24kbpsVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG726r24kbpsVoiceEnable transmission.
Voice Priority defaultCodecG726r24kbpsVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG726r24kbpsVoicePriority
Payload Type defaultCodecG726r24kbpsPayloadType RTP dynamic payload type used in an initial offer.
epSpecificCodecG726r24kbpsPayloadType
Voice Transmission defaultCodecG726r32kbpsVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG726r32kbpsVoiceEnable transmission.
Voice Priority defaultCodecG726r32kbpsVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG726r32kbpsVoicePriority
Data Transmission defaultCodecG726r32kbpsDataEnable Indicates whether the codec can be selected for data
epSpecificCodecG726r32kbpsDataEnable transmission.
Data Priority defaultCodecG726r32kbpsDataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecG726r32kbpsDataPriority
Payload Type defaultCodecG726r32kbpsPayloadType RTP dynamic payload type used in an initial offer.
epSpecificCodecG726r32kbpsPayloadType
Voice Transmission defaultCodecG726r40kbpsVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG726r40kbpsVoiceEnable transmission.
Voice Priority defaultCodecG726r40kbpsVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG726r40kbpsVoicePriority
Data Transmission defaultCodecG726r40kbpsDataEnable Indicates whether the codec can be selected for data
epSpecificCodecG726r40kbpsDataEnable transmission.
Data Priority defaultCodecG726r40kbpsDataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecG726r40kbpsDataPriority
Payload Type defaultCodecG726r40kbpsPayloadType RTP dynamic payload type used in an initial offer.
epSpecificCodecG726r40kbpsPayloadType
G.729 Section
Voice Transmission defaultCodecG729VoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecG729VoiceEnable transmission.
Voice Priority defaultCodecG729VoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecG729VoicePriority
T.38 Section
Enable defaultCodecT38DataEnable If enabled, the T.38 protocol is used for fax transmission.
epSpecificCodecT38DataEnable
Priority defaultCodecT38DataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecT38DataPriority
Detection Threshold defaultCodecT38DetectionThreshold Sets the T.38 input signal detection threshold.
epSpecificCodecT38DetectionThreshold
Frame Redundancy defaultCodecT38FinalFramesRedundancy Defines the number of times T.38 packets will be
Level retransmitted.
No Signal Timeout defaultCodecT38NoSignalTimeout The period, in seconds, at which no-signal packets are sent
during a T.38 transmission, in the absence of valid data.
Voice Transmission defaultCodecClearModeVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecClearModeVoiceEnable transmission.
Voice Priority defaultCodecClearModeVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecClearModeVoicePriority
Data Transmission defaultCodecClearModeDataEnable Indicates whether the codec can be selected for data
epSpecificCodecClearModeDataEnable transmission.
Data Priority defaultCodecClearModeDataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecClearModeDataPriority
Payload Type defaultCodecClearModePayloadType RTP dynamic payload type used in an initial offer.
epSpecificCodecClearModePayloadType
Voice Transmission defaultCodecClearChannelVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecClearChannelVoiceEnable transmission.
Voice Priority defaultCodecClearChannelVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecClearChannelVoicePriority
Data Transmission defaultCodecClearChannelDataEnable Indicates whether the codec can be selected for data
epSpecificCodecClearChannelDataEnable transmission.
Data Priority defaultCodecClearChannelDataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecClearChannelDataPriority
Payload Type defaultCodecClearChannelPayloadType RTP dynamic payload type used in an initial offer.
epSpecificCodecClearChannelPayloadType
X CCD Section
Voice Transmission defaultCodecXCCDVoiceEnable Indicates whether the codec can be selected for voice
epSpecificCodecXCCDVoiceEnable transmission.
Voice Priority defaultCodecXCCDVoicePriority Priority of this voice codec versus the other voice codecs.
epSpecificCodecXCCDVoicePriority
Data Transmission defaultCodecXCCDDataEnable Indicates whether the codec can be selected for data
epSpecificCodecXCCDDataEnable transmission.
Data Priority defaultCodecXCCDDataPriority Priority of this data codec versus the other data codecs.
epSpecificCodecXCCDDataPriority
Payload Type defaultCodecXCCDPayloadType RTP dynamic payload type used in an initial offer.
epSpecificCodecXCCDPayloadType
Security Sub-Page
Security Section
RTP
Mode defaultSecurityRtpMode Defines the RTP payload mode (secure or not secure).
epSpecificSecurityRtpMode
Key Management defaultSecurityKeyManagement Defines the key management protocol for SRTP.
epSpecificSecurityKeyManagement
T.38
Allow unsecure T.38 allowUnsecureT38WithSrtp Enables T38 even if the call has been established previously
with secure RTP in SRTP.
RTP Stats
Period Beginning lastPeriodsStatsPeriodBeginning Date and time of the collection period beginning.
Period End lastPeriodsStatsPeriodEnd Date and time of the collection period end.
Packets Lost lastPeriodsStatsPacketsLost Number of packets lost during the collection period.
Connection Statistics
Collection Period statsCollectionPeriodDuration Specifies the collection period duration (in minutes).
(minutes)
Misc Sub-Page
Data Call defaultVbdJitterBufferType Algorithm to use for managing the jitter buffer during a call.
Playout Type epSpecificCustomVbdJitterBufferType
Data Call defaultVbdJitterBufferCustomMinLength The delay the jitter buffer tries to maintain.
Minimum epSpecificCustomVbdMinLength
Data Call defaultVbdJitterBufferCustomNomLength The delay the jitter buffer uses when a call begins.
Nominal epSpecificCustomVbdNomLength
Data Call defaultVbdJitterBufferCustomMaxLength The highest delay the jitter buffer is allowed to introduce.
Maximum epSpecificCustomVbdMaxLength
SIP Transport Method interopDtmfTransportMethod Defines the method used to transport DTMFs out-of-band
over the SIP protocol
Payload Type defaultDtmfTransportPayloadType RTP dynamic payload type used for telephone-event in an
epSpecificDtmfTransportPayloadType initial offer.
CNG Tone Detection defaultMachineDetectionCngToneDetection Enables fax calling tone (CNG tone) detection.
specificMachineDetectionCngToneDetection
Behavior on CED Tone defaultMachineDetectionBehaviorOnCedToneD Defines the behavior of the unit upon detection of a CED
Detection etection tone.
specificMachineDetectionBehaviorOnCedTone
Detection
Telephony Page
First DTMF Timeout dtmfMapTimeoutFirstDtmf Time the user has to enter the first DTMF after the dial tone.
Inter DTMF Timeout dtmfMapTimeoutInterDtmf Value of the “T” DTMF in the DTMF map strings.
Completion Timeout dtmfMapTimeoutCompletion Total time the user has to dial the DTMF sequence.
DTMF Maps Digit DtmfMapDigitDetection Determines when a digit is processed through the DTMF
Detection (FXO/FXS) maps.
DTMF Map callDtmfMapAllowedDtmfMap DTMF map that is considered valid when dialed.
Enable callDtmfMapRefuseEnable If enabled, this DTMF map is recognised and refused only if
it is also valid.
Apply to callDtmfMapRefuseApplyTo Sets the entity to which apply the DTMF map.
DTMF Map callDtmfMapRefuseDtmfMap DTMF map that is considered invalid when dialed.
First DTMF Timeout EpSpecificDtmfMapTimeoutFirstDtmf Time the user has to enter the first DTMF after the dial tone.
Inter DTMF Timeout EpSpecificDtmfMapTimeoutInterDtmf Value of the 'T' DTMF in the DTMF map strings.
Completion Timeout EpSpecificDtmfMapTimeoutCompletion Total time the user has to dial the DTMF sequence.
Endpoint Specific epSpecificForwardOnBusyEnableConfig Defines the configuration to use for a specific endpoint.
Allow Activation via defaultForwardOnBusyEnable Enables/Disables the call forward on busy service.
Handset epSpecificForwardOnBusyEnable
DTMF Map Activation defaultForwardOnBusyDtmfMapActivation DTMF map the user can dial to enable the application of the
service.
DTMF Map defaultForwardOnBusyDtmfMapDeactivation DTMF map the user can dial to disable the application of the
Deactivation service.
Forwarding Address: forwardOnBusyConfigForwardingAddress Address or telephone number to which the user wants to
forward calls.
Endpoint Specific epSpecificForwardNoAnswerEnableConfig Defines the configuration to use for a specific endpoint.
Allow Activation via defaultForwardNoAnswerEnable Enables/Disables the call forward on no answer service.
Handset epSpecificForwardNoAnswerEnable
DTMF Map Activation defaultForwardNoAnswerDtmfMapActivation DTMF map the user can dial to enable the application of the
service.
DTMF Map defaultForwardNoAnswerDtmfMapDeactivation DTMF map the user can dial to disable the application of the
Deactivation service.
Forwarding Address: forwardNoAnswerConfigForwardingAddress Address or telephone number to which the user wants to
forward calls.
Endpoint Specific epSpecificForwardUnconditionalEnableConfig Defines the configuration to use for a specific endpoint.
Allow Activation via defaultForwardUnconditionalEnable Enables/Disables the unconditional call forward service.
Handset epSpecificForwardUnconditionalEnable
DTMF Map Activation defaultForwardUnconditionalDtmfMapActivation DTMF map the user can dial to enable the application of the
service.
DTMF Map defaultForwardUnconditionalDtmfMapDeactivati DTMF map the user can dial to disable the application of the
Deactivation on service.
Forwarding Address: forwardUnconditionalConfigForwardingAddress Address or telephone number to which the user wants to
forward calls.
Services Sub-Page
Field Name SNMP Variable Description
Service Section
General Configuration
Endpoint Specific epSpecificCallEnableConfig Defines the configuration to use for a specific endpoint.
Automatic Call
Endpoint Specific epSpecificAutoCallEnableConfig Defines the configuration to use for a specific endpoint.
Automatic Call defaultAutoCallEnable Enables/Disables the automatic call service. This service
Activation epSpecificAutoCallEnable provides a 'redphone'-like experience.
Automatic Call Target defaultAutoCallTargetAddress Address or telephone number that the user wants to
epSpecificAutoCallTargetAddress automatically call.
Call Completion
Endpoint Specific epSpecificCallCompletionEnableConfig Defines the configuration to use for a specific endpoint.
Allow CCBS Activation defaultCallCompletionBusySubscriberEnable Enables/Disables the call completion busy subscriber
Via Handset epSpecificCallCompletionBusySubscriberEnabl (CCBS) service.
e
Allow CCNR Activation defaultCallCompletionNoResponseEnable Enables/Disables the call completion no response (CCNR)
Via Handset epSpecificCallCompletionNoResponseEnable service.
CCBS DTMF Map defaultCallCompletionBusySubscriberDtmfMap DTMF map the user can dial to enable the application of the
Activation Activation call completion busy subscriber (CCBS) service.
CCNR DTMF Map defaultCallCompletionNoResponseDtmfMapAct DTMF map the user can dial to enable the application of the
Activation ivation call completion no response (CCNR) service.
DTMF Map defaultCallCompletionDtmfMapDeactivation DTMF map the user can dial to disable the application of the
Deactivation call completion busy subscriber (CCBS) and call completion
no response (CCNR) services.
Expiration Timeout defaultCallCompletionExpirationTimeout Defines the delay after the call completion activation to
automatically deactivate the call completion if the call is not
completed.
Method defaultCallCompletionMethod Selects the call completion method to detect that the call
completion destination is ready to complete the call.
Auto Reactivate Delay defaultCallCompletionAutoReactivateDelay Defines the minimal delay to wait before executing a call
completion after its activation.
Early-Media Behaviour defaultCallCompletionEarlyMediaBehaviour Defines how the call completion service needs to interpret
the reception of a progress message with early media.
Polling Interval defaultCallCompletionPollingInterval Defines the delay between the calls to the call completion
target used for the polling mechanism.
Call Transfer
Endpoint Specific epSpecificTransferEnableConfig Defines the configuration to use for a specific endpoint.
Call Waiting
Endpoint Specific epSpecificCallWaitingEnableConfig Defines the configuration to use for a specific endpoint.
Cancel DTMF Map defaultCallWaitingCancelDtmfMap Default DTMF Map to Cancel the Call Waiting Service
Conference
Endpoint Specific epSpecificConferenceEnableConfig Defines the configuration to use for a specific endpoint.
Delayed Hotline
Endpoint Specific epSpecificDelayedHotlineEnableConfig Defines the configuration to use for a specific endpoint.
Delayed Hotline defaultDelayedHotlineCondition Selects the condition(s) that activate the delayed hotline.
Condition epSpecificDelayedHotlineCondition
Delayed Hotline Target defaultDelayedHotlineTargetAddress Address or telephone number of the target of the delayed
epSpecificDelayedHotlineTargetAddress hotline.
Direct IP Address Call defaultCallAllowDirectIp Enables/Disables the direct IP address call service.
Activation
Hold
Endpoint Specific epSpecificHoldEnableConfig Defines the configuration to use for a specific endpoint.
Second Call
Endpoint Specific epSpecificSecondCallEnableConfig Defines the configuration to use for a specific endpoint.
Override Current Tone countryCustomizationToneOverride Allows overriding the default country tone setting.
Values
Frequencies
Value
countryToneStatusPattern Pattern description of the currently used tone for the country
Power
Loop Count
State
On/Off
Frequencies
countryToneStatusPattern Pattern description of the currently used tone for the country
Duration
Loop
Next State
Frequencies
Value
countryCustomizationTonePattern Pattern description of the custom tone.
Power
Loop Count
State
On/Off
Frequencies
countryCustomizationTonePattern Pattern description of the custom tone.
Duration
Loop
Next State
Transfer (command) Saves the settings and transfers the MP3 file now.
CancelTransfer (command) Saves the settings and stops a file transfer in progress.
Status Section
Last Transfer Result lastTransferStatus Status of the last file transfer attempt.
Last Successful lastTransferDateTime Date and time of the last successful music file transfer.
Transfer
Streaming musicOnHoldStreamingEnable Indicate whether or not the unit should play music when
being put on hold.
URL fileUrl URL to a MP3 file which will be loaded at unit startup and
reloaded every time the ReloadInterval elapsed.
User Name username When authentication is required by the remote file server,
this variable will be used as the username.
Reload Interval reloadInterval Time, in hours, between attempts to load the MP3 file.
Misc Sub-Page
Country Section
Syslog Remote Host syslogRemoteHost Host name and port number of the device that archives CDR
log entries.
Syslog Format syslogFormat Specifies the format of the syslog Call Detail Record.
Syslog Facility syslogFacility Syslog facility used by the unit to route the Call Detail
Record messages.
Status Sub-Page
Field Name SNMP Variable Description
Config Modified configModifiedStatus Shows whether the configuration of the call routing was
modified without being applied.
Route Section
Properties Criteria routeStatusPropertiesCriteria Call properties criteria to match to apply the route.
Signaling Properties routeStatusSignalingProperties Name of the signaling properties to apply to the call.
Mapping Section
Criteria mappingTypeStatusCriteria Expression or call property to compare with the call and
mappingExpressionStatusCriteria match in order to apply the properties manipulation.
Hunt Section
Timeout huntStatusTimeout Maximal time allowed to the destination to handle the call.
Destination Host sipRedirectStatusDestination Host address inserted in the Moved Temporarily response.
Route Section
Properties Criteria routePropertiesCriteria Call properties criteria to match to apply the route.
Signaling Properties routeSignalingProperties Name of the signaling properties to apply to the call.
Destination routeDestination Destination to apply to the call if the call matches the criteria.
Criteria mappingTypeCriteria Call properties that the service must compare with the call
and match in order to apply the properties manipulation.
Config Status mappingTypeConfigStatus It indicates whether the configuration of the row is valid.
Criteria mappingExpressionExpressionCriteria Expression to compare with the call and match in order to
apply the properties manipulation.
Config Status mappingExpressionConfigStatus It indicates whether the configuration of the row is valid.
Allow 180 with SDP signalingPropertiesAllow180Sdp Enables/Disables the 180 with SDP allowed.
Allow 183 without SDP signalingPropertiesAllow183NoSdp Enables/Disables the 183 without SDP allowed.
SIP Headers signalingPropertiesSipHeadersTranslation Name of the SIP headers translation to apply to the call.
Translations
Call Properties signalingPropertiesCallPropertiesTranslation Name of the call properties translation to apply to the call.
Translations
Name sipHeadersTranslationName Name of the SIP headers translation defined by this row.
SIP Header sipHeadersTranslationSipHeader Sets which SIP header is modified by this translation.
Built From sipHeadersTranslationBuiltFrom Sets what information is used to build the selected SIP
header.
Name callPropertiesTranslationName Name of the call properties translation defined by this row.
Call Property callPropertiesTranslationCallProperty Sets which call property is modified by this translation.
Built From callPropertiesTranslationBuiltFrom Sets what information is used to build the selected call
property.
Hunt Section
Timeout huntTimeout Maximal time allowed to the destination to handle the call.
Config Status sipRedirectConfigStatus Configuration status of the row. It indicates whether the
configuration of the row is valid.
Auto-Routing Sub-Page
Field Name SNMP Variable Description
Criteria Type autoRoutingCriteriaType Determines the type of criteria to use to create automatic
rule from SIP to the telephony endpoints.
Incoming Mappings autoRoutingIncomingMappings Name of the properties manipulations associated with the
route from the SIP gateway to the endpoint.
Outgoing Mappings autoRoutingOutgoingMappings Name of the properties manipulations associated with the
route from the endpoint to the SIP gateway.
Incoming Signaling autoRoutingIncomingSignalingProperties Name of the signaling properties associated with the route
Properties from the SIP gateway to the endpoint.
Outgoing Signaling autoRoutingOutgoingSignalingProperties Name of the signaling properties associated with the route
Properties from the endpoint to the SIP gateway.
Auto-routing Gateway autoRoutingAutoRoutingGateway Name of the SIP gateway to use as the destination of
outgoing calls and the source of incoming calls when
generating auto-routing rules.
E164 autoRoutingE164 The telephone number associated with this endpoint, if any.
SIP Username autoRoutingSipUsername The SIP username associated with this endpoint, if any.
Management Page
Current State (Export) scriptsStatsCurrentTransferState The current state of the configuration script transfer and
execution.
Current State ScriptsStatsCurrentExportState The current state of the configuration script exportation.
(Execute)
Last Result (Export) scriptsStatsLastTransferResult Result of the last configuration scripts transfer command.
Last Result (Execute) ScriptsStatsLastExportResult Result of the last configuration script exportation command.
Last Successful scriptsStatsLastTransferDateTime Date and time of the last successful configuration script
(Export) transfer command.
Last Successful ScriptsStatsLastExportDateTime Date and time of the last successful configuration script
(Execute) exportation and transfer command since the last reset to
default settings.
Service Name ScriptExportServiceName Name of the service from which to export configuration.
Send To URL scriptExportUrl URL where to send the configuration script exported.
Privacy Key scriptExportSecretKey Key used to encrypt the configuration script to export.
Transfer Protocol scriptsTransferProtocol Protocol used to transfer the configuration script files.
User Name scriptsTransferUsername User name used to transfer the configuration script.
Allow Repeated scriptsAllowRepeatedExecution Allows the execution of a script even if it is identical to the
Execution last executed script.
Time Of Day scriptsTransferTimeOfDay Time when the automatic configuration scripts transfer
occurs.
Status Section
Last Backup Result imageBackupStatus Result of the last configuration backup command.
Last Restore Result imageRestoreStatus Result of the last configuration restore command.
File Name imageFileName Name of the file used to backup (save) and restore (load)
the unit’s configuration.
User Name imageTransferUsername User name used to transfer the configuration image.
Status Section
Firmware Pack status Indicates the current status of the Firmware Pack Updater.
Updater Status
Last Successful mfpLastInstallationDateTime Date and time of the last successful install command.
Installation
Rollback (command) Launches the rollback of the previously installed MFP found
in recovery bank.
Automatic Restart automaticRestartEnable Enables the firmware pack updater to automatically restart
Enable the system when needed for completing a firmware update
operation.
Automatic Restart automaticRestartGraceDelay Configures the grace delay in minutes that the unit waits for
Grace Delay all telephony calls to be terminated before the automatic
restart can occur.
Transfer Configuration
User Name mfpTransferUsername User name to use to access the update tree.
Host Name mfpTransferSrvHostname Name or IP address and port of the Update Files server.
Certificates Sub-Page
Issued To hostCertificatesInfoIssuedTo Certificate subject name. This is the common name that
must match the host being authenticated.
Issued By hostCertificatesInfoIssuedBy Certificate issuer name. This is the certificate authority that
signed this certificate.
Issued To othersCertificatesInfoIssuedTo Certificate subject name. This is the common name that
must match the host being authenticated.
Issued By othersCertificatesInfoIssuedBy Certificate issuer name. This is the certificate authority that
signed this certificate.
SIP hostCertificateAssociationSip Specifies if this certificate can be used for SIP security.
Web hostCertificateAssociationWeb Specifies if this certificate can be used for Web security.
EAP hostCertificateAssociationEap Specifies if this certificate can be used for EAP security.
Override OCSP URL certificateAuthoritiesOverrideIssuedCertificateO Defines a specific OCSP URL to use for certificate
cspUrl revocation status of certificates issued by this certificate
authority (CA).
SNMP Listening Port port Port on which the SNMP service should listen for incoming
SNMP requests.
Enable SNMP V1 enableSnmpV1 Specifies if a user can connect to the system by using
SNMPv1.
Enable SNMP V2 enableSnmpV2 Specifies if a user can connect to the system by using
SNMPv2.
Enable SNMP V3 enableSnmpV3 Specifies if a user can connect to the system by using
SNMPv3.
Privacy Password privPassword Password to use with SNMPv3 when using DES privacy.
Community community String to use for the community field of SNMPv1 and
SNMPv2 read-write commands and traps.
Users Section
Access Rights usersAccessRights Defines the access rights template applying to a user.
Service servicesAaaTypeService Service name for which the Aaa types are configured.
Accounting Type servicesAaaTypeAccountingType Accounting type a service uses once a user is successfully
authenticated on the unit.
Authentication
Server Secret radiusServersAuthenticationSecret Secret key shared between the Radius server and the unit.
Accounting
Host radiusServersAccountingHost Hostname and port of a Radius server used for accounting
requests.
Server Secret radiusServersAccountingSecret Secret key shared between the Radius server and the unit.
General
Server Request radiusServersTimeoutS Maximum time, in seconds, the unit waits for a reply from a
Timeout Radius server.
Radius Users Access radiusUserAccessRights Defines the access rights template applying to all Radius
Rights users.
File Sub-Page
Misc Sub-Page
E Glossary
10 BaseT
An Ethernet local area network that works on twisted pair wiring.
100 BaseT
A newer version of Ethernet that operates at 10 times the speed of a 10 BaseT Ethernet.
Access Device
Device capable of sending or receiving data over a data communications channel.
Accounting
Accounting measures the resources a user consumes during access. This can include the amount of system
time or the amount of data a user has sent and/or received during a session. Accounting is carried out by
logging of session statistics and usage information and is used for authorization control, billing, trend analysis,
resource utilization, and capacity planning activities.
A-Law
The ITU-T companding standard used in the conversion between analog and digital signals in PCM (Pulse
Code Modulation) systems. A-law is used primarily in European telephone networks and contrasts with the
North American mu (µ)-law standard. See also mu (µ)-law.
ANI
In CAS signalling, the sending of the calling numbers is known as Automatic Number Identification.
AOC
In ISDN signalling, an Advice Of Charge (AOC-D) message is sent to advise of the current charge (D)uring a
call or an AOC-E message is sent to advise of the total charge at the (E)nd of a call.
Area Code
The preliminary digits that a user must dial to be connected to a particular outgoing trunk group or line. In North
America, an area code has three digits and is used with a NXX (office code) number. For instance, in the North
American telephone number 561-955-1212, the numbers are defined as follows:
Table 351: North American Numbering Plan
No. Description
561 Area Code, corresponding to a geographical zone in a non-LNP (Local Number Portability)
network.
955 NXX (office code), which corresponds to a specific area such as a city region.
1212 Unique number to reach a specific destination.
Outside North America, the area code may have any number of digits, depending on the national
telecommunication regulation of the country. In France, for instance, the numbering terminology is xZABPQ
12 34, where:
Table 352: France Numbering Plan
No. Description
In this context, the area code corresponds to the Z portion of the numbering plan. Because virtually every
country has a different dialing plan nomenclature, it is recommended to identify the equivalent of an area code
for the location of your communication unit.
Authentication
Authentication provides a way of identifying a user, typically by having the user enter a valid user name and
valid password before access is granted. The process of authentication is based on each user having a unique
set of criteria for gaining access. The AAA server compares a user's authentication credentials with other user
credentials stored in a database. If the credentials match, the user is granted access to the network. If the
credentials are at variance, authentication fails and network access is denied.
Call Routing
Calls through the Aastra can be routed based on a set of routing criteria.
Echo Cancellation
Technique that allows for the isolation and filtering of unwanted signals caused by echoes from the main
transmitted signal.
Firewall
A firewall in a networked environment prevents some communications forbidden by the security policy. It has
the basic task of controlling traffic between different zones of trust. Typical zones of trust include the Internet
(a zone with no trust) and an internal network (a zone with high trust).
Full-Duplex Connection
Refers to a transmission using two separate channels for transmission and reception and that can transmit in
both ways at the same time. See also Half-Duplex Connection.
G.703
ITU-T recommendation for the physical and electrical characteristics of hierarchical digital interfaces at rates
up to 140Mbit/s.
G.704
ITU-T recommendation for synchronous frame structures on G.703 interfaces up to 45Mbit/s. The
conventional use of G.704 on a 2Mbit/s primary rate circuit provides 30 discrete 64kbit/s channels, with a
further 64kbit/s channel available for common channel signalling.
G.711
Algorithm designed to transmit and receive A-law PCM (Pulse Code Modulation) voice at digital bit rates of 48
kbps, 56 kbps, and 64 kbps. It is used for digital telephone sets on digital PBX and ISDN channels.
G.723.1
A codec that provides the greatest compression, 5.3 kbps or 6.3 kbps; typically specified for multimedia
applications such as H.323 videoconferencing.
G.726
An implementation of ITU-T G.726 standard for conversion linear or A-law or µ-law PCM to and from a 40, 32,
24 or 16 kbit/s channel.
G.729
A codec that provides near toll quality at a low delay which uses compression to 8 kbps (8:1 compression rate).
Gateway
A device linking two different types of networks that use different protocols (for example, between the packet
network and the Public Switched Telephone Network).
Half-Duplex Connection
Refers to a transmission using the same channel for both transmission and reception therefore it can't transmit
and receive at the same time. See also Full-Duplex Connection.
Hunt Group
The hunt group hunts an incoming call to multiple interfaces. It accepts a call routed to it by a routing table or
directly from an interface and creates another call that is offered to one of the configured destination interfaces.
If this destination cannot be reached, the hunt group tries another destination until one of the configured
destinations accepts the call. When an interface accepts a call, the interface hunting is complete and the hunt
group service merges the original call with the new call to the interface that accepted the call.
Impedance
Impedance is the apparent resistance, in an electric circuit, to the flow of an alternating current, analogous to
the actual electrical resistance to a direct current, being the ratio of electromotive force to the current.
Internet-Drafts
Internet-Drafts are working documents of the IETF, its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
IP Forwarding
Allows the packet to be forwarded to a specific network based on the packet’s criteria (source IP address and
source Ethernet link).
Jitter
A distortion caused by the variation of a signal from its references which can cause data transmission errors,
particularly at high speeds.
Local Firewall
Allows you to dynamically create and configure rules to filter incoming packets with the unit as destination. The
traffic is analyzed and filtered by all the rules configured.
Mu (µ)-Law
The PCM (Pulse Code Modulation) voice coding and companding standard used in Japan and North America.
See also A-Law.
Network
A group of computers, terminals, and other devices and the hardware and software that enable them to
exchange data and share resources over short or long distances. A network can consist of any combination
of local area networks (LAN) or wide area networks (WAN).
Network Firewall
Allows dynamically creating and configuring rules to filter packets forwarded by the unit. Since this is a network
firewall, rules only apply to packets forwarded by the unit. The traffic is analyzed and filtered by all the rules
configured.
Off-hook
A line condition caused when a telephone handset is removed from its cradle.
On-hook
A line condition caused when a telephone handset is resting in its cradle.
Packet
Includes three principal elements: control information (such as destination, origin, length of packet), data to be
transmitted, and error detection. The structure of a packet depends on the protocol.
Port
Network access point, the identifier used to distinguish among multiple simultaneous connections to a host.
Protocol
A formal set of rules developed by international standards bodies, LAN equipment vendors, or groups
governing the format, control, and timing of network communications. A set of conventions dealing with
transmissions between two systems. Typically defines how to implement a group of services in one or two
layers of the OSI reference model. Protocols can describe low-level details of machine-to-machine interfaces
or high-level exchanges between allocation programs.
Proxy Server
An intermediary program that acts as both a server and a client for the purpose of making requests on behalf
of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other
servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding it.
QSIG
QSIG is an ISDN based signaling protocol for signaling between private branch exchanges (PBXs) in a Private
Integrated Services Network (PISN). It makes use of the connection-level Q.931 protocol and the application-
level ROSE protocol. ISDN "proper" functions as the physical link layer.
Registrar Server
A server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server
and MAY offer location services.
Server
A computer or device on a network that works in conjunction with a client to perform some operation.
Subnet
An efficient means of splitting packets into two fields to separate packets for local destinations from packets
for remote destinations in TCP/IP networks.
T.38
An ITU-T Recommendation for Real-time fax over IP. T.38 addresses IP fax transmissions for IP-enabled fax
devices and fax gateways, defining the translation of T.30 fax signals and Internet Fax Protocols (IFP) packets.
Telephony
The science of translating sound into electrical signals, transmitting them, and then converting them back into
sound.
F List of Acronyms
AC Access Concentrator
AES Advanced Encryption Standard
ANI Automatic Number Identification
CA Certification Authority
CAS Channel Associated Signalling
CCBS Completion of Calls to Busy Subscriber
CCNR Completion of Calls on No Reply
CHAP Challenge Handshake Authentication Protocol
CLI Command Line Interface
CLIP Calling Line Information Presentation
CLIR Calling Line Information Restriction
CNG Comfort Noise Generator
COLP Connected Line Identification Presentation
COLR Connected Line Identification Restriction
CS-ACELP Conjugate Structure-Algebraic Code Excited Linear Prediction
B
bootp-dhcp-option-88 ................................................................................................................................................... 91, 92
D
draft draft-poetzl-bliss-call-completion-00 ......................................................................................................................... 414
draft-choudhuri-sip-info-digit-00 ................................................................................................................................ 354, 381
draft-ietf-http-authentication-03 ........................................................................................................................ 519, 535, 543
draft-ietf-sipping-realtimefax-00 ........................................................................................................................................ 309
E
ETS 300 207 - Call Diversion and Call Rerouting ............................................................................................................ 209
ETSI 300 659-1 January 2001 (Annex B) ......................................................................................................................... 160
ETSI EN 300659-3 ........................................................................................................................................................... 164
I
IEEE 802.1Q -Virtual Bridged Local Area Networks ........................................................................................................... 98
IEEE 802.1X - Port Based Network Access Control ......................................................................................................... 106
IEEE Std 1003.1-2001 - IEEE Standard for Information Technology---Portable Operating System Interface (POSIX®) 457
ITU-T Recommendation E.164 - The international public telecommunication numbering plan ........................................ 455
ITU-T Recommendation F.69 - List of Telex Destination Codes ...................................................................................... 455
ITU-T Recommendation G.703 - Physical/Electrical Characteristics of Hierarchical Digital Interfaces ............ 182, 193, 219
ITU-T Recommendation G.704 - Synchronous Frame Structures Used at Primary and Secondary Hierarchy Levels ... 182,
193, ............................................................................................................................................................. 219
ITU-T Recommendation G.711 ........................................................................................................................................ 349
ITU-T Recommendation G.723.1 ..................................................................................................................................... 350
ITU-T Recommendation G.726 ........................................................................................................................................ 350
ITU-T Recommendation G.729 ........................................................................................................................................ 351
ITU-T Recommendation I.430 - Basic user-network interface - Layer 1 specification ...................................................... 193
ITU-T Recommendation I.431 - Primary rate user-network interface - Layer 1 specification ........................................... 182
ITU-T Recommendation Q.24 - Multifrequency push-button signal reception .................................................................. 354
ITU-T Recommendation Q.310-Q.332 - Specifications of Signalling System R1 ............................................................. 251
ITU-T Recommendation Q.421 - Digital line signalling code ............................................................................................ 219
ITU-T Recommendation Q.441 - Signalling code ............................................................................................................. 219
ITU-T Recommendation Q.921 - ISDN user-network interface - Data link layer specification ................................. 182, 193
ITU-T Recommendation Q.931 - ISDN user-network interface layer 3 specification for basic call control ....... 182, 193, 458
ITU-T Recommendation T.38 ................................................................................................................................... 309, 353
ITU-T Recommendation X.121 - International numbering plan for public data networks ................................................. 455
R
RFC 1034 - Domain Names - Concepts and Facilities ....................................................................................................... 90
RFC 1035 - Domain Names - Implementation and Specification ....................................................................................... 90
RFC 1157 - Simple Network Management Protocol (SNMP) ........................................................................................... 559
RFC 1332 - The PPP Internet Protocol Control Protocol (IPCP) ...................................................................................... 103
RFC 1334 - PPP Authentication Protocols ....................................................................................................................... 103
RFC 1350 - The TFTP Protocol (Revision 2) ........................................................................................... 441, 519, 535, 543
RFC 1661 - The Point-to-Point Protocol (PPP) ................................................................................................................ 103
RFC 1877 - PPP Internet Protocol Control Protocol Extensions for Name Server Addresses ......................................... 103
RFC 1886 - DNS Extensions to support IP version 6 ......................................................................................................... 90
RFC 1890 - RTP Profile for Audio and Video Conferences with Minimal Control ............................................................ 354
RFC 1910 - User-based Security Model for SNMPv2 ...................................................................................................... 559
RFC 1945 - Hypertext Transfer Protocol - HTTP/1.0 ......................................................................................................... 41
RFC 1994 - Challenge Handshake Authentication Protocol (CHAP) ............................................................................... 103
RFC 2030 - Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI ...................................................... 91
RFC 2104 - HMAC Keyed-Hashing for Message Authentication ..................................................................................... 559
T
TR-069 - CPE WAN Management Protocol v1.1 (Issue 1 Amendment 2) ....................................................................... 565
TR-098 - Internet Gateway Device Data Model for TR-069 (Issue 1 Amendment 2) ....................................................... 565
TR-104 - Provisioning Parameters for VoIP CPE ............................................................................................................. 565
TR-106 - Data Model Template for TR-069-Enabled Devices .......................................................................................... 565
TR-111 - Applying TR-069 to Remote Management of Home Networking Devices ......................................................... 565
B
bootp-dhcp-option-8893, 94
D
draft draft-poetzl-bliss-call-completion-00420
draft-choudhuri-sip-info-digit-00358, 387
draft-ietf-http-authentication-03525, 541, 549
draft-ietf-sipping-realtimefax-00311
E
ETS 300 207 - Call Diversion and Call Rerouting211
ETSI 300 659-1 January 2001 (Annex B)162
ETSI EN 300659-3166
I
IEEE 802.1Q -Virtual Bridged Local Area Networks100
IEEE 802.1X - Port Based Network Access Control108
IEEE Std 1003.1-2001 - IEEE Standard for Information Technology---Portable Operating
System Interface (POSIX®)463
ITU-T Recommendation E.164 - The international public telecommunication numbering
plan461
ITU-T Recommendation F.69 - List of Telex Destination Codes461
ITU-T Recommendation G.703 - Physical/Electrical Characteristics of Hierarchical Digi-
tal Interfaces184, 195, 221
ITU-T Recommendation G.704 - Synchronous Frame Structures Used at Primary and Sec-
ondary Hierarchy Levels184, 195, 221
ITU-T Recommendation G.711353
ITU-T Recommendation G.723.1354
ITU-T Recommendation G.726354
ITU-T Recommendation G.729355
ITU-T Recommendation I.430 - Basic user-network interface - Layer 1 specification195
ITU-T Recommendation I.431 - Primary rate user-network interface - Layer 1 specifica-
tion184
ITU-T Recommendation Q.24 - Multifrequency push-button signal reception358
ITU-T Recommendation Q.310-Q.332 - Specifications of Signalling System R1253
ITU-T Recommendation Q.421 - Digital line signalling code221
ITU-T Recommendation Q.441 - Signalling code221
ITU-T Recommendation Q.921 - ISDN user-network interface - Data link layer specifica-
tion184, 195
ITU-T Recommendation Q.931 - ISDN user-network interface layer 3 specification for ba-
sic call control184, 195, 464
ITU-T Recommendation T.38311, 357
ITU-T Recommendation X.121 - International numbering plan for public data networks461
R
RFC 1034 - Domain Names - Concepts and Facilities92
RFC 1035 - Domain Names - Implementation and Specification92
RFC 1157 - Simple Network Management Protocol (SNMP)563
RFC 1332 - The PPP Internet Protocol Control Protocol (IPCP)105
RFC 1334 - PPP Authentication Protocols105
RFC 1350 - The TFTP Protocol (Revision 2)447, 525, 541, 549
RFC 1661 - The Point-to-Point Protocol (PPP)105
RFC 1877 - PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
105
RFC 1886 - DNS Extensions to support IP version 692
RFC 1890 - RTP Profile for Audio and Video Conferences with Minimal Control358
RFC 1910 - User-based Security Model for SNMPv2563
RFC 1945 - Hypertext Transfer Protocol - HTTP/1.041
RFC 1994 - Challenge Handshake Authentication Protocol (CHAP)105
RFC 2030 - Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI93
RFC 2104 - HMAC Keyed-Hashing for Message Authentication563
RFC 2131 - Dynamic Host Configuration Protocol109, 149
RFC 2132 - DHCP Options and BOOTP Vendor Extensions109, 149
RFC 2181 - Clarifications to the DNS Specification92
RFC 2246 - The TLS Protocol Version 1.0305, 526, 542, 550
RFC 2459 - X.509 Digital Certificates526, 542, 550
RFC 2460 - IPv6100
RFC 2464 - Transmission of IPv6 Packets over Ethernet Networks100
RFC 2475 - An Architecture for Differentiated Services115
RFC 2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)105
RFC 2543 - SIP, Session Initiation Protocol281, 287, 289, 321
RFC 2576 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-stan-
dard Network Management Framework563
RFC 2616 - Hypertext Transfer Protocol - HTTP/1.141, 447, 525, 541, 549
RFC 2617 - HTTP Authentication - Basic and Digest Access Authentication525, 541, 549, 591
RFC 2705 - Media Gateway Control Protocol (MGCP) Version 1.0401
RFC 2741 - Agent Extensibility (AgentX) Protocol Version 1563
RFC 2818 - HTTP Over TLS526, 542, 550
RFC 2833 - RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals358
RFC 2865 - Remote Authentication Dial In User Service (RADIUS)591
RFC 2866 - RADIUS Accounting591
RFC 2976 - The SIP INFO Method417
RFC 3164 - The BSD Syslog Protocol71
RFC 3261 - SIP, Session Initiation Protocol281, 287, 289, 301, 305, 312, 320
RFC 3262 - Reliability of Provisional Responses in the Session Initiation Protocol (SIP)342
T
TR-069 - CPE WAN Management Protocol v1.1 (Issue 1 Amendment 2)569
TR-098 - Internet Gateway Device Data Model for TR-069 (Issue 1 Amendment 2)569
TR-104 - Provisioning Parameters for VoIP CPE569
TR-106 - Data Model Template for TR-069-Enabled Devices569
TR-111 - Applying TR-069 to Remote Management of Home Networking Devices569
V
V.21 modulation detection 396
VLAN
creating 113
in QoS 117
vocal features, special
IP address 161
MAC address 161
vocal unit information 161
voice activity detection
G.729 366
voiceband data mode
starting a call in 390
W
wait before answering delay, on FXO port 170
wait for calle to answer, on FXO port 170
web interface
automatic call 419
call completion
CCBS 420
CCNR 420
call forward
on busy 409
on no answer 412
unconditional 414
call hold 435
call transfer
attended 424