WO2008083459A1

WO2008083459A1 - System and method for duplicating and delivering media streams using the unicast protocol

Info

Publication number: WO2008083459A1
Application number: PCT/CA2007/001831
Authority: WO
Inventors: Mathieu Giguere; Patrick Riendeau; Marc-André FORGET; Ronald Brisebois
Original assignee: Technologies Ezoom Exponentiel Inc.
Priority date: 2007-01-12
Filing date: 2007-10-16
Publication date: 2008-07-17

Abstract

In the system and method for duplicating and delivering media streams from at least one media streamer to end users using a Unicast protocol, requests for media streams from the end users are received and processed. The requested media streams are received from the at least one media streamer and duplicated in response to the requests from the end users. The requested and duplicated media streams are delivered to the corresponding requesting end users through a communication network and using the Unicast protocol. The media stream duplicating and delivering system and method forms an interface between the at least one media streamer on one side and the end users on the other side, whereby access to the requested media streams by the end users is available only through the media stream duplicating and delivering system and method.

Description

TITLE OF THE INVENTION

SYSTEM AND METHOD FOR DUPLICATING AND DELIVERING MEDIA STREAMS USING THE UNICAST PROTOCOL

FIELD OF THE INVENTION

[001] The present invention generally relates to media streaming.

More specifically, but not exclusively, the present invention is concerned with a system and method for duplicating and delivering media streams using the Unicast protocol.

BACKGROUND OF THE INVENTION

[002] In the past few decades, Internet has experienced an incredible boom in its growth and expansion. Also, technologies changed from centralized computing to personalized computing, then to mobile computing and now to intelligent services with a convergence of networks, devices and services. Since users and consumers are always connected and are demanding for more, personalized and intelligent services are required in order to satisfy the demands and expectations of the consumers.

[003] For example, the field of streaming has been constantly growing for the past five years and IP TV (Internet Protocol Television) is becoming more and more popular. Also, IP TV can offer personalized profiles and searches. Companies offering such services can use intelligently targeted advertisement in order to increase their income; this can potentially become a huge market.

[004] IP TV is based on broadcasting media streams. More specifically, IP TV started with broadcast content and is now moving towards Unicast content for achieving personalized services. [005] A broadcast media stream is a media stream that is consumed (heard or viewed) while it is being delivered to a consumer. Each stream (audio or video) is delivered to the consumer through a network. Two protocols can be used when broadcasting to a large audience over the network: Unicast or Multicast.

[006] The Unicast protocol sends a separate copy of the media stream from a server to each client or end user. This is simple, but can lead to a massive duplication of data or media streams through the network, which implies the use of many servers for providing a separate copy of the media stream to each client or end user.

[007] The Multicast protocol sends only one copy of the media stream over any given network connection, i.e. along the path between any two network routers. This is a more efficient use of the network capacity and it keeps the number of servers to a minimum, but it is much more complex to implement. Furthermore, the multicast protocol is implemented in the network routers, as well as in the servers. Plus, forwarding multicast traffic requires a great deal of protocol complexity, particularly when knowing and satisfying in real-time the profile of each client or end user of the audience, such as personalized content, interactions, billing, Quality-of-Service (QoS), etc. Thus, the multicast protocol suffers from deployment problems and complexity. Also, there is no efficient software to support such deployment and implementation. Usually, the few networks that use multicast protocols are complex and expensive, and they are also difficult to install and maintain.

[008] Therefore, there is a need for overcoming the above discussed problems related to both the Unicast and Multicast protocols. Accordingly, a system and method with an approach similar to the Unicast protocol but offering the capabilities of the Multicast protocol for providing, in a simple way, personalized streaming content to clients or end users are sought.

SUMMARY OF THE INVENTION

[009] According to the present invention, there is provided a method for duplicating and delivering media streams from at least one source of media streams to end users using a Unicast protocol. The method comprises receiving and processing requests for media streams from the end users, receiving the requested media streams from the at least one media stream source, duplicating, in response to the requests from the end users, the requested media streams, and delivering the requested and duplicated media streams to the corresponding requesting end users through a communication network and using the Unicast protocol. The media stream duplicating and delivering method forms an interface between the at least one media stream source on one side and the end users on the other side, whereby access to the requested media streams by the end users is available only through the media stream duplicating and delivering method.

