WO2005104591A1

WO2005104591A1 - Technique for distributing content data

Info

Publication number: WO2005104591A1
Application number: PCT/EP2004/004181
Authority: WO
Inventors: Ralf Keller; Thorsten Lohmar; Frank Hundscheidt
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2004-04-20
Filing date: 2004-04-20
Publication date: 2005-11-03
Also published as: EP1738608A1; CN1977558A; CN1977558B

Abstract

A technique for distributing content data in a first domain (145) to a plurality of network components (103) communicating in a second domain (110) is provided, wherein the network components have addresses in both the first domain and the second domain. Content data for distribution in the first domain is received together with addresses of the network components in the first domain that have been derived from the addresses of the network components in the second domain. Thereafter, the content data is distributed to the network components (103) via the first domain using the first domain addresses.

Description

Technique for Distributing Content Data

DESCRIPTION

Field of the Invention

The current invention relates to communications. More specifically, the current invention relates to a technique for distributing content data in a first domain to one or more network components engaged in communication in a second domain.

Background of the Invention

Advances in mobile communications devices allow users to exchange increasing amounts of content data, such as audio, video, and multimedia files. However, the ability for a mobile communications device (or other network component) to exchange such content data while participating in a conference (or any other communication arrangement such as a combinational service communication) having more than two participants is limited. Unless the conference is between two communications devices, content data cannot (or not satisfactorily) be sent to the various participants simultaneously during the conference. For example, while two communications device users speaking to each other over a circuit switching (CS) domain may simultaneously exchange video data over a packet switching (PS) domain, a user would not be able to send that same video data to multiple users. As a result communications devices must sequentially send the content data to each par- ticipant of a conferencing session, an arrangement that generates unnecessary data traffic and is time consuming.

Accordingly, it will be appreciated that there remains a need for an improved technique for distributing content data to one or more network components in communi- cation with each other. Summary of the Invention

The invention may be embodied in a method for distributing content data in a first domain to a plurality of network components that are in communication or otherwise communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain. The method may include the steps of receiving content data from a network component for distribution in the first domain, receiving the addresses of the network components in the first domain derived from the addresses of the network components in the second domain, and distributing the content data to the network components via the first domain using the first domain addresses. In one variation, the addresses of the second domain are resolved into (or otherwise associated with) equivalent or compatible addresses in the first domain.

Depending on the desired configuration, the method may also include the step of centrally storing the addresses of the network components in the first domain that have been derived from the second domain addresses. The addresses may either be the addresses of individual components, or they may be addresses for groups of network components (so that the transfer of content data to the group address re- suits in the content data being distributed to each network component associated therewith). If the addresses are stored on a server or other storage device, the method may also include the step of updating the list of centrally stored network components addresses based on the network components currently communicating in the second domain (e.g., participating in a conferencing session or other session in which data is transmitted and/or received among the various network components). With this arrangement, the content data is only distributed to those currently participating in the communications (which might include new participants).

The addresses may be centrally stored when the communications in the second do- main commence. In addition to, or optionally, the addresses may be stored after a request (such as a Session Initiation Protocol message) by a network component in the second domain (for example, when a network component makes a request to initiate the process for content distribution). Furthermore, if the addresses are stored on a server, the method may include the step of contacting, by the server, a Home Location Register to determine the addresses of the network components in the sec- ond domain. To facilitate the acquisition of the addresses and to minimize data traffic in some instances, the method may also comprise the step of generating a pointer to the centrally stored addresses.

The centrally stored first domain addresses may be generated by providing the ad- dresses in the second domain to an address resolver. The address resolver transposes, converts, or otherwise associates the second domain addresses with corresponding addresses in the first domain. After the addresses in the first domain addresses have been derived (e.g. for a group of communicating network components), they may be centrally stored. Additionally, a pointer to the centrally stored group of first domain addresses (i.e. to their storage location) may be generated.

In addition, or in the alternative, the method may also include the step of receiving the pointer (so that, for example, the receiving network component may subsequently transmit a distribution request with the pointer and the content data to be distributed for more rapid distribution of the content data). The use of a pointer also may ensure, as will be explained further below, that the most current list of addresses in the first domain are used for the distribution of content data.

