Sip Dect

SIP-DECT® 4.
0
Training as of 06/2013
module 1: Basic Training
module 2: Advanced Training
module 3: Messaging and Locating
module 4: Troubleshooting Training
Aastra confidential information / for training purpose only © Aastra - 2013
Basic Training Content
Overview
Base station and handset types
Licensing
OpenMobility Manager
Handover
Sync over AIR
Media-stream Management
Base station Start-UP
LED handling
OMM configuration (basics)
Handsets
Aastra confidential information / for training purpose only © Aastra - 2013 3

SIP-DECT® – Overview System
System Overview of one SIP-DECT® system with multiple sites and available applications
Provisioning
Server (if set)
Applications
e.g. Messaging
Locating, Alarm
OMM PC for
big installations
DHCP TFTP
Call Server / PBX
PSTN SIP
System capacities:
• up to 2048 base stations The system is scalable from single-cell
• up to 4500 handsets to large enterprise installation, which
depending on the call server can be distributed to multiple sites with
and the OMM software stream one central OpenMobility Manager
SIP-DECT® - Products
DECT base stations Additional equipment
RFP(L) 35: indoor

RFP(L) 36: outdoor
RFP(L) 37: outdoor with external antenna
RFP(L) 43: indoor DECT + WLAN (802.11n)
DECT
Site Survey Kit
OMM Activation Kit Headsets

DECT handset
(System CD)
Charger Racks
610d
> 612d
620d
> 622d incl. PARK DECT antenna
630d software and for RFP L37 IP
> 632d documentation
(omni. / directed)
650c 142d or license papers
SIP-DECT® - Base Station features
Base Station DECT features

Usage of all 12 channels between base station and handset
8 simultaneous voice channels on each DECT- base station,
RFP (L) 32 IP
additional 4 channels e.g. for location registration
Synchronisation of IP Base Stations over DECT
Support of GAP-standard
Connection handover
DSAA authentication between base station and handset
RFP (L) 34 IP DSC-64bit-encryption over the air interface
Support of DECT XQ extension for reflective environments
Status indication with 4 LEDs’ (red / yellow / green)
CAT IQ / Wideband Audio Support (RFP(L) 35/36/37/43)
RFP (L) 42 WLAN

SIP-DECT® - Base Station features
Network features
Ethernet: RFP(L) 32/34/42 100Mbit, RFP(L) 35/36/37/43 1GBit
Power supply according to Power over Ethernet Standard
IEEE 802.3af or AC adapter for RFP(L) 32/42/35/43
USB
Power 1GBit VoIP-connection with protocol RTP/RTCP
48V DC Ethernet (PoE)
(optional) Network boot (32/34/42), DHCP client, SW-Download / update
Codec G.711/G.722/G.729 depending on call server,
DECT antenna connector hardware and licenses
(RFP 37) Support of quality of service with Diffserv / ToS-flag / 802.1p
Adaptive jitter compensation
Echo cancellation / suppression for acoustic and transmitted echo
Voice pause cancellation und comfort noise-generation
VLAN tagging for voice and data traffic

OpenMobility Manager (OMM)
A SIP-DECT system is controlled via an active OpenMobility Manager (OMM).

A Standby OMM can also be configured to become active, as soon the active fails.
All base stations need to connect to the OMM, which controls
the base stations and provides the central management.
A signaling connection to the call server is only effected by the OMM.
The OMM can run on a selected base station or PC (depend on software stream)
Webservice XML Applications
e.g. OMP
RFP
OMM PBX / Callserver

RFP
OMM
RFP (Stand-by)

SIP-DECT® – Applications
OM AXI applications
OM AXI
OMP
OMM OM AXI Configuration
(Server) Monitoring
OM AXI OM AXI
RFP IMA OML
Locating
RFP
OM AXI
other applications
e.g. Provisioning,
LAN Alarm Server, …
OM AXI = OpenMobility Application XML Interface The OMM provide the OM AXI (XML) interface
IMA = Integrated Messaging & Alerting server to connect with other applications. OM AXI
can be used e.g. for configuration, Monitoring,
OMM = OpenMobility Manager or
Locating, Messaging.
SIP-DECT® – Applications (2)
DECT handsets (600d/c series) can access external applications

using the OMM Terminal XML interface. This feature provides various
options for the integration of applications and call servers. Application Menu
call / redial lists
XML Applications can include different objects:

e.g TextScreen, TextMenu, InputScreen
Applications can also push information to handsets Idle screen modification

e.g. display information as call forwarding icon and text lines
This Aastra XML interface is similar to the one used by

Aastra 673x/5xi terminals.
Overview - Deployment
Base station (RFP) Start Up

DHCP or Static IP configuration
Support of external configuration files (ipdect.cfg)
Multicast TFTP download for faster firmware download (RFP(L) 32/34/42)
Support of up to 3 TFTP Server for firmware download
RFP(L) 35/36/37/43 local startup and SW download by TFTP, FTP(s), HTTP(s)
Multicast TFTP Download (RFP 32/34/42) DHCP Server with DHCP / OM

common settings Configuratior
Configuration
Server ipdect.cfg
with config files
<MAC.cfg>
OMM

Overview – Deployment (II)
Webservice
OMP – OM Management Portal with monitoring and statistic features
Automatic Database Import (initial and periodical)
Manual Import abilitys for handsets and base stations
OpenMobility Application XML Interface (OMAXI) for deployment,
management and 3rd party applications (messaging and locating)
Site
Building
Floor
Room
RFP Name

Overview – Deployment (III)
Support of external handset user data configuration (user.cfg)
Dynamic device to user assignment (new provisioning model, Handset Sharing)
2 1 2
1 Config
user 300
Server
device 4 OMM
4 OMM 3 3
device user201
201.cfg
Overview - Management
Management / Monitoring
Webservice for system configuration and status display
OMP for configuration and display system status / statistics / real time monitoring
Automatic Database Export via FTP(s), HTTP(s), TFTP
OMM and RFPs’ send event information to central syslog server
SNMP support (read community and trap support)
DECT IP Monitor to display real time handset activities
Handset site survey mode for on site verification
RFP displays current status using 4 LEDs’ for e.g. system alarm states
Quick system status overview

Overview - Messaging and Locating
Messaging / Alerting
Handset messages with up to 1000 characters
Different message priority and confirmation handlings
Handset <> Handset (,fax, email, application) messaging abilitys
XML interface with messaging support for application server
IMA - Integrated messaging and Alerting service
(with alarm triggers and escalations) handset <> handset handset <> email
XML Alarm triggers

applications
OMM e.g. Alarm Server
OM AXI IMA
IMA Locating Server

Overview - Messaging and Locating (II)
Handset tracking
OM Locating server display for handset link, RFP visibility,
handset event history, active SOS and mandown alarms
Handset location request can be initiated by an handset
Base station visibilitys reported by the handset

can be displayed on 600d/c handsets
Handset last location update history

with user action e.g. call, handover >
SIP-DECT® Licensing
Since the OMM Release 2.1 licenses are required.

This depend on the system configuration and licensed features.
Licensed features are messaging, locating, G.729 channels and number of RFPs.
Other features are not part of a license. (e.g. Standby OMM, …)
In order to properly address small, medium and large installations

the offering is split into the following parts:
tiny – 1-2 RFPs (no license)

small – up to 20 RFPs (RFP-L)
medium – up to 256 RFPs
large – up to 2048 RFPs
A demonstation license is configured if the system start up without configuration.

This allow to test and show features and applications. (72h time limit, limited voice)
Since OMM 2.1 standard RFPs e.g. RFP 32/34/42 and L-RFPs e.g. RFP-L 32/34/42
are supported. With Release 1.x only L-RFPs can be used.
SIP-DECT® License Concept
# License description dependency License steps
1 OM System Enables telephony for a system of 10, 20, 50, 100,

a certain size (number of RFPs) 250,500,1000
and a defined SW release; linked (steps are additive)
to a PARK up to 256 or >256 RFPs
2 OM Message & Enables receiving alarm 1; if messages 1
Alerting System messages/alarms on handsets shall be sent
incl. confirmation of msg./alarms between handset: 3
3 OM Messaging Enables sending messages from a 1 10, 20, 50, 100, 250
handset for a number of users
4 OM Locating Enables locating for a no. of users 1 10, 20, 50, 100, 250
5 OM Locating Server Enables the locating application 1;2;4 1
6 OM G.729 License Use of G.729 Codec (Rel 3.0 >) 1 5, 10, 20, 50
7 OM G.729 License Special package for 1-2 standard
Mini RFP systems, containing 2x RFP
and 4x G.729 license
8 SW Update Process of updating the license a new license file is
file to enable the system to run required
with a later SW release
SIP-DECT® License Concept (2)
L-RFP systems (small systems up to 20 L-RFPs with incl. licensed features)

• need activation Key from license server using TAD + PARK from the System CD
• max. of 20 L-RFPs (no support of standard RFPs)
• 3 RFPs need to be selected for activation on the license server (license RFPs)
• update License for mayor and minor software change is required
• 1-2 L-RFP systems need no activation and no update license (only PARK from CD)
standard RFP systems (medium and large systems up to 2048 RFPs)

• require license files from license server
• 3 license RFPs are required for the license file
• system size, messaging and locating are licensed
• update License for mayor and minor software change is required
• order of additional licensed features or higher amounts is possible
• L-RFPs can be used as standard RFPs in a licensed system (e.g. to update small system)
• 1-2 RFP systems need no activation and no update license (no messaging / locating)
Applications can send Messages with Priority: Info, Low, Normal, High without license.
function 1-2 RFP-L 1-2 RFP 3-20 RFP-L 3-256 RFPs 3-2048 RFPs
activation not required not required System CD require License require License
license build in License build in License build in License feature Licenses feature Licenses
telephony only
G.729 Activation req. mini License req. 10 channels feature Licenses feature Licenses
PARK System CD System CD System CD License Server License Server

from (256 > XXL PARK)
update free free Update License Update License Update License
activation
The activation is required for 3-20 RFP-L installations.
The user need a activation key (TAD) + PARK from the system CD to contact the license server.
Insert TAD + PARK + 3 RFP MAC addresses to receive an activation file.
After this file is applied to the OMM, the OMM is activated for the current software release.
License
The customer order the required licenses and get a license paper.
With this license paper contact the license server and insert the TAD
from the license paper and 3 RFP MAC addresses in your installation.
Apply the received license file to the OMM. The OMM is then licensed for the current release.
Update
For a software update to a later major or minor SW release a update license is required.
Go to the license server and insert the TAD from the license paper to receive a updated license.
Update the OMM to the new release and apply this new license afterwards.
There is a free update time frame of 1 year after activation/licensing or usage of update license
Build in license
A build in license is given in RFP-L installations with up to 20 base stations.
This license is enabled by default after insert PARK with 1-2 RFP-L or activation 3-20 RFP-L
# License Included featureset
1 OM System 20 RFP-L, without activation 2 RFPs
2 OM Message & Yes, system wide but limited to msg. prios “Info”, “Low”, “Normal” and “High”
Alerting System (no “Emergency”, no “Locating Alert”)
3 OM Messaging Yes, for all user, incl. confirmations
4 OM Locating No
5 OM Locating Server No
6 OM G.729 License 10 simultanious calls (if you use 1-2 RFP-L, activation required for G.729)
8 SW Update Free SW update for < 3 RFPs’, because activation is not required
>= 3 RFPs’ a update licence is required, because of mandatory activation
1-2 RFP (standard)

Up to two standard RFP does work with a build-in telephony only licence. (PARK still required)
Demonstration license
As soon the OMM start up, the demo license is configured (by using the demo PARK).
This license is valid for 72h and allow to use all features (RFP number limited to 20).
All media streams are restricted to 30 seconds in demo mode!

License violation
violation scenarios reaction
software release is not licensed or activated license violation
configuration exceed the licensed features license violation
e.g. to many RFPs, messaging on handsets
no license is installed license violation
license RFPs are not connected 72h latency period,
(only 1 of 3 RFPs is connected) then license violation
latency period
When 2 of 3 license RFPs are not connected a 72 hour timer will be started.
As long as the timer is not expired the system can be used as before.
After that 72 hour period the license become violated.
If the license RFPs are connected again, the timer runs backwards until it reaches 72h
license voilation
For common licenses (like activation or system license) telephone calls are limited to 30 sec
for each call. All other activated features (like messaging/alarm or locating) will be deactivated.
(exception for message receive license: messages with priority “Info” are always supported)
System activation process

System CD
PARK + Activation Key (TAD)
1. order
License document(s)
L incl. TAD
or L
2.
ware house
Activation key or License document

and MAC addresses of 3 RFP
1 2 3 or L
3.
license server
4. Activation file OMM
or License file
The license server is available at http://licence.aastra.de/

Go to Generate Licence and select the Licence Carrier Type: SIP-DECT
The server will ask for 3 RFP MAC addresses and the TAD (license paper or CD)
Insert the MAC Address in CAPITAL Letters, remember the MAC is hex 0-9,A-F
If you have multiple license papers for one system, start with the system license TAD.

# Name of the License Description SAP No. JDE No.

OM System Licenses Number of usable RFPs
1 OM System License 10 System License for 10 RFPs 68667013 T0000-68667013
8 OM Messaging & Alerting System License System License for alert handling 68660018 T0000-68660018
OM Messaging Licenses Number of handsets which can send messages
9 OM Messaging License 10 Messaging License for 10 handsets (send) 68659010 T0000-68659010
OM Locating License Number of locatable handsets
14 OM Locating License 10 Locating License for 10 handsets 68654011 T0000-68654011
19 OM Locating Server License License for the Locating Server Application 68649011 T0000-68649011
20 OM Upgrade License License for upgrades within 12 months 68632017 T0000-68632017
Simultaneous use of G.729 CODECs Number of useable CODECs GIM No.
21 OM G.729 License 5 License for simultaneous use of 5 G.729 CODECs 86-00012AAA-A
25 OM G.729 License Mini License for 1-2 Standard RFPs using G.729 (4x) 86-00016AAA-A
OM Licensing Overview

OM Licensing Overview (2)



Handover
x 2x
dBm
Handover fsl.
0 -6 - 12
Sync over Air
-70 dBm
-60 / -65 dBm
-50 very good

For a handover the field strength threshold values between -60 good
neighbouring RFP‘s needs to be –60 dBm till max. –65 dBm. -65 satisfactory
-70 sufficient
For Sync over Air the RFP‘s have to see each other with –70 dBm -73 weak
-76 poor

Sync over Air
SIP DECT® synchronizes itself via air interface (Sync over Air).
The OMM manage the synchronization of all connected RFP’s.
RFP‘s that can synchronize each other via the air interface are linked into one cluster.
Handsets can handover (within a call) between the RFP‘s in one cluster.
It is possible to set up several clusters, handset‘s can do a roaming between

this clusters. There is no handover between different clusters or to TDM DECT.
SIP DECT networks should be designed to have multiple synchronization path

if possible. Do not install multiple clusters of the same system in the same area.
The required field strength for Sync over Air is -70 dBm or better.
Synchronization (Sync over Air)
Switch
PBX
Router
WAN
Router
Cluster
Synchronization
Switch TDM
Air

Media Stream Manager (MSM)
PBX / Signaling IP-Phone /

Call server Media Gateway
RTP
Signaling
LAN IP
forward
DECT
IP forward IP
OMM
3
DECT DECT
1
2
When a handset change the RFP during a call, the voice data is re-directed between the RFP‘s.
There is one redirected connection established between the initial(1) and the current RFP (2 or 3)
A base station offers 12 IP- and 8 DECT connection resources e.g. 8 calls + 4 redirected calls.
Base Station Start-Up
An DHCP-server or permanent local network configuration in the base station

(stored by OpenMobility Configurator) are necessary for making the IP-RFP operational.
For the Start Up of RFP (L) 32 / 34 and 42 a TFTP-server is required

on each Start-Up to download the operating system software image (net boot).
Using RFP (L) 35 / 36 / 37 / 43 the TFTP Server is not mandatory for start up.
TFTP
Server 2.
DHCP
Server 1.
or
OpenMobility
Configurator

Base Station Start-Up (2)
RFP(L) 32/34/42 (2G / second generation) - Startup require TFTP Server

SW image: iprfp2G.tftp (in Release 1.x – 2.1: omm_ffsip.tftp)
RFP(L) 32/34/42 require a TFTP Server with a software image on each Start-UP (power up).
On Start-Up the base station will load the image file and run this software.
If the base stations does loose the connection to the OMM, all base station will check
for a new version of the image on the TFTP server. If the image is the same or
the TFTP Server is not reachable, the base stations keep using the running image.
RFP(L) 35/36/37/43 (3G / third generation) – SW Download

SW image: iprfp3G.dnld
On Start Up the RFP (L) 35/37/37/43 operates with the firmware running in the RFP.
There is no initial net boot phase as in the RFP(L) 32/34/42 anymore.
Software Updates are done in the Application Phase by TFTP (default) or

if configured in a RFP config file (ipdect.cfg) via TFTP, FTP(s), HTTP(s).
Configuration e.g. OM_SwImageUrl=ftp://server/openmobility/iprfp3G.dnld

TFTP Server Example Configuration
In this example we use a PumpKIN TFTP Server on a MS Windows® PC.

Check that the Server is running (right side of the bottom line) and
click on Options to configure the TFTP Server root directory.
Than copy the RFP firmware and aafon6xxd.dnld (optional) files into this directory.
2 3
If you have a active Firewall on the PC, check that Port 69 UDP is open for TFTP downloads.

RFP(L) 32/34/42 Booter 3.4 LED handling
LED 1 LED 2 LED 3 LED 4 comment
continuous Power connected
continuous cont. cont. cont. wait for OM Configurator Input
1s 1s DHCP
1,9s 0,1s cont. cont. cont. DHCP failed, wait for OM Configurator Input
0,25s 0,25s TFTP download after DHCP
0,25s 0,25s cont. TFTP download after local configuration
0,25s 0,25s cont. TFTP download after DHCP Multicast
0,25s 0,25s cont. cont. TFTP download after local configuration and
multicast
3,9s 0,1s cont. cont. cont. TFTP failed, wait for OM Configurator Input

RFP(L) 32/34/42 Booter 3.4 Flowchart

Base Station LED handling
Task LED 1 LED2 LED3 LED4

(INFO) (OMM / System) (DECT) (WLAN)
Kernel cont. Kernel boot phase
RFPM 1s 1s DHCP phase
1,9s 0,1s DHCP failure (idle loop)
0,5s 0,5s obtaining external config
0,9s 0,1s External configuration (fail)
cont. Ready
1,9s 0,1s Ready + OMM reside on this RFP
RFP 1s 1s OMM connect phase

general
1,9s 0,1s OMM connection failure (loop)
cont. Ready (OMM Connected)
1,9s 0,1s Ready + OMM has a warning
1,9s 0,1s Ready + OMM has an error

Base Station LED handling (II)
Task LED 1 LED2 (OMM LED3 LED4

(INFO) / System) (DECT) (WLAN)
RFP DECT cont. DECT not configured on this RFP
1,9s 0,1s DECT inactive (not synced yet)
cont. DECT “on air”
1,9s 0,1s DECT + call active
1,9s 0,1s DECT + call active + busy bit
RFP WLAN cont. WLAN not configued on this RFP
1,9sec 0,1sec WLAN inactive yet
cont. WLAN “on air”
1,9s 0,1s WLAN + assoc. clients
cont. WLAN failure (e.g. 10Mbit uplink)
License cont. cont. Branding mismatch
Reboot cont. cont. cont. cont. RFP will reboot (reboot request)

Application Start Up

OpenMobility Configurator
A local configuration can be stored permant into a base station using the OMM Configurator.
This tool require a installed Java 1.6 (JRE) or higher on your computer. If jar files are not linked
to Java on your computer, use „java –jar OM_Configurator.jar“ from a cli to start this tool.
List configuration: read a local configuration from a RFP

Send config.: send the present configuration to the RFP
Reset config.: clear present configuration in the OMM Configurator
By default the OMM Configurator send broadcast packets to the target MAC address.
If a RFP address is given, a unicast packet will be send to the RFP. (For this, the RFP
IP-address have to be configured first.)
The option „as proxy“ can be used to list, send or

Scan RFPs using broadcast packets send from
a running RFP. e.g. if the OMM Configurator PC
is not located in the same IP subnet,
as some unconfigured RFPs.
As RFP(L) 35/36/37/43 have firmware build in,

use Login: omm and Password: omm
for the initial configuration.
Configuration SIP-DECT®
SIP-DECT®
Start-Up of the Base Stations – Permanent
Configuration
Required network parameters of the base stations

can be stored onto a permanent flash memory with the OpenMobility Configurator
or sourced via DHCP over the network.
Required options:
IP-address, Subnet mask, TFTP-server,
TFTP-file, OMM-IP-address, Gateway
Optional facilities: (add paramenter)
DNS, VLAN, NTP, Syslog, config. Import
Country Code, 2nd OMM IP-Address,
Configuration file server, TFTP-Server list
...
OMM Configurator Example Configuration
1. Connect the RFP to your LAN

and Power Up the units
2. Open the OMM Configurator

and select your network interface
3. Login / Password: omm

(for initial config until start up)
4. Insert the RFP MAC address
5. Insert the configuration

Parameters for this RFP
(OMM IP = First RFP in your
Installation)
6. Press „Send config.“ to apply

the configuration to the RFP
TFTP file name: iprfp2G.dnld for RFP (L) 32/34/42 and iprfp3G.dnld for RFP(L) 35/36/37/43
To configure the next unit just modify MAC-Address + IP address in your config, then send config.
Start-Up of the Base Stations - DHCP
A DHCP client is embedded in the booter of the base station, which initiates requests to the
DHCP server in the network. The DHCP client only accepts answers that fulfil the following
conditions:
Option 224 includes “OpenMobilitySIP-DECT“ .
Option 43 Vendor-Specific Information ist set. Example in hex:

“0A:04:XX:XX:XX:XX“ (XX:XX:XX:XX = IP-address of the OpenMobility Manager)
Required parameter:
IP-address, Subnet mask, gateway
boot file name, next file server,
Option 43: code 10 (OMM IP-address)
…
Optional parameter:
NTP (Option 42), Domain Name Server, Option 43: code14 (Syslog Server IP),
code15 (Syslog Port), code17 (country code), code 18 (NTP Server Name),
code 19 (Standby OMM IP-Address), Code 24 (restore URL), ....
further details and sample configurations are available e.g. in the installation guide, training
User Name: omm

Password: omm
After the first Start-Up of the OMM, the unit‘s second LED blinks orange / green
The OMM can now be configured via the WEB service https://<omm-ipaddress>/
The Webservice use a self generated SSL certificate,

most browsers need a user approval to open the webservice.
OpenMobility Manager – User
After the first Login, the User have to set a new user and root password.
They are 3 different account types:
Full access
login: omm passwd: omm
Read only (optional)

