WO2010041020A1

WO2010041020A1 - Multicast media system

Info

Publication number: WO2010041020A1
Application number: PCT/GB2009/002409
Authority: WO
Inventors: Anthony J. Ballardie; Dominic N. Robinson
Original assignee: Gmix Software Limited
Priority date: 2008-10-08
Filing date: 2009-10-08
Publication date: 2010-04-15
Also published as: GB0818489D0; GB2464452A

Abstract

A multicast media streaming method and system is provided for multicasting communication. A multicast data stream is received at an end user node from a source. The data stream is provided 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. The multicast data is converted to unicast data at the end user node. The unicast data stream is then played through a media player. The multicast data stream is received at the end user node by means of a tunnel through a wide area network.

Description

MULTICAST 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 Tunnelling 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 'tunnelled' IP Multicast.

WMTaIk is another forum, created initially by Microsoft, but with public access, where many 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 delivery of IP 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 tunnelling 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. Additionally, the technology introduces a signalling 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 multicast data from another node.

hi 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.

hi 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 Tunnelling) 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;

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;

Figure 7 is a flow diagram schematically illustrating interactions and state transitions between the mediator and gateway components according to an embodiment of the inter-node signalling protocol; and

Figure 8 is a schematic diagram illustrating protocol message formats according to an embodiment of the invention.

Detailed Description of Embodiments of the Invention

Overview

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. Li 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 11 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 5b 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 1 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 13a. The gateway 13a then provides the multicast data to the local host IP stack 17a 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 17a, as well as to the mediator 25b of the second client device 2b via the LAN 5b and the local host IP stack 17b 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 17b 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, hi 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, 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

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 UDP 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 (™) 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 IP 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 foπnat data.

User nodes

Referring now to Fig. 5, further details of user nodes 400 and 401 will be described, hi 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.

hi 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 uiiencapsulated 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.

hi 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, hi 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.

Media Player Application

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 S 6-1, the media player application 19 receives a user request for a particular media data stream. At step S 6-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-11, 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 S 6-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-11 and playback by media playback unit 21 at step S6-6, as discussed above.

Inter-node Signalling Protocol

Referring to Figure 7, further specific details of an embodiment of the inter-node signalling protocol will now be described. In this embodiment, the protocol will be referred to as an AMT Inter-Gateway Signalling Protocol (IGSP). Figure 7 is a flow diagram schematically illustrating interactions and state transitions between the mediator 25 and gateway 13 components according to an embodiment of the IGSP.

As described above, IGSP is a LAN-based stateless application-layer protocol with two protocol components, an AMT gateway (corresponding to the media tunnel gateway 13 illustrated in Figures 1 and 2) and a Mediator (corresponding to the mediator 25 illustrated in Figures 1 and 2). Any node on a LAN 5b can adopt one or both IGSP components. If a node adopts both components that node acts as two logically separate protocol components. In this particular embodiment, the IGSP protocol and its component interactions will be described in relation to an arrangement of nodes which provides the protocol components in physically separated nodes. For the protocol to be robust, it is advantageous to provide at least two physically separate AMT gateway components 13 present per LAN segment. The protocol will automatically elect one as the Primary gateway and the other will be the Secondary, or backup, gateway. As those skilled in the art will appreciate, as an alternative, the protocol will operate perfectly well with just one gateway per LAN, provided the gateway does not fail.

All of the IGSP protocol messaging takes advantage of IP multicast, inherent in most LAN technologies today. Both components listen on a predefined IP multicast address assigned to the IGSP protocol. All IGSP protocol messages are sent to this multicast group, which is confined to the LAN 5b. In this embodiment, the multicast group is assigned a IGSP group IP address of 224.0.0.50. The protocol messages are sent using the UDP transport protocol. In this embodiment, the IGSP protocol's UDP port is 31000.

IGSP: AMT Gateway behaviour

As mentioned above, IGSP-enabled AMT gateways 13 use IGSP to elect a Primary gateway. The Primary gateway is the gateway on the LAN 5b elected to form a multicast tunnel to a remote tunnel end-point which is connected to one or more multicast content sources.

As illustrated in Figure 7, the IGSP election process begins after start up and initialisation of a gateway 13 at step S7-1. In a learning step S7-3, IGSP Hello messages are multicast to the IGSP group address on which all IGSP-enabled nodes (gateways 13 and mediators 25) listen. Mediators 25 ignore IGSP Helios. Each AMT gateway 13 may be explicitly configured with an IGSP Priority. In this embodiment, the IGSP Priority value is an integer from O to 15, with 15 being the default. The priority is used by a LAN administrator to preference a particular gateway 13 to become the elected Primary. Figure 8 is a schematic diagram illustrating protocol message formats according to the present embodiment. As shown in Figure 8, IGSP Hello messages 81 contain the sending gateway's configured (or default) priority 83. In this embodiment, IGSP Helios are multicast at fixed intervals (e.g. 5 seconds) for as long as a gateway 13 is running.

