Patent Publication Number: US-2015085874-A1

Title: Provisioning sip-based remote vpn phones

Description:
TECHNICAL FIELD 
     Embodiments relate generally to computer network telecommunications, and more particularly, to methods, systems and computer readable media for provisioning SIP-based remote virtual private network (VPN) phones. 
     BACKGROUND 
     In some conventional VPN phone environments, provisioning a VPN phone for a remote user (e.g., a user that is using the phone at a location away from a local area network (LAN) or wide-area network (WAN) network) can be cumbersome and time consuming. For example, an information technology (IT) administrator or network administrator may need to manually configure a VPN phone and send the phone to a remote worker (e.g., a telecommuting worker or teleworker). Alternatively, the IT department can develop a custom script or program in a corporate PC, which the teleworker uses to configure the phone by executing the program or script on the PC. In another alternative, the remote worker provisions the VPN phone using a document prepared by the IT department that contains instructions for provisioning the VPN phone. Each of the above provisioning techniques can be complex and difficult for a remote worker to perform or can be burdensome for the IT staff. 
     Further, in some deployments using session initiation protocol (SIP) over transport layer security (TLS) and a session boarder controller (SBC), there can be issues. For example, SBC may be a costlier solution compared to VPN. Also, some SBC solutions may not be scalable and flexible and thus may limit the evolution of phone applications. Desktop phones are becoming increasingly intelligent and employ not only voice communications, but data communications from applications such as email and instant messaging. Thus a session boarder controller may need to terminate data links in addition to voice links. Also, there may be a growing number of VPN devices than SBC devices being deployed in enterprise deployments. The above may exacerbate the issues and limitations of a SIP over TLS and SBC solution. 
     Embodiments were conceived in light of the above mentioned needs, problems and/or limitations, among other things. 
     SUMMARY 
     One or more embodiments can include methods, systems and computer readable media for provisioning SIP-based remote virtual private network (VPN) phones (or other computer network-based telecommunications equipment). 
     Some implementations can include a method comprising providing a session initiation protocol (SIP) registrar proxy module at a gateway system, wherein the SIP registrar proxy module is configured to facilitate automatic provisioning of a SIP-based VPN phone. The method can also include receiving, at the SIP registrar proxy module of the gateway system, a first request from the SIP-based VPN phone and providing a first file in response to the first request. The method can further include receiving, at the SIP registrar proxy module of the gateway system, a second request from the SIP-based VPN phone and providing a second file in response to the second request. The method can also include configuring the SIP-based VPN phone based on the second file. 
     The method can further include connecting the SIP-based VPN phone to a call server subsequent to the configuring. The method can also include rebooting the SIP-based VPN phone subsequent to the configuring. The method can further include sending a gatekeeper request message from the SIP-based VPN phone to the call server. 
     Some implementations can include a system comprising one or more processors configured to perform operations. The operations can include providing a SIP registrar proxy module at a gateway system, wherein the proxy module is configured to facilitate automatic provisioning of a SIP-based VPN phone. The operations can also include receiving, at the SIP registrar proxy module of the gateway system, a first request from the SIP-based VPN phone and providing a first file in response to the first request. The operations can further include receiving, at the SIP registrar proxy module of the gateway system, a second request from the SIP-based VPN phone and providing a second file in response to the second request. The operations can also include configuring the SIP-based VPN phone based on the second file. 
     The operations can also include connecting the SIP-based VPN phone to a call server subsequent to the configuring. The operations can further include rebooting the SIP-based VPN phone subsequent to the configuring. The operations can also include sending a register request message from the SIP-based VPN phone to the call server. 
     Some implementations can include a nontransitory computer readable medium having stored thereon software instructions that, when executed by a processor, cause the processor to perform operations. The operations can include providing a SIP registrar proxy module at a gateway system, wherein the proxy module is configured to facilitate automatic provisioning of a SIP-based VPN phone. The operations can also include receiving, at the SIP registrar proxy module of the gateway system, a first request from the SIP-based VPN phone and providing a first file in response to the first request. The operations can further include receiving, at the SIP registrar proxy module of the gateway system, a second request from the SIP-based VPN phone and providing a second file in response to the second request. The operations can also include configuring the SIP-based VPN phone based on the second file. 
     The operations can also include connecting the SIP-based VPN phone to a call server subsequent to the configuring. The operations can further include rebooting the SIP-based VPN phone subsequent to the configuring. The operations can also include sending a register request message from the SIP-based VPN phone to the call server. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is diagram of an example SIP-based VPN phone environment in accordance with at least one implementation. 
         FIG. 2  is a diagram of an example SIP-based VPN phone environment showing organization intranet connections in accordance with at least one implementation. 
         FIG. 3  is a diagram of an example SIP-based VPN phone environment in accordance with at least one implementation. 
         FIG. 4  is a diagram of an example SIP-based VPN phone environment in accordance with at least one implementation. 
         FIG. 5  is a flow chart of an example method for SIP-based VPN phone provisioning in accordance with at least one implementation. 
         FIG. 6  is a flow chart of an example method for SIP-based VPN phone provisioning in accordance with at least one implementation. 
         FIG. 7  is a flow chart of an example method for SIP-based VPN phone provisioning in accordance with at least one implementation. 
         FIG. 8  is a data/control flow diagram of an example method for SIP-based VPN phone provisioning in accordance with at least one implementation. 
         FIG. 9  is a data/control flow diagram of an example method for SIP-based VPN phone provisioning in accordance with at least one implementation. 
         FIG. 10  is a data/control flow diagram of an example method for SIP-based VPN phone provisioning in accordance with at least one implementation. 
         FIG. 11  is a diagram of an example computer system in accordance with at least one implementation. 
     
    
    
     DETAILED DESCRIPTION 
     Some implementations can include the use of a VPN gateway, such as the Avaya VPN Gateway (AVG), as a SIP registrar proxy between a remote SIP-based VPN phone and a backend or core server. The VPN gateway can provide an initial configuration to the SIP-based VPN phone and then connect the phone through to the core server to obtain an updated configuration. 
     The VPN gateway can be configured to support SIP messages and act as a SIP registrar proxy. Also, the VPN gateway can host initial phone configuration files as an HTTP/HTTPS server. 
       FIG. 1  is diagram of an example SIP-based VPN phone environment  100 . The environment  100  can include a VPN gateway  102 . The VPN gateway  102  has a SIP registrar proxy  104 . The VPN gateway  102  also has a rewrite engine  106  including an HTTP module  108 , an HTML module  110  and an XML module  112 . The VPN gateway  102  also includes an SSL VPN tunnel  114 , an IPSec VPN  116  and an L2TP/IPSec VPN  118 . 
     In operation, a VPN phone  120  can connect to a server  126 , soft switch  128  or ID management system  130  via the SIP Registrar Proxy  104  of the VPN gateway  102 . The connection between the VPN phone  120  can the SIP Registrar Proxy  104  can include an SIP over TLS connection. A remote PC  122  can connect via the SSL VPN tunnel  114  and/or the IPSec VPN  116 . A mobile device  124  can connect via the IPSec or SSL VPN  118 . 
       FIG. 2  is a diagram of an example VPN phone environment  200  that includes a VPN phone  202  associated with a first organization and a VPN phone  204  associated with a second organization. The VPN phones ( 202  and  204 ) connect to a VPN gateway  206  and, in turn, to a switch  208 . The switch  208  connects each phone ( 202 ,  204 ) to a respective intranet  210  and  212 . The intranets ( 2210  and  212 ) can each include a domain names server, a telecommunications platform and an IP telephony system. 
     The environment  200  includes an internet portion  214 , a managed network zone  216  and a private network zone  218 . 
       FIG. 3  is a diagram of an example VPN phone environment  300  that includes a remote VPN phone  302 , a VPN gateway  304  and a plurality of local IP phones ( 306 - 312 ). 
     In operation, the VPN gateway  304  can provide automatic provisioning over the Internet including protocols such as SIP and IPSec. The VPN gateway  304  can be located within an enterprise cloud. The local IP phones ( 306 - 312 ) can connect with the VPN gateway  304  via an SSL connection or the like. 
       FIG. 4  is a diagram of an example VPN phone environment  400  that includes a remote VPN phone  402 , a VPN gateway  404  and a communications platform  406 . The communications platform  406  includes a call center  408 . 
       FIG. 5  is a flow chart of an example method for VPN phone configuration file generation in a VPN gateway in accordance with at least one implementation. Processing beings at  502 , where a request to access a configuration wizard is received. Processing continues to  504 . 
     At  504 , a wizard is caused to be displayed. Processing continues to  506 . 
     At  506 , a VPN internet protocol address (IP address) is received. Processing continues to  508 . 
     At  508 , the VPN IP is saved. Processing continues to  510 . 
     At  510 , a call server IP is received. For example, the IP address of a call server within the intranet is received. Processing continues to  512 . 
     At  512 , the call server IP address is saved. Processing continues to  514 . 
     At  514 , the IP address(es) are confirmed. Processing continues to  516 . 
     At  516 , the settings file for the VPN phone is generated and hosted in a VPN gateway. 
       FIG. 6  is a flow chart of an example method for initial VPN phone configuration. Processing begins at  602 , where a VPN IP is received. Processing continues to  604 . 
     At  604 , the VPN gateway IP address is saved as the call server address. Processing continues to  606 . 
     At  606 , a VPN user name and password are received. Processing continues to  608 . 
     At  608 , the VPN user name and password are saved. Processing  610 . 
     At  610 , the device (e.g., the VPN phone) is rebooted. 
       FIG. 7  is a flow chart of an example method for VPN phone provisioning. Processing begins at  702 , where a VPN phone is powered on. Processing continues to  704 . 
     At  704 , stage 1 of the automatic provisioning process is performed. Stage 1 is described in greater detail below in connection with  FIG. 8 . Processing continues to  706 . 
     At  706 , the device is rebooted. Processing continues to  708 . 
     At  708 , stage 2 of the automatic provisioning process is performed. Stage 2 is described in greater detail below in connection with  FIG. 9 . Processing continues to  710 . 
     At  710 , the device is rebooted. Processing continues to  712 . 
     At  712 , stage 3 of the automatic provisioning process is performed. Stage 3 is described below in greater detail in connection with  FIG. 10 . Processing continues to  714 . 
     At  714 , the device is rebooted. 
       FIG. 8  is a data/control flow diagram of an example method for SIP-based VPN phone provisioning in accordance with at least one implementation. Messages are transferred between a SIP VPN phone  802 , a router  804  (e.g., a home router), a VPN gateway  806  and an intranet system  814  (e.g., a call server). The VPN gateway  806  includes a SIP registrar proxy module  808 , a UA  810  and a portal  812 . 
     The VPN phone sends a dynamic host configuration protocol (DHCP) message  816  to the router  804 . The router  804  responds with a DHCP acknowledge message  818 . 
     At  820 , the VPN phone  802  provides a craft menu (e.g., a configuration menu) and receives a configuration of a VPN as a call server. At  822 , the VPN phone  802  sends an HTTPS get message to the portal  812  of the VPN gateway  806 . The VPN gateway  806  responds  824  with the upgrade file for the VPN phone  802  if the phone is authenticated. If the phone  802  is not authenticated, the VPN gateway may not respond, but the phone will continue with the sequence. 
     At  826 , the VPN phone  802  sends an HTTPS get message for the settings file. At  828 , the VPN gateway  806  responds with the settings file, if the phone is authenticated. If the phone  802  is not authenticated, the VPN gateway may not respond, but the phone will continue with the sequence. At  830 , the VPN phone  802  sends a register message to the SIP registrar proxy  808  of the VPN gateway  806 . The registrar proxy  808  initiates a far end NAT traversal (FENT) process  832  to the UA  810 , which forwards a register message  834  to the call server  814 . 
     The call server responds with an unauthorized  401  message  836 . The UA  810  initiates a reverse FENT process to the registrar  808 , which in turn sends the  401  unauthorized message  840  to the SIP VPN phone  802 . 
     At  842 , the VPN phone  802  sends a register message to the SIP registrar proxy  808  of the VPN gateway  806 . The registrar proxy  808  initiates a FENT process  844  to the UA  810 , which sends a register message  846  to the call server  814 . 
     The call server responds with an options message  848 . The UA  810  initiates a reverse FENT process  850  to the registrar  808 , which in turn sends the options message  852  to the SIP VPN phone  802 . 
     At  854 , the call server  814  sends a  200  OK message  854  to the UA  810 . The UA  810  initiates a reverse FENT process  856  to the registrar  808 , which sends a  200  OK message  858  to the SIP VPN phone  802 . At  860  the VPN phone is auto-rebooted. 
       FIG. 9  is a data/control flow diagram of an example method for VPN phone provisioning. The VPN phone  802  sends a DHCP offer  902  to the router  804 . The router  804  responds with a DHCP acknowledgement  904 . 
     The VPN phone  802  sends an HTTPS get message  906  for the upgrade file to the portal  812 . The VPN gateway (e.g., via the registrar proxy) responds  908  with the upgrade file. The VPN phone  802  then sends an HTTPS get message  910  for the settings file. The VPN gateway  806  responds with the settings file  912 . 
     At  914 , the VPN phone  802  is configured using the settings file received from the VPN gateway  806 . At  916 , the VPN phone  802  sends a register message to the registrar proxy  808  of the VPN gateway  806 . The VPN gateway  806  responds with an options message  920  and a  200  OK message  922 . At  924  the VPN phone  802  performs an auto-reboot. 
       FIG. 10  is a data/control flow diagram of an example method for VPN phone provisioning. The VPN phone  802  sends a DHCP offer  1004  to the router  804 . The router  804  responds with a DHCP acknowledgement  1006 . 
     At  1008 , the VPN phone  802  provides a craft menu (e.g., a configuration menu) and receives a configuration of a VPN user ID and password. At  1010  the SIP VPN phone  802  sends an ISAKMP message to the IPSec module  1002 . At  1012 , the SIP VPN phone  802  sends an ESP message  1012  to the IPSec module  1002 . 
     At  1014 , the VPN phone  802  sends an HTTPS get message for the upgrade file to the VPN gateway  806 . The VPN gateway  806  (e.g., via the registrar proxy) responds  1016  with the upgrade file. The VPN phone  802  then sends an HTTPS get message  1018  for the settings file. The VPN gateway  806  responds with the settings file  1020 . 
     At  1022 , the VPN phone  802  sends a register message to the call server  814 . At  1024 , the call server responds with a  401  unauthorized message. 
     The VPN phone  802  then sends another register message  1026  to the call server  814 . The call server  814  responds with an options message  1028 , a  200  OK message  1030  and a subscribe message  1032 . 
       FIG. 11  is a diagram of an example computer system. The computer  1100  includes a processor  1102 , operating system  1104 , memory  1106  and I/O interface  1108 . The memory  1106  can include a VPN provisioning application  1110  and files  1112  for configuring a VPN phone. 
     In operation, the processor  1102  may execute the application  1110  stored in the memory  1106 . The application  1110  can include software instructions that, when executed by the processor, cause the processor to perform operations for network management in accordance with the present disclosure (e.g., performing one or more of the steps described above in connection with  FIGS. 5-10 ). 
     The application program  1110  can operate in conjunction with the files  1112  and the operating system  1104 . 
     It will be appreciated that the modules, processes, systems, and sections described above can be implemented in hardware, hardware programmed by software, software instructions stored on a nontransitory computer readable medium or a combination of the above. A system as described above, for example, can include a processor configured to execute a sequence of programmed instructions stored on a nontransitory computer readable medium. For example, the processor can include, but not be limited to, a personal computer or workstation or other such computing system that includes a processor, microprocessor, microcontroller device, or is comprised of control logic including integrated circuits such as, for example, an Application Specific Integrated Circuit (ASIC). The instructions can be compiled from source code instructions provided in accordance with a programming language such as Java, C, C++, C#.net, assembly or the like. The instructions can also comprise code and data objects provided in accordance with, for example, the Visual Basic™ language, or another structured or object-oriented programming language. The sequence of programmed instructions, or programmable logic device configuration software, and data associated therewith can be stored in a nontransitory computer-readable medium such as a computer memory or storage device which may be any suitable memory apparatus, such as, but not limited to ROM, PROM, EEPROM, RAM, flash memory, disk drive and the like. 
     Furthermore, the modules, processes systems, and sections can be implemented as a single processor or as a distributed processor. Further, it should be appreciated that the steps mentioned above may be performed on a single or distributed processor (single and/or multi-core, or cloud computing system). Also, the processes, system components, modules, and sub-modules described in the various figures of and for embodiments above may be distributed across multiple computers or systems or may be co-located in a single processor or system. Example structural embodiment alternatives suitable for implementing the modules, sections, systems, means, or processes described herein are provided below. 
     The modules, processors or systems described above can be implemented as a programmed general purpose computer, an electronic device programmed with microcode, a hard-wired analog logic circuit, software stored on a computer-readable medium or signal, an optical computing device, a networked system of electronic and/or optical devices, a special purpose computing device, an integrated circuit device, a semiconductor chip, and/or a software module or object stored on a computer-readable medium or signal, for example. 
     Embodiments of the method and system (or their sub-components or modules), may be implemented on a general-purpose computer, a special-purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit element, an ASIC or other integrated circuit, a digital signal processor, a hardwired electronic or logic circuit such as a discrete element circuit, a programmed logic circuit such as a PLD, PLA, FPGA, PAL, or the like. In general, any processor capable of implementing the functions or steps described herein can be used to implement embodiments of the method, system, or a computer program product (software program stored on a nontransitory computer readable medium). 
     Furthermore, embodiments of the disclosed method, system, and computer program product (or software instructions stored on a nontransitory computer readable medium) may be readily implemented, fully or partially, in software using, for example, object or object-oriented software development environments that provide portable source code that can be used on a variety of computer platforms. Alternatively, embodiments of the disclosed method, system, and computer program product can be implemented partially or fully in hardware using, for example, standard logic circuits or a VLSI design. Other hardware or software can be used to implement embodiments depending on the speed and/or efficiency requirements of the systems, the particular function, and/or particular software or hardware system, microprocessor, or microcomputer being utilized. Embodiments of the method, system, and computer program product can be implemented in hardware and/or software using any known or later developed systems or structures, devices and/or software by those of ordinary skill in the applicable art from the function description provided herein and with a general basic knowledge of the software engineering and computer networking/telecommunications arts. 
     Moreover, embodiments of the disclosed method, system, and computer readable media (or computer program product) can be implemented in software executed on a programmed general purpose computer, a special purpose computer, a microprocessor, a network server or switch, or the like. 
     It is, therefore, apparent that there is provided, in accordance with the various embodiments disclosed herein, methods, systems and computer readable media for provisioning SIP-based remote VPN phones. 
     While the disclosed subject matter has been described in conjunction with a number of embodiments, it is evident that many alternatives, modifications and variations would be, or are, apparent to those of ordinary skill in the applicable arts. Accordingly, Applicants intend to embrace all such alternatives, modifications, equivalents and variations that are within the spirit and scope of the disclosed subject matter.