login: user passwd: user
root access
login: root passwd: 22222
(for diagnostics purposes only)

OpenMobility Manager – User
The new Password has to match with the following password complexity:
Password complexity: HTTPS OMP OM CFG SSH
> 5 or more characters long Full Access
> contain characters from at least 3

of the following groups: Read only Read only Read only
lower case, upper case, Access
digits or other characters (!,$,..)
Root user after user
> the new password has less Access login
than 50% of the same character
('World11111' or 'W1o1r1l1d1')
> the new password does not contain one of the following items
(either upper or lower case as well as forward or backward):
account name, host name (IP address), old password or

some adjoining keystrokes (e.g. 'qwert').

OpenMobility Manager - Overview
As long there is no PARK (1-2 RFPs) or license configured.

The OMM run in a DEMO mode for 72h with limited media (30s) function.
License Import
If your System require a license

(3 RFP or more connected).
Import the license file in the
OMM licenses section.

OpenMobility Manager - System Settings
General settings
The system name is portrayed

on the Aastra 142d handsets.
remote access:
enable the SSH service shell
DECT settings
required parameters are:
Regulation domain
(EMEA-ETSI, US-FCC/IC, ...)
PARK (on the system CD or

import your license file)
The DECT-authentification
If you don‘t want to operate your system in demo mode code is used as master copy
change the PARK (1F100CF0A6) or apply a license file! for the setup of new terminals.
OpenMobility Manager - System Settings
Download new firmware to

portable parts
activate automatic firmware

update for A600d/c handsets
Syslog (optional)
configure a Syslog Server and

UDP Port. All connected RFP‘s
use this setting.
WLAN settings
select your local WLAN (802.11)

regulatory domain
Date and time

Select your timezone.
Date is set by NTP (if configured)

OpenMobility Manager - SIP
SIP
insert the SIP Server to which

the OMM have to connect to.
This can be a IP-Address or
DNS name (DNS SRV is supported)
The configuration of the SIP

clients is effected under terminals.
If the Proxy server is set to

127.0.0.1, local calls can be
done without SIP server.

OpenMobility Manager – SIP (2)
Receiver precedence on CODEC negotiation
Allow the CODEC selection for incoming SDP

offers based on the OMM preference order list.
Registration traffic shaping
limit the number of simultaneous SIP registrations,

to avoid high registration peaks on the call server.
Supplementary Services
Enable call forwarding / diversion menu

in the handsets system menu.
(apply with next handset location registration)
The local line handling can be switch off.

If the local line handling is switched off then all
R key events (Hook flash) in a call active state will
be sent via SIP INFO as DTMF.
OpenMobility Manager – Database Management
OpenMobility Manager (FFSIP)

configuration file
The OMM does allow the import and backup of configuration files.
|park
This can be done manually from a local file on a PC via webservice -------------
or via TFTP, FTP, FTPs, HTTP, HTTPs from / to a server. PA|1E1010FE
|ac |sys name |e|tz |rd|ra

-------------------------------------
It is also possible to automaticly export the configuration after SYS|0000 |OMMSIP | |CET | 1|X
changes was done (logout of the user) or to schedule a |a|ip address |port
configuration import. ---------------------------
LOG|X|172.30.11.123 |10107
|tos_v|tos_s|ttl|portb
------------------------
IP| B8| B8| 32|16320

OpenMobility Manager – Database Management (2)
Backup / Restore:
The configuration of the OMM is saved via the file “config.omm.gz“.

This file contains all configured data on the OMM Webservice.
(PARK, User account, Base Stations, Handsets, SIP, ...)
Data that has been configured via the OpenMobility Configurator

(e.g. IP-address, OMM IP address) are not stored in this backup.
The browser must allow the popup to restore the configuration.

OpenMobility Manager – Base Stations
state
> In operation
> syncronize
> not syncron.
Radio fixed parts
New: configure new base stations

Import: base station configuration with a text script
Start: capture not configured RFP‘s which try to connect (as inactive)
The OMM RFP must be configured here as well.

OpenMobility Manager – Base Stations
New
Add here new base stations.
- MAC-address (see backside of the base station)

- Name (description / location of the base station)
- DECT Cluster (for Sync over Air)
WLAN (RFP 42/43 only)
- select a WLAN profile (need to be configured)

- set the WLAN channel
- set the WLAN Output Power level
(Full, 50%, 25%, 12% or 6%)
The RFP(L) 43 can operate as WLAN Access Point

and OMM at the same time. If the OMM reside on a
RFP (L) 42 (Rel. <= 2.1) WLAN function is disabled.

OpenMobility Manager – Portable Parts
Portable Part
New:
configure new DECT handsets
Import:
handset configuration with a text script
Search:
search for a number or IPEI
in the database
to allow subscriptions for handsets with

config. IPEI configuration use Start (24h)
or
to allow a subscription without IPEI configuration use the Wildcard subscription.
Subscription will be enabled permanently while at least one PP (with IPEI) is configured and
no PP is subscribed. After the subscription of the first PP the subscription will still be enabled
for 24 hours.
OpenMobility Manager – Portable Parts
Name: User Name displayed on the handset
Number: handset extention number
IPEI: of the handset
Login/Additional ID: (optional)

number to select a individual handset e.g.
setup multiple handsets without IPEI
SOS number: SOS key destination number
Man down number: (Aastra 630/633d)

Man down function destination number
User name: SIP user name
Password: SIP password

Handset Subscription
To subscribe new handsets, make sure that the RFPs are active and connected.
Then activate the generic subscription or wildcard subscription.
< If each handset is configured with IPEI
< If handset are configured with

or without IPEI
Menu > System > Subscriptions > New:

Park: enter the System Park or leave blank to select the first available system
Auth Code: enter the DECT authentication code if set
Additional ID: to select the additional ID hit the R key after the auth code
142d
Menu > System > Subscriptions > New system:

Auth Code: enter the DECT authentication code if set
Additional ID: to select the additional ID hit the key after the auth code
Park: use Enter PARK to insert the system PARK, this is usefull if several DECT
600d/c systems are around or go to subscription to select the first available system

Special SIP Features / Codecs
SIP v2 and SDP (RFC 3261 / 2327 / 3264)

Call transfer (blind and consulted; RFC 3515 / 3891 / 3892)
Call forward (busy, no answer, timer triggered)
Message Waiting Indication (RFC 3842)
Broker call (support of two lines)
Call waiting
Caller ID with name (in all states, if supported by proxy)
Do not disturb
DTMF out-of-band (RFC 2833), in-band, INFO
Call logs (dialled, missed, received)
VoIP Codecs
• G.711 Codec (10 20 30 ms)
• G.729 Codec (10 20 30 ms), depend on licensing.
• G.722 Codec (10 20 30 ms), depends on the hardware capabilites.

RFC Compliance
RFC 2030 - Simple Network Time Protocol (SNTP)

RFC 2474 - Definition of the Differentiated Services Field (DS Field)
RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication
RFC 2782 - A DNS RR for specifying the location of services (DNS SRV)
RFC 3261 - Session Initiation Protocol (SIP)
RFC 3262 - Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
RFC 3264 - An Offer/Answer Model with Session Description Protocol (SDP)
RFC 3311 - The Session Initiation Protocol (SIP) UPDATE Method
RFC 3326 - Reason Header Field
RFC 3420 - Internet Media Type message / sipfrag
RFC 3515 - The Session Initiation Protocol (SIP) Refer method [2]
RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
RFC 3665 - Session Initiation Protocol (SIP) Basic Call Flow Examples
RFC 3842 - A Message Summary and Message Waiting Indication Event Package
RFC 3891 - The Session Initiation Protocol (SIP) "Replaces" Header
RFC 3892 - The Session Initiation Protocol (SIP) Referred-By Mechanism
RFC 4235 - INVITE-Initiated Dialog Event Package for SIP
RFC 4320 - Actions Addressing Identified issues with the SIP Non-INVITE Transaction
RFC 4475 - SIP Torture Test Messages
RFC 4566 - SDP: Session Description protocol
RFC 4579 - Call Control - Conferencing for User Agents
RFC 4733 - RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
RFC 4961 - Symmetric RTP / RTP Control Protocol (RTCP)
RFC 5359 - (SIP) Call Control – Transfer
RFC 5806 - Display Diversion Indication

Aastra Phone 142d
Aastra Phone
142d

142d Basic Features
Call Forward (all calls / busy / no answer)

Call Logs (dialled / missed / received)
Handsets with personal phonebook (100 entries) and directory search
Redial last number, redial list
Call waiting & missed call indicator
Caller ID with name & with Name on Call Waiting
Call filter
Hold call, hold call visual indication,
Hold call reminder tones (calling party / called party)
Microphone mute function
Lock keypad
Alarm
Reset to factory default settings
User interface in English, German, French, Spanish, Italiano, Nederlands,
Svenska, Dansk, Norsk, Português, Sumoi, Cesky, Slovensky language
Country specific tone plan
…
for more details please read the data sheets and manual

142d Technical Data
Technical Data
» Graphic display: back-lit, 5 lines (96 x 60 pixels), adjustable contrast
» Standby time: up to 140 h*
» Talk time: up to 14 h*
» Batteries: 3 AAA (NiMH)
» Charge time: max. 6 hours with empty batteries
» Weight: 138 g incl. Batteries
» Dimensions (L x W X H): 146 x 52 x 28 mm
Delivery units
»Set Aastra 142d,Continental Europe:68884
»Set Aastra 142d,UK:68867
»Set Aastra 142d,Australia:68866
The delivery unit of the sets consists of: handset, 3 batteries, belt clip, memory card,
user guide, desktop charger and AC-power adaptor

142d Memory Card
On Start Up the 142d will check if a memory card is present.

If a empty card is available, the handset write the local configuration
to the card and will only work with a written memory card in the future.
If the handset fail, you can recover the memory card and insert the
card into a new handset. If the handset detect, that the card is not
empty. The handset work with the card settings.
Memory card
card slot

142d Service Procedures
Software Version: Menu > R * 1 #

Site Survey Mode: Menu > R * 2 # (same procedure to switch mode off)
Battery capacity setup: Menu > R * 3 # (if the battery capacity has changed)
Service Mode: Menu > R * * * 76 # (for service and support only)
> Version Number ...

> Auto Call Test > Attention Tones
> Auto Answer Test > Message Options
> Site Survey > Subscriptions
> Battery > Master Reset
> Loud enviroment > Reset
> Info LED > Life Calls
> Light > Read Only
...

600d/c Handset Family
New family of DECT wireless handsets

• 610/612d: Low End Office version with basic features
• 620/622d: Business version
• 630/632d: Industrial / Care
• 650c: Business version with CAT-iq Wideband Audio
• International AC Adapter for EMEA, North America and Australia
• Download of new firmware possible from OMM over Air
610d 620d 630d

612d 622d 632d 650c
Aastra 600d/c - Overview

Features 610/612d
Standards Batteries
• DECT / GAP • Lithium-Ion battery pack, 850 mAh
• Firmware download over air or PC • At least 12/15h talk time (EMEA/US)
Housing • At least 100/95h stand by time (EMEA/US)
• Protection class IP 50 • Intelligent Battery Management
• Drop-resistance: 1.5 m
Display, Special Keys
• Aastra 610d : LC-display monochrom
Aastra 612d: TFT-Colour display
• 1 three - coloured LED
• Illuminated Keypad 610d
• Dim function
• 2 programmable soft keys
• 2 programmable navigation keys
• 2 volume keys

Features 610/612d
Audio
• 44 polyphone (Midi type) ring tones
with automatic volume control
• Hands free mode
• Ambient noise filter for loud
environments
Interfaces
• Headset connector (2.5 mm jack)
Local features
• Phonebook with 200 entries
• Redial (20) and caller (30) list
• 12 Display languages

Features 620/622d and 630/632d
Standards Batteries
• DECT / GAP • Li-Ion Battery Pack 850 / 1800 mAh
• Firmware download over air or PC • Intelligent Battery Management
• At least 12/24 h talk time with 850/1800 mAh, EMEA
Housing • At least 15/30 h talk time with 850/1800 mAh, US
• Protection class IP 50 / IP 65 (620d/630d) • At least 100/200 h stand by time with 850/1800 mAh,
• Rubber armed (630d, only) EMEA
• Drop-resistance: 1.7 / 2 m (620d/630d) • At least 95/195 h stand by time with 850/1800 mAh, US
Display, Keypad (module)

• 2" Colour TFT display (65,536 colours)
• 1 three - coloured LED
• Illuminated Keypad
• Dim function
• 8 programmable keys: 620d
1 Hotkey, 2 Soft keys, 3 Side keys,
2 Navigation keys
• 1 Emergency key (630d, only)

Features 620/622d and 630/632d
Audio
• 44 polyphone (Midi type) ring tones with
automatic volume control
• Hands free mode
• Ambient noise filter for loud environments
• Trembler for vibra-call
Interfaces
• Headset connector (2.5 mm jack) 630d
• Bluetooth interface (speech)
• USB
Local features
• Phonebook with 200 entries
• Redial (30) and caller (50) list
• 12 Display languages
• Man down, no movement and escape
alarm (630/633d, only)

Aastra 630/633d Alarm Handling
The Aastra 630/633d has a emergency key and integrated alarm sensor.
The alarm triggers can also be used with a GAP DECT system.
Using a GAP system may cause restrictions, because possibly the

emergency number cannot be dialed in every state of the handset.
Depending on the DECT system, the configuration can be distributed.
The alarm settings can be configured using Emergency Key

Menu > security > (PIN: 0000) > alarm sensor
- Alarm auto answer

- Alarm tone
- Handsfree in alarm
- Pre alarm (Off, 10, 20, 30, 45, 60, 75 sec)
- Repeat alarm (Off, 5, 10, 20, 30, 45, 60, 75, 120, 240 sec)

Aastra 630/633d Alarm Trigger
Emergency Key
if the emergency key is pressed, the handset dial the emergency number
Mandown
is triggered when the device is no longer in vertical position (< 45°)
- configurable delay 1, 2, 5, 10, 20, 30, 45, 60, 75 seconds
No movement
is triggered when the device is not in motion anymore
- configurable delay 10, 20, 30, 45, 60, 75 seconds
- configurable sensibility low, medium, high
Escape alarm
is triggered when the device is in dynamic (hectic) motion
- configurable delay 10, 20, 30, 45, 60, 75 seconds
- configurable sensibility low, medium, high

600d/c Features – Dial Editor, Call Distinction
alphanumeric dial editor
Some call servers use names as telephonenumbers e.g. “tom” instead of “311”
For this reason the dial editor mode can be configured to allow alphanumeric char.
Go to “>>>” > System > Subscription > “System” > “>>>” > Character set.
Available modes can be selected if supported by the DECT system.

e.g. 123.. , 123 …ABC, 123…ABC…aüö, ABC…123, ABC…äüö…123
In the dial editor the user can switch the mode by using * (long press * to get star)
external / internal call distinction by ringtone
The 600d/c handset allow to configure ringtones for internal and external calls.
To distinguish the call type a prefix for external calls and the length of internal
numbers can be configured in the handset.
Go to “>>>” > System > Subscription > “System” > “>>>” > External / Internal call.

600d/c Features – SD Card
With the firmware 4.0 an optional micro SD card is supported.

Using this card, handset settings can be transferred between
devices by the user, if the user’s handset is broken.
Requirement: 620d / 630d hardware version 2 or higher.

(all versions of 622d, 632d, 650c are supported)
Check for the hardware version “HW: “ in the handset menu

“>>>” > System > Version Info
All subscription and device data on the card is encrypted and copy-protected.
Commercially available microSD cards are not recognised!
Do not use the card with other devices (e.g. cameras). This ensures the card is not
accidentally reformatted and that sufficient storage space is available.
The card can no longer be used with portable parts if it has been reformatted
or data has been deleted
600d/c Features – SD Card (2)
As soon the handset is running with micro SD card, handset settings as:
System -> Subscription / IPEI / Auto search

Settings -> Display (except "Brightness")
Settings -> Illumination (except "LED indications")
Settings -> Device options
Time / Alarms -> Format settings
Audio (except "Noise detection", "Loud environment", "Volume" / "Melodies" for Messages)
Personal directory, VIP-list
Programmed keys
are transferred to the card and only used from the card from that time on.
If your handset is already subscribed, the device IPEI will be exchanged with the
IPEI on the card. This allows to operate the device also if the card is removed later
and avoid trouble from copied and dublicated IPEIs.

600d/c Service Abilities
Software Version: Menu >>> * 1 # software version

Site Survey Mode: Menu >>> * 2 # handset
Version firmware
(same procedure to switch mode off) Container: 3.03
Battery: Menu >>> * 3 # BT: 1.2.1 / n.a bluetooth
USB Mode: Menu >>> * 4 # SW: 128.4.4 software
Language: Menu >>> * 5 # HW: 3 (activate BT)
hardware
for service and support only: revision
site survey mode
Service Mode: Menu >>> * * * 76 #
> Version Info RFPI 1018721100 = connected FP
> Auto Call Test FE PP: 0 FP:0 = frame errors
> Auto Answer Test RPN 00 01 02 = RFPs (4) in
> Site Survey dBm: -30 -70 -53 area + signal
> Battery
> Master Reset
Site survey mode include also
The Aastra 62xd / 63xd USB interface - active encryption
can be used for software updates - XQ ability
- XXL PARK
and to modify the personal directory.
Bibliography
SIP – DECT solution is described in a variety of documents:
SIP – DECT: OM System Manual (Installation, Administration, and Maintenance)

SIP – DECT: Aastra 6xxd Messaging & Alerting Applications User Guide
SIP – DECT: OM Integrated Messaging & Alerting Application
SIP – DECT: OM Locating Application (Installation, Administration & User Guide)
SIP – DECT: OM Handset Sharing & Provisioning Installation & Administration
SIP – DECT: OM User Monitoring
SIP – DECT: OM Compendium
Aastra 600d/c SIP-DECT User’s Guides
OM Application XML Interface (OMAXI) via Aastra A2P2
600d/c Terminal XML Interface via Aastra A2P2

SIP-DECT® 4.0
module 4: troubleshooting Training
Module 2: Advanced Training
Power over Ethernet Paging areas

RFP Start Up & application flowchart XQ for Reflective environment
OMM Configurator (reset cookie, proxy) Wideband Audio / CAT-iq
RFP Configuration files (ipdect.cfg) Sync over air startup
OMP – OM Management Portal LDAP Directory and digit treatment
Base station organisation / topology Simple Network Management Protocol
Quality of Service (VLAN and IP header) Feature Access Codes (FAC)
Advanced SIP settings Device and user data relation
SIP DECT® Conferencing User data import
OMM Resiliency User login / logout
OMM Standby / failover Automatic Database Import / Export
OMM Software Update OMM Linux Server (PC OMM)
Download over Air OpenMobility Application XML Interface
configuration scripts / import files Handset Terminal XML Interface
RFP enrolment / export Wireless Local Area Network (WLAN)
XXL DECT – PARK

PoE - Power over Ethernet
support the Power over Ethernet Standard IEEE 802.3af

RFP 34/36/37 require PoE (no power adapter jack)
If the switch does not support PoE, an Midspan Adapter can be used.
Power sourcing equipment (PSE) must support class 3 (for RFP 32/34/42 class 0)
IEEE 802.3af power classification
Class mode Power in watt
RFP 32/34/42 0 Default 0.44 bis 12.95

1 Optional 0.44 bis 3.84
2 Optional 3.84 bis 6.49
RFP 35/36/37/43 3 Optional 6.49 bis 12.95

Start Up - Options
VLAN can be configured without static IP configuration

Up to 3 TFTP Servers can be configured (random selection to distribute load)
one preffered TFTP Server can be configured, if this fail the Server list is used.
Multicast TFTP download (decrease network load and faster startup)(RFP 32/34/42)
Multiple LEDs are used to display the present actions while booting
RFP configuration files can be applied from configuration server (ipdect.cfg)
RFP 32/34/42
The Booter will automatically update with Software Updates and
do not downgrade if an older Software is activated afterwards.
LED 1: The Booter Phase is running as long this LED is RED

LED 2: Display if a local configuration is active (Orange) 4
3
2
LED 3: Display if a Multicast Download is running (Orange) 1
If a RFP work on a older booter version than required for a new feature,
it will start working with the new feature after the automaic booter update.
Start Up - Supported Parameters
parameter Description DHCP OMCFG mandatory type

IP-Address RFP IP-Address IP-Address yes yes ip-address
Net mask Subnetmask option 1 yes yes ip-address
Router Default Gateway option 3 yes yes ip-address
TFTP server IP Address of the TFTP next server yes yes on RFP ip-address
address Server with the RFP image 32/34/42
TFTP file name path to RFP image file boot file name yes yes on RFP string
/omm/omm_ffsip.tftp 32/34/42
OMM IP addr. IP of the OpenMobility option43/code10 yes yes or use ip-address
Manager ipdect.cfg
2nd OMM IP IP of 2nd OpenMobility option43/code19 yes no ip-address
addr. Manager
Country country dial tone (number) option43/code17 yes no integer 16
Syslog IP IP address of syslog server option43/code14 yes no ip-address
address
Syslog Port Port of Syslog Server option43/code15 yes no integer 16
e.g. 514

Start Up - Supported Parameters (2)
parameter Description DHCP OMCFG mandatory type

NTP Server IP-Address of NTP Server option 42 yes no ip-address
address
NTP Server DNS name of NTP Server option43/code18 yes no string
name
DNS address IP-address of DNS Server option 6 yes no ip-address
DNS domain domain name option 15 yes no string
configuration RFP config file server for option 66 yes no string
file server ipdect.cfg and mac.cfg (or option 233)
TFTP server list List of TFTP Servers option 150 yes no ip-address
(random selected)
preferred use next server for boot, n.a. yes no -
TFTP Server if this fail the list is used
VLAN ID VLAN ID for this RFP option 132 or 225 yes no integer 16
use VLAN and enable VLAN and use DHCP n.a. yes no -
DHCP
core dump enable core dump n.a. yes no -
import URL URL to Import the OMM DB option43/code24 yes no string
magic_str “OpenMobilitySIP-DECT” option 224 - yes string
Start Up - DHCP Example (3)
SIP-DECT dhcpd.conf example (extraction)