When a Hello is received by a gateway 13, that gateway compares the Hello's priority 83 with that of its own. In the absence of a configured priority, or in the event of a tie between the priority values, the Hello with the highest IP address is considered the Primary gateway 13 by this node, at step S7-5. Any gateway 13 which is not itself the Primary, is considered a secondary or backup gateway, at step S7-7. However, a node's status may subsequently change as the Hello protocol is running on the gateway 13 all the time.

As discussed above, the role of the Primary gateway 13 is to initiate a AMT multicast tunnel 9 on receipt of an IGSP AMT Tunnel Request, with the exception of these two circumstances:

1. The Primary gateway 13 already has already created a tunnel 9 (as only one tunnel 9 is needed for all multicast sources and groups). Once an AMT gateway 13 has created a tunnel 9, then at step S7-9, it starts multicasting IGSP Tunnel Active Node (TAN) messages 85 to the IGSP group to notify all other IGSP gateways 13 that a tunnel 9 is active for the LAN 5b.

2. This gateway 13 has an active tunnel 9 and is multicasting IGSP TAN messages, but it is no longer considered the Primary gateway 13 because, for example, a new gateway 13 has started and been elected the new Primary gateway 13. However, since the new Primary gateway 13 will also be receiving the IGSP TAN messages from the active tunnel node, the new Primary gateway does not initiate a new tunnel so long as it continues receiving TAN messages.

IGSP: Mediator behaviour

The mediator 25 is triggered by the user requesting a content stream via HTTP, at step S7-11. Where the mediator 25 is deployed, the content is assumed to be IP multicast content. In this embodiment, the content source 3 is remote from the LAN 5b.

When the media player application 19 starts, it passes to the mediator 25 the stream metadata URL, requests the mediator 25 to play the stream via a designated TCP port on the localhost, and the mediator 25 fetches the stream's metadata. The mediator 25 then processes the stream's parameters. At step S7-13, the mediator 25 issues a IGSP AMT Tunnel Request (TR) 87 for the stream's (source, group) pair. At step S7-15, the IGSP TR is multicast to the IGSP group and received by all IGSP enabled gateways 13. The elected Primary gateway 13, or Tunnel Active Node, processes the IGSP TR and depending on whether a tunnel already exists, initiates a tunnel, or if it already has a tunnel established, silently discards the TR. To protect against TR packet loss, the mediator 25 re-transmits the TR at least 3 times at short intervals (e.g. every 5 seconds). Subsequent to sending the TR, the mediator 25 signals its continued interest in the content source and group by multicasting a periodic IGSP Group Refresh 89 for the (source, group) pair. When the TAN gateway receives this it refreshes its tunnel state for the (source, group) pair.

As those skilled in the art will appreciate, as an alternative, the IGSP Group Refresh 89 may be replaced by simply issuing a periodic IGSP TR 87 for the (source, group) pair. In such a scenario, the Group Refresh 89 is redundant and steps S7-13 and S7-15 may be combined into a single transition state as indicated by the dashed box.

At step S7-17, the application terminates on the mediator node 25 and the periodic IGSP Group Refresh 89 (or TR 87) messages cease. Lack of notification of interest for the (source, group) results in the TAN gateway timing out that source and group which in turn will result in the expiry of the AMT tunnel state for that source and group.

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 (EEPROMs), magnetic or optical currents, flash memory, or other type of media/machine-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-ήode 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 7, 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 in accordance with claim 7, further comprising: determining, at the second end user node, an imminent cessation of the multicast data from the first end user node from a cease in inter-node signalling; establishing a new connection from the second end user node to the source by means of multicast tunnelling; signalling by the second end user nodes to allow the second end user node to receive the data stream and make it available to other end user nodes.

10. 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.

11. 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.

12. 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.

13. A method in accordance with claim 10 further comprising providing, as a downloadable plug-in, means for converting the data from multicast to unicast form.

14. A computer program product having stored thereon instructions that, when executed by a suitable processor connected to a network, cause the processor to perfoπn the method of any one of claims 1 to 9.

15. 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.

16. A device in accordance with claim 15, comprising tunnelling means for receiving the multicast data stream at the end user node by means of a tunnel through a wide area network.

17. 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.

18. 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.

19. 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.

20. The plug-in of claim 19, 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.