Mitel Networks 69134000 Users manual
Product Document
Document ID:
pm-0504
All Rights
OpenMobility SIP Installation,
Administration and Maintenance
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 Winfinity.
Aastra DeTeWe Doc-ID: pm-0504 30.11.2006 Page: 1 (52)
Aastra
DeTeWe
Zeughofstr. 1
10997 Berlin, Germany
2006 -
Reserved
OpenMobility SIP Installation, Administration and Maintenance
History
Version Reason / Version Date Author
1 / 0 Initial release. 30.11.2006 H. Zander
1 / 2 Draft removed 30.11.2006 Tielmann
Additional Information:
Tool: Microsoft Office 2000 SP3
Print Date: 30.11.2006
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 2 (52)
OpenMobility SIP Installation, Administration and Maintenance
Table of contents
1 OVERVIEW ....................................................................................................................................................... 5
1.1 P
1.2 A
1.3 R
2 INTRODUCTION .............................................................................................................................................. 8
2.1 A
2.2 A
2.3 O
2.4 IP
2.5 RFP S
2.6 RFP
2.7 A
2.8 A
2.9 S
3 INSTALLATION AND CONFIGURATION ................................................................................................ 19
3.1 O
3.2 S
3.3 C
URPOSE
BBREVIATIONS AND DEFINITIONS
1.2.1 Abbreviations .............................................................................................................................. 5
1.2.2 Definitions................................................................................................................................... 5
EFERENCES
BOUT THE
BOUT THE
PENMOBILITY MANAGER
BOUT THE PORTABLE PARTS
BOUT LICENSING
YSTEM CAPACITIES
PENMOBILITY START UP
3.1.1 Start up of the RFPs .................................................................................................................. 19
3.1.2 Start up of the OpenMobility Manager ..................................................................................... 20
3.1.3 Booter........................................................................................................................................ 20
3.1.4 Application................................................................................................................................ 21
3.1.5 RFP LED status......................................................................................................................... 23
3.1.6 State graph of the start up phases .............................................................................................. 24
TATIC LOCAL CONFIGURATION OF THE
ONFIGURING THE OPENMOBILITY MANAGER
3.3.1 Service Login procedure ........................................................................................................... 26
3.3.2 Licensing................................................................................................................................... 28
3.3.3 System....................................................................................................................................... 29
3.3.4 RFP configuration ..................................................................................................................... 35
3.3.5 Configuration of Portable Parts................................................................................................. 37
.................................................................................................................................................... 5
............................................................................................................ 5
.............................................................................................................................................. 7
IP DECT
RFPS....................................................................................................................................... 9
SIGNALLING AND MEDIA STREAM
YNCHRONIZATION
CHANNEL CAPACITY
3.1.1.1 Booting overview....................................................................................................................19
3.1.3.1 DHCP client ............................................................................................................................20
3.1.3.1.1 DHCP request .........................................................................................................................20
3.1.3.1.2 DHCP offer.............................................................................................................................21
3.1.3.1.3 Retries.....................................................................................................................................21
3.1.3.2 TFTP client..............................................................................................................................21
3.1.4.1 Booter update ..........................................................................................................................22
3.1.4.1.1 Automatic booter update.........................................................................................................22
3.1.4.1.2 Automatic booter update for major release changes ...............................................................22
3.1.4.2 Selecting the right DHCP server .............................................................................................23
3.3.2.1 Definition of the License RFPs'...............................................................................................28
3.3.2.2 Get and add the licence key and PARK number......................................................................29
3.3.3.1 System settings........................................................................................................................29
3.3.3.1.1 Restarting the OMM ...............................................................................................................30
3.3.3.1.2 Encryption...............................................................................................................................31
3.3.3.1.3 Regulatory domain..................................................................................................................31
3.3.3.2 SIP...........................................................................................................................................31
3.3.3.3 User account............................................................................................................................33
3.3.3.4 Time zones ..............................................................................................................................33
3.3.3.5 Backup ....................................................................................................................................34
3.3.4.1 DECT configuration................................................................................................................36
3.3.4.2 States of a RFP........................................................................................................................36
3.3.4.3 OMM / RFP SW version check...............................................................................................36
WIRELESS SOLUTION
...................................................................................................................... 11
.......................................................................................................................... 14
......................................................................................................................... 15
................................................................................................................. 16
.................................................................................................................................... 16
................................................................................................................................. 18
........................................................................................................................ 19
................................................................................................ 8
........................................................................................................ 11
IP DECT B
ASE STATION
........................................................................................ 26
........................................................... 25
4 MAINTENANCE.............................................................................................................................................. 39
4.1 B
4.2 S
4.3 C
4.4 D
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 3 (52)
OOTER
................................................................................................................................................... 39
4.1.1 Checking the RFP booter version.............................................................................................. 39
4.1.2 Manual update of the RFP booter.............................................................................................. 39
ITE SURVEY MEASUREMENT EQUIPMENT
HECKING THE AASTRA PHONE
IAGNOSTIC
4.4.1 Aastra Phone 142 site survey mode........................................................................................... 40
............................................................................................................................................. 40
142
................................................................................................ 39
FIRMWARE VERSION
........................................................................ 40
OpenMobility SIP Installation, Administration and Maintenance
4.4.2 Aastra Phone 142 auto call test mode........................................................................................ 41
4.4.3 Aastra Phone 142 auto answer test mode.................................................................................. 41
4.4.4 Syslog........................................................................................................................................ 41
4.4.5 Telnet user shell ........................................................................................................................ 43
4.4.5.1 Login.......................................................................................................................................43
4.4.5.2 Command overview ................................................................................................................43
4.4.5.3 RFP console commands ..........................................................................................................44
4.4.5.4 OMM console commands .......................................................................................................44
4.4.6 DECT monitor of the OpenMobility system............................................................................. 45
5 APPENDIX ....................................................................................................................................................... 49
5.1 C
5.2 C
OMMUNICATIONS REGULATION INFORMATION FOR AASTRA PHONE
OMMUNICATIONS REGULATION INFORMATION FOR
RFP 32 US
OR
142 US ....................................... 49
RFP 34 US (NA) .......................... 50
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 4 (52)
OpenMobility SIP Installation, Administration and Maintenance
•
10 carrier frequencies (1,728 MHz spacing) with 12
1 Overview
1.1 Purpose
This document describes the service interfaces of the OpenMobility Manager.
In this version only the DECT relevant service issues are described.
1.2 Abbreviations and definitions
1.2.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
RTCP Real Time Control Protocol
RTP Real Time Protocol
TFTP Trivial File Transfer Protocol
1.2.2 Definitions
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 standardsbased 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 are:
•
Frequency range: approx. 1,880 – 1,900 GHz
(approximately 20 MHz bandwidth)
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 5 (52)
OpenMobility SIP Installation, Administration and Maintenance
whether a PP can access a particular DECT system. Used
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
•
Maximum transmission power of 10 mW
GAP Generic Access Profile
•
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 manufacturerspecific 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
for unique selection of the system at enrolment.
Roaming Roaming
While in motion, the PP performs ongoing measurements
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 6 (52)
OpenMobility SIP Installation, Administration and Maintenance
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 can be almost equally well
received, certain threshold values are in effect.
(similar to a Schmitt trigger circuit)
1.3 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
/18/ OpenMobility Diagnostic Tools
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 7 (52)
OpenMobility SIP Installation, Administration and Maintenance
2 Introduction
2.1 About the IP DECT wireless solution
The DECT over IP system comprises the following components:
• DECT Radio Fixed Parts (RFP) being distributed over an IP network and
offering DECT as a wireless interface.
• Media server / media gateway as telephony system platforms (e.g.
Asterisk).
• Portable Parts (PP): Aastra Phone 142.
• OpenMobility Manager (OMM): Management interface for IP DECT
wireless solution, which runs on one of the Radio Fixed Parts.
The following pictures give a graphical overview of the architecture of the IP
DECT wireless solution:
Media Server
Media Gateway
Radio Fixed Parts
255 max.
Web browser for
administration purposes
The media server, media gateway, OMM and the RFPs communicate
through the IP infrastructure. The RFPs and the Portable Parts communicate
over air, where the DECT GAP protocol is used or DECT GAP with
proprietary enhancements.
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 8 (52)
OpenMobility SIP Installation, Administration and Maintenance
2.2 About the RFPs
In general all RFPs have the same hardware and software capabilities.
But please mind the differences in regulatory domains which exist for North
America and all other areas of the world . These domains lead to different
RFP variants which use specific frequency bands and field strengths:
• RFP 32 IP or RFP 34 IP (EMEA)
- Frequency Band 1.880 to 1.900 Mhz
- 10 carrier frequencies
- Transmit Power 24 dBm
• RFP 32 US or RFP 34 US (NA)
- Frequency Band 1.920 to 1.930 Mhz
- 5 carrier frequencies
- Transmit Power 20 dBm
One of the RFPs within an IP DECT installation must be chosen to operate
not in the RFP mode, only, but also in the OpenMobility Manager (OMM)
mode. During installation you must set one of the RFPs to OMM mode. The
others are set to RFP only mode.
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 9 (52)
OpenMobility SIP Installation, Administration and Maintenance
standard IEEE 802.3af
LED orange (Application)
LED green (Application)
Unused
LED
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 4 time slots are used for e.g. control
signalling between RFPs and the PPs.
Groups of RFPs have to be built which are named clusters. Within a cluster
RFPs are synchronized to enable a seamless handover, when a user
crosses from one RFP’s zone of coverage to another. For synchronization it
is not necessary for an 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 4 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 3). 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).
Note: 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.
IP RFP32 /
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 10 (52)
LED red (Booter)
Ethernet jack
Power supply in line with Power over LAN™
Power jack (120 V/230 V AC adapter)
OpenMobility SIP Installation, Administration and Maintenance
SIP-Phone
Primary RFP
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.
The OpenMobility Manager (OMM) may run on one of the RFPs or on a
dedicated Linux server.
2.4 IP signalling and media stream
To establish a call between an IP Phone and a PP, 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 media gateway and then a
RTP/RTCP connection between the media gateway and the RFP.
The following figure illustrates this scenario.
Media Server
Media Gateway
OMM
(RFP in OMM mode)
Signalling
RFP Control Interface
RTP/RTCP
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.
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 11 (52)
OpenMobility SIP Installation, Administration and Maintenance
Media Server
Media Gateway
OMM
(RFP in OMM mode)
Signalling
RFP Control Interface
RTP/RTCP
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.
It is also be possible to direct the media stream to connect directly the IP
phone and the RFP, as shown in the following figures.
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 12 (52)
OpenMobility SIP Installation, Administration and Maintenance
SIP-Phone
Primary RFP
Secondary RFP
SIP-Phone
Primary RFP
New secondary RFP
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.
Media Server
Media Gateway
OMM
(RFP in OMM mode)
Signalling
RFP Control Interface
RTP/RTCP
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.
Media Server
Media Gateway
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 13 (52)
OMM
(RFP in OMM mode)
Signalling
RFP Control Interface
RTP/RTCP
OpenMobility SIP Installation, Administration and Maintenance
which does not receive a
which receives a signal
tries to get synchronized
which receives and
transmits a signal on the
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. During start up one RFP
will be the first, which transmits a signal on the air. The other RFPs only
receive the signal until their are synchronous. If a RFP gets in sync then it will
transmit a signal on the air and will be the sync source for the next RFPs.
Only RFPs which can receive each other will be 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.
The first active RFP will be chosen by the ADMM.
Unsynchronized RFP,
R 101 R 102 R 103 R 104 R 105
signal from another RFP
Unsynchronized RFP,
from another RFP and
Synchronized RFP,
air interface
R 111 R 110 R 109 R 108
R 107
R 106
As long as a 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.
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.
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 14 (52)
OpenMobility SIP Installation, Administration and Maintenance
Unreliable Installation
R 101 R 102 R 103 R 104 R 105
Don‘t
R 111 R 110 R 109 R 108
Reliable Installation
R 101 R 102 R 103 R 104 R 105
R 107
R 106
R 111 R 110 R 109 R 108
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 startup 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.
R 107
R 106
• The remaining 4 slots are used for e.g. control signalling between RFPs
and PPs.
If all 8 media stream channels are used IP DECT 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.
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 15 (52)
OpenMobility SIP Installation, Administration and Maintenance
2.7 About the Portable Parts
Please mind the differences in regulatory domains which exist for North
America and all other areas of the world . These domains lead to different PP
variants which use specific frequency bands and field strengths:
• Aastra Phone 142 (EMEA)
- Frequency Band 1.880 to 1.900 Mhz
- 120 duplex channels
- 10 mW (average output per active channel)
• Aastra Phone 142 US (NA)
- Frequency Band 1.920 to 1.930 Mhz
- 60 duplex channels
- 5 mW (average output per active channel)
In addition to the Aastra Phone 142 also standard 3rd party DECT GAP
phones function on the IP DECT solution. But the functionality may be limited
by the characteristics of the 3rd party DECT phone.
2.8 About licensing
The OMM needs to be enabled with a license key, which depends on the
MAC address of some RFPs in the DECT system. The license key needs to
be entered / administered via the OMM web interface.
There are a sets of licenses with additional upgrade licenses:
• License for 1 to 2 RFPs
• License for more than 2 RFPs
As mentioned above the license key depends on the MAC addresses of
some RFPs of the DECT system (License RFPs). Each RFP can be a
License RFP independent from where the RFP is located. The number of
RFP MAC addresses encoded in the license depends on the size of the
DECT installation.
System size
(# of RFPs)
Number of RFP MAC addresses
encoded in the license (License RFPs)
1 1
2 2 (1, if a second RFP has been added to a single RFP
system)
More than 2 3
Additional to the MAC addresses the PARK (Portable Access Rights Key),
which identifies the DECT installation, is also part of the license. Because a
DECT system can only be operated with a valid PARK, a DECT installation
without a license will be inactive on the DECT side.
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 16 (52)
Loading...