### SIP-DECT options definition ### subnet 192.168.11..0 netmask 255.255.255.0
option space SIPDECT; { pool { range 192.168.11.181 192.168.11.199;
option SIPDECT.omm-ip code 10 = ip-address; allow members of "SIP-DECT2G";
option SIPDECT.omm-syslog code 14 = ip-address; allow members of "SIP-DECT3G";
option SIPDECT.omm-syslog-port code 15 = unsigned integer 16;
option SIPDECT.country code 17 = unsigned integer 16; option routers 192.168.11.1;
option SIPDECT.ntpsrvname code 18 = text; option subnet-mask 255.255.255.0;
option SIPDECT.omm-ip2 code 19 = ip-address; option ntp-servers 192.168.11.7;
option SIPDECT.importurl code 24 = text; option domain-name-servers 10.103.2.4,192.168.11.5;
option magic_str code 224 = text;
option tftp-list code 150 = array of ip-address; next-server 192.168.11.7;
option vlanid code 132 = unsigned integer 16; vendor-option-space SIPDECT;
option magic_str = "OpenMobilitySIP-DECT";
### class definition for filter allow members ### option SIPDECT.omm-ip 192.168.11.180;
# RFP (L) 31,32,33,34,41,42 #option SIPDECT.omm-ip2 192.168.11.180;
class "SIP-DECT2G" { match if option vendor-class- #option SIPDECT.country 1;
identifier = "OpenMobility"; } option SIPDECT.omm-syslog 192.168.11.5;
# RFP (L) 35,36,37,43, since firmware 3.0RC3 if option vendor-class-identifier = "OpenMobility" {

class "SIP-DECT3G" { match if option vendor-class- filename "/openmob/iprfp2G.tftp"; }
identifier = "OpenMobility3G"; }
if option vendor-class-identifier = "OpenMobility3G" {
filename "/openmob/iprfp3G.dnld"; }
#option tftp-server-name "tftp://192.168.11.5/config/";

Aastra confidential information / for training purpose only
…
© Aastra - 2013 91
Start Up - Virtual LAN (802.1q) Configuration
VLAN is used to separate logical networks on the same physical infrastructure.

This is most times used to save costs, improve security, improve network quality
and for network design / deployment reasons.
An VLAN ID can be configured for each RFP using one of the following senarios:
RFP has an active local Configuration including VLAN ID (lcfg + VLAN ID)
RFP has no active Configuration but VLAN ID + Use VLAN and DHCP is set
RFP receive an VLAN ID option via DHCP during the Start UP

If DHCP option 132 or 225 is received via DHCP with an VLAN ID,
the RFP enable VLAN and start an new DHCP discover using this VLAN ID.
In the booter phase the RFP reply to

OM_Configurator request with the VLAN ID
which is used in the request packet.
Start Up - Booter 3.4 Multicast (RFP 32/34/42)
To decrease the boot time and network load the booter support Multicast TFTP.
If this is supported by the TFTP Server the base station use IGMP to join the
multicast group and start the multicast download.
The base station have an integrated fail over to unicast, if an Multicast TFTP
download was started but no packets has been received by the base station.

OMM Configurator – Reset to Factory Default
once a RFP is connected to a running system, the OpenMobility Configurator

access is protected by the system Full Access username and password.
Also if the RFP has no connection to the OMM anymore.
If the basestation is connected to a new system, the login automaticly update.
To delete all stored informations from the RFP (local cfg, login and user data)
enter the login data (only if set) and click on factory defaults
If no valid login was send to the RFP,

the basestation response with a cookie.
contact your support with this cookie

to get a reset key for this basestation.

OMM Configurator – Proxy Function
Using the OMM Configurator, local settings of base stations can be configured
in the following senarios:
using MAC address
UP connect the PC to the same network
Switch Boot (layer 2) as the base station (RFP). RFP can
be in an booter (wait for cfg) or operating state
using MAC address + RFP IP address

UP connect the PC to the same network
Router (layer 2 or 3) as the base station (RFP).
RFP need to be in an operating state
UP Proxy RFP target RFP

UP
Router Proxy RFP forward
Boot packets to target RFP
using MAC address of target RFP + IP address of Proxy RFP + select Proxy checkbox
connect the PC to the same network (layer 2 or 3) as the base station.
The RFP selected as proxy (every RFP can be selected) need to be in an operating state.
The target RFP can be in an booter (wait for cfg) or operating state.
RFP Configuration File (ipdect.cfg)
In addition to providing start up information by DHCP or the OM Configurator (OMC),

RFP configuration files can be used. There are common (ipdect.cfg) and
RFP specific (<mac-address>.cfg) configuration files.
If a Configuration File Server is set by the OM Configurator or using DHCP,

the RFP load this file on start up and within the interval configured in the files.
DHCP Server with 1) Start up configuration using DHCP or a local configuration

common settings which include a configuration server URL.
Configuration Server 2) fetch the ipdect.cfg and <mac>.cfg (if configured) files using
with config files ftp(s), http(s) or tftp, containing the installation specific details.
This parameters will overwrite already set parameters
3) The base station does apply the new parameters,

OMM start up and connect to the configured OMM.

RFP Configuration Files
A configuration server can be configured using DHCP or the OM Configurator.

The following parameter need to be configured for the start up:
IP address, Net mask, Gateway, Boot file name, TFTP server, DNS (if required),
Configuration file server and by using DHCP option 224: OpenMobilitySIP-DECT.
Configure the URL of the Configuration file server (DHCP option 66) using the
syntax: {http(s)|ftp(s)|tftp}://[[user:password@]servername]/[directory]
On the configuration server a ipdect.cfg file is required (mandatory).

If configured there can be also <mac>.cfg file for specified base stations.
As soon a RFP specific configuration file are enabled they are mandatory to.
If mandatory files can not be loaded from the server, the RFP do not start up !
This is relevant for RFP boot / start up (after power on, SW update)
or if the configuration server URL was changed.
RFP Configuration Files (2)
If an parameter is provided by more than one of the possible ways,

the last setting has priority. There is the following order: DHCP / OM
DHCP or Local Configuration < ipdect.cfg < <MAC>.cfg Configuratior
(It is also possible to remove settings “paramter”=)
ipdect.cfg
Configuration files are read at the following times:
RFP reboot, Restart of an application e.g. OMM,
DHCP renew and DHCP bound, Configuration changes <MAC.cfg>
via OM Configurator and RFP configuration file update check
RFP configuration file update check has the following characteristics:

The interval is configurable in the RFP configuration files
• Minimum interval: 5 minutes
• Maximum interval: 7 days
• Default interval: 24 hours
• Both RFP configuration files are checked if relevant

RFP Configuration Files (3)
If configuration file(s) cannot be received by a base station in operating state:
The RFP continues operation with the last successfully received config file(s).
The RFP will re-try to get the configuration files, starting with an interval of
1 minute and doubling this interval with each retry, not exceeding the update
check interval (either default or configured).
If the RFP is using DHCP a renew of the lease is scheduled,

so that possible changes in DHCP configuration will be detected.
Failures in getting the configuration files is reported via syslog.
A change of a parameter (DHCP / OM Configurator, RFP config files) does not

necessarily mean a change of the RFP configuration, because the parameter
could be covered up or previously set by using an alternative way.
Depending on the changed parameter an RFP configuration update is done:
On the fly without any service interruption (e.g. Syslog IP has been changed)
With an application restart (e.g. OMM IP address has been changed).

RFP Configuration Files – sample configuration
1) DHCP # OMM Configurator config file

DHCP active = 1
Server net_mask = 255.255.255.0
tftp_server = 100.100.100.5
tftp_file = omm_ffsip.tftp
2) DHCP gateway = 100.100.100.1
RFP offer with config server omm_1 = 100.100.100.180
config_file_server =
tftp://100.100.100.5/configfiles
3) TFTP download
TFTP data_sequence
of omm_ffsip.tftp
Server 00:30:42:0e:27:1e;;100.100.100.180
….
4) download
ipdect.cfg from Config
configuration server Server
# dhcpd.conf on unix / linux
...
option space OMMSIP;
5) apply configuration option magic_str code 224 = text;
from ipdect.cfg and vendor-option-space OMMSIP;
option magic_str = "OpenMobilitySIP-DECT";
connect to OMM filename "iprfp3G.dnld";
OMM next-server 100.100.100.5;
option tftp-server-name "tftp://100.100.100.5/configfiles/";
...
RFP Configuration Files – ipdect.cfg basic syntax
This example shows how to configure the ipdect.cfg and <MAC.cfg> files (same file syntax).
Create a text file with the name „ipdect.cfg“ on your configuration server directory, configured by DHCP
or OM Configurator. Configuration parameters in this example are blue, optional are italic
# sample configuration file for the OpenMobility system,
# retrieved via the net using file transfer protocols like tftp, ftp(s) or http(s)
# Insert the URL to the folder containing this file into DHCP option 66 (TFTP Server)
# or use the OM Configurator parameter "configuration file server" Insert a URL e.g. ftp://server/path
# comments are starting with the hash sign: "#"

# BOOL variables support the following values
# YES Y 1 TRUE or NO N 0 FALSE (case does not matter) , other values are interpreted as false
# configuration files check interval for checking the remote cfg files in seconds
# minimum value is 300 (5 minutes) maximum value is 604800 (7days)
OM_ConfigCheckInterval=300
# personal configuration files have the following name <OWN-MAC>.cfg e.g. 003042ABCDEF.cfg
# all RFPs will also load the <OWN-MAC>.cfg file if this parameter is set to yes(,y,1) there have to be a valid mac.cfg!
#Until the MAC is excluded with OM_PersonalConfig_<MAC>=n
OM_PersonalConfigAll=n
#DO load the individual file for the RFP with mac 003042FFF0D0 no matter what OM_PersonalConfigAll says
#OM_PersonalConfig_003042FFF0D0=y
#DO NOT load the individual file for the RFP with mac 003042ABCDEF no matter what OM_PersonalConfigAll says
#OM_PersonalConfig_003042ABCDEF=n
RFP Configuration Files – ipdect.cfg configuration
# OpenMobility system
OM_ManagerIpAddress1=100.100.100.180
#OM_ManagerIpAddress2=100.100.100.181
OM_ManagerCountry=2
#OM_ManagerDownloadOverAirUrl=ftp://server/pub # URL to the directory with the A600d firmware aafon6xxd.dnld

#OM_ManagerRestoreDbUrl=tftp://server/folder/OMMDATABASE.gz
#OM_SwImageUrl=ftp://server/openmobility/iprfp3G.dnld # SW Download for RFP 35/36/37/43 if you don‘t use TFTP
#SYSLOG
#OM_SyslogIpAddress=100.100.100.228
#OM_SyslogPort=514
# NTP
#OM_NtpServerName=de.pool.ntp.org
OM_NtpServerIPAddress=131.188.3.220 130.149.17.21
#Core dump
#OM_CoreDumping=y
#OM_CoreFileSrv=100.100.100.5
#OM_CoreFilePath=/corefiles/
# to remove parameters e.g. delete a ipdect.cfg common setting in the <mac>.cfg use parameterxy=
RFP Configuration Files – verification and tools
Problems with importing the configuration files will be reported by syslog.

To read the last applyed configuration use the ssh remote access to connect to an RFP.
omm@100.100.100.180 > rfpmconsole

Welcome to the rfpm console, use ? for a list of possible commands
rfpm# env
OM_NtpServerIPAddress=131.188.3.220 130.149.17.21
OM_ConfigUrl=tftp://100.100.100.5/configfiles/
OM_RfpInterface=br0
OM_RfpIPAddress=100.100.100.180
OM_TftpServerIpAddress=100.100.100.5
OM_TftpServerBootImage=omm_ffsip.tftp
OM_RfpDrivenBy=DHCP
OM_DhcpLease=86400
OM_ConfigCheckInterval=300
OM_PersonalConfigAll=0
OM_ManagerIpAddress1=100.100.100.180
OM_ManagerCountry=100
OM_SyslogIpAddress=100.100.100.228
OM_SyslogPort=514
OMP – OM Management Portal
Specially for the requirements of big installations the OMP Suite is developed.
OMP has an configuration and monitoring mode .
It include additional functions which has not been introduced on the webservice.
Other parameters are currently only available on the OMM web service.
OMP require Java 1.6 (JRE) to run. If jar files are not linked to Java on
your computer, use „java –jar OMP.jar“ from a terminal to start this tool.
OMP connect to the OMM using the OMM Application XML Interface (port 12622, TCP)
using the same login credentials as on the Webservice.
On a linux system preferences are stored in the

users home directory ~/.java/.userPrefs/…,
on a windows system in the registry node
HKEY_CURRENT_USER/Software/JavaSoft/Prefs/…
OMP has no automatic logout (as the webservice) and

the OMM allow multiple logins at the same time.
OMP – OM Management Portal (2)
configuration and running OMM tools for language

monitoring mode software version and spy settings help: EULA,
OMP version
and spy console
system process
status overview
inactive or unknown
error
warning
ok
status for actions link status

and operations to OMM
status bar with PARK connected
and subscription state broken
OMP allow the user to customise the view on some configuration

sections using the actions in the tasks bar on the right side of OMP.
With select colums you can sort out information out of an record.
Select colums
To reduce the amount of records the filter function can be used.
configure multiple entrys at once
The OMP feature set has been enhanced to now cover all mayor features
offered by the OMM Web Service, in addition to new features only covered by OMP.
The Web service still remains on a limited feature set, so that basic installations
can also be performed with web browser only and accepting lack of some
parameters in configuration interface. (for simple setups)
Currently the following parameters can be configured with Web service only and
are not supported via OMP: WLAN configuration, Time Zone, SNMP, Event log,
capture unconfigured RFPs and handset import (CSV).
OMP – User Management
In addition to the default accounts, OMP allow to create new accounts.

These accounts can be used by OMP and connected OM AXI applications.
Accounts can also have customised permissions now.
OMP > System > User Administration
Read OMM data (OM AXI get requests)

Read OMM data (OM AXI set requests)
Sent messages with prio „Info“
Sent messages with prio “Low”, „Normal“, “High”
Sent messages with prio „Emergency“
Sent messages with prio „LocatingAlert“
Permission to query the position
of PPs and to track PP positions
Permission to monitor various
technical aspects of the mobility system
Video = Permission to access Video Cameras
Base Station Organization / Topology
To keep the overview in large systems an structure containing

Site > Building > Floor > Room > Name can be used.
The structure is used for

Site
sorting and filters Building
modifyed views Floor
monitoring Room
tracking applications
RFP Name
each base station structure can be
configured using OMP > Radio Fixed Parts
Base Station Organization / Topology (2)
HQ (Site) Office1 (Site)

Tower 2 Office (Building)
(Building)
Tower 1 Office2 (Site)
(Building) Cluster 2
PA4 Office (Building)
Cluster 3
DECT Cluster 1 PA5
Object’s Equals to use for

Tower1
PA3 Site Location Wideband,
Digit Treatment
3
Building / Organisation OMP, OML
Floor
2 Floor / Units as structure

Room
1 Paging Area Traffic areas DECT paging
PA1 PA2 Cluster Syncronisation handover

Quality of Service (QoS)
In a network a situation can occur, that a device receive more Information then it can forward.
In this overflow situations the device. e.g. a router will drop packets who can not be forwarded.
QoS give the forwarding devices

the ability to decide which packets
are how Important. By default all
packets are forwarded with the
same priority.
The device classify the traffic on

parameters in the packet headers
like ToS / DSCP, IP-ranges, Ports, ...
Afterwards the device will forward

packets by the given priority and
configured flow.
classify > prioritize > queuing > forwarding
Quality of Service (QoS)
signalling and voice packets from the OMM and base stations
are marked with ToS (Type of Service) values in the IP header.
The values can be modifyed by using the OMM webservice

system > system settings
Example:
If VLAN tagging is enabled on an base station, prioritys will

also be set in Layer 2 using the VLAN header (IEEE 802.1p)
By default packet lost and high jitter is reported in the OMM syslog:
MSM : 2% packet loss / 290ms jitter detected from 192.168.10.10 to 10.103.11.21 (number: 4217)
Advanced SIP Settings – DNS SRV
SIP-DECT® can resolve the SIP Proxy, Registrar and Outbound Proxy using
DNS Service Records e.g. for Load Distribution at Internet Telephony Providers
DNS 2) DNS Response:

Server Server A / prio: 0 / weight: 1
Server B / prio: 0 / weight: 5
Server C / prio: 10 / weight: 1
2
1 Server A 3) SIP Register:
1) DNS Query: 3 Register for Domain
OMM Type: SRV Server B send to Server A
_sip._udp.domain.xy if this fails register
Server C on Server B, …
OMM performs DNS-SRV on FQDN before the SIP transaction starts,

if the port “0” is configured (default: 5060) for the server entry.
If there is no answer within the transaction time, the OMM tries the next server.
DNS SRV records are sorted ascending by priority / weight
To prevent loops while retrying, the OMM blacklists servers (default timeout: 5min)
Advanced SIP Settings – Backup Settings
In addition to the primary SIP Registrar and Proxy(s), the OMM supports up to two
additional backup levels called secondary and tertiary. If the SIP transaction e.g.
REGISTER or INVITE to the primary fails, the OMM retries with secondary and tertiary.
OMP > System > SIP > Backup Settings Server A Server B
1 2
OMM
The OMM tries to register with the primary on each reregister e.g. if primary failed
As soon reregistration to former failed servers (e.g. primary) succeed,
the SIP User Registration, MWI, Invites are refreshed.
If no SIP registration exists, invites are send to primary, then secondary, then tertiary.
Advanced SIP Settings – Register Redirect
The OMM allows SIP call servers to spread SIP registrations

e.g. for load distribution and failover scenarios on multiple servers.
This can be done using SIP 301 (Moved Permanently) or 302 (Moved Temporarily).
If the response contains multiple contacts the OMM tries them successively.
1) Registration Server A
Send SIP Register for
user s 10,20,30 10
to primary SIP registrar server
10 > OK
2) SIP Server response 1
301 Moved Permanently 20 > move to B
contact:<Server B> … 10
30 > move to C
20
3) Redirected Registration 2
30
SIP Register on redirected Server B
Server contact(s) 3 20
20
OMM 3 30 Server C
30
Advanced SIP Settings – Failover Keep Alive
Failover Keep Alive
Using SIP (re)registrations the OMM checks the availability of SIP call servers.
If Failover Keep Alive is enabled the OMM forces SIP reregistrations within
the configured period (1-60min).
If the reregistration fails or a former failed primary server becomes available again,
all affected registrations will be refreshed to move SIP users to the next available
server (check order: primary, secondary, tertiary).
OMP > System > SIP > Backup Settings:
Prioritized Registrations
Parallel SIP registrations of many Users e.g. during Start Up can take some minutes.
Within this time the users are not reachable for incoming calls.
To prioritize the registration of important Users e.g. emergency users

the attribute „VIP“ can be set in the User configuration. (OMP > Portable Parts)
Advanced SIP Settings – Sample Setup: Migration
PBX migration
Using Backup Settings one OMM can be connected to multiple independent SIP servers.
Registrations which fail on the primary server will be reregistered on the secondary.
1) Registration 10 11 20 22
Send SIP Register for all Users to Trunk
the primary SIP registrar server PBX A PBX B
2) SIP Server response
The PBX A only allow some (known) Users 3
10
to register, other users fail. (SIP: 603 decline)
1 11 20
3) Failover Registration 10 20 22
The OMM try to register failed Users to 11 22
the secondary (and tertiary) SIP server. 20 2 20
4) Successful Registration 22 22
The PBX B successfully register the Users.
OMM 4
Notice:
- all reregistrations will go to PBX A, failed User registrations then go to PBX B
- Features can not be configured specific for each PBX e.g. XML call list, SIP settings, Digit Tr.
- The SIP Failover Keep Alive function needs to be disabled. (default)
Advanced SIP Settings - Semi-Attended Transfer
The SIP Semi-Attended Transfer allows the transferor to start the transfer while
the target phone is still ringing. The behavior of such a semi-attended transfer
can be configured at OMP > System > SIP > Advanced settings
S.-A. T. Refer-to with Semi-Attended Transfer behavior

mode replaces
Blind No handled as a blind transfer. The phone sends CANCEL
before REFER for semi-attended transfer. (Default)
Blind Yes handled as a blind transfer. The phone sends REFER
with Replaces for semi-attended transfer and no CANCEL.
This behavior is not SIP compliant but required for some PBX.
Use this mode only if required by the PBX platform e.g. A5000.
Attended - handled as an attended transfer. Both lines of the transferor
remain active until the transfer succeeds.
This behavior is compliant to RFC 5589.
Advanced SIP Settings – Misc.
Failover to OMM
In case the OMM is connected to one SIP Server

a local failover can be configured to establish calls
between Handsets if the SIP Server is unavailable. OMM SIP Server
To use this feature configure 127.0.0.1 as secondary

or tertiary SIP proxy. (no registrar Server required)
OMP User Status
OMP allows to display the SIP Status of each User.

OMP > Monitoring > Portable parts > Overview.
Advanced SIP Settings – Misc. (2)
Display Diversion Indication (RFC 5806) from the SIP server

Support of SIP “Reason” header field (RFC 3326) e.g. call completed elsewhere
P-Asserted-Identity is received also in ringing state (update display and call log)
X-Aastra-Id header (include terminal type, model, IPEI and software version)
Call Completed Elsewhere Diversion Indication
1) Incoming call to multiple devices 1) Jim (100) calls Bob (200)

2) One terminal hooks off 2) Bob (200) is diverted (busy) to Jenny (300)
3) Send reason to the other terminals
e.g. no missed call
user-busy Bob (200) Jim
1 >>200 Diverted >>200
300 to Jenny
2
SIP
Server 3 Jim (100) Jenny (300)
SIP DECT® - Conferencing
SIP-DECT® can initiate 3-way conferences by A600d/c and A142d handsets.
This conferencing feature base on the RFC 4579.

SIP-DECT® integrated conferencing resources and compliant
3rd party conference servers e.g. Broadsoft or Sylantro, can be
configured to link the media streams of the connected parties.
SIP DECT® Users can initiate a conference via the handset menu.
The OMM automatically allocate available conference resources.
A A A call B, B hook off
B C B C A put B on hold
A call C, C hook off
A initiate “3 party”
A,B and C are (blind)
transferred to the
D SIP URI Conference Room D
or a External SIP URI
Integrated Conference External Conference
Room on dedicated RFPs Server (RFC 4579)
SIP DECT® - Conferencing (2)
OMP > System > SIP > Conference

Select the default Conference Server type for this system.
Integrated = Use OMM Conference Rooms and RFP Media
External = Use External Conference Server via SIP URI
OMP > Conference Rooms (Integrated mode only)

Create Conference Rooms (one conference per room).
Each Room is a SIP User account and register to the PBX.
Conference attendees will be transferred to these rooms.
OMP > Radio fixed parts > Device List (Integrated mode only)
Dedicate RFP’s (35,36,37,43) to host conference channels.
OMP > Portable parts > Overview / Users

The conference type and URI can be configured per User.
Default: All Users use the System > SIP setting “Global”.
To use external conference services e.g. a conference server or PBX

with the SIP-DECT® Conferencing feature, setup the URI of the
conference unit in OMP > System > SIP > Conference (template for all users)
or user specific in OMP > Portable parts > Overview / Users
The configuration depend on the conference server / PBX product.

