Setting up a Mitel SIP-DECT RFP for home/enthusiast use

Project maintained by dect-e Hosted on GitHub Pages — Theme by mattgraham

How-to DECT: Setting up a Mitel SIP-DECT RFP for home/enthusiast use


DECT telephony, courtesy of Eventphone, has been a staple of hacker conferences for years.
Recently, Eventphone has improved their registration and management system and presented more information on its inner workings. There has also been some investigation into the internal hardware and protocols of the Mitel SIP-DECT RFP hardware.

With all this information at the ready, one might decide to try and replicate the familiar DECT setup at home.
Even with these excellent (and entertaining!) resources, however, SIP-DECT is very much an enterprise solution and can be a bit daunting to set up for your own personal use.
Think for a few moments whether you really want to go through with this, or if you already have plenty of other side-projects to occupy your time. Then, probably, read on. ;)

Glossary: What is SIP-DECT?

Just to recap:

The SIP-DECT setup uses several more terms and abbreviations. You’ll primarily come across:

Hardware: RFP generations

The SIP-DECT RFP hardware exists in several feature classes and has gone through several years of development. The model numbers that arise from this are, shall we say, creative.

The naming follows the schema “RFP number [IP|WLAN]”.
“IP” models can only act as a DECT base station; “WLAN” models can provide both DECT base station and WiFi access point service at the same time. Both DECT and WiFi functionality can be enabled/disabled in the configuration.

There used to be “numberL” models that included a license for multiple RFPs. As of SIP-DECT 6.0, licenses are independent from RFP models; there is no distinction between L- and non-L-RFPs anymore. (see also: section “Licensing”)

RFPs exist in indoor and outdoor variants (easily distinguished by their smooth vs rugged case).
Do not use an indoor variant outdoors; its circuit board will corrode, which is generally a bad thing.

Model overview

Let’s look at an overview (as of the release of SIP-DECT v8.0):

  indoor, 4 speech channels indoor, 8 speech channels outdoor, 8 speech channels identification characteristic
UpN (non-IP) - 21, 22 23, 24 rectangular with protrusion, 1 LED
1st generation - 31 IP, 41 WLAN 33 IP smooth edges, no USB port, 1 LED
2nd generation - 32 IP, 42 WLAN 34 IP smooth edges, no USB port, 4 LEDs
3rd generation - 35 IP, 43 WLAN 36 IP (PoE-only), 37 IP (ext-ant) smooth edges, USB port, 4 LEDs
4th generation 44 IP 45 IP, 47 IP (ext-ant), 48 WLAN 47 IP DRC “modern” angular look, no USB port

(PoE-only): power only via PoE, no RJ11 power input
(ext-ant): external antenna connector, no internal DECT antenna
IP: only contains a DECT base station
WLAN: contains both a DECT base station and a WiFi AP
DRC: preinstalled with directional antennas in an outdoor enclosure

You can see a 3rd gen (whose front looks almost identical to that of a 2nd gen, but has vents on the back) and a 4th gen RFP in this photo by Eventphone.

Selecting an RFP

For a home/enthuasiast setup, you probably won’t be too picky about speech channels and indoor/outdoor variants. You should, however, pay attention to the generation:

Buying an RFP

RFPs can cost upwards of 450€ per piece when new.
There is a second-hand market for used devices, but even those are not exactly “cheap”).
You will usually find several offers for RFPs on common auction sites, but it may take some patience to find ones in the 100€ range. (The Eventphone presentation mentions offers around 50€, but those mostly applied to bundles of multiple RFPs and have become a rare exception now that documentation for SIP-DECT setups is becoming more accessible.)

As long as the hardware is functional, you should have nothing to worry about: there are means to reset the configuration even if the seller has not provided the passwords.

Plugging it in: Getting your RFP(s) up and running

Powering the RFP

Gen 2 and 3 RFPs can be powered via Power over Ethernet or via an RJ11 power connector.
Gen 4 only supports Power-over-Ethernet.

As a point of reference for power consumption: An RFP 43 WLAN uses about 5.5 W during normal operation.