The method may also include the step of determining which types of content data are compatible with each end user device (or participant). For example, the addresses of the communicating network components may be obtained using a pointer and a capabilities request may be sent to the addresses thus obtained to poll the various network components regarding the transmission and/or reception capabilities. Therefore, prior to distributing content data, it may be determined whether the content data needs to be modified for any particular participants. Distribution of the content data may be performed by an Internet Protocol Multimedia Unit, or any other component, module, etc. that can efficiently transmit data to a plurality of identified recipients. The content data may be distributed by multicast, unicast, SMS, MMS, etc.

The invention may further be embodied in a method for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain. Such a method comprises the step of sending content data and an identifier associated with at least one of the addresses of the network compo- nents in the second domain to a transmission unit for determining the corresponding addresses of the network components in the first domain and for distributing the content data to the network components via the first domain using the first domain addresses. The identifier may, for example, be a list with one or more addresses or a pointer to such a list

The invention may be used in connection with the provision of combinational services that combine circuit switching (CS) domain services (e.g., voice) with packet switching (PS) domain / Internet protocol multimedia (IPMM) services (e.g., content sharing), such as push-to-watch voice and image sharing, push to view video, voice, and video-clip sharing, as well as voice and whiteboard sharing. The invention may also be used in connection with PS with PS/IPMM domain combinational services such as gaming and push to talk, and gaming and instant messaging. In other words, the various participating network components may be exchanging data while communicating via a conforming protocol relating, for example, to at least one of video con- ferencing, audio conferencing, and multimedia conferencing. In some variations, the network components include at least one mobile communications device, and more specifically, mobile telephone. In other variations, the network component is a device such as a communications terminal, a network node, an intermediary node such as a router, or the like. It will also be appreciated that the invention may be embodied in a computer program product comprising program code portions for performing the steps of the preceding inventions when the computer program product is run on a computer system. Depending on the desired implementation, the computer program product may be stored on a computer readable recording medium.

Similarly, the invention may be embodied in a system comprising a computer processor and a memory coupled to the processor, where the memory is encoded with one or more programs that may perform the steps of any the preceding inventions.

In an interrelated embodiment, the invention is provided in an apparatus for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses .in both the first domain and the second domain. The apparatus may comprise a content data unit for receiving content data from a network component for distribution in the first domain, an addressing unit for receiving the addresses of the network components in the first domain derived from the addresses of the network components in the second domain, and a distribution unit for distributing the content data to the network components via the first domain using the first domain addresses.

The invention may also comprise another interrelated embodiment, namely an apparatus for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain. The apparatus may in- elude a request unit for sending a distribution request containing content data and an identifier associated with at least one of the addresses of the network components in the second domain to a transmission unit for determining the corresponding addresses of the network components in the first domain and for distributing the content data to the network components via the first domain using the first network addresses. In addition to the apparatus embodiments, the invention may be an interrelated system for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain. Such a system may com- prise an address resolver for determining the addresses of the network components in the first domain from the addresses of the network components in the second domain, and a transmission unit for receiving content data from a network component for distribution in the first domain and distributing the content data to the network components via the first domain using the first domain addresses from the address resolver.

In an example useful for understanding the invention, a sequence of events may occur (in whole or in part) that facilitate a mobile communications device (or other type of network component) to send content data to a group of participating network components in a conferencing session. The mobile communications device may order in a first domain, such as the CS domain, the storage of addresses of participating network components on a server or database (which may be part of the CS domain, an IPMM unit, or integrated into the mobile communications device). Alternatively, the mobile communications device may send a message, such as a session initiation protocol (SIP) message, via a protocol such as IPMM to the server whereafter the server may contact the CS domain for the addresses. If a SIP message is utilized, it may contain the mobile switching centre (MSC) address, or in the alternative, the server may contact a home location register (HLR) for routing information (such as the MSC address) in order to retrieve the conference information (which may be the individual addresses of each participant in the CS domain or it may be one or more addresses that pertain to groups of participants).

In another variation in the initialization step, the CS domain may automatically store the pertinent conference information when the conferencing session is established and it may periodically update this information whenever participants join or leave the conferencing session (in order to reduce signalling delays whenever a mobile communications device desires to send content to the other participating devices).

The next occurrence may be that the CS domain stores the addresses of the partici- pants in the server. The server may then, for example, resolve these addresses in an address resolver so that PS or other domain addresses are derived from the CS domain addresses. The resolved addresses may be subsequently stored in the server and a pointer to the addresses, generated by the server, may be sent to the requesting mobile communications device via the CS domain or the PS domain (e.g., using an SMS).