The URI should point to a proxy or media server, see the call server
documentation for more details. URI samples:
• conf@<proxy-server-address>:<proxy-port> (Sylantro)
• Conference@<proxy-server-address>:<proxy-port> (Broadsoft)
Integrated Conference requirements:
To use integrated conference Rooms the call server need to allow 3 simultaneous
incoming calls for each SIP Conference Room User. OMM support up to 100 Rooms.
Conferencing should be verified with the Call server prior the first productive usage.
RFP Media Conference resources

DECT Confere G.729 Conference DECT
enabled ncing enabled channels Voice
enabled channels
Yes No Yes/No 0 8
Yes Yes No 15 8
Yes Yes Yes 3 5
No Yes No 24 0
No Yes Yes 9 0
Activating “Conference channels” on a RFP with enabled DECT in a system with

enabled G.729 reduce the available DECT channels on that RFP from 8 to 5 !
If G.729 is not required, remove G.729 from the Codec List in System > SIP.
OMM Resiliency
The OMM can be configured in resiliency mode. PBX /

In this mode two basestations are defined as OMM. Callserver
DHCP Option 43:
option code 10
option code 19
OMM OMM
If the active OMM fail, the standby OMM get active (standby) (primary)
and all RFPs connect to the new active OMM.
All RFPs will restart (softreset). 2nd OMM IP OMM IP
If the failed OMM come up again, he will be the standby.
As long the primary OMM is failed, configuration changes

are done unsafe (can be overwritten if primary is back).
A Resiliency with a RFP and a PC OMM is not possible, RFP RFP
(only RFP <> RFP or PC <>PC)
OMM Resiliency – Senario (1)
1. primary OMM (.56) is active,

standby (.57) is synchronized
2. primary OMM (.56) is offline,
standby (.57) is active
3. New primary OMM (.57) is active,
standby (.56) is synchronized
fall over occurs in following situations:

- an OMM error occurs on the active OMM
- active OMM is rebooted at the ssh console
- the OMM is rebooted in the web service.
the standby OMM becomes the active OMM in the following situations:
- The configured SIP Proxy/Registrar is reachable and
- The active OMM is not reachable / not up
If both OMM's are not active (normally at system start up),

the OMM with the lower IP Address become the primary one.
If the primary OMM is active and the standby OMM lose the connection to the
primary OMM e.g. because of a issue in the network, both OMM‘s become active.
In this case both systems are working parallel. (If the callserver / PBX is reachable)
2nd OMM
OMM
As soon the connection beween
both OMM‘s is recovered, the
longer running OMM keep active.
The other OMM switch to standby.
If you like to add a OMM Resiliency to a running single OMM System,

you have to make sure that the new OMM (2) is not up & running
with a Plug&Play configuration and overwrite the configuration of the
configured OMM.
The update can be done with the following steps:
1) Backup your configuration of the running OMM (1)

2) Disable the new OMM (2) base station, by power off the RFP
3) Apply the OMM-2 IP option to the OMM (1) and the other RFPs
4) Wait until the OMM (1) is up an running again
5) Start UP the new OMM (2) with the right OMM and OMM2 IP options
OMM Standby / Failover
If the primary OMM fail or restart e.g. because of an software update,

the Standby OMM get active and all base stations connect to this OMM.
If this failover is done within 20 seconds, the DECT syncronisation stay active.
In this case the RFPs can connect to the OMM and keep in service, without the
need to restart or resync. Active calls will be dropped during this failover.
The downtime is noticable shorter than in former update and failover senarios.
The total downtime depend mainly on the following parameters:
stable synconisation of the system (no need to resync RFPs)

call server performance (handset registration on the call server after restart)
network speed
TFTP Server speed, blocksize, multicast ability (in case of an software update)
OMM Software Update
Software updates are tiggered by the RFP image check (compare image checksums)
or if an update is initiated by the Operator e.g. using the OMM webservice
Update and Restart are initiated in System > System settings
If a different SW Version is detected, the OMM restart the Standby OMM (if present).
As soon the Standby OMM is updated and up, the active OMM restarts (calls drop)
and all RFPs connect (failover) to the new active (already updated) OMM.
Afterwards the OMM restart the base stations one by one while observing there
sync relations. So the system sync is still stable during the update. A concurrently
update of all base stations can be configured to restart all RFPs at once.
If there is a mayor version difference, RFPs will be forced to update instantly.
The software update check is also done, while restarting the OMM.
e.g. for senarios without standby OMM
The Update status is shown in the OMM Webservice.

RFPs waiting for an update approval are marked yellow.
RFP Software Update Modes
With SIP-DECT® Release 4.0 the RFP Software Update Mode can be configured.
Successively:
RFP updates are initiated per Cluster RFP by RFP (Default Mode since Rel. 2.1)
Pro: Availability during the Update Contra: Update take some time
Concurrently:
All RFP updates are initiated at the same time. (Default Mode in Rel. 1.x)
Pro: Fast Update Contra: System downtime
The Update mode can be configured in the OMM Web service.
In addition a Trigger can be configured, at this time the RFPs

will restart with the new Firmware. A manual or times update
check need to initiated before the triggered time.
Download Over Air
Aastra 600d/c handsets update the handset firmware from the OMM via DECT.
Downloading new firmware to portable parts is enabled by default and will start
15 minutes after the system is up. The status is displayed on the status page.
If this feature is active, the OMM load the handset software aafon6xxd.dnld from
the tftp server where the base station software (e.g. iprfp3G.dnld) is located.
You can activate this feature in the system settings:
Download Over Air (2)
As soon the OMM download the handset software, the version number is shown.
The handset will check if the provided firmware is different.

If yes the handset request a version file and check what software parts changed.
The handset initiate the download procedure to update the new parts.
The Status page provide a summary of the handset status.
In the portable parts section a detailed

status for each handset is shown.
Download Over Air (3)
Download over Air details
- download over Air start 15 minutes after the system is up

- the system provide 30 handset downloads at the same time (PC OMM: unlimited)
- one basestation can handle up to 6 downloads at once (depend on calls)
- the PP hold up to 2 different software version, a switch back is possible
- the download happens without any user intervention or user interruption.
- during download, the telephony services, roaming- and handover are survived.
- the download stops automatically if the PP leave the coverage area or the RFP is busy.
- the download resumes automatically when the coverage area is available again.
- a full software download for one handset take about 180 minutes
- download over Air use the DECT signalisation channel
- download can be blocked on a handset by a menu option
- the handset only download software from the selected master DECT system
handset will download the software only if
- battery power status is adequate (start with minimum 50% battery power, stop at 30%)
- handset is in coverage area and the viewed RFP isn‘t busy
- the current connected system is the master download system
(first subscribed system, can be configured by service mode Menu > ***76# > DOA)
Pre Configuration Scripts
The OMM and the OpenMobility Configurator support the import of configuration files
for handsets, basestations and the local configuration of basestations.
The configuration files are seperated in two sections:
1. Instruction section:
generic data creation for those fields, not filled within data sequence section
2. data sequence section:

defines data record fields. Each of them are explicitly set!
Layout:
- comments start with „#“
- each record is terminated by the regular expressions “\r” or “\n”
- Instruction settings are made like: <tag> = <value>
- data sequence sections starts with “data_sequence”.
All instructions have to be written before this row!
- data sequence record fields are separated by colon “;”.
colons have also to be set for empty fields! (value1;;;value4)
OpenMobility Configurator – Import
The OpenMobility Configurator can search for RFPs and

send configurations from a configuration file to basestations.
Scan: search for all available RFPs in the local LAN segment or via a Proxy RFP
Save RFPs: save the scan result

MAC Address of the RFPs to a text file
Load config: load the configuration file
Run config‘s: send the configuration

from the config file to the basestations
The red and green light show if or that

the RFP receive the configuration.
< ok fail> < resend
OpenMobility Configurator – Import (2)
supported Instructions
All instructions are taken as common value, which are set to all records of
data sequence section of that file if the corresponding field is empty
• active: Local configuration active: {0=inactive(use DHCP instead), 1=active}

• net_mask: Net mask
• tftp_server: IP address of TFTP server
• tftp_file: Path and name of boot file
• omm_1: OMM IP address
• omm_2: IP address of 2nd OMM
• gateway: Default gateway
• dns_server: Up to two DNS server IP addresses
• dns_domain: local DNS domain
• ntp_addr: Up to two NTP server IP addresses
• ntp_name: Up to two NTP server names
• syslog_addr: IP address of syslog daemon vlan_id: Virtual LAN ID
• syslog_port: Listen port of syslog daemon country: Country Code
• broadcast_addr: local broadcast address import_url: URL for the
• country: Country code Automatic Database import
OpenMobility Configurator – Import (3)
Data section fields sample import file:
The data sections contains the following field order: active = 1

net_mask = 255.255.0.0
1. MAC_ADDR
2. ACTIVE_FLAG tftp_server= 172.30.200.92
3. RFPADDR tftp_file = omm_ffsip.tftp
4. NET_MASK omm_1 = 172.30.111.188
5. TFTP_SERVER
6. TFTP_FILE gateway = 172.30.0.2
7. OMM1
8. OMM2 data_sequence
9. GATEWAY
10. DNS_SERVER 00-30-42-01-01-01;;172.30.111.1
11. DNS_DOMAIN 00-30-42-02-02-02;;172.30.111.2
12. NTP_ADDR 00-30-42-01-01-03;;172.30.111.3;
13. NTP_NAME
14. SYSLOG_ADDR
15. SYSLOG_PORT
16. BROADCAST_ADDR
17. VLAN_ID
18. COUNTRY
19. PROXY_OMM
20. IMPORT_URL
RFP Enrolment
The OMM can import basestations from a configuration file (RFP enrolment).
This can be done in the RFP section of the OMM Webservice or OMP.
1. Browse and select the configuration file
2. Import the configuration file to the OMM
The OMM then output the result of the import.
3. check the result and select the records

you want to import to the configuration
and click on Add.
RFP Enrolment (2)
All instructions are taken as common value, which are set to all records of
data sequence section of that file if the corresponding field is empty
location = {<location name>} # -- Location Name

active = {0=inactive, 1=active} # -- Activate DECT
cluster = {0..999} # -- Cluster the RFP is referred to
paging_area = {0..999} # -- Paging area, the RFP is referred to *
sync_source = {0=inactive, 1=active} # -- Synchronisation source
refl_env = {0=inactive, 1=active} # -- Reflective environment
site = {<ID of Site>} # -- ID number of site, need to be existing
building = {<building name>} # -- Building Name *
floor = {<floor name>} # -- Floor Name *
room = {<room name>} # -- room Name *
wlan_profile = <valid reference to an existin WLAN profile>} # -- Reference key to an existing WLAN profile
wlan_antenna = {0=diversity, 1, 2} # -- Antenna settings
wlan_channel_bg = {0..14 (size depends on regulatory domain) } # -- WLAN Channel
wlan_power = { 6, 12, 25, 50,100 (in percent)} # -- WLAN output power
wlan_act = {0=inactive, 1=active} # -- WLAN enabled
* The OMM webservice import will ignore this parameters, they are n.a. on the webservice.
RFP Enrolment (3)
Data section fields
The data sections contains the following field order:
1. MAC address sample import file:

2. Location name
3. DECT active active = 1
4. Cluster cluster = 1
5. Paging Area paging_area = 1
6. Prefered sync source sync_source = 0
7. Reflective environment refl_env = 0
8. Site ID
9. Building data_sequence
10. Floor 00:30:42:01:01:01;Office-ABC
11. Room 00:30:42:01:01:02;RFPB;0;1;2;1;0;1;B;F;R;
12. WLAN profile
13. WLAN antenna
14. Channel_bg
15. WLAN power
16. WLAN active
RFP Export
Configured RFPs can be exported to a CSV file using OMP > RFP > Export.
The exported file can be modified with a text editor or spreadsheet software
and also be imported using OMM RFP enrolment.
(Import does not update or overwrite configured RFPs)
Handset Import
The OMM can import handsets from a configuration file.
1. Browse and select the configuration file
2. Import the configuration file to the OMM
The OMM then output the result of the import.
3. check the result and select the records

you want to import to the configuration
and click on Add.
Handset Import (2)
• start_number
Numbers can be generated automatically. This instruction defines the start value
• no_of_number
If start_number is given, this instruction defines the maximum of numbers which are generated
• ac (authentication code)
If set to “number”, ac will be equal to number. If a value is given it will
be taken as start value which is increased within each generation step.
• additional_pin: see ac
• sip_user: see ac
• sip_pw: see ac
Handset Import (3)
Data section fields sample import file:
The data sections contains the following field order: start_number = 100
no_of_number = 3
1. Number ac = number
2. Name additional_pin = number
3. AC sip_user = number
4. IPEI sip_pw = number
5. Additional ID
6. SIP user name data_sequence
7. SIP password 101;PP 1;;0081008625768
104;PP 4;;0007701154842
;Kiel Phone1;;0127105395099
;Karl May
import output
XXL DECT Systems – PARK
A DECT system is identified using the Portable Access Right Key (PARK).
Part of this PARK is an identifier, which define the possible number
of base stations in this DECT system. (assimilable to the subnet mask in IPv4)
The default system CD PARK does support up to 256 RFPs. (Starting with 1F or 31)
For bigger systems an XXL PARK is required, which support up to 2048 RFPs.
(Changing the PARK will require a resubscription of all handsets.)
With the Aastra 600d/c and 142d handsets handovers can be done within
the full system, as long the RFPs are synchronized another.
GAP handsets are only able to do handovers within an area of up to 256 RFPs.
PARK 256 RFPs
PARK XXL 2048 RFPs

GAP handover
Aastra 600d/c / 142d handover
Paging Areas
DECT devices do not have an active connection to the system in idle.

For this reason base stations send out pagings to initiate connections to idle
handsets over all base stations in the current paging area.
To optimize the paging of handsets e.g. for an higher troughput,

multiple paging areas (PA) can be defined.
The system is able to do 20 pagings within one area at the same time
Handsets announce their movement between paging areas to the system
The number and size depends on the PARK and can be changed using
OMP > system settings > DECT
(max. 256 RFP in one paging area) PA 1 PA 2
PA 1
PA 3 PA 4
single paging area multiple paging area

system system
Paging Areas (2)
By default one paging area with up to 256 RFPs is configured. The number of areas
depend on the configured area size e.g. 16, 32, 64, 128 or 256 RFPs and the system
PARK e.g. in a normal 256 RFP installation, up to 16 paging areas can be configured.
The Paging area size is configured in OMP > System > System settings > DECT
The system show the possible configurations and the numbers of paging areas.
256 RFP system 2048 RFP system
RFPs need to be assigned to paging areas using OMP > Radio fixed parts
DECT XQ for Reflective Environments
Within areas containing a lot of reflective surfaces (e.g. metal or metal coated glas)
in an open space environment (e.g. warehouses, production sites, ...)
the voice quality of a DECT call can be disturbed because of signal reflections
which arrive on the handset or RFP using multipath propagation.
Calls may have permanent drop outs while moving and high error rates
on the base station and handset. (use the site survey mode to see error rates)
reflections
direct signal
For such compaditive environments Aastra has developed the DECT XQ

enhancement into base stations and the Aastra 600d/c handset family.
Using this enhancement in a call might reduce drop outs and cracking noise.
The basestation and handset does use more bandwith on the Air Interfaces,
to get the best quality out of the voice connection.
DECT XQ for Reflective Environments (II)
This extention can be enabled for each base station individually.

This shall only be done when problems sourced by metal reflections are detected !
As soon as this feature is enabled, the number of calls on an

RFP 32/34/42/35/36/37/43 is reduced to 4 calls at the same time.
DECT XQ can be enabled in the Radio fixed parts configuration

using
Base stations with enabled XQ mode are also backward compatible

to devices which does not support XQ e.g. 142d or GAP devices
In addition to the XQ enhancement, the well known DECT installation

and site survey instructions need to be followed.
DECT XQ ability is shown in the handset site survey mode

The handset may be restricted to initiating handovers in XQ connections
Locating of handsets in XQ connections may be imprecise
DECT XQ for Reflective Environments (III)
To get the best result for the DECT XQ feature it is essential,

that all regarding installation rules have been executed:
take care on the following pre-conditions:

• It is not recommended to use XQ in non reflective environments.
• The maximum number of calls is limited to 4.
• The maximum overlap between base stations should be -60 dBm.
bracket example
Do not mount the base station with omni directional antenna
directly on metal surfaces. Use a bracket to keep the
base station on distance (min. 20 - 40cm). wrong
Do not mount the base stations direct on steel beams

(e.g. in steel H beams). Use a bracket to keep the
base station on distance, otherwise deadspots will
occur in the area behind the beam.
don’t mount directly on metal
DECT XQ for Reflective Environments (IV)
Typical potential heavy reflective environments can be identified as follows:

• steel constructions with walls, floors or ceilings of metal surfaces
• huge glass walls with metal coated glass
• material or goods, made of metal which are highly concentrated in one place e.g. stores
The reflective influence increases with the dimension of the free space.
Typical potential reflective environments:

• production plants
• car dealers
• multi storey car park
• metal working industry
• airport hangar or terminal halls
For more detailed instructions on performing a site survey,

please read the user manual of the DECT Site survey kit.
Wideband Audio Connections (CAT-iq)
Wideband Audio Connections can only be established if all hardware involved

do support this. Wideband connections are established with other partys e.g.
SIP phones or handsets, using the Voice Codec G.722.
Wideband needs to be activated per Site, for this all

RFPs in this site need to be Wideband capable.
e.g.: RFP (L) 35, 36, 37, 43
Activate “Hi-Q audio technology” in the Site Setting.
limitations :
RFPs can perform up to 4 Wideband connections. (instead 8 narrowband)

It is not allowed to mix Wideband and non Wideband Sites in one Cluster.
Wideband is only available if the callserver, calling and called party support G.722.
DECT XQ is not available in Wideband connections.
Sync Over Air Startup
To avoid base station synchronisation problems and to speed up the syncronisation

on the system startup, the initial syncronisation process was split into 4 stages.
stage 0
if at least one RFP was configured as preferred synchronization source in a cluster,

the synchronisation process will wait up to 30 seconds for this RFP to connect.
Receiving a message from one preferred RFP will finishing stage 0 and starting to stage 1.
If no message was received within the 30 seconds, the next stage will be started.
If no preferred RFP was configured, this stage will be ignored.
RFP configured as
preferred sync source
Sync Over Air Startup (II)
stage 1
If a preferred RFP was determined in stage 0, this one will be the synchronisation source for
the next upcoming RFPs, otherwise the first RFP which startup sync is selected.
RFPs reporting an RSSI value better than -65 dBm will be permitted to do a synchronisation.
If an RFP was synchronised, it will be also a synchronisation source for other upcoming RFPs.
The initial timeout for this stage is 30 seconds. Whenever an RFP has finished its
synchronisation in this stage a new stage (shorter) timeout value will be calculated.
If no RFP comes up within the timeout time or if all the upcoming RFPs do not fit the RSSI
threshold, the next stage will be started.
-65 dBm range
initially synchronised
RFP
Sync Over Air Startup (III)
stage 2
behaviour is identical to stage 1, but an RSSI threshold value of -70 dBm is significant.
stage 3
behaviour is identical to stage 1, but an RSSI threshold value of -75 dBm is significant.
stage 4 / synchronisation finished

No more RSSI threshold value is significant. All the RFPs which failed the stage conditions
above, are now permitted to do a synchronisation.
-65 dBm range -70 dBm range -75 dBm range
final stage 1 stage 2 stage 3 synchronised RFP

Directory Service
The OMM can browse in up to 5 LDAP or XML directory servers to provide

phonebook entries on all system handsets. A600d/c – full, A142d use LDAP only.
To configure the directory(s) go to System Features > Directory.
As soon multiple directory entrys have been activated,

the handset show the activated directory names.
To make search requests unique for different users, the search base
configuration can include space holders which are replaced by user
specific values when submitting the LDAP request to a server.
The following placeholders are available:

“<TEL>” which is replaced by the specific telephone number of the user
“<DESC1>” which is replaced by the “Description 1” attribute value of the user
“<DESC2>” which is replaced by the “Description 2” attribute value of the user
To search the directory, press the arrow up key on the system handset.
Or define a softkey on the handset with the corp. phonebook function.
Directory Service (2)
Order: Order of appearance in the handset menu

Name: Name of this connection (displayed in the handset)
Server name:
DNS name or IP address of the LDAP Server
Server port: default 389 (SSL is not supported)

(Windows Active Directory Server Port: 3268)
Search base: LDAP Search base (provided by server),

can include placeholder e.g. <TEL>, <DESC1>
Search type:
search for surname (sn) or given name.
Display type:
Surname,Given name (Smith, John)
Given name, Surname (John, Smith)
Server search timeout: (1 - 10 sec)

Timeout until the OMM accept search results
Directory Service (3)
supported LDAP attributes: sn (surname), givenname, telephoneNumber,

mobile, homephone and for messaging: email, facsimileTelephoneNumber
corporate directory usage within call states e.g. for call transfer
multiple attributes per name are supported
messaging abilitys depend on configured message and alarm servers
call messaging LDIF example entry
sn: Doe
givenName: John
telephoneNumber: +1555123200
facsimileTelephoneNumber: +1555123456
mail: john.doe@company.local
mobile: +1555123456
142d display only the telephoneNumber

Digit Treatment
The Digit treatment replaces, deletes or inserts numbers for the

LDAP based Corporate Directory, incoming calls and outgoing calls.
To configure the Digit treatment go to system features > Digit treatment
LDAP
the LDAP entry is checked against the external prefix pattern
only the best matches rule will be applied and send to the handset
invalid characters like space or hyphens are removed from the number
( e.g. “+49 (30) 6104 1234” will be substituted to +493061041234 )
digit treatment takes place before the number will be transmitted to the handset.
Notice that a conversion performed for a LDAP

entry can be reversed, if the rule is also activated
for an outgoing call e.g.
LDAP to handset +49 00, outgoing 00 +49
In this case you may apply two rules.
Digit Treatment (2)
incoming call
the calling party number is checked against the external prefix pattern
only the best matches rule will be applied and send to the handset + call log
digit treatment takes place before the number will be transmitted to the handset.
outgoing call
the dialed number is checked against the best matching internal prefix pattern
and will be replaced by the assigned external prefix pattern.
conversion applies to on-bloc dialled numbers and to overlap sending in predial
result of the conversion is not sent to the handset e.g. to be displayed or call log
To support digit treatment and overlap sending, it is necessary to have a dial

