Aastra DECToverSIP Instruction Manual

Installation, Administration and
Maintenance
DECToverSIP
Release 1.8
Document ID: depl-0900
Version: 1.8
Aastra Zeughofstr. 1
10997 Berlin, Germany ©February 2010 - All Rights
Reserved
No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying,
recording, or information storage and retrieval system, for any purpose without the express written permission of Aastra.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 2 (104)
Table of contents
1OVERVIEW ....................................................................................................................................................... 4
1.1 PURPOSE .................................................................................................................................................... 4
1.2 DECLARATION OF CONFORMITY ................................................................................................................ 4
1.3 ABBREVIATIONS AND DEFINITIONS ............................................................................................................ 4
1.3.1 Abbreviations.............................................................................................................................. 4
1.3.2 Definitions................................................................................................................................... 4
1.4 REFERENCES .............................................................................................................................................. 7
2INTRODUCTION.............................................................................................................................................. 8
2.1 ABOUT THE DECTOVERIP USING SIP SOLUTION ....................................................................................... 8
2.2 ABOUT THE ACCESS POINTS (RFPS’)......................................................................................................... 9
2.3 OPENMOBILITY MANAGER ...................................................................................................................... 12
2.4 IP SIGNALLING AND MEDIA STREAM......................................................................................................... 12
2.5 RFP SYNCHRONIZATION.......................................................................................................................... 15
2.6 RFP CHANNEL CAPACITY......................................................................................................................... 16
2.7 ABOUT THE PORTABLE PARTS ................................................................................................................. 17
2.8 SYSTEM CAPACITIES................................................................................................................................. 18
3INSTALLATION AND CONFIGURATION ................................................................................................ 19
3.1 OPENMOBILITY START-UP ....................................................................................................................... 19
3.1.1 Start-up of the RFPs’................................................................................................................. 19
3.1.1.1 Booting overview....................................................................................................................19
3.1.2 Start-up of the OpenMobility Manager..................................................................................... 20
3.1.3 Booter........................................................................................................................................ 20
3.1.3.1 DHCP client............................................................................................................................20
3.1.3.1.1 DHCP request.........................................................................................................................20
3.1.3.1.2 DHCP offer.............................................................................................................................22
3.1.3.1.3 Retries.....................................................................................................................................22
3.1.3.2 TFTP client .............................................................................................................................22
3.1.4 Application................................................................................................................................ 22
3.1.4.1 Booter update..........................................................................................................................24
3.1.4.2 Selecting the right DHCP server .............................................................................................24
3.1.5 RFP LED status......................................................................................................................... 25
3.1.6 State graph of the start-up phases.............................................................................................. 27
3.2 STATIC LOCAL CONFIGURATION OF A RFP............................................................................................... 28
3.3 CONFIGURING THE OPENMOBILITY MANAGER........................................................................................ 32
3.3.1 Service Login procedure ........................................................................................................... 33
3.3.2 System....................................................................................................................................... 35
3.3.2.1 System settings........................................................................................................................35
3.3.2.1.1 Restarting the OMM...............................................................................................................37
3.3.2.1.2 Encryption ..............................................................................................................................37
3.3.2.1.3 Regulatory domain..................................................................................................................38
3.3.2.2 SIP...........................................................................................................................................38
3.3.2.3 User account............................................................................................................................41
3.3.2.4 Time zones..............................................................................................................................42
3.3.2.5 Database Management ............................................................................................................43
3.3.2.5.1 Manual Database Import.........................................................................................................45
3.3.2.5.2 Manual Database Export.........................................................................................................45
3.3.2.5.3 Automatic Database Import....................................................................................................46
3.3.2.5.4 Automatic Database Export....................................................................................................47
3.3.3 RFP configuration..................................................................................................................... 48
3.3.3.1 Creating and Changing RFPs’.................................................................................................49
3.3.3.1.1 New, change and delete button...............................................................................................49
3.3.3.1.2 Import by configuration files ..................................................................................................49
3.3.3.1.3 Capture of RFPs’ ....................................................................................................................50
3.3.3.2 States of a RFP........................................................................................................................51
3.3.3.3 RFP HW type..........................................................................................................................52
3.3.3.4 OMM / RFP SW version check...............................................................................................52
3.3.4 Configuration of Portable Parts................................................................................................. 52
3.3.4.1 Creating and Changing PPs’....................................................................................................53
3.3.4.1.1 New, change and delete button...............................................................................................53
3.3.4.1.2 Import by configuration files ..................................................................................................54
3.3.4.2 Subscription ............................................................................................................................55
3.3.4.2.1 Subscription with configured IPEI..........................................................................................56
3.3.4.2.2 Wildcard Subscription ............................................................................................................57

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 3 (104)
3.3.4.3 Searching within PP list ..........................................................................................................57
3.3.5 WLAN Configuration (RFP L42 WLAN only) ........................................................................ 58
3.3.5.1 Optimizing the WLAN............................................................................................................60
3.3.5.2 Securing the WLAN with Radius............................................................................................61
3.3.5.3 Requirements for the WLAN ..................................................................................................64
3.3.6 System features ......................................................................................................................... 64
3.3.6.1 Central configuration of LDAP access....................................................................................64
3.3.6.2 Digit treatment ........................................................................................................................66
3.3.6.3 Feature Access Codes..............................................................................................................66
4SECURITY ....................................................................................................................................................... 68
4.1 THE SECURITY CONCEPT ......................................................................................................................... 68
4.2 ACCOUNT TYPES ...................................................................................................................................... 68
4.3 CHANGING ACCOUNT DATA .................................................................................................................... 69
4.4 POTENTIAL PITFALLS ............................................................................................................................... 70
5OMM RESILIENCY........................................................................................................................................ 71
5.1 HOW OMM RESILIENCY WORKS............................................................................................................. 71
5.2 INTRODUCTION ........................................................................................................................................ 71
5.3 CONFIGURING OMM RESILIENCY............................................................................................................ 71
5.4 FALL OVER SITUATIONS .......................................................................................................................... 71
5.5 FALL OVER FAILURE SITUATIONS............................................................................................................ 72
5.6 SPECIFIC RESILIENT SITUATIONS ............................................................................................................. 73
5.6.1 How A Resilient OMM Becomes Active.................................................................................. 73
5.6.2 Handling When Both OMMs’ Are Not Synchronized.............................................................. 73
5.6.2.1 Two DECT Air Interfaces.......................................................................................................74
6DOWNLOAD OVER AIR............................................................................................................................... 75
6.1 HOW DOWNLOAD OVER AIR WORKS ....................................................................................................... 75
6.2 HOW TO CONFIGURE DOWNLOAD OVER AIR............................................................................................ 76
7MAINTENANCE.............................................................................................................................................. 79
7.1 SITE SURVEY MEASUREMENT EQUIPMENT................................................................................................ 79
7.2 CHECKING THE AASTRA DECT 142 /AASTRA 142D HANDSET FIRMWARE VERSION ............................... 79
7.3 DIAGNOSTIC............................................................................................................................................. 79
7.3.1 Aastra DECT 142 / Aastra 142d site survey mode.................................................................... 79
7.3.2 Aastra DECT 142 / Aastra 142d auto call test mode................................................................. 80
7.3.3 Aastra DECT 142 / Aastra 142d auto answer test mode........................................................... 80
7.3.4 Syslog........................................................................................................................................ 81
7.3.5 ssh user shell ............................................................................................................................. 81
7.3.5.1 Login.......................................................................................................................................83
7.3.5.2 Command overview ................................................................................................................83
7.3.5.3 RFP console commands ..........................................................................................................84
7.3.5.4 OMM console commands .......................................................................................................84
7.3.6 Core file captchering................................................................................................................. 85
7.3.7 DECT Monitor.......................................................................................................................... 85
8APPENDIX ....................................................................................................................................................... 90
8.1 COMMUNICATIONS REGULATION INFORMATION FOR AASTRA DECT 142 US........................................ 90
8.2 COMMUNICATIONS REGULATION INFORMATION FOR RFP 32 OR RFP 34 (NA)....................................... 91
8.3 PRE CONFIGURATION FILE RULES ............................................................................................................ 94
8.3.1 PP configuration file (OMM database) ..................................................................................... 95
8.3.1.1 Supported Instructions.............................................................................................................95
8.3.1.2 Data section fields...................................................................................................................95
8.3.1.3 Example ..................................................................................................................................95
8.3.2 RFP configuration file/central (OMM database)....................................................................... 97
8.3.2.1 Supported Instructions.............................................................................................................97
8.3.2.2 Data section fields...................................................................................................................97
8.3.2.3 Example ..................................................................................................................................97
8.3.3 RFP configuration file/local (OM Configurator)....................................................................... 99
8.3.3.1 Supported Instructions.............................................................................................................99
8.3.3.2 Data section fields.................................................................................................................100
8.3.3.3 Example ................................................................................................................................100
8.4 PROTOCOLS AND PORTS ......................................................................................................................... 103

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 4 (104)
1 Overview
1.1 Purpose
This document describes the installation, configuration and maintenance of
the DECToverIP using SIP solution.
1.2 Declaration of Conformity
The CE mark on the product certifies its conformity with the technical
guidelines for user safety and electromagnetic compatibility, valid from the
date of issue of the relevant Declaration of Conformity pursuant to European
Directive 99/5/EC. The Declaration of Conformity can be viewed on the
Aastra homepage.
1.3 Abbreviations and definitions
1.3.1 Abbreviations
AC Authentication Code
ADPCM Adaptive Differential Pulse Code
Modulation
DECT Digital Enhanced Cordless
Telecommunication
DHCP Dynamic Host Configuration Protocol
DSP Digital Signal Processor
FCC Federal Communications Commission
GAP Generic Access Profile
IPEI International Portable Equipment Identity
HTTP Hyper Text Transfer Protocol
OMM OpenMobility Manager
PARK Portable Access Rights Key
PP Portable Part (DECT handset)
SNMP Simple Network Management Protocol
TFTP Trivial File Transfer Protocol
RFP Radio Fixed Part (Access Point)
RTCP Real Time Control Protocol
RTP Real Time Protocol
1.3.2 Definitions
Aastra DECT 142
Handset / Aastra
142d
Aastra DECT 142 Handset / Aastra 142d
In the context of the DECToverIP using SIP solution, an
Aastra DECT 142 Handset, Aastra 142d and Portable
Part (PP) are interchangeable.
In consideration of differences in regulatory requirements
between North America and all other areas of the world
exist two different PP variants which use specific
frequency bands and field strengths:

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 5 (104)
•Aastra DECT 142
For use in North America.
•Aastra 142d
For use in all other areas.
Access Point Access Point
In the context of the DECToverIP using SIP solution, an
Access Point and a Radio Fixed Part (RFP) are
interchangeable.
Asterisk Asterisk
Asterisk is a complete Open Source PBX in software. It
runs on Linux, BSD and MacOSX and provides many
features. Asterisk supports voice over IP in many
protocols, and can interoperate with almost all standards-
based telephony equipment.
DECT Digital Enhanced Cordless Telecommunication
• The standard (ETS 300 175) essentially specifies the
air interface, known as the radio interface. Voice and
data can both be transmitted via this interface.
• Its technical key characteristics for Europe are:
• Frequency range: approx. 1880 – 1900 MHz
(approximately 20 MHz bandwidth)
• 10 carrier frequencies (1728 kHz spacing) with 12
time slots each
• Doubling the number of time slots (to 24) using the
TDMA process
• Net data rate per channel of 32 kbps
(for voice transmission using ADPCM)
• Voice coding using the ADPCM method
Its technical key characteristics for North American are:
• Frequency range: approx. 1920 – 1930 MHz
(approximately 10 MHz bandwidth)
• 5 carrier frequencies (1728 kHz spacing) with 12
time slots each)
• Doubling the number of time slots (to 24) using the
TDMA process
• Net data rate per channel of 32 kbps
(for voice transmission using ADPCM)
• Voice coding using the ADPCM method
GAP Generic Access Profile

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 6 (104)
• GAP is the abbreviation for Generic Access Profile
• The GAP standard (ETS 300 444) is based on the
same technology as DECT, but is limited to the most
important basic features. This standard was created in
order to allow telephones of different vendors to be
used on any type of DECT system. It thus represents
the smallest common denominator of all manufacturer-
specific variants of the DECT standard.
• An important limitation in the GAP standard is that
external handover is not possible. For this reason
connection handover is used, which is supported by
GAP terminals.
• The operation of GAP-capable telephones is
comparable to that of analogue terminals. For
example, features can be called up via ‘*’ and ‘#’
procedures.
Handover Handover
A handover is similar to roaming, but occurs during an
ongoing call. A handover normally takes place “in the
background”, without disrupting the call (seamless
handover).
IPEI International Portable Equipment Identity
•13-digit identification code for PPs’
•Example: 00019 0592015 3
(the final digit is the checksum).
•The code is represented in decimal form.
•This code is globally unique.
PARK Portable Access Rights Key
Access code for the Portable Part. This code determines
whether a PP can access a particular DECT system. Used
for unique selection of a dedicated the system from a
handset at enrolment/subscription time. Labelled on the
OpenMobility CD and unique to each SIP-DECT
deployment.
Roaming Roaming
While in motion, the PP performs ongoing measurements
to determine which RFP is best received. The one that can
be best received is defined as the active RFP. To prevent
the PP from rapidly switching back and forth between two
RFPs’ that have similar signal strength, certain threshold
values are in effect.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 7 (104)
1.4 References
/1/ RFC 1350, The TFTP Protocol, Revision 2, July 1992
/2/ RFC 1889, RTP: A Transport Protocol for Real-Time Applications,
January 1996
/3/ RFC 2030, Simple Network Time Protocol (SNTP) Version 4 for IPv4,
IPv6 and OSI, October 1996
/4/ RFC 2131, Dynamic Host Configuration Protocol, March 1997
/5/ RFC 2327, SDP: Session Description Protocol, April 1998
/6/ RFC 2474, Definition of the Differentiated Service Field (DS Field) in the
IPv4 and IPv6 Headers, December 1998
/7/ RFC 2617, HTTP Authentication: Basic and Digest Access
Authentication, June 1999
/8/ RFC 3164, The BSD Sys Log Protocol, August 2001
/9/ RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and
Telephony Signals, May 2000
/10/ RFC 3261, Session Initiation Protocol (SIP), June 2002
/11/ RFC 3264, An Offer/Answer Model with Session Description Protocol
(SDP), June 2002
/12/ RFC 3420, Internet Media Type message/sipfrag, November 2002
/13/ RFC 3515, The Session Initiation Protocol (SIP) Refer method, April
2003
/14/ RFC 3665, The Session Initiation Protocol (SIP) Basic Call Flow
Examples, December 2003
/15/ RFC 3842, A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP), August 2004
/16/ RFC 3891, The Session Initiation Protocol (SIP) “Replaces” Header,
September 2004
/17/ RFC 3892, The Session Initiation Protocol (SIP) Referred-By
Mechanism, September 2004

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 8 (104)
2 Introduction
2.1 About the DECToverIP using SIP solution
The DECToverIP using SIP solution comprises the following components:
•Aastra SIP-DECT Access Points (also known as Radio Fixed Parts
(RFPs’)) being distributed over an IP network and offering DECT wireless
and IP interfaces.
•A SIP Call Manager/IP PBX/Media Server platform (e.g. Asterisk).
•Aastra DECT 142 Handsets / Aastra 142d (also known as Portable Parts
(PP))
•OpenMobility Manager (OMM): Management interface for the
DECToverIP using SIP solution, which runs on one of the Radio Fixed
Parts.
The following figure gives a graphical overview of the architecture of the IP
DECT wireless solution:
The IP PBX/media server/media gateway, OMM and the RFPs’ communicate
through the IP infrastructure. The RFPs’ and the Portable Parts communicate
over the air, where the DECT GAP protocol or DECT GAP with proprietary
enhancements is used.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 9 (104)
2.2 About the Access Points (RFPs’)
Aastra DeTeWe provides 3 kind of Access Points:
- RFP L32
DECT Access Point as indoor model
- RFP L34
DECT Access Point as outdoor model
- RFP L42 WLAN
DECT + WLAN Access Point as indoor model
In general the RFP 32 and RFP 34 have the same hardware and software
capabilities. Please be aware of the regulatory differences between North
America and all other areas of the world . These differences lead to different
RFP 32/34 variants which use specific frequency bands and field strengths:
•RFP 32 NA or RFP 34 NA (NA)
-Frequency Band 1920 to 1930 MHz
-5 carrier frequencies
-Transmit Power 20 dBm
•RFP L32 IP or RFP L34 IP (EMEA)
-Frequency Band 1880 to 1900 MHz
-10 carrier frequencies
-Transmit Power 24 dBm
The RFP L42 WLAN is only available for the EMEA region.
One RFP within a SIP-DECT installation must be declared to operate as the
OpenMobility Manager (OMM). The RFP acting as the OMM may also act as
a regular RFP as well if it is included into a DECT Cluster.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 10 (104)
RFP only mode
Within this mode the RFP converts IP protocol to DECT protocol and then
transmits the traffic to and from the handsets over a DECT time slot. On air
the RFP has 12 available time slots, 8 can have associated DSP resources
for media streams, the remaining 2 time slots are used for control signalling
between RFPs’ and the PPs’, and 2 time slots are reserved for hand-in
purposes.
Groups of RFPs’ can be built which are named clusters. Within a cluster
RFPs’ are synchronized to enable a seamless handover when an user
crosses from one RFP’s zone of coverage to another. For synchronization it
is not necessary for a RFP to communicate directly with all other RFPs’ in the
system. Each RFP only needs to be able to communicate with the next RFP
in the chain. But it is preferable for a RFP to see more than one RFP to
guarantee synchronization in the event that one of the RFPs’ fails.
The 2 control signalling channels are also used to carry bearer signals that
signal the handset to start the handover process. If the radio signal of
another RFP is stronger than that of the current RFP, then the handset starts
the handover process to the RFP that has the stronger signal as the user
moves around the site.
OpenMobility Manager mode
In this mode a RFP functions as a regular RFP. Additionally it is responsible
for SIP signalling between the IP DECT system and the telephony or media
server. Further on it takes over the management part of the IP DECT
solution. You designate a RFP as the OMM by assigning an IP address to
the RFP within the DHCP scope (see chapter 3) or by setting the data via the
OM Configurator (see 3.2). After a RFP is designated as the OMM, it starts
the extra services on board (for example, the web service that supports the
management interface). All RFP’s download the same firmware from a TFTP
server but only one RFP activates the OMM services.
Note: It is possible to deactivate the DECT part of a RFP. If the DECT
interface is deactivated then all resources (CPU and memory) are available
for the OMM.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 11 (104)
Power jack (120 V/230 VAC adapter)
Ethernetjack
Power supply in line with Power over Ethernet
standard IEEE 802.3af
LED red (Booter)
RFP 32 NA /
RFP L32 IP
LED orange(Application)
LED green (Application)
UnusedLED
Power jack (120 V/230 V AC adapter)
Ethernetjack
Power supply in line with Power over Ethernet
standard IEEE 802.3af
LED red (Booter)
RFP L42 WLAN
LED orange (Application)
LED green (Application)
LED for WLAN

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 12 (104)
2.3 OpenMobility Manager
The OpenMobility Manager (OMM) performs the following tasks:
•Signalling gateway (SIP <-> DECT).
•Media stream management.
•Managing sync-over-air functions between RFPs’.
•Facilitating system configuration modifications.
•Provides additional services e.g.
- Corporate directory (LDAP based)
The OpenMobility Manager (OMM) runs on one of the RFPs’.
2.4 IP signalling and media stream
To establish a call between an IP Phone and a PP (Aastra DECT 142
Handset / Aastra 142d), the following IP streams must be established:
•A signalling channel to and from the SIP phone.
•A signalling channel to and from the OMM.
•A control interface between the OMM and the RFP that has a connection
to the PP (known as the primary RFP).
•A Real Time Protocol (RTP) / Real Time Control Protocol (RTCP)
connection between the SIP phone and the primary RFP.
The following figure illustrates this scenario.
To establish a call between two PPs’ the same IP streams must be
established like in the scenario before, except the IP phone is not involved.
The following figure illustrates this scenario.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 13 (104)
A call from one PP to another that resides on the same RFP will loop back
within the RFP, if no media gateway is involved. So the call will not pass
through to the Local Area Network (LAN). Although the voice packets will not
impact LAN traffic, signal packets will.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 14 (104)
If the PP user is moving, the PP detects that another RFP has a better signal
strength and, therefore, it starts the handover process. The media stream
from the IP phone cannot move to the secondary RFP, so the primary RFP
uses the LAN to direct the voice to the secondary RFP, as shown in the
following figure.
As the PP user moves into the next RFP zone of coverage, the PP detects
that the RFP has a better signal strength. Again the media stream from the
SIP phone cannot move to the secondary RFP, so the primary RFP uses the
LAN to direct the voice to the new secondary RFP.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 15 (104)
2.5 RFP Synchronization
To guarantee a seamless handover if a caller moves from one RFP zone of
coverage to another RFP zone of coverage, an accurate synchronization of
the RFPs’ is necessary.
The RFPs’ are synchronized over the air interface. The first RFP to complete
start-up will transmit a signal on the air for the other RFPs’ to synchronize
from. If a RFP gets in sync then it will transmit a signal on the air and will be
the sync source for the next RFP. Only RFPs’ which can receive a
synchronization signal will become synchronized.
For the RFP to sync to another RFP the signal strength cannot drop below
–70 dBm. You must consider this requirement during the site survey.
As long as an RFP is not in sync, no calls can be established using this RFP.
If a RFP loses the synchronization the RFP does not accept new calls (“busy
bit”). There is a delay of maximum 3 minutes until the active calls on this RFP
are finished. Then it tries to get synchronized again.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 16 (104)
An IP DECT installation is more reliable if a RFP can receive the signal from
more than only one RFP, because the other signals are also used for
synchronization.
The sync-over-air solution is very reliable, because all existing redundant
paths are used for synchronization. Thus, hardware tolerances have only
very little influence. No RFP has a key position.
Only unfavourable setups without redundant synchronization paths can
cause problems.
Sometimes RFPs’ do not need to be synchronized, e.g. if they are in different
buildings. These RFPs’ can be put into different clusters. RFPs’ in different
clusters will not be synchronized with each other. Different clusters start-up at
the same time independently.
2.6 RFP channel capacity
The RFP has 12 available air time slots:
•8 slots can have associated DSP resources for media streams.
•The remaining 4 slots are used for e.g. control signalling between RFPs’
and PPs’, and hand-in purposes.
If all 8 media stream channels are used the RFP announces a “busy bit”. In
that case the PPs’ determine whether another RFP has an appropriate signal
strength. If so, the PP will handover to that RFP. Once the handover has
been completed, the RFP will then lower its “busy bit”.
Whenever the busy state is announced a log entry is made to the system
logs. If the announcement of busy raises in a specific area, a further RFP
should be installed to double the number of media streams available for calls.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 17 (104)
2.7 About the Portable Parts
Portable Part (PP) is DECT standard terminology and in the context of the
DECToverIP using SIP solution is interchangeable with handset.
Aastra provides the following handsets:
- 142d
- 610d
- 620d
- 630d
142d 610d 620d 630d
Please be aware of differences in regulatory requirements between North
America and all other areas of the world. These differences lead to different
142d variants which use specific frequency bands and field strengths:
•Aastra DECT 142 (NA)
-Frequency Band 1920 to 1930 MHz
-60 duplex channels
-100 mW (maximum output per active channel)
-5 mW (average output per active channel)
•Aastra 142d (EMEA)
-Frequency Band 1880 to 1900 MHz
-120 duplex channels
-250 mW (maximum output per active channel)
-10 mW (average output per active channel)
The 610d / 620d / 630d supports both the NA and EMEA regulatory
requirements.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 18 (104)
In addition to the Aastra DECT 142 / Aastra 142d, standard 3rd party DECT
GAP phones may operate on the DECToverIP using SIP solution. But the
functionality may be limited by the characteristics of the 3rd party DECT
phone.
2.8 System capacities
There is only one active OpenMobility Manager (OMM) in the system. The
OMM capacities are:
•Up to 256 RFPs’ (Access Points) can be controlled.
•Up to 512 PPs’ (Handsets) are handled.
It is possible to deactivate the DECT part of a RFP. If the DECT interface is
deactivated then the resources (CPU and memory) are available for the
OMM only.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 19 (104)
3 Installation and configuration
To establish and maintain an IP DECT installation, a network infrastructure is
assumed, which comprises at least the following components:
•RFPs’
•PPs’
•IP PBX/media server (e.g. Asterisk)
•TFTP server
Depending on the operational modes the following services should be
provided:
•DHCP
•SNTP
•DNS
•LDAP
•Syslog daemon
Note: In NA outdoor RFP’s may only be installed with the antennas’ shipped
with the units. No other antennas’ or cabling are permitted. In EMEA the
outdoor RFPs’ are shipped without antennas and you may use the units with
one of the optional antennas’ (separate order no.).
3.1 OpenMobility start-up
3.1.1 Start-up of the RFPs’
For booting a RFP there must at least a TFTP server on the attached
network to load the OMM/RFP application software.
The essential network settings can be alternatively
•Communicated by a DHCP server at start-up time.
•Configured on the RFP with the tool OM Configurator. The settings made
by the OM Configurator will be saved permanently in the internal flash
memory of each OMM/RFP.
The RFP gets the boot image file from a TFTP server. The used TFTP server
needs to support Section 1.3 reference /1/. A used DHCP server needs to
support Section 1.3 reference /4/.
The TFTP and DHCP server need not to reside on the same host.
3.1.1.1 Booting overview
Booting is performed in two steps:
1. Starting the boot process.
2. Starting the application.
Booter
The RFP has only a little standalone application built into the flash. This
software realizes the so called net boot process.

