CA2399979C - Ip device registration - Google Patents
Ip device registration Download PDFInfo
- Publication number
- CA2399979C CA2399979C CA002399979A CA2399979A CA2399979C CA 2399979 C CA2399979 C CA 2399979C CA 002399979 A CA002399979 A CA 002399979A CA 2399979 A CA2399979 A CA 2399979A CA 2399979 C CA2399979 C CA 2399979C
- Authority
- CA
- Canada
- Prior art keywords
- controller
- address
- pbx
- database
- cluster
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/58—Arrangements providing connection between main exchange and sub-exchange or satellite
- H04Q3/62—Arrangements providing connection between main exchange and sub-exchange or satellite for connecting to private branch exchanges
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5061—Pools of addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13097—Numbering, addressing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13103—Memory
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/1322—PBX
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13298—Local loop systems, access network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13384—Inter-PBX traffic, PBX networks, e.g. corporate networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13389—LAN, internet
Abstract
In a method of registering an IP device in a network where one of a plurality of servers in the network has provided to the IP device an IP address for a controller for which the IP device has not been programmed, the improvement comprising accessing a database to obtain a further IP address for a designated controller for which the IP device has been programmed.
Description
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
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
-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.
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.
-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
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
-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
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
-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 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
- 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 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
-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.
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.
Claims (3)
1. In a method of registering an IP device programmed for a particular PBX in a network of multiple PBXs connected in clusters, said PBXs including respective servers and controllers, where one of said servers has provided to the IP device an IP address for one of said controllers in a further PBX for which the IP device has not been programmed, the improvement comprising accessing a database to obtain a further IP address for a designated controller in said particular PBX for which the IP device has been programmed, and redirecting said IP
device to establish a connection with said designated controller for registering said IP device therewith.
device to establish a connection with said designated controller for registering said IP device therewith.
2. The improvement of claim 1, wherein said accessing said database further includes: reading a cluster element ID from a remote directory number (DN) table in said database using a software ID supplied by said IP device as a key, wherein said cluster ID identifies one of said clusters within said network containing said designated controller; reading a PBX
signalling ID from a cluster table using said cluster element ID as a key, wherein said PBX
signalling ID identifies one of said multiple PBXs within said one of said clusters containing said designated controller;
and reading said further IP address for said designated controller from a PBX
controller table using said PBX signalling ID as a key.
signalling ID from a cluster table using said cluster element ID as a key, wherein said PBX
signalling ID identifies one of said multiple PBXs within said one of said clusters containing said designated controller;
and reading said further IP address for said designated controller from a PBX
controller table using said PBX signalling ID as a key.
3. The improvement of claim 1, wherein said database is replicated in each of said multiple PBXs.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002399979A CA2399979C (en) | 2002-08-28 | 2002-08-28 | Ip device registration |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002399979A CA2399979C (en) | 2002-08-28 | 2002-08-28 | Ip device registration |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2399979A1 CA2399979A1 (en) | 2004-02-28 |
| CA2399979C true CA2399979C (en) | 2009-10-06 |
Family
ID=31983606
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002399979A Expired - Lifetime CA2399979C (en) | 2002-08-28 | 2002-08-28 | Ip device registration |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2399979C (en) |
-
2002
- 2002-08-28 CA CA002399979A patent/CA2399979C/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2399979A1 (en) | 2004-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10834049B2 (en) | Systems and methods for dynamically registering endpoints in a network | |
| US7843923B2 (en) | Methods and apparatus for determining the port and/or physical location of an IP device and for using that information | |
| US6684243B1 (en) | Method for assigning a dual IP address to a workstation attached on an IP data transmission network | |
| US7287077B2 (en) | Reservation of TCP/UDP ports using UID, GID or process name | |
| US7843934B2 (en) | Methods and apparatus for providing emergency telephone service to IP-based telephone users | |
| US6622220B2 (en) | Security-enhanced network attached storage device | |
| US6754321B1 (en) | Naming convention for different types of device, and apparatus and methods using the naming convention | |
| CA2503929C (en) | A method for recognizing location move of voip phones and ip devices | |
| EP0998099B1 (en) | Network address management | |
| US6421427B1 (en) | Interactive voice response data transfer system and method | |
| US20030200311A1 (en) | Methods and apparatus for wiretapping IP-based telephone lines | |
| JPH1065737A (en) | Substitutive server device and server device | |
| JPH0657007B2 (en) | Local area network | |
| JP2001527327A (en) | Automatic registration of user device settings | |
| US6868450B1 (en) | System and method for a process attribute based computer network filter | |
| US8346940B2 (en) | Method and system for provisioning customer premises equipment | |
| US6618476B1 (en) | Line information security interface for TAPI service provider | |
| US6029201A (en) | Internet application access server apparatus and method | |
| US7298708B2 (en) | IP device registration | |
| CN1672393A (en) | Mobile terminal identity protection through home location register modification | |
| JP3601526B2 (en) | Proxy registration device, network system and program | |
| EP2127328A2 (en) | Addressing system | |
| WO2001014989A1 (en) | Architecture for a network management service which identifies and locates users and/or devices within an enterprise network | |
| CA2399979C (en) | Ip device registration | |
| CN111010425A (en) | Server connection method, load balancing equipment and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20220829 |
|
| MKEX | Expiry |
Effective date: 20220829 |