terminator configured in the OMM SIP settings.
Digit Treatment (3) – Configuration
External pattern
Pattern with up to 32 character received with an incoming call or from LDAP.
(allow: +*~#,;.-_!$%&/()=?09aAzZ)
Internal pattern
Internal prefix pattern with up to 32 character to replace the external pattern for
LDAP or incoming calls or vice versa for outgoing calls. (allow: * # and 0 – 9)
Direction
Incoming calls , outgoung calls ,Incoming and outgoing calls
and Apply on directory only
Directory If set the rule applies on LDAP directory
Sites
Sites for which a rule shall be applied e.g. “1,2”.
If set to “0” the rule applies to all sites.
limit value: up to 128 entries on a RFP OMM and 750 entries on a PC OMM
Digit Treatment (4) – Examples
incoming calls and directory request

example
number: +493061041234
prefix: +4930 > substitute: 0
result: 061041234
call operators desk based on current location

The user dial “9” and the call goes
to the operator in the local office.
5009 9 1 Vienna
6009 9 2 Madrid
other scenarios
+15551234987 78987 (route call to tieline)

help #*4357 (LDAP “help“ get #*4357)
help #*4357 (incoming call from help become #*4357, outgoing call to #*4357 become help)
Simple Network Management Protocol - SNMP
SNMP can be used to integrate RFP’s into network monitoring systems.

In order to monitor a large network of RFPs a SNMP agent in each RFP is provided.
The SNMP agent responds to SNMPv1 and SNMPv2c read requests for the
standard MIB-II objects. (for MIB details please see system manual)
SNMP can be configured in OMM Webservice > System > SNMP
If enabled the SNMP client can access each RFP using the read only community.
(common default for read only community “public”)
Simple Network Management Protocol – SNMP (2)
The agent on the RFP sends a “coldStart” trap at it first starts up,
and an enterprise-specific trap “nsNotifyShutdown” when it stops.
When it receives a SNMP request using an unknown community name

it sends an “authenticationFailure” trap. The agent generates an
enterprise-specific trap “nsNotifyRestart” after being re-configured.
examples:
Feature Access Codes (FAC)
The OMM does provide FAC to
- activate subscription
- activate wildcard subscription
- deactivate subscription
- user login (bind device to user)
- user logout (unbind device from user)
- initiate Alarm triggers
This can be used for senarios, where

the configuration is done before the handsets receive at the location.
So a handset subscription is possible without access to the OMM webservice.
By default FAC is unconfigured, configure and activate them first in the web service.
To use FAC take a subscribed handset and type the FAC number + the action
then dial. You will get a short confirmation tone. (notice: overlap sending is not supported)
In this example „123*3#“ will deactivate the subscription of new handsets.

The number „123*2#“ will activate the wildcard subscription for new handsets.
Device and User Data Relations
The OMM provide different senarios to create handset and user information.
In the traditional methods one user is bound to one handset in a fixed relation.
With the OMM 2.0 a dynamic usage (binding) of devices and users was introduced.
Relations between users and handsets can be bound or release by the user.
This can be used e.g. for deployment senarios or free seating.
Subscription: handsets can be configured using the following senarios:
with IPEI and user data > subscription with configured IPEI
without IPEI and user data > wildcard subscription
without IPEI and no user data > autocreate on subscription
User / device data: DECT devices e.g. 600d/c, 142d, GAP can be bound to user data,
using the user login and logout feature access codes in the following scenarios:
User is configured without device data in the OMM database
User data are stored as <telno.>.cfg file on an external server
User – Device relations can be changed from fixed <> dynamic and
from dynamic / unbound <> external
Assign a User to Device
In this senario we subscribe a unconfigured new handset

to a user data entry which is configured in the OMM database.
A) requirements:
- enable “auto-create on subscription” in the OMP > system settings > DECT
- create a FAC number and a FAC for user login / logout (in system features)
- subscribe the handset to the OMM (access code defined in system settings)
The handset display the system name (600d/c and 142d only) and is shown in
OMP > Portable parts > devices
create a new user in OMP > Portable parts > Users > Create User
B) assign user to subscribed handset:

1. login device to user 300 (enter FAC no. + login FAC + extention no. (300) + ok)
2. OMM found user 300 configured in the OMM database. 2
1
3. device will be associated to user 300 user 300
4. User data are transferred to the handset and device
4 OMM
will be shown in the handset display (only 600d) 3
Assign a User to Device (II)
In this senario we subscribe a unconfigured new handset and bind this handset
to a user data entry which is provided on an external server as “<tel-no>.cfg” file
e.g. “201.cfg” for the extention 201. No configuration for specific handsets need to
be done in the OMM for this senario.
A) requirements:
- configure FAC and subscribe the handset the same way as in the last senario.
- create a user_common.cfg and the user config files (<tel-no>.cfg) on a
configuration Server and configure the URL to this server in OMP > System >
Data Management > User data import (details described on the following pages)
B) assign user to subscribed handset:
1. device login to user 201 (enter FAC no. + login FAC + extention no. (201) + ok)
2. OMM does not find user 201 in the local OMM database and requests the file
201.cfg from the configured server 1 2
3. device will be associated to User 201 Config
Server
4. User data are transferred to the handset 4 OMM
and will be shown in the handset display 3
(only 600d/c) device user201
201.cfg
Automatic User Data Import – Configuration
The OMM can be configured to download user data

from an configured server. The configuration is done in
OMP > System Data Management > User data import.
Configure the server address, protocol e.g. tftp, ftp(s),
http(s), login and the folder where the files are stored.
In this folder a common configuration file

“user_common.cfg” and one file for each user <tel-no.>.cfg have to be stored.
The OMM loads the user_common.cfg file directly after this feature has been activated.
During a handset login, the OMM downloads the extention file from the configured
Server, if the user is not found in the OMM database.
Afterwards the OMM checks all involved files in the configured intervals.
If a user file on the server is deleted, the OMM detect this change with the next update.
Then the OMM deletes the user in the database and remove the device association.
Automatic User Data Import – user_common.cfg
This example shows how to configure the user_common.cfg and <tel-no.cfg> files.
Create a text file (UTF-8) with the name „user_common.cfg“ on your server directory, configured by OMP.
Configuration parameters in this example are blue, optional are italic
# user_common.cfg sample configuration file for Automatic User Import

# retrieved via the net using file transfer protocols like tftp, ftp(s) or http(s)
# comments are starting with the hash sign: "#"
# BOOL variables support YES Y 1 TRUE or NO N 0 FALSE (case does not matter) , other values are interpreted as false
# Common User data configuration possibilities:

# OM_<variable> # Identifier for an OMM variable setting
# UDS_<variable> # Identifier for a user data server variable setting
# UD_<variable> # Identifier for a user data variable setting
OM_UniqueId=NUMBER # Unique id is the ext. number, this can not be changed yet
UDS_CommonUpdateInterval=6 # Interval to re import this file in hours / default=24 hours when not set
UDS_UseExternalUsers=YES # Enables / disables user data import - when disabled all users are deleted
# in the OMM (incl. private data) and gets unlinked from the handset / default=yes
UD_SosNumber=112 # Common SOS number when needed
UD_ManDownNumber=112 # Common ManDown number when needed
UD_Pin=1234 # User PIN, all user data sets will be set to this value initially when not set
# in the "<user>.cfg" file / default=0000 / can also be given in a public key crypted form*
UD_UpdateInterval=4 # Interval to re import user data files in hours / default=24 hours when not set
UD_Locatable=FALSE # BOOL, if TRUE the user shall be locatable per default
UD_LocatingPermission=FALSE # BOOL, if TRUE localisation for the user shall be allowed per default
UD_Tracking=FALSE # BOOL, if TRUE life tracking localisation for the user shall be activated per default
UD_AllowMsgSend=FALSE # BOOL, if TRUE admission to send messages for the user shall be activated per default
Automatic User Data Import – <tel-no>.cfg
# 201.cfg sample user configuration file

# Possible user data configuration settings:
UD_PinDel=FALSE # BOOL, if TRUE the user PIN will be deleted in OMM private data to default "0000", must be set
# to FALSE after the file is processed to have the possibility to set a new user PIN at the linked handset!
# reason for this option: PIN updates are not applied as long the user is active
UD_Pin= 201 # User PIN to login and logout / this can only be used until PIN change is implemented
# at the handset! Can also be given in a public key crypted form*
UD_UpdateInterval=1 # Interval to re import user data files in hours / default=24 hours when not set
UD_Number=201 # Subscriber number, ignored when NUMBER is unique (OM_UniqueId=NUMBER)
UD_Name=Julian # Displayed name
UD_SosNumber=112 # Common SOS number when needed
UD_ManDownNumber=112 # Common ManDown number when needed# Only for FFSIP:
UD_SipAccount= 201 # SIP account
UD_SipPassword= 0815 # SIP password
UD_Locatable=FALSE # BOOL, if TRUE the user shall be locatable, default is FALSE
UD_LocatingPermission=FALSE # BOOL, if TRUE localisation for the user shall be allowed, default FALSE
UD_Tracking= FALSE # BOOL, if TRUE tracking for the user shall be activated, default is FALSE
UD_AllowMsgSend=FALSE # BOOL, if TRUE send messages permission for the user is activated (require licence)
UD_AllowVcardSend=FALSE # BOOL, if TRUE admission to allow vcard send from PP / Supported
UD_AllowVcardRecv=FALSE # BOOL, if TRUE admission to allow vcard receive at the PP / Supported
UD_KeepLocalDir=FALSE # BOOL, if TRUE admission to keep the local directory after PP logoff / Supported
UD_VoiceMailNumber=22222 # User VoiceMail number when needed
UD_HierarchyName1=first aider # Optional 1. hierarchy name of a user, to make groups of users up to 16 bytes
…
* The encryption of credentials e.g. UD_Pin or UD_SIPPassword is not implemented yet
Automatic User Data Import – Details
Dynamic links between devices and users are restored after OMM restarts.
User data including personal settings e.g. Call Forwarding are stored permanently
in the OMM database as long as the user is available on the server / in the database.
This allows to keep data changed by the user between logout and the next login.
During a user logout some local handset data e.g. message list, message icon,
received call list, caller list, call forwarding icon and personal phone book are cleared.
(keep personal phonebook can be configured for each handset in OMP)
Instead of the users extention number the additional id can be used for login. (system settings)
User data received from an external server are removed from the OMM only when the user data file is not
available on the external server anymore or the import function is disabled.
information received from external files are permanently stored in the OMM database.
A copy is stored once a user logged in successfully.
Dynamic links between user and devices are not restored if an OMM db backup file is restore.
If wildcard subscription is enabled, auto-create on subscription will be disabled
Auto-create on subscription is available for 24h after the first handset is subscribed.
(as normal subscription senarios)
Automatic User Data Import - verification
Problems while importing the configuration files will be reported by syslog.

To see the last applyed configuration use OMP or the ommconsole.
omm@100.100.100.180 > ommconsole (enter setconsole first to see epr output on RFP shell)
omm# epr
ExternalUserDataImport data:
============================
update_interval: 'user_common.cfg' file and all user data files will be reimported every 1 hours
uds_protocol: FTP
uds_server: 10.103.50.254
uds_directory: usercfg
uds_account: user
uds_password: ****
uds_unique_id: NUMBER
use_ext_user: TRUE
use_fixed_handsets: FALSE
user update interval: user data files will be reimported additionally every 1 hours or different when replaced ..
common PP data: rel2dev=UNBOUND sos='' man-down='' pin=0000 hierarchy=''/'‘ flags=0001(ALLOW…
'Logged in' or 'linked fixed to a device' imported/external users:

===============================================
…
To reload / update the configuration from the cli instantly use the command omm# epr sync
User Login / Logout (I)
The OMM support an dynamic user login and logout.

Using the „auto-create on subscription“ feature handsets
can be subscribed to the system without further configuration in the OMM.
This function can be configured in the system settings > DECT

As soon subscription (and auto create on subscription) is active, handsets can
subscribe to the system using the access code defined in system settings.
Afterwards a user can take an unbound handset (device without phone number)
and login to a configured user account using an configured
feature access code (FAC) + phone number + PIN.
User Login / Logout (II)
basic requirements
enable „auto-create on subscription“ in the system settings

or configure handsets without phone number (unbound)
configure a FAC number and FACs for User login / logout
configure handset users in OMP > portable parts > Users
and set up a pin for each user or Import the user configuration from a server
subscribe your handsets to the system. (activate subscription first)
the handset will be configured as unbound in the database.
User login
Type in the FAC Number + User Login FAC + Phone Number > OK
The handset will ask for a PIN, now insert the pin assigned to the phone number.
On 600d/c the display will update after some seconds and show the new number.
User logout
Type in the FAC Number + User Logout FAC > OK
The handset will ask for a PIN, now insert the pin assigned to the phone number.
Automatic Database Import
The automatic database import feature makes it easier to restore a prepared

OMM database into an OMM for an initial configuration or for update reasons.
The automatic import can be configured via DHCP (code 24) or the OMM Configurator.
The file location for an automatic import has to be configured in an URL format like
{ftp|ftps|http|https}://[[user:password@]server]/[directory/]file or tftp://server]/[directory/]file
The periodic update and the update time can be configured in database management.
The OMM will check once per day at the configured point in time if there is a
new database to be imported. (NTP need to be configured for this feature!)
Automatic Database Import (2)
To initially configure an OMM by importing a preconfigured database,

only the checksum of the file is verified and no further checks are done.
To update an existing OMM configuration by importing its database configured by

another OMM instance, the following checks are done before the database file is accepted
and replaces the own one for usage:
- The checksum of the file have to be OK

- the checksum of the new database file and the checksum of the last database import file
(stored in the flash) must be different, to avoid the import of the same file multiple times.
For authorization/ authentication reasons:
- The PARK of the new database file must be the same as the PARK of the current configuration.
- The admin/full access account of the new database file must be the same as the one
of the of the current configuration.
Only if all checks are passed then the new database file:
1. Will be copied to the OMM
2. The new checksum will also be stored in the flash of the OMM
3. The new database file will be backed up to the backup server
4. The OMM restarts with the new database
In all other cases the new database file will be ignored.
The automatic OMM database import allows to change all configuration settings
but not the account settings and PARK. Only exception: changing the
default user account settings and PARK for an initial configuration
After the initial configuration, the user account settings and PARK can only be
changed via the Web service on the target OMM itself.
Example Scenario
customer offices
service provider
Automatic
Database Export
NAT-Router
Configuration manual Backup
using OMP or Import Server
OM AXI script (e.g. FTPS)
Provisioning
NAT-Router
Lab OMM Server
(e.g. HTTPS)
manual hosting Initial + periodic
export of OMM DBs Database Import
new Database + user files
NAT-Router
Automatic OMM Database Backup
The configuration of automatic

database backup is done in the
database management using the
OMM webservice.
A TFTP / FTP(S) / HTTP(S)* URL specifies the backup server, file location and
also account if possible. Backup files will be written to the directory specified by the URL.
File name convention <yymmdd>_<system name>_<PARK>_omm.conf.gz
The OMM will write a backup file if there are configuration changes e.g. handset subscription
If there is no configuration change then no new file will be created.
A backup file will be overwritten during a day if there is more than one modification.
A new file will be created when this first change occurs at the day
*Please be aware that HTTP(S) are not intended for file transfer and
has therefore some specific restrictions. FTP is recommended.
OMM Linux Server (PC OMM)
The OpenMobilityManager can be installed on a Linux Server instead of a RFP.

A OMM PC is also required for systems with more than 256 RFPs or 512 handsets.
For a Standby OMM, both OMMs have to run on the same plattform (RFP or PC).
Database Backups from a RFP OMM can be applied to the PC OMM.
(PC to RFP OMM only, if size of the database is within the RFP OMM limits)
The Linux PC OMM requires the following configuration (see release notes):
Red Hat Enterprise Linux (RHEL) Server Release 6

Server hardware minimum:
CPU: Dual Core Intel® Xeon® 3065, 2.33GHz, 4MB cache,
Bus 1333MHz
Memory : 2GB DDR2 SDRAM 667MHz
Hard disk: 80 GB SATA 7200 rpm
1 Gbit/s Ethernet interface
Usage of Virtualization (Vmware ESX) and CentOS 6 is restricted to approved projects.

PC OMM (2)
To install or update the OMM run the install file “SIP-DECT_version.bin” as root. e.g.
run sh SIP-DECT_version.bin in an terminal.
[root@server]# sh SIP-DECT.bin
After the installation procedure you have Unpacking...
to start the OMM e.g. with the command Archive: install.omm.19418.zip
inflating: SIP-DECT-OMM-<version>.i586.rpm
/etc/init.d/sip-dect-omm start inflating: SIP-DECT-HANDSET-<version>.i586.rpm
Preparing... ####################### [100%]
1:SIP-DECT-OMM ############### [100%]
The output should look like: Preparing... ######################## [100%]
Starting Open Mobility Manager: [ OK ] 1:SIP-DECT-HANDSET ########## [100%]
The OMM PC update does not update

To delete the OMM installation
the base station tftp image file. It may be
run yum erase SIP-DECT-OMM necessary to update the image file on
the TFTP servers as well !
further abilitys of the OMM install file:
SIP-DECT_version.bin -f force install/update, required for build version updates
SIP-DECT_version.bin -x only extract rpm files
Since RHEL 6 telnet is not installed by default. Install telnet using „yum install telnet“
PC OMM (3)
The OMM PC configuration file is stored in /etc/sysconfig/SIP-DECT.

Configure this file only if it is required e.g. if you do not use the Ethernet Interface eth0
or if you need to setup a new country code for (dial)tones.
##############################################
# OMM configuration file
# if you use a different interface for omm activate/correct parameter below

#OMM_IF="eth0"
#
OMM_CONFIG_FILE=/opt/omm_ffsip/tmp/omm_conf.txt
#
#if you use OMM resiliency for OMM activate parameter below with OMMs IP adresses
#OMM_RESILIENCY="192.168.0.1:192.168.0.2"
#
# Automatic OMM database import:

# TFTP / FTP / HTTP(S) URL specifies the import server and file
#RST_URL="ftp://download-url.com/directory/file.dat"
# country tones:
#Germany=1, Great Britain=2, Switzerland=3, Spain=4, Italy=6, Russia=7, Belgium=8, ....
#COUNTRY="1"
PC OMM (4)
The OMM is installed as a daemon and runs automatically at system start.

You can start and stop the OMM on a shell as a root user with the command
/etc/init.d/sip-dect-omm [start|stop|restart]
You can login to the OMM command line interface with ommconsole
To delete the OMM configuration remove the OMM configuration file

“/opt/SIP-DECT/tmp/omm_conf.txt” (default localtion).
OMM log files are stored in /opt/SIP-DECT/spy_trace_<date>.log
For PC requirements and supported operating systems, please read the

release notes and installation guide. We recommend to connect the OMM PC
with one 1 Gbit/s Ethernet Interface to the LAN.
On RHEL 5 logwatch is installed by default. This application analyse PC logfiles

and send the result to root e.g. by email. If the PC has big log files e.g. /var/log/messages
the load might block or crash the PC or applications (logwatch run at about 4 am).
In this case remove logwatcher using rpm -e logwatcher
PC OMM – Firewall configuration
If required the firewall on the OMM PC can be configured and enabled.

All required ports are documented in the installation guide.
To enable the firewall on Redhat Enterprise Linux (iptables) go to System >

Administration > Security Level and Firewall or run system-config-securitylevel
The following ports need to be open

for incoming requests to the OMM:
/etc/sysconfig/system-config-securitylevel
--enabled
--port=12622:tcp list of further ports which may be
--port=16321:tcp required for other applications
--port=16322:tcp e.g. DHCP, NTP and TFTP
--port=5060:udp --port=67:udp
--port=8106:tcp --port=68:udp
--port=8107:tcp --port=69:udp
--port=443:tcp --port=8080:tcp
--port=8443:tcp
--port=22:tcp
--port=21:tcp
--port=123:udp
OpenMobility Application XML Interface (OM AXI)
The OpenMobility Application XML Interface (OM AXI) is an

application programming interface (API) which allows (3rd party) applications
to communicate with the OpenMobility Manager (OMM)
e.g. for Configuration, Monitoring, Messaging, Locating
The interface is designed not to be bound to a certain OMM version.

To eliminate hardware dependency and to simplify the implementation on both,
client and server side, an XML based language is used.
The communication takes place over an SSL link, where the OMM acts as server.
OM AXI API specifications will be provided after registration via

Aastra Application Partner Program (A²P²)
OM AXI applications e.g. OMP, OML, A7900, Aastra Alarm Server, …
XML Applications for SIP-DECT Handsets
DECT handsets (600d/c series) can access external applications

using the OMM XML interface. This feature provides various
options for the integration of applications and call servers. Application Menu
call / redial lists
XML Applications can include different objects:

e.g TextScreen, TextMenu, InputScreen
Applications can also push information to handsets Idle screen modification

e.g. display information as call forwarding icon and text lines
XML Applications for SIP-DECT Handsets (2)
The OMM can redirect local handset applications to external XML

applications e.g. the caller list, redial list, system Menu
Additionally up to 10 XML applications can be configured in

OMP > System features > XML applications menu
The OMM can access XML applications using HTTP(s).

Configure predefined or new XML application to access
external applications.
Using the “eventAction” application, the OMM will

provide handset states e.g. for presence applications.
For more information on this application interface

see the XML API description in A²P².
Handsets can access XML applications from

Menu > Applications, where the OMM displays
a list of available applications. (req. SW 4.0 >)
Applications in this menu can be configured

as a shortcut on a programmable key on the
handset using the ongoing sequence number
in the XML Applications menu.
e.g. second application in menu = App 2
To use an external caller or redial list go to

>Settings > List access.
Each list can be configured as

- local: local list function in the handset
- PBX: access remote application
- Automatic: DECT system sets configuration (local or PBX)
Handset XML Application objects forwarding icon
text line
AastraIPPhoneTextScreen User Name
AastraIPTextMenu Number
AastraIPPhoneInputScreen System Name
AastraIPPhoneStatus application
AastraIPPhoneConfiguration key(s)
AastraIPPhoneExecute
Status / Configuration
InputScreen TextScreen TextMenu

XML Applications for SIP-DECT handsets (5)
FAC translation
A600c/d and A142d handsets can initiate XML feature access code requests.
This feature allow to access applications and transfer a FAC e.g. PBX procedure
using a HTTP(s) Request which contain the user input in the URL.
This Feature can be configured via OMP > System Features > XML Application
Select the Application “Feature Access codes” and insert the URL
to access your Application / PBX. Use the supported XML Placeholder:
{subsc} = Number, {ppn} = Device ID, {fac} = FAC
Handset open FAC Editor via Menu, OMM send HTTP(s) request with FAC to PBX
User dial “FAC” within Call (0-9*#) http://pbx/fac.php?na={subsc}&pp={ppn}&fac={fac}
FAC e.g. 1234 HTTP GET http://pbx/fac.php?na=100&pp=40&fac=1234
PBX Response
Handset OMM 200 OK (empty) PBX
Aastra Call Server XML integration
The Aastra call servers MX-ONE (Rel. 5.0) / A700, Aastra 5000 (Rel. 5.4)
and OpenCom 1000 (Rel. 6.2) provide build in XML handset applications.
MX-ONE
- Idle screen modifications (Name, Diversion, Call Profile)
- Diversion Menu (Absence, Follow Me, DND)
- Menu in call states e.g. Absence, Busy
- Phonebook (CMG)
Aastra 5000
- Caller List, Redial List, Idle screen modifications (Diversion, Parking),
- Activated Features, Forwarding, Settings, VoiceMail, Parking
OpenCom 1000
- Idle screen modifications (Forward Indication)
- Caller List
- Phonebook
- Diversion Menu
- DND
XML Sample - Text Screen
1
1.) HTTP GET request to http://server/text/
2 include User Agent with extension and version.
e.g. Aastra SIP-DECT MAC:3151 V:3.0
and the configured Handset Language
OMM Webserver
2.) Server response with XML page
<?xml version="1.0" encoding="UTF-8"?>

