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.
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.
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.
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.
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.
The environment 200 includes an internet portion 214, a managed network zone 216 and a private network zone 218.
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.
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.
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.
At 704, stage 1 of the automatic provisioning process is performed. Stage 1 is described in greater detail below in connection with
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
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
At 714, the device is rebooted.
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.
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.
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.
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
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.