All RFPs support Power over Ethernet (PoE) according to the 802.3af standard.
The RFP generally negotiate as Class 2, i.e. 3.84–6.49 W at the device. RFP 48 (Gen 4 with 802.11ac WiFi) requires slightly more power and negotiates as Class 3 (6.49–12.95 W at the device).

The circuit layout of RFP 37 and 43 suggests that they support both “Mode A” (+ on pin 1&2, - on pin 3&6) and “Mode B” (+ on pin 4&5, - on pin 7&8), as they have two bridge rectifiers feeding into the internal DC-DC converter.

Manual testing indicates that PoE voltage can be applied directly (with either Mode A or Mode B pinout) without going through 802.3af negotiation.
Unfortunately, the RFPs only establish an Ethernet link when all 8 pins are connected, so 100 Mbit/s passive PoE injectors (which replace 4 data pins with power-only pins) do not work. 1 Gbit/s passive injectors (which use a transformer to add power to the existing data pins) should work, though.
The RFP requires at least 37 V to function (which matches the specifications of the PA1136NL transformer used in the power supply section).

Gen 2 and 3 indoor RFPs also support direct DC power via an RJ11 connector:

RJ11 power connector

Software update

There are multiple ways to get the latest Firmware on your DECT RFP. (There are additional ways beside the ones described below.)

Update via USB Flash drive

This is the easiest option.

  1. Make sure the Flash Drive is formatted FAT32
  2. Copy the Firmware file onto the Drive
  3. Make sure it is named iprfp3G.dnld (for Gen. 3 RFPs) or iprfp4G.dnld (for Gen. 4 RFPs)
  4. Connect the Flash drive to the RFP and reboot the RFP by switching off and on the 48V
  5. Wait for about 2 minutes until the RFP signalizes successful flashing by flashing all LEDs in orange once

Update via HTTP

This method requires access to an existing webserver.

  1. Extract files iprfp3G.dnld (for Gen. 3 RFPs) and/or iprfp4G.dnld (for Gen. 4 RFPs) on your webserver
  2. Go to your OMM’s web interface, log in and navigate to System/Provisioning & Software Update
    1. Enable Advanced (checkbox in the top right corner)
  3. Below “Software update URL”
    1. Check from specific source
    2. Fill in the URL parts to point to the files from step 1 (as you can see from the form, the filename “iprfp3G.dnld” is appended automatically, so should not be part of your input)
  4. Below “System update”
    1. In the trigger matrix check Software Update and set RFP Software to “M” in the manual trigger column
    2. Go to the top of the page and click OK
  5. If the settings are saved, scroll back down to “System update” and click the “Update” button.

Now the RFP should download its dnld file from the webserver you specified and reboot.

Recovering a RFP with corrupted Firmware.

If the LED1 does not switch to orange after a reboot, chance is high the firmware might be corrupted. You can optionally verify this by get a serial dump of the u-boot bootloader. “UBI error” and “Error reading files” are the indicators you looking for.

To fix this, there is a function called uImageFailSafe that can be found on the internet, at least for SIP-DECT Version 4.

Take a FAT32 formatted USB Flash Drive, copy the “uImageFailSafe” and the corresponding SIP-DECT Vers. 4 “iprfp3G.dnld” onto the Drive and reboot the RFP.

The RFP will flash Version 4 from where it can be upgraded to the latest Version by the procedure shown above.

Factory reset

Just as for the firmware upgrade, the easiest way to reset the RFP is to copy an empty file called factoryReset (case-sensitive) to a FAT32-formatted USB flash drive. Power-cycle the RFP and wait for the RFP to be reset. After a successful reset, the file should theoretically be deleted by the RFP, but sometimes it also resets correctly without deleting the file.

The factory reset via USB was added in SIP-DECT version 6.0. If your RFP has an older version, you will have to update to a newer version first (for example via the USB update method), and use the factoryReset file after the update.

IP configuration

To function as a DECT base station, each RFP needs to be connected to a network, have an IP address, and know (and be able to connect to) the address of an OMM.

The RFP tries to obtain these settings via DHCP by default, but can also be configured manually with a static configuration.

Manual/static configuration via the OM Configurator

A note beforehand: You cannot mix static and dynamic configuration (e.g. obtain the IP via DHCP but configure the OMM IP statically), the RFP will ignore either one or the other.

