WO2013098812A1

WO2013098812A1 - Transport over udp system and method

Info

Publication number: WO2013098812A1
Application number: PCT/IL2012/000404
Authority: WO
Inventors: Adi ROZENBERG
Original assignee: Video Flow Ltd.
Priority date: 2012-01-01
Filing date: 2012-12-31
Publication date: 2013-07-04
Also published as: WO2013098812A8; IL217305A0

Abstract

In data transport over a network using User Datagram Protocol (UDP) for transferring a stream of packets from a transmitter to a receiver, a system for correcting errors in reception, comprising: one or more probing devices (probes) for probing the media/transport stream and for sending information relating to the stream along; one or more detection devices (detectors) for receiving the information and the transmitted packets and for taking action to correct for the errors in reception, wherein the errors in reception include re-ordering of packets and/or lost packets, wherein the information being sent along includes a list of transport packets in the UDP packet, wherein the information is used to detect lost or re-ordered packets, and wherein the detector further includes means for network jitter reduction or elimination.

Description

Transport over UDP System and Method

Embodiments of the present invention relate to systems for media stream transmission using an improved User Datagram Protocol (UDP) for re-ordering of packets and efficient recovery of lost packets .

BACKGROUND

Media video delivery systems today use the User Datagram Protocol (UDP) to transfer media over an IP network. UDP is simple, cheap, and has low overhead. A possible drawback of UDP is an unreliable delivery protocol: Due to its simplicity, it lacks any information on packet sequence and thus it is prone to packet loss and reordering, which are common to the IP network.

Most IP systems must provide means to safely deliver the media from one end of the network to the other based on the UDP protocol. Since no sequence information is associated with the UDP packet, the end device has no way to know if a packet was lost or reordered on the way - which would require the application of suitable means to correct the problem. Network devices have the option to use a Real Time Protocol (RTP), which is an extension of the UDP protocol, but this means that all network devices will need to comply with the new protocol. Figure 1 shows a Prior Art transmitter which sends an original UDP media stream and, at another end of the channel, a receiver which stands by for the stream to arrive. The receiver will try to play the stream with the information received. A transmitter 11 sends serially transmitted packets 123, including data (Dl , D2, D3...), over a network 12 to a receiver 13.

A data in 111 stream is formed into data to be transmitted 112. A UDP transmitter 113 processes the data to generate a UDP stream.

After passage through the network 12, serially received packets 124 arrive at the receiver 13, with an exemplary lost data packet (D2). In the receiver 13, the packets are received in a stack 135, thence are transferred to a UDP receiver that stores the media packets in data buffer 136. The receiver then reads out the packets, in a sequential order calculated from the reception order, to the next stage. The data stream 137 is missing the data packet D2 138.

Thus, a standard media delivery system is made of the transmitter 11 and receiver 13 devices; the media stream is transmitted using a UDP protocol which is unreliable and does not provide any information of lost packet or means to detect or correct these loss events.

The prior art system does not include a built-in support for packet retransmission, as is done with Data delivery protocols such as TCP. Embodiments of the present invention serve to improve the efficiency of transport stream over UDP with regard to packet loss and re-order detection.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, transport over UDP is improved using a system comprising two devices: The first device will probe the

media/transport stream and use its transport stream packet information to form a list of transport packets in the UDP packet.

Several of these lists might be sent along with the UDP stream to a second detection device, which in turn will form the same data base from the UDP stream and by comparing the information with the list will know if packets where lost or re-ordered on the way. The second device can repair or correct problems relating to re-ordering of packets, or may signal other devices for a corrective action to solve for lost packets. Two embodiments of the present invention are described by way of example: a

Detect Only (DO) system, implementing a packet loss detection system that alerts of a lost packet; and a Detect and Recover (DR) system, implementing a system which not only detects, but also actively recovers missing packets, by resending the missing information.

The present patent application is the third of four applications being presently filed by the present applicant and inventor; embodiments of the inventions disclosed in these applications can be used together in various combinations: 1. Adaptive FEC System and Method 2. Packets Recovery System and Method

3. Transport over UDP System and Method

4. Media Stream Rate Reconstruction System and Method Further purposes and benefits of the current invention will become apparent upon reading the present disclosure and the related drawings.

