Mitel Deutschland GmbH 68635RFP36U-01 Manuale Utente
SIP-DECT OM System Manual
14
1.2.2 RFP ONLY MODE
Within this mode the RFP converts IP protocol to DECT protocol and then transmits the traffic to and
from the DECT phones over a DECT time slot. On air the RFP has 12 available time slots, 8 can have
associated DSP/media resources for media streams. All DECT time slots are used for control signaling,
software download over air, messaging and bearer handover independent of associated DSP/media
resources.
from the DECT phones over a DECT time slot. On air the RFP has 12 available time slots, 8 can have
associated DSP/media resources for media streams. All DECT time slots are used for control signaling,
software download over air, messaging and bearer handover independent of associated DSP/media
resources.
Two control signaling channels are also used to carry bearer signals that signal the DECT phone to start
the handover process. If the radio signal of another RFP is stronger than that of the current RFP, the
DECT phone starts the handover process to the RFP that has the stronger signal as the user moves
around the site.
the handover process. If the radio signal of another RFP is stronger than that of the current RFP, the
DECT phone starts the handover process to the RFP that has the stronger signal as the user moves
around the site.
Clusters
Groups of RFPs can be built which are named clusters. Within a cluster RFPs are synchronized to
enable a seamless handover when a DECT phone crosses from one RFP’s area of coverage to another.
For synchronization, it is not necessary for an RFP to have direct line of sight to all other RFPs in the
system. Each RFP only needs to be able to see the next adjacent RFP. But it is highly recommended
that an RFP have visibility to more than one RFP to guarantee synchronization in the event that one of
the RFPs fails.
Groups of RFPs can be built which are named clusters. Within a cluster RFPs are synchronized to
enable a seamless handover when a DECT phone crosses from one RFP’s area of coverage to another.
For synchronization, it is not necessary for an RFP to have direct line of sight to all other RFPs in the
system. Each RFP only needs to be able to see the next adjacent RFP. But it is highly recommended
that an RFP have visibility to more than one RFP to guarantee synchronization in the event that one of
the RFPs fails.
1.2.3 OPENMOBILITY MANAGER (OMM) MODE
If the OMM is not running on a dedicated Linux server, one RFP within a SIP-DECT installation must be
declared to operate as the OpenMobility Manager (OMM). The RFP acting as the OMM may also act as
a regular RFP if it is part of a DECT cluster.
declared to operate as the OpenMobility Manager (OMM). The RFP acting as the OMM may also act as
a regular RFP if it is part of a DECT cluster.
In OMM mode, an RFP functions as a regular RFP. Additionally, it is responsible for SIP signaling
between the SIP-DECT system and the IP PBX/SIP server. Further on, it takes over the management
part of the SIP-DECT solution. You designate an RFP as the OMM by assigning an IP address to the
RFP within the DHCP scope (see section 7.5) or by setting the data via the OM Configurator (see
section 7.7). After an RFP is designated as the OMM, it starts the extra services on board (for example,
the web service that supports the management interface). All RFPs download the same firmware (for
their RFP type), but only one RFP (or two, in standby implementations) activates the OMM services.
between the SIP-DECT system and the IP PBX/SIP server. Further on, it takes over the management
part of the SIP-DECT solution. You designate an RFP as the OMM by assigning an IP address to the
RFP within the DHCP scope (see section 7.5) or by setting the data via the OM Configurator (see
section 7.7). After an RFP is designated as the OMM, it starts the extra services on board (for example,
the web service that supports the management interface). All RFPs download the same firmware (for
their RFP type), but only one RFP (or two, in standby implementations) activates the OMM services.
Note: It is possible to deactivate the DECT part of an RFP. If the DECT
interface is deactivated, all resources (CPU and memory) are
available for the OMM.
This might be necessary, for example, in configurations where a
mix of OpenMobility Manager, G.729/Conferencing and WLAN is
provided by the same RFP.
available for the OMM.
This might be necessary, for example, in configurations where a
mix of OpenMobility Manager, G.729/Conferencing and WLAN is
provided by the same RFP.
1.3 ABOUT THE OPENMOBILITY MANAGER
The OpenMobility Manager (OMM) requires an RFP 35/36/37 IP resp. RFP 43 WLAN, or a dedicated
Linux server.
Linux server.
There is only one OpenMobility Manager (OMM) active in the system at a given time.
•
If the OMM runs on an RFP, a 100 MB network link is required.
•
If the OMM runs on a dedicated Linux server, a 1 GB network link is required (see also section