[0010] The present invention also relates to a system for duplicating and delivering media streams from at least one source of media streams to end users using a Unicast protocol. The system comprises a processor of requests for media streams from the end users, a receiver of the requested media streams from the at least one media stream source, a duplicator responsive to the requests for media streams from the end users and structured to duplicate the requested media streams received by the receiver from the at least one media stream source, and a sender of the requested and duplicated media streams to the corresponding requesting end users through a communication network and using the Unicast protocol. The media stream duplicating and delivering system forms an interface between the at least one media stream source on one side and the end users on the other side, whereby access to the requested media streams by the end users is available only through the media stream duplicating and delivering system.

[0011] The foregoing and other objects, advantages and features of the present invention will become more apparent upon reading of the following non-restrictive description of an illustrative embodiment thereof, given by way of example only with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In the appended drawings:

[0013] Figure 1 is a schematic view of a current, known network broadcasting model;

[0014] Figure 2 is a schematic view of a network broadcasting model comprising a system for duplicating and delivering media streams using the Unicast protocol according to the non-restrictive illustrative embodiment of the present invention;

[0015] Figure 3 is a schematic block diagram of the system for duplicating and delivering media streams using the Unicast protocol according to the non-restrictive illustrative embodiment of the present invention;

[0016] Figure 4 illustrates a flow chart showing duplication of a media stream; and [0017] Figure 5 illustrates a flow chart showing encapsulation and communication of data packets between a NPU (Network Processing Unit) and a processor.

DETAILED DESCRIPTION

[0018] Generally stated, the non-restrictive illustrative embodiment according to the present invention can be an embedded piece of software implemented directly in a network processing unit, that rationalizes and accelerates non-intrusively the delivery of streaming media to remote end users while lowering deployment costs and operating expenses, improving streaming Quality-of-Service (QoS) and opening the feasibility of new TV and Audio related applications over an IP network. The non-restrictive illustrative embodiment of the present invention uses standard networking equipments and is compatible with the Internet Protocol (IP). It can duplicate, control and deliver media streams to an unlimited number of destinations using the Unicast protocol. It also uses standard IETF (Internet Engineering Task Force) protocols and it is not bound to any streaming audio or video CODEC. However, it can further use proprietary protocols, specific to different elements in the network.

[0019] Furthermore, the non-restrictive illustrative embodiment of the present invention takes advantage of both Unicast and Multicast protocols. For a standard server, only one copy of the media stream is sent to a large audience, without using the complexity inherent to the Multicast protocols.

[0020] It should be noted that the non-restrictive illustrative embodiment according to the present invention can be implemented through a specially designed chip or a FPGA (Field Programmable Gate Array) or a network processor unit inside a switch. [0021] Although the non-restrictive illustrative embodiment of the present invention will be described in conjunction with an Internet network using an IP (Internet Protocol), it should be kept in mind that the various features of the non-restrictive illustrative embodiment of the present invention could be applied to another type of communication network using another type of communication protocol.

[0022] Figure 1 shows a current known model 10 of a network for broadcasting media streams, which consists of four (4) segments: a headend segment 12, a transport segment 14, an access segment 16 and a home segment 18.

[0023] First, in the headend segment 12, broadcast information and signals are received by a plurality of media streamers 20 through digital and analog receivers 22, including for example antennas. The plurality of media streamers 20, for example special streaming servers, is connected to a switch 24. Also connected to the switch 24 are application servers 26 and other content sources 28.

[0024] The switch 24 allows to forward the media streams received from the plurality of media streamers 20, the application servers 26 and/or the other content sources 28, to the public internet network 30 using the IP (Internet Protocol) in the transport segment 14. The media streams are composed of data packets in which is encapsulated a destination address such that the public internet network 30 knows where to send each data packet for reaching its destination.

[0025] The media streams then enter each user's home 18 through the access segment 16. The access segment 16 to the users' home may consist of a DSLAM (Digital Subscriber Line Access Multiplexer) 32, a cable 33, or a radio frequency access 34 via antennas. The media streams finally arrive at each user's computer 36 either through, for example, a suitable modem 38, for example a WiMax™ modem, wirelessly connected to the radio frequency access 34, a cable modem 40 connected to the cable 33 or a xDSL (x Digital Subscriber Line) 42 connected to the DSLAM 32. Each user can start viewing or listening to the media streams as the media streams are received.

