GB2464452A

GB2464452A - Multicast Media Streaming

Info

Publication number: GB2464452A
Application number: GB0818489A
Authority: GB
Inventors: Anthony J Ballardie; Dominic N Robinson
Original assignee: GLOBAL MIX Ltd; GMIX SOFTWARE Ltd
Current assignee: GMIX SOFTWARE LIMITED
Priority date: 2008-10-08
Filing date: 2008-10-08
Publication date: 2010-04-21
Also published as: WO2010041020A1; GB0818489D0

Abstract

A multicast data stream is encapsulated within a unicast data stream and tunneled 9 across a WAN 5a to an end user node 2a. The data stream is provided to a communications protocol stack 17a at the end user node and the data stream is made accessible as multicast data to other end user nodes 2b over a LAN 5b. At end user nodes the multicast data is converted 25a to a unicast data stream which is then played through a media player 21a. Thus, the invention can be applied to media players which do not support multicasting. The multicast-unicast conversion may be achieved by means of a downloadable plug-in. Inter-node signaling may be performed to identify the gateway node for a particular data stream.

Description

MUILTICAST MEDIA SYSTEM

Field of the Invention

This invention relates to an apparatus, method and system for communication and playback of media content, particularly in a multicast media streaming system.

Background of the Invention

AMT (Automatic Multicast Tunneling Protocol) is a protocol that has been developed and introduced as an IETF standard for automatically provisioning tunnels' through non-multicast networks that allow the start-point, where native multicast is originated, to deliver IP multicast packets to a remote end-point on network (typically a router) from where applications can receive the multicast packets, even if the intermediate networks do not support multicast.

StreamingMedia.com -Advanced is a forum, hosted by streamingmedia.com, where many of the worlds leading applied streaming media engineers discuss technical issues with the delivery of streaming audio, video and data. There has been a number of discussions on this forum recognizing the need for the delivery of IP multicast data streams (typically of Audio or Video) to the newer streaming media players, principally, but not exclusively, including Silverlight (by Microsoft) and Flash (by Adobe).

Currently this is not possible either with the use of native' IP Multicast, nor with tunneled' IP Multicast.

WMTalk is another forum, created initially by Microsoft, but with public access, where may of the world's leading Windows Media engineers discuss technical issues with the delivery of streaming windows media audio, video and data. As with the Streamingmedia.com -Advanced forum there has been a number of discussions recognizing the need for the the delivery of I? Multicast data streams (Typically Audio or Video) to the new Microsoft Silverlight technologies. Currently this is not possible.

Windows Media Player and VLC (Videolan.org) player are standalone applications that support the reception of IP Multicast audio, video and data streams. Windows Media Player also supports a logging model for informing the originating service provider about the reception and usage of the Multicast delivered streams. VLC does not support such a logging model.

Microsoft's Silverlight (trade mark) player is a new application suite (known as a Rich Internet Application) that is delivered to multiple platforms using common code and a platform specific run-time environment. While it supports the reception of unicast Audio, Video and Data streaming, Microsoft's Silverlight player does not currently support the reception of multicast streams. Nor does it support any method that could be used for the logging of any such received multicast streams. Adobe's Flash player is also a rich internet application suite. It supports the reception of unicast Audio, video and data streams, but does not currently support the reception of Multicast streams. Nor does it support any method that could be used for the logging of any such received Multicast streams.

