This document summarizes information about the Stream Control Transmission Protocol (SCTP), Real-time Transport Protocol (RTP), and RTP Control Protocol (RTCP). SCTP is a transport layer protocol that provides reliable message delivery like TCP with multi-streaming capabilities. RTP is used for delivering audio and video over IP and defines packet formats with timestamps and sequence numbers. RTCP monitors RTP transmission quality and provides feedback on metrics like packet loss.
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...ijcsit
A widely used TCP protocol is originally developed for wired networks. It has many variants to detect and
control congestion in the network. However, Congestion control in all TCP variants does not show similar
performance in MANET as in wired network because of the fault detection of congestion. In this paper, we
do a performance comparison between TCP variants NEW RENO, SACK and Vegas in AODV and DSR
reactive (On-Demand) routing protocols. Network traffic between nodes is provided by using File Transfer
Protocol (FTP) application. Multiple scenarios are created and the average values of each performance
parameter are used to evaluate the performance. The results show that TCP variants perform better in
terms of throughput and Packet drop with DSR routing protocol compared with AODV routing protocol.
TCP variants show a lower Jitter in AODV compared with DSR.
Abstract - The Transmission Control Protocol (TCP) is
connection oriented, reliable and end-to-end protocol that support
flow and congestion control, with the evolution and rapid growth
of the internet and emergence of internet of things IoT, flow and
congestion have clear impact in the network performance. In this
paper we study congestion control mechanisms Tahoe, Reno,
Newreno, SACK and Vegas, which are introduced to control
network utilization and increase throughput, in the performance
evaluation we evaluate the performance metrics such as
throughput, packets loss, delivery and reveals impact of the cwnd.
Showing that SACK had done better performance in terms of
numbers of packets sent, throughput and delivery ratio than
Newreno, Vegas shows the best performance of all of them.
Abstract
The rapid growth in the Internet of Things (IoTs)
has change our life to be more intelligent and smart,
the development in the Wireless Sensors Networks
(WSNs), besides the wide use of the embedded devices
in different area like industry, home automation,
transport, agriculture and health care, which was led
the Routing Over Low-power and Lossy-network
(ROLL) working group to introduce the IPv6 Routing
Protocol for Low-Power and Lossy Networks (RPL),
therein the RPL nodes have organized topology as a
Directed Acyclic Graph (DAG) and terminated at one
root to form the Destination Oriented DAGs
(DODAGs). In this paper by using InstantContiki3.0
and CoojaGUI we analyze the DODAG formations,
the RPL control messages that are send downward
and upward routes to construct and maintain
DODAG and the Rank computation by Objective
Function (OF) for inconsistency and loop detection,
also we evaluate the performance of the RPL based
on the Expected Transmission Count (ETX) OF that
enable RPL to select and optimize routes within RPL
instance, as well as we evaluate the following metrics:
The ETX Reliability Object (ETX), Radio Duty Cycle
(RDC), energy consumption, the received packets by
the motes and neighbor count. The simulation results
show that the RPL control messages flow in consistent
manner, the DODAG root able to connect to all of the
neighbor motes, also Rank illustration shows no loops
and DODAG topology consistent, as well as the ETX
can essentially take control over DODAG formations
and it has an effects in the RDC ratio, furthermore
most of the motes show reasonable low power
consumption, also the motes show acceptable number
of the received packets.
Abstract— Internet of things (IoT) is a new networks paradigm,
that billions of internet things can be connected at anytime and
anyplace, and it’s expected to include billions of smart devices,
these devices characterized by small memory, low transfer rate
and low energy, internet protocol version 6 (IPv6) it was
introduced to offer huge address space, however it doesn’t
compatible with capabilities of the constrained device, therefore
IPv6 over low power Wireless Personal Area network
(6LoWPAN) adaptation layer was introduced to carry IPv6
datagram over constrained links, in this paper, we first provide
intensive analysis of 6LoWPAN specifications that includes IPv6
encapsulation, frame format, 6LoWPAN header compression,
fragmentation of the payload datagram and encoding of user
datagram protocol UDP, in addition to the implementation of the
6LoWPAN in the NS-3 using different payload size, then we
evaluate the following metrics throughput, packets loss, delay
and jitter, the results showed that the fragmentation effects the
network throughput and increase the delay and the number of
lost packets, moreover, when payload fit within a single frame the
network show better performance , there are no packets lost as
well as minimum values of the delay and the jitter, and in the
two cases 6LoWPAN shows reasonable packets delivery ratio.
Location Gathering: An Evaluation of Smartphone-Based Geographic Mobile Field...Greenapps&web
Mobile field spatial data collection is the act of gathering attribute data, including spatial position, about features in a study area. A common method of field data collection is to use a handheld computing device attached to a global navigation satellite system in which attribute data are directly inputted into a database table. The market for mobile data collection systems was formerly dominated by bulky positioning systems and highly specialized software. However, recent years have seen the emergence and widespread adoption of highly customizable and user-friendly mobile smartphones and tablets. In this research, smartphone devices and smartphone data collection applications were tested and compared to a conventional survey-grade field data collection system to compare the capabilities and possible use cases of each. The test consisted of an evaluation of the accuracy and precision of several mobile devices, followed by a usability analysis of several contemporary data collection applications for the Android operating system. The results of the experiment showed that mobile devices and applications are still less powerful than dedicated conventional data collection systems. However, the performance gap is shrinking over time. The use cases for mobile devices as data collection systems are currently limited to general use and small to mid-size projects, but future development promises expanding capability.
This 2-hour class is dedicated to Facebook – what is it, how it works and how to use it.
With lots of information and practical tips and tricks, this workshop will give you the knowledge and tools to start utilising the world’s most popular social media platform better for your organisation.
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...ijcsit
A widely used TCP protocol is originally developed for wired networks. It has many variants to detect and
control congestion in the network. However, Congestion control in all TCP variants does not show similar
performance in MANET as in wired network because of the fault detection of congestion. In this paper, we
do a performance comparison between TCP variants NEW RENO, SACK and Vegas in AODV and DSR
reactive (On-Demand) routing protocols. Network traffic between nodes is provided by using File Transfer
Protocol (FTP) application. Multiple scenarios are created and the average values of each performance
parameter are used to evaluate the performance. The results show that TCP variants perform better in
terms of throughput and Packet drop with DSR routing protocol compared with AODV routing protocol.
TCP variants show a lower Jitter in AODV compared with DSR.
Abstract - The Transmission Control Protocol (TCP) is
connection oriented, reliable and end-to-end protocol that support
flow and congestion control, with the evolution and rapid growth
of the internet and emergence of internet of things IoT, flow and
congestion have clear impact in the network performance. In this
paper we study congestion control mechanisms Tahoe, Reno,
Newreno, SACK and Vegas, which are introduced to control
network utilization and increase throughput, in the performance
evaluation we evaluate the performance metrics such as
throughput, packets loss, delivery and reveals impact of the cwnd.
Showing that SACK had done better performance in terms of
numbers of packets sent, throughput and delivery ratio than
Newreno, Vegas shows the best performance of all of them.
Abstract
The rapid growth in the Internet of Things (IoTs)
has change our life to be more intelligent and smart,
the development in the Wireless Sensors Networks
(WSNs), besides the wide use of the embedded devices
in different area like industry, home automation,
transport, agriculture and health care, which was led
the Routing Over Low-power and Lossy-network
(ROLL) working group to introduce the IPv6 Routing
Protocol for Low-Power and Lossy Networks (RPL),
therein the RPL nodes have organized topology as a
Directed Acyclic Graph (DAG) and terminated at one
root to form the Destination Oriented DAGs
(DODAGs). In this paper by using InstantContiki3.0
and CoojaGUI we analyze the DODAG formations,
the RPL control messages that are send downward
and upward routes to construct and maintain
DODAG and the Rank computation by Objective
Function (OF) for inconsistency and loop detection,
also we evaluate the performance of the RPL based
on the Expected Transmission Count (ETX) OF that
enable RPL to select and optimize routes within RPL
instance, as well as we evaluate the following metrics:
The ETX Reliability Object (ETX), Radio Duty Cycle
(RDC), energy consumption, the received packets by
the motes and neighbor count. The simulation results
show that the RPL control messages flow in consistent
manner, the DODAG root able to connect to all of the
neighbor motes, also Rank illustration shows no loops
and DODAG topology consistent, as well as the ETX
can essentially take control over DODAG formations
and it has an effects in the RDC ratio, furthermore
most of the motes show reasonable low power
consumption, also the motes show acceptable number
of the received packets.
Abstract— Internet of things (IoT) is a new networks paradigm,
that billions of internet things can be connected at anytime and
anyplace, and it’s expected to include billions of smart devices,
these devices characterized by small memory, low transfer rate
and low energy, internet protocol version 6 (IPv6) it was
introduced to offer huge address space, however it doesn’t
compatible with capabilities of the constrained device, therefore
IPv6 over low power Wireless Personal Area network
(6LoWPAN) adaptation layer was introduced to carry IPv6
datagram over constrained links, in this paper, we first provide
intensive analysis of 6LoWPAN specifications that includes IPv6
encapsulation, frame format, 6LoWPAN header compression,
fragmentation of the payload datagram and encoding of user
datagram protocol UDP, in addition to the implementation of the
6LoWPAN in the NS-3 using different payload size, then we
evaluate the following metrics throughput, packets loss, delay
and jitter, the results showed that the fragmentation effects the
network throughput and increase the delay and the number of
lost packets, moreover, when payload fit within a single frame the
network show better performance , there are no packets lost as
well as minimum values of the delay and the jitter, and in the
two cases 6LoWPAN shows reasonable packets delivery ratio.
Location Gathering: An Evaluation of Smartphone-Based Geographic Mobile Field...Greenapps&web
Mobile field spatial data collection is the act of gathering attribute data, including spatial position, about features in a study area. A common method of field data collection is to use a handheld computing device attached to a global navigation satellite system in which attribute data are directly inputted into a database table. The market for mobile data collection systems was formerly dominated by bulky positioning systems and highly specialized software. However, recent years have seen the emergence and widespread adoption of highly customizable and user-friendly mobile smartphones and tablets. In this research, smartphone devices and smartphone data collection applications were tested and compared to a conventional survey-grade field data collection system to compare the capabilities and possible use cases of each. The test consisted of an evaluation of the accuracy and precision of several mobile devices, followed by a usability analysis of several contemporary data collection applications for the Android operating system. The results of the experiment showed that mobile devices and applications are still less powerful than dedicated conventional data collection systems. However, the performance gap is shrinking over time. The use cases for mobile devices as data collection systems are currently limited to general use and small to mid-size projects, but future development promises expanding capability.
This 2-hour class is dedicated to Facebook – what is it, how it works and how to use it.
With lots of information and practical tips and tricks, this workshop will give you the knowledge and tools to start utilising the world’s most popular social media platform better for your organisation.
Data Management for Urban Tree Monitoring – Software RequirementsGreenapps&web
The creation of this report was organized by the Pennsylvania Horticultural Society (PHS) and the USDA Forest Service Philadelphia Field Station to explore how technology could be used to support the longterm systematic monitoring of urban trees by trained professionals, student interns and volunteers; assist with tree planting and maintenance data processes; and enable data to be organized and shared between researchers and practitioners. Interviews with researchers and forestry practitioners led to the development of user stories demonstrating how various individuals would interact with a software tool designed for long-term urban forestry monitoring. The information gathered from the interviews also resulted in a list of related system requirements for an ideal software monitoring system. Using that list of requirements, an evaluation of eleven existing software platforms in three general categories (proprietary forestry software, proprietary non-forestry specific software, and free and open source software) was completed and options listed for expanding the software to meet the system requirements. Data model and data integration workflows for a software system that met the majority of the system requirements were outlined, and PHS served as a test case for how such a system might work for tree planting and monitoring. The report concludes with a series of recommendations regarding cost and tech support, establishing an open data standard, creating a central data repository, and balancing collaboration and leadership.
Händler in Deutschland unterliegen den Vorschriften eines besonders strengen Wettbewerbsrechts. Gerade beim Verkauf an Verbraucher (business-to-consumer) sind diverse Informationspfl ichten beim Fernabsatzkauf und Pfl ichten im elektronischen Geschäftsverkehr zu erfüllen, denen Internethändler gerecht werden müssen. Praktisch jeder kleine Fehler kann abgemahnt werden. Es ist allerdings leichter gesagt als getan, einen Online-Shop rechtssicher zu gestalten. So gibt es unzählige Vorschriften zu beachten, die im Zweifel nur ein spezialisierter Rechtsanwalt vollständig überblicken kann. In dieser Broschüre soll daher ein Überblick über die wichtigsten rechtlichen Aspekte eines Online-Shops gegeben werden, so dass ein Händler, der an Verbraucher
verkauft, zumindest den gängigsten „Abmahnfallen“ entgehen kann.
Internet of things protocols for resource constrained applications Pokala Sai
A detailed documentation on internet protocols at present happening of internet of things applications and a bit comparison of protocols using basic requirements
Performance Evaluation of UDP, DCCP, SCTP and TFRC for Different Traffic Flow...IJECEIAES
The demand for internet applications has increased rapidly. Providing quality of service (QoS) requirements for varied internet application is a challenging task. One important factor that is significantly affected on the QoS service is the transport layer. The transport layer provides end-to-end data transmission across a network. Currently, the most common transport protocols used by internet application are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Also, there are recent transport protocols such as DCCP (data congestion control protocol), SCTP (stream congestion transmission protocol), and TFRC (TCP-friendly rate control), which are in the standardization process of Internet Engineering Task Force (IETF). In this paper, we evaluate the performance of UDP, DCCP, SCTP and TFRC protocols for different traffic flows: data transmission, video traffic, and VOIP in wired networks. The performance criteria used for this evaluation include throughput, end to end delay, and packet loss rate. Well-known network simulator NS-2 used to implement the UDP, DCCP, SCTP, and TFRC protocols performance comparison. Based on the simulation results, the performance throughput of SCTP and TFRC is better than UDP. Moreover, DCCP performance is superior SCTP and TFRC in term of end-to-end delay.
Overview of SCTP (Stream Control Transmission Protocol)Peter R. Egli
Overview of SCTP (Stream Control Transmission Protocol), outlining the main features and capabilities of SCTP.
SCTP is a transport protocol that overcomes many of the shortcomings of TCP, namely head-of-line blocking and stream-oriented transmission.
SCTP supports multiple streams within a connection and preserves boundaries of application messages thus greatly simplifying communication.
Additionally, SCTP supports multi-homing which increases availability in applications with high reliability demands.
SCTP inherits much of the congestion, flow and error control mechanisms of TCP.
SCTP has its roots in telecom carrier networks for use in transitional voice over IP scenarios.
However, SCTP is generic so that it is applicable in many enterprise applications as well.
Overview of SCTP (Stream Control Transmission Protocol)Peter R. Egli
Overview of SCTP (Stream Control Transmission Protocol), outlining the main features and capabilities of SCTP.
SCTP is a transport protocol that overcomes many of the shortcomings of TCP, namely head-of-line blocking and stream-oriented transmission.
SCTP supports multiple streams within a connection and preserves boundaries of application messages thus greatly simplifying communication.
Additionally, SCTP supports multi-homing which increases availability in applications with high reliability demands.
SCTP inherits much of the congestion, flow and error control mechanisms of TCP.
SCTP has its roots in telecom carrier networks for use in transitional voice over IP scenarios.
However, SCTP is generic so that it is applicable in many enterprise applications as well.
1. Assignment on SCTP, RTP and RTCP Protocol
Submitted by Abhishek Kesharwani
College: United Institute of Technology
Course: M.Tech
Branch: (CSE)
2. Stream Control Transmission Protocol
In computer networking, the Stream Control Transmission Protocol (SCTP) is a transport
layer protocol (protocol number 132 ), serving in a similar role to the popular protocols Transmission
Control Protocol (TCP) and User Datagram Protocol(UDP). It provides some of the same service
features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of
messages with congestion control like TCP.
The protocol was defined by the IETF Signaling Transport (SIGTRAN) working group in 2000, and is
maintained by the IETF Transport Area (TSVWG) working group. RFC 4960 defines the protocol.
Message-based multi-streaming
SCTP applications submit their data to be transmitted in messages (groups of bytes) to the SCTP
transport layer. SCTP places messages and control information into separate chunks (data chunks
and control chunks), each identified by a chunk header. The protocol can fragment a message into a
number of data chunks, but each data chunk contains data from only one user message. SCTP
bundles the chunks into SCTP packets. The SCTP packet, which is submitted to the Internet
Protocol, consists of a packet header, SCTP control chunks (when necessary), followed by SCTP
data chunks (when available).
SCTP may be characterized as message-oriented, meaning it transports a sequence of messages
(each being a group of bytes), rather than transporting an unbroken stream of bytes as does TCP.
As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed
to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol,
transporting streams of bytes reliably and in order. However TCP does not allow the receiver to
know how many times the sender application called on the TCP transport passing it groups of bytes
to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out
over the network, rather than having to keep a queue of individual separate outbound messages
which must be preserved as such.
The term multi-streaming refers to the capability of SCTP to transmit several independent streams of
chunks in parallel, for example transmitting web page images together with the web page text. In
essence, it involves bundling several connections into a single SCTP association, operating on
messages (or chunks) rather than bytes.
TCP preserves byte order in the stream by assigning a sequence number to each packet. SCTP, on
the other hand, assigns a sequence number to each message sent in a stream. This allows
independent ordering of messages in different streams. However, message ordering is optional in
SCTP; a receiving application may choose to process messages in the order of receipt instead of the
order they were sent.
Features
Features of SCTP include:
Multihoming support in which one or both endpoints of a connection can consist of more than
one IP address, enabling transparent fail-over between redundant network paths.
Delivery of chunks within independent streams eliminates unnecessary head-of-line blocking, as
opposed to TCP byte-stream delivery.
Path selection and monitoring to select a primary data transmission path and test the
connectivity of the transmission path.
Validation and acknowledgment mechanisms protect against flooding attacks and provide
notification of duplicated or missing data chunks.
3. Improved error detection suitable for Ethernet jumbo frames.
Association
TCP has provided the primary means to transfer data reliably across the Internet. However, TCP has
imposed limitations on several applications. From RFC 4960:
TCP provides both reliable data transfer and strict order-of-transmission delivery of data.
Some applications need reliable transfer without sequence maintenance, while others would
be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking
offered by TCP causes unnecessary delay.
The stream-oriented nature of TCP is often an inconvenience. Applications must add their
own record marking to delineate their messages, and must make explicit use of the push
facility to ensure that a complete message is transferred in a reasonable time.
The limited scope of TCP sockets complicates the task of providing highly-available data
transfer capability using multi-homed hosts.
TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks.
Packet structure
Bits 0–7 8–15 16–23 24–31
+0 Source port Destination port
32 Verification tag
64 Checksum
96 Chunk 1 type Chunk 1 flags Chunk 1 length
128 Chunk 1 data
… …
… Chunk N type Chunk N flags Chunk N length
… Chunk N data
SCTP packets have a simpler basic structure than TCP packets. Each consists of two basic
sections:
1. The common header, which occupies the first 12 bytes and is highlighted in blue, and
2. The data chunks, which occupy the remaining portion of the packet. The first chunk is
highlighted in green, and the last of Nchunks (Chunk N) is highlighted in red.
Each chunk has a type identifier that is one byte long yielding, at most, 255 different chunk
types. RFC 4960 defines a list of chunk types and there are currently 15 types defined. The
remainder of the chunk is a two byte length (maximum size of 65,535 bytes) and the data. If the
chunk does not form a multiple of 4 bytes (i.e., the length is not a multiple of 4) then it is implicitly
padded with zeros which are not included in the chunk length.
Security
Although encryption was not part of the original SCTP design, SCTP was designed with features for
improved security, such as 4-way handshake (compared to TCP 3-way handshake) to protect
against SYN flooding attacks, and large "cookies" for association verification and authenticity.
4. Reliability was also a key part of the security design of SCTP. Multihoming enables an association to
stay open even when some routes and interfaces are down. This is of particular importance
for SIGTRAN as it carries SS7 over an IP network using SCTP, and requires strong resilience during
link outages to maintain telecommunication service even when enduring network anomalies.
SCTP is sometimes a good fingerprinting candidate. Some operating systems ship with SCTP
support enabled, and, as it is not as well known as TCP or UDP, it is sometimes overlooked in
firewall and intrusion detection configurations, thus often permitting probing traffic.
Real-time Transport Protocol
The Real-time Transport Protocol (RTP, sometimes referred to as RTTP) 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 one of the technical foundations
of Voice over IP and in this context is often used in conjunction with a signaling protocol such as
the Session Initiation Protocol (SIP) which assists in setting up connections across the network.
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.
Overview
RTP is designed for end-to-end, real-time, transfer of stream data. The protocol provides facilities
for jitter compensation and detection of out of sequence arrival in data, which are common during
transmissions on an IP network. RTP allows data transfer to multiple destinations through IP
multicast. RTP is regarded as the primary standard for audio/video transport in IP networks and is
used with an associated profile and payload format.
Real-time multimedia streaming applications require timely delivery of information and can tolerate
some packet loss to achieve this goal. For example, loss of a packet in audio application may result
in loss of a fraction of a second of audio data, which can be made unnoticeable with suitable error
concealment algorithms The Transmission Control Protocol (TCP), although standardized for RTP
use is not normally used in RTP applications because TCP favors reliability over timeliness. Instead
the majority of the RTP implementations are built on the User Datagram Protocol (UDP). Other
transport protocols specifically designed for multimedia sessions are SCTP and DCCP, although, as
of 2010, they are not in widespread use.
RTP was developed by the Audio/Video Transport working group of the IETF standards
organization. RTP is used in conjunction with other protocols such as H.323 and RTSP The RTP
standard defines a pair of protocols, RTP and RTCP. RTP is used for transfer of multimedia data,
and the RTCP is used to periodically send control information and QoS parameters.
Protocol components
The RTP specification describes two sub-protocols:
The data transfer protocol, RTP, which deals with the transfer of real-time data. Information
provided by this protocol includes timestamps (for synchronization), sequence numbers (for
packet loss and reordering detection) and the payload format which indicates the encoded
format of the data.
5. The control protocol RTCP is used to specify quality of service (QoS) feedback
and synchronization between the media streams. The bandwidth of RTCP traffic compared to
RTP is small, typically around 5%.
An optional signaling protocol such as H.323, Session Initiation Protocol (SIP), or Jingle (XMPP)
An optional media description protocol such as Session Description Protocol
Sessions
An RTP Session is established for each multimedia stream. A session consists of an IP address with
a pair of ports for RTP and RTCP. For example, audio and video streams will have separate RTP
sessions, enabling a receiver to deselect a particular stream. The ports which form a session are
negotiated using other protocols such as RTSP (using SDP in the setup method) and SIP. According
to the specification, an RTP port should be even and the RTCP port is the next higher odd port
number.RTP and RTCP typically use unprivileged UDP ports (1024 to 65535) but may use other
transport protocols (most notably, SCTP and DCCP) as well, as the protocol design is transport
independent.
Packet header
RTP packet header
Bit offset[b]
0-1 2 3 4-7 8 9-15 16-31
0 Version P X CC M PT Sequence Number
32 Timestamp
64 SSRC identifier
96
CSRC identifiers
...
96+32×CC Profile-specific extension header ID Extension header length
128+32×CC
Extension header
...
The RTP header has a minimum size of 12 bytes. After the header, optional header extensions may
be present. This is followed by the RTP payload, the format of which is determined by the particular
class of application.[19]
The fields in the header are as follows:
6. Version: (2 bits) Indicates the version of the protocol. Current version is 2.
P (Padding): (1 bit) Used to indicate if there are extra padding bytes at the end of the RTP
packet. A padding might be used to fill up a block of certain size, for example as required by an
encryption algorithm. The last byte of the padding contains the number of padding bytes that
were added (including itself).
X (Extension): (1 bit) Indicates presence of an Extension header between standard header and
payload data. This is application or profile specific.
CC (CSRC Count): (4 bits) Contains the number of CSRC identifiers (defined below) that follow
the fixed header.
M (Marker): (1 bit) Used at the application level and defined by a profile. If it is set, it means that
the current data has some special relevance for the application.
PT (Payload Type): (7 bits) Indicates the format of the payload and determines its interpretation
by the application. This is specified by an RTP profile. For example, see RTP Profile for audio
and video conferences with minimal control (RFC 3551).
Sequence Number: (16 bits) The sequence number is incremented by one for each RTP data
packet sent and is to be used by the receiver to detect packet loss and to restore packet
sequence. The RTP does not specify any action on packet loss; it is left to the application to take
appropriate action. For example, video applications may play the last known frame in place of
the missing frame. According to RFC 3550, the initial value of the sequence number should be
random to make known-plaintext attacks on encryption more difficult. RTP provides no
guarantee of delivery, but the presence of sequence numbers makes it possible to detect
missing packets.
Timestamp: (32 bits) Used to enable the receiver to play back the received samples at
appropriate intervals. When several media streams are present, the timestamps are
independent in each stream, and may not be relied upon for media synchronization. The
granularity of the timing is application specific. For example, an audio application that samples
data once every 125 µs (8 kHz, a common sample rate in digital telephony) would use that value
as its clock resolution. The clock granularity is one of the details that is specified in the RTP
profile for an application.
SSRC: (32 bits) Synchronization source identifier uniquely identifies the source of a stream. The
synchronization sources within the same RTP session will be unique.
CSRC: (32 bits each) Contributing source IDs enumerate contributing sources to a stream which
has been generated from multiple sources.
Extension header: (optional) the first 32-bit word contains a profile-specific identifier (16 bits)
and a length specifies (16 bits) that indicates the length of the extension (EHL=extension header
length) in 32-bit units, excluding the 32 bits of the extension header.
RTP-based systems
A complete network based system includes other protocols and standards in conjunction with RTP.
Protocols such as SIP, Jingle, RTSP, H.225 and H.245 are used for session initiation, control and
termination. Other standards, such as H.264, MPEG and H.263, are used to encode the payload
data as specified via RTP Profile.
An RTP sender captures the multimedia data, then encodes frames and transmits it as RTP packets
with appropriate timestamps and increasing sequence numbers. Depending on the RTP Profile in
use, the sender may set the Payload Type field. The RTP receiver captures the RTP packets,
detects missing packets, and may reorder packets. It decodes the frames according to the payload
format and presents the stream to its user.
7. (RTCP)RTP Control Protocol
The RTP Control Protocol (RTCP) is a sister protocol of the Real-time Transport Protocol (RTP). Its
basic functionality and packet structure is defined in RFC 3550. RTCP provides out-of-band statistics
and control information for an RTP session. It partners with RTP in the delivery and packaging of
multimedia data, but does not transport any media streams itself. The primary function of RTCP is to
provide feedback on the quality of service (QoS) in media distribution by periodically sending
statistics information to participants in a streaming multimedia session.
RTCP transports statistics for a media connection and information such as transmitted octet and
packet counts, lost packet counts, jitter, and round-trip delay time. An application may use this
information to control quality of service parameters, perhaps by limiting flow, or using a
different codec.
Protocol functions
Typically RTP will be sent on an even-numbered UDP port, with RTCP messages being sent over
the next higher odd-numbered port.
RTCP itself does not provide any flow encryption or authentication methods. Such mechanisms may
be implemented, for example, with the Secure Real-time Transport Protocol (SRTP).
RTCP provides three basic functions expected to be implemented in all RTP sessions:
The primary function of RTCP is to gather statistics on quality aspects of the media distribution
during a session and transmit this data to the session media source and other session
participants. Such information may be used by the source for adaptive media encoding (codec)
and detection of transmission faults. If the session is carried over a multicast network, this
permits non-intrusive session quality monitoring.
RTCP provides canonical end-point identifiers (CNAME) to all session participants. Although a
source identifier (SSRC) of an RTP stream is expected to be unique, the instantaneous binding
of source identifiers to end-points may change during a session. The CNAME establishes
unique identification of end-points across an application instance (multiple use of media tools)
and for third-party monitoring.
RTCP reports are expected to be sent by all participants, even in a multicast session which may
involve thousands of recipients. Such traffic will increase proportionally with the number of
participants. Thus, to avoid network congestion, the protocol must include session bandwidth
management. This is achieved by dynamically controlling the frequency of report transmissions.
RTCP bandwidth usage should generally not exceed 5% of total session bandwidth.
Furthermore, 25% of the RTCP bandwidth should be reserved to media sources at all times, so
8. that in large conferences new participants can receive the CNAME identifiers of the senders
without excessive delay.
A fourth, optional feature, is the provisioning of session control functions, because RTCP is a
convenient means to reach all session participants, whereas RTP itself is not. RTP is only
transmitted by a media source.
Message types
RTCP distinguishes several types of packets: sender report, receiver report, source, description, and
bye. In addition, the protocol is extensible and allows application-specific RTCP packets. A
standards-based extension of RTCP is the Extended Report packet type introduced by RFC 3611
Sender report (SR)
The sender report is sent periodically by the active senders in a conference to report
transmission and reception statistics for all RTP packets sent during the interval. The sender
report includes an absolute timestamp, which is the number of seconds elapsed since
midnight on January 1, 1900. The absolute timestamp allows the receiver to synchronize
RTP messages. It is particularly important when both audio and video are transmitted
simultaneously, because audio and video streams use independent relative timestamps.
Receiver report (RR)
The receiver report is for passive participants, those that do not send RTP packets. The
report informs the sender and other receivers about the quality of service.
Source description (SDES)
The Source Description message is used to send the CNAME item to session participants. It
may also be used to provide additional information such as the name, e-mail address,
telephone number, and address of the owner or controller of the source.
End of participation (BYE)
A source sends a BYE message to shut down a stream. It allows an end-point to announce
that it is leaving the conference. Although other sources can detect the absence of a source,
this message is a direct announcement. It is also useful to a media mixer.
Application-specific message (APP)
The application-specific message provides a mechanism to design application-specific
extensions to the RTCP protocol.