[0026] When a large number of end users want to watch or listen to the media streams, a heavier infrastructure would be required for supporting a larger number of media streamers 20, which is not an optimal solution. Therefore, a new and lighter infrastructure is illustrated in Figure 2.

[0027] More specifically, Figure 2 shows a model 60 of a network for broadcasting media streams according to the non-restrictive illustrative embodiment of the present invention. The model 60 is very similar to the model 10 in Figure 1. However, the plurality of media streamers 20 has been reduced to one media streamer 62 (or a few media streamers) connected to a streaming accelerator (SA) 64, which is in turn connected to the switch 24. Also, the application servers 26 and the other content sources 28 are connected to the switch 24 through the SA 64. The SA 64 duplicates and delivers media streams from the media streamer 62, application servers 26 and other content sources 28, using the Unicast protocol. The model 60 is much lighter in terms of number of media streamers and thus infrastructure, and is easier to handle, maintain and deploy, while being able to support a large number of end users. Furthermore, the SA 64 is compatible with the current IP equipments and can be easily integrated into existing network infrastructures. The rest of the model 60 of the network remains the same as described hereinabove in accordance with Figure 1. It should be noted that the same numerals correspond to the same elements as shown in Figure 1. [0028] More specifically, the SA 64 produces Multicast packets through a duplication process, while using the Unicast protocol for delivering the media streams.

[0029] Now turning to Figure 3, the SA 64 will be described in more detail. The SA 64 comprises a processor 70 and a forwarding element 72. A private network 74 is interposed between the processor 70 and the forwarding element 72 to ensure bi-directional communication between the processor 70 and the forwarding element 72. This will allow, for example, the processor 70 to control the forwarding element 72. The private network 74 can be an internal base channel using GbE (Gigabit Ethernet) or any other link that allow communication between different elements.

[0030] The SA 64 may further comprise a plurality of processors 70 and/or a plurality of forwarding elements 72 for supporting a variety of different services and functionalities.

[0031] The forwarding element 72 communicates with the processor

70 through the private network 74 using, for example, a MVIF (Multiple Command Virtual Interface) as will be described hereinbelow. Furthermore, the forwarding element 70 is connected to an external network 76, which is usually an ultra fast network using, for example, 10 Giga or 100 Giga Ethernet. The external network 76 will route and deliver data packets of the requested media streams duplicated by the SA 64 to each user's destination.

[0032] The processor 70 may comprise a RTSP (Real-time

Streaming Protocol) proxy+ 78 or any other software/hardware which can accomplish the following functions: handling users' requests for media streams, handling users' authentication and handling media streamers such as 62. The proxy 78 is responsible for identifying where to find streaming content, for example from a media streamer such as 62, and can receive a high volume of connections and requests for media streams from the end users. Indeed, when an end user wants to listen to a specific piece of music or to watch a particular video or other program, the end user sends out a request for the corresponding media stream. The proxy 78 receives the request and, then, authenticates the end user using different methods of authentication such as validating passwords or IP addresses of the requesting end users, etc. After the authentication has succeeded, the proxy 78 identifies and enters in contact the media streamer 62 capable of supplying the requested media stream in order to get the requested media stream.

[0033] In the non-restrictive illustrative embodiment of the present invention, the communications are performed using the RTP (Real-Time Protocol) or RTCP (Real-Time Control Protocol). However, it should be kept in mind that other, different protocols can be used without departing from the nature and scope of the present invention.

[0034] The processor 70 further comprises a MVIF (Multiple

Command Virtual Interface) driver 80, which is a communication driver of layer 2 of the OSI (Open System Interconnection) model, which is the data link layer. The MVIF driver 80 forms an interface that is used to exchange data packets between processor 70 and the forwarding element 72. The MVIF driver 80 is designed to decapsulates/encapsulates original packets from the element 72 in the layer 2 protocol. More specifically, the MVIF driver 80 removes/adds a MAC (Media Access Control) address and proprietary header in front of the original packet. However, by so doing, it adds one constraint to the design of the SA 64. This constraint is concerned with an internal network representing the link between a host 84 of the forwarding element 72 and a NPU (Network Processing Unit) 82 of the same forwarding element 72. When using the MVIF driver 80, this internal network has to be able to support jumbo frames, which are frames of size of 1518 bytes or more. [0035] In terms of the implementation of the MVIF driver 80, when using a single blade solution (meaning that there is only one hardware card for supporting the processor 70 and the forwarding element 72), a RGMII (Reduced Giga Media Independent Interface) port or connector from the NPU 82 to the host 84 will be used. When using a distributed solution, a reserved port must be used to achieve the same result. For example, this reserved port is connected to a basic switch fabric in an ATCA (Advanced Telecom Computing Architecture) chassis.