LIST OF DRAWINGS

Figure 1 (Prior art) details a transmitter which sends the original media stream and calculates the Row, Column FEC packets.

Figure 2 details a System and method for detecting an UDP Packet loss over a network, and for packets recovery and re-ordering of the packets.

Figure 3 illustrates an UDP System, with its high level blocks: a Probe and its high level component parts, and a Detection device.

Figure 4 illustrates an UDP packet encapsulation of 7 Transport packets and an UDP header. Figure 5 illustrates a packet representation based on TS packet headers and transport packets.

Figure 6 illustrates a Combined list of UDP packets (K, K+l,...) based on TS packet headers of each UDP packet.

Figure 7 illustrates an example of a Control message structure. Figure 8 illustrates a Probe processing method and data flow. Figure 9 illustrates a Detection device internal building blocks and data flow. Figure 10 illustrates Probe device internal building blocks and data flow.

Figure 11 illustrates a Detection processing method and data flow.

Figure 12 illustrates a Probe processing method and data flow.

Figure 13 illustrates a Detection processing method and data flow.

Figure 14 illustrates a system architecture including both intrusive and non-intrusive deployment topology.

Figure 15 illustrates a system architecture using both a public and a private network.

DETAILED DESCRIPTION OF THE INVENTION

Glossary of terms

Throughout the present disclosure, the following terms may be used:

Moving Picture Experts Group (MPEG) is a working group of experts that was formed by ISO and IEC to set standards for audio and video compression and transmission.

MPEG transport stream (TS) is a standard format for transmission and storage of audio, video, and Program and System Information Protocol (PSIP) data, and is used in broadcast systems such as DVB and ATSC. Transport Stream is specified in MPEG-2 Part 1, Systems (formally known as ISO/IEC standard 13818-1 or ITU-T Rec. H.222.0) .

TS Packet is the basic unit of data in a transport stream. It consists of a sync byte, whose value is 0x47, followed by three one-bit flags and a 13-bit Packet Identifier (PID) . This is followed by a 4-bit continuity counter. Additional optional transport fields, as signaled in the optional adaptation field, may follow. The rest of the packet consists of payload. Packets are 188 bytes in length.

Program Identifier (PID) Each table or elementary stream in a transport stream is identified by a 13-bit packet ID (PID) . A demultiplexer extracts elementary streams from the transport stream in part by looking for packets identified by the same PID.

Program Clock Reference (PCR) is transmitted in the adaptation field of an MPEG-2 transport stream packet. The value of the PCR, when properly used, is employed to generate a system__timing_clock in the decoder. The PCR is used by the decoder to present synchronized content, such as audio tracks matching the

associated video, at least once each 100 ms.

Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features. RTP is used in conjunction with the RTP Control

Protocol (RTCP). While RTP carries the media streams {e.g., audio and video) , RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. RTP is originated and received on even port numbers and the associated RTCP communication uses the next higher odd port number. RTP was developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) and first published in 1996 as RFC 1889, superseded by RFC 3550 in 2003.

User Datagram Protocol (UDP) is one of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without requiring prior

communications to set up special transmission channels or data paths. UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the

application, avoiding the overhead of such processing at the network interface level.

Set-top box (STB) is an information appliance device that generally contains an interface to a network and connects to a television set and an external source of signal, turning the signal into content which is then displayed on the television screen or other display device. In IP networks, the set-top box is a small computer providing two-way communications on an IP network and decoding the video streaming media. IP set-top boxes have a built in home network interface which can be Ethernet or one of the existing wire home networking technologies.

Forward Error Correction (FEC) - Technique to recover packet information partial or full, based on calculation made on the information. Such techniques maybe by means of XOR between packets or any other mathematical computation.

Pro-MPEG - the Professional-MPEG Forum - is an association of broadcasters, program makers, equipment manufacturers, and component suppliers with interests in realizing the interoperability of professional television equipment, according to the implementation requirements of broadcasters and other end- users . SMPTE 2022 - The Pro-MPEG Forum began initial work on a FBC scheme for video transport. That work, added to by the Video Services Forum, was introduced to SMPTE. This proposed standard is known as SMPTE 2022, and it describes both a FEC scheme and a way to transport constant bit rate video over IP networks.

***