Installation, Administration and Maintenance
Aastra depl-0900/0.4 Page: 20 (104)
On start-up each RFP tries to determine its own IP address and other
settings of the IP interface from the configuration settings in the internal flash
memory. If no settings are available or these settings are disabled, the RFP
tries to determine these settings via DHCP.
The RFP gets the application image file from the TFTP server.
Application
After starting the application image the RFP checks the local network settings
in its internal flash memory once again. If no settings are available or if they
are disabled it starts a DHCP client to determine the IP address of the OMM
and other start-up settings.
3.1.2 Start-up of the OpenMobility Manager
There is no difference in booting that RFP, which is chosen to be running in
OMM mode from those which are in the RFP only mode.
The decision is driven by the OMM IP address, which is read
•within the local network settings, if active.
•via DHCP request.
The RFP which has the same IP address as the dedicated OMM IP address,
will be the RFP which the OMM software runs on.
3.1.3 Booter
3.1.3.1 DHCP client
Within the initial boot process the DHCP client supports the following
parameters:
•IP address mandatory
•Net mask mandatory
•Gateway mandatory
•Boot file name mandatory
•TFTP server mandatory
•Public option 224: “OpenMobility” mandatory
3.1.3.1.1 DHCP request
3.1.3.1.1.1 Vendor class identifier (code 60)
The DHCP client sends the vendor class identifier “OpenMobility”.
3.1.3.1.1.2 Parameter request list (code 55)
The DHCP client in the booter requests the following options in the
parameter request list:
•Subnet mask option (code 1)
•Router option (code 3)
•Public option 224 (code 224)