The requesting network component may then send the content data and the pointer to a distribution unit, such as an IPMM unit, which may use the pointer to retrieve the addresses of the participating network components. Once the addresses are obtained, the IPMM unit may distribute the content to the participants via unicast (where IPMM sequentially distributes the content data to each of the participants using a protocol such as instant messaging, MMS or the like) or MBMS in the PS domain. Optionally, the IPMM unit may also distribute the pointer to each of the participants either with or separate from the content data.

Brief Description of the Drawings

In the following the invention will be described with reference to exemplary embodiments illustrated in the figures, in which:

Fig. 1 is a first process flow diagram useful for understanding and implementing the invention;

Fig. 2 is a second process flow diagram useful for understanding and imple- menting the invention; Fig. 3 is a signalling sequence chart useful for understanding and implementing the invention;

Fig. 4 is a process flow diagram of a method embodiment of the invention; and

Fig. 5 is a schematic diagram of an apparatus embodiment of the invention.

Detailed Description of the Preferred Embodiments

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular sequences of steps and various configurations, etc. in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. Moreover, those skilled in the art will appreciate that the functions explained herein below may be implemented using software functioning in conjunction with a programmed microprocessor or general purpose computer, and/or using an application specific integrated circuit (ASIC). It will also be appreciated that while the current invention is primarily de- scribed as a method, it may also be embodied in a computer program product as well as a system comprising a computer processor and a memory coupled to the processor, wherein the memory is encoded with one or more programs that may perform the methods disclosed herein.

Fig. 1 illustrates a process flow diagram 100 useful for understanding and implementing the invention. A plurality of network components 103, here pictured as mobile telephones, communicate with each other on a conferencing session in a circuit switching (CS) domain 110 via a server 120 that stores addresses for each of the network components and is coupled to an address resolver 130 that resolves the addresses from one domain to another (or otherwise derives addresses from one domain into addresses of another domain), and an IP Multimedia (IPMM) unit 145 that distributes data via a packet switching (PS) domain 165 or via MBMS/PS domain.

A network component 104 that wishes to send content data to the other participating network components 103, at step 105, orders the CS domain 110 to store the addresses of the participating components, at step 115, in the server or database 120. Alternatively, the network component 104 may send a session initiation protocol message (SIP) via IP Multimedia (IPMM) to the server 120 upon which the server 120 contacts the CS domain for the addresses. With this variation, either the SIP message contains the mobile switching centre (MSC) address or the server 120 contacts the home location register (HLR) for routing information, such as the MSC Address, in order for the server 120 to retrieve the conference information (i.e., the addresses of the participating components).

After the CS domain addresses are stored at the server 120, the server resolves the addresses, at step 125, using the address resolver 130 and subsequently stores the resolved addresses. The address resolver 130 may convert the CS addresses, as in the case of E164 addresses (as specified by the ITU (International Telecommunications Union)), into packet switching (domain) addresses such as URLs or IP ad- dresses using ENUM (an IETF (Internet Engineering Task Force) proposal in which DNS (Domain Name System) systems will be used to translate E164 telephone numbers into URL (Uniform Resource Locator) and IP addresses - see RFC 2916) or using similar translation mechanism. Moreover, the addresses may be a single address for the entire group, or they may be the individual addresses of each participant. At step 135, a pointer to the resolved addresses stored on the server 120 (and generated by the server 120) is sent to the requesting network component 104 (either via the CS domain or in the PS domain (e.g., as an SMS)).

Optionally, modifications may be made to the list of addresses in case there are new network components participating or previously participating network components have ceased communicating. This modification / updating may be performed on a periodic basis (whether or not initiated by a network component 104).

At step 140, the requesting network component 104 sends the content data including the received pointer to the IPMM unit 145. Next, at steps 150 and 155, the IPMM unit 145 uses the pointer to retrieve the addresses of the participating components and at step 160, the content data is distributed to the network components 103 via unicast in the PS domain 165 or Multimedia Broadcast / Multimedia Sen/ice (MBMS) in the PS domain 170.