Flash Media Server, Wowza, Windows Media Server, Real Media Server, PTNS Proxy and VLC are media servers' (or capable of working as media servers). Typically they are used to receive single input streams and then serve this to multiple users (clients'). Commonly they are used to deliver this input stream to all their clients as a unicast. Windows Media Server, Real Media Server and VLC can all deliver such a stream as a multicast. The input streams are typically a single unicast (origin') stream, although Windows Media Server, Wowza and PTNS Proxy can be configured receive a Multicast input stream and deliver this to clients as a Unicast. These servers are designed and typically configured to be hosted remotely from the clients, closer (in network terms) to the origin. They require complex configuration and this must be carried out by the end users each time they wish to connect to a new stream.

The present invention has the advantage of enabling multicast data streams to be delivered to the end user's network, using an integrated tunneling system (embracing AMT) and subsequently delivered to applications, such as, but not limited to Silverlight and Flash. It requires no extra user configuration or installation.

In its preferred embodiment, the technology also implements a logging model allowing the usage of streaming by the applications to be logged back to the originating (or any other) service providers infrastructure. Aditionally, the technology introduces a signaling protocol which allows optimization of the end to end delivery of the multicast streams both from the origin and between nodes on the receiving network to ensure that maximum network efficiency and most effective user experience is provided.

Summary of the Invention

In accordance with a first aspect of the invention, a method is provided for multicasting communication comprising: receiving a multicast data stream at an end user node from a source; providing the data stream to a communications protocol stack at the end user node and making it is accessible as multicast data to other end user nodes over a local area network; converting the multicast data to unicast data at the end user node; and playing the unicast data stream through a media player. The multicast data stream may be received at the end user node by means of a tunnel through a wide area network.

At the end user node, inter-node signalling may be provided to inform other nodes that the first node is a gateway for that data stream. For example, an inter-node signalling protocol is provided which indicates to all nodes which node is a primary gateway for the data stream. The inter-node signalling protocol facilitates changing of the primary node. The inter-node signalling can inform other nodes of an imminent cessation of the multicast It is particularly envisaged that a node only requests the data stream from the source by means of tunnelling if it is not available as muticast data from another node.

In accordance with a second aspect of the invention, a method is provided for multicasting communication between first and second end user nodes connected via a network supporting multicast capability. The method comprises: receiving a multicast data stream at the first end user node from a source by means of multicast tunnelling; providing the data stream to a communications protocol stack at the first end user node and making it is accessible as multicast data to the second end user node over the local area network; converting the multicast data to unicast data at the first user node; and playing the unicast data stream through a media player at the first end user node.

Inter-node signalling may be provided at the first node to inform the second end user node of an imminent cessation of the multicast data, reception of the multicast data at the first end user node may be continued for a period of time without playing it out through the player; and a new connection from the second end user node to the source may be established by means of multicast tunnelling. Signalling between the first and second end user nodes may allow the first end user node to cease reception of the data stream and allow the second end user node to receive the data stream and make it available to other end user nodes.

In accordance with a further aspect of the invention, a method for multicast communication is provided comprising: receiving a multicast data stream at an end user node via a communications protocol stack; converting the multicast data to unicast data at the end user node; providing the data stream as unicast data to the communications protocol stack at the end user node; and playing the unicast data stream from the communications protocol stack through a media player.

In accordance with preferred features, conversion of a data stream is logged, and is reported to a predetermined destination address. At a minimum, the identity of data stream converted and the duration of the data stream are logged and reported. The identity of the user node can also be reported.

A downloadable plug-in may be provided having means for converting the data from multicast to unicast form, for loading onto a user device having an player that only supports unicast form.

In accordance with a further aspect of the invention, a user device is provided for connection as a node to a network for multicasting communication. The device comprises: means for receiving a multicast data stream at an end user node from a source; means for providing the data stream to a communications protocol stack at the end user node and making it is accessible as multicast data to other end user nodes over a local area network; means for converting the multicast data to unicast data at the end user node; and means for playing the unicast data stream through a media player.

In accordance with a further aspect of the invention, a network is provided comprising first and second end user nodes and means for multicast communication therebetween, with: means for receiving a multicast data stream at the first end user node from a source by means of multicast tunnelling; means for providing the data stream to a communications protocol stack at the first end user node and making it is accessible as multicast data to the second end user node over the local area network; means for converting the multicast data to unicast data at the first user node; and a media player for playing the unicast data stream at the first end user node.

In accordance with a further aspect of the invention a downloadable plug-in for a user device connected to a network is provided, where the user device has means for receiving a multicast data stream from a source. The plug-in is adapted and arranged to provide a player on the user device that is capable only of playing unicast data streams with conversion means for converting the multicast data to unicast data for playing the unicast data stream through the media player.

The plug-in is preferably adapted and arranged to provide the user device with means for logging conversion of a data stream and for reporting to a predetermined destination address at least the data stream converted and the duration of the data stream.

Glossary of Acronyms AMT (Automatic Multicast Tunneling) allows multicast communication amongst isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It also enables them to exchange multicast traffic with the native multicast infrastructure. AMT uses an encapsulation interface so that no changes to a host stack or applications are required, all protocols (not just UDP) are handled.

IGMP (Internet Group Management Protocol) is an asymmetric communications protocol used to manage the membership of Internet Protocol multicast groups. IGMP is used by IP hosts and adjacent multicast routers to establish multicast group memberships. It is used between IP hosts and their immediate neighbour multicast agents to support the creation of transient groups, the addition and deletion of members of a group, and the periodic confirmation of group membership.

UDP (User Datagram Protocol or Universal Datagram Protocol) is a message-oriented Transport Layer protocol that is documented in IETF RFC 768. In the Internet Protocol Suite, UDP provides a simple interface between the Internet Layer below and the Application Layer above.

Brief Description of the Drawings

Specific embodiments of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a block diagram of a media system according to an embodiment of the invention; Figure 2 is a schematic illustration of another example of the media system illustrated in Figure 1; Figure 3 is a schematic block diagram illustrating communications between a client and a server according to an embodiment of the invention; Figure 4 is a schematic block diagram illustrating the protocols and flow of data between client device end nodes according to an embodiment of the invention; Figure 5 is a schematic block diagram illustrating the signalling protocol between client device end nodes according to an embodiment of the invention; and Figure 6 is a flow diagram illustrating the operation of the media player application to respond to a user request for a media data stream according to an embodiment of the invention.

Detailed Description of Embodiment of the Invention Figure 1 is a block diagram showing functional features of the media system according to one embodiment of the invention. In this embodiment, the media system provides a media server (typically implemented as a cluster of servers together providing a media service) 1 which is an Internet-enabled server for distributing steaming multimedia data to a plurality of viewing devices across a network. One such viewing device may be a client device 2 such as a personal computer (PC) or set-top box running a applications (e.g. a web browser) capable of receiving and executing an embedded multimedia player application, using for example a cross-platform rich media application environment such as Microsoft's Silverlight or Adobe's Flash platforms.

In this embodiment, the media server 1 provides media content from a multicast data source 3 over a network or networks, such as the Internet 5a and/or Local Area Network (LAN) 5b, to the client device 2, only one of which is shown in Figure 1. In this embodiment, the media server 1 provides the multicast data to the client device 2 via a multicast tunnel 9, for example using the Automatic Multicast Tunnelling protocol, which is set up between a multicast tunnel relay 111 provided at the media server 1 and a multicast tunnel gateway 13 provided at the client device 2. The multicast tunnel 9 allows transmission of multicast data across the networks 5 which may or may not provide for native multicast support. As those skilled in the art will appreciate, by using a multicast tunnelling protocol such as AMT, no changes to the server or client network stacks or applications are required. Instead, the multicast tunnel relay 11 provided on the media server 1 encapsulates the multicast data packets for transmission over the multicast tunnel 9 to the multicast tunnel gateway 13 of the client device 2.

The client device 2 receives the encapsulated multicast data packets from the media server 1 via the multicast tunnel 9, and the multicast tunnel gateway 13 de-encapsulates the received packets to recover the original multicast data packets. The gateway 13 provides the recovered multicast data packets to a local host TCP/IP stack 17, for example, for onward multicast transmission to a plurality of other devices (not shown) connected to the local network, for example the LAN Sb or a Wide Area Network (WAN).

In this embodiment, the client device 2 provides an embedded media player application 19 for receiving multimedia multicast data from the media server 1 for playback by a media playback unit 21 and output on a display (not shown) of the client device 2. The media player application 19 also includes a plurality of controlled processes 23 for controlling operation of the elements of the player application 19.

The media player application 19 on the client device 2 also includes a mediator 25 which receives multicast data from, for example, the multicast tunnel gateway 13 via the local host TCP/IP stack 17. The mediator 25 converts the received multicast data to unicast which is suitable for reception and playback by non-multicast-capable applications which do not inherently support the reception and playback of multicast data, such as the media playback unit 21 of the embedded media player application 19. Mediator 25 may convert the multicast data to unicast data by translating, for example, address mappings, content or header transcodings, or other information, as appropriate. The converted unicast data is then provided by the mediator 25 to the media playback unit 21 via the local host TCP/IP stack 17 for subsequent playback and display.

As also illustrated in Figure 1, the media server I may also provide multicast data from the multicast data source 3 to a plurality of Internet service providers (not shown) via a multicast distribution backbone 15.

Figure 2 is a schematic block diagram illustrating a further example of the media system illustrated in Figure 1. As shown in Figure 2, two client devices 2a and 2b are provided for playback of multimedia originating from the multicast data source 3 of the media server 1. As discussed above, the first client device 2a receives multicast data via a multicast tunnel 9 and gateway 1 3a. The gateway 1 3a then provides the multicast data to the local host IP stack 1 7a to make the multicast data accessible to other client devices connected to the LAN 5b, such as the second client device 2b. Figure 2 schematically illustrates flow of the multicast data from the gateway 13a of the first client device 2a to the mediator 25a of the first client device 2a via the local host IP stack 1 7a, as well as to the mediator 25b of the second client device 2b via the LAN Sb and the local host 1P stack 1 7b of the second client device 2b. The mediator 25b of the second client device 2b receives the forwarded multicast data, converts the multicast data to unicast data, passes the converted unicast data to a media playback unit 21b via the local host TCP/IP stack 1 7b for playback by the second client device 2b, in the same way as discussed above with reference to Figure 1.

As also shown in Figure 2, each media player application 19 of the client device 2 includes an inter-node signalling unit 25 for providing inter-node signalling to inform other nodes of the availability of multicast data streams. In the example flow of data illustrated in Figure 2, the inter-node signalling unit 25a of the first client device 2a will transmit a separate signal, ii for example a multicast signal, to other inter-node signalling units 25 of the other client devices 2 connected to the LAN 5b, to inform the other client devices 2b that the first client device 2a is the primary gateway node in the local area network which has established a multicast tunnel with the media server 1 for reception of a particular multicast media stream. As will be discussed in more detail below, the inter-node signalling protocol advantageously reduces congestion in the network which would otherwise result from multiple multicast tunnels being created, as well as providing for smoother handover in the event that a primary gateway node is to be shut down.

Operation of the system in its preferred embodiment will now described in greater detail with reference to Figures 3, 4 and 5.

Referring to Fig. 3, a server 300 is shown communicating with a client 301 via a network 302. The case will be considered where the network 302 is incapable of supporting multitask communications. The server 300 is shown connecting to a local area network 310 and the client is shown as connected to a separate local area network 311. Within the server 300 the immediate connection to the network 310 is provided by data link layer communications function 320, which has Internet protocol layer function 321. A UIDP generator 322 is shown and an AMT tunnel function 323. Other multicast tunnel mechanisms can be used, e.g. Castgate. Also shown is a TCP protocol module 324 that need not be described. The client node or computer 301 is connected to its respective LAN 311 by data link layer module 330 and has a corresponding Internet protocol module 331. UDP receiver/generator 332 is shown as well as AMT tunnel generator 333.

In operation, a multicast data stream from a sender (not shown) is carried by LAN 310, but is unable to be transferred through the network 302 to LAN 311. The server 300 picks up the multicast data stream, which passes through the data link layer 320 and the Internet protocol layer 321 and arrives at UDP generator 322. In order to deliver the multicast data to the client, a tunnel needs to be established (through the network 302, but illustrated separately).

It is no consequence whether the tunnel is initiated by the AMT tunnel function 323 at the server side or the AMT generator 333 at the client side.

Typically, it is initiated at the client side, because the client wishes to receive the multicast data stream. Accordingly, the client side AMT generator 333 generates a request 340 for a tunnel and this request is sent (through the network 302) to the server 300. The server 300 sends its response 341 and begins to send the multicast protocol packets 342 encapsulated in unicast packet headers 343. The unicast packets are generated by UDP protocol generator 322 in server 300. At the client node 301, the UDP packets are received at the UDP module 332, where the outer "envelope" is removed, i.e. the headers are stripped off and multicast data packets are delivered to the IP layer 331. From the IP layer 331, the data stream is picked up by the TCP layer 334 and delivered to a media player 350, such as a Silverlight (TM) Media Player, and it is played out through a user screen 351 and/or an audio speaker 352.

The data stream in the IP layer 331 is a multicast data stream, and it is not only available to the media player 350, but can also be made available to other devices connected to LAN 311. It is made available to these advices through data link layer module 330.

Referring to Fig. 4, this Figure shows an extension to the right-hand side of Fig. 3 and shows the LAN 311 extended, with further user nodes 400 and 401 connected to the LAN 311.

User node 400 has data link layer module and 1P module 420 and 421 and UDP and TCP modules 422 and 424, similar to user node 301. In addition, user node 400 has a mediator module or functionality 430 which will be described in greater detail, and an application 431. User node 401 is identical.

In operation, the multicast data on the LAN 311 (now referred to as "native multicast data" because it is local to the LAN) is picked up by client nodes 400 and 401 simultaneously. Note that this is a function of multicast data. Whether a node wishes to process and output the broadcast data stream depends on the application 431 or 451. The multicast data stream passes through the data link layer and IP layer 420 and 421 and is received by UDP processing module 422. Which receives the multicast data stream and delivers it to the mediator 430. The mediator 430 converts the multicast data into unicast format. This conversion converts the address format of the multicast packets to unicast addressing format. The data stream is now available to the application 431 for use even when the application 431 is not capable of receiving multicast data format (e.g. a Silverlight Media Player which is not capable of receiving multicast data as opposed to a Windows media player which is).

Similarly, user node 401 is able to receive the multicast data, convert it is unicast format and play it through its respective player 451.

In this manner, the AMT functionality 333 of user node 301 acts as a "gateway" for the local area network 311. The multicast data is received over the tunnel 341 at the AMT gateway 333 for use by the player 350 of the user node 301, but at the same time it can be picked up by other user nodes 400 and 401 on the LAN 311. Note that it is not essential user nodes 400 and 401 have mediators 430 and 450. These user nodes can operate in the same manner provided that their respective players are capable of receiving and playing multicast format data.

Referring now to Fig. 5, further details of user nodes 400 and 401 will be described. In addition to the elements described with respect to Fig 4, novel signalling protocol functions 460 and 461 are provided in the respective nodes, as well as AMT tunnelling functions 462 and 463. The scenario will be considered where the AMT function of node 400 has established the tunnel 340/341 with the server side server 300. In this scenario, user node 400 is the "gateway".

In operation, for so long as the tunnel is established, AMT function 462 is active, and signalling protocol function 460 generates a periodic signal indicating the active nature of the AMT function 462. This periodic signal is sent through the lower layers 422, 421 and 420 onto the LAN 311. The message is placed on the LAN 311 in the form of a multicast control message.

Thus, it is available to be picked up by node 401 and any other node on the network. In this manner, node 400 continues to signify that it is the gateway.

This signal can be sent, for example, every two to five seconds.

So long as any other node on the network wishes to receive that particular broadcast stream, it is able to identify that there is already a gateway node that is providing the broadcast data stream in multicast format.

Thus no other node need establish a tunnel to the server 300.

The node 400 may cease sending of these signals for one of two reasons. The first may be because it crashes or simply is switched off. The second is because the user of node 400 no longer wishes to play out broadcast data stream.

In the first scenario, the signalling from signalling protocol generator 460 ceases, and any other node that is receiving that broadcast data stream (e.g. node 401) will identify in its signalling protocol function 461 that the signalling has ceased and that the broadcast data stream is therefore no longer available or in imminent danger of becoming unavailable. When this happens, signalling protocol function 461 causes AMT function 463 to establish a tunnel through the network 302 to the server 300 to receive the data stream in its multicast format encapsulated in unicast UDP packets.

These are then unencapsulated and playing continues. At the same time, being unencapsulated, they are available as multicast packets in the protocol stack of user node 401 and are available to other nodes on the network. As soon as the tunnel is established by AMT node 463, signalling protocol function 461 begins to generate a periodic signal indicating that it is the new gateway. If user node 400 re-establishes itself, it can now receive the broadcast data stream from the LAN 311 via user node 401.

In the second scenario, where the user node 400 simply wishes to stop playing the broadcast data stream, the user clicks on a "stop" button on his user interface, and this causes signalling protocol function 460 to cease transmission of signalling indicating the gateway function. This is not to say that the tunnel immediately ceases. In this scenario, the tunnel can be maintained by tunnel function 462 for a few seconds more, and the data stream can continue to be provided as multicast data to the LAN 311, giving sufficient time for the tunnel function 463 of user node 401 to establish a new tunnel and commence reception of the data stream. After an appropriate period of time (or by some other mechanism), AMT function 462 can tear down the tunnel.

Referring again to Fig. 4, a further functionality of the mediator 430 or 450 is now described. It is particularly advantageous that the mediator 430 (or 450) generates logging information concerning the playing of the data stream through the player 431 (or 451). In other words, version of the multicast data to unicast format and delivery to the player, the mediator 430 logs the duration of playing and the particular data stream that is being played. Upon cessation of playing, the media 430 generates a log URL report, by which the total duration of playing and the particular data stream being played is delivered as a message to a predetermined URL In this way, for each unicast data stream delivered by the mediator, appropriate reporting is generated to a central location for purposes of billing and the like.

Figure 6 is a flow diagram illustrating the operation of the media player application 19 to respond to a user request for a media data stream. At step S6-1, the media player application 19 receives a user request for a particular media data stream. At step S6-3, in response to receipt of the user request, the media player application 19 looks for a local unicast which meets the user request. If a local unicast is available, the media player application 19 initiates streaming of the local unicast via the local host TCP/IP stack at step S6-5, and at step S6-6, the data stream is played back by the media playback unit 21. However, if the media player application 19 does not find a local unicast meeting the user request at step S6-3, then at step S6-7, the media player application 19 activates the mediator 25 at step S6-7. At step S6-9, the mediator 25 listens for a multicast meeting the user requested data stream. If a desired multicast is available, then at step S6-1 1, the mediator 25 receives the multicast data packets for the desired data stream and processes the received multicast data packets to convert the multicast data to unicast data. The converted unicast data is passed to the media playback unit 21 via the local host TCP/IP stack 17 for playback at step S6-6, as discussed above.

If at step S6-9, the mediator 25 does not find a multicast meeting the user request, then at step S6-13, the media player application 19 activates the media tunnel gateway 13 to receive the user requested data stream. The media player application 19 then introduces the received multicast to the local network for processing by the mediator 25 at step S6-1 1 and playback by media playback unit 21 at step S6-6, as discussed above.

Alternative Embodiments The embodiments described above are illustrative of rather than limiting to the present invention. Alternative embodiments apparent on reading the above description may nevertheless fall within the scope of the invention. Embodiments of the present invention include various processes and operating units forming a server (or cluster of servers) or client device.

The processes may be performed by a unit or units such as hardware components or maybe embodied in machine-executable instructions, which may be used to cause one or more processors programmed with the instructions to perform processes. Alternatively, the processes may be performed by a combination of hardware and software. As used in herein, a unit performing a process can be one or more processors, ASIC, a controller such as a micro-controller, and any other module capable of carrying out the processes.

Embodiments of the present invention may be provided as a computer programme product that may include a machine-readable medium having stored thereon instructions, which may be used to programme a computer (or other electronic device) to perform a process according to embodiments of the present invention. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMS), magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable or read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROM5), magnetic or optical currents, flash memory, or other type of medialmachine-readable medium suitable for storing instructions. Moreover, embodiments of the present invention may also be downloaded as a computer programme product, wherein the programme may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium by a communication link (e.g., a modem or network connection).