Embodiments of the current invention are described by way of example and with reference to the accompanying drawings.

Figure 2 details a system and method for detecting an UDP Packet loss over a network 12, and for packets recovery and re-ordering of the packets. The Figure illustrates a system which includes an UDP transmitter 11 with Receivers 13, 13B, and a Probe device 14 (in a preferred embodiment, the Probe should be located as close as possible to the transmitter 11) and Detection devices 15, 15B (which should be located as close as possible to Receivers 13, 13B).

Probe device 14 buffers the UDP stream for a predefined period of time. The buffered information will be used for two purposes: The first is to create a sequential pattern list of the stored UDP packets; this list will be sent to the next device. The second purpose is to re-send a lost packet back to the stream and reconstruct the original stream, thus providing protection from packets loss. Media stream encapsulated in a MPEG transport may be packetized in 188 byte packets, each packet may include a 8 byte header. The Packet header includes a special sync byte, various flag on the payload, a Packet identifier ( PID ) and Packet continuity counter ( CC ). Every 1 to 7 transport packets are encapsulated into one UDP packet. The present invention includes a probe device and a detection device.

The Probe device includes an IP interface, Memory buffer, Transport processing block and a processor. Any packet received by the IP interface is forwarded to the memory buffer in a sequential order. The Transport stream processor reads each packet and extracts the PID and CC information of each transport packet

encapsulated in the UDP packet. The transport stream processor then compiles a list of all PID + CC inside one UDP packet. Those are associated with a unique sequence number. Several of UDP packets are combined into a new information packet which holds the IP address of the stream and the list of sequence numbers, each followed by the PID and CC of that packet. The new packet is sent by either unicast or multicast to the network, preferably via a different UDP port of the original IP address.

Figure 3 illustrates an UDP System, with its high level blocks: Probe 14 and its high level component parts, and Detection device 15 and its high level component parts. Embodiments of the present inventions consists of a probe device 14 and a detection device 15. Probe device 14 comprises IP interface 216, Memory buffer 215, transport processing block and a processor 213. A packet received by the IP interface is forwarded to the memory buffer in a sequential order. The Transport stream processor reads each packet and extracts the PID and CC information of each transport packet encapsulated in the UDP packet. Input UDP video stream 12A is transferred to network 12 and also to unit 14, Processor 213 receives information from packet buffer 215, also relating to packet filter 216, playout, network stack and network interface. Real time information is kept in TS packet list 218. Data flow, processing and network interface are coordinated using control 217.

In one embodiment of the invention, media stream encapsulated in MPEG transport is packetized in 188 byte packets, each packet with 8 byte header. The Packet header is made out of a special sync byte, various flag on the pay load, Packet identifier ( PID ) and Packet continuity counter ( CC ). Every 1 to 7 transport packets are encapsulated into one UDP packet. Unit 14 further processes Control messages 12B and Corrective packets 12C. The detection device 15 follows the same probing as the probe device 14. The detection device probes the mcoming stream for missing packets and reports the information through a RTCP message. The RTP sequence number is used to generate a list to verify the order of the packets. Whenever disorder is detected, Processor 233 can change the position of the internal packet back to its original state. Whenever packet information is unaccounted for, the detection device can issue a request for Packet loss intervention to occur. Output 1 8 includes the corrected RTP video stream.

Figure 4 illustrates an UDP packet encapsulation of 7 Transport packets 125B and an UDP header 125 A. In the embodiment as illustrated in the Figure, there is a UDP packet and Transport stream payload, up to 7 TS packet of the length of 188Bytes + UDP header. Each TS header may have a specific 4 byte length.

Figure 5 illustrates a packet representation based on TS packet headers 125 A and transport packets 125B. The figure depicts the extraction of TS headers 125 A to form a single pattern 125C that is a representation of the respective UDP packet.

Figure 6 illustrates a Combined list of UDP packets (K, K+l,...) basedon TS packet headers of each UDP packet.

In an exemplary embodiment, based on packets K, K+l, K+2, K+3 (125E), the transport stream processor compiles a list 125F of all PID + CC inside one UDP packet. The packets are associated with a unique sequence number. Several of UDP packets are combined into a new information packet which holds the IP address of the stream and the list of sequence numbers, each followed by the PID and CC of the packet. The new packet is sent by either unicast or multicast to the network, preferably as a different UDP port of the original IP address.