[0036] The protocol used by the MVIF driver 80 can use a reserved

(experimental) Ethernet protocol-type to identify the encapsulated packet (for example OxOffO in the non-restrictive illustrative embodiment of the present invention). After the proprietary protocol is incorporated into the packet, the header can be given by message type and physical port. For example, two (2) message types are supported: forward and local packets. And the physical port corresponds to the input or output port used for receiving or sending the packets.

[0037] Finally, the processor 70 may comprise a statistic reporter

(not shown). The statistic reporter is responsible for fetching information about the users' accounts, using for example RADIUS (Remote Authentification Dial in User Service). This information can be used for billing purposes, for example. The statistic reporter can also collect or produce statistics about the quality of the communication network in general.

[0038] In the network, two session information are created. The first session information is established between the proxy 78 and the media streamer 62 when the proxy looks for a media stream requested by an end user. The second session information is established between the proxy 78 and the end user requesting the media stream. [0039] The forwarding element 72 of the SA 64 comprises a NPU

(Network Processor Unit) 82 and a host 84 as shown in Figure 3, for performing the duplication of the media streams.

[0040] The NPU 82 comprises a plurality of elements, such as a receiver/sender 86, a duplicator 88, a stream modifier 90, a RTCP handler 92, a packet sender 94 and a local packet handler 96.

[0041] Media stream duplication 100 will now be described in connection with the flow chart of Figure 4, and referring to the structure of Figure 3.

[0042] The receiver/sender 86 first receives the data packets of the media stream requested by the end user from the media streamer 62 (as shown in Figure 2), in operation 102.

[0043] The received data packets are then sent to the duplicator 88 in operation 104.

[0044] The data packets supplied to the duplicator 88 are first identified or matched to a streaming flow in operation 106. For that purpose, a flow matching based on a 5-tupple is used. The 5-tupple information concerning a data packet is given by: the source IP address, the destination IP address, the nature of the used protocol, the source port and the destination port.

[0045] Once the streaming flow matching of operation 106 is performed, meaning that the data packets are identified, the duplicator 88 duplicates n times the data packets in operation 108. Each data packet can be duplicated up to 4095 times, mainly due to the limitations in current switches. Furthermore, each streaming flow represents one instance of the duplicator 88, and the duplicator 88 can manage up to 255 instances per NPU and each instance can produce up to 4095 copies, whereby a total of 1 ,044,225 copies of the same source media stream can be generated. A special hash table is used to keep track of the number of copies. It can be fetched with a KEY and the results are shown below:

KEY: IP source + IP destination + Protocol + Source port +

Destination port

Result: Number of copies for the last instance (maximum of 4095) Number of instances (maximum of 255)

[0046] After the duplication is completed, the n duplicated data packets or copies are sent to the stream modifier 90 in operation 110.

[0047] Inside the stream modifier 90, stream modification is performed in operation 112. The packets of the requested and duplicated media streams are modified according to the session information of the corresponding, requesting end users. The session information can be found in a compact hash table or a lookup table included in and controlled by the host 84. The KEY used to fetch information in the hash table is as follows:

KEY: IP destination + Protocol + Source port + Destination port +

ID Result: physical port

MAC address

IP destination

UDP (User Datagram Protocol)/TCP (Transmission Control

Protocol) source and destination port

VLAN (Virtual Local Area Network) /Pbits (layer 2 Priority bits)

ToS (Terms of Service)

[0048] Such hash table and packet information are used over IPv4

(Internet Protocol version 4), which is still widely used for most of the Internet networks. However, they can also be used over IPv6 (Internet Protocol version 6). The different fields inside the packet stay the same except for the field regarding the IP level checksum, which does not exist for IPv6.

[0049] Each packet is therefore modified according to results retrieved from the hash table. For example, the MAC layer can be completely replaced by the next gateway physical layer. This information can be resolved using the host ARP (Address Resolution Protocol) table. This information can also be directly resolved by the forwarding element 72. The destination IP address and ToS bits (and obviously the IP header checksum), corresponding to each end user are also changed in the IP layer. Finally, the destination port at the UDP (User Datagram Protocol) layer is further changed, so that the UDP checksum needs to be recalculated. The modified packets are then ready to be sent out to their respective destination.

