GB2445791A

GB2445791A - Interconnection of Universal Plug and Play Networks using eXtensible Messaging and Presence Protocol Streams

Info

Publication number: GB2445791A
Application number: GB0700901A
Authority: GB
Inventors: Steven Bennett; Iain Stuart Barclay; Richard Sewell; Kevin Vernon
Original assignee: ELECTRICPOCKET Ltd
Current assignee: ELECTRICPOCKET Ltd
Priority date: 2007-01-17
Filing date: 2007-01-17
Publication date: 2008-07-23
Also published as: GB0700901D0; WO2008087374A2; WO2008087374A3

Abstract

The invention allows a client application on a network to discover Universal Plug and Play (UPnP) devices and services on a remote network and retrieve associated content from these devices/services, for example accessing a music/photo collection from a mobile phone. The system encapsulates and relays UPnP protocol messages between networks in eXtensible Messaging and Presence Protocol (XMPP) streams. Home server software 3 and handheld client software 6 establish connections with and XMPP server 10 which relays UPnP messages between them. Once the client has discovered and selected media on the home network a direct TCP link can be established to deliver the media stream. The system can be set up so that only home network resource advertisements are relayed, or the transfer can be two way.

Description

SYSTEM AND METHOD FOR REMOTELY ACCESSING

UNIVERSAL PLUG AND PLAY (UPnP) NETWORKS The present invention relates generally to networking and more particularly to accessing devices and services on one network from another network. In particular, though not exclusively, the invention relates to systems and methods for allowing a client application on a network to discover remote Universal Plug and Play (UPnP) devices and services on another network and retrieve associated content from these devices/services.

