The invention relates generally to accessing devices from a remote location. More particularly, the present invention relates to accessing home resources located on a home network through a HTTP proxy gateway from a remote network.
Currently, user devices connected to various home networks that use Internet Protocol (IP) connectivity may be accessed and/or controlled from a personal computer or other smart device. The home devices that may be accessed or controlled include devices such as personal computers, personal video recorders (PVRs), and other media type devices. In addition, the number of these “smart” devices used in a home environment is expected to significantly increase in the near future.
In most cases, Internet Service Providers (ISPs) assign a dynamic public IP address to each of their customers. Typically IP addresses are assigned within home networks through use of a Dynamic Host Configuration Protocol (DHCP) server. A Dynamic Host Configuration Protocol is a protocol for assigning dynamic IP addresses to devices on a network. With the use of dynamic addressing, a device may have a different IP address every time it connects to the network, (usually after device reboot), or after some time out set by a network operator.
In addition in some systems, a device's IP address may change while the device is still connected. The IP address represents an identifier for a computer or device on a TCP/IP network. Networks using a TCP/IP protocol route messages based on the IP address of the final destination. The format of an IP address is a 32-bit numeric address written as four numbers separated by periods. Within an isolated network, one may assign IP addresses at random as long as each IP address is unique. However, connecting a private network to a public network such as the Internet requires using registered IP addresses to avoid duplication of addresses. Thus, devices on a home network that are to be connected or accessed through an outside network need to be addressable by devices connected to the outside network.
Currently there are a few existing solutions for resolving the above problem, however, each of the solutions suffers from various shortcomings and drawbacks. We discuss each of these existing solutions and their drawbacks below noting that none of the currently existing solutions may be regarded as a successful solution.
A first prior art solution involves the use of a Virtual Private Network (VPN). The VPN provides a method for accessing a home network from a trusted personal device such as a personal mobile phone. However, a VPN solution has numerous drawbacks including the requirement that a VPN client be installed on a remote terminal. Therefore, such a solution may work on smart devices but will not work on simple devices. In addition, a VPN solution may not work using certain corporate resources as many corporate entities do not allow modifications of a client's VPN policies. Moreover, guests or visitors can not be invited to access home devices as a guest or user would be able to obtain the IP access to the whole home network creating a possible security concern. Finally, with a VPN solution the configuration needed is significant and time consuming.
A second prior art solution involves the use of third party services. These third party services create tunnels from home devices to external proxies. However, these third party solutions suffer from major drawbacks as all traffic is routed through the servers of these third party companies. Users of these third party services must ask themselves questions such as: “Why should I trust my personal content going through some non-trusted company?” or “Does this third party company have enough bandwidth for all of their users?” Most third party services only provide a small bandwidth per user, so the fast home connection is not fully utilized. In addition, third party services involve payment of costly monthly subscription fees for use of their services.
A third prior art solution involves use of port forwarding techniques. A port forwarding solution allows a gateway to forward external connections to internal devices. For example, rules may be implemented in which connections from the external network such as the Internet, on port 80 of the external IP address, are forwarded to port 80 of a personal computer located on an internal network. Similarly, connections on a port such as a port 81 of the external IP address may be forwarded to port 80 of a PVR device located on a home network.
However, current port forwarding solutions suffer from numerous problems that include making difficult configurations on the gateway. In addition, typical owners of home networks do not have extensive knowledge regarding IP addresses and ports which would lead to owners creating unknown holes in firewalls of their networks. These holes may expose home devices to external attacks.
Moreover, internal IP addresses of devices might change, in case DHCP is used in a home network (which is the most common configuration). Thus, in case of a reboot, of the gateway/DHCP server for example, all of the connected home devices will get different internal IP addresses. Thus, the static port forwarding settings would need to be reconfigured. Furthermore, home devices have different URLs depending if accessed from an inside network or an outside network. For example, an internal network device address such as a PVR device address may be 192.168.100:80 and if accessed from an external network such as the Internet the PVR device has an address 100.100.100.100:81 (assuming that the 100.100.100.100 is the public address of the gateway, and port 81 is forwarded to port 80). This would confuse users and cause them to have duplicate bookmarks on their portable device (example mobile phones), depending if they access the home devices from the home network or an external network. Finally, problems with some well known ports may lead to potential problems. For example, some phone browsers allow SSL connections only on port 443. If a user has two home devices with SSL, one has to be mapped on a different port (on the gateway), thus the phone would refuse to connect.
A fourth prior art solution involves use of a HTTP Proxy. Such a solution may be useful as HTTP protocols are used extensively. Using a free dynamic DNS service (example www.dyndns.org) one may constantly resolve an IP address from a DNS name. For illustrative purposes in this application and as shown in
However, current HTTP proxy solutions suffer from numerous problems such as address changing during reboot. For example,
Another problem that exists with the current HTTP proxy solutions involves the use of two different bookmarks to obtain access to a particular device depending on whether a device is accessed from an internal network or an external network. For example, a WLAN enabled mobile phone could access a device such as PVR 112 (when within home network), at address http://192.168.1.100/ and this is the bookmark that the user would save on the phone's browser. However, the very same device, when outside a home network, would access the same device using a different address such as http://myhome.dns.com/something/192.168.1.100/. Therefore, a user needs to save a second bookmark on the phone depending upon internal and external access.
Another problem encountered using a HTTP Proxy solution involves the fact that some protocols (example ATOM), require URLs that are absolute. For example, a PVR may have an ATOM feed that exports recordings to the client devices. Within the ATOM xml file of the PVR, there will be a URL like http://192.168.1.100/abc. The gateway should replace it with the external URL. However, current implementations do this only for text/html files. Therefore, new rewrite modules are needed for all protocols.
Finally, another problem encountered using a HTTP Proxy solution involves address translation (html rewrites) that are done in all HTTP protocols. As the process has to scan huge amounts of data, the process is very slow and the translations may not be sufficiently accurate.
Thus, a need exists in the art for a method and apparatus that enables uniform addressing of home resources regardless of device location which overcomes the above shortcoming and limitations of current solutions.
In order to overcome the above-described problems and other problems that will become apparent when reading this specification, the present invention provides methods and apparatus for enabling HTTP based applications to work remotely with each other without the limitations of the prior art solutions. In an aspect of the invention, the usage of the dynamic Domain Name Service (DNS) is extended to both outside and inside a home network. Each home device has a fall host name under the home domain. Same device names are resolved to different IP addresses depending if the DNS lookup request originates from the internal network or external network.
In another aspect of the invention, if the lookup request is accomplished from a device that is within the home network, the reply includes the internal IP address of the device.
Once the address is resolved, a user may directly connect to the device. However, if the lookup request is done from an external device (for example mobile phone, or office PC), the DNS reply should contain the public IP address of the home gateway. In this case, the remote client opens a connection to the gateway device. The gateway now accepts an HTTP connection from a remote device. The remote device makes an HTTP request, and in the HTTP header the field “Host” contains the domain name that the user actually wants to contact. Thus, the gateway may differentiate the requests and forward the requests where (which device) they are targeted.
Other features and advantages of the invention will become apparent with reference to the following detailed description and figures.
The invention will be described in detail in the following description with reference to the following figures wherein:
In the following description of the various embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the invention.
The memory 302 may be implemented with any combination of read only memory modules or random access memory modules, optionally including both volatile and nonvolatile memory. Software 390 may be stored within memory 302 and/or storage to provide instructions to processor 360 for enabling smart device 108 to perform various functions. Alternatively, some or all of smart device 108 computer executable instructions may be embodied in hardware or firmware (not shown).
Further, smart device 108 of present invention is not limited to any particular embodiment for enabling data connectivity or broadcast reception. For example, the smart device 108 may use a circuit switched connection for data connectivity, such as a second-generation wireless system using TDMA (Time Division Multiple Access), CDMA (Code Division Multiple Access), GSM (Global System for Mobile Communications), UMTS/3G, WCDMA or other such access systems. In other examples, the smart device 108 may use a packet based access system, such as GPRS (General Packet Radio Service) over a GSM network, or short range connectivity systems such as WLANs (Wireless local area networks) or BLUETOOTH. With regard to possible broadcast tuning, smart device 108 may receive, for example, analog radio transmissions, digital radio transmissions, such as DAB (Digital Audio Broadcasting), DRM (Digital Radio Modiale), satellite radio transmissions, analog television transmissions, digital television transmissions, such as DMB (Digital Multimedia Broadcasting), DVB-H, and DVB-T, or other such broadcasts.
In an aspect of the invention, gateway 102 may implement a dynamic DNS client. When the public IP address of gateway 102 changes, gateway 102 may notify dynamic DNS provider. The DNS provider may enter the new address in their DNS database. In this example, we suppose that the user has subscribed to an external free dynamic DNS provider, and has mapped the IP address 100.100.100.100 (202) to the name myhome.dns.com (changes of the public IP address are automatically communicated to the DNS provider from the gateway, using existing protocols).
As illustrated in
As home devices 112, 114, 116, and 117 receive their IP address from the DHCP protocol, they are informed that DNS queries should be made to the local DNS server (=gateway=192.168.1.1). Gateway 102 (from the dynamic DNS provider), may have a public domain name myhome.dns.com as illustrated in
The mapping may only be done through the internal DNS server. As such only the resolved names are given to internal devices. At the same time, wildcard resolving may be used on the dynamic DNS provider such that the dynamic DNS provider has the original mapping of: myhome.dns.com=100.100.100.100. Through use of wildcards (*) gateway 102 resolves *.myhome.dns.com=100.100.100.100, where * can be anything. For example PVR 112 may include pvr.myhome.dns.com=100.100.100.100 and pc.myhome.dns.com=100.100.100.100 and anything.myhome.dns.com=100.100.100.100. This mapping is provided by the external DNS server (hosted at the dynamic DNS provider). Therefore, these results are returned to any external host trying to resolve names under the myhome.dns.com sub-domain.
As those skilled in the art will realize from the above discussion home addresses are resolved differently from the same domain name, depending if the requester is in the home network or external to the home network. The case that some client tries to connect to xxx.myhome.dns.com from home network 104 is resolved (from the internal DNS) to one of the internal IP address (192.168.1.yyy), and then the client can directly communicate with the device.
In the case of a remote connection such as smart device 108 trying to connect to the same xxx.myhome.dns.com an attempt to resolve the name is made. Smart device 108 may be given, from the dynamic DNS service provider database, the IP address of gateway 102. An HTTP connection to gateway 102 is opened and an HTTP request is made. From the HTTP headers gateway 102 understands that the connection is for the device xxx.myhome.dns.com, so it connects to that device and makes the same request on behalf of smart device 108. Gateway 102 returns the results to the requester, acting as an HTTP proxy.
In another aspect of the invention, gateway 102 may discover the name of a new home device through UPNP or web server probing. Using UPnP device discovery, a newly added home device may advertise itself and its services to the gateway when connected. From those advertisements, the gateway can get the “friendly” name and assume that this name may be used for naming the device. If multiple devices with the same name are in use, the gateway may add numeral at the end of their names, such as Pvr1, pvr2, etc. Then, from the MAC address information one may ensure that exactly the same name is assigned to the same device every time it reconnects.
In the alternative, web server probing may be used to discover the name of a new home device connected to a home network. When a new device is added, the gateway may try to connect on port 80 of that device, where web servers usually run. If a web server is there, it may try to get the title of the main page, and use that title as the name of the device. As a further alternative, manual configuration may be used to discover the name of a connected new home device where a user may open a configuration page of the gateway and manually assign the desired names. This configuration needs to happen only once per device.
In further aspects of the invention,
In
Existing devices already connected to home network 104 may include a home computer 114, a tablet PC 116, and a VoIP phone 117. In
Once the PVR 602 has IP connectivity, it may announce itself and the services it may provide over UPnP 502 (illustrated as path 706). Gateway 102 receives the announcements and from the UPnP device/service descriptions discovers the friendly name of PVR 602. For example, the friendly name for PVR 602 may be “pvr.”
As illustrated in
In order to resolve the address conflict, tablet PC 116 in accordance with an aspect of the invention may try to contact a Dynamic (DNS) provider as illustrated by server 120 located on Internet 106. The DNS provider may reply through a path 1202 of
In
In another aspect of the invention, as shown in
In other aspects of the invention, gateway 102 may include a DNS server accessible also from the Internet, and act as an authoritative DNS server for the sub-domain .myhome.dns.com. With this approach when an external host is trying to resolve the address (for example) pvr.myhome.dns.com, will not get a direct reply from the dynamic DNS service provider (so no wildcards used in this case). Instead, it will be instructed to contact the DNS server running on the gateway, for resolving the specified name.
In particular
In addition, VoIP phone 117 may reply to the original HTTP response by smart device 108 with information regarding what ports have been allocated for the communication (path 2204). Moreover, smart device 108 may make direct TCP/UDP data transfers through the given port 2002 (
Next, is step 2226 second VoIP phone 2208 may in response to the received message from first VoIP phone 2210 open ports for use in receiving non-HTTP information. In step 2226, second VoIP 2208 forwards its opened port information to first VoIP phone 2210 in the form of a HTTP response. As both VoIP devices (2210 and 2208) have revealed their open port to each other, VoIP communication may begin.
Furthermore, while the present invention has been described with respect to specific examples, those skilled in the art will appreciate that there are numerous variations and permutations of the above described method and system that fall within the spirit and scope of the invention as set forth in the appended claims.