Whenever disorder (packets out of order and/or missing packets) is detected, the processor can change the position of the internal packet back to its original state.

Figure 7 illustrates an example of a Control message structure. This is the control message structure that is made of several (in this example up to y+1 UDP packets representation), of UDP packet representation in a sequential order. The Message may hold a message header, sequence number and a payload length (for this example: y+1 packets).

The detection device 15 follows the same probing as the probe device 14. The detection device forms a list of the PID + CC information for comparison with the sequence packet. The detection device receives the sequence packet transmitted by the probe.

Whenever a sequence packet is received, the detection device compares the PID -+- CC pattern list in the sequence packet with the internal list to verify the order of the packets. Whenever disorder is detected the Processor can change the position of the internal packet back to its original state. Whenever packet information is unaccounted the detection device can issue a request for Packet loss intervention to occur.

Detection Only (DO) system

The following description of data flow relates to a Detection Only (DO) embodiment of the present invention that is applicable for only detection of a lost event. The probe device in the following Data flow is only capable of signaling the Detection device about the stream packets order.

Figure 8 illustrates a Probe processing method and data flow. For details of Data Flow, see also Figures 2 and 4. The method includes:

1. UDP stream packets are received 31

2. UDP packets are stored in a dedicated stream buffer/storage, step 32

a. Stored packets content is analyzed, step 33

b. Calculate rate

c. Calculate rate step adjustment

d. Adjust rate counter

3. Extract Packet TS header (4 byte per Transport stream packet) , step 3D a. Create a TS header list to represent the packet step 3E

b. Wait for n packets, gather the packet representation, steps 3F, 3G

c. Add the n packet to a data base/list in a control packet, steps 3H

d. Send List out , step 31

4. Clear packet , step 36 Figures 8 and 11 describe the a Detection Only (DO) embodiment of the current invention. The following description of data flow relates to embodiments of the present invention that deal with a second part of the invention, Detect packet loss and recover from the packet loss. The probe device in the following Data flow signals the Detection device about the stream packets order.

Figure 11 illustrates a Detection processing method and data flow.

The method includes:

1. Receive packet stream, step 61

2. Store the packet, step 62

3. Analyze the packet, storage, step 63 4. Calculate the TS rate, step 64

5. Calculate a rate adjustment parameter, step 65

6. Adjust a packet rate counter, ste 66

7. Read a packet from storage, step 67

8. Packet to send?, step 68

9. If yes- send packet out, step 69

10. If no- clear packet, step 6G

11. Extract packet header, step 6A

12. Create packet TS header list, step 6B

13. Wait for N packets, steps 6C, 6D

14. Add n TS packet list to data base, step 6E

15. Analyze packet, step 6F

16. Receive control packet, step 61

17. Search the database, step 6J

18. Match a pattern, step 6K

19. If pattern is located correctly, then End, steps 6L, 6M

20. If pattern not located correctly- Modify packet order list, step 6N

Detect and Recover (OR) system

Figure 12 illustrates a Probe processing method and data flow.

1. UDP stream packets are received from two different ports, step 31

2. UDP packets are stored in a dedicated stream buffer/storage, step 32

3. Extract packet header, step 6 A

4. Create packet TS header list, step 6B 5. Wait for N packets, step s 6C, 6D

6. Add n TS packet list to data base, step 6E

7. Send control message, step 6P

8. Analyze packet, step, step 33

9. Wait for packet request, step 34

10. If no new packet request: clear packet from buffer, step 35, 36

11. if new packet request: compare to database, step 6Q

12. Read packet from storage, step 67

13. Send packet out, step 681

Figure 13 illustrates a Detection processing method and data flow. Whenever packet information is unaccounted for (e.g. a packet is considered lost), the detection device issues a request for Packet reconstruction from the Probe device by means of a specific message, that includes the information about the lost packet and its position in the stream. The probe device will use the position information to recall the packet from its data buffer and re-sends it through a control UDP port back to the Detection device. The Packet is sent with a header describing the position of the data in the stream. The Detection device uses the information and the data to re-insert the missing packet back to the buffer and then be played out.

The method includes:

1. Receive packet stream, step 61

2. Receive fixed packet, step 6R

3. Store the packet, step 62

4. Analyze packet storage, step 63 5. Calculate TS rate, step 64

6. Calculate rate adjustment, step 65

7. Adjust packet rate counter, step 66

8. Read packet from storage, step e 67

9. Analyze packet, step 6F

10. To send packet? , step 68

a. If No: Clear packet 66

b. If Yes: Send packet out, step 69

11. Extract packet header, step 6A

12. Create packet TS header list, step 6B

13. Wait for n packets, step 6C

14. N packets? , step 6D

15. Add n TS packet list to database, step 6E

16. Receive control packet, step 61

17. Search the database, step 6 J

18. Pattern match? , step 66

a. If Yes: End

b. If No: Create control message, step 68K

Request message, step 69K.

Building blocks common to both the DO and PR systems

Embodiments of present invention, as detailed above, can also include additional optional features as detailed below. Figure 9 illustrates a detection device internal building blocks and data flow, including:

1. Media packets (Video/media or RTCP ) arrive at the Ethernet MAC port. Each packet is stored in a memory buffer, step 51

2. For each assigned packet, the software assigns a pointer that points to the memory buffer in 1, step 52

3. The Software sends memory pointer to the INPUT processing (see 4), step 53

4. The packet memory pointer is assigned with a sequential number and are stored in a Stream pointer Fifo pool, each entry is indexed according to the sequential number, step 54

5. The Processor scans each arrived packet and extracts the TS header from each TS Packet stored in the memory pool, step 58

6. The information is gathered to form a pattern which is assigned with the sequential number of the packet (location in the Stream pointer Fifo pool ). Several such patterns are collected and send by a RTCP message to form a Control list, step 56

7. The Control/RTCP message is written out, step 55

8. Packet stored in the Stream pointer Fifo pool may be read according to the pointer, to extract and calculate video information ( such as rate, video & Audio codec information, and transport stream performance information according to ETR 290 standard), step 55.

Figure 10 illustrates a Probe device internal building blocks and data flow:

1. Media packets (Video/media or RTCP) arrive at the Ethernet MAC port, Each packet is stored in a memory buffer, step 51 2. For each assigned packet the software assign a pointer that point to the memory buffer in 1„ step 52

3. The Software sends memory pointer to the INPUT processing (see 4), step 53

4. The packet memory pointer is assigned with a sequential number and are stored in a Stream pointer Fifo pool, each entry is indexed according to a sequential number, step 54

5. The Processor scans each arrived packet and extracts the TS header from each TS Packet stored in the memory pool, step 5

6. The TS information of the new packet is gathered to form a pattern, the pattern is then compared against the Control list to detect miss location and/or missing packet , step 56

7. The TS information is gathered to form a pattern which is assigned with the sequential number of the packet ( location in the Stream pointer Fifo pool ). Several such patterns are collected to form a Control list, step 59

8. The Stored stream may be played out according to a calculated rate, any packet read from play out is then freed from the Memory pool, step 55

9. Packet stored in the Stream pointer FIFO ("first-in-first-out", as known in the art) pool may be read according to the pointer, to extract and calculate video information (as rate, video & Audio codec information, and transport stream performance information according to ETR 290 standard) 55

Figure 14 illustrates a system architecture including both intrusive and non-intrusive deployment topology. The figure shows a system description and the various options for deploying Probe and Detection devices. For example, Probe #1 14 is connected in a non-intrusive mode (in parallel with transmitter #1 11), whereas Probe #2 14B is connected in an intrusive mode (in series with transmitter #2 11 B). The Detection device #1 15 is connected in an mtrusive mode (in series with receiver #1 13), whereas the Detection devices #2 15B and #3 15C are connected in a non- intrusive mode (in parallel with receivers #2 13B and #3 13C respectively).