Table 1 : Modifications done in each packet: underlined

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+—H—I—+—H—H-+-+-H 1—+-+-+—K-+-H—+-+-+-+-+-H H—H-+-+-+-H—H V-+-λ H

M I Destination MAC

A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C Destination MAC I Source MAC

Source MAC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Type I

H—+-H—+—H—V-+-λ—H—H—H—H V-λ—+-H—+

IVersionl IHL I Type of Service I Total Length |

+-+-+-H—+—H-H—H—+-H—H—+—H-+-+—H-H—H—+—V—V—V—H-+-H V-λ V-+-λ—H H—V

1 I Identification | Flags | Fragment Offset |

P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I Time to Live I Protocol I Header Checksum |

H—H—H—H 1 V-+-+-Λ—H—H—+—V—I—+—I—H—+-+-+-+—V-+-+—I—+-H V-+-Λ 1 H—V

I Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Destination Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Options I Padding |

H—H—H—H V—V-+-+-Λ—H—+-+—H-+-+—H-H—+-+-+—H—H—H-+-+—V-λ H—V-λ H—H-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U I Source port I Destination port |

D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P I UDP length | UDP checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I V I P I X I CC | M | PT I sequence number |

+-H — H — H h — I-- + - + -H — H — H — + -+-H — + — I — H — + — h — I 1 — + — I-- + -H H-H — H 1 ^ — H- + - +

R I timestamp |

T +-H — H — H — +-H H- + -H — H — +- + -H — + - + — I — + - + — I — + - + -H — + — H-H — H h-H — H V — h- + — h

P I synchronization source (SSRC) identifier |

I contributing source (CSRC) identifiers |

I I

I DATA I

+ — h — h — I 1 h — H-H — H — H — + - + — H- + - + — I — H — + — ^ — I — H — H ^ — H-H 1 — + -H 1 1-- + - + - +

[0050] The result of the duplication process 100 consists of Unicast packets, which are ready to be used in the multicast loopback in the TM (Traffic Manager, not shown). The term "loopback" means that the n duplicated data packets are sent by the packet sender 94 back to the receiver/sender 86 (operation 114 of Figure 4) through a specific port indicated by the stream modifier 90 in view of being sent out (operation 116 of Figure 4) by the sender 86 to the external network 76 (Figure 3) in destination to each corresponding requesting end user.

[0051] More specifically, in operation 114, all the duplicated packets are supplied to their respective ports in the NPU 82 as indicated by the stream modifier 90. They are then sent out from their respective ports in the NPU 82 in operation 116. Their destination MAC address has been inserted by the receiver/sender 86, according to the information given by the lookup tables of the host 84.

[0052] However, it may happen that some incoming packets, from the media streamer 62, cannot be identified with the lookup tables. Those non- identified packets, called local packets (as opposed to the forward packets which are sent out to the network) are handled by the local packet handler 96. The local packet handler 96 sends them to the host 84 or to the processor 70 for further and deeper processing (or local processing). A packet to be considered valid at the local processing must first have a valid MAC address, so that the packet can be processed normally by a linux IP stack, for example. For example, a Linux IP stack can validate the destination IP address of the packet. In the case where the packet is not valid, the linux IP stack will simply drop it.

[0053] Finally, the NPU 82 also takes care of RTCP handling through the RTCP handler 92. The reception of a RTCP receiver report is done directly at the NPU level via the RTCP handler 92. The last values of this report will be kept for further processing. The RTCP receiver report collects/gathers cumulative packet drop or loss information, which constitutes an indication of the quality of a link. Therefore, one easy way to detect problems in a media stream of data packets is to use RTCP receiver reports. The values given by this report can form statistics which are then analyzed and compared to a threshold of packet drop for preventive purposes. For example, if the analyzed value is below a certain QoS threshold, then adjustment of the QoS drop function is necessary in order to provide an acceptable quality of the link. All abnormal data packets should be flagged to a control element 122 in the host 84 so that a network dynamic down sampling adjustment can be activated, for example.

[0054] The statistics can be also used for overall dynamic quality feedback. The host 84 can post-process all the statistics. The host 84 has access to all the statistics and can generate reports about an overall end user experience quality, for example.

