WO2007060564A2

WO2007060564A2 - Translator for translating addresses of packets

Info

Publication number: WO2007060564A2
Application number: PCT/IB2006/054139
Authority: WO
Inventors: Mariana Simons-Nikolova
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-11-22
Filing date: 2006-11-07
Publication date: 2007-05-31
Also published as: WO2007060564A3

Abstract

Translators (15) for translating addresses of packets are provided with input parts (51) for receiving first packets comprising first headers and first payloads comprising first payload-addresses and with payload translator parts (61) for translating the first payload- addresses into second payload-addresses and with output parts (52) for supplying second packets comprising second headers and second payloads comprising the second payload- addresses, to allow the translators (15) to be used in a universal plug and play environment. The translators (15) may further comprise header translator parts (62) for translating first header-addresses into second header-addresses in dependence of translation results originating from the payload translator parts (61), the first headers comprising the first header-addresses and the second headers comprising the second header-addresses. The payload-addresses and header-addresses may be IPv4 / IPv6 addresses and the packets may be IP packets. Basic universal plug and play mechanisms - such as discovery, description, control, eventing, presentation - can be used advantageously.

Description

Translator for translating addresses of packets

The invention relates to a translator for translating addresses of packets, and also relates to a translator device comprising a translator, to a universal plug and play system comprising a translator device, to a method for translating addresses of packets, to a computer program product for translating addresses of packets and to a medium comprising a computer program product.

Examples of such a translator device are home network devices such as personal computers, audio and/or video receivers, audio and/or video players, audio and/or video recorders and set top boxes.

A prior art translator device is known from US 6,038,233, which discloses a translator device for IP networks. This translator device comprises a translator for translating IPv4 header-addresses of IPv4 packets into IPv6 header-addresses for IPv6 packets and for translating IPv6 header-addresses of IPv6 packets into IPv4 header-addresses for IPv4 packets. The translator device is located between an IPv4 network and an IPv6 network.

The known translator is disadvantageous, inter alia, owing to the fact that it cannot be used in a universal plug and play environment system, such as a universal plug and play system. The reason for this is that in a universal plug and play system the translation of header-addresses depends on the universal plug and play environment.

It is an object of the invention, inter alia, to provide a translator for translating addresses of packets, which translator can be used in a universal plug and play environment.

Further objects of the invention are, inter alia, to provide a translator device comprising such a translator, to provide a universal plug and play system comprising such a translator device, to provide a method for translating addresses of packets, which method can be used in a universal plug and play environment, a computer program product for translating addresses of packets through performing such a method, and to provide a medium comprising such a computer program product. The translator according to the invention for translating addresses of packets is defined by comprising: an input part for receiving a first packet, the first packet comprising a first header and a first payload, the first payload comprising a first payload-address, - a payload translator part for translating the first payload-address into a second payload-address, and an output part for supplying a second packet, the second packet comprising a second header and a second payload, the second payload comprising the second payload- address. By introducing the payload translator part, the translator according to the invention can be used in a universal plug and play environment. The reason for this is that, in a universal plug and play system, not just the headers of the packets carry address information, but the payloads of the packets also carry address information. In a universal plug and play environment, the address information carried by the payloads might be considered to be primary address information, and the address information carried by the headers might be considered to be secundary address information.

An embodiment of the translator according to the invention is defined by the translator further comprising: a header translator part for translating a first header-address into a second header-address in dependence of a translation result originating from the payload translator part, the first header comprising the first header-address and the second header comprising the second header-address.

By introducing the header translator part, the header-addresses can be translated as well. In the prior art situation, the header-addresses were translated independently. According to the invention, the header-addresses are not translated independently but are translated in dependence of translation results originating from the payload translator part. In other words, the secundary (following) address information in the form of a header-address is derived from the primary (leading) address information in the form of a payload-address. An embodiment of the translator according to the invention is defined by the respective first and second payload-addresses being respective IPv4 and IPv6 addresses or respective IPv6 and IPv4 addresses, the respective first and second header-addresses being respective IPv4 and IPv6 addresses or respective IPv6 and IPv4 addresses, and the packets being IP packets. Other kinds of addresses such as asynchronous transfer mode addresses or medium access control addresses and other kinds of packets such as asynchronous transfer mode packets or medium access control packets are not to be excluded.

An embodiment of the translator according to the invention is defined by the respective first and second payload-addresses comprising respective first and second host addresses, the first host address comprising a respective IPv4 or IPv6 multicast address and the second host address comprising a respective IPv6 or IPv4 multicast address.

A basic universal plug and play mechanism is the discovery mechanism. During the discovery mechanism, the payloads of packets exchanged between incompatible address services may comprise "Advertisement: device (un)available" messages, "M- SEARCH" messages and "Search response" messages. The translator according to the invention translates, for the "M-SEARCH" messages and the "Advertisement: device (un)available" messages, a HOST header value address comprising an IPv4 multicast address into an IPv6 multicast address and vice versa, to improve the efficiency of the discovery mechanism in the universal plug and play environment (no human interaction required although incompatibility being present).

