Abstract:
A device includes a Session Initiation Protocol (SIP) phone, an audio interface for receiving or transmitting audio information with the SIP phone to test a SIP-based network, and a controller for controlling the SIP phone and the audio interface.

Description:
BACKGROUND INFORMATION 
       [0001]    Session Initiation Protocol (SIP) is an application-layer control (i.e., signaling) protocol for creating, modifying, and terminating sessions with one or more users. These sessions may include Internet-based telephone calls, multimedia distribution, multimedia conferences, instant messaging conferences, interactive voice response (IVR), automated and manual operator services, automatic call distribution, call routing, etc. SIP invitations or SIP INVITE requests may be used to create sessions and may carry session descriptions that allow participants to agree on a set of compatible media types. SIP may use proxy servers to help route requests to a user&#39;s current location, authenticate and authorize users for services, implement provider call-routing policies, and/or provide other features to users. SIP may also provide a registration function that allows users to upload their current locations for use by proxy servers. 
         [0002]    Testing of SIP-based systems typically is a manual and time consuming task. For example, a SIP device (e.g., a SIP telephone) may be a computer-based device that participates in call processing within a SIP-based network. Unlike conventional telephones which may be emulated during testing of network functions, SIP telephones fail to provide such emulation. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0003]      FIG. 1  depicts an exemplary network in which systems and methods described herein may be implemented; 
           [0004]      FIG. 2  depicts an exemplary device, client or server, configured to communicate via the exemplary network of  FIG. 1 ; 
           [0005]      FIG. 3  is an exemplary functional diagram of an automated SIP device of the exemplary network shown in  FIG. 1 ; 
           [0006]      FIG. 4  is an exemplary functional diagram of a handset control server of the exemplary network shown in  FIG. 1 ; 
           [0007]      FIG. 5  depicts another exemplary network in which systems and methods described herein may be implemented; 
           [0008]      FIG. 6  is a flowchart of an exemplary process capable of being performed by the automated SIP device shown in  FIG. 3 ; and 
           [0009]      FIGS. 7 and 8  are flowcharts of exemplary processes capable of being performed by the handset control server shown in  FIG. 4 . 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0010]    The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. 
         [0011]    Implementations described herein may provide systems and methods that use an automated SIP device (ASD) to permit functional testing of a SIP-based network and/or devices within the SIP-based network with minimal manual input. The systems and methods may implement the ASD within an interactive testing platform (ITP) system that may test the performance of the SIP-based network. The ITP system may include a handset control server that may provide specific control of the ASD and may enable ASD to be used in the larger ITP system. 
         [0012]      FIG. 1  is a diagram of an exemplary network  100  in which systems and methods described herein may be implemented. Network  100  may include automated SIP devices (ASDs)  110  connected to multiple servers (e.g., a SIP server  120 , a voice server  130 , and a handset control server  140 ) via a network  150 . Network  150  may include a local area network (LAN), a wide area network (WAN), a telephone network, such as the Public Switched Telephone Network (PSTN), an intranet, the Internet, or a combination of networks. 
         [0013]    ASDs  110  and servers  120 - 140  may connect to network  150  via wired, wireless, and/or optical connections. Two ASDs  110  and three servers  120 - 140  have been illustrated as connected to network  150  for simplicity. In practice, there may be more or fewer ASDs and servers. Also, in some instances, an ASD may perform one or more functions of a server and/or a server may perform one or more functions of an ASD. 
         [0014]    ASDs  110  may include a device, such as a personal computer, a SIP telephone, a wireless telephone, a personal digital assistant (PDA), a laptop, or another type of computation or communication device, a thread or process running on one of these devices, and/or an object executable by one of these devices. Additional details of ASDs  110  are provided below in connection with  FIG. 3 . 
         [0015]    SIP server  120 , also commonly referred to as a network server, may include a device that facilitates the establishment of SIP calls. A “SIP call,” as the term is used herein, is to be broadly interpreted to include any out-of-dialog or dialog-establishing SIP method (e.g., a SIP INVITE request, a SIP SUBSCRIBE request, a SIP REFER request, a SIP OPTIONS request, a SIP MESSAGE request, a SIP REGISTER request, etc.). SIP server  120  may act as both a server and a client for the purpose of making requests on behalf of other clients. Requests may be serviced internally or by passing them on, possibly after translation, to other servers. SIP server  120  may interpret, and, if necessary, rewrite a request message before forwarding it. 
         [0016]    Voice server  130  may include server entities that are capable of facilitating SIP-based communications, e.g., Internet-based telephone calls, multimedia distribution, multimedia conferences, instant messaging conferences, interactive voice response (IVR), automated and manual operator services, automatic call distribution, call routing, etc. Voice server  130  may include T1, E1, and/or International Telecommunication Union (ITU) Signaling System 7 (SS7) interface cards that may facilitate in-band, Primary Rate Interface (PRI), and/or SS7 signaling methods. 
         [0017]    Handset control server  140  may include server entities that may provide control of ASDs  110  and may enable ASDs  110  to be implemented in an ITP system. For example, handset control server  140  may enable ASDs  110  to be named in a human readable format, may map physical port locations of ASDs  110  for communications, may translate testing script commands (e.g., provided by the ITP system) into specific communications provided by ASDs  110 , etc. Additional details of handset control server  140  are provided below in connection with  FIG. 4 . 
         [0018]    Although  FIG. 1  shows exemplary components of network  100 , in other implementations, network  100  may contain fewer or additional components that may permit network testing. In still other implementations, one or more components of network  100  may perform the tasks performed by other components of network  100 . In one implementation, for example, network  100  may include the features set forth in co-pending application Ser. No. ______ (Attorney Docket No. 20060152), entitled “AUTOMATED TELETYPE (TTY) TESTING,” filed on the same date herewith, the disclosure of which is incorporated by reference herein in its entirety. 
         [0019]    While servers  120 - 140  are shown as separate entities, it may be possible for one or more of servers  120 - 140  to perform one or more of the functions of another one or more of servers  120 - 140 . For example, it may be possible that two or more of servers  120 - 140  are implemented as a single server. It may also be possible for a single one of servers  120 - 140  to be implemented as two or more separate (and possibly distributed) devices. 
         [0020]    Although implementations are described below in the context of SIP and an Internet Protocol (IP)-based network, in other implementations equivalent or analogous communication protocols (e.g., ITU H.323, ITU SS7, integrated services digital network (ISDN), in-band, etc.) and/or types of transport networks (e.g., asynchronous transfer mode (ATM), frame relay, etc.) may be used. Both the ITU H.323 standard and the IETF&#39;s SIP are examples of protocols that may be used for establishing a communications session among terminals, such as ASDs  110 , connected to a network. Although SIP-type messages are shown for convenience, any type of protocol or a mixture of such protocols may be applied in various parts of the overall system. 
         [0021]      FIG. 2  is an exemplary diagram of a client or server entity (hereinafter called “client/server entity”), which may correspond to one or more of ASDs  110  and servers  120 - 140 . The client/server entity may include a bus  210 , a processor  220 , a main memory  230 , a read only memory (ROM)  240 , a storage device  250 , an input device  260 , an output device  270 , and a communication interface  280 . Bus  210  may include a path that permits communication among the elements of the client/server entity. 
         [0022]    Processor  220  may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Main memory  230  may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor  220 . ROM  240  may include a ROM device or another type of static storage device that may store static information and instructions for use by processor  220 . Storage device  250  may include a magnetic and/or optical recording medium and its corresponding drive. 
         [0023]    Input device  260  may include a mechanism that permits an operator to input information into the client/server entity, such as a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, etc. Output device  270  may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface  280  may include any transceiver-like mechanism that enables the client/server entity to communicate with other devices and/or systems. For example, communication interface  280  may include mechanisms for communicating with another device or system via a network, such as network  150 . 
         [0024]    As will be described in detail below, the client/server entity may perform certain operations. The client/server entity may perform these operations in response to processor  220  executing software instructions contained in a computer-readable medium, such as memory  230 . A computer-readable medium may be defined as a physical or logical memory device and/or carrier wave. 
         [0025]    The software instructions may be read into memory  230  from another computer-readable medium, such as data storage device  250 , or from another device via communication interface  280 . The software instructions contained in memory  230  may cause processor  220  to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. 
         [0026]    Although  FIG. 2  shows exemplary components of the client/server entity, in other implementations, the client/server entity may contain fewer or additional components. In still other implementations, one or more components of the client/server entity may perform the tasks performed by other components of the client/server entity. 
         [0027]      FIG. 3  is an exemplary functional diagram of a single ASD  110  of exemplary network  100 . As shown, ASD  110  may include a variety of components, including, e.g., a controller  300 , a relay interface  310 , an audio interface  320 , a ring detector  330 , a SIP telephone or SIP phone  340 , a communication interface  350 , etc. Controller  300  may correspond to processor  220  and may perform functions similar to the functions performed by processor  220 . For example, controller  300  may enable communications for ASD  110  (e.g., via communication interface  350 ), may activate and/or deactivate relays of relay interface  310  per instructions received by ASD  110 , may monitor ring detector  330  for ringing events, call waiting events, message waiting indicator events, etc. 
         [0028]    Relay interface  310  may be controlled by controller  300  and may be connected to a number keypad, function keys, a hook switch, and/or a power supply of SIP phone  340 . Relay interface  310  may perform a variety of tasks. For example, relay interface  310  may include a series of relays that may be activated and/or deactivated based on instructions received by, e.g., controller  300 , may disconnect SIP phone  340  (i.e., take SIP phone  340  off the hook), may dial telephone numbers of varying lengths via SIP phone  340  (e.g., emulating human action), press function keys, etc. In other implementations, an on/off duration of relay interface  310  may be controlled to specify, e.g., a duration of a dual-tone multi-frequency (DTMF) digit. In still other implementations, relay interface  310  may control the power supplied to SIP phone  340  in order to reset SIP phone  340  and to cause SIP phone  340  to receive new configuration information. 
         [0029]    Audio interface  320  may replace a handset of SIP phone  340  and may provide electrical conversion of information (e.g., audio information) received and/or transmitted by SIP phone  340 . For example, in one implementation, audio interface  320  may include a speaker interface  321  that receives audio information from SIP phone  340 , and may further include a transmitter  322  that converts the audio information from speaker interface  321  into electrical signals (e.g., representative of the audio information) and outputs the electrical signals for measurement or testing. In another implementation, audio interface  320  may include a receiver  323  that receives electrical signals representative of audio information, and may further include a microphone interface  324  that converts the electrical signals from receiver  323  into audio information, and outputs the audio information via SIP phone  340 . Audio interface  320  may permit adjustment of outputs by transmitter  322  and receiver  323 . 
         [0030]    Although  FIG. 3  shows audio interface  320  replacing the handset of SIP phone  340 , in other implementations, for example, the handset of SIP phone  340  may perform the functions of audio interface  320 . In other implementations, speaker interface  321  may be combined with transmitter  322  into a single transmitter entity, and microphone interface  324  may be combined with receiver  323  into a single receiver entity. 
         [0031]    Ring detector  330  may monitor a ringing event for SIP phone  340 . If a ringing event occurs for SIP phone  340 , ring detector  330  may provide this information to controller  300  and controller  300  may notify devices external to ASD  110 , via communication interface  350 , of the ringing event. Ring detector  330  may connect to a speaker provided within SIP phone  340  or audio interface  320 , and may monitor the audible ringing provided by the speaker of SIP phone  340  or audio interface  320  for a predetermined ring frequency. Ring detector  330  may permit adjustment of the predetermined ring frequency. Similar functions may be performed to monitor for call waiting and/or message waiting indicator events. For example, a light-emitting diode (not shown) may be monitored for the presence of energy to determine if a message waiting indicator event has occurred. 
         [0032]    SIP phone  340  may include a device capable of providing SIP-based communications, such as a telephone, a wireless telephone, a personal digital assistant (PDA), or another type of computation or communication device, a thread or process running on one of these devices, and/or an object executable by one of these devices. As described above, SIP phone  340  may include a number keypad, function keys, a hook switch, a power supply, a speaker, and/or a microphone. 
         [0033]    Communication interface  350  may correspond to communication interface  280  and may perform functions similar to the functions performed by communication interface  280 . For example, communication interface  350  may include any transceiver-like mechanism that enables ASD  110  to communicate with another device or system via a network, such as network  150 . 
         [0034]    Although  FIG. 3  shows exemplary components of ASD  110 , in other implementations ASD  110  may contain fewer or additional components that may permit automated testing by ASD  110 . In still other implementations, one or more components of ASD  110  may perform the tasks performed by other components of ASD  110 . 
         [0035]    An ITP system may include several servers that may interoperate in the execution of testing a SIP-based system (e.g., a script server that may create script, a script execution server that may execute script, voice server  140 , etc.). In one implementation, for example, the ITP system may include the features set forth in co-pending application Ser. No. ______ (Attorney Docket No. 20060153), entitled “AUTOMATED AUDIO STREAM TESTING,” filed on the same date herewith, the disclosure of which is incorporated by reference herein in its entirety. In another implementation, the ITP system may include the features set forth in co-pending application Ser. No. ______ (Attorney Docket No. 20060154), entitled “DISTRIBUTED VOICE QUALITY TESTING,” filed on the same date herewith, the disclosure of which is incorporated by reference herein in its entirety. 
         [0036]      FIG. 4  is an exemplary functional diagram of one such server of the ITP system, i.e., handset control server  140  of exemplary network  100 . Generally, handset control server  140  may control ASDs  110 , may enable ASDs  110  to be used in the ITP system, may enable ASDs  110  to be named in a human readable format, may map IP address and port locations of ASDs  110 , and/or may translate script commands (e.g., Visual Basic style script commands) into ASD  110  specific communications. As shown, handset control server  140  may include a variety of components. For example, handset control server  140  may include a script translator  410 , a database  420 , an ASD controller  430 , an event monitor  440 , etc. 
         [0037]    Script translator  410  may receive a script command(s)  400  from the ITP system, and may translate script command(s)  400  into information capable of being understood by ASDs  110 . Script command(s)  400  may include commands for the creation of test cases for the SIP-based network, e.g., network  100 . Script command(s)  400  may also define which physical devices of the SIP-based network may be used, and may assign names to the physical devices. For example, script command(s)  400  may include test commands such as “OffHook” (which may cause the hook-switch of SIP phone  340  to be activated, resulting in a dial tone), “Presskeys” (which may indicate a phone number, e.g., of one ASD  110 , to dial), etc. 
         [0038]    Script translator  410  may utilize database  420  to aid in the translation of script command(s)  400 . In one implementation, database  420  may correspond to main memory  230 , ROM  240 , storage device  250 , or combinations of the aforementioned (see  FIG. 2 ). In another implementation, database  420  may be external to handset control server  140  and may be accessed via, e.g., communication interface  280 . Database  420  may provide information enabling devices of the SIP-based system to reference specific IP address/port combinations for communication with specific ASDs  110  being used. Database  420  may also provide a reference to voice server  130  and/or a channel bank associated with a particular ASD. 
         [0039]    ASD controller  430  may utilize the translated script command(s) to provide ASD information  450  to ASDs  110 . For example, ASD controller  430  may map desired keystrokes to relays of relay interface  310  of ASD  110 , and may repeat this function for each keystroke that needs to be activated (e.g., keystrokes for dialing a telephone number). In one example, to activate a single relay (e.g., “K3”) of ASD  110  for “125” milliseconds (ms), ASD controller  430  may provide the following information: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 Unsigned char array( ) 
               
               
                 Array(0) = 0x02;  // ASCII start of text 
               
               
                 Array(1) = 0x31;  // unit address 1 
               
               
                 Array(2) = 0x33;  // relay number K3 
               
               
                 Array(3) = 0x95;  // Timed command to turn relay on for xxxxx ms. 
               
               
                 Array(4) = 0x35;  // 5 ones - 5 ms 
               
               
                 Array(5) = 0x32;  // 2 tens 
               
               
                 Array(6) = 0x31;  // 1 hundreds 
               
               
                 Array(7) = 0x30;  // 0 thousands 
               
               
                 Array(8) = 0x30;  // 0 ten thousands 
               
               
                 Array(9) = 0x0d;  // ASCII carriage return 
               
               
                 Send array to microcontroller, Array(0) first. 
               
               
                   
               
             
          
         
       
     
         [0040]    Event monitor  440  may monitor for incoming event(s)  460  (e.g., a “Ring Detected” or ringing event) from ASDs  110 , and may report event(s)  460  to the ITP system to enable interaction with the ITP scripting commands. 
         [0041]    ASD controller  430  and/or event monitor  440  may permit handset control server  140  to communicate with ASDs  110  in a variety of ways. For example, in one implementation, handset control server  140  may include an Ethernet interface for communicating directly with ASDs  110 . In another implementation, handset control server  140  may communicate directly with ASDs  110  using Transmission Control Protocol/Internet Protocol (TCP/IP). In still another implementation, handset control server  140  may communicate, via a terminal server, with ASDs  110  using TCP/IP. The terminal server may convert communications from TCP/IP into a serial interface (e.g., a “9600” baud rate serial interface). The terminal server may enable configuration of several serial devices and/or may enable TCP/IP communications with such devices via an IP address and a port number. Database  420  may map each ASD  110  to a TCP/IP address and port, which may enable handset control server  140  to communicate with several ASDs  110  by addressing ASDs  110  on the network (e.g., network  100 ). 
         [0042]    Although  FIG. 4  shows exemplary components of handset control server  140 , in other implementations, handset control server  140  may contain fewer or additional components that may permit control and monitoring of ASDs  110 . In still other implementations, one or more components of handset control server  140  may perform the tasks performed by other components of handset control server  140 . 
         [0043]      FIG. 5  depicts an exemplary network  500  in which systems and methods described herein may be implemented. As shown, network  500  may include an originating ASD (ASD/ORIG)  110  and a terminating ASD (ASD/TERM)  110  connected to multiple servers (e.g., SIP server  120 , voice servers  130 , and handset control server  140 ) via network  150 . A first local area network (LAN)  510  may connect ASD/ORIG  110  to network  150  via a network device  530 , and a second local area network (LAN)  520  may connect ASD/TERM  110  to network  150  via network device  530 . LANs  510  and  520  may connect other devices (e.g., SIP phones  540 , other ASDs  110 , etc.) to network  150  via network devices  530 . 
         [0044]    Network devices  530  may include data transfer devices, such as gateways, routers, switches, firewalls, bridges, proxy servers, or some other type of device that processes and/or transfers data. In one implementation, network devices  530  may operate on data on behalf of a network, such as network  150 . For example, network devices  530  may receive all, or substantially all, data destined for network  150  and/or transmitted by network  150 . 
         [0045]    ASD/ORIG  110  and ASD/TERM  110  may connect to handset control server  140  via terminal server  550 . ASD/ORIG  110  and ASD/TERM  110  may connect to voice server  130  via channel bank  560 . Handset control server  140  may communicate, via terminal server  550 , with ASDs (ORIG and TERM)  110  using TCP/IP. Terminal server  550  may convert communications from TCP/IP into a serial interface (e.g., a “9600” baud rate serial interface). Terminal server  550  may enable configuration of several serial devices and/or may enable TCP/IP communications with such devices via an IP address and a port number. 
         [0046]    Channel bank  560  may include a device that multiplexes a group of channels into a higher bit-rate digital channel and/or demultiplexes these aggregates back into individual channels. For example, channel bank  560  may change analog voice and data signals into a digital format. Channel bank  560  may be called a “bank” because it may convert a bank of a predetermined number (e.g., “24”) of individual channels into a digital format, and then back to analog again. The predetermined number of channels may make up a “T1” circuit. In another implementation, channel bank  560  may multiplex a group of channels into a higher bandwidth analog channel. For example, channel bank  560  may convert voice signals from voice server  130  into analog signals. In still another implementation, channel bank  560  may enable adjustment of the transmit and receive levels of audio interfaces  320  of ASDs  110 . 
         [0047]    As further shown in  FIG. 5 , a voice path  570  may be provided in an exemplary test. The test shown in  FIG. 5 , for example, may originate a call from ASD/ORIG  110  (e.g., controller  300  of ASD/ORIG  110  may originate the call). The test call may be established, a tone may be sent by voice server  130  through ASD/ORIG  110 , and the tone may be received by ASD/TERM  110  and verified by voice server  130 . The devices and logic within network  500  may be configured to route a telephone number (e.g., “9727282583”) to ASD/TERM  110 . In  FIG. 5 , the ITP system may include ASD/ORIG  110 , ASD/TERM  110 , voice server  130  (upper left of  FIG. 5 ), channel bank  560 , terminal server  550 , and handset control server  140 . The remaining devices of  FIG. 5  may constitute the SIP-based system being tested. 
         [0048]    A script (e.g., script command(s)  400 ) may define the physical devices of network  500  to be used for conducting the test. For example, the script may define ASD/ORIG  110  as an originating ASD, and may define ASD/TERM  110  as a terminating ASD. A database within the ITP system (e.g., database  420 ) may enable the ITP system to reference specific IP address/port combinations to communicate with the specific ASDs being used. The database may also provide a reference to voice server  130  (upper left of  FIG. 5 ) and channel bank  560 . 
         [0049]    ASD/ORIG  110  may be activated, and the ITP system (e.g., voice server  130  in cooperation with handset control server  140 ) may verify that SIP phone  340  of ASD/ORIG  110  is providing a dial tone via audio interface  320 , and channel bank  560 . The telephone number for ASD/TERM  110  may be entered on ASD/ORIG  110  (e.g., controller  300  may dial the telephone number on SIP phone  340  via relay interface  310 ). The ITP system (e.g., handset control server  140 ) may monitor ASD/TERM  110  for a ringing event. If a ringing event is detected, the ITP system (e.g., handset control server  140 ) may pause for a predetermined time (e.g., several seconds to simulate a ringing cycle in a real telephone) and may activate the hook-switch of ASD/TERM  110  (e.g., controller  300  may activate the hook-switch of relay interface  310  which may cause SIP phone  340  to receive the call) to answer the call. 
         [0050]    The ITP system (e.g., voice server  130  in cooperation with handset control server  140 ) may cause a tone of a predetermined frequency (e.g., “1025” Hertz) to be generated on a particular T1 and channel associated with ASD/ORIG  110  (e.g., controller  300 , via communications with voice server  130 , may cause voice server  130  to generate the tone via channel bank  560  and audio interface  320 ). The ITP system (e.g., voice server  130  in cooperation with handset control server  140 ) may detect the presence of the tone via ASD/TERM  110  (e.g., controller  300 , via communications with voice server  130 , may cause voice server  130  to detect the tone via audio interface  320  and channel bank  560 ). 
         [0051]    In one implementation, the tone may be generated using pulse code modulation (PCM) on a T1 interface of voice server  130  corresponding to ASD/ORIG  110 . Channel bank  560  may convert the PCM tone into an analog tone, and may enable transmit and receive levels of the tone to be adjusted. The analog tone may be provided via audio interface  320  of ASD/ORIG  110 . The tone received by audio interface  320  may be adjusted to a level that emulates the level received by a human voice driving a microphone. The tone may be received by SIP phone  340  of ASD/ORIG  110  in a manner similar to the manner a human voice is received by a handset of a SIP phone. A SIP phone, in normal operation, may provide SIP signaling to a network and may convert audio signals to Real Time Protocol (RTP) packets. In  FIG. 5 , after SIP signaling establishes the call, the tone may be transferred from ASD/ORIG  110  to ASD/TERM  110 , via RTP packets, across network  150  (e.g., via LANs  510  and  520 , and network devices  530 ). ASD/TERM  110  may receive the RTP packets and may convert the RTP packets into analog audio signals. ASD/TERM  110  may adjust the level of the audio signals (e.g., the tone) and may transmit the audio signals to speaker interface  321  of ASD/TERM  110 . Speaker interface  321  of ASD/TERM  110  may transmit the audio signals to channel bank  560 , and channel bank  560  may encode the audio signals as PCM. Channel bank  560  may send the encoded audio signals to voice server  130  (upper left of  FIG. 5 ) where measurement and other testing functions may be performed. 
         [0052]    In another implementation, ASD/TERM  110  may provide an adjustable tone to ASD/ORIG  110  in a manner similar to the manner ASD/ORIG  110  provides an adjustable tone to ASD/TERM  110 , as described above. Voice server  130  (upper left of  FIG. 5 ) may perform measurements and other testing functions on the tone generated by ASD/TERM  110 . 
         [0053]    Although  FIG. 5  shows one test performed by the ITP system, in other implementations, additional or different tests may be performed by the ITP system. For example, the ITP system may be used to verify tones in both directions between ASD/ORIG  110  and ASD/TERM  110 , and to provide perceptual speech quality measure (PSQM) voice quality testing of voice path  570 . In another example, the ITP system may provide interfaces to a network (e.g., network  150 ) using protocols such as in-band, ISDN, and SS7. The ITP system may support testing from an ASD to or from such protocols. In still another example, the ITP system may support SIP testing directly from IP resources on an IP network. Rather than using an actual SIP phone, the ITP system may emulate SIP messaging and an RTP voice path. This may make it possible to create tests where the protocol may be non-conforming or corrupt. Such testing may help determine systems error trapping abilities. In a further example, ASDs  110  may originate and/or terminate SIP based calls directly to a SIP server (e.g., SIP server  120 ). 
         [0054]    Although  FIG. 5  shows exemplary components of network  500 , in other implementations, network  500  may contain fewer or additional components that may permit network testing. In still other implementations, one or more components of network  500  may perform the tasks performed by other components of network  500 . 
         [0055]      FIG. 6  is a flowchart of an exemplary process  600  capable of being performed by ASD  110 . As shown, process  600  may enable communications between an ASD and a SIP-based network for the purposes of testing the network (block  610 ). For example, in one implementation described above in connection with  FIG. 3 , controller  300  may enable communications for ASD  110  (e.g., via communication interface  350 ). 
         [0056]    Process  600  may activate and/or deactivate relays based on the communications (block  620 ). For example, in one implementation described above in connection with  FIG. 3 , relay interface  310  of ASD  110  may be controlled by controller  300  and may be connected to a number keypad, function keys, a hook switch, and/or a power supply of SIP phone  340 . Relay interface  310  may include a series of relays that may be activated and/or deactivated based on instructions received by, e.g., controller  300 , may disconnect SIP phone  340  (i.e., take SIP phone  340  off the hook), may dial telephone numbers of varying lengths via SIP phone  340  (e.g., emulating human action), etc. In another example, relay interface  310  may control the power supplied to SIP phone  340  in order to reset SIP phone  340  and to cause SIP phone  340  to receive new configuration information. 
         [0057]    As further shown in  FIG. 6 , process  600  may receive and/or transmit audio information (block  630 ). For example, in one implementation described above in connection with  FIG. 3 , audio interface  320  of ASD  110  may provide electrical conversion of information (e.g., audio information) received and/or transmitted by SIP phone  340 . Audio interface  320  may include speaker interface  321  that receives audio information from SIP phone  340 , and may further include transmitter  322  that converts the audio information from speaker interface  321  into electrical signals (e.g., representative of the audio information) and outputs the electrical signals. Audio interface  320  may include receiver  323  that receives electrical signals representative of audio information, and may further include microphone interface  324  that converts the electrical signals from receiver  323  and outputs audio information via SIP phone  340 . 
         [0058]    Process  600  may monitor a ringing event (block  640 ). For example, in one implementation described above in connection with  FIG. 3 , ring detector  330  of ASD  110  may monitor a ringing event for SIP phone  340 . Ring detector  330  may connect to a speaker provided within SIP phone  340  or audio interface  320 , and may monitor the audible ringing provided by the speaker of SIP phone  340  or audio interface  320  for a predetermined ring frequency. Ring detector  330  may permit adjustment of the predetermined ring frequency. 
         [0059]    As further shown in  FIG. 6 , process  600  may provide notification if a ringing event occurs (block  650 ). For example, in one implementation described above in connection with  FIG. 3 , if a ringing event occurs for SIP phone  340 , ring detector  330  may provide the information to controller  300  and controller  300  may notify devices external to ASD  110 , via communication interface  350 , of the ringing event. 
         [0060]      FIG. 7  is a flowchart of an exemplary process  700  capable of being performed by handset control server  140 . As shown, process  700  may translate script into ASD specific communications (block  710 ). For example, in one implementation described above in connection with  FIG. 4 , script translator  410  may receive a script command(s)  400  from the ITP system, and may translate script command(s)  400  into information capable of being understood by ASDs  110 . Script command(s)  400  may include commands for the creation of test cases for the SIP-based network, e.g., network  100 . Script command(s)  400  may also define which physical devices of the SIP-based network may be used, and may assign names to the physical devices. For example, script command(s)  400  may include test commands such as “OffHook” (which may cause the operation of the hook-switch of ASD  110 , resulting in a dial tone), “Presskeys” (which may indicate a phone number, e.g., of one ASD  110 , to dial), etc. 
         [0061]    As further shown in  FIG. 7 , process  700  may map IP address and port locations of an ASD based on the translated script (block  720 ). For example, in one implementation described above in connection with  FIG. 4 , script translator  410  may utilize database  420  to aid in the translation of script command(s)  400 . Database  420  may provide information enabling devices of the SIP-based system (e.g., handset control server  140 ) to reference specific IP address/port combinations for communication with specific ASDs  110  being used. Database  420  may also provide a reference to voice server  130  and/or a channel bank associated with voice server  130 . 
         [0062]    Process  700  may control an ASD(s) based on the mapped IP address and port locations and the script (block  730 ). For example, in one implementation described above in connection with  FIG. 4 , ASD controller  430  may utilize the translated script command(s) to provide ASD information  450  to ASDs  110 . For example, ASD controller  430  may map desired keystrokes to relays of relay interface  310  of ASD  110 , and may repeat this function for each keystroke that needs to be activated (e.g., keystrokes for dialing a telephone number). 
         [0063]    As further shown in  FIG. 7 , process  700  may monitor an event(s) from an ASD(s) (block  740 ). For example, in one implementation described above in connection with  FIG. 4 , event monitor  440  may monitor for incoming event(s)  460  (e.g., a “Ring Detected” or ringing event) from ASDs  110 , and may report event(s)  460  to the ITP system to enable interaction with the ITP scripting commands. 
         [0064]      FIG. 8  is a flowchart of another exemplary process  800  capable of being performed by handset control server  140 . As shown, process  800  may define originating and terminating ASDs (block  810 ). For example, in one implementation described above in connection with  FIG. 5 , a script (e.g., script command(s)  400 ) may define the physical devices of network  500  to be used for conducting the test. For example, the script may define ASD/ORIG  110  as an originating ASD, and may define ASD/TERM  110  as a terminating ASD. 
         [0065]    As further shown in  FIG. 8 , process  800  may use a database to map IP address and port locations of the defined ASDs (block  820 ). For example, in one implementation described above in connection with  FIG. 5 , a database within the ITP system (e.g., database  420 ) may enable the ITP system to reference specific IP address/port combinations to communicate with the specific ASDs being used. The database may also provide a reference to voice server  130  (upper left of  FIG. 5 ) and channel bank  560 . 
         [0066]    Process  800  may verify if the originating ASD is providing a dial tone (block  830 ). For example, in one implementation described above in connection with  FIG. 5 , ASD/ORIG  110  may be activated, and the ITP system (e.g., voice server  130  in cooperation with handset control server  140 ) may verify that SIP phone  340  of ASD/ORIG  110  is providing a dial tone via audio interface  320  and channel bank. 
         [0067]    As further shown in  FIG. 8 , process  800  may instruct the originating ASD to dial a telephone number for the terminating ASD to initiate a call (block  840 ). For example, in one implementation described above in connection with  FIG. 5 , the telephone number for ASD/TERM  110  may be entered on ASD/ORIG  110  (e.g., controller  300  may dial the telephone number on SIP phone  340  via relay interface  310 ) to initiate a call. 
         [0068]    Process  800  may monitor for a ringing event from the terminating ASD (block  850 ). For example, in one implementation described above in connection with  FIG. 5 , the ITP system (e.g., handset control server  140 ) may monitor ASD/TERM  110  for a ringing event. 
         [0069]    As further shown in  FIG. 8 , process  800  may instruct the terminating ASD to answer the call (block  860 ). For example, in one implementation described above in connection with  FIG. 5 , if a ringing event is detected, the ITP system (e.g., handset control server  140 ) may pause for a predetermined time (e.g., to simulate a user delay in answering a call) and may activate the hook-switch of ASD/TERM  110  (e.g., controller  300  may activate the hook-switch of relay interface  310  which may cause SIP phone  340  to receive the call) to answer the call. 
         [0070]    Process  800  may instruct a voice server to generate a tone associated with the originating ASD (block  870 ). For example, in one implementation described above in connection with  FIG. 5 , the ITP system (e.g., voice server  130  in cooperation with handset control server  140 ) may cause a tone of a predetermined frequency (e.g., “1025” Hertz) to be generated through ASD/ORIG  110 . In one example, the tone may be generated, using PCM on voice server  130 , through a portion of channel bank  560  corresponding to ASD/ORIG  110 . Channel bank  560  may convert the PCM tone into an analog tone, and may enable transmit and receive levels of the tone to be adjusted. The analog tone may be provided via audio interface  320  of ASD/ORIG  110 . The tone received by audio interface  320  may be adjusted to a level that emulates the level received by a human voice driving a microphone. After SIP signaling establishes the call, the tone may be transferred from ASD/ORIG  110  to ASD/TERM  110 , via RTP packets, across network  150  (e.g., via LANs  510  and  520 , and network devices  530 ). 
         [0071]    As further shown in  FIG. 8 , process  800  may optionally instruct the voice server to generate a tone on a T1 channel associated with the terminating ASD to generate a tone (block  880 ). For example, in one implementation described above in connection with  FIG. 5 , voice server  130  in cooperation with handset control server  140  may provide an adjustable tone through channel bank  560  and ASD/TERM  110  to ASD/ORIG  110  in a manner similar to the manner ASD/ORIG  110  provides an adjustable tone to ASD/TERM  110 . 
         [0072]    Process  800  may verify the results of the generated tone(s) (block  890 ). For example, in one implementation described above in connection with  FIG. 5 , the ITP system (e.g., voice server  130  in cooperation with handset control server  140 ) may detect the presence of the tone with ASD/TERM  110 . ASD/TERM  110  may receive the RTP packets and may convert the RTP packets into analog audio signals. ASD/TERM  110  may adjust the level of the audio signals (e.g., the tone) and may transmit the audio signals to speaker interface  321  of ASD/TERM  110 . Speaker interface  321  of ASD/TERM  110  may transmit the audio signals to channel bank  560 , and channel bank  560  may encode the audio signals as PCM. Channel bank  560  may send the encoded audio signals to voice server  130  (upper left of  FIG. 5 ) where measurement and other testing functions may be performed. Voice server  130  (upper left of  FIG. 5 ) may also perform measurements and other testing functions on the tone generated by ASD/TERM  110 . 
         [0073]    Systems and methods described herein may use an ASD that permits functional testing of a SIP-based network and/or devices within the SIP-based network with minimal manual input. The systems and methods may implement the ASD within an ITP system that may test the performance of the SIP-based network. The ITP system may include a handset control server that may provide specific control of the ASD and may enable ASD to be used in the larger ITP system. 
         [0074]    The foregoing description provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. 
         [0075]    For example, while series of acts have been described with regard to the flowcharts of  FIGS. 6-8 , the order of the acts may differ in other implementations consistent with the embodiments described herein. Further, non-dependent acts may be performed in parallel. 
         [0076]    Embodiments, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that one would be able to design software and control hardware to implement the embodiments based on the description herein. 
         [0077]    No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.