Connect the RFP to the network and start the OM Configurator (omcfg).
In the top right corner, click on “General”, then select “Options”. Select the correct Network Interface and click “OK”.
Then, in the right side menu, click “Scan”. You will see a “Scan settings” popup, select “get configuration after detecting  an RFP” [sic], enter username and password (default is omm/omm). Select “show only successfully accessed RFPs”. Start the scan can by clicking “OK”.

Select the RFP with the correct MAC adress and click “Edit configuration” on the right side menu. This will let you access the RFP’s configuration.

In the “General” tab, enter the network configuration for the RFP and tick “Use Local Config” to have it use this static configuration.

In the “OpenMobility” tab, enter the IP address of the OMM (and optionally, a backup OMM). If you want to serve the OMM on the RFP itself, enter the RFP’s own IP. It will start up the OMM on reboot. Also enter a working DNS server.
Next, you need to configure TFTP. The options can’t be left empty, but you can enter “” as the “TFTP server address” and any non-empty value as the “TFTP file name” if you’re not planning to use it. The RFP will boot from its internal flash instead (TFTP boot is supported by all RFP generations, internal flash supported on generation >= 3).

The Fields “RFP configuration file”, “Syslog Server address” and “Syslog Server port” may be left empty.

In the “Other” tab, you don’t have to set anything.

When finished, apply the settings by clicking “OK”, then upload the config to the RFP by clicking “Send Configuration”. Enter the username and password (default is omm/omm), then click “OK”.

A message “<Timestamp> Configuration of <MAC-Address> successful” will appear in the OM Configurator’s console to tell you it worked. You can then power-cycle the RFP.



Networks/IPs used in examples:

Network/IP Usage Network for DECT Gateway OMM DHCP-Range begin DHCP-Range end DNS - Quad9 DNS - Quad9

Example snippet for isc-dhcp-server’s dhcpd.conf:

option space sipdect;
option local-encapsulation code 43 = encapsulate sipdect;
option sipdect.ommip1 code 10 = ip-address;
option sipdect.ommip2 code 19 = ip-address;
option sipdect.syslogip code 14 = ip-address;
option sipdect.syslogport code 15 = integer 16;
option magic_str code 224 = text;