Universal Plug and Play (UPnP) is a network architecture that allows peer to peer network connectivity of devices such as personal computers (PCs), intelligent appliances and wireless devices. UPnP enables such devices to connect seamlessly and simplifies the implementation of networks in the home (e.g. for data sharing, communications and entertainment) and corporate envfronments. The UPnP Forum (http://www.upnp.org) defines and publishes the standards (e.g. network protocols) that define UPnP networking. UPnP is built upon open, Internet-based communication standards including IP, TCP, UDP HTTP and XML and enables data communication between any two devices under the command of any control device on the UPnP network. Any operating system and any programming language can be used to build UPnP products.

The foundation for UPnP networking is IF addressing. In UPnP networking a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request and learn about the presence and capabilities of other devices. This is achieved by following various steps in the UPnP networking process. These steps are well known and understood in the art. Once an IP address has been obtained for the device, the first step in UPnP networking is discovery in which the UPnP discovery protocol is used to advertise the device's services to control points on the network. Similarly, when a control point is added to the network the UPnP discovery protocol allows that control point to search for devices of interest on the network. The UPnP discovery protocol is based on the Simple Service Discovery Protocol (SSDP).

The further steps in the UPnP networking process include description, (in which the control point retrieves the device's description from the URL provided by the device in the discovery step), control, event notification, and presentation.

Using UPnP data, such as audio files, video or still images, can be shared between different devices in the UPnP network. For example, music files can be transferred from one device to another in a UPnP network of devices in a user's home.

It may sometimes be desirable to remotely access a UPnP network in order to retrieve media content associated therewith. For example, a user may desire to browse and play music from their home PC on a Smartphone via the cellular data network. Or a user who is visiting a friend may wish to be able to access music files or images stored on their home UPnP network in order to play/view them on the friend's home UPnP network.

One disadvantage of UPnP is that it generally only enables networking of devices which are in close proximity to one another, for example in a home or office environment. This makes remote accessing of UPnP networks difficult. Previous proposed solutions to these goals have relied on internet messaging protocols such as Simple Object Access Protocol (SOAP) and/or other Web services to relay UPnP messages between the networks. See, for example, Intel Corporation's Intel Device Relay which uses SOAP to effectively mirror a UPnP device on one network onto a different network. (See Intel Tools for UPnP Technologies at http://www.inteI.com/cd/ids/developer/asmo na/engJdownloads/upnp/overview/index.htm#anchor 3 and downloadable from http://www.intel. com/cd/ids/deve1oper/asmo-na/engldownloads/upnp/overview/21 8893.htm?desturl=21 8891.htm.) In this technique UPnP messages are translated into SOAP requests which are sent to the remote network. Use of SOAP and other Web services require separate management and configuration of firewalls and Network Address Translation (NAT) routers which is a significant disadvantage. Moreover there are security and privacy issues associated with this approach as it allows all devices on each network to be seen by each other e.g. If a user is in an office network then all the other users on the office network would be able to "see" the user's home media server and content from the office. Furthermore, in the Intel solution the UPnP devices are proxied and appear as real devices on the remote network with changed IP addresses on the same subnet as the remote network. The Intel solution handles the UPnP SSDP messages locally and sends events and commands via SOAP to the far end. This has the disadvantage that the bandwidth and processing power required therefore scales as the number of local and remote devices increases.

It is an aim of the present invention to avoid or minimise one or more of the foregoing disadvantages.

According to a first aspect of the present invention there is provided a method of linking separate UPnP networks, wherein the method comprises using XMPP to encapsulate and relay UPnP protocol messages between the networks. In particular, though not exclusively, the method may comprise using XMPP to encapsulate and relay UPnP protocol messages between a first network (for example a home network) and a remote network so as to allow devices and content on the first network to be accessed from the remote network. It will be understood that a "remote network" in the context of this application is one from which it is not possible to discover UPnP Media Servers and Devices using standard UPnP protocol and services.

The Extensible Messaging and Presence Protocol (XMPP) is the IETFs formalisation of the base XML streaming protocols for instant messaging and presence developed within the Jabber community and is an open XML technology for real-time communications, which powers a wide range of applications including instant messaging, presence, media negotiation and generalised XML delivery among others.

The core protocol is defined by the RFC 3920 and RFC 3921 standards. There also exist many XMPP extensions for functionality which are generally specified in the XEP series published by the Jabber Software Foundation.

One significant advantage of using XMPP to encapsulate and relay the UPnP protocol messages in the present invention is that it enables firewalls and NAT routers to be traversed automatically.

Preferably, UPnP Discovery and Description requests are encapsulated in XMPP message stanzas. For example, in a preferred embodiment UPnP Discovery requests and responses are encapsulated into XMPP headline message stanzas and UPnP Description requests and responses are encapsulated into XMPP chat message stanzas.

According to a second aspect of the invention there is a provided a system for linking two separate UPnP networks, wherein the system comprises a server software object for installing on a first one of said UPnP networks, client software for installing on a device for connection to a second one of said UPnP networks, and an XMPP server accessible to both said first UPnP network and said device. The first UPnP network and the device may, for example, access the XMPP server via the internet. The server software object and client software are preferably configured to encapsulate and relay UPnP protocol messages (sometimes alternatively referred to as "UPnP protocol traffic" or simply "UPnP traffic") between said first and second UPnP networks, via the XMPP server.

The device may be a mobile device. For example, the device may be a mobile phone or any other device, hand-held or otherwise, enabled with the facility to communicate over a cellular data network (for example a messaging device such as a Blackberry device). However, the device may alternatively simply be enabled with the facility to communicate over a wifi or wired internet network. Thus the device may, for example, be a laptop or desktop PC which is located remotely from the first UPnP network and is capable of connecting to the internet. For example, the first UPnP network may be located in a first house and said laptop or desktop PC may be located in a second house containing the second UPnP network.

In the method according to the first aspect of the invention, where the method is used to link two UPnP networks, respective data processing units in each of the UPnP networks are preferably uniquely identified and the method preferably includes establishing a one-to-one communication channel between the two networks for relaying UPnP protocol traffic therebetween. Advantageously, said communication channel may be configured so as to carry solely UPnP protocol traffic. Preferably, the method includes filtering UPnP protocol traffic between the two networks. Most preferably, the traffic is filtered so that the tunnel does not carry UPnP Service Discovery requests from the first network (i.e. the home network) or UPnP Service notifications from the second (i.e. the "away") network. This has the advantage of reducing the required bandwidth and providing better performance. For example, where the device is a mobile phone, such devices typically have limited energy sources (battery) and slower processors than desktop computing devices. By filtering and reducing the amount of traffic between the two networks less processing is required by the mobile device and hence more processing time is available for other tasks and less power is used by the client UPnP task.

Optionally the method may include encrypting the encapsulated UPnP protocol messages prior to relay thereof.

The method may further comprise creating a separate TCP data connection or "tunnel" between the two UPnP networks for sending large objects such as, for example, music files and word documents between the two networks. This tunnel may, for example, comprise a peer to peer connection to transmit content data (e.g. music files) from one network to the other, or alternatively, a relay connection. Techniques for creating such connections are well-known, for example libjingle, ICE and STUN. For smaller data objects the data content of the object may instead be sent via XMPP encapsulation and relay. Encryption and/or secure protocols may be used for sending the content data.

In the system according to the above-described second aspect of the invention the client software and the server software object are preferably configured so as to create and register a new pair of respective network addressable jdentities or "IDs" and a pair of corresponding passwords with the XMPP server. Preferably, the client software and server software object are configured to do this upon their installation.

This enables a one-to-one communication channel to be established between the client software and server software object, for relaying UPnP traffic therebetween via the XMPP server. Preferably the client software and server software object are configured to, upon initiation of the client software, establish mutual presence on the XMPP service a a a provided by the XMPP server and to subsequently communicate with each other over XMPP using XMPP Messaging and Query/Response services.

Preferably, the-client software and server software object (hereinafter referred to as "the software components") are configured to transmit received relayed UPnP protocol messages on their own respective one of said networks so that UPnP devices on said respective networks can receive them. Conveniently, the software components may each be configured to listen for UPnP traffic on their own respective one of said networks and encapsulate and relay this UPnP traffic to the complementary software component on the other (remote) network. Most preferably, the software components are configured so as to be capable of differentiating between traffic addressed to local and remote device IDs and to ignore traffic that has local relevance only and relay the rest of the traffic to the remote network. Optionally, the software components may be configured to encrypt the encapsulated UPnP traffic.

According to a third aspect of the invention there is provided a method of linking two separate UPnP networks, wherein the method comprises establishing a one-to-one communication channel between the two networks which channel carries solely UPnP protocol traffic. -According to a fourth aspect of the invention there is provided a system for linking separate UPnP networks, wherein the system comprises a server software object for installing on a first one of said UPnP networks, client software for installing on a device for connection to a second one of said UPnP networks, and an intermediate network server accessible to both said first network and said device, and wherein the server software object and the client software are configured to establish a communication channel therebetween via said network server which channel carries solely UPnP protocol traffic. Preferably, the client software receives only UPnP SSDP advertisement and discovery response messages from the home network. i.e. the server software object preferably does not transmit discovery search requests from the home network to the away network, and the client software preferably does not transmit SSDP advertisements from the away network to the home network. This has the advantage of reducing the bandwidth and processing requirement of the system.

Preferred embodiments of the invention will now be described by way of example only and with reference to the accompanying Figures in which: Figure 1 is a schematic drawing of a system according to one embodiment of the invention; and Figure 2 is a flow diagram illustrating message flow in the system of Figure 1.

Figure 1 illustrates an inventive network configuration for accessing a home media server from a mobile device (which in this embodiment is a hand-held mobile phone) which is remote from the home media server. The system comprises: a home network 1 with UPnP enabled media server 2 and a desktop PC 3a with a server software object 3 (hereinafter referred to as "the Server" 3) installed thereon, optionally behind a NAT firewall 4; a mobile device 5 with client software 6 (hereinafter referred to as the Client software 6) installed thereon, the mobile device being connected to a network 7 which is remote from the home network I (this remote network 7 is hereinafter referred to as the "away" network) and has its own UPnP enabled media server 11 (not shown in Fig.1) and is optionally behind a remote firewall and NAT 9; and an XMPP server 10 accessible to both the home network and the mobile device (e.g. via the internet).

The Server 3 and Client software 6 are complementary pieces of software as will be described below. In this embodiment the home media server 2 is on the same machine as the Server 3 (but in other possible embodiments they may be on separate machines).

With reference to Fig.2, the Client software 6 consists of a modified UPnP Media Controller 12, Media renderer 14 and a UPnP proxy service 16 (hereinafter referred to as the "Client Proxy"). The proxy service 16 may be integrated in the Client software 6 r in a separate software object (not shown).

The mode of operation of (i.e. message flow in) the system of Figure 1 is illustrated in Figure 2. The various phases of the message flow will now be described in detail and sequentially, with reference to Figure 2.

Identification and Discovery phases The Client software 6 and the Server 3 know each other's XMPP IDs. This is accomplished at installation time by creating and registering a new pair of IDs and passwords with the XMPP server 10 and setting them in the Server 3 and Client software configuration files. The Server 3 is always logged onto the XMPP service provided by the XMPP server 10. When the Client software 6 is started it logs onto the same XMPP service, spots the presence of its complementary Server 3 and sends its presence information to the Server 3.

Having established mutual presence the Server 3 and Client software 6 then communicate to each over XMPP using the XMPP Messaging and Query/response services.

The UPnP Media Controller 12 of the Client software 6 issues a UPnP discovery request (multicast) on its local host interface. The UPnP Client Proxy 16 listens for multicasts on the local host interface. It encapsulates 22 the content (headers) of any discovery request it hears into an XMPP headline message stanza using Base64 encoding and sends 24 the XMPP headline message stanza to the XMPP server addressed to the Server 3.

Listening to the local host interface as well as the normal (i.e. local) network interface is an important part of the solution according to this embodiment. If the away network 7 doesn't support multicasting (e.g. Carrier Mobile phone Internet networks) then listening only on the normal network interface will not hear requests.

The XMPP message stanza type (headline or chat) is used to distinguish between encapsulated discovery requests/responses/notifications and encapsulated description requests/responses.

The XMPP message arrives at the home network Server 3. The encapsulated UPnP discovery request is extracted and base64 decoded from the XMPP message (i.e. "unpacked") 26 and sent via UDP multicast 27 (the standard UPnP method) on both the local network and local host network interfaces of the home network desktop PC 3a.

Responses 29 to the multicast requests are received by the Server 3. The content of the response is base64 encoded and encapsulated 28 in an XMPP headline message. The message is sent 30 to the Proxy 16 of the Client software (via the XMPP server).

The Client Proxy 16 extracts (i.e. Unpacks) 32 the discovery response and sends it via UDP unicast (the standard UPnP method) 34 to the IP address and port that the original Discovery request came from (i.e. the modified UPnP Media Controller 12).

The modified UPnP Media controller 12 needs to identify whether the discovery response is for a device on its local network (the away network 7) or the remote network (the home network 1) so that it can send the subsequent description requests directly on the local network or via the XMPP encapsulation relay technique. It uses the IP address the response came from and the IP address of the service description in the response to do this. For the implementation of Figure 1 and 2 on a mobile device 5 with the modified UPnP Media Controller 12 and Client Proxy 16 on the same device and the assumption that there is no media server on the device 5 it is sufficient to spot if it came from a local host. If it did the response is marked 56 as being from a local device, If it did not then it is a response from a remote service and is marked 58 as such.

This algorithm is extended and modified for the cases where the Away UPnP Media Controller 12 and Away Client Proxy 16 are not on the same IP address or a media server is present on the same IP address or local host 7. If the IP addresses don't match then it is remote. If the IP addresses match it is local. For the case where the remote media server URL has the same IP address as the Client software the IP addresses will match and an attempt to open a socket to the URL address is used to determine if it is local (socket success) or remote (socket open fails).

Subsequent Service Notifications on the home network I are encapsulated and relayed via the Server 3 to the Client software 6 using the same methods as for discovery request responses.

Various levels of filtering are implemented by the Client software 6 and Server 3 to minimise UPnP traffic relaying depending on the specific implementation requirements.

For instance, in this client/server implementation, Service Discovery requests from the home network I are not needed and therefore are not relayed to the away network 12.

Similarly Service notifications on the away network 12 are not needed or relayed to the home network 1.

It will though be appreciated that if the invention were to be used in a full bridging implementation then these messages would be needed and therefore would not be filtered.

Service Description phase

The next phase in UPnP is Service Description. The Client software 6 asks the devices it has discovered what services they provide using Service Description requests. The modified UPnP Media Controller 12 of the Client software 6 on the away network 7 encapsulates 40 the contents of the service description requests 38 (http get) for remote devices into an XMPP chat message using base64 encoding. It adds an XMPP ID element to the message that identifies the IP address and port that the request was sent from (e.g. 192.168.1.1:8912) and sends it 42 to the Server 3 in the home network 1.

The XMPP message Stanza type (headline or chat) is used to distinguish between encapsulated discovery traffic and encapsulated description requests. The Server 3 unpacks 44 the Service Description request and opens a socket and makes a service request 45 on its network to the URL address in the request. It tags the socket with the id of the XMPP message so that if the request from the Client is segmented (split over 2 or more tcp segments) then the ID in the XMPP message can be be used to select the same socket at the Server end to send it over (e.g. a simple session method).

When the Server 3 gets a response 46 it encapsulates it 47 in an XMPP chat message, adds the source IP address and port that the response was sent from to the IP address and Port from the encapsulated discovery requested ID (e.g. if the response came from 192.168.2.1:54533 then the ID is set to 192.168.1.1:8912/192.168.2.1:54533) and sets the id element of the message to it. It then sends 48 the XMPP chat message to the Client Proxy 16.

The Client Proxy 16 unpacks 50 the encapsulated response and uses the first part of the id of the message (e.g. 192.11 68.1.1:8912) to determine where to send the response 52 to (http response) on the away network 12 and if to use an existing socket (e.g. if the response is segmented).

Content browsing and content retrieval phase When the UPnP service discovery and service description phases are complete the content of the local and remote UPnP devices can be browsed 54. The Client software 6 knows if the parent nodes (devices) of the browse tree are local or remote from the service discovery and notification phases. If the UPnP device is remote the browse requests are encapsulated and relayed in the same way as for Service Description requests.

The child nodes inherit the local/remote attribute so that when the user has browsed to the remote data object that they want to obtain (e.g. a music track or album, photo, video footage) the URL in the UPnP description object is used to make a request for the data and the client uses the local/remote attribute to determine whether to make a local request (e.g. http get) or make a remote request using the XMPP encapsulation and relaying technique.

The data content of the object can be sent back via XMPP encapsulation for small data objects. For large objects (e.g. music files, word documents etc.) a separate TCP data connection is made between the Client software 6 and Server 3. This may be a direct peer to peer connection or indirect via a relay. The methods for creating this connection are well known (e.g. see Libjngle, ICE and STUN). Optionally, the bitrate of the source media files (at the Server side) is transcoded before the files are transferred to the Client software 6, in order to ensure that desired end to end bandwidth requirements are met.

It will be readily appreciated that the above-described embodiment may be used to send a variety of types of data content from a home network to a remote network. For example, the method or system may be used to: (a) send music data from a home network to an away network for playing on a music renderer forming part of the away network; (b) send photo data from a home network to an away network for viewing on a photo renderer forming part of the away network; (c) send video data from a home network to an away network for playing on a video renderer forming part of the away network; (d) send application specific data from a home network to an away network to be used by an application on the away network.

It will be appreciated that network connections in the above described embodiment may be via any suitable means such as, for example, wired network connections or WiFi.

Furthermore, it will be understood that various modifications and additions to the above-described embodiment are possible within the scope of the invention. For example, the Client software 6 need not be installed on a mobile device: instead it could, for example, be installed on a personal computer (PC) which is connected to the same XMPP server 10 as the Server 3. This PC may form a component of the away UPnP network 7 or be otherwise connected to the away network 7.

In another possible embodiment, the mobile device 5 may be a Smartphone equipped with a Music Player application which is capable of playing music files retrieved from the home network using the above-described method for encapsulating and relaying UPnP protocol messages using XMPP.

In other possible embodiments more than two UPnP networks may be linked in a similar manner as described above, using XMPP to encapsulate and relay UPnP protocol messages between the networks.

In further possible modified embodiments an intermediate network server utilising a different technology to XMPP may be used to perform the encapsulation and relay of UPnP protocol messages between the networks. For example other Instant Messaging and Presence protocols such as Open Mobile Alliance's IMPS (see http://en.wikipedia.org/wiki/IMPS and http://www.openmobilealliance.org/releaseprogram/imps_vl_3.html) , SIP/SIMPLE (http://en.wikipedia.orgJwikifSIMPLE and http://www.ietf.orglhtml.charters/simple charter.html) and proprietary protocols such as Yahoo! Messenger, AOL's AIM (AOL Instant Messenger) and Microsofts MSN Messenger could be used.

Claims

l.A method of linking separate UPnP networks, wherein the method comprises using XMPP to encapsulate and relay UPnP protocol messages between the networks.
2.The method according to claim 1 comprising using XMPP to encapsulate and relay UPnP protocol messages between a home network and a remote network so as to allow devices and content on the home network to be accessed from the remote network.
3.The method according to claim 1 or claim 2, wherein UPnP Discovery and Description requests are encapsulated in XMPP message stanzas.
4.The method according to claim 3, wherein UPnP Discovery requests and responses are encapsulated into XMPP headline message stanzas and UPnP Description requests and responses are encapsulated into XMPP chat message stanzas.
5.The method according to any one of the preceding claims, where the method is used to link two UPnP networks, wherein respective data processing units in each of the UPnP networks are uniquely identified and the method includes establishing a one-to-one communication channel between the two networks for relaying UPnP protocol traffic therebetween.
6.The method according to claim 5, wherein said communication channel is configured so as to carry solely UPnP protocol traffic.
7.The method according to claim 5 or claim 6, wherein the method includes filtering UPnP protocol traffic between the two networks.
8.The method according to claim 7, wherein the UPnP protocol traffic is filtered so that the communication channel does not carry UPnP Service Discovery requests from a first one of the networks or UPnP Service notifications from a second one of the networks.
9.The method according to any one of claims 5 to 8, further comprising creating a separate TCP data connection between the two said UPnP networks for sending large amounts of data content between the two networks.
10. The method according to any one of the preceding claims, wherein the bit rate of data files to be transferred from a first one of the networks to a second one of the networks is transcoded at the first network side before transfer to the second network.
11. The method according to any one of the preceding claims, further comprising encrypting the encapsulated UPnP protocol messages prior to relay thereof.
12.A system for linking two separate UPnP networks, wherein the system comprises a server software object for installing on a first one of said UPnP networks, client software for installing on a device for connection to a second one of said UPnP networks, and an XMPP server accessible to both said first UPnP network and said device.
13. The system according to claim 12, wherein the first UPnP network and the device are configured to access the XMPP server via the internet.
14. The system according to claim 12 or claim 13, wherein the server software object and the client software are configured to encapsulate and relay UPnP protocol messages between said first and second UPnP networks, via the XMPP server.
15. The system according to claim 14, wherein the client software and the server software object are configured to encrypt the encapsulated UPnP traffic.
16. The system according to any one of claims 12 to 15, wherein the client software and the server software object are configured to create and register a new pair of respective network addressable identities and corresponding passwords with the XMPP server.
17. The system according to claim 16, wherein the client software and the server software object are configured to, upon initiation of the client software, establish mutual presence on the XMPP service provided by the XMPP server and to subsequently communicate with each other over XMPP using XMPP Messaging and Query/Response services.
18. The system according to any one of claims 12 to 17, wherein the client software and the server software object are configured to transmit received relayed UPnP protocol messages on their own respective one of said networks so that UPnP devices on said respective networks can receive them.
19, The system according to claim 18, wherein the client software and the server software object are each configured to listen for UPnP traffic on their own respective one of said networks and to encapsulate and relay this UPnP traffic to the other one of the client software and the server software object on the other network.
20. The system according to claim 19, wherein the client software and the server software object are each configured so as to be capable of differentiating between traffic addressed to local and remote device IDs and to ignore traffic that has local relevance only and to relay the rest of the traffic to the remote one of the networks.
21. The system according to any one of claims 12 to 20, wherein the device is a mobile phone.
22. A method of linking two separate UPnP networks, wherein the method comprises establishing a one-to-one communication channel between the two networks which channel carries solely UPnP protocol traffic.
23. A system for linking separate UPnP networks, wherein the system comprises a server software object for installing on a first one of said UPnP networks, client software for installing on a device for connection to a second one of said UPnP networks, and an intermediate network server accessible to both said first network and said device, and wherein the server software object and the client software are configured to establish a communication channel therebetween via said network server, which channel carries solely UPnP protocol traffic.
24. The system according to claim 23, wherein the client software receives only UPnP SSDP advertisement and discovery response messages from the home network.
25. A method of providing a client on first network access to UPnP resources on a second network where the UPnP resources omit local JP addresses, the method having the steps of: a) relaying UPnP traffic between the client and the second network; and b) modifying the client's interpretation of the UPiIP traffic to allow the remote network traffic to be used by the client.
26. A method according to Claim 25, wherein the method uses one or more protocols selected from the group consisting of XMPP, SIP, Yahoo, AIM, and MSN.
27.A network configuration for accessing a home media server from a device remote from the home media server, as described herein and with reference to Figures 1 and 2.
28. A method of linking separate UPnP networks as described herein and with reference to Figures 1 and 2.