Before distribution, the content data is temporarily stored in the IPMM unit 145 (which may be accomplished via a multimedia resource function (MRF)). The network component 104 that sends the content data may include the content data in a SIP message (e.g., SIP INFO message) and the content may be temporarily stored in the multimedia resource function centre (MRFC - or a dedicated database coupled to the MRFC).

Alternatively, the requesting network component 104 may inform the MRFC (indirectly via a Sen ing-Call Session Control Function (S-CSCF) with a corresponding SIP message, upon which the multimedia resource function processor (MRFP) is ordered by the MRFC to retrieve the content from the requesting network component 104. With this arrangement, the content data may be retrieved immediately prior to its distribution, thereby avoiding the requirement for intermediate storage. In addition, the MFRP may be used to adapt and modify the content data so that it is compatible with the capabilities of each of the participating components 103 (a technique for determining the capabilities of the participating components is described below).

If the content data is distributed by the IPMM unit 145 via MBMS/PS 170, then the MRFC contacts a broadcast multicast service centre (BMSC) for further content data distribution. The MRFP then sends a single copy of the content data to the BMSC from which the content is distributed to the participating components 103. Option- ally, if the technical capabilities of the participating components are known (such as by the IPMM unit 145, or retrieved from the participating components 103, or from a database), the MRFP may modify the data to ensure compatibility. s In yet another variation, the IPMM unit 145 may cause the content data to be distributed via the PS domain 165 such that the MRFC acts as the content data provider and requests an multimedia messaging centre (MMSC) to distribute the content data via MMS.

ιo The skilled artisan will also appreciate that with the example shown in Fig. 1, the CS domain 110 may automatically trigger the storage of the conference information in the server 120 whenever a conference is established (resulting in reduced number of signalling delays when a network component sends content data to the participating components). Also, with regard to this example, the master control of the functional- i5 ity described above resides within the server 120. The server 120 provides updated conference information and is the coordination node between the CS conference and the PS data sessions. However, the skilled artisan will appreciate that the server 120 may be a logical unit that is integrated within another unit or module. For example, the server 120 may be integrated in the CS domain, IPMM or within the network

20 component (or mobile communications device) that commands steps 105 and 140. It will also be appreciated that, at step 135, the server 120 may send the pointer to all of the network components 103, rather than just the requesting network component 104.

25 Fig. 2 illustrates a variation 200 of the example of Fig. 1 in which the technical capabilities of the various participating components may be determined so that certain types of content data or services can be provided. These capabilities may be the types of content data that may be displayed or otherwise processed for each network component 103, and/or it may include information pertaining to the content distribu-

30 tion (e.g., codecs, etc.). Common features and steps have the same numbering as in Fig. 1. Simultaneous or subsequent to sending the content data at step 105, the requesting network component 104, at step 205, requests information pertaining to the capabilities of the participating components. The IPMM unit 145, at step 210, which has retrieved the addresses of the network components 103 in the first domain using a pointer to the addresses of the participating network components 103 which has been received by the requesting network component 104, then sends a capability request to the participating components 103 and receives the results from the participating components 103.

Optionally, at step 215, the IPMM unit 145 sends the capabilities information to the server 120 for storage (for later use). With this variation, the next capability request from the IPMM unit 145 need only be sent to participating components 103 that joined the conferencing session subsequent to the last capability request. Finally, at step 220, the capability information of the other participating components 103 is sent either to the requesting network component 104 or to all of the participating components 103 (which in the latter case would also include the capabilities of the requesting network component 104).

With reference to Fig. 3, a signalling sequence chart 300 useful for understanding and implementing the invention is provided. The signalling sequence chart 300 illustrates various messages that may be exchanged among a requesting network component 305, a CS domain unit 310, an IPMM/PS unit 315, a server 320, an address resolver 325, and other network components 330 currently participating in a CS con- ferencing session with the requesting network component 305.

During the CS conferencing session, the requesting network component 305 sends signal 335 to the CS domain unit 310 to request it to store the addresses of the participating network components 330. The CS domain unit 310 then sends the partici- pant information (e.g., a list of CS domain addresses of the participating components and optionally a group identification) to the server 320 via signal 340. The server 320 then sends signal 345 to the address resolver 325 to request that the CS domain addresses (e.g., a sequence of numbers according to the ITU-T E164 standard) be resolved for use in the IPMM/PS domain. The address resolver 325 via signal 350 returns the resolved addresses (or single address when the individual participating component addresses are grouped together in some fashion) to the server 320.

Next, the server 320 generates a pointer to the resolved addresses stored thereon and sends a confirmation signal and the pointer 355 to the CS domain unit 310 (or optionally, the server may simply send the resolved addresses rather than a pointer). The CS domain unit 310 forwards the confirmation via signal 360 (and the pointer to the address or addressed on the server 320) to the network component 305. Signal 365 acts to notify the CS domain unit 310 if there are any additions or deletions of participating network components 330. If a modification of the list of participating components is necessary, then, via signal 370, the server 320 is notified about the change (which may require that the server 320 repeat signals similar to signals 345 and 350 to resolve the addresses of new participating components).

The requesting network component 305 then sends the content data and the pointer to the IPMM/PS unit 315 in signal 375 (wherein the content data is temporarily stored in the IPMM/PS unit 315 (e.g., in the multimedia resource function (MRF)). Via signal 380, the IPMM/PS unit 315 requests the addresses of the group members (or an address for the entire group) by sending the pointer to the server 320. The server 320, via signal 385 provides the IPMM/PS unit 315 with the addresses, whereafter, via signal 390, the IPMM/PS unit 315 distributes the content data to the participating components 330. Optionally, in addition, each of the participating components 315 sends a signal back to the IPMM/PS unit 315 confirming receipt of the content data.

With the above examples, the CS conference may be a voice, video or multimedia conference. The conference control and data handling can be performed by a confer- encing call device (CCD) in the MSC, a dedicated multipoint control unit (MCU) (e.g., for mobile multimedia based on protocols such as 3G.324M), or similar arrange- ments. The conference may also be applied to PS and IPMM/PS conferences (e.g., voice or videoconferencing in the PS domain or in combination with push-to-talk, gaming, or similar functionalities). The conferencing session may be established by a network component (e.g., multi-party call in the CS domain) or all conference partici- pants can register at a central server where the conference is established.

As described above, each participant may optionally send a confirmation after it has received the content data, either from each network component or by the BMSC when MBMS is applied. In the latter case, the BMSC returns a list of content receivers (i.e., the participating components that it monitors and controls). This confirmation may be used to verify the integrity and performance of the applicable data communications network and can also be used to charge accounts associated with the network components (in exchange for obtaining the content data). If the participating components have registered to receive the content data, then their accounts are simply charged, but if they have not registered (such as when the content data is distributed via multiple unicasts), then the participant will have the opportunity to reject the content data (and as a result, the participant will not have to pay for such content data).

If the content data is being distributed to a large number of participating components, it may be advantageous to use MBMS for the content data replication. If this is the case, then MBMS can notify the participating components about the contents of the content data (e.g., by spoken message in conference or an SMS with the multicast address) so that the participating components may register to indicate that they want to receive the content data. Alternatively, the content data may be pushed to the participating components via MBMS (and signalling messages may also be distributed via MBMS such as step 160 in Fig. 1 and steps 210 and 220 in Fig. 2).

In some variations, the content data may comprise a pointer to further content data that may be transmitted so that each participant may retrieve the content data (e.g., from the Internet). With this arrangement, each receiving network component may retrieve the further content data whenever required and its own preferred data transfer technique. Furthermore, portions of the content data may be subsequently stored at a server and network components that are not part of a conferencing session may access the stored content data by providing a conference identifier.

With regard to Fig. 4, a process flow diagram 400 is illustrated relating to a method for distributing content data in a first domain to a plurality of network components communicating in a second domain. Similar to the illustrations and embodiments above, the network components have addresses in both the first domain and the second domain. The method commences, at step 410, with the recipt of content data from a network component for distribution in the first domain. Thereafter, at step 420, addresses of the network components in the first domain derived from the addresses of the network components in the second domain are received. The method concludes, at step 430, with the distribution of the content data to the net- work components via the first domain using the first domain addresses.

Fig. 5 illustrates an apparatus 500 for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses in both the first domain and the second do- main. The apparatus includes a content data unit 510 for receiving content data from a network component for distribution in the first domain, an addressing unit 520 for receiving the addresses of the network components in the first domain derived from the addresses of the network components in the second domain, and a distribution unit 530 for distributing the content data to the network components via the first domain using the first domain addresses.

It will be appreciated from the above, that the invention provides many benefits such as the ability to enable instant exchange of content data while communicating in a voice, video, or multimedia conference among three or more participants. A user may conveniently send the content data to all or selected participants via a user-friendly interface. In those variations that utilize MBMS or similar protocols, the content data is efficiently delivered using common transport channels (with a single copy of the content date) in the network and broadcasting on the radio interface.

While the present invention has been described with respect to particular embodi- ments (including certain system arrangements and certain orders of steps within various methods), those skilled in the art will recognize that the present invention is not limited to the specific embodiments described and illustrated herein. Therefore, while the present invention has been described in relation to its preferred embodiments, it is to be understood that this disclosure is only illustrative. Accordingly, it is intended that the invention be limited only by the scope of the claims appended hereto.

Claims

1. A method for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), the method comprising the steps of: receiving content data from a network component (104) for distribution in the first domain (160); receiving the addresses of the network components (103) in the first domain (160) derived from the addresses of the network components (103) in the second domain (110); and distributing the content data to the network components (103) via the first domain (160) using the first domain addresses.

2. The method of claim 1, further comprising the step of resolving the addresses in the first domain (160).

3. The method of any of the preceding claims, further comprising the step of centrally storing the addresses of the network components (103) in the first do- main (160).

4. The method of claim 3, further comprising the step of updating the centrally stored network component addresses based on the network components (103) currently communicating in the second domain (110).

5. The method of any of claims 3 to 4, wherein the addresses are centrally stored when communications in the second domain (110) commence.

6. The method of any claims 3 to 4, wherein the addresses are stored af- ter a request by a network component (104) in the second domain (110).

7. The method of any of claims 3 to 6, further comprising the steps of generating a pointer to the centrally stored addresses in the first domain.

8. The method claim 7, further comprising the step of providing the pointer to the network component (104) sending the content data.

9. The method of claim 8, further comprising the step of receiving the pointer from the network component (104) sending the content data, and distribut- ing the content data to the network components (103).

10. The method of any of claims 3 to 9, wherein the centrally stored addresses are stored on a server (120).

11. The method of claim 10, further comprising the step of contacting, by the server (120), a Home Location Register to determine the addresses of the network components (103) in the second domain (110).

12. The method of any of the preceding claims, wherein at least one of the network components (103) is a mobile communications device.

13. The method of any of the preceding claims, further comprising the step of determining which types of content data are compatible with each network component (103).

14. The method of any of the preceding claims, wherein distribution of the content data is performed by an Internet Protocol Multimedia Unit (145).

15. The method of any of the preceding claims, wherein each of the net- work components (103) is communicating via at least one conferencing protocol.

16. A method for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), the method comprising the step of: sending content data and an identifier associated with at least one of the addresses of the network components (103) in the second domain (110) to a transmission unit for determining the corresponding addresses of the network components (103) in the first domain (160) and for distributing the content data to the network components (103) via the first domain (160) using the first domain addresses.

