GB2523123A

GB2523123A - Method and hardware device for remotely connecting to and controlling a private branch exchange

Info

Publication number: GB2523123A
Application number: GB1402482.2A
Authority: GB
Inventors: David Lochrin; Fergal Meath; Michael Noel O'keeffe
Original assignee: FIJOWAVE Ltd
Current assignee: FIJOWAVE Ltd
Priority date: 2014-02-12
Filing date: 2014-02-12
Publication date: 2015-08-19
Anticipated expiration: 2034-02-12
Also published as: GB201614376D0; WO2015121389A1; GB2523123B; GB201402482D0; GB2537785B; GB2537785A

Abstract

A method and apparatus for remotely connecting to and controlling IP-enabled private branch exchange IP-PBX 110 in the presence of barriers, such as a firewall 114, without the need to configure the IP-enabled PBX's that are requiring the ability to be remotely accessed. A hardware device 300 automatically initiates a connection request to a remote control server 106. The remote control server 106 authenticates the unique set of encrypted data from the hardware device 300 and establishes a permanent secure tunnel connection 120 on the same connection socket to the uniquely identified hardware device connection request. A remote control server mediates the establishment of dynamic IP links within this secure tunnel to the requested IP-enabled PBX via the hardware device upon request of the Support PCs operated by customer support engineer 118. With programmed IP address or plurality of addresses in the hardware device the Support PC user can access selected IP-enabled PBX's connected on the same network as the hardware device. Firewall traversal for providing remote support and maintenance of a device inside a private local area network (LAN).

Description

METHOD AND HARDWARE DEVICE FOR REMOTELY CONNECTING TO AND CONTROLLING A

PRIVATE BRANCH EXCHANGE.

Field of the Application

