Difference between revisions of "RTP"

m (Reverted edits by Yhorebapemy (Talk) to last version by Brain)
 
(25 intermediate revisions by 4 users not shown)
Line 1: Line 1:
RTP
=== RTP Protocol===


[[wikipedia:Real-time Transport Protocol|RTP (Real-time Transport Protocol)]], as a standard application protocol of the [[wikipedia:Internet Protocol Suite|Internet Protocol Suite]], has been designed for transport of multimedia streams in IP networks.


RTP (Real-time Transport Protocol) has been designed for the transport of multimedia streams over IP networks. It works on top of UDP.
Implementation is widely based on the [[wikipedia:User_Datagram_Protocol|User Datagram Protocol (UDP)]]. The [[wikipedia:Transmission Control Protocol|Transmission Control Protocol (TCP)]] is not often used by RTP for its high latency caused by connection establishment and error correction. The Barix implementation employs UDP as a transmission protocol.
It was developed by the Audio-Video Transport Working Group of the IETF[http://en.wikipedia.org/wiki/IETF] and first published in 1996 as RFC 1889, and superseded by RFC 3550 in 2003.


IP networks are asynchronous and may lose or reorder packets.
In multimedia applications low latency is essential, whereas an occasional  packet loss can be tolerated. A packet typically carries a fraction of a second worth of audio, which makes the lost packet almost inaudible. RTP adds a sequence number and a time stamp to each packet to allow detection and recovery from network errors.


Some fields in RTP are defined to address these problems:
===Payload Type===


- PT (Payload Type) tags the content of the packet. Some standardized values exist, but for other codecs, the type must be described in a service description protocol, SDP (Session DescriptionProtocol);
Each RTP packet carries 7-bit information describing the type of the media data - so called payload type. For most common audio and video formats standard payload types are defined. The non-standard types have to be negotiated by the communicating parties by other means/protocols (e.g. using the Session Description Protocol SDP). For that reason a range of <i>dynamic payload types</i> is reserved.


- sequence number is primarily used to identify and detect lost packets and secondly to reconstruct the order in which packets where sent, which may make loss detection easier;
The following table shows the defined RTP payload types used in Barix firmware.
Note that Payload types 0, 8, 10, 11 and 14 are defined by the RTP standard while types 96 to 112 (dynamic payload types) are Barix specific.


- the timestamp is the sampling instant for the first octet of media data in a packet. It can be used to help recover the clock frequency at the receiving side, if it is not given by other means.


RTP does not include a loss recovery mechanism in case of packet losses.
{| class="wikitable" border="1" cellspacing="0"
! <center style="background-color:#FFB6C1">RTP payload type</center>
! <center style="background-color:#FFB6C1">Audio Format</center>
 
|-
| <center>0</center>
| μ-Law, 8bit, mono, 8kHz
 
|-
| <center>8</center>
| A-Law, 8bit, mono, 8kHz
 
|-
| <center>10</center>
| PCM 16bit, MSB first, signed, 44.1kHz stereo, left channel first
 
|-
| <center>11</center>
| PCM 16bit, MSB first, signed, 44.1kHz mono
 
|-
| <center>14</center>
| MPEG audio
 
|-
| <center>96</center>
| PCM, 16bit, MSB first, signed, 8kHz mono
 
|-
| <center>97</center>
| μ-Law, 8bit, mono, 24kHz
 
|-
| <center>98</center>
| A-Law, 8bit, mono, 24kHz
 
|-
| <center>99</center>
| PCM, 16bit, MSB first, signed, 24kHz mono
 
|-
| <center>100</center>
| μ-Law, 8bit, mono, 32kHzreserved
 
|-
| <center>101</center>
| A-Law, 8bit, mono, 32kHzreserved
 
|-
| <center>102</center>
| PCM, 16bit, MSB first, signed, 32kHz monoreserved
 
|-
| <center>103</center>
| PCM 16bit, MSB first, signed, 48kHz stereo, left channel first
 
|-
| <center>104</center>
| PCM, 16bit, LSB first, signed, 8kHz mono
 
|-
| <center>105</center>
| PCM, 16bit, LSB first, signed, 24kHz mono
 
|-
| <center>106</center>
| PCM, 16bit, LSB first, signed, 32kHz monoreserved
 
|-
| <center>107</center>
| PCM 16bit, LSB first, signed, 44.1kHz stereo, left channel first
 
|-
| <center>108</center>
| PCM 16bit, LSB first, signed, 48kHz stereo, left channel first
 
|-
| <center>109</center>
| μ-Law, 8bit, mono, 12kHz
 
|-
| <center>110</center>
| A-Law, 8bit, mono, 12kHz
 
|-
| <center>111</center>
| PCM, 16bit, MSB first, signed, 12kHz mono
 
|-
| <center>112</center>
| PCM, 16bit, LSB first, signed, 12kHz mono
 
|-
| <center>127</center>
| Generic (see below)
 
|}
 
===Sequence Number===
is primarily used to identify and detect lost packets and secondly to reconstruct the order in which packets where sent, which may make loss detection easier;
 
===Time Stamp===
is the sampling instant for the first octet of media data in a packet. It can be used to help recover the clock frequency at the receiving side, if it is not given by other means.
 
===References===
Check the Wikipedia for an introduction to the RTP protocol [http://en.wikipedia.org/wiki/Real-time_Transport_Protocol].

Latest revision as of 10:11, 18 November 2010

RTP Protocol

RTP (Real-time Transport Protocol), as a standard application protocol of the Internet Protocol Suite, has been designed for transport of multimedia streams in IP networks.

Implementation is widely based on the User Datagram Protocol (UDP). The Transmission Control Protocol (TCP) is not often used by RTP for its high latency caused by connection establishment and error correction. The Barix implementation employs UDP as a transmission protocol.

In multimedia applications low latency is essential, whereas an occasional packet loss can be tolerated. A packet typically carries a fraction of a second worth of audio, which makes the lost packet almost inaudible. RTP adds a sequence number and a time stamp to each packet to allow detection and recovery from network errors.

Payload Type

Each RTP packet carries 7-bit information describing the type of the media data - so called payload type. For most common audio and video formats standard payload types are defined. The non-standard types have to be negotiated by the communicating parties by other means/protocols (e.g. using the Session Description Protocol SDP). For that reason a range of dynamic payload types is reserved.

The following table shows the defined RTP payload types used in Barix firmware. Note that Payload types 0, 8, 10, 11 and 14 are defined by the RTP standard while types 96 to 112 (dynamic payload types) are Barix specific.


RTP payload type
Audio Format
0
 μ-Law, 8bit, mono, 8kHz
8
 A-Law, 8bit, mono, 8kHz
10
 PCM 16bit, MSB first, signed, 44.1kHz stereo, left channel first
11
 PCM 16bit, MSB first, signed, 44.1kHz mono
14
 MPEG audio
96
 PCM, 16bit, MSB first, signed, 8kHz mono
97
 μ-Law, 8bit, mono, 24kHz
98
 A-Law, 8bit, mono, 24kHz
99
 PCM, 16bit, MSB first, signed, 24kHz mono
100
 μ-Law, 8bit, mono, 32kHzreserved
101
 A-Law, 8bit, mono, 32kHzreserved
102
 PCM, 16bit, MSB first, signed, 32kHz monoreserved
103
 PCM 16bit, MSB first, signed, 48kHz stereo, left channel first
104
 PCM, 16bit, LSB first, signed, 8kHz mono
105
 PCM, 16bit, LSB first, signed, 24kHz mono
106
 PCM, 16bit, LSB first, signed, 32kHz monoreserved
107
 PCM 16bit, LSB first, signed, 44.1kHz stereo, left channel first
108
 PCM 16bit, LSB first, signed, 48kHz stereo, left channel first
109
 μ-Law, 8bit, mono, 12kHz
110
 A-Law, 8bit, mono, 12kHz
111
 PCM, 16bit, MSB first, signed, 12kHz mono
112
 PCM, 16bit, LSB first, signed, 12kHz mono
127
 Generic (see below)

Sequence Number

is primarily used to identify and detect lost packets and secondly to reconstruct the order in which packets where sent, which may make loss detection easier;

Time Stamp

is the sampling instant for the first octet of media data in a packet. It can be used to help recover the clock frequency at the receiving side, if it is not given by other means.

References

Check the Wikipedia for an introduction to the RTP protocol [1].

Retrieved from "https://wiki.barix.com/index.php?title=RTP&oldid=2411"