Note: Descriptions are shown in the official language in which they were submitted.
CA 02399979 2002-08-28
IP DEVICE REGISTRATION
The present invention relates generally to TCP/IP networks, and more
specifically to a method of handling device registration in a TCP/IP network.
A DHCP server is a component that uses the Dynamic Host
Configuration Protocol (DHCP) to provide configuration information to IP hosts
on a
TCP/IP network. For example, in IP telephone systems such as the Mitel
Networks
MN3300 telephone system, DHCP servers are used to provide IP addresses to IP
devices that connect to the system. Each MN3300 has its own DHCP server, such
that
when multiple DHCP servers are connected in clusters (e.g. networked MN3300
systems), problems can occur when registering newly connected IP devices.
When an IP device to be controlled by such a system first connects to
the network, it must request configuration information (at a minimum, its own
IP
address and that of its controller) from a DHCP server. It does so by
broadcasting a
message referred to as DHCP Discovery. The IP device accepts the first
response to
its request and ignores any others. Once the device receives the required
information
from the responding DHCP server, it receives a software download from a TFTP
server associated with the responding DHCP server and attempts to communicate
with its controller using the DHCP-specified IP address. The TFTP server is a
component that uses the Trivial File Transfer Protocol (TFTP) to transfer
files (e.g.
device software loads) from a storage area to a client (e.g. the device 1).
The DHCP server in a MN3300 system is typically configured to
provide the IP address of its co-resident controller as part of the
configuration
information requested from it by an IP device. The DHCP server has no way of
determining whether, in fact, a device making the request 'belongs' to the
controller
associated with the server. In a multiple or clustered MN3300 network, any
DHCP
server may respond to any IP device that broadcasts a Discovery request within
the
CA 02399979 2002-08-28
-2-
network. This results in the IP device being programmed via a software
download
from the responding MN3300 system. If an IP device receives an IP address for
a
controller other than the one on which it has been programmed via the software
download to be controlled, its attempt to receive service fails.
One approach to overcoming this problem is to turn off all but one
DHCP server in a cluster or network. This requires that the DHCP server be
configured to use a unique identifier for the device (typically a Media Access
Control
or MAC address) to map the appropriate configuration information. It further
requires
that this identifier be pre-programmed (i.e. mapped to one of multiple
controllers) in a
database accessible to the DHCP server.
A second approach is to provide one MN3300 (hence, one DHCP) per
subnet within a network. However, that requires more complex network
architecture.
According to the present invention a method is provided by which a
controller (such as a MN3300 controller) is able to determine the designated
controller for any IP device that attempts to receive service from it. The
method also
includes a step of redirecting any such IP device to its appropriate
controller.
A detailed description of the prior art and the preferred embodiment is
set forth herein below having regard to the following drawings, in which:
Figure 1 is a system block diagram of a TCP/IP network in connection
with which the method of the invention may be implemented.
Figure 2 is a message flow diagram showing IP device registration
according to the prior art.
CA 02399979 2002-08-28
-3-
Figure 3 is a message flow diagram showing IP device registration
according to the method of the present invention.
Figure 1 shows a system for registering and controlling an IP device 1
in a network, such as a MN3300-based system. When initially connected, the
device
must obtain configuration information from a DHCP server 3, including the IP
address for the device 1, the IP address of a TFTP server 5 from which the
device
obtains its software load, and the IP address of its controller 7.
Thus, as shown in Figure 2, the device 1 periodically broadcasts a
DHCP Discovery request until it receives a response. It accepts the first
response
received and ignores any subsequent responses from other DHCP servers in the
network. The IP device 1 then obtains its software load from the TFTP server
5,
including MAC address, and execution of its software begins.
The IP device 1 then attempts to 'register' with the controller 7 for
which it has received an IP address. This involves establishing a TCP/IP link
with the
controller and providing it with the programmed MAC address for the device. If
the
MAC address supplied by an IP device upon registration has not been pre-
programmed against a directory number (DN) in the database, then the user of
the IP
device is prompted to supply a PIN (e.g. the DN preceded by a unique code).
The PIN
associates the user with a line of service (e.g. DN), programmed in the
database 9 of
the controller 7. The controller 7 checks to determine whether the DN device
"belongs" to it (i.e. the database 9 for the controller 7 contains an entry
(DN) for the
device 1). If not, the registration attempt is rejected (Neg_Ack requesting re-
entry of
PIN) and the device does not receive service. The foregoing device
registration
process is in accordance with the prior art.
According to the present invention, as shown in Figure 3, in the event
that the controller 7 determines that it is nvt the assigned controller for
the IP device
1, it calls a "send redirect reg req" procedure, as discussed in detail below.
This
procedure is used to determine whether the device belongs to any other
controller in
CA 02399979 2002-08-28
-4-
the cluster or network based on the PIN (with the pre-pended code removed). It
then
obtains the address of the designated (i.e. programmed) controller for that
device from
its local database 9. Specifically, remote DNs (i.e. DNs programmed for
devices on a
MN3300 system connected to the same network cluster) may be programmed into
the
database 9 from the controller 7 using forms accessible via a graphical user
interface
(GUI). The remote DNs stored on database 9 include a number to identify the
designated MN3300 followed by the actual DN. The controller 7 then accesses
another locally stored form to map the remote DN to an IP address for the
designated
controller.
OPS Manager may be used to propagate changes to any DN in the
database 9 to all MN3300s in the network, as described in co-owned Canadian
Patent
No. 2197517 issued January 15, 2002.
If, in fact, the device belongs to the originally designated controller,
registration completes and the device receives service (i.e. the device 1
receives a
Pos Ack message, as in Figure 2). If not, the controller 7 provides the new
controller
IP address to the device 1 in order to redirect the device to the designated
(i.e.
programmed) controller. A person of skill in the art will understand the
sequence by
which the device handles the redirection (i.e. closing the link with the
current
controller, and opening a new link with the appropriate controller using the
new IP
address that is received from the current controller). Once a TCP/IP link has
been
established with the appropriate controller the registration process is
repeated and, if
successful, the device 1 receives service.
The pseudo-code reproduced below describes the process that accesses
database 9 to obtain the remote DNs and sends that information to the IP
device 1 for
redirecting the device to the designated controller:
The following new routines are used in this process:
- get~bx ip address: this routine finds the IP address of the
designated controller in the cluster.
- format save-pin request to set
CA 02399979 2002-08-28
-5-
- send redirect reg req: upon finding the designated controller, this
routine sends the IP address to the telephone set (e.g. via a Mitel
Viper virtual "card" for mapping IP addresses to devices in legacy
systems made prior to the advent of IP addresses.
- format redirect reg request to set: this routine formats the
redirect message.
Prior to calling the Get_pbx ip address routine, the swid (software id
object that includes the DN) is sent by the IP device 1 to the controller 7,
as follows:
IF((map DN to swid(dn of_set,device swid)=success)
AND
(device swid.sw_slctr = sws remote dn))
THEN
send redirect reg req(new_msg,device_swid);
Then, the send redirect reg_req procedure is executed. This procedure
fulfils two functions. First, it calls the get-pbx ip address routine for
collecting the IP
address of the correct controller. Secondly, it sends a message to the IP
device 1 along
with the correct controller IP address, for redirecting the device 1 to
establish a
TCP/IP connection with the correct controller, as discussed above.
send redirect reg_req
30
get_pbx ip_address(device_swid, pbx ip address);
get_pbx ip_address(device_swid, pbx ip_address)
{
IF the device swid.sw_slctr is pointing to a remote DN THEN
//Access the Remote DN Table in the database 9 and read the specific
record //using as key the DN contained by the device swid:
IF read table record(device_swid, rdn table entry) = success THEN
//Create a temporary swid using the cluster element ID in the record
obtained //from the Remote DN Table above; Access the Cluster Table in
CA 02399979 2002-08-28
-6-
the //database 9 and read the specific record using as key the cluster
element IIID:
temp swid.sw_slctr := sws cluster_element;
temp swid.cluster_element_id := dn_table_entry.ceid table index;
IF read table record(temp swid, cluster table entry) = success THEN
//Create a temporary swid using the sws_pbx signalling ID in the
record //obtained from the Cluster Table above; Access the PBX
(Controller) llTable in the database 9 and read the specific record using
as key the //sws_pbx_signalling ID:
temp swid.sw_slctr := sws~bx_signalling;
temp swid.pbx_signalling id:=cluster table entry.cluster_element index-1;
IF read table record(temp_swid, pbx entry) = success THEN
//Set the pbx_ip_address to the IP address in the record obtained
from //the PBX (Controller) Table above:
pbx_ip address := pbx_entry.ip_netwk sig_ip_address;
ENDIF;
ENDIF;
ENDIF;
ENDIF;
All the tables exist in the local database and they must get filled
through user interfaces (e.g. CDE, ESM, OPS).
Modifications and alternatives of the invention are possible. For example,
although the method of the present invention has been described in terms of a
networked MN3300 telephone system, it will be appreciated that the method may
be
applied to any controller capable of handling registration of IP devices.
This, and all
other such modifications and variations are believed to be within the sphere
and scope
of the invention as defined by the claims appended hereto.