Claims

Claims: 1. A method for multicasting communication comprising: receiving a multicast data stream at an end user node from a source; providing the data stream to a communications protocol stack at the end user node and making it is accessible as multicast data to other end user nodes over a local area network; converting the multicast data to unicast data at the end user node; and playing the unicast data stream through a media player; wherein the multicast data stream is received at the end user node by means of a tunnel through a wide area network.
2. A method in accordance with claim 1 or 2, further comprising, at the end user node, providing inter-node signalling to inform other nodes that the first node is a gateway for that data stream.
3. A method in accordance with claim 1, 2 or 3 further comprising an inter-node signalling protocol which indicates to all nodes which node is a primary gateway for the data stream.
4. A method in accordance with claim 4, wherein the inter-node signalling protocol facilitates changing of the primary node.
5. A method in accordance with any one of claims 1 to 5, further comprising, at the end user node, providing inter-node signalling to inform other nodes of an imminent cessation of the multicast data.
6. A method in accordance with claim 6 further comprising, at the end user node, receiving the requested data stream from the source by means of tunnelling only if it is not available as multicast data from another node.
7. A method of multicasting communication between first and second end user nodes connected via a network supporting multicast capability, comprising: receiving a multicast data stream at the first end user node from a source by means of multicast tunnelling; providing the data stream to a communications protocol stack at the first end user node and making it is accessible as multicast data to the second end user node over the local area network; converting the multicast data to unicast data at the first user node; and playing the unicast data stream through a media player at the first end user node.
8. A method in accordance with claim 8, further comprising, at the first end user node, providing inter-node signalling to inform the second end user node of an imminent cessation of the multicast data; continuing reception of the multicast data at the first end user node for a period of time without playing it out through the player; establishing a new connection from the second end user node to the source by means of multicast tunnelling; signalling between the first and second end user nodes to allow the first end user node to cease reception of the data stream and allow the second end user node to receive the data stream and make it available to other end user nodes.
9. A method for multicast communication comprising: receiving a multicast data stream at an end user node via a communications protocol stack; converting the multicast data to unicast data at the end user node; providing the data stream as unicast data to the communications protocol stack at the end user node; and playing the unicast data stream from the communications protocol stack through a media player at the node.
10. A method in accordance with claim 10, further comprising: providing the multicast data stream as multicast data to the communications protocol stack at the end user node and making it is accessible as multicast data to other end user nodes over a local area network.
11. A method in accordance with claim 10 or 11, further comprising: logging conversion of a data stream; and reporting to a predetermined destination address at least the data stream converted and the duration of the data stream.
12. A method in accordance with claim 11 further comprising providing, as a downloadable plug-in, means for converting the data from multicast to unicast fonn.
13. A computer program product having stored thereon instructions that, when executed by a suitable processor connected to a network, cause the processor to perform the method of any one of claims 1 to 8.
14. A user device for connection as a node to a network for multicasting communication comprising: means for receiving a multicast data stream at an end user node from a source; means for providing the data stream to a communications protocol stack at the end user node and making it is accessible as multicast data to other end user nodes over a local area network; means for converting the multicast data to unicast data at the end user node; and means for playing the unicast data stream through a media player.
15. A device in accordance with claim 14, comprising tunnelling means for receiving the multicast data stream at the end user node by means of a tunnel through a wide area network.
16. A device in accordance with claim 15 or 16, further comprising an inter-node signalling generator to inform other nodes that the first node is a gateway for that data stream.
17. A network comprising first and second end user nodes and means for multicast communication therebetween, comprising: means for receiving a multicast data stream at the first end user node from a source by means of multicast tunnelling; means for providing the data stream to a communications protocol stack at the first end user node and making it is accessible as multicast data to the second end user node over the local area network; means for converting the multicast data to unicast data at the first user node; and a media player for playing the unicast data stream at the first end user node.
18. A downloadable plug-in for a user device connected to a network, where the user device has means for receiving a multicast data stream from a source, the plug-in being adapted and arranged to provide a player on the user device that is capable only of playing unicast data streams with conversion means for converting the multicast data to unicast data for playing the unicast data stream through the media player.
19. The plug-in of claim 18, further being adapted and arranged to provide the user device with means for logging conversion of a data stream and for reporting to a predetermined destination address at least the data stream converted and the duration of the data stream.
20. A multicast data streaming system substantially as hereinbefore described with reference to, or as illustrated in Figure 1, 2, or 3 to 5 of the accompanying drawings.
21. A data streaming method substantially as hereinbefore described with reference to, or as illustrated in Figure 6 of the accompanying drawings.