[0055] It should be noted that the RTCP handler 92 can be also implemented inside the proxy 78 and gather statistics about the quality of the media streams.

[0056] Turning back to Figure 3, the host 84 of the forwarding element 72 will now be described. The host 84 comprises a driver 120 for filling out the lookup tables used by the NPU 82 during the media stream duplication process 100 of Figure 4. The host 84 further comprises a control protocol unit 122.

[0057] The host 84 is responsible for keeping the lookup tables in a coherent state and for filling them out. For example, adding or removing RTP (Real-Time Protocol) streams may affect each lookup table, stored in a memory (not shown) of the SA 64.

[0058] The control protocol unit 122 of the host 84 has a control protocol which uses a TIPC (Transparent Inter Process Communication) mechanism. The control protocol of the control unit 122 uses binary formats with fast encoding/decoding mechanisms to execute basic user commands, such as adding, removing or fetching a user's media stream. The TIPC mechanism also allows the host 84 to send requests and to receive responses. Generally, a network administrator or any person authorized to access the host 84 can perform those tasks.

[0059] Turning now to Figure 5, the encapsulation and communication process 160 between the processor 70 and the forwarding element 72 will be described. More specifically, the interactions between the NPU 82 and the processor 70 are illustrated in Figure 5.

[0060] As a non-limitative example, the case where the local packets, which were not identified by the duplicator 88, are sent from the NPU 82 to the processor 70 for further processing is considered. However, it should be noted that an additional function, such as a validation function, can be implemented in the NPU 82 so as to decide if the local packets should be sent to the processor 70 or not. [0061] The receiver/sender 86 receives the non-identified packets in operation 162.

[0062] The packets are then sent, in operation 164, to the local packet handler 96 of the NPU 82 for performing a local matching in operation 166, meaning that a local address or valid MAC address is sought. The local packet handler 96 also checks for a rate limit or capacity of processing of the NPU 82 in operation 168. If the NPU 82 has not a sufficient capacity for handling the received packets, a flag is sent out for requesting more capacity or even another processor. The local packet handler 96 further encapsulates the packets with a MVIF header (not shown in Figure 5).

[0063] Then, the packets are sent to the processor 70. More specifically, the packets are supplied to the MVIF driver 80 via the MVIF protocol in operation 170.

[0064] In operation 172, the MVIF driver 80 first decapsulates the packets by taking off the MAC address and proprietary header that were added to the original packets.

[0065] Then, the decapsulated packets are sent to an application

188 in operation 174 for further processing.

[0066] The application 188 produces a response in operation 176.

For example, the application 188 can use different keywords or methods to identify the local packets and find their destination address; for instance, the application can use a PING (Packet INternet Groper) function by sending an ICMP (Internet Control Message Protocol) request to a destination IP address. Then the application waits for an ICMP response. If the destination IP address is reachable, then the PING application returns a positive answer and additional information such as the number of packets received by the destination IP address and the time needed to reach the destination IP address.

[0067] After the application 188 is over, this application sends the packets back to the MVIF driver 80 in operation 178.

[0068] The MVIF driver 80 then encapsulates the packets in operation 180 by adding a MAC address and proprietary header to the packets according to the MVIF protocol.

[0069] Finally, the packets are sent from the MVIF driver 80 back to the receiver/sender 86 of the NPU 82 via the MVIF protocol.

[0070] Since the packets have been identified and validated, they can be sent out from the NPU 82 to the external network 76 in destination of the corresponding requesting end user (operation 184).

[0071] Therefore, the media stream duplicating and delivering system and method according to the non-restrictive illustrative embodiment of the present invention form an interface between the at least one media streamer 62 on one side and the end users on the other side, whereby access to the requested media streams by the end users is available only through the media stream duplicating and delivering system.

[0072] Although the non-restrictive illustrative embodiment of the present invention has been described in the context of at least one media streamer such as 62 for supplying media streams to the SA 64, it should be kept in mind that the media streams can be supplied to the SA 64 by any type of sources of media streams internal or external to the SA 64. [0073] Many modifications and other embodiments of the present invention will come to mind to those of ordinary skill in the art. Therefore, it is to be understood that the invention is not to be limited to the specific illustrative embodiment disclosed in the present patent application and that modifications and other embodiments are intended to be included within the scope of the present invention. Although specific terms are employed hereinabove, they are only used to clarify the implementation and not for purposes of limiting the scope of the present invention in any manner.