<AastraIPPhoneTextScreen destroyOnExit="yes" > Text Screen
<Title wrap="no">Text Screen</Title>
<Text>This is my text</Text> This is my text
</AastraIPPhoneTextScreen>
OK ESC
Wireless LAN
Wireless LAN
WLAN - Basics
To operate a own WLAN a name (SSID), channels (2.4 / 5 GHz) for Access Points,
a mode e.g. 802.11n and encryption (usage recommend) need to be configured.
The range of
2.4 GHz is
higher as with
WLAN devices share bandwidth with 5 GHz (loss)
all devices on the same channel.
ABC ABC ABC ABC

Stations with lower data rates e.g. old
Neighbor Access Point should devices or devices with long distance
operate on different frequencies to the AP require more time to transfer.
WLAN Standards (Summary)
802.11a (1999) » 802.11i (2004)

– Physical Layer in 5 GHz band – additional WLAN security
– data rate up to 54 Mbit/s using OFDM
– AES, TKIP, EAP (base for WPA2)
802.11b (1999)
– data rate up to 11 Mbit/s » 802.11e (2005)
using CCK / DSSS – Medium Access Control(MAC)
Quality of Service Enhancements
802.11g (2003) – automatic power save delivery
– Physical Layer in 2,4 GHz band
– data rate up to 54 Mbit/s using OFDM
– backward compatible to 802.11b
802.11n (2009)
– Physical Layer in 2,4 GHz and 5 GHz band
– data rate up to 600 Mbit/s using OFDM / MIMO
– backward compatible to 802.11b/g / 802.11a
WLAN Applications
environments applications
hotels
» healthcare
hospitals
office buildings » logistics
production halls » Internet / network
.... » ....
devices
» laptops
» PDAs
» phones
» ....
WLAN Frequency (General)
2.4 GHz ISM (channels EMEA: 1-13, NA: 1-11)
Channel
Ch: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Frequency
Freq: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484
There are 3 overlap-free channels in 2.4 GHz ISM band (using 802.11b/g + n-HT20)
e.g. 1 – 6 – 11. Each channel has a bandwidth of 22MHz. APs should always be
5 channels seperated from each other.
5 GHz ISM
Channel 36 40 44 48 52 56 60 64 100 - 140 149 - 165
Frequency 5180 5200 5220 5240 5260 5280 5300 5320 5500,…,5700 5745 - 5825
In 5 GHz all channels are overlapping free. The usage of certain channels is bound
to regulatory requirements, Access Point capabilities (DFS, TPC) and indoor / outdoor usage.
WLAN Frequency Planning
For planning the channels for a base of a site-covering radio network,

the distance between two base stations with the same frequency should be
at least double that of the coverage. The coverage can be adjusted with the help
of the Output Power Level parameters by 6% / 12% / 25% / 50% or 100%.
1 13 7
7 1 13
HT40 (double channel) vs

HT20 (single channel)
Using the 802.11n HT40 mode two
WLAN channels will be combined for more primary (1) secondary
troughput. This reduce the number of non
1 6 11
overlapping channels in 2.4 GHz frequency.
WLAN Deployment
customer requirement application, devices, coverage, bandwidth
site survey, building details, disturbing devices

Planning channels, security, if possible pre deployment
Installation deployment, device configuration, network,

security settings, client configuration, backup
Verfication site survey, fine tuning, check data rates,

check stability, user verfication by customer
Documentation building maps, verification results, photos!
WLAN 802.11n MIMO
Using 802.11n, AccessPoints and clients (stations) can use multiple antennas
to transmit or receive data on individual streams.
Multiple Input Multiple Output (MIMO) allow higher data rates and
provide better radio conditions as signals can be received by multiple antennas.
maximal phy. data rates (Mbit/s)

Mode HT20 HT40
1x1 72 150
2x2 145 300
3x3 216 450
4x4 288 600
data rates vary on the radio
environment and devices
The RFP43 support the 2x2 antenna mode
capabilites.
with the maximal data rate of 300 Mbit/s
WLAN Security = Authentification + Encryption
Authentification:
• SSID – Service Set Identifier
• Access filter e.g. MAC address filter, external radius server
Encryption details
WEP Not recommended, because this is not safe !!
(Wired Equivalent Privacy) usage to support old clients with no WPA support
WPA WPA 2 using AES is presently the most secure

Wi-Fi Protected Access WLAN encryption in the market
WPA 1 / 2 for households and small enterprise

PSK (pre shared key) using a secret / password on all WLAN stations
WPA 1 / 2 for SME / MLE using a Radius Server (802.1x)

Enterprise for the station authentication e.g. using EAP-TLS
WPA Authentification with a Radius Server
Access Point Radius Server

Station
Authentification
Server Certificate
EAP / 802.1x Authentification Private + Public Key
Master Secret CA Certificate

Client Certificate Private + Public Key
Private + Public Key
Key
CA Certificate
Private + Public Key
Normal data traffic
LAN
Key
Normal data traffic
LAN
WLAN | LAN
VLAN 802.1q
The RFP 42 / 43 supports VLAN tagging (separation) for up to 4 WLANs and Voice data.
e.g. for enabling the separation of different WLAN network‘s and the telephone network.
WLAN Data
Data Internet
WLAN Data
Data
Switch
corporate
WLAN Data Data LAN
Data
WLAN Data RFP 42/43
VoIP (e.g untagged) Voice LAN
DECT Voice
WLAN Profile Configuration
Create WLAN profiles which later can be assigned to the RFPs.

Profiles have to be defined for RFP types e.g. RFP(L)42 or RFP(L)43
Service Set Identifier (SSID): Name / Description of this WLAN

VLAN tag: tag WLAN data to this VLAN and receive with this tag
802.11 mode: WLAN mode 802.11n prefered
Hidden SSID mode: send no SSID in beacon packets
WLAN Profile Configuration (2)
Select the security type: open, WEP, WPA(2)-PSK, WPA(2)-802.1x
WLAN Profile Configuration (3)
Distribution interval: key exchange interval for WPA

Radius Settings: IP address and Port of the Radius server and
the secret to authenticate the basestation as radius client
WME: Wireless Media Extentions (for QoS, required for 802.11n)
Multiple SSID: one profile can have up to 4 different SSIDs
Be aware that on RFP(L) 42 only SSID1 can be broadcast.

All other SSIDs have to be known to the station as they are
hidden SSIDs.
RFP WLAN Configuration
Assign the WLAN profile to your RFP’s (42 / 43).
WLAN profile: ID of the WLAN profile

(need to match RFP type)
802.11 channel: (selection depend on profile)

1-14 = 2,4 GHz 802.11b/g or 802.11n
36-48 = 5 GHz 802.11a or 802.11n
Output power level: WLAN transmit power
HT40: activate WLAN channel bundle for more

troughput. In 2.4 GHz this reduce the number of
overlapping free channels! Use only for single spots.
The RFP(L) 43 can operate as WLAN Access Point and OMM at the same time.
If the OMM reside on a RFP (L) 42 the WLAN function is disabled.
The RFP type need to be known in the OMM to apply a WLAN Profile.
e.g. RFP is connected or type is set by OMP
SIP-DECT® 4.0
module 4: troubleshooting Training
Module 3: Messaging and Locating
Messaging
Integrated Message & Alerting Service (IMA)
OM Locating Server (OML)
600d/c Messaging
142d Messaging for A5000
Message Traffic Shaping
OMP Device Placement
User Monitoring
Video Locating (preliminary)
Bluetooth Locating (preliminary)
Messaging
The OpenMobility Manager provide an OM Application XML Interface (OM AXI)

which also can be used to connect messaging applications e.g. an Alarm Server.
Applications can subscribe to message destinations e.g. an URI (mailto:),

portable part number or to an alarm event (alarm trigger) e.g. MAN DOWN
OM AXI push the message / event information to all subscribed applications.
The OMM provide also an integrated message and alarm server (IMA).
This service provide basic alarm and message abilities without
the need of additional hardware.
The functions of IMA are limited and does not provide the same abilities as an
Alarm Server e.g. ESPA connector or keep an alarm if the application reset.
XML applications
OMM e.g. Alarm Server
OM AXI
IMA OM Locating
IMA - Integrated Message and Alarm Server
IMA can be activated in the OMM System > System Settings.

Activate IMA and insert an URL where the IMA configuration file (ima.cfg) is stored.
e.g. ftp://username:password@server/folder/ima.cfg (using http(s), tftp, ftp(s) )
handset <> handset

Handset to Handset messaging is also possible without
IMA configuration file as soon IMA is activated.
(permission to send message from a handset need to be set by OMP)
handset <> email
IMA is able to send messages to handsets using the extention
number (tel:), handset number (ppn:) and to email addresses IMA
using (mailto:) (email header text is supported only, no body)
Alarm triggers
Handsets are able to send messages (up to 1000 bytes)
to other handsets, an email address and if supported by a
IMA
external application server as sms or fax.
IMA – Alarm Handling
IMA process configured alarm triggers to send messages to configured targets.

Alarm Scenarios and actions can be configured in the IMA configuration file
and can be triggered with the following actions:
Man Down - initiated by the alarm sensor of the 630d handset

SOS – initiated by pressing the SOS Key on 620d or 630d handset
dial an FAC – using feature access codes for an alarm trigger
Email messages with a defined subject
OMM health state warnings
RSS feed
DISTRESS_OPERATOR_TIMEOUT (if tracking server Operator did not react)
PAGEBYMENU (600d paging menu)
As reaction to an triggered alarm one action e.g. send message

for up to 20 destinations (handsets or email) can be configured.
In addtion escalation levels can be defined (up to 3 levels for an alarm trigger),
if no or not the expected number of confirmations has been received for an alarm.
IMA – Message Types
The system support different types of messages and Jobs,

which have different acknowledge and confirmation handlings.
Jobs are messages containing tasks.

They have to be confirmed as “read”, “accepted” and in case of urgent jobs as “done”.
The message priority also lead to different melodies on the 6xxd handsets.
The permission to send message can be configured for each handset. (default none)
6xxd handset
Menu Text Messages
Enhanced Alarm Messaging
The SIP-DECT® 4.0 Messaging provide a new feature set for Alarm Messaging.
To use these features the OM Message & Alerting License is required.
The following additional options can be used by OM AXI Applications

in text messages send to A600c/d handsets. (to overwrite device settings)
Options
Melody (1-10)
Volume (off, 1-100%)
Increasing Volume
Vibra Call (Vibrator on)
Disconnect Call
Auto callback (initiate call to number)
In band Signaling of tone
Ringer tone (on / off)
Text + Background color
IMA – IMA Configuration File (ima.cfg)
The IMA configuration file have to be UTF-8 coded! and within an XML syntax.
In the configuration file the following points can be configured:
MailBoxAccount to receive emails (one account using PoP3 (SSL) )

SendmailAccount to send emails (one account using SMTP (SSL) )
RSS feeds
AlarmScenarios with trigger and actions
IMA receive MailBox Alarm trigger events do initiate

an email Account Senario alarm senarios, which initiate
triggers configured actions e.g. send
IMA pool URL RSS with trigger message (with escalation)
with RSS feed feed and actions
actions
Handset FAC Alarm trigger Sendmail Account
dial FAC (OMM) e.g. Meeting to send an email
SOS
Mandown Fixed Alarm trigger message
OMM errors triggers e.g. SOS
IMA – IMA Configuration File: Alarm Scenario
Attribute Duty Description

alarmTriggerId mandatory Trigger to initiate this alarm senario e.g. text string, MANDOWN,
emailsubject:Alarm123, emailsubject:*, OMM-WARNING-*,
SOS, DISTRESS_OPERATOR_TIMEOUT, PAGEBYMENU
level mandatory Escalation level to use identical alarmTriggerId for higher
escalation levels e.g. 1, 2, 3
recipients mandatory List of up to 20 recipients like mailto-URI’s or tel:1234 to address
single handsets, tel:* to send an message to all handsets which
have messaging capability (without confirmation)
alarmMsg mandatory Alarm message to send to the recipients (support of placeholders)
alarmConfirm optional Expected confirmations of recipients (not for broadcasting to tel:*)
e.g. ConfRead, ConfOrder, ConfCompletion
requiredPosConfirmCount optional Count of expected confirmations from the recipients e.g. 0
confirmTimeout optional Timeout in seconds of expected confirmations (max. 3600) e.g. 0
priority optional Priority, with which the message should be send and signalled.
PrioInfo, PrioLow, PrioNormal, PrioHigh (default), PrioAlarm
popUp optional Whether or not the message must pop-up e.g. 1 true, 0 false
…
IMA – IMA Configuration File: Alarm Scenario (2)

