Network Working Group Magnus Westerlund
INTERNET-DRAFT Kristofer Dovstam
Expires: July 2002 Ericsson, Sweden
Frank Hartung
Uwe Horn
Ericsson, Germany
January 2, 2002
Generic RTP Payload Format for Time-lined Static Media
<draft-westerlund-avt-rtp-static-media-01.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This Internet Draft discusses an RTP payload format for time-lined
static media. "Time-lined static media" means static media objects
like pictures and text extended by timing information. Applications
that would benefit from such a payload format are for instance
slideshow streaming and streaming of subtitled video and audio. We
discuss the important requirements for a payload format and propose a
specification that suits those requirements.
Westerlund [Page 1]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
TABLE OF CONTENTS
1. Introduction........................................................2
2. Usage scenarios.....................................................3
2.1. Image slideshow...................................................3
2.2. Subtitled video and audio streams.................................4
3. Problems of existing approach.......................................5
4. Requirements........................................................6
5. Proposal for an RTP Payload Format for time-lined static media......7
5.1. RTP Header Usage..................................................7
5.2. Header Formats....................................................8
5.2.1. Object Identifier Header........................................8
5.2.2. Duration Header.................................................9
5.2.3. Data Header.....................................................9
5.2.4. Offset Headers (ByteOffset).....................................9
5.3. Compound payload.................................................10
6. Media Profiles.....................................................11
6.1. JPEG.............................................................11
6.1.1. Resilient transport............................................11
6.1.2. Profile specific headers.......................................12
6.1.3. Payload format header usage:...................................12
6.2. TEXT.............................................................13
6.2.1. Resilient transport............................................13
6.2.2. Profile Specific Headers.......................................13
6.2.3. Payload format header usage:...................................14
7. Congestion Control.................................................14
8. Security Consideration.............................................15
8.1. Confidentiality..................................................15
8.2. Authentication...................................................15
9. IANA Considerations................................................15
10. MIME type registration............................................15
11. Author's Addresses................................................16
12. References........................................................16
1. Introduction
Today, content creators have various options to specify complex
multimedia presentations composed of different media types and
synchronized along a global timeline.
SMIL [1] for instance is a powerful tool that allows one to define
the spatial and temporal layout of multimedia presentations that
contain video, audio, still images, text, and other media elements.
In addition to SMIL, there are a couple of file format specifications
that also allow one to create synchronized multimedia presentations,
composed of a mix of different media types.
Westerlund et al. [Page 2]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
Media types are usually classified into static and continuous media.
Continuous media types are characterized by an intrinsic time line
resulting from taking media samples at regular time intervals. Video
and audio are typical examples for continuous media types. Static
media types differ from continuous media types in the sense that they
do not possess an intrinsic time line. Examples of static media types
are still images and plain text.
In addition to static and continuous media one can identify a third
media type, which we call "time-lined static media". With time-lined
static media we mean static media objects like pictures and text with
added timing information such that the presentation of a series of
static media objects can be synchronized with a global timeline.
Application scenarios that would benefit from such an RTP [3] payload
format are for instance slideshow streaming and subtitled video and
audio streams.
Today, there exist various RTP payload formats that can be used to
packetize data belonging to continuous media elements. Static media
types, like an image in an HTML page, are usually transferred via
HTTP. However, as we will see later, using TCP [2] based HTTP for
time-lined static media has many drawbacks, especially if
synchronization with a continuous media streams is required.
Therefore, streaming of time-lined static media objects should be
done based on RTP over UDP similar to streaming of continuous media.
In the following, we will first discuss in more detail some usage
scenarios that would benefit from an RTP payload format for time-
lined static media. After that, we will list some important
requirements of such a payload format. Finally, we propose a
specification of a payload format for time-lined static media that
takes the identified requirements into account.
2. Usage scenarios
This section discusses in more detail two use cases that would
benefit from a payload format for time-lined static media objects,
namely slideshow streaming and video and audio streaming with
subtitles.
2.1. Image slideshow
A slideshow in its simplest form is characterized by a series of
images with a defined presentation start time and duration for each
image. Usually the time-lined images are accompanied by a
synchronized audio track.
Westerlund et al. [Page 3]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
/ \
Media |
Elements|
|
Image 1 | ####
Image 2 | #########
Image 3 | #####
Image 4 | ##########
Audio | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------->
time
Figure 1
Figure 1 gives an example for a series of images synchronized with
audio. The vertical axis denotes the different media elements; the
horizontal axis represents the time line. In the shown example audio
starts first. After three time units the first image appears and
stays visible for 4 time units, followed by the second image which
stays visible for 9 time units and so on.
2.2. Subtitled video and audio streams
Subtitling is characterized by combining continuous media types like
video with audio or audio only with time-lined static text elements.
Fig. 2 gives an example that starts with video and audio. The first
subtitle appears after three time units and remains visible for four
time units. After a short period where no subtitle at all is shown,
subtitle 2 is shown over a period of 5 time units and so on.
/ \
Media |
Elements|
|
ST 1 | ####
ST 2 | #####
ST 3 | #####
ST 4 | ###
Audio | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Video | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------->
time
Figure 2
Westerlund et al. [Page 4]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
3. Problems of existing approach
As mentioned in the introduction, there is currently no RTP payload
specification that could be used for time-lined static media
elements.
The workaround today is to transfer each of the static media objects
in separate files via TCP or HTTP to the client, where the timing
information is added. For instance, a slideshow application defined
in SMIL would use HTTP/TCP for the images, with timing information
coming from the SMIL file, and if audio is present as well, use
RTP/UDP for streaming the audio.
However, this "hybrid" approach has a couple of drawbacks, which are
listed in the following:
- TCP is not suited for real-time transmission scenarios
TCP guarantees error-free delivery of data between a sender and a
receiver over best effort networks by employing a specific
retransmission mechanism. However, the requirements of real-time
streaming applications are not addressed by TCP. For streaming timely
delivery of data is more important than error-free delivery of data.
This is a well-known fact and has lead to the development of RTP [3].
- TCP is not suited for multicast scenarios
In a multicast distributed multimedia session it is not recommended
that the receivers use TCP to fetch static media. If the group were
large, this would create an enormous load on the server holding the
static media. Instead a method that can take advantage of multicast
network is needed. In the past, plenty of work has been done on
achieving reliable transport over multicast, e.g. SRM [5]. There is
today ongoing work on standardizing solutions in the IETF Reliable
Multicast Transportation (RMT) working group.
Note that this payload format is not intended to replace such
mechanisms, instead it can be used to achieve simple unreliable
transport of static media that can tolerate some losses.
- Protocol mix prevents unified congestion control
The need for congestion control in the context of real-time media
delivery becomes more and more important. In this context a unified
congestion control approach on session level is more appropriate
compared to using different congestion control mechanisms for time-
lined static (TCP) and continuous (RTP/UDP) media elements.
Westerlund et al. [Page 5]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
- Protocol mix prevents unified bandwidth adaptation
The division of responsibility for transport of media between a
server and a client also complicates bandwidth adaptation. Audio and
video will be streamed down from the server to the client. The client
fetches static media from the server. If also the static media are
streamed to the client, the server can more easily ensure an optimal
quality of the overall presentation under the presence of a bandwidth
constraint.
We therefore propose to introduce a new RTP payload type suitable for
static media types. In the following section we will discuss some
important requirements of such a payload format before we are going
to describe our specification proposal for such a payload format.
4. Requirements
A payload format for time-lined static media types should fulfill the
following requirements:
- Timing information
The availability of timing information in the media packet(s) is
crucial. It can be used for many transmission related purposes, like
optimal scheduling of RTP packets at the application server. Timing
information also tells the client application when and for how long a
specific static media object should be presented to the user.
- Applicable to any kind of static media
The payload format SHOULD be generic enough to be applicable to any
kind of static media.
- Support for Application Level Framing (ALF)
The payload format SHOULD support packetization of data according to
the needs of the application [6]. An application might for instance
want to packetize the data belonging to one static object in a way
that is most resilient against packet losses.
- Support for object identifiers
It SHOULD be possible for client applications to reference each
object in a series of time-lined media objects by a unique
identifier. For instance in a layout specification file one might
want to specify different spatial locations for each of the time-
lined objects. How this can be done for instance within SMIL [1] is
however out of the scope of this document.
Westerlund et al. [Page 6]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
- Error resilience
The payload specification SHOULD support the employment of forward
error correction (FEC) mechanisms as described in RFC 2733 [7]. It
SHOULD also be possible to use the RTP retransmission methods that
are currently under discussion within IETF [10][11]. Also the
employment of application-level error concealment methods for lost
packets SHOULD NOT be prevented.
- Multicast capabilities
The payload format specification MUST allow streaming of time-lined
static media objects using multicasting.
5. Proposal for an RTP Payload Format for time-lined static media
This RTP payload format is supposed to be applicable to all kind of
static media types. We therefore use a header format that is
specified by a payload "framework" together with several payload
profiles.
The payload framework is independent of the media type and defines a
number of basic headers that can be used. Payload profiles are media
type dependent and define how to use the framework. Typically, a
payload profile defines which headers of the payload framework are
used, and MAY also specify new headers. A payload profile also
specifies and MAY give recommendations on how to packetize data of
the specific media type according to the ALF [6] principle. It may
also propose error recovery mechanisms for improved error resilience
against packet losses.
5.1. RTP Header Usage
The first part of an RTP packet is the fixed RTP header. The three
fields set by the application in the fixed RTP header, timestamp,
marker bit and payload type are explained here. For this payload
format these fields should be interpreted and defined as following:
Timestamp: The timestamp is used for identifying the time
when the object shall be used by the receiver(s).
The timestamp MUST be identical for all packets
being part of the same object, i.e. the timestamp
is used for binding packets to the correct
object. If two different objects are going to be
used at the same time, they MUST have different
timestamps. To minimize the effect of this rule,
the timestamp difference between these objects is
RECOMMENDED to be a single timestamp unit. The
timestamp rate is either defined, dynamically
Westerlund et al. [Page 7]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
during session setup, e.g. in SDP [4], or by a
profile.
Marker bit (M bit): The marker bit is used to indicate the last
packet of an object.
Payload Type (PT): The payload type is set dynamically and out of
band in accordance with current practice.
Different payload types SHALL be established for
each media profile that is used in a multimedia
session.
5.2. Header Formats
This section defines a number of general headers that can be used by
any profile.
All headers start with an eight-bit identifier. These identifiers are
taken from two different number spaces. The numbers 0-127 are used a
common number space, identifying general headers and must be
registered with IANA. Numbers 128-255 represent the profile specific
range. Each profile is responsible for assigning the header numbers
uniquely within this space.
A Header SHALL only be present a single time in the each packet,
unless the interpretation of multiple instances is defined in the
header format or a profile.
Some headers may contain information that is essential for the whole
object and not only for the actual packet. To reduce the probability
that this essential information is lost due to a single packet loss,
it is recommended to employ appropriate FEC mechanisms. In the
simplest case, important headers should be repeated in multiple
packets belonging to the same object.
5.2.1. Object Identifier Header
The object identifier header (OID) is used by applications to name
different objects within a stream. The exact meaning of the OID is
profile and/or application dependent.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hd.type (1) | Len | Object Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: (Variable len. 0-255) :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Westerlund et al. [Page 8]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
Len: Number of bytes that the object identifier consists of. Valid
lengths are 0-255, where 0 is allowed but lacks purpose.
Object Identifier: Byte stream used for identifying the object that
this packet is part of. The interpretation of the content of
this field is profile or/and application specific.
5.2.2. Duration Header
This header is used to express the duration for which the object is
to be used at the receiver, in timestamp units.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hd.type (2) | Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Duration: The length of the time this object is to be used, expressed
in RTP Timestamp units.
5.2.3. Data Header
This header is used to carry object data. It MUST be the last header
used in the packet, since it lacks a length field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hd.type (0) | Data (until end of payload) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data: A byte stream of object data, which MUST be byte aligned. If
the objectÆs data prior to packetization in this header is not
byte aligned, the profile is responsible for defining how to
do it.
5.2.4. Offset Headers (ByteOffset)
A Fragmented byte stream needs indicators for where the data in each
packet belongs in the stream. This header gives an offset from the
start of the byte stream. The offset is of the first byte in the
fragmented data present in the packet.
Westerlund et al. [Page 9]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
16-bit offset field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hd.type (3) | Offset (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32-bit offset field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hd.type (4) | Offset (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Offset: The offset in bytes from the start of the object that the
first byte in the data block shall be located.
5.3. Compound payload
A complete payload consists of one or more headers and their content.
Which headers that are used is profile and application dependent. The
order of the headers have no importance, except for the data header
and its data block, that MUST be located last in the payload.
If a receiver encounters an unknown payload header the
depacketization SHOULD be halted. Valid headers positioned before the
unknown MAY be used. The reason it cannot simply be ignored is that
the size is unknown.
An example packet could look like this.
--------------
| RTP header |
-------------- <- RTP payload begins
| OID header |
--------------
| ByteOffset |
--------------
| Data head. |
--------------
| Data |
--------------
Westerlund et al. [Page 10]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
This example starts with the RTP header, which gives information
about which payload format and profile that is used in the PT field.
The timestamp gives information about when this object is to be
presented. The marker bit tells when the last packet in an object has
been received.
Looking at the start of the payload the header type field gives that
it is an Object Identifier. The length field of the OID gives how
long to read before the next payload header begins. The byte offset
header is of fixed length and after it is the data header. Directly
after the header the data begins and runs to the end of the payload.
6. Media Profiles
For each media type that is going to use this payload format, a
profile MUST be defined. A profile SHALL consists of the following:
- Definition of which of the general headers that are required, or
optional. Any unlisted header is prohibited
- Any definitions and numbering of profile specific headers.
- How to fragment an object to large for a single packet.
- Requirements and recommendations on how to improve the error
resilience of the media objects.
- A security consideration
- MIME Registration of the profile
In the following we give examples for appropriate media profiles for
JPEG images and text.
6.1. JPEG
Images, and especially JPEG, are widely used in multimedia
presentations. This profile describes how to transport image objects
in the form of JPEG coded images. The purpose of this profile is
different than the RTP payload format defined for motion JPEG in RFC
2035 [13]
The JPEG file should conform to the JPEG standard defined in ITU-T
Rec. T.81 | ISO/IEC 10918-1:1992 and the JPEG File Interchange
Format, JFIF.
The images are transported in the data and the JPEG file should end
with an End-Of-Image, EOI, marker segment signaled as 0xFFD9 [12].
6.1.1. Resilient transport
A JPEG image might not be possible to fragment into sizes suitable
for transport over IP networks without converting the bit stream.
Westerlund et al. [Page 11]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
To achieve images that can be fragmented according to the ALF
principle the image MUST be created using restart markers. This
marker makes it possible for the decoder to restart the decoding even
if previous segments were lost. Also Restart Interval Definition
(DRI), see B.2.4.4 in [12], SHOULD be used in a way that allows a
decoder to compute the spatial area that is affected by a lost
fragment.
The JPEG file header contains information that is absolutely
necessary for the decoding process. To ensure that this vital
information reaches the receiver, it SHOULD be repeated in each
packet. The relevant JPEG header information that needs to be
duplicated is labeled "Tables/Misc." and "Frame Header" (see B.2.4
and B.2.2 in [12]).
6.1.2. Profile specific headers
JPEG image header (JPEGhdr)
This header is used for repeating the header information in packets
that do not carry the header information in their data section.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hd.type (128) | Length | JPEG Header Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| (Variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The length in bytes of the JPEG Header Data.
JPEG Header Data: The data that MUST be copied into this header is:
Any information belonging to those parts of the bit stream
labeled "Tables/Misc." mentioned in section B.2.4, and "Frame
Header" in section B.2.2 in [12]. This means that the JPEG
header data includes all bytes starting with the first byte
after the SOI (start of image marker) until the scan starts.
6.1.3. Payload format header usage:
Any application using this profile MUST follow the table below
defining the usage of headers.
Westerlund et al. [Page 12]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
Headers Required Optional
----------------------------------------------
Data x
OID x
Duration x
ByteOffset x
JPEGhdr x
Each image is an object and fragmented if needed. The fragmentation
SHOULD be done at a restart marker. The ByteOffset header is used to
indicate where in each byte stream a fragment belongs. A JPEG image
header SHOULD be added to all packets to ensure that this essential
header information reaches the receiver.
6.2. TEXT
Time-lined text is typically used in subtitling, presentations,
advertisements, etc. Text streamed separate from other media will
give a greater flexibility in terms of language as well as spatial
and temporal control.
This profile describes how to transport text objects in the form of
strings. Each string consists of one or more lines. The text strings
are transported in the data part and SHALL also be NULL terminated.
The encoding of text shall be ISO 10 646-1 code with UTF-8
transformation.
6.2.1. Resilient transport
To make transport of text objects resilient against transport errors
the following measures can be taken.
The use of code based FEC, e.g. RFC 2733 [7] is RECOMMENDED to be
calculated over a single object. This will reduce the extra delay
that any recovery packet will result in. The use of FEC over an
object consisting of a single packet MAY give no advantage at all,
compared to repeating the packet one or several times.
It is RECOMMENDED to use retransmission [10]Error! Reference source
not found.[11] whenever it is possible.
6.2.2. Profile Specific Headers
Text Fragmentation header
This header is used to fragment text objects that are larger then one
packet (which is not the case for e.g. subtitling as mentioned
earlier, but can be the case for other applications). It has a row
Westerlund et al. [Page 13]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
and column offset used to place it in the correct position. A row is
equal to a text line and ends by a new line marker. The column number
is equal to which characters in order it is on the line, since the
last new line marker. A Text object MAY be fragmented at any
character, but it is RECOMMENDED to do fragmentation between
sentences or even more preferably between paragraphs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hd.type (128) | Row Offset | Col. Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Row Offset: 14 bits used to give a row offset into the text object,
i.e. the line in the text object which this packet's data
start on.
Column Offset: 10 bits giving which character on the line that the
text in the data part shall start on.
6.2.3. Payload format header usage:
Any application using this profile MUST follow the table below
defining the usage of headers.
Headers Required Optional Prohibited
----------------------------------------------------------
Data x
OID x
Duration x
ByteOffset x
TextFrag x
When fragmenting text objects it MUST be done using the TextFrag
header and not the ByteOffset header that would be a possibility. The
reason is that in the event of packet loss the fragment can be placed
on the correct row and character. Thus maintaining correct layout for
all received fragments.
7. Congestion Control
The need of congestion control for data transported with RTP has to
be considered. Some of the static media that can be transported by
this payload format have the possibility to adapt the size of each
object by trading size against quality. For example, an image can be
compressed to different sizes and corresponding qualities, and the
different versions can be sent alternatively. Attempting to use more
than the available bandwidth SHOULD be avoided. If FEC is used, there
is a need to regulate the amount, so that the FEC itself does not
Westerlund et al. [Page 14]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
worsen the problem. Therefore, it is RECOMMENDED that applications
using this payload also implement congestion control. The actual
mechanism for congestion control is not specified but should be
suitable for real-time flows, e.g. "Equation-Based Congestion Control
for Unicast Applications" [8]. For a more unified congestion control
between streams the congestion manager [14] can be used.
8. Security Consideration
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [3]. This implies that confidentiality of the media
streams is achieved by encryption. Because the payload format is
arranged end-to-end, encryption MAY be performed after encapsulation
so there is no conflict between the two operations.
This payload type and the profiles specified within this document
does not exhibit any significant non-uniformity in the receiver side
computational complexity for packet processing to cause a potential
denial-of-service threat. This MUST be considered and stated for all
new profiles created. Otherwise the main security issues are
confidentiality and authentication of the media itself. The payload
format itself does not have any support for security. These issues
have to be solved by a payload external mechanism, e.g. SRTP [9].
8.1. Confidentiality
When confidentiality of the transported media is desired, all RTP
payload bits MUST be encrypted.
8.2. Authentication
To authenticate the sender of the media an external mechanism has to
be added. It is RECOMMENDED that such a mechanism protect all the
payload bits. To prevent a man in the middle from tampering with the
packetization of the media data, also the RTP header SHOULD be
protected. Tampering with the RTP header could result in erroneous
depacketization/decoding that will lower media quality.
9. IANA Considerations
[TBW]
10. MIME type registration
[TBW]
Westerlund et al. [Page 15]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
11. Author's Addresses
Magnus Westerlund Tel: +46 8 4048287
Ericsson Research Email: Magnus.Westerlund@ericsson.com
Ericsson Radio Systems AB
Torshamnsgatan 23
SE-164 80 Stockholm, SWEDEN
Kristofer Dovstam Tel: +46 8 7641788
Ericsson Research Email: Kristofer.Dovstam@era.ericsson.se
Ericsson Radio Systems AB
Torshamnsgatan 23
SE-164 80 Stockholm, SWEDEN
Frank Hartung Tel: +49 2407 575389
Ericsson Research Email: Frank.Hartung@eed.ericsson.se
Ericsson Eurolab Deutschland GmbH
Ericsson Allee 1
D-52134 Herzogenrath, GERMANY
Uwe Horn Tel: +49 2407 5757834
Ericsson Research Email: Uwe.Horn@eed.ericsson.se
Ericsson Eurolab Deutschland GmbH
Ericsson Allee 1
D-52134 Herzogenrath, GERMANY
12. References
[1] Synchronized Multimedia Integration Language(SMIL 2.0)
Specification, http://www.w3.org/TR/smil20, January 2001
[2] Postel, J., "Transmission Control Protocol û DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September
1981.
[3] IETF RFC1889, "RTP: A Transport Protocol for Real-Time
Applications".
[4] IETF RFC 2327, "Session Description Protocol (SDP)".
[5] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L., "A
Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing", IEEE/ACM Transactions on Networking,
December 1997, Volume 5, Number 6, pp. 784-803.
[6] D. Clark, D. Tennenhouse, "Architectural Considerations for a
New Generation of Protocols", Proc. ACM SIGCOMMÆ90, 1990.
[7] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for Generic
Forward Error Correction", RFC 2733, IETF, December 1999.
Westerlund et al. [Page 16]
INTERNET-DRAFT RTP Payload Format for Static Media January 2, 2002
[8] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based
Congestion Control for Unicast Applications", ACM SIGCOMM 2000,
Stockholm, Sweden.
[9] R. Blom, et al., "The Secure Real Time Transport Protocol", IETF
WG draft, draft-ietf-avt-srtp-02.txt, November 2001, Work in
progress.
[10] Stephan Wenger and Joerg Ott, "RTCP-based Feedback: Concepts and
Message Timing Rules", draft-ietf-avt-rtcp-feedback-01.txt,
IETF, 21 November 2001, Work in progress.
[11] Miyazaki et al., "RTP Retransmission Payload Format", IETF WG
draft, draft-ietf-avt-rtp-selret-03.txt, November 2001, Work in
progress.
[12] ISO/IEC 10918-1, Information technology - Digital compression
and coding of continuous-tone still images requirements and
guidelines.
[13] L. Berc, et al., "RTP Payload Format for JPEG-compressed Video",
RFC 2035, IETF, October 1996.
[14] H. Balakrishnan and S. Seshan, "The Congestion Manager", RFC
3124, IETF, June 2001.
This Internet-Draft expires in July 2002.
Westerlund et al. [Page 17]