| submitted | available | document details (if available) | source link |
|---|---|---|---|
| various | users manual | Users Manual | 1.08 MiB |
Product Document OpenMobility SIP Installation, Administration and Maintenance Document ID: pm-0504 Aastra DeTeWe 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. Zeughofstr. 1 10997 Berlin, Germany 2006 - All Rights Reserved Aastra DeTeWe Doc-ID: pm-0504 30.11.2006 Page: 1 (52) History OpenMobility SIP Installation, Administration and Maintenance Version Reason / Version Date Author 1 / 0 1 / 2 Initial release. Draft removed 30.11.2006 H. Zander 30.11.2006 Tielmann Additional Information:
Tool:
Print Date:
Microsoft Office 2000 SP3 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 PURPOSE .................................................................................................................................................... 5 1.2 ABBREVIATIONS AND DEFINITIONS ............................................................................................................ 5 1.2.1 Abbreviations .............................................................................................................................. 5 1.2.2 Definitions................................................................................................................................... 5 1.3 REFERENCES .............................................................................................................................................. 7 2 3 INTRODUCTION .............................................................................................................................................. 8 2.1 ABOUT THE IP DECT WIRELESS SOLUTION................................................................................................ 8 2.2 ABOUT THE RFPS....................................................................................................................................... 9 2.3 OPENMOBILITY MANAGER ...................................................................................................................... 11 2.4 IP SIGNALLING AND MEDIA STREAM ........................................................................................................ 11 2.5 RFP SYNCHRONIZATION .......................................................................................................................... 14 2.6 RFP CHANNEL CAPACITY......................................................................................................................... 15 2.7 ABOUT THE PORTABLE PARTS ................................................................................................................. 16 2.8 ABOUT LICENSING.................................................................................................................................... 16 2.9 SYSTEM CAPACITIES................................................................................................................................. 18 3.1.1 INSTALLATION AND CONFIGURATION ................................................................................................ 19 3.1 OPENMOBILITY START UP ........................................................................................................................ 19 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 .............................................................................................................................21 3.1.3.1.3 Retries .....................................................................................................................................21 TFTP client..............................................................................................................................21 3.1.3.2 3.1.4 Application ................................................................................................................................ 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 Selecting the right DHCP server .............................................................................................23 3.1.4.2 3.1.5 RFP LED status......................................................................................................................... 23 3.1.6 State graph of the start up phases .............................................................................................. 24 3.2 STATIC LOCAL CONFIGURATION OF THE IP DECT BASE STATION ........................................................... 25 3.3 CONFIGURING THE OPENMOBILITY MANAGER ........................................................................................ 26 Service Login procedure ........................................................................................................... 26 Licensing ................................................................................................................................... 28 Definition of the License RFPs'...............................................................................................28 3.3.2.1 3.3.2.2 Get and add the licence key and PARK number......................................................................29 System ....................................................................................................................................... 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 SIP...........................................................................................................................................31 3.3.3.2 User account............................................................................................................................33 3.3.3.3 Time zones ..............................................................................................................................33 3.3.3.4 3.3.3.5 Backup ....................................................................................................................................34 3.3.4 RFP configuration ..................................................................................................................... 35 DECT configuration ................................................................................................................36 States of a RFP ........................................................................................................................36 OMM / RFP SW version check...............................................................................................36 3.3.5 Configuration of Portable Parts ................................................................................................. 37 3.3.4.1 3.3.4.2 3.3.4.3 3.3.1 3.3.2 3.3.3 4 MAINTENANCE.............................................................................................................................................. 39 4.1 BOOTER ................................................................................................................................................... 39 4.1.1 Checking the RFP booter version.............................................................................................. 39 4.1.2 Manual update of the RFP booter.............................................................................................. 39 4.2 SITE SURVEY MEASUREMENT EQUIPMENT ................................................................................................ 39 4.3 CHECKING THE AASTRA PHONE 142 FIRMWARE VERSION........................................................................ 40 4.4 DIAGNOSTIC............................................................................................................................................. 40 4.4.1 Aastra Phone 142 site survey mode........................................................................................... 40 Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 3 (52) 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 Syslog........................................................................................................................................ 41 4.4.4 4.4.5 Telnet user shell ........................................................................................................................ 43 Login .......................................................................................................................................43 4.4.5.1 Command overview ................................................................................................................43 4.4.5.2 RFP console commands ..........................................................................................................44 4.4.5.3 4.4.5.4 OMM console commands .......................................................................................................44 4.4.6 DECT monitor of the OpenMobility system ............................................................................. 45 5 APPENDIX ....................................................................................................................................................... 49 5.1 COMMUNICATIONS REGULATION INFORMATION FOR AASTRA PHONE 142 US ....................................... 49 5.2 COMMUNICATIONS REGULATION INFORMATION FOR RFP 32 US OR RFP 34 US (NA) .......................... 50 Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 4 (52) 1 Overview 1.1 Purpose OpenMobility SIP Installation, Administration and Maintenance 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 ADPCM DECT DHCP DSP FCC GAP IPEI HTTP OMM PARK PP SNMP TFTP RFP RTCP RTP TFTP Authentication Code Adaptive Differential Pulse Code Modulation Digital Enhanced Cordless Telecommunication Dynamic Host Configuration Protocol Digital Signal Processor Federal Communications Commission Generic Access Profile International Portable Equipment Identity Hyper Text Transfer Protocol OpenMobility Manager Portable Access Rights Key Portable Part (DECT handset) Simple Network Management Protocol Trivial File Transfer Protocol Radio Fixed Part Real Time Control Protocol Real Time Protocol Trivial File Transfer Protocol 1.2.2 Definitions Asterisk Asterisk DECT 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. 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) 10 carrier frequencies (1,728 MHz spacing) with 12 Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 5 (52) OpenMobility SIP Installation, Administration and Maintenance 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 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 IPEI 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). 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 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) 1.3 References 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/ 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) 2 Introduction OpenMobility SIP Installation, Administration and Maintenance 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 Web browser for administration purposes Radio Fixed Parts 255 max. 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 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 RFPs 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 /
IP RFP32 US Unused LED LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over LAN standard IEEE 802.3af Power jack (120 V/230 V AC adapter) Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 10 (52) OpenMobility SIP Installation, Administration and Maintenance 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. SIP-Phone Media Server Media Gateway Primary RFP 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 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. SIP-Phone Media Server Media Gateway Secondary RFP Primary RFP 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. SIP-Phone Media Server Media Gateway New secondary RFP Primary RFP OMM
(RFP in OMM mode) Signalling RFP Control Interface RTP/RTCP Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 13 (52) OpenMobility SIP Installation, Administration and Maintenance 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, which does not receive a signal from another RFP R 101 Unsynchronized RFP, which receives a signal from another RFP and tries to get synchronized R 111 R 110 Synchronized RFP, which receives and transmits a signal on the air interface R 102 R 103 R 104 R 105 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 R 111 R 110 R 109 R 108 R 107 R 106 Dont Reliable Installation R 101 R 102 R 103 R 104 R 105 R 111 R 110 R 109 R 108 R 107 R 106 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. 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 2 1 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) OpenMobility SIP Installation, Administration and Maintenance An IP DECT system is operational, if it is set up with a license and the RFPs, which are encoded in the license are part of the system so that the OMM can communicate with these License RFPs. Depending on the size of the IP DECT system, it will still work if some License RFPs are out of service. System size
(# of RFPs) Number of License-
RFPs Number of License RFPs available at minimum 1 2 More than 2 1 2 3 1 1 2 If the minimum number of License RFPs cannot be reached by the OMM or more RFPs are administered than licensed the DECT system will block the voice streams. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 17 (52) OpenMobility SIP Installation, Administration and Maintenance 2.9 System capacities There is only one OpenMobility Manager (OMM) in the system. The OMM capacities are:
Up to 256 RFPs can be controlled. Up to 512 PPs 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. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 18 (52) 3 OpenMobility SIP Installation, Administration and Maintenance 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 media server (e.g. Asterisk) The following services should be provided:
TFTP DHCP Syslog daemon 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 application software. The essential network settings can be alternatively given by a DHCP server at startup 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. The RFP gets the boot image file from a TFTP server. The used TFTP server needs to support /1/. A used DHCP server needs to support /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. On startup each IP DECT Base Station 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 IP DECT Base Station 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 IP DECT Base Station checks the local network settings in its internal flash memory once again. If no settings Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 19 (52) OpenMobility SIP Installation, Administration and Maintenance are available or if they are disabled it starts a DHCP client to determine the IP address of the ADMM and other startup 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 IP DECT Base Station which has the same IP address as the dedicated OMM IP address, is running as the OMM. 3.1.3 Booter 3.1.3.1 DHCP client IP address Within the initial boot process the DHCP client supports the following parameters:
Netmask Gateway Boot file name TFTP server Public option 224: OpenMobility mandatory mandatory mandatory mandatory mandatory 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) Public option 225 (code 225) Public option 226 (code 226) Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 20 (52) OpenMobility SIP Installation, Administration and Maintenance 3.1.3.1.2 DHCP offer The DHCP client selects the DHCP server according to the following rules:
the public options (code 224) has a value equal to the string OpenMobility. or the file field in the DHCP message has a sub string equal to ip_rfp.cnt. If none of the two rules above match the DHCP offer is ignored. Information retrieved from the DHCP offer:
The IP address to use is taken from the yiaddr field in the DHCP message. The IP netmask is taken from the subnet mask option (code 1). The default gateway is taken from the router option (code 3). The TFTP server IP address is taken from the siaddr filed in the DHCP message. The boot image filename is taken from the file field in the DHCP message, if this field is empty the default filename iprfp.bin is used. 3.1.3.1.3 Retries If the DHCP client does not get an appropriate DHCP offer a new DHCP request is send after 1 second. After 3 DHCP requests are sent the DHCP client will sleep for 60 seconds. During this time the booter will accept a local configuration with the OpenMobility Configurator (OMC). 3.1.3.2 TFTP client The TFTP client will download the application image from the TFTP server. Both TFTP server and the name of the application image are supplied via the DHCP client. The application image is checksum protected. 3.1.4 Application After successfully downloading and starting the application the RFP will determine the IP address of the OMM from DHCP. The DHCP client is capable of receiving broadcast and unicast DHCP replies. Therefore the flags field is 0x0000. The DHCP request contains the well-known magic cookie (0x63825363) and the end option (0xFF). The following parameters will be supported within this step:
Option / Field Meaning Mandatory yiaddr siaddr file IP-Address of the IP-RFP IP-Address of the TFTP server Path and name of the application image yes yes yes Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 21 (52) OpenMobility SIP Installation, Administration and Maintenance code 1 code 3 code 6 code 15 code 42 code 43 Subnet mask Default Gateway Domain Name Server Domain Name IP-Address of a NTP server Vendor Specific Options public option 224 Must set to "OpenMobility". The Vendor Specific Options consist of:
yes yes no no no yes yes Vendor Specific Option Meaning Mandatory option 10 option 14 option 15 option 17 option 18 ommip: Used to select the IP-RFP who should reside the Open Mobility Manager (OMM) syslogip: IP-Address of a Syslog Daemon syslogport: Port of a Syslog Daemon country: Used to select the country in which the OMM reside. This enables country specific tones
(busy tone, dial tone, ...) ntpservname: Name of a NTP Server yes no no no no Tones for the following countries are supported:
country code country 1 2 3 4 6 7 8 9 10 14 16 25 100 101 Germany Great Britain Suisse Spain Italy Russia Belgium Netherlands Czechia Finland Poland Taiwan USA France 3.1.4.1 Booter update 3.1.4.1.1 Automatic booter update Each application SW comes with the latest released booter SW. The application SW will update the booter automatically as long as the major release number of the booter SW has not changed, e.g booter SW 2.1.2 will not be automatically updated by the booter SW 3.x.y, but the booter SW 3.0.0 will be automatically updated by the booter SW 3.1.0. Details on how to check the booter SW version, see 4.1. Details on how to update the booter manually, see 4.1.2. 3.1.4.1.2 Automatic booter update for major release changes Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 22 (52) OpenMobility SIP Installation, Administration and Maintenance The update of booters with a major release number change will be performed automatically when the DHCP client in the application receives an DHCP offer with the public option 254 with a value UPDATE. 3.1.4.2 Selecting the right DHCP server The DHCP client requests its own IP address using code 50. The DHCP client will select the DHCP server that offers the currently used IP address. Additionally the mandatory options must be offered otherwise the DHCP offer is ignored by the DHCP client. If no matching reply was received the DHCP client resends the request for 2 times after 1 second. Then the DHCP client will wait for 1 minute before resending 3 requests again. If the DHCP client cannot accept an DHCP offer within 3 minutes the RFP is rebooted. 3.1.5 RFP LED status The following diagram shows the LED status of a RFP according to the different states during start up. The RFP32 IP has three separate LEDs for red, orange and green to show the different states during start up. IP RFP32 /
IP RFP32 US Unused LED LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over LAN standard IEEE 802.3af Power jack (120 V/230 V AC adapter) State LED state Remarks Booter (Start up) Red on Waiting for link up Booter DHCP Red flashing 0.5 Hz Booter (TFTP) Red flashing 2.5 Hz Application (DHCP) Orange on Application (init) Green flashing 0.5 Hz Application (init) Green flashing 1 Hz Launching a DHCP request and waiting for an DHCP offer Downloading the application image Launching DHCP request and waiting for DHCP reply RFP is initializing its internal components RFP tries to connect to the OMM Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 23 (52) OpenMobility SIP Installation, Administration and Maintenance State LED state Remarks Application (init) Green flashing (2 sec on, 0.5 sec off) The DECT part of the RFP does not work (either not configured or not synchronized with other RFPs) Application (init) Green RFP is up and running 3.1.6 State graph of the start up phases LED RED ON Start-up wait for link up BOOTER LED red flashing 0,5 Hz DHCP wait for reply DHCP no answer / offer not o.k. LED red flashing 0,25 Hz retry Wait for 60 seconds LED red flashing 2,5 Hz TFTP File download TFTP failed Kernel DHCP no answer; offer not o.k.
(try 3 minutes) Init failed Connection attempt to OMM failed Failure, i.e. connection to OMM lost Failure, i.e. connection to OMM lost LED orange DHCP wait for reply LED green flashing (0,5 Hz) Application Init LED green flashing 1 Hz Application Connect to OMM LED green flashing 2 seconds on / 50ms off LED green Application Synchronize DECT Application Up & running Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 24 (52) OpenMobility SIP Installation, Administration and Maintenance 3.2 Static local configuration of the IP DECT Base Station For a static local configuration you must use the java configuration tool OpenMobility Configurator (requires Java Runtime Environment version 1.4 or higher). The settings, which are configured on the IP DECT Base Station with the tool OM Configurator, will be saved permanently in the internal flash memory of an IP DECT Base Station. The parameters configurable via the OM Configurator comply with the DHCP option, please see section 3.1 for details. If a local static configuration has been done, DHCP is not used anymore. The following figure shows the OM Configurator. To configure an IP DECT Base Station, at least the MAC address and all mandatory options (see table below) have to be set. If the IP DECT Base Station has an IP address enter this address in the IP address field. In this case you can reach the IP DECT Base Station from outside the local LAN segment. To set additional parameters, press the Add parameter button and choose the desired parameter. Press the Send configuration button to transmit the parameters to an IP DECT Base Station. The configuration can only be set after powering up or at the retry phase
(LED flashing 0,25 Hz) or in kernel mode, please see section 3.1.6 for details. The configurator tool waits 2 seconds and retries transmitting the data 3 times. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 25 (52) OpenMobility SIP Installation, Administration and Maintenance If you want to read the configuration parameters from an IP DECT Base Station set the MAC address and the IP address additionally and press the List configuration button. All parameters will be listed in the OM Configurator tool. Press the Reset configuration" button to clean all input fields and additional parameters. 3.3 Configuring the OpenMobility Manager The OMM can be configured via HTTP. The OMM acts as a HTTP server which binds to port 80 by default. If executed in host mode the port can be configured via the command line interface. The configuration data will be either read from the internal flash memory or from a local file. A local file is only used if specified on the command line on a PC host. The configuration file is a human readable ASCII file. Changing the configuration file outside the OMM is not permitted. The configuration file can be downloaded and uploaded via the web interface. The service access is restricted to one active session at a time and is password protected. The browser used for service access has to be at least Microsoft Internet Explorer 6.0 or Mozilla Firefox 1.0 and must have frame support, JavaScript and cookies enabled. 3.3.1 Service Login procedure The OMM allows only one user at a time to configure the system. A user must authenticate with an user name and a password. Both strings are checked case sensitive. Default login and password is omm. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 26 (52) OpenMobility SIP Installation, Administration and Maintenance After login there are the following options available:
Configuration of general IP DECT system parameters.
Administration of the attached RFPs.
Administration of the PPs.
Administration of the licence options. If no user action takes place the OMM logs out the user after 5 minutes. To logout from the system click at Logout. Note: If the browser is closed without logging out first the service access will be blocked for other clients for 5 minutes. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 27 (52) OpenMobility SIP Installation, Administration and Maintenance 3.3.2 Licensing Within the initial configuration of the IP DECT system, the license is missing and a warning occurs. 3.3.2.1 Definition of the License RFPs'
The License RFPs' have to be defined in that manner as described in chapter 2.8. Press the New button and add the MAC addresses of the License RFPs':
If that has been done please wait for the green tick(s) as shown in the next image. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 28 (52) OpenMobility SIP Installation, Administration and Maintenance 3.3.2.2 Get and add the licence key and PARK number The second step is to go to the Aastra - DeTeWe License web site and enter the serial number generated by the first step along with a TAN from your documentation. This will generate a license key that has to be entered in the 3rd step. If the license is valid, the warning Missing License disappears and the OMM restarts. 3.3.3 System 3.3.3.1 System settings The system settings cover global settings for the OpenMobility Manager like the system name or a system wide authentication code. The authentication code is used during initial PP subscription as a security option (see chapter 3.3.5). Encryption and regulatory domain are described in the chapters 3.3.3.1.2 and 3.3.3.1.3. For monitoring the DECT system behaviour of the OpenMobility Manager a separate application will be delivered. This tool needs an access to the OpenMobility Manager which is disabled by default and can be enabled on the system page. To allow the prioritisation of Voice Packets and/or Signalling Packets (SIP) inside the used network the IP parameter ToS (Type of Service) could be configured here. The OpenMobility Manager and the RFPs are capable of propagating syslog messages conforming to /8/. This feature together with the IP address of a host collecting these messages can be configured. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 29 (52) OpenMobility SIP Installation, Administration and Maintenance If SNTP is not used, date and time can be configured at the OMM. This has to be done to provide date and time to the Aastra Phone 142. The time zone, which is shown on this web page, has been configured at the IP region section of the web service. Please note, that in the case that SNTP is not used, the date and time has to be configured after every restart of the IP DECT Base Station, where the OpenMobility Manager is running. The date and time will be provided by the OpenMobility Manager to the Aastra Phone 142 if the Aastra Phone 142 initiates a DECT location registration. This will be done in the following cases:
Subscribing at the OMM Entering the network again after the DECT signal was lost Power on Silent charging feature is active at the phone and the phone is taken out of the charger After a specific time to update date and time 3.3.3.1.1 Restarting the OMM To restart the OMM select System Settings from the navigation tree and then select Restart. There is also the option to reset the configuration data. A reset web page is loaded then displaying a progress bar and the login web page is loaded automatically if the OMM is reachable again. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 30 (52) OpenMobility SIP Installation, Administration and Maintenance 3.3.3.1.2 Encryption Encryption is only available if RFP32/34 IP (not RFP 31/33 IP) are used. Therefore it can only be enabled on the System Settings web page if no RFP31/33 IP has been connected to the OMM. If encryption is enabled and an RFP31/33 IP connects to the OMM, its DECT air interface will not be activated. The user always has the possibility to disable encryption. In this case all connected RFP31/33 IP are restarted. Note: The PPs have to support DECT encryption which is not a mandatory feature. 3.3.3.1.3 Regulatory domain To define where the IP DECT is used the parameter regulatory domain has to be configured. Existing installations are updated to the default value EMEA (ETSI). To setup an FCC compliant installation the value has to be set to US (FCC/CI). ETSI compliant RFPs are inactive and can not be activated if the regulatory domain is set to US (FCC/CI) and vice versa. 3.3.3.2 SIP The SIP settings cover all global settings matching the SIP signalling and the RTP voice streams. Proxy Server IP address or name of the SIP proxy server. Proxy Port SIP proxy servers port number. Default is 5060. Registrar Server IP address or name of the SIP registrar. Enables the PPs to be registered with a Registrar. Registrar Port SIP Registrars port number. Default is 5060. Registration Period The requested registration period, in seconds from the registrar. Outbound Proxy Address of the outbound proxy server. All SIP messages originating from the OMM are sent to this server. For example, if you have a Session Border Controller in your network, then you would normally set its address here. Outbound Proxy Port The proxy port on the proxy server to which the OMM sends all SIP messages. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 31 (52) OpenMobility SIP Installation, Administration and Maintenance Explicit MWI Subscription Some Media Server such as the Asterisk support Message Waiting Indication (MWI) based on /15/. A MWI icon will be presented on a Aastra Phone 142 if the user has received a voice message on his voice box which is supported by the Media Server. If Explicit MWI Subscription is enabled the OMM sends explicit for each PP a MWI Subscription message to the Proxy or Outbound Proxy Server. RTP Port Base Each RFP needs a continuous port area of 68 UDP ports for RTP voice streaming. The RTP Port Base is the start port number of that area. Default is 16320. Preferred Codec 1 5 Specifies a customized codec preference list which allows you to use the preferred Codecs. The Codec 1 has the highest and Codec 5 the lowest priority. Silence Suppression Allows to configure whether Silence Suppression is preferred or not. DTMF Out-of-Band The OMM supports DTMF based on /9/. DTMF Payload Type If Out-of-Band is enabled the Payload Type specify the payload type which is used for sending DTMF events based on /9/. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 32 (52) OpenMobility SIP Installation, Administration and Maintenance 3.3.3.3 User account After initial installation or after removing the configuration file the OpenMobility service is accessible via a build-in user account with user omm and password omm. These settings which are case sensitive can be changed on the User Account web page. 3.3.3.4 Time zones A time and date resynchronization of the Aastra Phone 142 devices is described in chapter 3.3.3.1. In the time zone section the OpenMobility Manager provides all available time zones. They are set with their known daylight savings time rules adjusted to the Universal Coordinated Time (UTC) per default. The difference to the UTC time is shown in the UTC Difference column. In case of a configured daylight savings time rule this is also marked for each time zone. There is a possibility to change the time zone rules for maximal five time zones. Changed rules are marked with a bold time zone name in the table. The changes are saved in the configuration file and are restored after each OpenMobility Manager startup. The Default button sets all time zones back to the default values and deletes the changed time zone rules in the configuration file. With the Configure Time Zone dialog the standard time and the daylight savings time (DST) of a time zone can be changed. If the time zone has no DST only the UTC difference can be configured. For the DST both points of time (begin of standard time and begin of daylight savings time) have to be specified exactly. Therefore a certain day in the month or a certain week day in a month can be used. See the following screen shots as an example:
Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 33 (52) OpenMobility SIP Installation, Administration and Maintenance 3.3.3.5 Backup The web service interface allows to save a copy of the current configuration on the local host (host where the browser application is executed) as well as to restore an older configuration. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 34 (52) OpenMobility SIP Installation, Administration and Maintenance Restoring a previously saved configuration will lead to a reset of the OMM to take effect. 3.3.4 RFP configuration All configured RFPs are listed in tables grouped to clusters by its topographic relations. The RFPs are sorted by their Ethernet addresses. To ensure correct handover of a PP during a call, all involved RFPs must deliver the same clock signal to the PP. This is achieved by placing the RFPs so close to each other, that every RFP recognizes at least one other RFP through its radio interface. There are conditions where this is not possible, for instance with RFPs at remote locations. In this case the RFPs shall be grouped to different clusters. The OpenMobility Manager will not try to synchronize RFPs over cluster borders. All used clusters are displayed in the navigation bar on the left side and the OMM RFP is marked with a bold font. When the RFPs are connecting the OMM they submit their HW type. This type is displayed on the RFP list web page. New RFPs can be added to the system by pressing the New button. A popup window appears providing the configuration of a new RFP. Each RFP is identified by its MAC address (6 bytes hex format, colon separated). The Ethernet address is unique and can be found on the back of the chassis. For easier administration each RFP can be associated with a location string. The location string can hold up to 20 characters. The same popup window could be opened for an existing RFP by pressing the tool icon of the appropriate RFP. An RFP could be deleted by pressing the trash can icon
. A similar popup window asks for confirmation showing the current configuration of this RFP. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 35 (52) OpenMobility SIP Installation, Administration and Maintenance 3.3.4.1 DECT configuration The DECT functionality for each RFP can be switched on/off. If DECT is active the RFP can be added to a cluster. 3.3.4.2 States of a RFP For each RFP the state of the DECT subsystem is displayed. The states are:
Synchronous The RFP is up and running. The RFP recognizes and is recognized by other RFPs in its cluster through its air interface and delivers a synchronous clock signal to the PPs. Asynchronous but active The RFP has not been able to synchronize to its neighbours yet. No DECT communication is possible. But nevertheless the RFP has already been able to connect to the OMM. This phase should usually last only for a few seconds after starting up the RFP or the OMM. If this state lasts longer this is an indication for a hardware or network failure. Searching The RFP has lost synchronization to its neighbours. No DECT communication is possible. This phase should usually last only for a few seconds after starting up the RFP or the OMM. If this state lasts longer or is re-entered after being in a synchronous state this is an indication for a bad location of the RFP. Inactive The RFP has connected to the OMM but the air interface has not been switched on yet. For any RFP with activated DECT functionality this phase should last only for a few seconds after starting up the RFP. If this state lasts longer this may indicate an hardware failure. Not connected The RFP was configured but has not connected to the OMM yet. Therefore the IP address column is empty. 3.3.4.3 OMM / RFP SW version check When the RFPs are connecting the OMM they submit their SW version. If this version differs from the OMM SW version the RFP connection attempt is rejected. This could happen when using several DHCP servers with different OpenMobility SW versions. In this case the RFP is marked with an error message. Moreover a global error message is displayed on the RFP list web page if at least one version mismatch has been found. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 36 (52) OpenMobility SIP Installation, Administration and Maintenance 3.3.5 Configuration of Portable Parts At the Portable Parts web page all configured DECT handsets are sorted by their number. To keep the list concise, the complete list is split up into sub lists containing up to 100 handsets. The user can move back and forth in steps of 100 handsets. Because the browser function can not be used to search for a certain handset in all sub lists, a search function is available, which allows to find a handset by a given number or IPEI. A new PP can be added to the system by pressing the New button. The following popup window appears allowing the configuration of a new PP. The name and authentication code fields are optional settings. The number represents the SIP user ID and the name represents the SIP display name. The DECT authentication code is used during initial DECT subscription as a security option and can be set here for each PP separately. If it is not configured the global authentication code on the System Settings web page is used (see chapter 3.3.3.1). The SIP Authentication User Name is optional. It represents the name which will be used during SIP authentications. If no name is given the number will be used instead. The password will be used during SIP authentications. A similar popup window appears when configuring an existing PP by pressing the tool icon checkbox. If this option is selected, the PP will be unsubscribed. The only difference is the delete subscription Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 37 (52) OpenMobility SIP Installation, Administration and Maintenance Note: The authentication code can only be changed if the PP is not subscribed. The PP name can be changed, but this will not take effect until the PP is subscribed again. Deleting of a PP can be done by pressing the trash can icon window appears and asks for confirmation. A popup After adding a PP to the OMM the PP must be subscribed. This is done by pressing the Subscribe button. The OMM will allow a subscription of configured but not subscribed PPs during the next hour. During the subscription process the system wide PARK and the authentication code either configured for the PP or system wide must be entered in the PP form fields. The PARK is displayed at the PP configuration page in the top right corner. If the user wants to find a certain handset then the search function can be used. A click on the Search button provides the following pop-up window. The user can enter the handsets number or IPEI. At least one parameter has to be set. The entered number or IPEI has to match exactly with a handsets number or IPEI. If number and IPEI are given then a handset has to exist in the OMMs database whose number and IPEI match both otherwise the search fails. If a handset with the specified number and/or IPEI was found then a list is displayed which has this handset as the first entry. The search function can also be used to get to the right sub list in one step. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 38 (52) 4 Maintenance 4.1 Booter OpenMobility SIP Installation, Administration and Maintenance The booter may be handled via the DHCP option 254 UPDATE (see chapter 3.1.4.1) automatically. In any case you may have direct control to the booter SW, if you use a telnet user session. A complete description of the usage of the user shell, you can find in /18/. 4.1.1 Checking the RFP booter version You can display the version information of the RFP booter using the telnet interface of an RFP. Check the booter version to determine whether an update is required to overcome any user issues or to enhance the functionality. 1. Start a telnet session using the IP address of the RFP. 2. Enter login iprfp and password ommsip/987. 3. Enter flash. The display will show the software and the hardware level of the RFP.
> flash version of initial booter : 2.0.12 Version of booter 1 : 3.2.2 Version of booter 2 : 3.2.2 Hardware Revision : 51 MAC address : 00:30:42:08:31:A4
4.1.2 Manual update of the RFP booter You can update the RFP booter manually if there is no opportunity to have an autonomic update. Please check the booter version to determine whether an update is required to overcome any user issues or to enhance the functionality. 1. Start a telnet session using the IP address of the RFP. 2. Enter login iprfp and password ommsip/987. 3. Enter flash_update. 4. Enter flash_update a second time because of the two booter images. 4.2 Site survey measurement equipment If an IP DECT installation has to be planned, a sufficient distribution of the RFPs is necessary, which fulfills the requirements for reliable synchronization and connectivity to the Portable Parts. The site survey kit may help you. It comprises:
Scaled layout diagram of the building/premises. One measuring RFP with its own power supply. A tripod and a battery for the RFP. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 39 (52) OpenMobility SIP Installation, Administration and Maintenance Two reference PPs with chargers. Battery chargers. A measuring handset, which can monitor other makers DECT radio sources. 4.3 Checking the Aastra Phone 142 firmware version You can display the version information of the Aastra Phone 142 with a few keystrokes. Check the firmware version to determine whether an update is required to overcome any user issues. 1. Press the Menu soft key 2. Select System (only to highlight) 3. Press OK. 4. Select Version Number 5. Press OK. The display will show the software and the hardware version of the Aastra Phone 142. 4.4 Diagnostic 4.4.1 Aastra Phone 142 site survey mode You can set the Aastra Phone 142 in site survey mode with a few keystrokes. In this mode the phone will display the RFPs and the actual field strength of the receiving signal in dBM. 1) Press the Menu soft key 2) Enter the following key sequence R***76#
3) Select Site Survey 4) Press OK. To leave the site survey mode switch the phone off and on again. The following display is shown on the Aastra Phone 142:
PARK: 1F-10-FF-F0-21 RFP ID: 02*
RFPI 10FFF21 02 Frame error FE PP: FP:
Field strength
-dBm 50 57 50 RFP ID RPN 02 01 00 RFP ID: 02*
*The ID of RFP to which the PP is currently associated to. Menu Phonebook In this example the PP is currently connected to the RFP with the number 02. The RFP 01 and 00 are also visible. The number 10FFF221 02 on the Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 40 (52) OpenMobility SIP Installation, Administration and Maintenance upper right side refers to the PARK 1F-10-F2-21 of the IP DECT system and to the RFP to which the phone is currently connected to. 4.4.2 Aastra Phone 142 auto call test mode You can set the Aastra Phone 142 to auto call test mode with a few keystrokes. In this mode the phone will call a specified number cyclically. You can use this feature to generate traffic for test purposes. This mode is also active if the phone is an the charger. 1) Press the Menu soft key 2) Enter the following key sequence R***76#
3) Select Auto Call Test 4) Press OK. 5) Enter the phone number to call. 6) Press OK. 7) Enter a number of seconds between two calls. 8) Press OK. 9) Enter a number of seconds a call shall be active. 10) Press OK. The test will be started automatically. To stop the test, switch the phone off and on again. 4.4.3 Aastra Phone 142 auto answer test mode You can set the Aastra Phone 142 to auto answer test mode with a few keystrokes. In this mode the phone will answer incoming calls automatically. You can use this feature together this phones in the auto call test mode for test purposes. This mode is also active if the phone is an the charger. 1) Press the Menu soft key 2) Enter the following key sequence R***76#
3) Select Auto Answer 4) Press OK. 5) Enter a number of seconds the phone shall ring before it will answer the call. 6) Press OK. 7) Enter a number of seconds a call shall be active. 8) Press OK. The test will be started automatically. To stop the test switch the phone off and on again. 4.4.4 Syslog The OpenMobility Manager and the RFPs are capable of propagating syslog messages conforming to /8/. This feature together with the IP address of a host collecting these messages can be configured. Syslog has to be enabled by Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 41 (52) OpenMobility SIP Installation, Administration and Maintenance DHCP using the public options 227 and 228. Setting the syslog daemon server and port via the web interface. To set up the syslog via DHCP or OM Configurator has the advantage, that syslogs are available in earlier states of the RFP start up. The level of syslog messages in the default state allows the user, to have control over the general system state and major failures. If it is wished to increase the level for diagnostic reasons, this can be done via the telnet user shell by increasing the spy level of each subsystem (see chapter 4.4.5). You can also read syslogs if you type the command logread within the telnet user shell. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 42 (52) OpenMobility SIP Installation, Administration and Maintenance 4.4.5 Telnet user shell Each RFP (OMM included) offers a lot of commands within the telnet shell. Most of them are useful for diagnostics and may help experts to resolve failures. Note: Some commands can harm the systems operation. 4.4.5.1 Login The procedure is:
Open a telnet session to the RFP. Enter user iprfp and password ommsip/987. Welcome to IP RFP OpenMobility SIP Version x.y.z Mon Nov 13 12:34:06 CEST 2006 Release
(BUILD 0) 172.30.106.41 login: iprfp Password:
Welcome to the system usershell!
172.030.206.41 > help 4.4.5.2 Command overview Type help to get a command overview:
arp console_off console_on dmesg flash flash_update interface ip_rfpconsole link logread mem ommconsole ps ping reboot route uptime exit
show arp table disable console on local terminal enable console on local terminal print the kernel ring buffer show flash info update the booter show interface configuration console to the rfp application show link state show message log show memory usage console to the omm application show process table ping <ipaddress>
restarts the system show routing table show system uptime exit shell Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 43 (52) OpenMobility SIP Installation, Administration and Maintenance 4.4.5.3 RFP console commands If you type ip_rfpconsole you are able to use the following commands on each RFP:
IP RFP console commands:
heap - shows heap buffer statistics help - Displays Command Help Table lec - adjust linear echo canceler parameters media - display state of media channels mutex - lists all created MXP mutexes queues - lists all created MXP queues reset - resets the IPRFP application rsx - allows RSX connection to BMC via TCP sem - lists all created MXP semaphores spy - set/display spy levels: [ <key #> <level #> ]
tasks - lists all running MXP tasks voice - displays the state of voice handling exit - leave the RFP console Note: The spy command enables you to increase the level of syslog messages. These should be used only by trained support personnel, because the spy command can harm the systems operation. 4.4.5.4 OMM console commands If you type ommconsole and you have opened the session on the OMM RFP you are able to use the following OMM related commands:
Note: The spy command enables you to increase the level of syslog messages especially for subsystems of the OMM. These should be used only by trained support personnel, because the spy command can harm the systems operation. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 44 (52) OpenMobility SIP Installation, Administration and Maintenance 4.4.6 DECT monitor of the OpenMobility system For a better error detection in the OpenMobility system the DECT monitor can be used. The DECT monitor is an MS Windows based standalone application. It provides the possibility to give a real time overview of the current RFP and PP states in the DECT OpenMobility system. The following features are provided by the DECT monitor:
Reading out of the DECT configuration of a OpenMobility system. Configuration can be stored in an ASCII file. Display of DECT transactions RFP-PP in clear tabular form, with highlighting of handover situations. Real-time display. Display of further events concerning the status or actions of RFPs and PPs of the OpenMobility system. All events can also be recorded in a log file. Display of the synchronization relations between the RFPs. Monitoring of systems with up to 255 RFPs and 1023 PPs. Reading out and display of RFP statistics data, either for a single RFP or for all RFPs. Display of DECT central data of the OpenMobility system. The DECT Monitor application can only be used if the DECT Monitor flag in the OMM web service on the system settings configuration page is enabled. The DECT monitor application is used together with the OpenMobility system. When the application is started, the user is requested to enter the IP address of the RFP or server running the OpenMobility Manager (OMM) software. This address is different from the IP address of the PABX the OMM is connected to!
There can be several reasons for an unsuccessful link establishment:
Operation of DECT Monitor is not enabled inside the OMM. Use the web service to enable the DECT Monitor operation. IP address is not correct. It has to be the address of the RFP or server the OMM is running on, not the address of the PABX!
A link routed through the PABX is not supported. In case of a remote service on a PABX via dial-in the OMM can not be accessed from the DECT Monitor. The application displays the IP address which has been used last time. When the application is started a link to the OpenMobility system is automatically established and the application window shows all user configured child windows and tables. When all links have been established, the DECT data of the system is automatically read out and entered in the tables RFP-Table and PP-Table. This procedure is called Config Request. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 45 (52) OpenMobility SIP Installation, Administration and Maintenance Next, the defined trace options (event mask) are sent to the OMM. The options which are sent to the OMM are always those which were active the last time the application was exited. If the trace option Transaction establish/release is activated, the OMM will deliver all existing transactions. Following this, the OMM system delivers the desired trace data. The user can either communicate with the application interactively (see below) or he can simply activate a log file in which to record the data. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 46 (52) OpenMobility SIP Installation, Administration and Maintenance Following this initialization, the user can carry out the following modifications:
The trace settings can be modified using the menu item Options-Event Mask. Transmissions to the OMM take place after confirming the settings with OK. A Config Request can be sent again to the OMM. A log file can be activated. By means of various dialogues, the configuration data of the PPs, RFPs and control modules can be displayed and stored in ASCII files. The following information is displayed in the tables dynamically:
Transactions between PP and PABX system. These are displayed in both tables. Simple transactions are displayed in black on a white background;
during handover, both transactions involved are displayed in white on a red background. The location registration and detach events are displayed in the tables for approximately 1 2 sec after their occurrence (light green background), if possible. There is no display in the RFP table if there is no column free for display. If the event has already been displayed, it can be overwritten at any time. The events are not displayed if they occur during an on-going transaction. Irrelevant of whether the events are displayed in the tables, they are always entered in the FP/PP-Events' window and in the log file
(provided that this is open). The following colour scheme is used for the RFP table display:
RFP grey-blue RFP is not active (not connected or disturbance) RFP black RFP is active The data of a RFP are displayed in a dialogue box after clicking on the respective RFP field in the RFP table. The statistics data of the RFP can be called up from this dialogue box. The following colour scheme is used for the PP table display:
PP black:
PP blue:
PP is enrolled. It is assumed that the PP can be reached. PP can presumably not be reached. Detach was received or when an attempt was made to reach a PP, the PP did not answer. PP grey/blue:
PP not enrolled. The PP data is displayed in a dialogue box after clicking on the corresponding PP field in the RFP table. The Sync Info child window contains all RFPs and shows their synchronization and relation states to each other. Selecting the RFPs with the right mouse button the user can change visibility views and can even force a resynchronization of a RFP. There are several optional sub windows selectable. They are all listed below and give some more information about the OpenMobility systems. Mostly they are statistics and for internal use only. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 47 (52) OpenMobility SIP Installation, Administration and Maintenance Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 48 (52) 5 5.1 OpenMobility SIP Installation, Administration and Maintenance Appendix Communications Regulation Information for Aastra Phone 142 US FCC Notices (U.S. Only) This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. Modifications not expressly approved by this company could void the user's authority to operate the equipment. NOTE: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:
. Reorient or relocate the receiving antenna. Increase the separation between the equipment and receiver. Connect the equipment into an outlet on a circuit different from that to which the receiver is connected. Consult the dealer or an experienced radio/TV technician for help. Health and Safety Information Exposure to Radio Frequency (RF) Signals:
The wireless phone is a radio transmitter and receiver. It is designed and manufactured not to exceed the emission limits for exposure to radio frequency (RF) energy set by the Federal Communications Commission
(FCC) of the U.S. Government. These limits are part of comprehensive guidelines and establish permitted levels of RF energy for the general population. The guidelines are based on the safety standards previously set by both U.S. and international standards bodies. These standards include a substantial safety margin designed to assure the safety of all persons, regardless of age and health. This device and its antenna must not be co-located or operating in conjunction with any other antenna or transmitter. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 49 (52) 5.2 OpenMobility SIP Installation, Administration and Maintenance This EUT has been shown to be capable of compliance for localized specific absorption rate (SAR) for uncontrolled environment/general population exposure limits specified in ANSI/IEEE Std. C95.1-1992 and had been tested in accordance with the measurement procedures specified in FCC/OET Bulletin 65 Supplement C (2001) and IEEE 1528-2003. Industry Canada (Canada only) Operation of this device is subject to the following two conditions: (1) this device may not cause interference, and (2) this device must accept any interference, including interference that may cause undesired operation of the device. Privacy of communications may not be ensured when using this telephone. Exposure to Radio Frequency (RF) Signals:
The wireless phone is a radio transmitter and receiver. It is designed and manufactured not to exceed the emission limit for exposure to radio frequency (RF) energy set by the Ministry of Health (Canada), Safety Code 6. These limits are part of comprehensive guidelines and established permitted levels of RF energy for the general population. These guidelines are based on the safety standards previously set by international standard bodies. These standards include a substantial safety margin designed to assure the safety of all persons, regardless of age and health. This device and its antenna must not be co-located or operating in conjunction with any other antenna or transmitter. This device has been shown to be capable of compliance for localized specific absorption rate (SAR) for uncontrolled environment / general public exposure limits specific in ANSI/IEEE C95.1-1992 and had been tested in accordance with the measurement procedures specified in IEEE 1528-2003. Communications Regulation Information for RFP 32 US or RFP 34 US (NA) FCC Notices (U.S. Only) This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. Modifications not expressly approved by this company could void the user's authority to operate the equipment. NOTE: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 50 (52) OpenMobility SIP Installation, Administration and Maintenance limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:
. Reorient or relocate the receiving antenna. Increase the separation between the equipment and receiver. Connect the equipment into an outlet on a circuit different from that to which the receiver is connected. Consult the dealer or an experienced radio/TV technician for help. Exposure to Radio Frequency (RF) Signals:
The wireless phone is a radio transmitter and receiver. It is designed and manufactured not to exceed the emission limits for exposure to radio frequency (RF) energy set by the Federal Communications Commission
(FCC) of the U.S. Government. These limits are part of comprehensive guidelines and establish permitted levels of RF energy for the general population. The guidelines are based on the safety standards previously set by both U.S. and international standards bodies. These standards include a substantial safety margin designed to assure the safety of all persons, regardless of age and health. This device and its antenna must not be co-located or operating in conjunction with any other antenna or transmitter. The radiating element of the base station should be installed during operating at a separation distance greater than 20 cm between user and device. The device comply with the requirements for routine evaluation limits Industry Canada (Canada only) Operation of this device is subject to the following two conditions: (1) this device may not cause interference, and (2) this device must accept any interference, including interference that may cause undesired operation of the device. Privacy of communications may not be ensured when using this telephone. Exposure to Radio Frequency (RF) Signals:
The wireless phone is a radio transmitter and receiver. It is designed and manfactured not to exceed the emission limit for exposure to radio frequency
(RF) energy set by the Ministry of Health (Canada), Safety Code 6. These limits are part of comprehensive guidelines and established permitted levels of RF energy for the general population. These guidelines are based on the Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 51 (52) OpenMobility SIP Installation, Administration and Maintenance safety standards previously set by international standard bodies. These standards include a substantial safety margin designed to assure the safety of all persons, regardless of age and health. This device and its antenna must not be co-located or operating in conjunction with any other antenna or transmitter. The radiating element of the base station should be installed during operating at a separation distance greater than 20 cm between user and device. The device comply with the requirements for routine evaluation limits. Aastra DeTeWe Doc-ID: pm-0504 28.11.2006 Page: 52 (52)
This product uses the FCC Data API but is not endorsed or certified by the FCC