Load testing for IP PBX systems

Abstract

A method of load testing an IP PBX. The IP PBX is connected to a LAN, to which a registration simulator is also connected. The registration simulator is used to load the IP PBX with registrations. Actual phone calls are then made on the LAN, to determine whether the loading has adversely affected performance of the IP PBX. In this manner, the maximum CPU capacity of the IP PBX can be determined.

Description

TECHNICAL FIELD OF THE INVENTION

[0001] This invention relates to IP (Internet Protocol) telephony, and more particularly to testing IP PBX systems.

BACKGROUND OF THE INVENTION

[0002] PBX is short for private branch exchange, a private telephone network used within an enterprise. Users of a PBX share a certain number of outside lines for making telephone calls external to the PBX. Most medium-sized and larger companies use a PBX as a less expensive alternative to connecting an external telephone line to every telephone in the company. In addition, it's easier to call someone within a PBX because the number to dial is typically just 3 or 4 digits.

[0003] PBX architecture is undergoing an important transition from circuit-switched to packet-switched transmission and coding. The future of voice communications, using PBX systems, seems to be headed toward use of the Internet Protocol (IP).

[0004] While the design architectures of today's IP telephone systems are diverse, the basic concept is that an IP telephone works like a PC. It has a LAN card with a MAC address and an IP address. It communicates with an IP PBX via the IP protocol. Therefore, the IP PBX no longer tracks phone numbers to physical devices. As a result, a phone can be easily relocated to any functioning port without re-punching the line or changing the PBX port setting. Essentially, you can move phones from port to port like a PC, because the IP PBX no longer looks for the phone number at a physical location, it searches for the phone's IP address across the network. Phone numbers are encapsulated into an IP packet, transported across the network using the TCP/IP protocol and then de-encapsulated at the PBX.

[0005] VOIP (voice over Internet Protocol) is a technology devised to utilize existing IP infrastructures to carry voice. This can be accomplished by using intelligent phones that have both a MAC address (NIC card) and an IP address. A speaker's voice is encapsulated into an IP packet and transmitted to the PBX. This allows the phone to be identified by an IP address instead of a phone number. The reason behind this is so that like a computer, a phone can be relocated easily to any location without the need for patching or PBX reprogramming. Essentially, since the PBX now communicates to the phone using IP, it will know what phone number to send and receive voice information regardless of location.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 illustrates an IP PBX load testing system in accordance with the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0007] FIG. 1 illustrates a load testing system 10 in accordance with the invention. As explained below, system 10 provides a means for load testing the IP PBX 12. The load testing appropriately involves LAN resources, telephone resources, and CPU resources within the IP PBX 12, and operates in conjunction with other test equipment that is commercially available.

[0008] IP PBX 12 is the PBX being evaluated. As indicated in the Background, a traditional PBX is a proprietary telephone-switching system that resides within an enterprise network and connects internal telephone extensions to each other and to the public switched telephone network. Vendors program their PBX with applications'such as call hold, forwarding, and conference calling, and more complex call-center applications. Because traditional PBX technology is proprietary, customers usually have to ask their vendor to add new applications, and pay for the service. Similarly, traditional PBX vendors usually handle—and charge for—adding, moving, and changing telephone extensions. Eliminating these expenses for users by using open protocols is a benefit of IP PBX technology. As the name implies, IP PBX 12 delivers PBX-like services, but over IP-based LANs or WANs rather than circuit-switched networks. IP PBX systems can be designed as a single network server, a group of servers, or a network appliance. Despite widespread use of open protocols, no real standards have been agreed on for IP PBXs, so interoperability between IP systems, phones, and other devices, remains an issue.

[0009] In the example of this description, IP PBX 12 operates over a LAN 14 and is designed as a single network server. However, as indicated in the preceding paragraph, other configurations are possible and are compatible with the invention described herein.

[0010] Phone sets 13 are compatible with IP PBX 12. Phone sets 13 are “intelligent” phone sets, i.e., computers, that communicate across a LAN 14, using a predetermined protocol, which may vary depending on the manufacturer of IP PBX 12. Other types of endpoints may also be connected to LAN 14, such as analog telephones or PCs with a telephone application installed.

[0011] One task of phone sets 13 is to “register” with a call processor. Because the phone is assigned an IP address, the LAN automatically reads the address. An IP number is analogous to a telephone number; it uniquely identifies a machine, but it does not identify a user.

[0012] Registration simulator 15 consists of software components that communicate with IP PBX 12 using the protocols native to IP PBX 12. As explained below, simulator 15 eliminates the need to use actual phone sets for loading IP PBX 12, by performing simulated connections and registrations with IP PBX 12. Simulator 15 need not make place or receive actual phone calls.