The present application relates generally to telecommunications equipment and more specifically to Private Branch Exchanges (PBX's) installed on a local area network. The application is directed at providing remote support and maintenance of such equipment.

Background

PBX's and other telecommunications equipment are regularly installed on a customers' local area network. PBX's which connect to a local area network are generally referred to as IP-PBX's. Local area networks in turn are typically connected to the Internet. For security however, barriers (for example firewalls) are placed between the local area network and the Internet. Generally, support for a PBX is performed by means of site visit by a support engineer. This is both costly and time consuming.

Eliminating the need for such site visits would be desirable. Whilst many PBX's offer the ability to be connected to over a network, the reality of the situation is that it is generally not practicable.

Specifically remotely connecting via the internet to PBX equipment on a company's internal network can be limited by the presence of firewalls, gateways or other barriers designed to provide protection of valuable data on the company's network by unauthorised users, thus the equipment to be remotely accessed is rarely directly accessible by a public IP address. At the same time, the PBX equipment itself may be designed by different companies and not easily programmed to allow set up of remote support from a single server location. At the same time, a site visit would generally be required to facilitate remote support if it is possible.

However, companies typically restrict incoming traffic to servers on the network via firewalls, for example public website, email. Outgoing traffic is typically permitted for standard functions such as web browsing using protocol such as Hyper Text Transfer Protocol (HTTP), File Transfers using File Transfer Protocol (FTP). Gateways can provide S centralised access to the internet based on Network Address translation (NAT) which allows specific IP equipment on a premises share access to the internet. There isn't a general mechanism for inbound traffic. Gateways can be configured to map ports to specific equipment or proxies installed to handle specific applications. Because of such security barriers it generally requires trained IT personnel to support and approve the initial setup of remote access to equipment. However, even where such support may be readily available on-site, which is not generally the case, the use of processes such as port forwarding are problematic from a security perspective since legacy IP-enabled equipment might typically not have the ability to process a secure connection from the internet. The conventional wisdom having been that PBX equipment would be maintained on site and thus security was not an issue. PBX equipment might not have the processing resources required or the software on the PBX has not been kept up to date with the latest state of the art security standards. Clearly in such a situation without secure communication, port forwarding would potentially provide a point of attack to the PBX and more generally to the local network from persons on the outside.

Summary

The present application addresses this by providing a hardware device that can be placed on a company's local area network that can connect a PBX to the outside world through a firewall or other barrier. The advantage of such a device is that PBX equipment may be remotely accessed without interfering with the firewall or other barriers locally present on the network where the PBX is located. At the same time, the hardware device may be shipped directly to a customer's site using post or courier. The hardware device is designed to be simple and easily installed by anybody requiring just a network and power supply connection. Once installed on the local area network, a remote connection to the PBX may be established through a secure tunnel established between the hardware device and a support centre server. In this way, an engineer located at the support centre may provide support by accessing the PBX thus saving the cost of a call out by a technician to the site.

Accordingly, the present application provides a method and hardware device in accordance with the claims which follow.

Brief description of the drawings

Figure 1 is a block diagram showing a system according to an embodiment of the present S application illustrating a single case use; Figure 2 is a block diagram illustrating the system in a multi case environment; Figure 3 illustrates an exemplary representation of a hardware device for use in the systems of figures land 2; Figure 4 is a block diagram of the circuitry of the hardware device of figure 3 Figure 5 is a flow chart of an exemplary process for establishing a secure tunnel between a hardware device and a server in figures 1 and 2; Figure 6 is a flow chart of the link management at the remote control server and the Hardware device end of link; Figure 7 is a table showing an example of the remote control server mapping; and Figure Eisa table showing an example of the hardware device mapping.

Detailed description of the drawings

The application will now be described with reference to the drawings. A simple situation, as illustrated by the arrangement 100 in Figure 1, is one in which a customer 102 has a local area network 108 to which a plurality of different devices 110, 112 may be connected. One of these devices may be a PBX 110. A supplier may be responsible for this PBX, albeit that the PBX is installed on the customer's rather than the suppliers local area network. In this context, the supplier may not have supplied the PBX to the customer but merely maintains it for them and provides support.

The customer's LAN is secured by a firewall 114 which prevents the supplier obtaining direct access to the customer's equipment unless provision is made on the firewall for example by the network administrator opening a port connection on the firewall to the PBX.

To address this, the supplier has provided the customer with a hardware device 300.

The hardware device has an Ethernet interface allowing it to be connected to the customerTs LAN using a conventional Ethernet (patch) cable. The hardware device may also have a Wi-Fi adaptor allowing it to connect wirelessly to a local network. The hardware S device is configured to employ standard networking protocols, for example Dynamic Host Configuration Protocol (DHCP), to obtain a local IP address on the network and the IP address of the Internet gateway on the LAN. Once the hardware device has obtained this, it attempts to make a connection to a server 106 on the Internet 104, which is associated with the supplier. The server may be identified by means of an IP address or LJRL. The server in turn may be protected by a firewall 116 from the Internet. Once the hardware device has established a connection with the server, the server and hardware device establish a secure tunnel. This secure tunnel may be used to allow a remote engineer 118 connect from a remote computer through the tunnel established by the server and the hardware device to a PBX 110 on the LAN, thus bypassing the firewall 114.

The arrangement is not limited to providing support for a single PBX. As illustrated in Figure 2, the system may be used to allow multiple engineers on different computers 12 connected to the remote server 6 access to multiple PBX devices using multiple hardware devices on different LAN5, which in turn are at different sites where each site may correspond to a separate customer.

The hardware device 300, as illustrated in Figure 3, is intended to be as simple as possible for a user to install. More particularly, the hardware device is intended to be shipped from the supplier and installed by any person on the customer's site without specialist knowledge. The hardware device accordingly has a minimum of connections and no displays, keyboards or similar features which would be common on a computing device.

Instead, the hardware device has an Ethernet connector 304 and a power supply connection 302 along with an associated power supply (not shown). It will be appreciated that where a network employs Power Over Ethernet (which is common when a LAN is used for IP phones), the separate power supply may be omitted and power obtained directly from the Ethernet connection. The only other visible features (with the exception of possibly RF antennas discussed below) are a number of indicators, typically LEDTs 306,308, 310. These are intended to be straightforward and easy for a user to understand. Thus in the exemplary device shown, there are three LED's. A red LED 308 is located beside a green LED 306 on the top of the device and an orange LED 310 is integrated with or beside the Ethernet port. It will be appreciated that the different colours are used to help distinguish the LED5 from one and other. The red LED is used to indicate power and will come on if there is power present.

The orange LED is used to indicate if a network connection is present. The green LED serves two purposes; firstly it flashes where the hardware device is attempting to connect to the remote server and then goes solid green when a secure tunnel has been established with the remote server. It will be appreciated that this simple arrangement for the hardware device allows for practically fool proof installation whilst at the same time allowing a remote engineer by means of simple questions over the telephone to a user to ascertain the state of connection of the hardware device. The hardware device may come with a separate wall-bracket allowing it to be mounted out of the way for example in a comm's cabinet. A clip 312 may be provided through which a cable tie or similar faster may be looped to restrain the power lead and to prevent the voltage supply from accidentally being removed.

The internal circuitry of the hardware device, as shown in Figure 4, is relatively straightforward and suitably comprises a processor 408, memory 404, a network interface 402 for connecting to a Ri45 connector 304 and driver circuitry 410 for the LEDTs along with other conventional circuitry including power regulation (not shown) which provides suitable voltages from the input voltage (e.g. 5V) from the power supply. The memory suitably comprises non-volatile memory which may be used to store program code and configuration information along with RAM for normal processor operation. The hardware device may also comprise a RF circuit 406 for communicating with one or more mobile networks. Where such an RE circuit is provided, the antennae for the RE circuit may be internal to or mounted externally on the hardware device. Where such an RE circuit is included the device may include a connection for one or two SIM cards to allow access to the mobile network. Having two SIM cards allows for redundancy in the case of the failure or unavailability of a particular mobile network (for example in an area of poor reception). It will be appreciated that mobile reception can never be guaranteed but providing multi-SIMS allows for access to more than one mobile network which reduces the risk. The purpose of the RE circuit is primarily as a back-up in case the hardware device is unable to establish an Internet connection through the local area network or where the connection fails.

The method of use 500 of the hardware device with the remote server will now be described in greater detail with reference to Figure 5. The process begins with the connection 502 of the hardware device to a port on the local area network of the customer.

The hardware device then automatically initiates 504 a connection to the remote (control) S server. Suitably, this initiating includes sending encrypted data to the server. Suitably, the data is encrypted using a public key of the server which may be obtained as part of the initial communication or be pre-stored on the hardware device. The encrypted data may contain a customer ID or PBX device ID details or both. The data is to identify the site to the control server. Other methods may be employed for example using the MAC address of the hardware device as the identifier. Regardless of the data selected, it is used by the server to ensure that the connection request is coming from a valid hardware device. Once a hardware device is authenticated, a permanent secure tunnel connection is established 506 from the remote control server to the Hardware device. It will be appreciated that the connection will be made through a port on the router/gateway of the customer's LAN. The secure tunnel will suitably be over the same port as the initial incoming request from the hardware device. Suitably, the port used may be port 443 which is the port conventionally used for secure http connections.

This secure tunnel is permanently established and duration of the link may be controlled 508 by the transfer of keep-alive control signals. The remote control server can dynamically establish 510 an P link within this secure tunnel to the PBX.

In one implementation, the administrator of the local IP network programs the Hardware device (via a web configuration interface) with the name and IP address of the PBX that may be accessed by the remote control server. This gives the LAN administrator the full control of how the remote control server can access the local LAN. The web configuration interface may also allow the LAN administrator the ability to identify the type of PBX present on the network. For example, the web configuration interface may allow the LAN administrator to select the manufacturer and model of the PBX. This for example may be by means of conventional drop-down boxes in a web page provided by the web configuration interface.

The web configuration interface may also be accessed by a remote user through the server and secure tunnel. Access to the web interface may be controlled by additional security including the requirement to provide a username and password. Different features may be provided in menus provided by the web configuration interface based on the user accessing the web configuration interface. This may for example be based on the username used to connect or whether the requested connection came from the local LAN or through the secure tunnel.

In another implementation, the PBX information (primarily IP address but may include make and model of PBX) is pre-programmed prior to dispatch to the customer.

Where the make and model of the PBX are not programmed or input manually, the hardware device may be configured to interrogate the PBX (using the programmed IP address) to identify the manufacturer or model of the PBX or both. Knowing the make and model of the PBX allows the hardware device to interact with the PBX correctly since the way in which data is retrieved from and loaded onto a PBX can vary based on manufacturer and possibly model.

One exemplary method of identification will now be described. The method commences with the hardware device issuing an IP connection request (e.g. ping or http request) to the IP address of the PBX. As a result of this, from the data returned, the PBX will have the MAC address of the PBX. The hardware device suitably has a table or database of MAC address ranges, with each range associated with a particular manufacturer and model. This database or table may be looked up using the retrieved MAC address to identify the manufacturer and model. The table or database may be updated from the remote server or indeed hosted on the remote server and interrogated by the hardware device.

Having an identification of the PBX, identification meaning at least one of the manufacturer and model of the PBX allows the hardware device to interact correctly with the PBX.

Thus as an example, the retrieving of call statistics from the PBX is described below. Whilst this feature may be provided generally on PBX's, the method and information required to retrieve the call statistic files will vary from manufacturer to manufacturer or indeed from model to model. Thus by performing the interrogation or by information entered through the web configuration interface or otherwise, the hardware device may identify the manufacturer or model of the PBX or both and interact with the PBX using the correct method permitted for the manufacturer or model or both.

For example, a certain manufacturer might make its call statistics retrievable as a particular file using a http request. Accordingly, the hardware device having identified a PBX as coming from a particular manufacturer would know (from a table or other source) that the appropriate method to use was a http request and more particularly the form of the http S request, e.g. http://cip address>/call_statistics.csv. It also allows the PBX to determine the file format of the call statistics file (if the information is provided in a file) e.g. whether it is a comma separated format (csv) or other generic format or indeed a proprietary format of the manufacturer. Equally, having identified the PBX, the structure of the call statistics data may be determined to allow the hardware device to perform an analysis, e.g. what format date and time data might be in, the order of the data items, etc. This allows the hardware device to parse the call statistics file to produce a call statistics search report. For example, duration of outgoing calls on a particular date. Thus for example, the hardware device may function with a wide variety of different PBX manufacturers and models but provide generic call statistics. This generic information may be uploaded to the remote server. Additionally, the information may be made available through a web interface, either at the remote server an associated server or on the hardware device, to a network administrator locally or to a remote engineer. Thus a standard interface showing call statistics may be presented to a user irrespective of the PBX present. It will be appreciated that the interface presented to the user on the hardware device is not that of the PBX and thus a network administrator may be given access to particular sets of data or indeed functionality of the PBX through the web interface without actually requiring any direct access to the PBX or indeed knowledge of how to navigate the PBX interfaces. It also allows for customisation of the access provided to a local network administrator or indeed other users.

It will be appreciated that this equally applies to actions performed from the remote server.

Continuing with the method of Figure 5, once a hardware device has established a secure connection, for example using the secure shell (SSH) protocol, with the remote server, the remote server can be used to grant access to a PBX on a customer's site from a support engineer which may be operating from a remote support centre PC connected to the remote control server via internal private network or via secure web access can request connection to a client site. Indeed, as illustrated in Figure 2, in all likelihood there will be a plurality of such support centre computers.

The method of granting access suitably begins with an engineer on a support centre computer making a request 514 to access the remote control server. Access from support computers may be limited by an authentication procedure 516 or other security procedures including for example requiring the entry of usernames and passwords.

Once authenticated, the engineer is granted access 518 to a database containing details of the various customer sites that are connected by secure tunnels to the remote server.

Access to this database maybe through a particular application or for example by means of a suitable web page interface.

Such access may be limited to users with appropriate privileges for accessing a particular client site. Upon request from support centre PC to remote control server to connect to a particular client site a dynamic IP link is established 520 by the remote control server within the already established secure tunnel to the hardware device of that specific client. To overcome overlapping IP subnets on different local networks, the remote control server maps a unique destination IP address to each local IP address of the predetermined PBX equipment on the local IP network as illustrated in Figure 7.

Once a link is established between the engineer on the support centre computer and the PBX through the remote server, secure tunnel and hardware device, there will be a general management function 600 shared between remote server and hardware device as shown in Figure 6. The remote server will continue to monitor 602 the connection. The remote control server is suitably configured to only permit IP traffic to flow from authorized remote support centre PCs to the hardware device. The hardware device will forward IP traffic to the local IP address of the PBX. Unsolicited traffic from the hardware device is ignored 606 by the remote control server. Unsolicited traffic from the local IP network to the hardware device is ignored. On completion of data transfer between support centre PC and client PBX being managed the support centre PC will close down the IP link within the secure tunnel to the hardware device thereby closing off communication to the client PBX being managed.

The remote control server can also close down the link automatically after pre-programmed conditions are met (e.g.; a specified time period, traffic inactivity). Equally, the remote server can monitor 604 the SSH tunnel to ensure that activity is with predefined limits.

Equally, all activity can be logged 604 to record an accurate picture of the actions and time spent between support computers and custonier sites.

Separately, the hardware device may include a monitoring function 608. This monitoring function may monitor 610 the secure connection to ensure that traffic is within expected limits. Where activity is detected outside these limits, the hardware device may clear down the secure tunnel and attempt a reconnection 612. An exemplary limit maybe the number of failed packets in a given period.

The IP-enabled PBX devices (3a-Na) that can be controlled may be determined by programming the IP addresses of these IP-enabled PBX devices (3a -Na) into the hardware device (la). The IP address of the IP-enabled PBX devices (3a -Na) on the company network can be programmed by, a network administrator, end user or support engineer directly onto the Hardware device (la) via a local IP link on site, pre-programmed prior to shipping to site or remotely downloaded by remote centre PC (12) onto the hardware device (la) via the remote control server (6).

Remote support centre PC (12) or plurality of PCs connected to the remote control server (6) via internal private network or via secure web access may request connection to a client site if they have appropriate access privileges. The remote control server (6) stores a list of all connected Hardware devices (la) and allows support centre PC (12) access to client sites and IP-enabled PBX devices (3a-Na) on each site that level of access control permits. Upon request from support centre PC (12) to remote control server (6) to connect to a client site a dynamic IP link is established within the already established secure tunnel by the remote control server (6) to the hardware device (la) of that specific client.

In order to overcome the fact that many client site networks have overlapping private P subnets (e.g. 192.168.1.0/24), the remote control server maps a unique destination P address to each of the local private P addresses of the P-enabled PBX devices on the client site network as shown in Figure 7. The mapping associated with a particular site is shared with the hardware device on site. Then the remote control server will only permit IP traffic to flow from authorized remote support centre PCs to the hardware device. The hardware device, as shown in Figure 8, will then use the shared mapping information to translate the destination IP address to the local IP address of the IP-enabled PBX equipment and forwards the IP traffic to the appropriate IP-enabled PBX device (3a -Na). At the remote control server (6) the mapping also specifies the I P addresses of the support centre PC5 that are authorized to access the client site network. IP traffic to and from un-authorized support S centre PC5 is ignored. This is accomplished by the remote control server (6) assigning virtual IP addresses to the hardware device (la) and for each IP-enabled PBX device (3a -Na) to be managed on the site and the Hardware device forwards on the appropriate data for each IP-enabled PBX device (3a to Na) through the use of IP tables to implement NAT. Once the IP link is established between the support centre PC (12) and the IP-enabled PBX device (3a -Na), support centre can interact with IP-enabled PBX device (3a -Na) as if it was connected on the same IP network as the IP-enabled device (3a-Na). Un-authorized access to the IP link is prevented by the use of firewall software both in the Hardware device (la) and at the remote control server (6). Unsolicited IP traffic from the hardware device (la) is ignored by the remote control server (6). Unsolicited IP traffic sent by the IP-enabled PBX devices (3a -Na) to the hardware device (la) is ignored. Unsolicited IP traffic from any device on the local IP network to the hardware device (la) is ignored.

On completion of data transfer between support centre PC (12) and client IP-enabled PBX devices (3a to Na) being managed the support centre PC (12) will issue a request to remote control server (6) to close down the IP link within the secure tunnel to the hardware device (la), thereby closing off communication to the client IP-enabled PBX device being managed.

Source or destination address mapping can be used in setting up the dynamic IP links.

The remote control server can also close down the IP link within the secure tunnel automatically after pre-programmed conditions are met (e.g. time period, traffic inactivity).

The hardware device (la) has stored in programme memory a plurality of domain names or public IP addresses. In the event of a failure to connect to the remote control server (6) after a predetermined number of attempts the hardware device (la) will cycle through the plurality of domain names and IP addresses until a successful connection is attained.

It is also possible that the remote control server (6) can establish secure IP links between a plurality of associated hardware devices (la) via the remote control server (6) thereby providing a restricted access virtual private network between the networks on which the associate hardware devices are connected.

Whilst, the primary purpose of the hardware device is to establish a secure tunnel to permit remote access to a PBX, it is not so limited. The hardware device may be used to supervise, monitor and update the PBX. For example, a particular problem with PBXT5 is updating their firmware. The conventional wisdom being that the firmware will be uploaded locally by a S technician. As a result, PBXT5 are not particularly fault resistant and having a PBX retrieve a firmware update across the internet may be at best unreliable. The hardware device may be configured to have excess storage capacity, which may be used to download a firmware update. Once the firmware update has been successfully downloaded, the hardware device may cause the PBX to download the update locally from the hardware device. Equally, software files may be uploaded from the PBX's to the server through the hardware device.

This option may for example be employed to allow the software to be passed onto a PBX manufacturer so that the manufacturer can debug the software or identify a solution to a particular issue identified.

The hardware device may also be used to interrogate the PBX for data, for example call statistics or call records.

One use of this may be to prevent misuse of the PBX. It will be understood by those skilled in the art that there are a variety of different methods by which an unsuspecting customer may be defrauded through misuse by either staff or third parties of a PBX. One particular example is hijacking by unauthorised third parties. Frequently, a customer only realises there is an issue when a bill is received a month or more after the event.

The hardware device may be used to identify the problems/potential abuses at an early stage from call statistics or call records. For example, the hardware device may build up a record of the usage pattern and then trigger a warning when the usage pattern differs significantly indicating abnormal activity. It may also monitor for calls during periods when no calls would be expected and trigger a warning if a threshold is exceeded. Similarly, the hardware device could periodically download a blacklist of numbers from the server suspected to be used for fraudulent purposes and monitor call records for their usage. The warning may be a notification message sent to a user or to the server. For example, the notification may be an email or SMS message.

The hardware device may also act by issuing a command to the PBX to halt the problem where a problem is detected. Such a command may be one to reset the PBX or to prevent any outgoing calls from the PBX.

It will be appreciated that a wide number of other applications may be usefully employed using the system, method and hardware device described herein. A number of these applications will now be described.

An advantage of the present application is that maintenance of PBX's is effectively centralised through the remote server. The centralisation of maintenance of PBX's through the remote server allows more accurate tracking of engineering time spent on support. In the past, time spent would have been loosely recorded since a significant amount of time spent in maintaining PBX's would have been with respect to travelling to and from the customer site. In contrast, where a hardware device is employed of the type described above, the time spent by a support engineer (i.e. connection time) may be directly tracked at the server. As a result, more accurate statistics can be developed allowing for more complex billing techniques or more accurate cost recovery. Thus a further feature provided is where the server monitors, using the logging information previously described, the time spent by an engineer connected remotely through a hardware device to a PBX. The recording of the time may include identifying the engineer, the customer and the PBX. The time may be recorded as a start time and a finish time. This information may be stored in a database associated with the server. The database may be on the same server or the information may be provided from the server to a database server which stores the information in a database.

A further benefit of using the hardware device and server combination is that advanced data analysis becomes available. For example, the hardware device may be used to collect more advanced information from the PBX over time. For example, the hardware device may periodically poll the PBX (or retrieve from logs), the number of P trunks used. This information may be provided to the server. By recording this information over time, a network operator can develop a more detailed picture of their network.

It will be appreciated that telecommunications are moving generally to VOIP based communication. A disadvantage of this is that the telecommunications operator loses oversight of the call quality where previously this might have been measured within the operator's equipment. Thus collecting more advanced information may be employed to account for this. More particularly, with the arrangement described herein, the hardware device may be employed to gather VOIP statistics from the PBX connected to it and provide this information to the server.

VOIP statistics include the number of IP trunks used/programmed per PBX, VOIP provider server details, and advanced VOIP settings. Advanced VOIP settings include VOIP QoS settings, preferred Codec options, and silence suppression. Bandwidth capacity of the IP trunk lines can be calculated, and a notification can be sent when a defined Bandwidth capacity threshold has been exceeded. These VOIP statistics can be retrieved from the PBX as configuration files or as reading data from the PBX web-page. Downloading PBX VOIP statistics or configuration files will depend on the PBX manufacturer and model. The PBX manufacturer and model is known in the server, and thus software is downloaded to the hardware device to retrieve the VOIP statistics, or the VOIP statistics is retrieved directly from the server.

The VOIP statistics may be collected over time allowing an accurate picture for VOIP quality to be presented for a customer. Additionally, the information may be aggregated with VOIP statistics for other customers on the server or passed to another server for analysis. This aggregated information may then be analysed to identify problems or to facilitate network planning\expansion. The aggregated information may be linked with customer information so that the aggregation of statistics may be based on particular geographic areas, which may be by means of street, post code, town etc. Equally, the statistics may be linked to a particular exchange to produce statistics for individual exchanges.

Given the make and model of the PBX, another list maintained on the hardware device may be referenced to establish what application to run for retrieval of internet connectivity statistics. For example an application would repeatedly call wget http://cip address>/network_statistics to get the latest network connectivity statistics. The a pplication can then parse through the data and produce an internet connection quality status report.

Similarly, call statistics data may be mined for patterns that indicate issues with call quality.

For example, a call that is dropped and re-established repeatedly over a short period of time between two parties, indicates a poor quality experience. Correlating this data with internet connectivity statistics can help conclude whether call quality issues are due to network service provider or other influences.

Traditional PBX configuration file information can also be retrieved by the hardware device and the server. This information includes, caller-id details, programming state of PBX telephone extensions, restriction of outgoing calls per extension, class of service extensions (international and national), menu configuration of DECT terminals, changing of advanced ADSL settings, configuration of detailed WAN settings, management of PBX wifi network, activate/deactivate the diversions of a line, PBX re-start/reset options and internal/external S voice-mail settings. This information can be directly accessed by the remote server via the secure tunnel between the hardware device and the remote server. The server may be configured to interrogate the PBX itself via the hardware device using the programmed IP address in the Hardware device (rather than the hardware device doing the interrogation) to identify the manufacturer or model of the PBX or both. Knowing the make and model of the PBX allows the server to interact with the PBX correctly since the way in which data is retrieved from and loaded onto a PBX will vary based on manufacturer and model.

The arrangement of the server and hardware devices may also be used to provide a state of health for an operator's network. This state of health may be obtained by the server having a state of health module periodically (or on demand) sending ping messages to the PBX's through the hardware devices. The resulting measures for loss or round times may be aggregated to present average times for localities or otherwise to provide a measure of health of the system. In contrast, it will be appreciated that this would not normally be possible as routers/gateways may typically be configured for security reasons to ignore such ping requests. Accordingly, by installing hardware devices as described above on customers' sites, a health of the network measurement may be performed and monitored overtime. It will be appreciated that having such measurements may be used to more accurately identify problems with the network and to proactively identify failures or to potentially pre-empt failures.

For example, different states of health may be determined by the present system. Since, the system allows for the hardware device and PBX or other devices to be tested (using a ping or http), having results for comparison allows for example to clarify whether a PBX processor was running slow or whether it was the network or indeed the LAN.

In the foregoing specification, the application has been described with reference to specific examples of embodiments. It will, however, be evident that various modifications and changes may be made therein without departing from the broader spirit and scope of the invention as set forth in the appended claims. For example, the connections may be any type of connection suitable to transfer signals from or to the respective nodes, units or is devices, for example via intermediate devices. Accordingly, unless implied or stated otherwise the connections may for example be direct connections or indirect connections.

Because the apparatus implementing the present invention is, for the most part, composed of electronic components and circuits known to those skilled in the art, circuit details will not be explained in any greater extent than that considered necessary as illustrated above, for the understanding and appreciation of the underlying concepts of the present invention and in order not to obfuscate or distract from the teachings of the present invention.

Thus, it is to be understood that the architectures depicted herein are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In an abstract, but still definite sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality.

Furthermore, those skilled in the art will recognize that boundaries between the functionality of the above described operations merely illustrative. The functionality of multiple operations may be combined into a single operation, and/or the functionality of a single operation may be distributed in additional operations. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.

It will be appreciated that whilst the present application was directed to ameliorating the particular problems associated with remotely supporting PBX's that the system, method and hardware device or not so limited and that the method may be used to provide remote support for other communications (for example network switches or gateways) or computing devices or network enabled devices present behind a barrier on a local area network. It will be appreciated that where this is the case, that PBX specific functionality will not be required. However, other modifications, variations and alternatives are also possible.

The specifications and drawings are, accordingly, to be regarded in an illustrative rather than in a restrictive sense.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word comprising' does not exclude the presence of other elements or steps then those listed in a claim. Furthermore, the terms "a" or "an," as used herein, are defined as one or more than one. Also, the use of introductory phrases such as "at least S one" and "one or more" in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an." The same holds true for the use of definite articles. Unless stated otherwise, terms such as "first" and "second" are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

Claims 1. A method for providing remote support to a PBX connected on a local network at a site, the method comprising the connecting of a hardware device to the local network, S the hardware device then performing the steps of: making a connection with a predefined server outside of the local network; establishing a secure connection with the server; and providing a connection through the server by which a user on a separate computing device may connect through the established secure connection with the PBX.
2. The method of claim 1, wherein the hardware device is shipped pre-programmed with a server address to the site.
3. The method of claim 1, wherein the hardware device is programmed with a server address on-site.
4. The method of claim 2 or claim 3, wherein the server address comprises one of an IP addressorurl.
5. A method according to any preceding claim, wherein there is more than one predefined server and in the event that a connection may not be made with one of the servers, the method attempts each predefined server in turn until a successful connection has been made.
6. The method of any preceding claim, wherein the step of making a connection comprises the steps of the hardware device making an outbound connection to the server and transmitting identification data.
7. The method of claim 6, wherein the secure tunnel is maintained by the server sending keep-alive messages to the hardware device.
8. The method of claim 6 or claim 7, further comprising the hardware device checking whether the secure tunnel to the server has collapsed and upon finding that the secure tunnel has collapsed automatically re-initiating the connection.
9. The method of any one of claims 6 toS, wherein the step of establishing a secure connection comprises the authenticating the identification data and requesting a secure tunnel connection over the same outbound connection socket back to the hardware device so as to establish the secure tunnel.
10. The method of claim 9, wherein the identification data comprises the MAC address of the hardware device and step of authentication comprises comparing the MAC address with predefined MAC addresses stored at the server.
11. The method of claim 9 or 10, wherein the identification data is encrypted with a key at the hardware device and decrypted by a corresponding key at the server.
12. The method of claim 11, wherein the step of authentication comprises confirming the valid decryption of the identification data.
13. A method according to any preceding claim, wherein the hardware device is configured to only respond to commands from the server upon receipt of a valid username and password.
14. The method of any preceding claim, wherein the hardware device is pre-programmed with a customer ID.
15. The method of any preceding claim, wherein the hardware device is pre-programmed with the local network address of the PBX.
16. The method of any one of claims ito 14, wherein the local network address of the PBX is provided from the server to the hardware device after a secure connection has been established.
17. The method of claim 15 or claim 16, further comprising the step of the hardware device performing a test to confirm the presence of the PBX at the local network address.
18. A method according to any preceding claim, further comprising providing at the server a network address through which a computer may connect to and access the PBX through the secure connection.
19. A method according to any preceding claim, wherein the server provides secure tunnels to a plurality of different sites.
20. A method according to claim 19, wherein access to individual sites is restricted by the server to particular computing devices or users.
21. A method according to claim 19, wherein mapping information is maintained on the server and locally on the hardware device of each site, wherein the mapping information is used to translate the destination IP address to the local address of the PBX on the network.
22. A method according to any preceding claim further comprising the step of the hardware device downloading an update of PBX firmware to memory on the hardware device and subsequently uploading the PBX firmware onto the PBX.
23. A method according to any preceding claim, further comprising the step of the downloading data from the PBX.
24. A method according to claim 23, comprising analysing the data to detect a problem and sending a notification where a problem is detected.
25. A method according to claim 24, wherein the notification is to the server.
26. A method according to claim 24, wherein the notification comprises sending an email message.
27. A method according to claim 24, wherein the notification comprises sending an SMS message.
28. A method according to claim 24, further comprising the step of issuing a command to the PBX to halt the problem where a problem is detected.
29. A method according to claim 28, wherein the command issued may be one to reset the PBX.
30. A method according to claim 28, wherein the command issued may be one which prevents any outgoing calls from the PBX.
31. A method according to any one of claims 24 to 30, wherein the downloaded data comprises call statistics.
32. A method according to claim 31, wherein the detected problem is an abuse of the PBX and where said abuse is detected by analysing the call statistics for abnormal activity.
33. The method of claim 32, wherein abnormal activity may comprise detecting from the data calls made to at least one of predetermined countries or numbers.
34. The method of claim 32 or claim 33, where the abnormal activity may be detected by reference to detecting in the data when calls exceed the average usage by a predetermined threshold.
35. The method of any of claims 32 to 34, wherein the abnormal activity may be detected by reference to the time calls were made.
36. The method of any one of claims 23 to 35, wherein the step of downloading is performed by the hardware device.
37. The method of claim 36, wherein the subsequent steps to downloading are performed by the hardware device.
38. The method of any one of claims 23 to 35, wherein the step of downloading is performed by the server.
39. The method of claim 38, wherein the subsequent steps to downloading are performed by the server.
40. The method of any preceding claim, wherein the hardware device includes a RE circuit for establishing a connection to a mobile network and wherein a connection to the server through the mobile network is established where a connection through the local network fails.
41. A method according to any preceding claim, wherein the server supports a plurality of PBX devices on different networks and wherein mapping information is maintained at the server allowing a computer to access a PBX as if it was on the same network, wherein the server translates the local address into a destination S address and forwards the IP traffic from the computer to the intended PBX to be accessed.
42. A method according to any preceding claim wherein the server is configured to only permit access to individual PBX's by one or both of authorised computers and authorised users.
43. A method according to any preceding claim, further comprising the provision of a web interface on the hardware device through which a user may program the address of the PBX or other information.
44. A method according to claim 43, wherein a user on the local network may access the web interface using the IP address of the hardware device on the network.
45. The method of claim 44 wherein data concerning one or more PBXs may be set or amended on the hardware device by a local user on the network through the web interface.
46. A method according to claim 43, where a user may access the web interface through the secure connection.
47. The method of claim 46 wherein data concerning one or more PBXs may be set or amended on the hardware device by a user through the web interface accessed by a user through the secure connection.
48. The method of any preceding claim, further comprising the step on the server of recording the time connections are established through the server to users on separate computing devices.
49. The method of claim 48, wherein the recording of the time may include an identification of one or more of: a) the user on the separate computing device, b) the separate computing device, c) the hardware device, d) the customer associated with the PBX.
50. A method according to any preceding claim, wherein the hardware device collects S information from the PBX over time.
51. A method according to claim 50, wherein the information is aggregated for multiple customers to provide a network measurement for the telecommunications network or a part thereof.
52. A method according to claim 50 or claim 51, wherein the information collected comprises the number of IP trunks in use at a particular time by the PBX.
53. A method according to any one of claims 50 to 51, wherein the information collected is VOIP statistics from the PBX.
54. A method according to any preceding claim, further comprising the server performing a health check of the telecommunications network to which a plurality of hardware devices are attached providing connections between the server and a plurality of PBX's, the method comprising the server performing a network test, e.g. sending a ping or http request, to the a plurality of PBX's to determine a measure of the state of the telecommunications network.
55. A hardware device for facilitating remote support to a PBX, the hardware device comprising an Ethernet network interface for connecting to a local network on which a PBX may be connected, the hardware device being configured to attempt to make a connection through the local network to a predefined server outside of the local network and upon making a connection to establish a secure connection with the server and to act as a conduit for data between the server and the PBX.
56. The hardware device of claim 55, wherein the device is pre-programmed with a server address prior to packaging and shipping.
57. The hardware device of claim 55 or 56, wherein the device is pre-programmed with multiple server addresses and the device is configured to attempt to make connections in turn with the addresses until a successful connection has been made toa server.
58. The hardware device of any one of claims 55 to 57, wherein the hardware device further comprises a RF circuit for establishing a connection to a mobile network in the event that the hardware device cannot make a connection to the server through the network interface.
59. The hardware device of any one of claims 55 to 57, further comprising an indicator for indicating when a connection has been established to a local network and for further indicating when a secure connection has been established with the server.
60. The hardware device of claim 59, wherein the indicator comprises an LED.
61. The hardware device of claim 60, wherein the hardware device is configured to check whether the secure tunnel to the server has collapsed and upon finding that the secure tunnel has collapsed to automatically re-initiate the connection.
62. The hardware device of any one of claims 55 to 61, wherein the hardware device is pre-programmed with a customer ID.
63. The hardware device of any one of claims 55 to 62, wherein the hardware device is pre-programmed with the local network address of the PBX.
64. The hardware device of any one of claims 55 to 62, wherein the local network address of the PEX is provided from the server to the hardware device after a secure connection has been established.
65. The hardware device of claim 63 or claim 64, wherein the hardware device is configured to perform a test to confirm the presence of the PBX at the local network address.
66. The hardware device of any one of claims 55 to 65, wherein the hardware device comprises local memory and wherein the hardware device is configured to download updated PBX firmware to the local memory and thereafter to update the PBX firmware on the PBX with the updated PBX firmware.
67. The hardware device of any one of claims 55 to 66, wherein the hardware device is configured to retrieve data from the PBX.
68. The hardware device of claim 67, wherein the hardware device is configured to analyse the data for problems and to send a notification where a problem is detected.
69. The hardware device of claim 68, wherein the notification is an email message or SMS message.
70. The hardware device of claim 68 or claim 69, wherein the hardware device is configured to autonomously send commands to the PBX to halt the problem where a problem is detected.
71. The hardware device of claim 70, wherein the command may be one to reset the PBX or to prevent any outgoing calls from the PBX.
72. The hardware device of any one of claims 55 to 71, further comprising a web interface on the hardware device through which a user may program the address of the PBX or other information.
73. The hardware device of any one of claims 55 to 72, wherein the hardware device is configured to download a copy of the PBX software from the PBX and to upload the copy of the software to the server.