17. A computer program product comprising program code portions for performing the steps of any of the preceding claims when the computer program product is run on a computer system.

18. The computer program product of claim 17, wherein the computer program product is stored on a computer readable recording medium.

19. A system comprising a computer processor and a memory coupled to the processor, where the memory is encoded with one or more programs that may perform the steps of any of claims 1 to 16.

20. An apparatus (500) for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first do- main (160) and the second domain (110), the apparatus comprising: a content data unit (510) for receiving content data from a network component (103) for distribution in the first domain (160); an addressing unit (520) for receiving the addresses of the network components (103) in the first domain (160) derived from the addresses of the network components (103) in the second domain (110); and a distribution unit (530) for distributing the content data to the network components (103) via the first domain (160) using the first domain addresses.

21. An apparatus for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), the apparatus comprising a request unit for sending a request containing content data and an identifier associated with at least one of the addresses of the network components (103) in the second domain (110) to a transmission unit for determining the corresponding addresses of the network components (103) in the first domain (160) and for distributing the content data to the network components (103) via the first domain (160) using the first network addresses.

22. A system for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), the system comprising: an address resolver (130) for determining the addresses of the network com- ponents (103) in the first domain (160) from the addresses of the network components (103) in the second domain (110); and a transmission unit for receiving content data from a network component for distribution in the first domain (160) and distributing the content data to the network components (103) via the first domain (160) using the first domain (160) addresses determined by the address resolver (130).