[0013] Protocol analyzer 16 monitors activity on the LAN 14 and verifies protocols in use on the LAN 14. An example of a suitable protocol analyzer 16 is the Internet Advisor, manufactured by Agilent Corporation.

[0014] Data traffic generator 17 loads LAN 14 with simulated data flows. An example of a suitable traffic generator 17 is the Smartbits traffic generator manufactured by Spirent Communications.

[0015] Gateway 18 permits IP PBX 12 to communicate with the public switched telephone network (PSTN) 19.

[0016] Voice traffic generator 20 generates voice traffic flows, the same type of traffic as would be created by actual users. Voice traffic generator 20 may also include testing features, such as for connection testing and DTMF testing. Voice traffic generator 20 may also test and report the quality of service for both voice and DTMF signals. An example of a suitable voice traffic generator 20 is the Hammer VOIP Test System, manufactured by Empirex.

[0017] Cell towers 21 represent communication links to cell phone systems. This permits end to end quality of service testing for wireless as well as wire line networks.

[0018] Phone set 22 represents one or more conventional phone sets that may be connected to PSTN 20.

[0019] In operation, simulator 17 registers a given number of simulated telephones with IP PBX 12. Each registration uses memory resources of IP PBX 12. The registration may include providing a unique Media Access Control (MAC) address, a unique IP address, and the type of phone set being simulated. The number of telephone sets and MAC addresses that are registered are tracked. It can then be determined whether the claimed capacity of IP PBX, especially in terms of its memory resources, matches the number actually supported by IP PBX 12.

[0020] Data files containing MAC and IP addresses and telephone types may be developed and re-used. This permits different runs of simulator 15 to produce consistent sets of results in terms of numbers of telephone sets and MAC addresses that can be supported by IP PBX 12.

[0021] While IP PBX 12 is loaded with simulated registrations, phone sets 11 are used to make real telephone calls. Successful call placement indicates the IP PBX 12 has an actual loading capacity equivalent to the simulated loading. Specifically, the CPU capability of IP PBX 12 may be determined by determining the maximum registrations that it may achieve while still handling new calls.

[0022] Additional functions of simulator 15 include providing signaling to convince IP PBX 12 that simulator 15 is an authorized telephone set type. It may also be programmed to respond to “keep alive” polling requests from IP PBX 12. Simulator 15 may further be programmed to de-register with IP PBX 12 when simulator 15 ends execution.

[0023] For further testing system 10 while IP PBX 12 is loaded with simulated registrations, LAN 14 may be loaded with data traffic. For this purpose, data and voice traffic may be generated using data traffic generator 17 and voice traffic generator 20. Gateway 18 is used in conventional manner so as to permit the LAN 14 and the voice network 19 to communicate. At this point, IP PBX 12 can be examined to determine whether it is properly handling the traffic.

[0024] During the network loading, protocol analyzer 16 may be used as an observation tool. It verifies that IP PBX is using the appropriate protocols.

Claims

1. A method of load testing an IP PBX, comprising the steps of: connecting a simulator process to the IP PBX; using the simulator process to perform registrations with the IP PBX, the registrations requesting at least a MAC address, an IP address, and a type of telephone; using the simulator process to provide signaling to the IP PBX representing data representing authorization for a telephone; using the simulator process to respond to keep alive polling requests from the IP PBX; and using the simulator process to de-register with the IP PBX.

2. A method of load testing an IP PBX, comprising the steps of: connecting a simulator process to the IP PBX; and using the simulator process to perform registrations with the IP PBX.

3. The method of claim 2, wherein the simulator process is performed by requesting at least a MAC address.

4. The method of claim 2, wherein the simulator process is performed by requesting at least an IP address.

5. The method of claim 2, wherein the simulator process is performed by providing data representing a type of telephone.

6. The method of claim 2, further comprising the step of using the simulator process to provide signaling to the IP PBX representing data representing authorization for a telephone.

7. The method of claim 2, further comprising the step of using the simulator process to respond to keep alive polling requests from the IP PBX.

8. The method of claim 2, further comprising the step of using the simulator process to de-register with the IP PBX.

9. The method of claim 2, further comprising the steps of connecting the IP PBX and the simulator on a LAN and of generating data traffic on the LAN.

10. The method of claim 2, wherein the IP PBX and the simulator are connected on a LAN and further comprising the steps of using a gateway to connect the LAN to a voice network and of generating voice traffic on the voice network.