autoDelete optional Whether or not the message should be deleted automatically
after final state e.g. 1 true, 0 false
vCard optional Whether or not the 'alarmMsg' contains a vCard e.g. vCard="true"
postDialSeperator optional Seperates digits dialed after a configured alarm trigger
FAC number. e.g. could be any combination of '#' and '*‘
dial: FAC no.+ FAC + value + Seperator + value2 (#91234*1234)
callbackNumber optional Callback number, the recipient of a text message can dial using a
single key on the handset. May contain a hard coded recipient
(cb:1234) or a number seperated from the post dialed digits
(cb:%#2R). The use of the URI type 'tel:' is also possible (will be
mapped to cb:), but other URI types like 'ppn:' or 'mailto :' will fail!
To use the functions vcard, callback and pagebymenu, the 600d handset firmware 3.03 or higher is required.

AlarmScenario only starts if initiated by a user which configured
compareDescription1 optional
'Description 1‘ (User settings) match to the compareDescription1
AlarmScenario only starts if initiated by a user which configured
compareDescription2 optional
'Description 2‘ (User settings) match to the compareDescription2
AlarmScenario only starts if initiated from users with the given URIs.
compareSender optional
';' separated and must end with ';'. e.g.compareSender="tel:10;tel:11; "
Overwrites Handset melody for this message.
melody optional
0=No melody, 1-10=Message Melody 1-10
volume optional Overwrites Handset volume for this message. 0=off; 100=loudest;
Overwrites Handset behavior of whether to use the ringer.
ringerTone optional
true = active, false = use Handset default
Overwrites Handset behavior of increasing volume for this message.
increasingVol optional
Overwrites Handset behavior of vibration for this message.
vibraCall optional
Feature require the OM Messaging & Alerting System License!


Overwrites Handset behavior of
noInband optional inband new message signalization for this message.
true = no-inband signalization, false = use Handset default;
Whether to automatic disconnect an call when
disconnectCall optional
the message is received at the Handset e.g. disconnectCall="1"
Automatic call establishment from the recipient Handset
autoCallback optional of the message to the 'callbackNumber‘
e.g. autoCallback="1" callbackNumber="2961"
textColourR
optional, message color for text (R,G,B) Value: 0-255.
textColourG but if used, e.g. textColourR="255" textColourB="255" textColourG="255“
all text and
textColourB background
bgColourR color
values
must be message color for background (R,G,B) Value: 0-255.
bgColourG
given! e.g. bgColourR="255" bgColourB="0" bgColourG="0"
bgColourB
Send alarm state messages to the activator (sender) of the alarm
alarmStatusMessages optional
trigger . default=true
Features above require the OM Messaging & Alerting System License!
placeholder replaced by
%s sender-URI Placeholders which can
%r receiver-URI be used within messages.
%t sendTime HH:MM:SS
The message size is limited
%T sendTime HH:MM:SSam/pm
to 1000 bytes (may be less
%d date (sendTime) in european format DD.MM.YYYY
characters in UTF-8).
%D date (sendTime) in US format YY-MM-DD
%p ppn (portable part number)
%n Name of the handset user
%R Handset Calling Party Number (CPN)
%c Message content of the alarm trigger
%i Alarm trigger ID
%l Escalation level
%u Count of last (escalation level) received confirmations
%x Count of last (escalation level) received rejects
%e Count of last (escalation level) expected confirmations
%o Last (escalation level) timeout value
%#1n Name of the number seperated from the post dialed digits (#1 -#9)
%#1R Number seperated from the post dialed digits (#1 -#9)
URI‘s supported by IMA Alarm triggers
Portable Part Number of an handset “Text-string” self defined alarm trigger text
ppn:
e.g. ppn:00 e.g. Meeting
extention Number of an handset SOS SOS Key initiated alarm
tel:
e.g. tel:201
MANDOWN 630d Alarm Sensor initiated alarm
email-Address
mailto: DISTRESS_ Tracking Application Operator Timeout
e.g. mailto:julian@aastra.com
OPERATOR
Initiate an Alarm trigger e.g. Meeting
alarm: _TIMEOUT
(can not be initiated by alarm trigger)
emailsubject: IMA received an email with this subject
e.g. emailsubject:Meeting,
emailsubject:* , emailsubject:Alarm-*
OMM- OMM Health State Alarms
e.g. OMM-ERROR-STANDBY
Alarm Senario Example PAGEBYMENU paging in 600d system menu
<AlarmScenario>
<as alarmTriggerId="Meeting" level="1" recipients="tel:201;tel:202;mailto:abc@company.com"
alarmConfirm="ConfRead" requiredPosConfirmCount="0" confirmTimeout="0" priority="PrioHigh"
popUp="true" autoDelete="1" alarmMsg="%n: Meeting now in Room ABC !"/>
</AlarmScenario>
IMA – IMA Configuration File: Email
IMA can receive Emails from one POP3 email server.

For this an MailBoxAccount have to be configured.
Type of mailbox account: POP3 or NONE to stop polling e.g.
mailBox mandatory
EmailPOP3, EmailNone
First try to use SSL, if failed used unencrypted port (StartTLS)
trySslFirst optional
default=false
Minimum time between each email poll (10-3600s)
pollTime optional
default=30
mbPort optional Port of the POP3 server; 0 for standard port
mbSslPort optional SSL-Port of the POP3 server; 0 for standard port
mbServer mandatory Name or IP address of the POP3 server
mbUser optional POP3 account user
mbPassword optional POP3 account password

Example Mailbox configuration to receive Emails from an POP3 email account
<MailBoxAccount mailBox="EmailPOP3" trySslFirst="false" pollTime="10"

mbServer="mail.company.local" mbUser="username" mbPassword="password"/>
IMA – IMA Configuration File: Email (2)
IMA can send Emails via SMTP to one email server.

For this an Sendmail Account have to be configured.
Authentication method to use if the server expects such login before
auth mandatory
receiving emails e.g. AuthNone AuthPOP3 AuthSMTP
trySslFirst optional First try to use SSL, if failed used unencrypted port (StartTLS) default=false
smtpPort optional Port of the SMTP server; 0 for standard port default=0
smtpSslPort optional SSL-Port of the SMTP server; 0 for standard port default=0
mbPort optional Port of the POP3 server, if authentification is used; 0 for standard port
mbSslPort optional SSL-Port of the POP3 server, if authentification is used; 0 for standard
smtpServer mandatory Name or IP address of the SMTP server
smtpUser optional SMTP account user
smtpPassword optional SMTP account password
mbServer optional Name or IP address of the POP3 server, if authentification is used
mbUser optional POP3 account user, if applicable (auth attribute)
mbPassword optional POP3 account password, if applicable (auth attribute)
senderAddress optional Email address used as the sender address of outgoing mails
IMA – IMA Configuration File: Email (3)
Example Sendmail Account to send emails
<SendmailAccount auth="AuthSMTP" trySslFirst="false" smtpServer="mail.company.local"

smtpUser="user" smtpPassword="password" mbServer="mail.aastra.local"
senderAddress="alarm@company.local"/>
Example Alarm Scenario triggered by email
<AlarmScenario>
<as alarmTriggerId="emailsubject:ABCmeeting" level=“1" recipients="tel:*"
priority="PrioHigh" popUp="true" autoDelete="1" alarmMsg="Meeting now in Room ABC !"/>
</AlarmScenario>
Example Email Subjects (can be used without alarm scenario configuration)

Email subject Description
tel:1234 message text IMA send message to handset 1234 containing text: message text
alarm:meeting Initiate the alarm trigger meeting
Hello No action, if no trigger with emailsubject:* or Hello is configured as alarm trigger
IMA – IMA Configuration File: RSS
IMA is able to download RSS feeds (up to 64k) from an configured URL.
Using an Alarm trigger the RSS feed is send as message to configured destinations.
(Do not forget to configure an DNS Server on the OMM using DHCP or OM Configurator!)
url mandatory URL of the RSS feed
trigger mandatory Alarm trigger ID
refresh optional After which time the RSS feed should be checked for new entries. Only
ONE of the newest will be sent! default=3600 seconds
Example RSS
<RSS>
<feed url="http://www.heise.de/newsticker/heise-atom.xml" trigger="RSSheise" refresh="40"/>
</RSS>
<AlarmScenario>
<as alarmTriggerId="RSSheise" level="1" recipients=“tel:200” priority="PrioInfo"
alarmMsg="Heise news: %c"/>
</AlarmScenario>
IMA – IMA Configuration File: OMM Health State
IMA is able to use OMM health state events as alarm trigger.

The trigger is build of OMM-HealthType-process e.g. OMM-WARNING-SYNC
HealthType: OK- (State okay), WARNING- (problem but still working), ERROR- (failed)
process Description
SYNC Health state of RFP synchronization
STANDBY Health state of standby OMM mechanism
AUTODB Health state of Auto Data Base Backup
DOWNLOAD Health state of software download over air
PROTOCOL Warning or Error if there are RFPs using a different protocol version
BRANDING Warning or Error if there are RFPs using a different branding
ENCRYPTION Warning or Error if there are RFPs which do not support encryptions but this is enabled
LICENSE Warning or Error if licensing is not (fully) satisfied
IMA Warning or Error if IMA is not (fully) working
Example for OMM Health State
<AlarmScenario>
<as alarmTriggerId="OMM-ERROR-*" level="1" recipients= "tel:1234" priority="PrioHigh"
popUp="true" autoDelete="false" alarmMsg="OMM System Trigger %i! Add.-Info: %c"/>
</AlarmScenario>
IMA – IMA Configuration File Samples
Example: User Monitoring
<AlarmScenario>
<as alarmTriggerId="UMON-ERR-USERSTATE" level="1" recipients="tel:*" priority="PrioHigh" popUp="true“
alarmMsg="UMON: %n out of service Error: %c"/>
</AlarmScenario>
Example: Escalation
<AlarmScenario>
<as alarmTriggerId="CALLME" level="1" recipients="tel:532;tel:533" priority="PrioAlarm" popUp="true"
alarmMsg="Alarm initiated from %n - %R , %c hook to callback" callbackNumber="cb:%R" autoDelete="1"
alarmStatusMessages="0"
requiredPosConfirmCount="1" confirmTimeout="15" ><alarmConfirm>ConfRead</alarmConfirm></as>
</AlarmScenario>
<AlarmScenario>
<as alarmTriggerId="CALLME" level="2" recipients="tel:555" priority="PrioAlarm" popUp="true"
alarmMsg="Alarm from %n - %R - Level2 after timeout!" callbackNumber="cb:%R" alarmStatusMessages="0" />
</AlarmScenario>
Callme
CALLME Hook to on timeout Escalation
Callback
Hook to …. on timeout
IMA – IMA Configuration File Samples (2)
Example: PostDialSeperator
<AlarmScenario>
<as alarmTriggerId=“BED" level="1" recipients="tel:201;tel:202" priority="PrioHigh" popUp="true" postDialSeperator="*"
alarmMsg=“Please deliver a bed at %#1R clock to room %#2R !"/>
</AlarmScenario>
dial FAC No. + FAC + time + * + room e.g.: *91400*313

“Please deliver a bed at 1400 clock to room 313"
Example: Callback
<AlarmScenario>
<as alarmTriggerId= "Callback" level="1" recipients="tel:%#1R" priority="PrioHigh" popUp="true" alarmMsg="%n: Please
call %#2n (%#2R)" callbackNumber="cb:%#2R" postDialSeperator="*" />
</AlarmScenario>
dial FAC No. + FAC + recipient + * + callbackno e.g.: *8400*500

“John: Please call Tom (500)" (press hook key to call tom)
Example: Callback Menu

<AlarmScenario>
<as alarmTriggerId="PAGEBYMENU" level="1" recipients="tel:%#1R" priority="PrioNormal" popUp="true" alarmMsg="please
call %#2R (%#2n) send by %n" callbackNumber="cb:%#2R" postDialSeperator="$~x" />
</AlarmScenario>
IMA – IMA Configuration File Samples (3)
Example: Alarm with continuous increasing Volume, Ringer, Color, Disconnect Calls
<AlarmScenario>
<as alarmTriggerId="Alarm-Fire" level="1" compareSender="tel:201;" recipients="tel:*" priority="PrioAlarm" popUp="true"
textColourR="255" textColourB="255" textColourG="255" bgColourR="255" bgColourB="0" bgColourG="0"
alarmMsg="Fire!!!" disconnectCall="1" vibraCall="1" increasingVol="1" ringerTone="1" melody="2" volume="50">
<alarmConfirm>ConfRead</alarmConfirm><alarmConfirm>ConfOrder</alarmConfirm></as>
</AlarmScenario>
Example: Alarm Scenarios depending on Initiating Handset:
<AlarmScenario>
<as alarmTriggerId="Alarm-Team" level="1" compareDescription2="DOC" recipients="tel:201" priority="PrioHigh"
popUp="true" textColourR="255" textColourB="255" textColourG="255" bgColourR="255" bgColourB="0"
bgColourG="0" alarmStatusMessages="0" disconnectCall="1" autoCallback="1" callbackNumber="202"
alarmMsg="Alarm Team DOC initiated by %n Wait initiate call"/>
</AlarmScenario>
<AlarmScenario>
<as alarmTriggerId="Alarm-Team" level="1" compareDescription2="HELP" recipients="tel:201" priority="PrioHigh"
popUp="true" textColourR="255" textColourB="255" textColourG="255" bgColourR="100" bgColourB="100"
bgColourG="0" alarmStatusMessages="0" alarmMsg="Alarm Team Member need help by %n"/>
</AlarmScenario>
TEAM TEAM
AutoCall…
IMA – FAC and Troubleshooting
FAC alarm triggers
Feature access codes can be used to initiate alarm senarios.

Configure the FAC in OMP > System feature > Alarm triggers.
To initate the alarm, dial the FAC number + the FAC for this alarm.
If an Number is given, the caller will call this number using the FAC.
IMA troubleshooting
IMA status and problems will be reported via syslog. To read the IMA status check
the event log or use the ssh remote access to connect the OMM. (enter setconsole to see output)
omm@OMM-IP > ommconsole

omm# ima
IMA-cmd usage:
ima start start message and alarm server
ima stop stop message and alarm server send messages permission
ima conn displays connection data (with OM AXI) need to be configured per
ima dump dump internal lists handset. Default disabled.
ima conf reload configuration
ima send_msg %URI% %content% send a text message
Tracking - Overview
The OMM provide handset tracking abilities, which can be used by applications
like the OpenMobility Locating server connected by the OM AXI XML interface.
Handset locations can be tracked by the locating server clients or 600d/c handsets.
Tracking abilities have to be configured for handsets, before they can be tracked.
Up to 10 clients can connect to the locating server using a web browser.
Web
emergency DECT XML browser
call indication OMM
locating requests
OpenMobility Manger OpenMobility Locating Server Emergency Operator
 controll base station network  manage escalations  receive emergency call

 detect emergency calls  display handset locations  work with the
 escalate emergency situations  send messages / alerts OM Locating Client
e.g. if a alarm is not confirmed
Mandown / SOS Example
2 4
2 3
OMM OML PBX OML client
1 1. 630/633d Mandown / SOS call

2. OMM call Emergency Number
and send alarm to OML
3. call proceed to Operator
1 4. OML Client Alarm for Operator
(Name, Base station, Alarm type)
possible reactions using OML
+ search people in the area
+ send messages
+ initiate locating alert tone
…
Locating Example
The OM Locating server show the current

RFP the handset is connected to.
OMM OML OML client In addition the operator can see the last
RFP’s the handset was connected to and
can initiate a site survey from the 600d/c.
In case the handset initiate a SOS or

Mandown alarm. The alarm type is shown.
To quickly find a handset in a surrounding

area, the 600d/c can play a alarm sound.
OM Locating - Installation
The OpenMobility Locating Server run on an Apache Tomcat Webserver.

Install the Tomcat webserver and copy OML.war file into the webapps directory.
Then start tomcat and connect to http://<tomcat-server>:8080/OML/

First login using the user: admin with password: OpenMob
Configure the OMM connection and users in the administration section.

The further configuration is done automaticly by the OMM.
To add pictures of the locations, generate two pictures for each base station
and copy them into the tomcat server folder ../webapps/OML/images/locations/
create an overview picture
with the RFP MAC address
as png e.g. 0030420E7AC0.png
(use CAPITAL letters!)
create a detailed location

picture with the RFP MAC
and string –zoom as png
e.g. 0030420E7AC0-zoom.png 256x256 pixel
OM Locating - Administration
After the first login the Locating server ask for the OMM connection. Insert the Full Access
Username (e.g. omm), Password and the IP address of the OMM. If a standby OMM is enabled,
the IP will be updated automaticly (after connect).
Handset tracking abilitys have to be
configured using OMP > portable parts
As soon the Locating Server is connected to the OMM,

status updates will popup and the configuration will be imported e.g. RFP locations, handsets.
Users (operators) can be configured in Administration > Users
User name: Login Name for the User

User Group: users should be selected for operators.
Administrators have more rights e.g. Administration
Password: Password for this user
Phone no.: extention number. Alarm events can be automaticly
assigned to a operator, if caller is connected with this phone number.
OM Locating – Tracking Abilities
The Locating server does provide information about handset locations

e.g. connected base station, visibility of other base stations (600d only)
and a handset location history with last user actions.
The operator can easy sort and filter e.g. to see first aiders
locations can be updated on request

e.g. if the handset is in idle
base station visibilitys reported by the handset

can be displayed on request for 600d handsets
Handset last location update history

with user action e.g. call, handover >
OM Locating – Tracking Abilities (2)
handset position data is updated on every interaction

between handset and base station. e.g.
phone calls and handovers

location registrations (switch on / off handset, roaming)
during connections (using corporate phone book) and software updates
on operator request e.g. update button or tracking is enabled
Location updates handset history
Location was recently updated. a phone call was made by
the handset at that time.
Last location update is more
than 20 minutes ago. There was a handover to that
RFPs during the connection
No active location information The handset registered to the system
is available. e.g. after the handset has been switched on
RFP visibility can not be The handset was registered at the RFP,
provided by this handset. e.g. because it reached the RFP coverage
e.g. no A600d handset
The user/operator requested an update
OM Locating – Alarm Handling
Using the Locating server an operator can manage alarm events.

If an alarm event occure, there is a acoustic and optical indication for the operators.
Operators can instantly see the alarm sender, alarm type (e.g. man down) and
base station the handset is connected to. further actions can be initiated directly.
New events can be assigned to an operator using „accept“. (escalation after timeout)
Auto assign if the connected number of the handset match to an operator number.
Event can be forwarded to another operator or closed,as soon the event is solved.
Comments can be added to a event at any time.
All events and actions are documented and can be read or exported
e.g. printed to handover information to medical staff ariving at site
OM Locating – Alarm Handling (2)
In addition to view a handset location, the operator can use the filter and search
function to display handsets within a area e.g. building or seach for special staff
e.g. security or doctors. For this 2 attributes can
be configured for each handset in OMP
Operators can also send messages with diffent prioritys to (multiple) handsets.
For this IMA need to be enabled in the OMM.
Alarm types
SOS key
alarm sensor
custom alarm
For senarios where the caller is not responsive and need to be located soon.
A locating alert can be initiated. As soon this alarm is initiated, the handset play
a rising alarm sound. So people in the area can hear the handset sound.
(The locating alert can be stoped by a user action on the handset)
OM Locating – Distress Operator Timeout,
Custom Alarms
If an operator does not response to a alarm event the OML

initiate the DISTRESS_OPERATOR_TIMEOUT trigger after 60 seconds.
Applications like an alarm server or IMA can monitor this trigger and
initiate further reactions if configured in the application.
IMA example alarm senario:

<AlarmScenario>
<as alarmTriggerId="DISTRESS_OPERATOR_TIMEOUT" level="1" recipients="tel:1000;tel:1001"
requiredPosConfirmCount="0" confirmTimeout="0" priority="PrioAlarm" popUp="true"
autoDelete="false" alarmMsg="Operator did not react on SOS/MANDOWN-Alarm! Add.-Info: %c"/>
</AlarmScenario>
Custom alarms
Custom alarms can be initiated using the alarmtrigger
LOC-<alarm> e.g. by using Feature access codes.
The OML does receive this alarm events and handle
them assimilable to other alarm events as SOS.
OM Locating – Requirements, Troubleshooting
Locating server requirements: (for latest req. see release notes and manual)
Hardware: 2 GHz Dual Core CPU, 1GB RAM, 10 GB hard disk space,
100MBit/s Ethernet network interface card (NIC)
Operating system: Red Hat Enterprise Linux 6 Server, Tomcat 6, Java 1.6
OM Locating clients / workstation requirements:
PC capable of running a recent browser with JavaScript, Cookies, and DHTML.

Sound card and set of speakers is recommended,
Ethernet connection to OM Locating server is required.
troubleshooting:
OML webpage is not available (404): check the URL and if OML.war is deployed
OML webpage is blank: check that java 1.6 is installed and used.
OML say missing license: check the OMM connection and if the OMM is licensed
RHEL6 - Tomcat 6 Installation and Deployment
To install Tomcat6 on RHEL 6 run “yum install tomcat6” from an terminal

with root privileges e.g. as root or as user using sudo.
The Locating Server application can be deployed by copy the OML.war file to the
tomcat webapps directory (/var/lib/tomcat6/webapps/)
Tomcat does also provide an web based application the Tomcat Webapps Manager.
install “yum install tomcat6-admin-webapps” (and “yum install tomcat6-webapps”)
Then start the tomcat6 server using /etc/init.d/tomcat6 start
To use the tomcat webapps manager a user account need to be created.

For this open the file /etc/tomcat6/tomcat-users.xml with an Text editor.
Add an new role for manager and assign this role to an user account e.g.
role: <role rolename= "manager"/> and
user: <user username="omm" password="password" roles="tomcat,manager"/>
Restart the tomcat5 server using /etc/init.d/tomcat6 restart e.g. after config changes
RHEL6 - Tomcat 6 Installation and Deployment (II)
If an war file is placed into the webapps folder, tomcat automaticly deploy this
file on startup. To use the manager open an browser with the URL
http://<tomcat-server>:8080/manager/html and login with the given user account.
(If an firewall is running, configure the port 8080 to be open for incoming connections)
The website show installed applications and tools to deploy new applications.
We recommend to undeploy old Locating Server version before installing an
new version. No settings will be lost, location images need to be installed again.
To deploy the Locating server select the oml.war file and click on deploy.
The application will be installed and started automaticly.
To run tomcat6 on PC startup use “chkconfig –levels 345 tomcat6 on”

600d/c - Messaging
The 600d/c can send and receive messages with up to 1000 characters.
Messages can have different prioritys (Info, Normal, High) and
can include confirmations requests (Jobs).
Status Icons
unread (message is not read)
finished (message is read, job is done)
final reject, final confirmation failed
open (message was opened but not finished)
Message type
confirmation message
Priority message – unread
message – read
high, e.g. urgent message job
alarm message, locating alert
For more information the Aastra 600d/c user

guide, message or alarm guides are available.
600d/c - Locating
The 600d/c handsets can be configured to locate other handsets.

The rights to be locatable and the locating permission have to
be configured in the portable parts configuration on the OMM.
If the handset and system provide locating abilities

and the handset (user) has locating permissions,
Locating will be shown in the handset Menu. Key programming
Handset locating will require the OM Locating server.

600d/c – vCard
600d/c handset can send and receive personal phonebook entries as vCard.
This can be done using IMA or the OMAXI interface e.g. send vCard(s) to
other 600d/c handsets, to / from email address or OMAXI applications.
The permission to send and receive vCards can be configured for each
handset using OMP. The user also can temporary enable receive vCard.
vCard options key 1 (priority) key 2 key 3 key 4 content
Name FN N <name in utf8 / latin1>
Private number TEL;HOME …;HOME;VOICE TEL;ISDN <number in ascii> *2
Business number TEL;WORK …;WORK;VOICE TEL;VOICE TEL;PREF <number in ascii> *2
Mobile number TEL;CELL …;CELL;VOICE <number in ascii> *2
Fax number TEL;FAX …;FAX <number in ascii> *2
E-Mail EMAIL EMAIL;PREF;INTERNET <E-Mail in ascii> *2
Quick-dial X-QC 2…9
Melody name X-MEL <xls source name>
VIP-number X-VIP <number in ascii> *2
Character set VERSION CHARSET Char mapper
Framing BEGIN:VCARD END:VCARD
*2 If there are numbers witch include + ( ) ,the handset will use this characters as dial digit. The default value maximum shall be 30.
600d/c – vCard (2) / Callback
If handsets have the permission (send or receive), personal directory entries

or the full personal directory can be send to other handsets.
The entries are automaticly applied at the receiving handset.
To send messages go to the personal directory > options > send

IMA example Alarm Trigger to send a predefined vCard entry to all handsets
<AlarmScenario>
<as alarmTriggerId="VCARD" level="1" recipients="tel:*" priority="PrioNormal“
alarmMsg="BEGIN:VCARD
VERSION:3.0
FN:Desk
TEL;HOME;
VOICE:4340
END:VCARD" vCard="true" />
</AlarmScenario>
Callback
Messages to 600c/d handset can include a callback number.

The given callback number is dialed when the user press hook off (green).
If a automated callback is initiated by the sending application, the handset
initiate the call automatically and the user need to unmute the terminal.
A142d Messaging for A5000
In A5000 Rel. 5.4 IP-DECT 2.1 is migrated to SIP-DECT® 4.0, with this step
the A142d VTI/XML Messaging for IP-DECT is replaced by OM AXI (as for A600c/d).
A142d handsets can receive messages send by AS7900 Rel 3.2.

The messaging capabilities are limited compared to A600c/d terminals.
e.g. 160 characters, limited character set, text messages only, one message list, …
To perform Messaging with A142d a handset software update via USB is required.
The A142d is not recognized by standard SIP-DECT® Messaging Applications
as IMA or OML
Message Message List

Message Traffic Shaping
Message traffic shaping is necessary to guarantee a non blocking message flow.

The messaging performance is influcenced by :
Paging areas and paging (approx. 20 parallel pagings per paging area)
Availability of DECT channels or PP’s (paging timeouts, busy RFPs)
Transmission time of a single message (about: 3-4sec 100bytes, 12sec 1000bytes)
Messages are queued by priority and send first in first out by queue priority.
If the handset has already a link e.g. active call, the message is send directly.
Messages with the priority locating alert are always send directly as well.
1 OMM 2 3
handset queue
OMAXI 4 Emergency
Alarm message queues
HIGH
Server 5 NORMAL
LOW
INFO
Message Traffic Shaping (2)
The traffic regulation ensures more than 50 percent of allowed paging requests per
time unit are reserved for call attempts (default configuration). To configure the
message traffic shaping use cmi crt in the ommconsole. OMP statistic counters
help you to analyse the system performance e.g. message delay, throughput,...
The calculation of the scheduling trigger depends on three parameters:

• Number of messages per seconds (default 3/sec) {1,..8}
• Increase in % depending on the number of paging areas (default 20) {0,..25}
• the number of paging areas Paging areas msg /h msg /min
1 10800 180
Adjustments should only be done by experienced
2-3 12960 216
administrators, ask for support if required.
4-7 15552 259
8-15 18662 310
CMI : cmi msg traffic control (ctr) ____ :
16-31 22394 372
CMI : : sendings = 3 [messages] per second
CMI : : paging areas = 1 (number of paging areas) 32-63 26872 446
CMI : : percent = 20 (increase of sendings in percent) 64-127 32246 535
CMI : that means: sendings are increased in steps of N*per.,
CMI : whenever the number of paging areas increases 2**N 128-256 38695 642
CMI : : calculated trigger time = 333 [msec] max. throughput(3msg/sec,20%)
OMP Device Placement
The OM Locating Application (OML) can use graphics

to show a base station location and map of the local area.
To simplify the creation of these graphics OMP offers the
Planning mode in the menu bar.
Using Device Placement you can assign configured RFPs

to images of a building or area (.jpg or .png).
Afterwards an image export for OML can be done.
Step 1: Image Management
Add your Images to OMP and select one (active) Image.

In the next step you can assign RFPs to this image.
After the assignment go back to Image management
to select a new active Image.
OMP Device Placement(2)
Step 2: Radio fixed parts
Select the RFPs you like to assign and click on assign to active image
OMP will switch to Placement view and

display the RFPs as an Icon in the upper left area.
Place the devices on your map by drag & drop.
OMP Device Placement(3)
Step 3: Image Management
After the RFPs have been assigned to your image(s),

you can adjust or set the scale of the overview images.
Finally select your images and

use generate to create the pictures for OML.
(Upload to OML server into the tomcat ../webapps/OML/images/locations/ directory)
Export project will save the project details e.g. images and RFP locations
Overview Images generated by OMP:
User Monitoring – Overview
The OMM can monitor the availability of handset users by active and passive checks.
This Monitoring includes various parameters to make sure the handset is available:
SIP registration, Battery state, Handset actions, Handset Firmware …
If a handset / user becomes unavailable the OMM generates an OM AXI Alarm Trigger
which then can be handled by OM AXI applications like IMA or OML.
OMM AXI OML

Locating
IMA
Alarm /
Escalation
active passive
IMA
(polling)
Text Messages
Email
OM AXI
Applications
Battery No activity Diversion

User Monitoring – Status Attributes
The DECT (combined) user status is a summary of status attributes.

If all conditions are fulfilled the user is “available”, as soon one condition fails
the user is “unavailable”. If the checks fail for a period of time (Escalation delay)
the OMM will generate an alarm and mark the user as “unavailable/escalated”.
The following status attributes are supported:
Handset assignment status (HAS) (Dynamic User logged on)

Handset subscription status (HSS) (DECT subscribed)
Handset registration status (HRS) (DECT attached)
Handset activity status (HCS) (Handset active within time period)
SIP user registration status (SRS) (SIP user registered)
Silent charging status (SCS) (Silent charging + Charger)
Call diversion status (CDS) (immediate call diversion enabled)
Handset battery status (HBS) (Battery power above limit, warn only)
Bluetooth status (BTS) (Bluetooth active, for further usage, warn only)
Software status (SWS) (minimal required SW version, warn only)
User Monitoring – Active / Passive Checks
Passive
The availability can be checked passively, event driven by checking the status
attributes which are changed due to user, administrator or automatic system/device
activities. This does not require additional resources e.g. DECT channels.
Active
Handset and OMM initiate periodically activities which indicate the handset availability.
This requires additional resources e.g. DECT channels and Battery Power
As this can be in conflict with other activities like messaging and voice calls,
this should only be enabled for a limited number of users.
Activity / Escalation
If the handset was not active for a certain period of time (a: 5-60min, p: 30-1440min)
or could not be reached e.g. during call setup or messaging delivery
the OMM automatically initiates an activity to check the DECT connectivity.
If this check fails the status changes to “unavailable”, the OMM then retries 2 times
more within Escalation delay before the state changes to unavailable/escalated.
User Monitoring – Configuration
User Monitoring can be configured in the System Settings

OMP > System > System Settings > User monitoring
Locating escalation: Escalate unavailable/escalated to OML
Startup delay: Time period after the OMM check the handset availability
Escalation delay: Time period before unavailability escalation (0-5min)
Activity timeout 1: passive monitoring activity timeout (30min – 24h)
Activity timeout 2: active monitoring activity timeout (5-60min)
Battery threshold: handset battery level alarm (0-100%)
Event e.g. battery OMM (re) init trigger Alarm

or timeout / no action Check (2x) After escalation delay
Available Unavailable (Warning) Unavailable/Escalated
User Monitoring needs to be configured in the User settings (default off)

OMP > Portable Parts > Overview > Handset > User monitoring
Select the Passive or Active Monitoring mode to enable Monitoring.
User Monitoring – Alarm / Escalation
When a user becomes unavailable/escalated the OMM generates an OM AXI

event. If configured, an OM AXI Application e.g. IMA and OML can handle this
event.
Alarm Triggers Event
UMON-WARN-USERSTATE user unavailable (warn)
UMON-ERR-USERSTATE user unavailable/escalated (error)
LOC-ERR-USERSTATE user unavailable/escalated (error) (for OML escalation)
UMON-OK-USERSTATE user becomes available again (ok)
OML
OML can handle Unavailable/escalated states as a customer specific event.
For this the User must be set locatable and Locating Escalation needs to be enabled
IMA Alarm Scenario
<AlarmScenario>
<as alarmTriggerId="UMON-ERR-USERSTATE" level="1" recipients="tel:123"
priority="PrioHigh" popUp="true" alarmMsg="UMON: %n Error: %c"/>
</AlarmScenario>
User Monitoring – Start Up and Restrictions
Handling during startup and failover
The availability status is set to “unknown” at startup.

After the Startup delay (2-15min) the OMM determines the availability status.
To speed up SIP registrations, monitoring enabled Users will be configured as VIP.
Restrictions
the availability of the device does not necessarily represent the user availability
e.g. whether a user actually carries his device with him or not.
check does not include the full infrastructure e.g. PBX trunks or active features
If a user is removed from the OMM then the monitoring stops without escalation
The OMM doesn’t monitor all handset features which may keep the handset from
ringing.
A142d: Silent charging state is not supported, as the handsets detach. (HRS alert)
GAP handsets: behavior depends on handset, which can not be guaranteed.
Limits RFP OMM: Active: 20, Passive: 30 and PC OMM: Active: 200, Passive: 300
SIP-DECT ® Video & Bluetooth Locating
preliminary, feature for limited trial
SIP-DECT® Video & Bluetooth Locating Overview
By using Bluetooth Beacon and USB Cameras a more detailed Locating is possible.
USB HUB
SIP-DECT ® - Video Locating
SIP-DECT® Video Locating combine the Locating Server Application (OML)

with USB Cameras connected to RFP(L) 35 and 43. The Locating Operator can watch
video streams of available cameras e.g. the camera next to a Emergency event.
OML display camera icons in the RFP detail information.

Also a overview picture of multiple cameras can be shown.
20m
USB HUB
SIP-DECT ® - Video Locating (2)
Configuration
For security reasons no OM AXI Application can access Video Cameras by default.
Go to OMP > System > User administration and create a new User with the
permissions: Video, Messaging, Monitoring and Locating.
Each Video device need to be configured and enabled in OMP > Video devices
Configure the Video device location and Video resolution.
OMP video device
configuration
OMP video
device status
SIP-DECT ® - Video Locating (3)
Technical details:
This feature is available for customer trial with Aastra guidance in the first step.
Aastra will offer qualified USB Equipment and Installation instructions.
Supported Video Device: Aastra will offer qualified equipment
Format: Motion JPEG. This is not supported by each browser e.g. IE!
Resolution: QCIF, QVGA, CIF, VGA, SVGA
External Applications can access the cameras (require OM AXI integration)
Bluetooth Locating
Bluetooth Locating allow to connect multiple Bluetooth Beacons via USB

Infrastructure (HUB, extender, cable) to RFP (L) 35 and 43 WLAN.
The Beacons will receive signals from locatable handsets and

transfer the location events to the Locating Server (OML).
This feature is available for customer trial with Aastra guidance in the first step.
Aastra will offer qualified USB equipment and installation instructions.
Bluetooth Locating (2)
Bluetooth beacons can be configured after they have been plugged into a RFP.
Go to OMP > Bluetooth beacons and configure the beacons.
Setup Location data as Name, Building, Floor and Room.

To adjust the range of this Beacon cell adjust the RSSI threshold.
Handset will only be shown in range when their signal is below the threshold.
The global RSSI thresholds (templates for each Beacon) can be configured
in OMP > System > System Settings > Bluetooth
Bluetooth Locating (3)
After the Bluetooth beacons have been configured, you can use the
OMP Device placement to assign them on map images.
Bluetooth Locating need to be enabled in the portable part configuration.

Enable this feature only for handsets where locating is required.
Check Bluetooth locatable in the Locating section, this enable the

Bluetooth module in the handset. An A620d/630d/622d/632d/650c is required.
OML will display Bluetooth Beacons as

SIP-DECT® 4.0
module 4: Troubleshooting Training
SIP-DECT® Troubleshooting Tools - Overview
OMP Monitoring
• Statistic Counter
• RFP Status
• Handset Status
Syslog
Eventlog
System Dump
SSH service shell
DECT IP Monitor
Handset Site Survey
DECTNet Monitor
The DECTNet Monitor shows the current

status of the base stations and telephones.
It shows the synchronization and

synchronization relations between
the base stations.
The DECT Monitor access can be released

via the OMM (“System > System Settings“).
The DECT Monitor is directly connected to

the active OMM.
limited to 256 RFPs with 512 handsets within the paging area 0, this tool is partly repaced by OMP
DECTNet Monitor (2)
Sync over Air relations
Program Messages
Handset state
basestations: state, DECT events from

active calls and channels basestation or handset
Event Log
In addition to the current system process status the Event log on the
OMM webservice provide an last error summary.
The output has the same format as the syslog output, but is limited to defined events only.
For detailed analyses or support requests, the full syslog output and
the system dump feature should be used.
OMP – System Dump
For troubleshooting it is important to get a snapshot of information about the

system regarding the most important logs and the status of base stations etc.
OMP can create a system dump log file, which collect and save this information
This can be done using OMP > System > Data Management > Miscellaneous
Select a directory and click on download. An “sysdump.txt” file will be generated here.
This text file include status and diagnostic information about the OMM and all RFPs.
OMP - System Dump (2)
The system dump file contain the following information:
OMM and from each base station

software version software version
uptime connection to OMM(s)
OMM resiliency status present media streams
handset database local Configuration Parameter
base station database rfpm configuration
base station round trip delays to OMM last syslog messages
sync over Air status and relations …
present handled calls
mediastream statistic
OM AXI connections
IMA status
automatic Database status
automatic User Import status
download over Air for 600d status
present OMM spy levels
…
OMP Monitoring > Statistics
OMP > Monitoring > System > Statistics
OMP does collect multiple system statistic counters.

If an single counter is selected an detailed window
show a graph and the counter details.
The detailed statistic history is only available for a

limited time frame. The total number counters are
avaliable for the hole OMM runtime.
OMP Monitoring > Radio Fixed Parts
The Radio fixed parts device list show the detailed status of
all configured base stations. The output can be sorted and filtered.
DECT is not enabled and/or

RFP not connected
DECT is enabled and RFP connected,

but DECT has not been activated yet
DECT is enabled and RFP is connected,
but RFP is not synchronized and
searches for other synchronized RFPs.
DECT is enabled and RFP is connected
and synchronized.
OMP Monitoring > Radio Fixed Parts > Sync View
Sync view show the DECT sync status of all RFPs and there sync relations.
The view can be filtered by the Filter in Radio fixed parts e.g. to see only one floor.
For more options on the sync view click on the arrow icon on the right side.
To view the sync relation of one or multiple RFPs select them in

the Radio fixed parts device list and click on Show sync. relations.
Or right click on the RFP in the Sync view and select Activate monitoring
background image file:
OMP Monitoring > Radio Fixed Parts > Sync View
The RFP icon color show the DECT sync status of the base station.
Grey: inactive
Red: not synchronized
Yellow: searching
Green: synchronized
Sync relations between RFPs are represented by arrows.

The color of the arrow is an indication of the RSSI value of the link:
Red: RSSI < -90 dBm

Orange: RSSI -90 dBm <= -70 dBm
Green: RSSI > - 70 dBm
If the mouse is moved over an RFP with monitoring activated a tool tip
with RSSI values will be opened.
OMP Monitoring > Radio Fixed Parts > Statistics
In addition to the system statistics the OMM collect base station events.
The following statistic counters will be monitored for each base station.
The events can be displayed for each RFP or as a list of all RFP’s for a
group of counters e.g. Voice channels, Air channels, Paging, Sync, RFP health
OMP Monitoring > Portable Parts
The Portable parts device list show the detailed status of all configured handsets.
The output can be sorted and filtered.
The colums Device activity and Last action show the current
and last handset activitys e.g. call, handover, paging, release
Handset activitys can be logged into a local pp_event.log file.

Click on Log events in the task bar to enable the logfile.
A log file will be created in the users home directory e.g.
MyDocuments on Windows and ~/.OMP on linux
This event log does log event type, Date, time, handset and RFP.
Supported event types: C – Connect, H - Handover, D - Call release,

P - Paging started, J - Setup Reject, B - Release from PP,
N - PP not found, U - Location registration, A – Detach
Health States
The OMM include a system Health State Monitoring for diffent subsystems.
The following states will be reported and can be accessed by OM AXI applications
e.g. OMP
name Description
sync Health state of RFP synchronization
standby Health state of standby OMM mechanism
autoDB Health state of Auto database export
download Health state of software download over air

…
protocol Warning or Error if there are RFPs
using a different protocol version
health types can have
the following states: branding Warning or Error if there are RFPs
using a different branding
inactive or unknown encryption Warning or Error if there are RFPs which do not
error support encryptions but encryption is enabled
warning
license Warning or Error if licensing is not (fully) satisfied
ok
ima Warning or Error if IMA is not (fully) working
Call Related Traces - Backtrace
The backtrace subsystem was developed to monitor handset connections

through the OMM system process communication e.g. calls
If an process detect handset connection related problems,

an backtrace output will be generated and the output is reported by syslog.
This feature is still under development, not all processes are included yet.
Backtrace is only available on PC OMM installations.
TRC : *************** Backtrace Start for PPN/PMID=0002F, Calling Number=2004 ******

TRC : Trc Output at end of call for PPN(0002F)
DLC : 11:10:14.400 - (0002F,000B) i MAC_CON_IND PMID(0002F) MCEI=13, BASCON, HO_NO, Cs, ECN=00, ..
LCE : 11:10:14.430 - (0002F) i ESTABLISH_IND Mode=B Chann=0x00 lln=0x02
LCE : 11:10:14.430 - (0002F) o ESTABLISH_RES
DLC : 11:10:14.430 - (0002F) Enter LINK_MULTIPLE_FRAME_ESTABLISHED
CC : 11:10:14.635 - (0002F) i 03 SETUP 05 0A 80 C0 10 00 E0 20 D7 1B 00 2F-06 06 A0 9D 10 18 72 B8-E0 …
CC : 11:10:14.635 - (0002F) o 83 CONNECT
DLC : 11:10:14.636 - (0002F) i AUDIO_SET_SER_REQ LCN(0x00), IWU(47), SERVICE(0x1)
DLC : 11:10:14.636 - (0002F) o MSM_ALLOC_HANDLE_REQ MCEI=13, RFPID(0011)
DLC : 11:10:14.636 - (0002F) i MSM_ALLOC_HANDLE_RSP HDL(FE83), 10.103.50.241, RTP(16332), RTCP(16333)
DLC : 11:10:14.636 - (0002F) o AUDIO_SET_SER_CNF LCN(0x00), IWU(47), H(65155), 10.103.50.241, RTP(16332), ..
Syslog
Diagnosis- and status reports from the OMM and the base stations can be sent
with the Syslog protocol to a Syslog server.
A Syslog server can be configured for all base stations in the OMM (> “System“).
In case that the Syslog server is set with the OpenMobility configurator,
the reporting also shows ramp-up reports of the base stations.
Syslog Format
The Syslog Output of the basestations have a specific format:
example message:
User.Warning 10.1.1.30 OMM: 0000167605 *** CNF: setting system name ‚aastra'
User.Warning > syslog severity

10.1.1.30 > sender ip-address
OMM: > application send this event e.g. OMM, RFP, kernel
0000167605 > equal
*** > severity (** = low <> ***** = high)
CNF: > process name
setting system name ‚aastra' > process output
Syslog - Sample
Most processes provide a [id] to identify

a user, device, link or session.
DSIP trace (level 2) [24|00] < device 24 (dez) = 0x18 (hex)
omm: ..29 ** DSIP: [24|00] Idle => StatePredial
omm: ..29 ** DSIP: [24|00] Predial => StateCallProceeding
omm: ..29 ** DSIP: [24|00] Allocated RTP channel 10.10.8.189:16368 / :
omm: ..29 ** DSIP: [24|00] StartTransactionSendRequest INVITE
omm: ..38 ** DSIP: [24|00] Send to sipproxy:5060 INVITE sip:532@sipproxy SIP/2.0
omm: ..38 ** DSIP: [-1|-1] rcv SIP/2.0 100 Giving a try
omm: ..38 ** DSIP: [24|00] ICT rcv SIP/2.0 100 Giving a try
omm: ..38 ** DSIP: [24|00] CallProceeding => StateProvisionalResponded
omm: ..38 ** DSIP: [-1|-1] rcv INVITE sip:532@10.10.8.189 SIP/2.0
omm: ..38 ** DSIP: [38|-1] IST rcv INVITE sip:532@10.10.8.189 SIP/2.0
omm: ..95 *** CMI : [PPN:x0026] Link not Establish: PD=x71, TI=xff, MT=x04, LI=63, Data=
omm: ..79 ** CMI_C: [24] <>EndP[0|0|1] PP_ACTIVE rfpId=0 …: [ CALL_REL | RELEASE ] 3/0:
10.10.8.189:16374
PPN = portable part / device id

UID = user id
SIP-DECT® Service Shell - basics
RFPs allow a SSH access when configured in OMM or the RFP is starting
Enable “remote access” in the OMM system settings to permit access.
The login is only possible with the credentials received by the OMM.
Service Shell can be used to
• see syslog events (current and short history)
• see the status of applications and processes
• initiate the restart or reload processes and configuration files
• restart the base station
SIP-DECT® Service Shell – basic commands
Command Function
logread display the log history stored in the ram of this RFP
setconsole enable the output of syslog messages to this terminal (real time)
ldb Display configured OM Configurator parameter for local startup
ping Send ping to a IP Address, use ctrl + c to stop the ping
Reboot Restart the RFP
? command list / help
Notice!
Some command and trace levels
can influence the system stability
SIP-DECT® Service Shell – RFP Manager
The RFP Manager handle the startup of the RFP and applications like the OMM.
With the rfpm_console you can check and force renews: DHCP, ipdect.cfg, firmware
Command Function
env Display startup configuration (DHCP, OM CFG, ipdect.cfg)
renew Force reload / renew of configuration (DHCP, ipdect.cfg, iprfp3G.dnld)

imgchk check for new firmware, use “imgchk 1” for restart after download
spy Initiate traces (reset the spy levels with “deftrc” )
“spy fts 2” > display all file downloads
SIP-DECT® Service Shell – OMM Console
The OMM console provide access to the subsystems in the OMM Application.
In this shell information about the status and configuration like in OMP are displayed.
There also some command and traces which provide additional actions.
Command Function
ipl List connected RFPs including the connection quality
rping Initiate a ping from multiple RFPs

rping host [ all | r:<rfpId> | c:<cluster> | p:<profile> ]
msm c Display active media streams
ima IMA commands e.g. “ima conf” to reload the ima.cfg file
epr Display dynamic logged in users and reload all external users files
sync List all sync over air relations using “sync rels”
xml Display active handset xml sessions
SIP-DECT® Service Shell – OMM Console (2)
Most traces in SIP-DECT® can be initiated in the ommconsole using “spy”.

Usage: spy <key> <level> (level scale: 0=debug, 2=normal events, 3=default, 6=off)
Command Function
spy dsip 2 basic SIP trace (for full packet trace add “dsip trcl full”, this make load !!)
spy cmi_c 2 basic call trace
spy fts 2 Display file downloads e.g. ima.cfg, aafon6xxd.dnld, user.cfg, xml apps.
spy ima 2 IMA alarm scenario and message progress
spy epr 2 Dynamic user login and external user data
spy cnf 2 Display configuration / DB changes
spy msm 2 media stream setup and handover
spy xml 2 Display XML terminal applications and display modifications.

External Services and Application Overview
Locating Server OMI OMM RFP RFPM RFP config

FTS
(OM files
Alarm Server
AXI)
DHCP
OMP
Provisioning TFTP
Email Server IMA Syslog
RSS feeds
This picture show external applications
and services which can be accessed
User data files FTS EPR by OMM and RFP.
Automatic DB
ADB The orange boxes are interface names
Backup
which are also used in service applications
LDAP Server TB e.g. spy levels, statistic counters, syslog, …
NTP SNTP
Core Dump
If there some fatal error on OMM and the software is breaking down,
the OMM is able to generate memory dump (core dump).
The OMM is able to store these core files on a TFTP server in your network.
To enabling core file creation write on OMM command line:
(If you login to the shell in user mode use ldb core= , in root mode local_db core=)
local_db core=yes
local_db core_srv=server-ip – TFTP server IP address
local_db core_path=path – file path on TFTP server (must writable)
Restart the OMM on the shell (or power off) after set the core options, to activate the feature
If no local_db_core_srv and local_db_core_path is given the OMM try to write

the core files to the TFTP server and path where the basestation software was downloaded.
The TFTP server must allow writing new files, this is usually not standard.
To disable the core file capturing write on command line: local_db core= (and restart)
Network Ports
Thank you
For the latest software and documentations visit your local

Aastra Websites e.g. http://www.aastra.com/sip-dect.htm#dl_software
(aastra.com > Support > Document Library > Mobility > SIP-DECT)
For technical support requests, please contact your local Aastra support.
Last slide & feedback (Aastra internal)
For the latest software and documentations go on
http://portal.aastra.com/coe/support_germany/
Please subscribe in the news sections, to receive information updates.
For technical support requests please go to Teamtrack (SIP DECT on <call server>)
https://eucs.aastra.com/tmtrack/tmtrack.dll?
feedback to this slides is also welcome. email: jzelina@aastra.com

SIP-DECT® 4.0
Training Labs

Lab: Basic Configuration
Tasks:
Configure one Base Station (RFP) as OMM and perform a basic configuration.
Connect a second RFP if available and subscribe your handset(s) to the system.
Make a call between the handsets and check signal level using the site survey mode.
Backup your OMM configuration. (Auto DB export)
Guideline:
setup a TFTP Server (software from tools) and put the software into TFTP root
configure the RFP startup using OM Configurator
connect to OMM Webservice and login (user:omm password:omm)
change your Passwords (5 or more characters, using lower + UPPER + digits)
configure system settings: Name, PARK, Domains, AC, ...
configure SIP settings: Proxy, Registrar ...
create your RFP(s) in Radio fixed parts (check DECT active)
create your Handset(s) in Portable parts
enable (wildcard) subscription in Portable parts
subscribe your handset(s)
Lab: RFP startup & Standby OMM
Tasks:
Startup your base station using the RFP configuration files (see sample files)
Try the different OM Configurator options e.g. multiple TFTP Servers
Enable a Standby OMM configuration
Guideline:
setup TFTP Server (tools), failover from local server to central server
create RFP config files (ipdect.cfg)
setup a syslog server for more output
enable a Standby OMM configuration (e.g. in ipdect.cfg)
Lab: Import, LDAP, DT, User config files
Tasks:
Apply your system license

Configure the LDAP directory with Digit Treatment
Subscribe dynamic handsets to login with a user account (see sample files)
Try OMM internal users and external users with config files
Guidelines:
apply your license file if not already done

configure the corporate directory
play around with digit treatment
enable autocreate on subscription (OM)
delete a handset and subscribe again using Autocreate
Create a feature access code (generic, login, logout)
login to a internal dynamic user
login to a external dynamic user
Lab: Team Task - Messaging
Customer requirements:
It should be possible to call each other.

One of our departments has problem with violent patients,
I am worried about the health and safety of my employees.
On each shift there is a shift manager responsible for making important decisions,
however sometimes personnel can’t get hold of him when his handset is not reachable which
creates critical situations. Please solve this.
We have patients which like to break out, we should have the ability to report this.
We have tasks which we like to distribute instantly to specific groups.
We are no technology experts it should be easy to initiate alarms.
I don’t understand why it is not possible for nurses to order food for patients on their phone.
Sometimes I have messages I like to share with all users from my Computer or phone.
I hate false alarms and will test your solution to ensure there will be no loopholes.

Sip Dect

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sip Dect

Загружено:

Авторское право:

Доступные форматы

SIP-DECT® 4.

Aastra confidential information / for training purpose only © Aastra - 2013 3

DECT base stations Additional equipment

RFP(L) 35: indoor

OMM Activation Kit Headsets

Base Station DECT features

RFP (L) 42 WLAN

Aastra confidential information / for training purpose only © Aastra - 2013 7

A SIP-DECT system is controlled via an active OpenMobility Manager (OMM).

OMM PBX / Callserver

Aastra confidential information / for training purpose only © Aastra - 2013 8

DECT handsets (600d/c series) can access external applications

call / redial lists

XML Applications can include different objects:

Applications can also push information to handsets Idle screen modification

This Aastra XML interface is similar to the one used by

Base station (RFP) Start Up

Multicast TFTP Download (RFP 32/34/42) DHCP Server with DHCP / OM

Aastra confidential information / for training purpose only © Aastra - 2013 11

Aastra confidential information / for training purpose only © Aastra - 2013 12

Aastra confidential information / for training purpose only © Aastra - 2013 14

XML Alarm triggers

IMA Locating Server

Base station visibilitys reported by the handset

Handset last location update history

Since the OMM Release 2.1 licenses are required.

In order to properly address small, medium and large installations

tiny – 1-2 RFPs (no license)

A demonstation license is configured if the system start up without configuration.

# License description dependency License steps

1 OM System Enables telephony for a system of 10, 20, 50, 100,

L-RFP systems (small systems up to 20 L-RFPs with incl. licensed features)

standard RFP systems (medium and large systems up to 2048 RFPs)

PARK System CD System CD System CD License Server License Server

1-2 RFP (standard)

Aastra confidential information / for training purpose only © Aastra - 2013 22

System activation process

Activation key or License document

The license server is available at http://licence.aastra.de/

Aastra confidential information / for training purpose only © Aastra - 2013 25

# Name of the License Description SAP No. JDE No.

Aastra confidential information / for training purpose only © Aastra - 2013 27

Aastra confidential information / for training purpose only © Aastra - 2013 28

Aastra confidential information / for training purpose only © Aastra - 2013 29

Aastra confidential information / for training purpose only © Aastra - 2013 30

-60 / -65 dBm

-50 very good

Aastra confidential information / for training purpose only © Aastra - 2013 31

It is possible to set up several clusters, handset‘s can do a roaming between

SIP DECT networks should be designed to have multiple synchronization path

Aastra confidential information / for training purpose only © Aastra - 2013 33

PBX / Signaling IP-Phone /

An DHCP-server or permanent local network configuration in the base station

For the Start Up of RFP (L) 32 / 34 and 42 a TFTP-server is required

Aastra confidential information / for training purpose only © Aastra - 2013 35

RFP(L) 32/34/42 (2G / second generation) - Startup require TFTP Server

RFP(L) 35/36/37/43 (3G / third generation) – SW Download

Software Updates are done in the Application Phase by TFTP (default) or

Aastra confidential information / for training purpose only © Aastra - 2013 36

In this example we use a PumpKIN TFTP Server on a MS Windows® PC.

Aastra confidential information / for training purpose only © Aastra - 2013 37

LED 1 LED 2 LED 3 LED 4 comment

continuous Power connected