Abstract:
A request to establish a communication session is received. A clone of a communication system object with configuration information is produced and associated with a session identifier for the communication session. The session identifier for the communication session is sent to a client. When an administrator wants to make updates to re-bootable parameter(s) in the configuration information, the re-bootable parameter(s) are updated in the clone of the communication system object based on the session identifier. A message to save the session information with the session identifier is received. In response to receiving the save session information message, the clone with the updates to the re-bootable parameter(s) is sent to the communication system. This results in the communication system rebooting. By updating multiple re-bootable parameters in the clone of the communication system, a single reboot will occur. This reduces the total number of reboots that would have occurred previously.

Description:
TECHNICAL FIELD 
     The systems and methods disclosed herein relate to communication systems and in particular to management of configuration parameters in communication systems. 
     BACKGROUND 
     When a user administers a communication system, such as a Private Branch Exchange (PBX), the user may want to change multiple parameters of the communication system. Changing multiple parameters works fine as long as the parameters do not require a reboot of the communication system. However, if the user wants to change multiple parameters that each requires a reboot of the communication system, the system will be rebooted for each change of each re-bootable parameter. This can lead to extensive down time if multiple parameters cause the communication system to be rebooted for each parameter. 
     This problem becomes even more difficult to resolve when stateless protocols, such as Representational State Transfer (REST) are used. Because of REST&#39;s stateless nature, REST requires that each re-bootable parameter be sent using a separate message. Like as previously described, the communication system must be reboot each time a re-bootable parameter is changed. 
     To address this problem, one solution that uses REST is to maintain a local copy of the configuration information (e.g., re-bootable parameters). The changes are managed by the client. When the changes are complete, the changes are then pushed back to the server. The server can then reboot based on the changes. The problem with this solution is that the client becomes more complicated and more difficult to maintain. This thwarts the whole purpose of REST where the clients are designed to be simple. 
     SUMMARY 
     Systems and methods are provided to solve these and other problems and disadvantages of the prior art. A request to establish a communication session is received. A clone of a communication system object with configuration information is produced and associated with a session identifier for the communication session. The session identifier for the communication session is sent to a client. When an administrator wants to make updates to a re-bootable parameter(s) in the configuration information, the re-bootable parameter(s) are updated in the clone of the communication system object based on the session identifier. A message to save the session information with the session identifier is received. In response to receiving the save session information message, the clone with the updates to the re-bootable parameter(s) is sent to the communication system. This results in the communication system rebooting. By updating multiple re-bootable parameters in the clone of the communication system, a single actual reboot of the communication system will occur. This reduces the total number of reboots that would have occurred previously, thereby reducing the overall downtime of the system. 
     In one embodiment, REST is used. The above process uses a unique session management layer within REST to address REST&#39;s stateless only limitation. This allows clients to track specific session information of active sessions on the PBX. The session information can be saved for use in tracking the session. For example, information such as the session creator, creation time, and IP details can be saved and utilized by both the PBX and the clients using REST. This allows REST servers to maintain REST Application Programming Interfaces (APIs) and keep the statelessness of REST intact. This solution also uses existing REST messages and therefore does not require additional bandwidth/messages. In addition, this solution maintains the simplicity of the REST client. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of a first illustrative system for managing re-bootable parameters of a communication system. 
         FIG. 2  is a flow diagram of a first exemplary process for managing re-bootable parameters of a communication system. 
         FIG. 3  is a flow diagram of a second exemplary process for managing re-bootable parameters of a communication system. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram of a first illustrative system for managing re-bootable configuration parameters  123  of a communication system  120 . The first illustrative system  100  comprises clients  101 A- 101 N, a network  110 , a communication system  120 , and a Representational State Transfer (REST) Hyper Text Transport Protocol (HTTP) server  130 . 
     The client  101  can be or may include any hardware device that can communicate on the network  110 , such as a Personal Computer (PC), a telephone, a cellular telephone, a Personal Digital Assistant (PDA), a tablet device, a smart phone, a notebook device, a laptop computer, and/or the like. As shown in  FIG. 1 , any number of clients  101 A- 101 N may be connected to the network  110 , including only a single client  101 . The client  101  is typically used to administer the communication system  120 . In one embodiment the client  101  is a REST client. 
     The network  110  can be or may include any collection of communication equipment that can send and receive electronic communications, such as the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), a Voice over IP Network (VoIP), the Public Switched Telephone Network (PSTN), a packet switched network, a circuit switched network, a cellular network, a combination of these, and the like. The network  110  can use a variety of electronic protocols, such as Ethernet, Internet Protocol (IP), Session Initiation Protocol (SIP), Integrated Services Digital Network (ISDN), REST, HTTP, and the like. Thus, the network  110  is an electronic communication network configured to carry messages via packets and/or circuit switched communications. 
     The communication system  120  can be or may include any hardware coupled with software that can manage communications on the network  110 , such as a Private Branch Exchange (PBX), a communication manager, a session manager, a communication processor, a central office switch, a router, a hub, a email server, an Instant Messaging server, a video switch, a video router, a network management system, a client  101 , and/or the like. The communication system  120  further comprises a configuration management service  121  and configuration parameters  122 . The configuration management service  121  can be or may include any hardware/software that can be used to configure the communication system  120 . 
     The configuration parameters  122  can be or may include any parameters that can be used to configure the communication system  120 . The configuration parameters  122  may include re-bootable configuration parameters  123  that require the communication system  120  to reboot when changed. 
     The REST HTTP server  130  can be or may include any hardware coupled with software that can manage REST/HTTP communications with the clients  101 A- 101 N, such as a communications server, a web server, and/or the like. The REST HTTP server  130  is shown being separate from the communication system  120 . However, in one embodiment, the REST HTTP server  130  may be included as a module in the communication system  120 . 
       FIG. 2  is a flow diagram of a first exemplary process for managing re-bootable configuration parameters  123  of a communication system  120 . Illustratively, the clients  101 A- 101 N, the communication system  120 , the configuration management service  121 , and the REST HTTP server  130  are stored-program-controlled entities, such as a computer or processor, which performs the method of  FIGS. 2-3  and the processes described herein by executing program instructions stored in a non-transitory computer readable storage medium, such as a memory or disk. Although the methods described in  FIGS. 2-3  are shown in a specific order, one of skill in the art would recognize that the steps in  FIGS. 2-3  may be implemented in different orders and/or be implemented in a multi-threaded environment. Moreover, various steps may be omitted or added based on implementation. 
     The processes describes in  FIGS. 2-3  are described using REST/HTTP protocols. However, the descriptions in  FIGS. 2-3  are not limited to any specific protocol. One of skill in the art would recognize that the process described in  FIGS. 2-3  may be implemented using a one or more protocols, such as SIP, IP, User Datagram Protocol (UDP), Transmission Control Protocol (TCP), proprietary protocols, REST, HTTP, and/or the like. In addition, some of the messages described in  FIGS. 2-3  may not show well known messages, such as acknowledgement messages (e.g., acknowledgement messages for steps  214 ,  218 ,  222 ,  302 ,  314 , and  318 ). 
     The process starts in step  200 A when new session request is sent by the client  101 A (e.g., a REST POST new session request). For example, the request for the new session is sent when an administrator wants to administer configuration information for the communication system  120 . The REST HTTP server  130  authenticates REST POST new session request in step  202 . For example, the REST HTTP server  130  (e.g., a web server) requests the user to provide a user name and password. After authenticating the user in step  202 , the REST HTTP server  130  sends the REST POST new session request to the configuration management service  121  in step  200 B. 
     In one embodiment, the configuration management service  121 , in response to receiving the REST POST new session request of step  200 B sends a request to get a clone of a communication system object that includes configuration information in step  204 . The clone of the communication system object includes configuration information for the communication system  120 . The configuration information can include a variety of configuration parameters  122  that can be configured, such as a dial plan, IP addresses, ports, Media Access (MAC) addresses, a sub-net mask(s), a country code, a trunk channel, a line type, an option to enable Cyclic Redundancy Checking (CRC), line numbering, a clock source, a national prefix, an international prefix, a port identifier, a speaker volume, and/or the like. The configuration information may include re-bootable configuration parameters  123  that require the communication system  120  to reboot in order for the re-bootable configuration parameters  123  to become effective. The configuration information may include configuration parameters  122  that do not require the communication system  120  to reboot when changed. The communication system  120  sends a clone of the communication system object that includes the configuration information in step  206 . The clone of the communication system object will have the configuration information as currently administered. 
     In another embodiment (indicated by the dashed lines), instead of sending the request for a clone of the communication system object in step  204 , the configuration management service  121  creates the clone of the communication system object in step  203  (in response to the REST POST new session request of step  200 B). The configuration management service  121  sends a request to get the configuration information in step  208 . The communication system  120  sends the configuration information in step  210 . The configuration management service  121  populates the clone of the communication system object with the configuration information in step  211 . 
     At this point, the configuration management service  121  has a clone of the communication system object with the configuration information. The configuration management system responds by sending a message with a session identifier (SID) in step  212 A. The session identifier can be any unique identifier for the communication session, such as a Global Session Identifier (GSID), a dialog session identifier, and/or the like. The REST HTTP server  130  sends a REST response message (e.g., in Extended Markup Language (XML)) that includes the session identifier in step  212 B. 
     The client  101  sends in step  214 A an update of a re-bootable parameter request that includes the session identifier (e.g., using HTTP). For example, the message of step  214 A may be sent when an administrator wants to change an IP address of the communication system  120 . The HTTP/REST server  130  sends the update of the re-bootable parameter with the session identifier in step  214 B to the configuration management service  121 . The configuration management service  121  updates the re-bootable configuration parameter  123  in the configuration information of the clone in step  216 . The update of the configuration information is based on the session identifier. 
     The client  101  can optionally send (indicated by the dashed lines) an update of a second re-bootable parameter using the session identifier in step  218 A. The REST HTTP server  130  sends the request to update the second re-bootable parameter in step  218 B to the configuration management service  121 . The configuration management service  121  updates the second re-bootable configuration parameter  123  in step  220 . The messages of steps  214  and  218  may update multiple configuration parameters  122 / 123 . The process of steps  218 - 220  can be repeated for additional changes to configuration parameters  122 / 123  that may be re-bootable configuration parameters  123  or non re-bootable configuration parameters  122 . 
     The client  101  sends a REST message to save the session information with the session identifier in step  222 A. The REST HTTP server  130  sends the message to save the session information with the session identifier in step  222 B. The configuration management service  121  updates the clone with any changes in the save message in step  224 . The configuration management service  121  sends the updated clone of the communication system object (with the updates of steps  216 ,  220 , and  224 ) to the communication system  120  in step  226 . 
     The communication system  120  receives the updated clone object for the communication system  120  in step  226 . The communication system  120  merges the changes into the live communication system object and reboots the communication system  120  in step  228 . In this example, the reboot is necessary because one or more re-bootable configuration parameters  123  were changed. However, if the objects changed in step  214 / 218  were not re-bootable objects, the reboot of step  228  would be unnecessary. In response to the reboot, the communication system  120  sends a status of the reboot to the client  101 , via the configuration management service  121  and the REST HTTP server  130  in steps  230 A- 230 C. 
     The advantage of changing re-bootable configuration parameters  123  in the clone is that a reboot is unnecessary when each change is made. In  FIG. 2 , two re-bootable configuration parameters  123  were changed before a reboot occurred. In the prior art, two reboots would have been necessary, one for each changed re-bootable configuration parameter  123 . 
       FIG. 3  is a flow diagram of a second exemplary process for managing re-bootable configuration parameters  123  of a communication system  120 . The process starts in step  200 A when new session request is sent by the client  101  (e.g., a REST POST new session request). The REST HTTP server  130  authenticates REST POST new session request in step  202 . After authenticating the user in step  202 , the REST HTTP server  130  sends the REST POST new session request to the configuration management service  121  in step  200 B. 
     The configuration management system responds by sending a message with a session identifier (SID) in step  300 A. The session identifier can be any unique identifier for the communication session, such as a Global Session Identifier (GSID), a dialog session identifier, and/or the like. The REST HTTP server  130  sends a REST response message (e.g., in Extended Markup Language (XML)) that includes the session identifier in step  300 B. 
     The client  101  sends, in step  302 A, an update of a re-bootable parameter request that includes the session identifier. For example, the message of step  302 A may be sent when an administrator wants to change a MAC address of the communication system  120 . The HTTP/REST server  130  sends the update of the re-bootable parameter with the session identifier in step  302 B to the configuration management service  121 . The configuration management service  121  updates the re-bootable configuration parameter  123  in the configuration information of the clone in step  304 . The update of the configuration information is based on the session identifier. 
     In addition, the configuration management service  121  determines whether the configuration parameter  122  of step  302  is a re-bootable configuration parameter  123 . The configuration management service  121  can determine if a configuration parameter  122  is a re-bootable configuration parameter  123  in various ways. For example, the configuration management service  121  can determine that a configuration parameter  122  is re-bootable configuration parameter  123  based on a list of defined re-bootable configuration parameters  123 . Alternatively, a re-bootable configuration parameter  123  can be determined based on an object type or number range (e.g., where re-bootable configuration parameters  123  are defined based on numbers). As used herein, the term re-bootable configuration parameter  123  is used to refer to any parameter or collection of parameters that will require a system re-boot prior to having the re-bootable configuration parameter  123  set from an value to a new/changed value. 
     In one embodiment, the configuration management service  121 , in response to determining that the configuration parameter  122  is a re-bootable configuration parameter  123  in step  304 , the configuration management service  121  sends a request to get a clone of a communication system object that includes configuration information in step  306 . The clone of the communication system object includes configuration information for the communication system  120 . The communication system  120  sends the clone of the communication system object that includes the configuration information in step  308 . The clone of the communication system object will have the configuration information as currently administered. 
     In another embodiment (indicated by the dashed lines), instead of sending the request for a clone of the communication system object in step  306 , the configuration management service  121  creates the clone of the communication system object in step  304  (in response to the request to update the re-bootable parameter of step  302 B). The configuration management service  121  sends a request to get the configuration information in step  310 . The communication system  120  sends the configuration information in step  312 . The configuration management service  121  populates the clone of the communication system object with the configuration information in step  313 . 
     The client  101  can optionally send (indicated by the dashed lines) an update of a second re-bootable parameter using the session identifier in step  314 A. The REST HTTP server  130  sends the request to update the second re-bootable parameter in step  314 B to the configuration management system  121 . The configuration management service  121  updates the second re-bootable configuration parameter  123  in step  316 . The messages of steps  302  and  314  may update multiple configuration parameters  122 / 123 . The process of steps  314 - 316  can be repeated for additional changes to configuration parameters  122  that may be re-bootable configuration parameters  123  or non re-bootable configuration parameters  122 . 
     The client  101  sends a REST message to save the session information with the session identifier in step  318 A. The REST HTTP server  130  sends the message to save the session information with the session identifier in step  318 B. The configuration management service  121  updates the clone with any changes in the save message in step  320 . The configuration management service  121  sends the updated clone of the communication system object (with the updates of steps  304 ,  316 , and  320 ) to the communication system  120  in step  322 . 
     The communication system  120  receives the updated clone object for the communication system  120  in step  322 . The communication system  120  merges the changes into the live communication system object and reboots the communication system  120  in step  324 . In this example, the reboot is necessary because one or more re-bootable configuration parameters  122  were changed. In response to the reboot, the communication system  120  sends a status of the reboot to the client  101 , via the configuration management service  121  and the REST HTTP server  130  in steps  326 A- 326 C. 
     In this embodiment, the communication system object is only cloned if a re-bootable object is updated. If no re-bootable objects are updated, the configuration management service  121  will not create/receive a clone of the communication system object. 
     The session identifier described in  FIGS. 2-3  is used by the configuration management service  121  to track messages associated with the communication session. For example, two different administrators may each have a separate communication sessions that are open concurrently. In this example, there would be two separate communication system objects created with different session identifiers. If a reboot is required, the configuration management system sends multiple updated clones that are merged in steps  228  and  324 . 
     Alternatively, the process of  FIGS. 2-3  may only allow a single administrative communication session to run concurrently. This embodiment does not require the session identifier because there is only a single administrative communication session. For example, none of the messages of  FIGS. 2-3  would require a session identifier. 
     The processes of  FIG. 2-3  may be implemented using encryption. For example, the messages described in  FIGS. 2-3  may be implemented over HTTPs (secure HTTP). 
     Of course, various changes and modifications to the illustrative embodiment described above will be apparent to those skilled in the art. These changes and modifications can be made without departing from the spirit and the scope of the system and method and without diminishing its attendant advantages. The following claims specify the scope of the invention. Those skilled in the art will appreciate that the features described above can be combined in various ways to form multiple variations of the invention. As a result, the invention is not limited to the specific embodiments described above, but only by the following claims and their equivalents.