Claims

What is claimed is:

1. A system for duplicating and delivering media streams from at least one source of media streams to end users using a Unicast protocol, the system comprising: a processor of requests for media streams from the end users; a receiver of the requested media streams from the at least one media stream source; a duplicator responsive to the requests for media streams from the end users and structured to duplicate the requested media streams received by the receiver from the at least one media stream source; and a sender of the requested and duplicated media streams to the corresponding requesting end users through a communication network and using the Unicast protocol; wherein the media stream duplicating and delivering system forms an interface between the at least one media stream source on one side and the end users on the other side, whereby access to the requested media streams by the end users is available only through the media stream duplicating and delivering system.

2. A system as defined in claim 1 , wherein the at least one media stream source comprises at least one internal source of media streams.

3. A system as defined in claim 1 , wherein the at least one media stream source comprises at least one external media streamer.

4. A system as defined in claim 1 , wherein the processor comprises a RTSP proxy for handling the requests for media streams from the end users.

5. A system as defined in claim 3, wherein the processor is so configured as to identify the at least one media streamer capable of supplying the requested media streams.

6. A system as defined in claim 1 , wherein the processor is so configured as to authenticate the end users requesting media streams.

7. A system as defined in claim 1 , wherein the processor is so configured as to authenticate the end users requesting media streams by validating passwords.

8. A system as defined in claim 1 , wherein the processor is so configured as to authenticate the end users requesting media streams by validating IP addresses of the requesting end users.

9. A system as defined in claim 1 , wherein the media stream duplicating and delivering system comprises an embedded piece of software implemented in a network processor unit.

10. A system as defined in claim 1 , wherein the processor comprises a statistic reporter for collecting and producing statistics on the quality of the communication network.

11. A system as defined in claim 1 , further comprising a forwarding element including the said receiver, duplicator and sender, and a private network for interconnecting the processor with the forwarding element.

12. A system as defined in claim 11 , wherein the processor comprises a driver forming an interface for exchanging data between the processor and the forwarding element through the private network, the said driver being so configured as to encapsulate/decapsulate data packets by adding/removing a media access control address and proprietary header.

13. A system as defined in claim 11 , wherein the forwarding element is connected to an ultra fast network for delivering the requested and duplicated media streams to the end users through the sender.

14. A system as defined in claim 1, further comprising a host for hosting look-up tables used in the duplication of the requested media.

15. A system as defined in claim 1 , further comprising a stream modifier for modifying the requested and duplicated media streams according to session information of the corresponding requesting end users.

16. A system as defined in claim 1 , wherein the duplicator is so configured as to identify the requested media streams received from the at least one media stream source.

17. A system as defined in claim 16, further comprising a local packet handler for processing the requested media streams non-identified by the duplicator.

18. A method for duplicating and delivering media streams from at least one source of media streams to end users using a Unicast protocol, the method comprising: receiving and processing requests for media streams from the end users; receiving the requested media streams from the at least one media stream source; duplicating, in response to the requests from the end users, the requested media streams; and delivering the requested and duplicated media streams to the corresponding requesting end users through a communication network and using the Unicast protocol; wherein the media stream duplicating and delivering method forms an interface between the at least one media stream source on one side and the end users on the other side, whereby access to the requested media streams by the end users is available only through the media stream duplicating and delivering method.

19. A method as defined in claim 18, wherein the at least one media stream source comprises at least one internal source of media streams.

20. A method as defined in claim 18, wherein the at least one media stream source comprises at least one external media streamer.

21. A method as defined in claim 20, wherein receiving and processing requests comprises identifying the at least one media streamer capable of supplying the requested media streams.

22. A method as defined in claim 18, wherein receiving and processing requests comprises authenticating the end users requesting media streams.

23. A method as defined in claim 18, wherein receiving and processing requests comprises authenticating the end users requesting media streams by validating passwords.

24. A method as defined in claim 18, wherein receiving and processing requests comprises authenticating the end users requesting media streams by validating IP addresses of the requesting end users.

25. A method as defined in claim 18, wherein duplicating the requested media streams comprises using look-up tables in the duplication of the requested media streams.

26. A method as defined in claim 18, further comprising modifying the requested and duplicated media streams according to session information of the corresponding requesting end users.

27. A method as defined in claim 18, wherein duplicating the requested media stream comprises identifying the requested media streams received from the at least one media stream source.