host myfancyrfp {
    hardware ethernet 00:30:42:cc:23:42;
    option host-name "myfancyrfp";
    # run OMM on the RFP itself
    option sipdect.ommip1;
    # or run OMM elsewhere (on a VM or other RFP)
    #option sipdect.ommip1;
    option magic_str = "OpenMobilitySIP-DECT";

Example snippet for dnsmasq-dhcp-server’s dnsmasq.conf:

# set interface dnsmasq listens to

# set dnsmask as the authoritative dhcp server

# dhcp pool (start, end, netmask, leasetime)

# static leases for RFPs
# for every RFP, set a tag to choose on which tftp boot file to take (tags are definded below: rfp2g/rfp3g/rfp4g)

# tell the RFPs where to find the omm by setting vendor-specific option 10 to rfp-1's adress.
# this also tells rfp-1 to host the omm on the rfp.

# 2nd gen RFPs will only take the dhcp offer when option 224 is set to the magic_str "OpenMobilitySIP-DECT".
# It might be possible to have co-existing DHCP servers where only the one responsible for RFPs sends the magic_str.

# set the tftp server adress (option 150) and tftp boot file name (option 67) depending on the tag set in the dhcp-host above

# location of the leasefile

# disable dnsmasq's dns server

# DNS servers to use

# enable built-in tftp server (e.g. for gen 2 boot files, ...)

OMM on RFP vs stand-alone OMM


Accessing the OMM

You can access the OMM with you browser for that go to the ip defined in your DHCP config. The default credentials are:

username: omm
password: omm

A common problem you might experince is that the omm only supports tls version 1.1 If you want to enable that in Firefox you can open a new tab with about:config and set security.tls.version.min to 1

Software: Configuring the RFP


Manual OMM configuration and making a test call

OMM Setup

First, log in to the OMM by browsing the web interface, you might have to accept the self-signed certificate. After accepting the EULA, you will be asked to set passwords.

User Default Password Description
omm omm Web Interface, OMM Configrator, OMM Management Portal
root - SSH access

System Settings

Now we have to do some basic setup. Make sure to set the Advanced-Checkbox at the top to access all settings.

First go to the System / System Settings tab to set the PARK.

After obtaining the PARK, the OMM will restart. After logging in again, set the Regulatory Domain setting according to your location. For Europe, select EMEA (“Europe, the Middle East and Africa”). Make sure you apply the settings by clicking OK at the top and wait for the RFP to restart.

SIP Settings

Go to System / SIP and enter the information about your SIP Server. Make sure, you apply the settings by clicking OK.

Setting Example
Proxy Server
Proxy Port 5060
Registrar Server
Registrar Port 5060

Find out the IPEI of your PP

As a prerequisite to the next step you have to know the IPEI of the PP you want to register:

GMI : AccessRightsFailed(ipei=XXXXX XXXXXXX X, Missing DECT_IE_PORTABLE_ID or no wildcard subscription)

Registering a PP

Go to the SIP Users/Devices page. At the Create a new SIP User/Device line, click New. A new window will open that lets you add a new User-Phone-Combination. *TODO: SIP acconts <> USER <> DEVICES ???*

General Settings

Setting Example Description
Display Name 3000 SIP display name (optional)
Number/SIP user name 3000 DECT-internal phone number; used as SIP username if not overridden below
User/Device relation fixed USER / Device relationship
IPEI 12345 1234567 1 IPEI of the PP to register
DECT authentication code 0000 DECT PIN (the one you enter on your PP when registering with the DECT base)

SIP Authentication

Setting Example Description
Authentication user name mySIPuser SIP authentication user (defaults to DECT-internal phone number if unset)
Password mySecret123 SIP authentication password
Password confirmation mySecret123 SIP authentication password

You can then apply the settings by clicking OK at the bottom. The newly created user will appear in the list. Now make sure Subscription is set to Subscription and try to register your PP. The PP should be able to subscribe to your DECT Network and you should be able to make a call. \o/

User-Device Relations


SIP-DECT provides a mechanism to dynamically assign Users (i.e. a number, display name, and SIP account) to Devices (PPs).
This can be useful when a device is shared by multiple users (same handset, changing on-call personnel with individual numbers), or vice versa (fixed on-call number, changing on-call personnel with individual handsets).

To use this feature, set the “User/Device relation” to “dynamic” when creating a combined user-device entry.
If it is not needed, you can choose “fixed” instead.

If a user-device combination is “dynamic” the user can call a feature-code number from their device to detach and re-attach their User from the Device they’re making the call from.

More: Larger deployments, SIP servers, and other shenanigans


There used to be “L" models that included a license for multiple RFPs. As of SIP-DECT 6.0, licenses are independent from RFP models; there is no distinction between L- and non-L-RFPs anymore.

With the new licensing model, up to 5 RFPs can be used together “out of the box” without adding an explicit license. (Presumably, this applies to the number of RFPs connected to the same OMM, regardless of how they are split into DECT synchronisation clusters.) For larger deployments, a license file needs to be purchased. The license is usually tied to the MAC addresses of three RFPs in the deployment (for redundancy in case one of the licensed RFPs becomes defective/unreachable). As a ballpark figure, these licenses start at approx. 530€ for up to 10 RFPs.


The RFPs feature different methods of (usually wall-) mounting them: The indoor models can generally be hooked onto a screw that was previously screwed into the wall, while the outdoor models feature both a hook and a number of nuts embedded into the plastic case.

Since the need for fast and frequent mounting and unmounting during events arose, there is now a repository with measured dimensions and mounting plate designs: dect-e/rfp-mounting


Outdoor RFPs (e.g. 36/37)

The water-resistant case unscrews with four Phillips screws, contains raw PCB, fastened with two Phillips screws:

RFP 37 case interior RFP 37 PCB front RFP 37 PCB back

Indoor RFPs (e.g. 43)

The case has three Torx T10 screws, two pairs of clips on each side, three single clips at the back (near the connectors).

RFP 43 case interior RFP 43 main PCB and antenna RFP 43 main PCB

RFP size

Size comparison between RFP 37 and RFP 43

Gen 4 RFPs are smaller, see this photo by Eventphone for an example.

Serial Console

RFP43 Serial Console