The Intrusive devices (Probe #2, Detection #1 ) have at least one input and one output interface. Data flows from input to output with added processing in the device itself. A benefit of using an intrusive Probe device (Probe #2) is a simpler data flow through each element; data flow from Transmitter #2 through Probe #2 allows for easy connection and a clear traffic flow, so that the Probe device will be assured to get all the packets from the transmitter into his packet buffer.

A benefit of using a Detection device in an intrusive mode is a larger buffer, which can shield/buffer the Receiver device from network artifacts such as jitter, packet reorder and packet loss. Another benefit of the intrusive mode is that it allows the Detection device (see Detection #1 15) to recover packets without the knowledge of the receiver (Receiver #1 13) and perform a rate adjust.

The non-intrusive device (Detection #2 15B and #3 15C) are devices which can tap the stream, and may be used to detect and report on loss packet events, but cannot actively recover events of a missing packet. A benefit of using a non-intrusive device is an ability to put it anywhere in the network in a seamless fashion, so that it does not disturb the original network traffic. The devices can be simply added to the network and add their capabilities, to be used to monitor the network for packet loss.

A system including the present invention and network jitter reduction

This section describes a system including embodiments of the present invention together with a novel system and method for network jitter removal, to recover lost UDP packets and to reduce network jitter, all in one integrated system. This optional addition to embodiments of the current invention is a system solution to protect a UDP streaming network from artifacts of packet loss and network jitter; the system consists of a probe device ( Probe #1, #2 ) connected in an mtrusive or non- intrusive mode and a Detection device ( Detection #1 ) connected in a intrusive mode. Refer to Figure 14.

Probe #1 14 is added in parallel to the Transmitter #1 11 ; it is up to the network operator to duplicate/direct the traffic from Transmitter #1 11 to allow Probe #1 14 to capture the packets in its memory buffer. Embodiments of the present invention comprise a system solution to protect a media network from artifacts of packet loss and network jitter. The system consists of a probe device (Probe #1,#2 ) connected in an intrusive or non-intrusive mode, and a Detection device ( Detection #1 ), connected in an intrusive mode, see Figure 14. A unique feature of this solution is in that the detection device shields the network artifices from the Receiver device (receiver #1 13) to allow it to receive a media stream free of lost packets and with a rmnimal jitter - which are crucial to media reception solutions.

A system consisting of the present invention and network jitter reduction

Embodiments of the present invention also include a system for UDP streaming and Packet recovery by using VPN links for bidirectional messaging and data recovery. Standard streaming solutions have a problem in transferring packets through a public network (such as, but not limited to the internet) because of the of the "high probability" and the amount of packet loss, jitter in the public network. This caused streamers to use Data-based protocols like TCP to overcome this limitation.

Embodiments of the current invention enable the use of a standard streaming and add a Packet loss recovery means, use of a parallel Private/VPN (Virtual Private Network) for messaging and Packet recovery, and the use of one of the UDP protection method to recover from packet loss Figure 15 illustrates the Streaming solution of this invention. The Internet has long been considered as a cheap and high bandwidth resource for streaming, while the use of Private or VPN are more expensive. This invention separates the path of the data stream from the control/correction path. The Private network or VPN will be used by Probe#l and the Detection device#l to send control/Correction packets - since they need lower bandwidth (compared to the stream), this will result in a lower cost compared to a full use of the VPN for streaming. The system consists of a probe device ( Probe #I,#2 ) connected in an intrusive or non intrusive mode and a

Detection device ( Detection #1 ) connected in a intrusive mode. As shown in Figure 15, a system architecture uses both a public and a private network. The Stream is traveling through the public network 12 to the Detection device 15, while the corrective action is traveling through a private VPN network 12D (which preferably should be error free or may have a lower error rate). A probe device (Probe #1 14) connects to the stream for media packet buffering and to a VPN 12D connection for RTCP and Recovery packets. A Detection device (Detection #1 15) may connect in an intrusive mode to both

the data stream and a VPN connection. The detection device will buffer the received packets in its packet memory buffer and use the VPN connection to request and receive correction packets.

Detection device 15 will shield/buffer the network jitter from the receiver device (Receiver #1 13). Probe 14 and Detection 15 devices may then use an additional method to recover lost packets in the stream between them. A major benefit is the ability to convert from an unrecoverable streaming protocol to a recoverable one and back to a system that does not support RTP protocol.

It will be recognized that the foregoing is but one example of an apparatus and method within the scope of the present invention and that various modifications will occur to those skilled in the art upon reading the disclosure set forth hereinbefore.

Claims

What is claimed is: 1. In a transport over User Datagram Protocol (UDP) network for transferring a stream of packets from a transmitter to a receiver,

a system for correcting errors in reception, comprising:

a. one or more probing devices (probes) for probing the media/transport stream and for sending information relating to the stream along;

b. one or more detection devices (detectors) for receiving the information and the transmitted packets and for taking action to correct for the errors in reception, wherein the errors in reception include re-ordering of packets and/or lost packets, wherein the information being sent along includes a list of transport packets in the UDP packet,

wherein the information is used to detect lost or re-ordered packets,

and wherein the detector further includes means for network jitter reduction or elimination.

2. The system according to claim 1, wherein the detector further includes means for network j itter reduction or elimination.

3. The system for correcting errors according to claim 1 or 2,

wherein probing devices are located each as close as possible to the transmitter. 4. The system for correcting errors according to claim 1 or 2,

wherein detection devices are located each as close as possible to the receiver.

5. The system for correcting errors according to claim 1, 2 or 3,

wherein the information being sent is received in the detection device and

is used to detect lost or re-ordered packets.

6. The system for correcting errors according to claim 5,

wherein the information being sent along is used in the detection device

for repairing or correcting problems relating to the errors, wherein the errors comprise loss of packets or re-ordering of packets.

7. The system for correcting errors according to claim 5,

wherein the information being sent along is used in the detection device

to signal other devices to initiate a corrective action to solve for lost packets. 8. The system for correcting errors according to claim 1, 2 or 3, wherein the probe device includes means for buffering the UDP stream for a predefined period of time.

9. The system for correcting errors according to claim 8, further including means for using the buffered information to create a sequential pattern list of the stored UDP packets, and/or to re-send a lost packet back to the

stream and reconstruct the original stream, thus providing protection from packets loss. 10. The system for correcting errors according to claim 1 _s or 3, wherein a media stream encapsulated in a Moving Picture Experts Group (MPEG) transport is packetized in 188 byte packets, each packet including a 8 byte header.

11. The system for correcting errors according to claim 10, wherein the

packet header includes a special sync byte, various flag on the payload, a

Packet Identifier ( PID ) and a Packet Continuity Counter (CC).

12. The system for correcting errors according to claim 10 or 11, wherein

every 1 to 7 transport packets are encapsulated into one UDP packet.

13. In a system for correcting errors in a transport over UDP including one or more probe devices and one or more detection devices,

a probe processing method, comprising:

a. receiving UDP stream packets;

b. storing the UDP packets in a dedicated stream buffer/storage, comprising:

1) analyzing the stored packets content

2) calculating a rate

3) calculating a rate step adjustment

4) adjusting a rate counter;

C . extracting a MPEG transport stream (TS) packet header from each of the UDP packets, wherein the header includes 4 bytes per transport stream packet, comprising:

1) creating a TS header list to represent one of the stored packets

2) waiting for n packets, gathering the packets representation