An embodiment of the translator according to the invention is defined by the respective first and second payload-addresses comprising respective first and second location addresses, the first location address comprising an original URL and the second location address comprising a translated URL, the original URL comprising an original host component and an original path component, the translated URL comprising a translated host component and a translated path component, the translated path component comprising the original host component and the original path component.

The translator according to the invention translates, for the "Search response" messages and the "Advertisement: device available" messages, a LOCATION header value address according to an algorithm. This algorithm translates the original URL (for example http://IPv6addrUPnPservice/file) into the translated URL (for example http://IPv4addrT15/IPv6addrUPnPservice/file), the original URL comprising the original host component (IPvόaddrUPnPservice) and the original path component (file), the translated URL comprising the translated host component (IPv4addrT15) and the translated path component (IPv6addrUPnPservice/file), such that the translated path component comprises the original host component and the original path component, to improve the efficiency of the discovery mechanism in the universal plug and play environment (no human interaction required although incompatibility being present). An embodiment of the translator according to the invention is defined by the respective first and second header-addresses comprising the respective first and second host addresses. The translator according to the invention translates, for the "M-SEARCH" messages and the "Advertisement: device (un)available" messages, the respective first header-destination address into a second header-destination address by making this address equal to the HOST header value in the translated payload, to improve the efficiency of the discovery mechanism in the universal plug and play environment (no human interaction required although incompatibility being present). The translator according to the invention translates, for the "Search response" messages, the first header- destination address (for example IPv6addrT15 or IPv4addrT15 respectively) into the second header-destination address (for example IPv4addrCP35 or IPv6addrCP35 respectively), to improve the efficiency of the discovery mechanism in the universal plug and play environment (no human interaction required although incompatibility being present).

An embodiment of the translator according to the invention is defined by the first payload comprising an original http request for a http response and the second payload comprising a translated http request for the http response, the original http request comprising a first get part and a first host part, the translated http request comprising a second get part and a second host part, the first get part comprising an address of a media point of a media device and a description part and the second get part comprising the description part without the address of the media point, the first host part comprising the first payload-address defining the translator of a translator device and the second host part comprising the second payload-address defining the media point, the second payload-address being equal to the address of the media point.

A basic universal plug and play mechanism is the description mechanism. During the description mechanism, the payloads of packets exchanged between incompatible address services may comprise GET request line and HOST header parts. The translator according to the invention translates the LOCATION header address discussed for the discovery mechanism according to the algorithm discussed for the discovery mechanism. The translator according to the invention uses a further algorithm to translate the original http get request for the http response into the translated http get request for the http response. According to this further algorithm, the first get request (for example GET IPvβaddrMP/description.xml HTTP /1.1) is translated into the second get request (for example GET description.xml HTTP /1.1) by removing the address of the media point (for example IPvβaddrMP) of the media device. According to this further algorithm, the first HOST header part (for example HOST: IPv4addrT15) is translated into the second HOST header part (for example HOST: IPvβaddrMP) by taking the address of the media point of the media device from the first GET request., to improve the efficiency of the description mechanism in the universal plug and play environment (no human interaction required although incompatibility being present).

An embodiment of the translator according to the invention is defined by the payload translator part being arranged to translate a http body of the http response into a translated http body, the http body comprising a description document and the translated http body comprising a translated description document. The translator according to the invention uses a yet further algorithm to translate the description document of the http body into the translated description document of the translated http body. As a result, the description document can be retrieved even in case of incompatibility being present in the universal plug and play environment.

An embodiment of the translator according to the invention is defined by the first payload comprising an original request for a http response and the second payload comprising a translated request for the http response, the original request comprising a first post part and a first host part, the translated request comprising a second post part and a second host part, the first post part comprising an address of a media point of a media device and a control part and the second get part comprising the control part without the address of the media point, the first host part comprising the first payload-address defining the translator of a translator device and the second host part comprising the second payload-address defining the media point, the second payload-address being equal to the address of the media point.

A basic universal plug and play mechanism is the control mechanism. During the control mechanism, the payloads of packets exchanged between incompatible address services may comprise POST request line and HOST header parts. The translator according to the invention translates the first post part (for example POST IPvβaddrMP/MPCntrl HTTP) into the second post part (for example POST MPCntrl HTTP) by removing the address of the media point (for example IPvβaddrMP) of the media device. The first HOST header part (for example HOST: IPv4addrT15) is translated into the second HOST header part (for example HOST: IPvβaddrMP) by taking the address of the media point of the media device from the first POST request., to improve the efficiency of the control mechanism in the universal plug and play environment (no human interaction required although incompatibility being present). An embodiment of the translator according to the invention is defined by the first payload comprising an original request for a http response and the second payload comprising a translated request for the http response, the original request comprising a first subscribe part and a first host part and a first callback part, the translated request comprising a second subscribe part and a second host part and a second callback part, the first subscribe part comprising an address of a media point of a media device and a publisher part and the second subscribe part comprising the publisher part without the address of the media point, the first host part comprising the first payload-address defining the translator of a translator device and the second host part comprising the second payload-address defining the media point, the second payload-address being equal to the address of the media point, the first callback part comprising an address of a control point and the second callback part comprising an address of the translator.

A basic universal plug and play mechanism is the eventing mechanism. During the eventing mechanism, the payloads of packets exchanged between incompatible address services may comprise SUBSCRIBE request line and HOST and CALLBACK header parts. The translator according to the invention translates the first subscribe part (for example SUBSCRIBE IPvβaddrMP/MPEvents HTTP) into the second subscribe part (for example SUBSCRIBE MPEvents HTTP) by removing the address of the media point (for example IPvβaddrMP) of the media device. The first HOST header part (for example HOST: IPv4addrT15) is translated into the second HOST header part (for example HOST:

IPvβaddrMP) by taking the address of the media point of the media device from the first SUBSCRIBE request line . The first CALLBACK header part (for example CALLBACK: IPv4addrCP35) is translated into the second CALLBACK header part (for example CALLBACK: IPv6addrT15) by using the IP address of the subscriber, to improve the efficiency of the eventing mechanism in the universal plug and play environment (no human interaction required although incompatibility being present).

An embodiment of the translator according to the invention is defined by the first payload comprising an original request for a http response and the second payload comprising a translated request for the http response, the original request comprising a first get part and a first host part, the translated request comprising a second get part and a second host part, the first get part comprising an address of a media point of a media device and a presentation part and the second get part comprising the presentation part without the address of the media point, the first host part comprising the first payload-address defining the translator of a translator device and the second host part comprising the second payload- address defining the media point, the second payload-address being equal to the address of the media point.

A basic universal plug and play mechanism is the presentation mechanism. During the presentation mechanism, the payloads of packets exchanged between incompatible address services may comprise GET request line and HOST header parts. The translator according to the invention translates the first GET request line part (for example GET IPvβaddrMP/presentation.html HTTP) into the second GET request line part (for example GET presentation.html HTTP) by removing the address of the media point (for example IPvβaddrMP) of the media device. The first HOST header part (for example HOST: IPv4addrT15) is translated into the second HOST header part (for example HOST:

IPvβaddrMP) by taking the address of the media point of the media device from the first GET request line, to improve the efficiency of the presentation mechanism in the universal plug and play environment (no human interaction required although incompatibility being present). An embodiment of the translator according to the invention is defined by the payload translator part being arranged to translate a http body of http response into a translated http body, the http body comprising a presentation document and the translated http body comprising a translated presentation document.

The translator according to the invention uses a next yet further algorithm to translate the presentation document of the http body into the translated presentation document of the translated http body. As a result, the presentation document can be retrieved even in case of incompatibility being present in the universal plug and play environment.

Embodiments of the translator device according to the invention and of the universal plug and play system according to the invention and of the method according to the invention for translating addresses of packets and of the computer program product according to the invention for translating addresses of packets and of the medium according to the invention correspond with the embodiments of the translator according to the invention. For example the translator device may comprise the translator as defined in any one of the embodiments already discussed and/or still to be discussed. The invention is based upon an insight, inter alia, that in a universal plug and play environment, the payloads carry primary (leading) address information and the headers carry secundary (following) address information, and is based upon a basic idea, inter alia, that a payload translator part is to be introduced for translating a first payload-address in a first payload of a first packet into a second payload-address in a second payload of a second packet.

The invention solves the problem, inter alia, to provide a translator for translating addresses of packets, which translator can be used in a universal plug and play environment., and is further advantageous, inter alia, in that address incompatibility in universal plug and play systems is solved.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments(s) described hereinafter.

In the drawings:

Fig. 1 shows diagrammatically a universal plug and play system according to the invention comprising a translator device according to the invention and further comprising a media device and a control device, the translator device comprising a translator according to the invention,

Fig. 2 shows in flow chart form an algorithm for solving an interoperability issue in a universal plug and play environment, and

Fig. 3 shows diagrammatically a translator according to the invention in greater detail as well as information exchanged between this translator and a control point and between this translator and a media server.

Initially, the universal plug and play stack (UPnP stack) was designed and implemented on top of the standard transmission control protocol/internet protocol stack (TCP/IP stack) for the Internet Protocol version 4 (IPv4). However, IPv4 will be gradually replaced in the future by the Internet Protocol version 6 (IPv6), with the two coexisting during a migration phase. This has impact on the UPnP device architecture and the audio/video architecture (A/V architecture). The latter may comprise three different components - a Media Server (MS), a Media Renderer (MR) and a Control Point (CP) or may comprise two different components - a media point (MP) and a CP, whereby the MP can be either a MS or a MR. In heterogeneous IPv6/IPv4 networks when the UPnP A/V framework is used, interoperability issues may arise. A MS, a MR and a CP in UPnP 1.0 can be either IPv6-only or IPv4-only or IPv6/IPv4. First interoperability issues arise in case a CP cannot discover either a MS or a MR or both due to incompatible IP stacks between the CP and the MS/MR. Prior art translation techniques do IPv4-IPv6 translation of headers of IP packets but cannot translate IP addresses and ports embedded in the payload of IP packets. Therefore, these techniques would not work for IP packets with UPnP messages as a payload. These first interoperability issues are solved by the invention.

Second interoperability issues arise in case a CP can discover and configure a MS as well as a MR, but cannot set up a stream between them due to incompatible IP stacks of the MS and the MR. In contrast to the first interoperability issues this problem can be solved if one of the prior art translation techniques is invoked. In this case the payload of the IP packets is A/V content and simple translation of the IP headers will be sufficient.

In order to avoid the aforementioned interoperability problems UPnP 1.1 has excluded IPv6-only devices. The UPnP 1.1 compliant devices are either IPv4-only or IPv6/IPv4. However, the presence of IPv6-only devices in UPnP is a fact and moreover the presence of IPv6-only devices in the future UPnP versions cannot be excluded because of emerging IPv6 mobile and Asian markets. Then, a solution for the first interoperability issues gets important.

Contrary to the UPnP standard, that defines logical devices, in the Figs. 1-3 physical devices are defined. A physical translator device comprises a translator and may further comprise a CP, a MR and/or a MS. A physical media device comprises a logical media device comprising a MR and/or a MS. A physical control device comprises a logical media device comprising a CP and possibly further comprising a MR and/or a MS.

Fig. 1 shows diagrammatically a universal plug and play system 1 according to the invention comprising a translator device 10 according to the invention and further comprising a media device 20 and a control device 30, the translator device 10 comprising an A/V framework 11 with a MR 14 and a translator 15 (T 15) according to the invention and comprising a UPnP stack 12 and an IPv6/IPv4 stack 13. The media device 20 comprises an A/V framework 21 with a MS 24 and comprises a UPnP stack 22 and an IPv6-only stack 23. The control device 30 comprises an A/V framework 31 with a MR 34 and a CP 35 and comprises a UPnP stack 32 and an IPv4-only stack 33.

Fig. 2 shows in flow chart form an algorithm for solving an interoperability issue in a universal plug and play environment. The blocks in Fig. 2 have the following meaning: Block 40: Start, CP 35 discovers MR 14 and MR 34 but cannot discover MS 24. Block 41 : Can CP 35 discover T 15 ? If yes, goto 42, if no, goto 46.

Block 42: T 15 offers a remote user interface of its embedded translator device control point to CP 35. Block 43: Can CP 35 render the remote user interface of embedded control point of T 15 ? If yes, goto 44, if no, goto 45.

Block 44: The embedded control point of T 15 sets up a stream between MS 24 and MR 14. Block 45: T 15 translates the interactions between CP 35 and MS 24. Block 46: End. The first interoperability issues can be solved if an IPv6-IPv4 UPnP translator according to the invention (T 15) is present in the UPnP system 1. The work of T 15 will be explained in terms of the set-up illustrated in Fig. 1. Suppose the UPnP system 1 consist of a MR 14 running on device 10 (IPv6/IPv4) and a MR 34 running on device 30 (IPv4-only), a MS 24 on device 20 (IPv6-only) and a CP 35 on device 30 (IPv4-only). Then, the IPv4-only CP 35 can find the IPv4-only MR 34 and the IPv6/IPv4 MR 14 but cannot find the IPv6-only MS 24 and an interoperability issue is present. It can be solved if the algorithm illustrated in Fig. 2 is executed between CP 35 and T 15.

T 15 runs on top of an IPv6/IPv4 device 10 and consists of two parts: an embedded control point CP and a translation service. The CP of T 15 can receive all device advertisements, events and discovery responses whereas the translation service of T 15 can be discovered by all UPnP CPs. The implementation of blocks 40-44 from the algorithm illustrated in Fig. 2 is either straightforward or uses standard UPnP mechanisms. About block 45, the following is observed.

The translator T 15 executes two main tasks. Firstly, a translation of the payload of IP packets exchanged between IP incompatible CPs and UPnP services based on specific UPnP knowledge. In fact, the payload of these IP packets are UPnP messages with embedded IP addresses and ports. Information embedded in these UPnP messages allows T 15 to automatically translate these messages without any need for maintaining additional translation tables/information. Secondly, a translation of source and destination addresses in the headers of IP packets exchanged between IP incompatible CPs and UPnP services. This translation of the destination address is not predefined, it is payload depended. Thus, T 15 as an UPnP translation service firstly translates the payload of the packets (as mentioned above) and secondly defines the destination address according to the info embedded in the payload. The aforementioned main tasks of T 15 are elaborated below for the basic UPnP mechanisms "discovery", "description", "control", "eventing" and "presentation" in view of Fig. 3.

Fig. 3 shows diagrammatically T 15 according to the invention in greater detail as well as the information 70,73 exchanged between T 15 and CP 35 and the information 71,72 exchanged between T 15 and MS 24. T 15 comprises, for translating addresses of packets, an input part 51 for receiving a first packet, the first packet comprising a first header and a first payload, the first payload comprising first embedded paylo ad- addresses, a processor 50 with a payload translator part 61 for translating the embedded addresses of the first payload into embedded addresses of the second payload, and an output part 52 for supplying a second packet, the second packet comprising a second header and a second payload, the second payload comprising the second embedded payload-addresses. The processor 50 further comprises a header translator part 62 for translating a first header- address into a second header-address in dependence of a translation result originating from the payload translator part 61, the first header comprising the first source and destination header-addresses and the second header comprising the second source and destination header-addresses. The payload translator part 61 is arranged to translate a http body of a http response into a translated http body, the http body comprising a description document and the translated http body comprising a translated description document and is arranged to translate a http body of a http response into a translated http body, the http body comprising a presentation document and the translated http body comprising a translated presentation document.

An output of CP 35 is coupled via the input part 51 to an input of the processor 50, an output of the processor 50 is coupled via the output part 52 to an input of MS 24, an output of MS 24 is coupled via a further input part 53 to a further input of the processor 50, and a further output of the processor 50 is coupled via a further output part 54 to an input of the CP 35. Each one of the parts 51-54 receives and supplies signals for example in the form of IP packets, with an IP packet for example comprising an IP header and an IP payload, the IP header for example comprising an IP preamble and an IP source address and an IP destination address and the IP payload for example comprising a UPnP message.

Below an extensive description of the work done by the payload translator part 61 and the header translator part 62 of T 15 for all five basic UPnP mechanisms is provided. These descriptions have the following structure per UPnP mechanism.

First, the work of the payload translator part 61 of T 15 is described. Second, the work of the header translator part 62 of T 15 is described. The source address translation in an IP header is conventional, i.e., the original source IPv4 (IPv6) address is translated into the IPv6 (IPv4) address of T 15. The destination address translation in an IP header is payload specific and is explained per UPnP mechanism.

UPnP discovery - The payloads of IP packets exchanged between IP incompatible CPs and UPnP services during the UPnP discovery are Simple Service Discovery Protocol (SSDP) messages from one of the following types: Advertisement: Device Available, Advertisement: Device Unavailable, M-SEARCH, Search Response. All these messages have the following structure: a request line followed by a number of headers. The request line comprises a method, e.g. NOTIFY or M-SEARCH, and a HTTP version, e.g. HTTP/1.1. A header comprises a header name, e.g. HOST, LOCATION, CACHE- CONTROL, etc., and a header value, e.g. the HOST header value is an IP address and port whereas the LOCATION header value is a URL.

T 15 translates the values of the HOST and LOCATION headers in all four types of messages according to the following table:

The translation of the SSDP HOST header value is done by replacing for example the IPv4 multicast address 239.255.255.250:1900 by the IPv6 multicast address [FFOX: :C]: 1900, where X specifies an appropriate IPv6 multicast scope. The value of the

SSDP LOCATION header is a single absolute URL to the root device description document, called description URL. For example in case of MS_B it can be http://IPv6addrMS_B/description.xml. IfT 15 acts as a simple http proxy, it will replace the IPv6 host component of the URL with its own IPv4 address/hostname, for example http://IPv4addrT15/description.xml. Then, the following problem might arise: a collision may occur if T 15 is a translator for multiple UPnP services with the same description document name. To avoid this, a new algorithm AA may be used that is executed by T 15 to translate the value of the LOCATION header.

Algorithm AA for translating the description URL in a LOCATION header of a SSDP message:

1. The host component of the translated description URL = IP address (or hostname) of T 15 and

2. The path component of the translated description URL = host component of original description URL/path component of original description URL. An interesting part concerns the second part of this algorithm AA and more precisely the way it is assembled. In fact, the host component of the original URL is embedded into the path component of the translated URL as shown below. Note that no replacement of special characters such as '.' and ':' contained by the host component of the original URL is needed since these characters are not reserved in the path component of the translated URL. The uniqueness of the UPnP service host component within the UPnP network guarantees the uniqueness of the path component of the translated URL. Thus, the special structure of the translated absolute URL allows T 15 (internal name: T 64) to deal with multiple UPnP services, avoiding both collisions and maintenance of translation tables.

original desctription URL: http://IPv6addrUPnPservice/file hosTscomponent

translated desctription URL: http://IPv4addrT15/IPv6addrUPnPservice/file

J host component path component

Up to now the work of the payload translation part 61 of T 15 for the UPnP discovery mechanism has been described.

Below the work of the header translator part 62 of T 15 is described, more precisely the translation of the destination address in the IP header that is payload dependent is depicted below.

UPnP Description - After a CP has discovered a device, it still knows very little about this device. To learn more about its capability, the CP retrieves a device description document from the description URL specified in the LOCATION header of the Search Response message. This is a HTTP -based process consisting of the following steps: the CP issues an HTTP GET request to the path component of the description URL and the device returns its description document in the body of a HTTP response.

The translation of the description URL in the LOCATION header has been discussed above and is done according to algorithm AA. The resulting translated description URL for the set-up in Fig. 3 is: http://IPv4addrT15/IPv6addrMS24/description.xml. Then, CP 35 uses the path component of this URL, i.e. IPv6addrMS24/description.xml, to fill in the GET method description path and the host component, i.e. IPv4addrT15,to fill in the HOST header value in the GET request illustrated in the information 70 of Fig. 3. This information 70 for example defines GET IPvβaddrMP/description.xml HTTP/1.1, HOST: IPv4addrT15,

ACCEPT-LANGUAGE: The translated information 71 for example defines GET description.xml HTTP/1.1, HOST: IPvβaddrMP, ACCEPT-LANGUAGE: ....

Thereby, for a HTTP GET request, the payload translator part 61 of T 15 translates the description path and the HOST header value according to algorithm AB below. The description path in the original GET request contains all data T 15 needs to send a translated GET request to MS 24 as shown via the information 71 in Fig. 3.

Algorithm AB for translating the description path and the HOST header value of the UPnP description message:

The description path in the translated GET request = description path in the original GET request minus the first (hostname) part.

The value of the HOST header in the translated request = the first part of the description path in the original request. Further, MS 24 sends a device description document (description, xml) to T 15 via the information 72 in Fig. 3 as a HTTP response to the GET request. The device description document includes the following xURLs among others: iconURL, controlURL, eventSubURL, SCPDURL and presentationURL. The payload translator part 61 of T 15 uses a yet further algorithm AC to translate them.

Algorithm AC for translating xURLs in the device description document (description.xml) :

1. If <URLBase> element is present in the description.xml then delete it in the translated description.xml; 2. If xURLs are not relative in the description.xml then make them relative in the translated description.xml by ignoring their host components and preserving only the path components;

3. Embed the IP address (or hostname) of the root device where the service is located as a first part of the path component in all relative xURLs in the translated description, xml.

After having applied algorithm AC, T 15 has a translated description.xml that is sent to CP 35 via the information 73 in Fig. 3.

The description.xml for example defines: <url> http://IPaddr/icon.png </url> ....

<controlURL> MS24Ctrl </controlURL> <eventSubURL> MS24Events </eventSubURL> <SCPDURL> description.xml </SCPDURL>

<presentationURL>http ://IPaddr/presentation.html </presentationURL>

The translated description.xml for example defines: <url» IPv6addrMS24/icon.png </url>

<controlURL> IPv6addrMS24/MS24Ctrl </controlURL>

<eventSubURL> IPv6addrMS24/MS24Events </eventSubURL> <SCPDURL> IPv6addrMS24/description.xml </SCPDURL> <presentationURL> IPv6addrMS24/presentation.html</presentationURL>

Summing up, the work the payload translator part 61 of T 15 is based on algorithms AB and AC. Below, the work of the header translator part 62 of T 15 with respect to destination addresses in case of UPnP description mechanism is described.

For an IP packet with HTTP GET request as a payload (see information 70), the translation of the destination address in the IP header is not predefined. The original destination address is translated to the HOST header value in the translated HTTP request (see information 71).

For an IP packet with HTTP response as a payload (see information 72), the original destination IPv6 address of T 15 is translated to the IPv4 address of CP 35 (see information 73).

UPnP Control - After a CP has learned the contro IURLs of the device services from the device description document (description.xml), the CP can invoke actions on these services and obtain results or errors back. To invoke a specific action, the CP encapsulates an action in SOAP (Simple Object Access Protocol) and sends it via a HTTP POST request to the path component of the absolute controlURL of the UPnP device. The HTTP response of the controlled service contains results or errors encapsulated in SOAP. The absolute controlURL of MS 24 is obtained from the relative controlURL in the translated description.xml and the host component of the description URL in the LOCATION header in the translated Search Response message. Therefore, for the set-up in Fig. 3 the absolute controlURL is: http://IPv4addrT15/IPv6addrMS24/MS24Ctrl. Then, CP35 uses this absolute controlURL to define both the control path following the POST request and the HOST header value. Further, CP 35 invokes actions on MS 24 such as Action: Invoke or Query: Invoke. So, the CP 35 for example calls Action: Invoke. The sequence of messages exchanged between CP 35, T 15 and MS 24 is depicted in Fig. 3 via the information 70-73 in Fig. 3.

This time, the payloads of the packets in 70 and 71 are HTTP POST requests whereas the payloads of the packets in 72 and 73 are HTTP responses. For example the information 70 defines POST IPv6addrMS24/MS24Ctrl HTTP/1.1., HOST: IPv4addrT15, CONTENT-LENGTH: .... The translated information 71 for example defines POST MPCntrl HTTP/1.1., HOST: IPvόaddrMP, CONTENT-LENGTH:.... Thereby, for a HTTP POST request the payload translator part 61 translates the control path following the POST request and the HOST header value according to translation rules similar to those described for algorithm AB and applied this time for the control path instead of the description path. The control path in the original HTTP request contains all data T 15 needs to send a translated HTTP request to MS 24.

Further, MS 24 sends Action: Response to T 15 via the information 72 in Fig. 3 as a HTTP response to the POST request.. No translation is needed, therefore T 15 forwards the response to CP 35 via the information 73 in Fig. 3.

Below, the work of the header translator part 62 of T 15 with respect to destination addresses in case of UPnP control mechanism is described.

For an IP packet with HTTP POST request as a payload (see information 70), the translation of the destination address in the IP header is not predefined. The original destination address is translated to the HOST header value in the translated HTTP request (see information 71). For an IP packet with HTTP response as a payload (see information 72), the original destination IPv6 address of T 15 is translated to the IPv4 address of CP 35 (see information 73).

UPnP eventing - Through eventing a CP listens to state changes in UPnP devices and services. In order to receive events a CP submits a SUBSCRIBE message to the path component of the absolute eventSubURL of the UPnP device. The service can accept the subscription and respond with duration for the subscription by sending an OK message with a time-out value to the CP. The above messages are delivered via HTTP that has been extended using additional methods and headers.

The absolute eventSubURL of MS 24 is obtained from the relative eventSubURL in the translated description.xml and the host component of the description URL in the LOCATION header in the translated Search Response message. Therefore, for the set-up in Fig. 3 the absolute eventSubURL is: http://IPv4addrT15/IPv6addrMS24/MS24Events. Then, CP 35 uses this absolute eventSubURL to (un)subscribe to events published by MS 24, i.e. the path component (IPv6addrMS24/MS24Events = publisher path) of this URL is the relative URL following the SUBSCRIBE method, and the host component (IPv4addrT15) is the HOST header value. The sequence of messages exchanged between CP 35, T 15 and MS 24 is depicted via the information 70-73 in Fig. 3. This time, the payloads of the packets in 70 and 71 are HTTP SUBSCRIBE requests whereas the payloads of the packets in 72 and 73 are HTTP responses. For example, the information 70 defines SUBSCRIBE IPvβaddrMP/MPEvents HTTP/1.1, HOST: IPv4addrT15, CALLBACK: http://IPv4addrCP35. The translated information 71 for example defines SUBSCRIBE MPEvents HTTP /1.1,, HOST: IPvβaddrMP, CALLBACK: http://IPv6addrT15.

Thereby, for a HTTP SUBSCRIBE request the payload translator part 61 translates the publisher path following the SUBSCRIBE request, the HOST header value and the CALLBACK header value according to translation rules similar to those described for algorithm AB and applied this time for the publisher path instead of the description path. The CALLBACK header in the SUBSCRIBE message specifies a URL for delivery of device/service event. The publisher path in the original HTTP request contains all data T 15 needs to send a translated HTTP request to MS 24.

Further, MS 24 accepts the subscription and sends response to T 15 via the information 72 in Fig. 3 as a HTTP response to the SUBSCRIBE request. No translation is needed, therefore T 15 forwards the response to CP 35 via the information 73 in Fig. 3.

Below, the work of the header translator part 62 of T 15 with respect to destination addresses in case of UPnP eventing mechanism is described.

For an IP packet with HTTP SUBSCRIBE request as a payload (see information 70), the translation of the destination address in the IP header is not predefined. The original destination address is translated to the HOST header value in the translated HTTP request (see information 71).

UPnP presentation - A CP can control a UPnP device or view its status through a presentation page in HTML that features a user interface. To retrieve the presentation page, the CP submits a HTTP GET request to the to the path component of the absolute presentationURL of the UPnP device. The HTTP response of the UPnP device contains the presentation page (presentation.html) as a body.

The absolute presentationURL of MS 24 is obtained from the relative presentationURL in the translated description.xml and the host component of the description URO of the LOCATION header in the translated Search Response message. Therefore, for the set-up in Fig. 3 the absolute presentationURL is: http://IPv4addrT15/IPv6addrMS24/presentation.html. Then, the CP 35 uses this presentationURL to retrieve the presentation page of MS24, i.e. the path component (IPv6addrMS24/presentation.html = presentation path) of this URL is the relative URL following the GET method, and the host component (IPv4addrT15) is the value of the HOST header. The sequence of messages exchanged between CP 35, T 15 andMS24 is depicted via the information 70-73 in Fig. 3.

This time, the payloads of the packets in 70 and 71 are HTTP GET requests whereas the payloads of the packets in 72 and 73 are HTTP responses. For example, the information 70 defines GET IPv6addrMS24/presentation.html HTTP/1.1., HOST: IPv4addrT 15 , ACCEPT-LANGUAGE : .... The translated information 71 for example defines GET presentation.html HTTP /1.1, HOST: IPv6addrMS24, ACCEPT-LANGUAGE:....

Thereby, for a HTTP GET request the payload translator part 61 translates the presentation path following the GET request and the HOST header value according to translation rules similar to those described for algorithm AB and applied this time for the presentation path instead of the description path. The presentation path in the original HTTP request contains all data T 15 needs to send a translated HTTP request to MS 24.

Further, MS 24 sends a presentation document (presentation.html) to T 15 via the information 72 in Fig. 3 as a HTTP response to the GET request. The presentation.html may contain embedded absolute URLs to services on that device. In this case T 15 has to apply the algorithm AC explained above. Then, T 15 forwards the translated presentation.html to CP 35 via the information 73 in Fig. 3.

Below, the work of the header translator part 62 of T 15 with respect to destination addresses in case of UPnP presentation mechanism is described.

The translator device 10 is for example a home network device such as a personal computer, an audio and/or video receiver, an audio and/or video player, an audio and/or video recorder and a set top box. The media device 20 may be a media renderer such as a display or a loudspeaker or may be a media server. The control device 30 is for example a home network device such as a personal computer, an audio and/or video receiver, an audio and/or video player, an audio and/or video recorder and a set top box. The translator device 10 and/or the control device 30 may in addition comprise a media point, just like the media device 20. The translator 15 is a hardware translator or is a mixture of hardware and software or is a software translator in the form of a computer program product stored on a medium such as a fixed memory for example forming part of the processor 50 or a removable or carryable or insertable memory not shown.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "to comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. Translator (15) for translating addresses of packets, the translator (15) comprising: an input part (51) for receiving a first packet, the first packet comprising a first header and a first payload, the first payload comprising a first payload-address, - a payload translator part (61) for translating the first payload-address into a second payload-address, and an output part (52) for supplying a second packet, the second packet comprising a second header and a second payload, the second payload comprising the second payload-address.

2. Translator (15) according to claim 1, the translator (15) further comprising: a header translator part (62) for translating a first header-address into a second header-address in dependence of a translation result originating from the payload translator part (61), the first header comprising the first header-address and the second header comprising the second header-address.

3. Translator (15) according to claim 2, the respective first and second payload- addresses being respective IPv4 and IPv6 addresses or respective IPv6 and IPv4 addresses, the respective first and second header-addresses being respective IPv4 and IPv6 addresses or respective IPv6 and IPv4 addresses, and the packets being IP packets.

4. Translator (15) according to claim 2, the respective first and second payload- addresses comprising respective first and second host addresses, the first host address comprising a respective IPv4 or IPv6 multicast address and the second host address comprising a respective IPv6 or IPv4 multicast address.

5. Translator (15) according to claim 2, the respective first and second payload- addresses comprising respective first and second location addresses, the first location address comprising an original URL and the second location address comprising a translated URL, the original URL comprising an original host component and an original path component, the translated URL comprising a translated host component and a translated path component, the translated path component comprising the original host component and the original path component.

6. Translator (15) according to claim 4, the respective first and second header- addresses comprising the respective first and second host addresses.

7. Translator (15) according to claim 2, the respective first and second header- addresses comprising a respective IPv6 address of the translator (15) of a translator device

(10) and an IPv4 address of a control point (35) of a control device (30) or comprising a respective IPv4 address of the translator (15) and an IPv6 address of the control point (35).

8. Translator (15) according to claim 1, the first payload comprising an original http request for a http response and the second payload comprising a translated http request for the http response, the original http request comprising a first get part and a first host part, the translated http request comprising a second get part and a second host part, the first get part comprising an address of a media point (24) of a media device (20) and a description part and the second get part comprising the description part without the address of the media point (24), the first host part comprising the first payload-address defining the translator (15) of a translator device (10) and the second host part comprising the second payload-address defining the media point (24), the second payload-address being equal to the address of the media point (24).

9. Translator (15) according to claim 8, the payload translator part (61) being arranged to translate a http body of the http response into a translated http body, the http body comprising a description document and the translated http body comprising a translated description document.

10. Translator (15) according to claim 1, the first payload comprising an original http request for a http response and the second payload comprising a translated http request for the http response, the original http request comprising a first post part and a first host part, the translated http request comprising a second post part and a second host part, the first post part comprising an address of a media point (24) of a media device (20) and a control part and the second get part comprising the control part without the address of the media point (24), the first host part comprising the first payload-address defining the translator (15) of a translator device (10) and the second host part comprising the second payload-address defining the media point (24), the second payload-address being equal to the address of the media point (24).

11. Translator (15) according to claim 1, the first payload comprising an original http request for a http response and the second payload comprising a translated http request for the http response, the original http request comprising a first subscribe part and a first host part and a first callback part, the translated http request comprising a second subscribe part and a second host part and a second callback part, the first subscribe part comprising an address of a media point (24) of a media device (20) and a publisher part and the second subscribe part comprising the publisher part without the address of the media point (24), the first host part comprising the first payload-address defining the translator (15) of a translator device (10) and the second host part comprising the second payload-address defining the media point (24), the second payload-address being equal to the address of the media point (24), the first callback part comprising an address of a control point (35) and the second callback part comprising an address of the translator (15).

12. Translator (15) according to claim 1, the first payload comprising an original http request for a http response and the second payload comprising a translated http request for the http response, the original http request comprising a first get part and a first host part, the translated http request comprising a second get part and a second host part, the first get part comprising an address of a media point (24) of a media device (20) and a presentation part and the second get part comprising the presentation part without the address of the media point (24), the first host part comprising the first payload-address defining the translator (15) of a translator device (10) and the second host part comprising the second payload-address defining the media point (24), the second payload-address being equal to the address of the media point (24).

13. Translator (15) according to claim 12, the payload translator part (61) being arranged to translate a http body of the http response into a translated http body, the http body comprising a presentation document and the translated http body comprising a translated presentation document.

14. Translator device (10) comprising a translator (15) as defined in claim 1 and further comprising a translator device control point.

15. Universal plug and play system (1) comprising a translator device (10) as defined in claim 14 and further comprising a media device (20) and a control device (30), the media device (20) comprising a media point (24) and the control device (30) comprising a control point (35).

16. Method for translating addresses of packets, the method comprising the steps of: receiving a first packet, the first packet comprising a first header and a first payload, the first payload comprising a first payload-address, translating the first payload-address into a second payload-address, and - supplying a second packet, the second packet comprising a second header and a second payload, the second payload comprising the second payload-address.

17. Computer program product for translating addresses of packets through performing a method as defined in claim 16.

18. Medium comprising a computer program product as defined in claim 17.