3) adding the n packets to a data base/list in a control packet

4) sending the data base/list out; d. clearing the stored packets.

14. In a system for correcting errors in a transport over UDP including one or more probe devices and one or more detection devices,

a detection processing method, comprising:

a. receiving media packets ( Video/media or RTCP, wherein

RTP Control Protocol (RTCP) and Real Time Protocol (RTP) )

arriving at the Ethernet Media Access Control (MAC) port, and storing each packet in a memory buffer;

b. assigning, for each of the received packets, a memory pointer that points to the memory buffer;

c. sending the memory pointers to an INPUT processing;

d. assigning a sequential number to each memory pointer and storing the sequential numbers in a stream pointer First In First Out (FIFO) pool, wherein indexing each packet entry according to the sequential number;

e. scanning each of the received packets and extracting a MPEG transport stream (TS) header from each TS packet stored in the pool;

f. gathering an information to form a pattern which is assigned with the

sequential number of the packet in a location in the stream pointer FIFO pool , collecting several patterns and sending the patterns by a RTCP message to form a control list;

2. writing out the control list or RTCP message;

h. storing each packet in the stream pointer FIFO pool and reading it according to the pointer, to extract and calculate a video information ( such as rate, video & audio codec information), and sending the information according to an ETR 290 standard, wherein:

ETSI Technical Report (ETR), and

European Telecommunications Standards Institute (ETSI).