draft-ietf-avt-uxp-04.txt   draft-ietf-avt-uxp-05.txt 
Internet Engineering Task Force G. Liebl Internet Engineering Task Force G. Liebl
Internet Draft LNT, Munich Univ. of Internet Draft LNT, Munich Univ. of
Technology Technology
Document: draft-ietf-avt-uxp-04.txt Document: draft-ietf-avt-uxp-05.txt
November 2002 M. Wagner, J. Pandel, March 2003 M. Wagner, J. Pandel,
W. Weng W. Weng
Expires: May 2003 Siemens AG, Munich Expires: September 2003 Siemens AG, Munich
An RTP Payload Format for Erasure-Resilient Transmission of An RTP Payload Format for Erasure-Resilient Transmission of
Progressive Multimedia Streams Progressive Multimedia Streams
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum Drafts. Internet-Drafts are draft documents valid for a maximum
skipping to change at page 2, line ? skipping to change at page 2, line ?
Abstract Abstract
This document specifies an efficient way to ensure erasure- This document specifies an efficient way to ensure erasure-
resilient transmission of progressively encoded multimedia resilient transmission of progressively encoded multimedia
sources via RTP using Reed-Solomon (RS) codes together with sources via RTP using Reed-Solomon (RS) codes together with
interleaving. The level of erasure protection can be explicitly interleaving. The level of erasure protection can be explicitly
adapted to the importance of the respective parts in the source adapted to the importance of the respective parts in the source
stream, thus allowing a graceful degradation of application stream, thus allowing a graceful degradation of application
quality with increasing packet loss rate on the network. Hence, quality with increasing packet loss rate on the network. Hence,
this type of unequal erasure protection (UXP) schemes is intended this type of unequal erasure protection (UXP) schemes is intended
to cope with the rapidly varying channel conditions on wireless to cope with the rapidly varying channel conditions on wireless
access links to the Internet backbone. Nevertheless, backward access links to the Internet backbone. Furthermore, protection of
compatibility to currently standardized non-progressive non-progressive multimedia streams is ensured, since equal
multimedia codecs is ensured, since equal erasure protection erasure protection (EXP) represents a subset of generic UXP. By
(EXP) represents a subset of generic UXP. By applying applying interleaving and RS codes a payload format is defined,
interleaving and RS codes a payload format is defined, which can which can be easily integrated into the existing framework for
be easily integrated into the existing framework for RTP. RTP.
Table of Contents
1. Introduction.................................................2
2. Conventions used in this Document............................3
3. Reed-Solomon Codes...........................................6
4. Progressive Source Coding....................................7
5. General Structure of UXP Schemes.............................8
Liebl,Wagner,Pandel,Weng [Page1]
6. RTP payload structure.......................................13
7. Indication of UXP in SDP....................................20
8. Security Considerations.....................................21
9. Application Statement.......................................21
10. Intellectual Property Considerations.......................23
11. References.................................................23
12. Acknowledgments............................................24
13. Author's Addresses.........................................24
1. Introduction 1. Introduction
Due to the increasing popularity of high-quality multimedia Due to the increasing popularity of high-quality multimedia
applications over the Internet and the high level of public applications over the Internet and the high level of public
acceptance of existing mobile communication systems, there is a acceptance of existing mobile communication systems, there is a
strong demand for a future combination of these two techniques: strong demand for a future combination of these two techniques:
One possible scenario consists of an integrated communication One possible scenario consists of an integrated communication
environment, where users can set up multimedia connections environment, where users can set up multimedia connections
anytime and anywhere via radio access links to the Internet. anytime and anywhere via radio access links to the Internet.
For this reason, several packet-oriented transmission modes like
Liebl,Wagner,Pandel,Weng [Page1] EGPRS (Enhanced General Packet Radio Service) or UMTS (Universal
For this reason, several packet-oriented transmission modes have Mobile Telecommunications System) can be used, which are mostly
been proposed for next generation wireless standards like EGPRS based on the same principle: Long message blocks, i.e. IP
(Enhanced General Packet Radio Service) or UMTS (Universal Mobile packets, that enter the wireless part of the network are split up
Telecommunications System), which are mostly based on the same into segments of desired length, which can be multiplexed onto
principle: Long message blocks, i.e. IP packets, that enter the link layer packets of fixed size. The latter are then transmitted
wireless part of the network are split up into segments of sequentially over the wireless link, reassembled, and passed on
desired length, which can be multiplexed onto link layer packets to the next network element.
of fixed size. The latter are then transmitted sequentially over
the wireless link, reassembled, and passed on to the next network
element.
However, compared to the rather benign channel characteristics on However, compared to the rather benign channel characteristics on
today's fixed networks, wireless links suffer from severe fading, today's fixed networks, wireless links suffer from severe fading,
noise, and interference conditions in general, thus resulting in noise, and interference conditions in general, thus resulting in
a comparably high residual bit error rate after detection and a comparably high residual bit error rate after detection and
decoding. By use of efficient CRC-mechanisms, these bit errors decoding. By use of efficient CRC-mechanisms, these bit errors
are usually detected with very high probability, and every are usually detected with very high probability, and every
corrupted segment, i.e. which contains at least one erroneous corrupted segment, i.e. which contains at least one erroneous
bit, is discarded to prevent error propagation through the bit, is discarded to prevent error propagation through the
network. But if only one single segment is missing at the network. But if only one single segment is missing at the
reassemble stage, the upper layer IP packet cannot be reassemble stage, the upper layer IP packet cannot be
reconstructed anymore. The result is a significant increase in reconstructed anymore. The result is a significant increase in
packet loss rate at IP level. packet loss rate at IP level.
Since most multimedia applications can only recover from a very Since most multimedia applications can only recover from a very
limited number of lost message blocks, it is vitally necessary to limited number of lost IP packets, it is vitally necessary to
keep packet loss at IP level within a certain acceptable range keep packet loss at IP level within a certain acceptable range
depending on the individual quality-of-service requirements. depending on the individual quality-of-service requirements.
However, due to the delay constraints typically imposed by most However, due to the delay constraints typically imposed by most
audio or video codecs, the use of ARQ-schemes is often prohibited audio or video codecs, the use of ARQ-schemes is often prohibited
both at link level and at transport level. In addition, both at link level and at transport level. In addition,
retransmission strategies cannot be applied to any broadcast or retransmission strategies cannot be applied to any broadcast or
multicast scenarios. Thus, forward erasure correction strategies multicast scenarios. Thus, forward erasure correction strategies
have to be considered, which provide a simple means to have to be considered, which provide a simple means to
reconstruct the content of lost packets at the receiver from the reconstruct the content of lost packets at the receiver from the
redundancy that has been spread out over a certain number of redundancy that has been spread out over a certain number of
subsequent packets. consecutive packets.
There already exist some previous studies and proposals regarding There already exist some previous studies and proposals regarding
erasure-resilient packet transmission[1,8]. Since most of them erasure-resilient packet transmission[1,8]. Since most of them
are based on the assumption that all parts in a message block are are based on the assumption that all parts in a message block are
equally important to the receiver, i.e. the respective equally important to the receiver, i.e. the respective
application cannot operate on partly complete blocks, they were application cannot operate on partly complete blocks, they were
optimized with respect to assigning equal erasure protection over optimized with respect to assigning equal erasure protection over
the whole message block. However, recent developments both in the whole message block. However, recent developments both in
audio and video coding have introduced the notion of audio and video coding have introduced the notion of
progressively encoded media streams, for which unequal erasure progressively encoded media streams, for which unequal erasure
protection strategies seem to be more promising, as it will be protection strategies seem to be more promising, as it will be
skipping to change at page 9, line 5 skipping to change at page 9, line 27
| +-+-+-+-+-+-+-+-+-+ \/ | | +-+-+-+-+-+-+-+-+-+ \/ |
| | . | . | | | . | . |
| + . + . | | + . + . |
| | . | . | | | . | . |
| +-+-+-+-+-+-+-+-+-+ /\ | | +-+-+-+-+-+-+-+-+-+ /\ |
| | data TSB #z | | L_d(z) octets | | | data TSB #z | | L_d(z) octets |
\/ +-+-+-+-+-+-+-+-+-+ \/ \/ \/ +-+-+-+-+-+-+-+-+-+ \/ \/
<-----------------> <----------------->
n packets n packets
Fig. 2: General structure of a TB Fig. 2: General structure of a TB
Since the UXP procedure is mainly applied to the data TSBs, it Since the UXP procedure is mainly applied to the data TSBs, it
will be described next, whereas the content and syntax of the will be described next, whereas the content and syntax of the
signaling TSB will be defined in section 6.4. signaling TSB will be defined in section 6.4.
For means of simplification, only one single data TSB will be For means of simplification, only one single data TSB will be
assumed throughout the following explanation of the encoding and assumed throughout the following explanation of the encoding and
decoding procedure. However, an extension to more than one data decoding procedure. However, an extension to more than one data
TSB per TB is straightforward, and will be shown in section 6.5. TSB per TB is straightforward, and will be shown in section 6.5.
As depicted in Fig. 3, the rows of a transmission sub block shall As depicted in Fig. 3, the rows of a transmission sub block shall
be partitioned into T+1 different classes EPC_i, where i=0...T, be assembled into T+1 different classes EPC_i, where i=0...T,
such that each class contains exactly R_i=|EPC_i| consecutive such that each class contains exactly R_i=|EPC_i| consecutive
rows of the matrix, where the R_i have to satisfy the following rows of the matrix, where the R_i have to satisfy the following
relationship: relationship:
R_0+R_1+...+R_T=L_d R_0+R_1+...+R_T=L_d
Data Transmission Sub Block (data TSB) Data Transmission Sub Block (data TSB)
T T
<-------> <------->
/\ +-+-+-+-+-+-+-+-+-+ /\ /\ +-+-+-+-+-+-+-+-+-+ /\
| |&|&|&|&|&|*|*|*|*| | | |&|&|&|&|&|*|*|*|*| |
| +-+-+-+-+-+-+-+-+-+ | R_T=3 | +-+-+-+-+-+-+-+-+-+ | R_T=3
| |&|&|&|&|&|*|*|*|*| | | |&|&|&|&|&|*|*|*|*| |
| +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+ |
L_d octets | |&|&|&|&|&|*|*|*|*| \/ L_d octets | |&|&|&|&|&|*|*|*|*| \/
per packet | +-+-+-+-+-+-+-+-+-+ /\ per packet | +-+-+-+-+-+-+-+-+-+ /\
skipping to change at page 10, line 49 skipping to change at page 11, line 28
a) All available info octet positions in the data TSB have to be a) All available info octet positions in the data TSB have to be
completely filled. If the info stream is too short for a desired completely filled. If the info stream is too short for a desired
profile, media stuffing may be applied to the empty info octet profile, media stuffing may be applied to the empty info octet
positions at the end of the data TSB by appending a sufficient positions at the end of the data TSB by appending a sufficient
number of octets (with arbitrary value, e.g. 0x00). The actual number of octets (with arbitrary value, e.g. 0x00). The actual
number of stuffing symbols per data TSB is then signaled via the number of stuffing symbols per data TSB is then signaled via the
respective stuffing indicator (see Sect. 6.4.). However, before respective stuffing indicator (see Sect. 6.4.). However, before
resorting to any stuffing, it should be checked whether it is resorting to any stuffing, it should be checked whether it is
possible to strengthen the protection of certain rows instead, possible to strengthen the protection of certain rows instead,
thus improving the overall robustness of the decoding process. thus improving the overall robustness of the decoding process.
b) The info stream should be fully contained within the data TSB b) The info stream SHOULD be fully contained within the data TSB
(unless cutting it off at a specific point is explicitly allowed (unless cutting it off at a specific point is explicitly allowed
by the properties of the used media codec). by the properties of the info stream).
c) The number of required descriptors and stuffing indicators c) The number of required descriptors and stuffing indicators
(see section 6.4.) to signal the profile shall not exceed the (see section 6.4.) to signal the profile SHALL NOT exceed the
space initially reserved for them in the signaling TSB. space initially reserved for them in the signaling TSB.
Constraints a) and b) should be already incorporated in the Constraints a) and b) should be already incorporated in the
optimization algorithm. However, if constraint c) is not met, the optimization algorithm. However, if constraint c) is not met, the
data TSB has to be reduced by one row in favor of the signaling data TSB has to be reduced by one row in favor of the signaling
TSB to accommodate more space for the descriptors and stuffing TSB to accommodate more space for the descriptors and stuffing
indicators, i.e. steps 2-5 have to be repeated until a valid indicators, i.e. steps 2-5 have to be repeated until a valid
redundancy profile has been obtained. redundancy profile has been obtained.
6.) For each nonempty class EPC_i, i=T...0, in the data TSB, the 6.) For each nonempty class EPC_i, i=T...0, in the data TSB, the
following steps have to be performed: following steps have to be performed:
a) All rows of this specific class shall be filled from left to a) All rows of this specific class SHALL be filled from left to
right and top to bottom with data octets of the info stream. right and top to bottom with data octets of the info stream.
b) For each row in the class, the required i parity-check octets b) For each row in the class, the required i parity-check octets
are computed from the same set of codewords of an (n,n-i) RS are computed from the same set of codewords of an (n,n-i) RS
code, and filled in the empty positions at the end of each row. code, and filled in the empty positions at the end of each row.
Thus, every row in the class constitutes a valid codeword of the Thus, every row in the class constitutes a valid codeword of the
chosen RS code. chosen RS code.
7.) After having filled the whole data TSB with information and 7.) After having filled the whole data TSB with information and
parity octets, the redundancy profile is mapped to the signaling parity octets, the redundancy profile is mapped to the signaling
TSB as described in section 6.4. TSB as described in section 6.4.
8.) Each column of the resulting TB is now read out octet-wise 8.) Each column of the resulting TB is now read out octet-wise
from top to bottom and, together with the respective UXP header from top to bottom and, together with the respective UXP header
(see section 6.2.) in front, is mapped onto the payload section (see section 6.2.) in front, is mapped onto the payload section
of one and only one RTP packet. of one and only one RTP packet.
9.) The n resulting RTP packets shall be transmitted
9.) The n resulting RTP packets SHALL be transmitted
consecutively to the remote host, starting with the leftmost one. consecutively to the remote host, starting with the leftmost one.
10.) At the corresponding protocol entity at the remote host, the 10.) At the corresponding protocol entity at the remote host, the
payload (without the UXP header) of all successfully received RTP payload (without the UXP header) of all successfully received RTP
packets belonging to the same sending TB shall be filled into a packets belonging to the same sending TB SHALL be filled into a
similar receiving TB column-wise from top to bottom and left to similar receiving TB column-wise from top to bottom and left to
right. right.
11.) For every erased packet of a received TB, the respective 11.) For every erased packet of a received TB, the respective
column in the TB shall be filled with a suitable erasure marker. column in the TB shall be filled with a suitable erasure marker.
12.) Before any other operations can be performed, the redundancy 12.) Before any other operations can be performed, the redundancy
profile has to be restored from the signaling TSB according to profile has to be restored from the signaling TSB according to
the procedure defined in Sect. 6.4.. If the attempt fails because the procedure defined in Sect. 6.4.. If the attempt fails because
of too many lost packets, the whole TB shall be discarded and the of too many lost packets, the whole TB SHALL be discarded and the
receiving entity should wait for the next incoming TB. receiving entity should wait for the next incoming TB.
13.) If the attempt to recover the redundancy profile has been 13.) If the attempt to recover the redundancy profile has been
successful, a decoding operation shall be performed for each row successful, a decoding operation shall be performed for each row
of the data TSB by applying any suitable algorithm for erasure of the data TSB by applying any suitable algorithm for erasure
decoding. decoding.
14.) For all rows of the data TSB for which the decoding 14.) For all rows of the data TSB for which the decoding
operation has been successful, the reconstructed data octets are operation has been successful, the reconstructed data octets are
read out from left to right and top to bottom, and appended to read out from left to right and top to bottom, and appended to
the reconstructed version of the info stream. the reconstructed version of the info stream.
skipping to change at page 12, line 27 skipping to change at page 13, line 4
profile for a data TSB of size (L_d x n) shall be denoted by a profile for a data TSB of size (L_d x n) shall be denoted by a
so-called erasure protection vector EPV of length (T+1), where so-called erasure protection vector EPV of length (T+1), where
EPV:=(R_0,R_1,...,R_(T-1),R_T) EPV:=(R_0,R_1,...,R_(T-1),R_T)
From the above definition, it is easy to realize that the trivial From the above definition, it is easy to realize that the trivial
cases of no erasure protection and EXP are a subset of UXP: cases of no erasure protection and EXP are a subset of UXP:
a) no erasure protection at all: all application data is mapped a) no erasure protection at all: all application data is mapped
onto onto
class EPC_0, i.e. EPV=(L_d,0,0,...,0). class EPC_0, i.e. EPV=(L_d,0,0,...,0).
b) EXP: all application data is mapped onto class EPC_T, i.e. b) EXP: all application data is mapped onto class EPC_T, i.e.
EPV=(0,0,...,0,R_T=L_d). EPV=(0,0,...,0,R_T=L_d).
Hence, backward compatibility to currently standardized non-
progressive multimedia codecs is definitely achieved. Hence, the UXP payload format also can be used with info streams
which are non progressive.
6. RTP payload structure 6. RTP payload structure
This section is organized as follows. First, the specific This section is organized as follows. First, the specific
settings in the RTP header are shown. Next, the RTP payload settings in the RTP header are shown. Next, the RTP payload
header for UXP (the so-called UXP header) is specified. After header for UXP (the so-called UXP header) is specified. After
that, the structure of the bitstream which is protected by UXP, that, the structure of the bitstream which is protected by UXP,
the so-called info stream, is discussed. Finally, the in-band the so-called info stream, is discussed. Finally, the in-band
signaling of the erasure protection vector is introduced. signaling of the erasure protection vector is introduced.
For every packet, the UXP payload is formed by reading out a For every packet, the UXP payload is formed by reading out a
skipping to change at page 19, line 42 skipping to change at page 20, line 21
TSB #u and data TSB #v, where v=u+1: TSB #u and data TSB #v, where v=u+1:
Let EPVu=(Au_0,Au_1,...) and EPVv=(Av_0, Av_1,...) be the Let EPVu=(Au_0,Au_1,...) and EPVv=(Av_0, Av_1,...) be the
corresponding erasure protection vectors and DPu and DPv the corresponding erasure protection vectors and DPu and DPv the
corresponding descriptors created according to Sect. 6.4. (with corresponding descriptors created according to Sect. 6.4. (with
stuffing). Let w be the smallest index for which Au_w >0. Let x stuffing). Let w be the smallest index for which Au_w >0. Let x
be the largest index for which Av_x >0. The resulting descriptor be the largest index for which Av_x >0. The resulting descriptor
can be created by concatenation of DPu and DPv where the first can be created by concatenation of DPu and DPv where the first
descriptor of DPv should be changed as follows: descriptor of DPv should be changed as follows:
The second half byte is defined by Au_w-Av_x. The second half byte is defined by Au_w-Av_x.
7. Security Considerations 7. Indication of UXP in SDP
From the discussion in Sect. 6.3 , we know that UXP encapsulates
and protects the info stream. The info stream consists usually of
a regular RTP-Payload format, e.g. RFC 3016.
There is no static payload type assignment for UXP, so dynamic
payload type numbers MUST be used. The binding to the number is
indicated by an rtpmap attribute. The name used in this binding
is
"UXP". The payload type number of UXP is indicated in the "m"
line of the
media as well as the payload type of the info-stream.
A sample indication of UXP in SDP is as follows:
m = video 8000 RTP/AVP 98 99
a = rtpmap:98 UXP/90000
a = rtpmap:99 MP4V-ES/90000
Here, PT 98 indicates that the payload consists of UXP with the
corresponding info stream "MP4V-ES". Alternatively, PT 99 can be
used which indicates "MP4V-ES" without UXP.
Since UXP is generic, several payload types can be protected. The
lines
m = video 8000 RTP/AVP 98 99 100
a = rtpmap:98 UXP/90000
a = rtpmap:99 MP4V-ES/90000
a = rtpmap:100 H263-1998/90000
mean that UXP can be used with either "MP4V-ES" or "H263-1998" as
info stream (indicated by PT 98 in the RTP-Header and either
block PT=99 or block PT=100 in the UXP-Header). Alternatively,
PT=99 or PT=100 in the RTP-Header means the use of "MP4V-ES" or
"H263-1998" without UXP.
As described in Sect. 6.4., the parameter P has the default value
P=ceil(n/2), if not otherwise stated. The parameter P MAY be
specified explicitly by means of SDP:
a = fmtp:98 UXP-prof: f
where f is a number in the interval (1,0) and specifies P by
P=ceil(n*f). For example, if we set f=0.5,
a = fmtp:98 UXP-prof: 0.5
we get the default value for P, since P=ceil(n/2).
8. Security Considerations
The payload of the RTP-packets consists of an interleaved media The payload of the RTP-packets consists of an interleaved media
and parity stream. Therefore, it is reasonable to encrypt the and parity stream. Therefore, it is reasonable to encrypt the
resulting stream with one key rather than using different keys resulting stream with one key rather than using different keys
for media and parity data. It should also be noted that for media and parity data. It should also be noted that
encryption of the media data without encryption of the parity encryption of the media data without encryption of the parity
data could enable known-plaintext attacks. data could enable known-plaintext attacks.
The overall proportion between parity octets and info octets The overall proportion between parity octets and info octets
should be chosen carefully if the packet loss is due to network should be chosen carefully if the packet loss is due to network
congestion. If the proportion of parity octets per TB is congestion. If the proportion of parity octets per TB is
increased in this case, it could lead to increasing network increased in this case, it could lead to increasing network
congestion. Therefore, the proportion between parity octets and congestion. Therefore, the proportion between parity octets and
info octets per TB MUST NOT be increased as packet loss increases info octets per TB MUST NOT be increased as packet loss increases
due to network congestion. due to network congestion.
The overall ratio between parity and info octets MUST NOT be The overall ratio between parity and info octets MUST NOT be
higher than 1:1, i.e. the absolute bitrate spent for redundancy higher than 1:1, i.e. the absolute bitrate spent for redundancy
must not be larger than the bitrate required for transmission of must not be larger than the bitrate required for transmission of
multimedia data itself. multimedia data itself.
8. Application Statement 9. Application Statement
There are currently two different schemes proposed for unequal There are currently two different schemes proposed for unequal
error protection in the IETF-AVT: Unequal Level Protection (ULP) error protection in the IETF-AVT: Unequal Level Protection (ULP)
and Unequal Erasure Protection (UXP). and Unequal Erasure Protection (UXP).
Although both methods seem to address the same problem, the Although both methods seem to address the same problem, the
proposed solutions differ in many respects. This section tries to proposed solutions differ in many respects. This section tries to
describe possible application scenarios and to show the strengths describe possible application scenarios and to show the strengths
and weaknesses of both approaches. and weaknesses of both approaches.
The main difference between both approaches is that while ULP The main difference between both approaches is that while ULP
preserves the structure of the packets which have to be protected preserves the structure of the packets which have to be protected
and provides the redundancy in extra packets, UXP interleaves the and provides the redundancy in extra packets, UXP interleaves the
skipping to change at page 21, line 27 skipping to change at page 23, line 16
right away. However, a significant delay is introduced, if right away. However, a significant delay is introduced, if
packets are corrupted, because in this case one has to wait for packets are corrupted, because in this case one has to wait for
several redundancy packets. Thus, the delay is in general several redundancy packets. Thus, the delay is in general
dependent on the actual ULP-FEC-packet scheme and cannot be dependent on the actual ULP-FEC-packet scheme and cannot be
considered in advance during the system design phase. considered in advance during the system design phase.
Finally, we want to point out that UXP uses RS codes which are Finally, we want to point out that UXP uses RS codes which are
known known
to be the most efficient type of block codes in terms of erasure to be the most efficient type of block codes in terms of erasure
correction capability. correction capability.
9. Intellectual Property Considerations 10. Intellectual Property Considerations
Siemens AG has filed patent applications that might possibly have Siemens AG has filed patent applications that might possibly have
technical relations to this contribution. technical relations to this contribution.
On IPR related issues, Siemens AG refers to the Siemens Statement On IPR related issues, Siemens AG refers to the Siemens Statement
on Patent Licensing, see http://www.ietf.org/ietf/IPR/SIEMENS- on Patent Licensing, see http://www.ietf.org/ietf/IPR/SIEMENS-
General. General.
10. References 11. References
[1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for [1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", Request for Comments 2733, Generic Forward Error Correction", Request for Comments 2733,
Internet Engineering Task Force, Dec. 1999. Internet Engineering Task Force, Dec. 1999.
[2] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan, [2] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan,
"Priority encoding transmission", IEEE Trans. Inform. Theory, "Priority encoding transmission", IEEE Trans. Inform. Theory,
vol. 42, no. 6, pp. 1737-1744, Nov. 1996. vol. 42, no. 6, pp. 1737-1744, Nov. 1996.
[3] Shu Lin and Daniel J. Costello, Error Control Coding: [3] Shu Lin and Daniel J. Costello, Error Control Coding:
Fundamentals and Applications, Prentice-Hall, Inc., Englewood Fundamentals and Applications, Prentice-Hall, Inc., Englewood
Cliffs, N.J., 1983. Cliffs, N.J., 1983.
[4] W. Li: "Streaming video profile in MPEG-4", IEEE Trans. on [4] W. Li: "Streaming video profile in MPEG-4", IEEE Trans. on
skipping to change at page 22, line 16 skipping to change at page 24, line 4
coding for lossy packet networks - a principle approach", Tech. coding for lossy packet networks - a principle approach", Tech.
Rep., ITU-T SG16, Q.15, Q15-I36, Red Bank, N.J., Oct. 1999. Rep., ITU-T SG16, Q.15, Q15-I36, Red Bank, N.J., Oct. 1999.
[7] Guenther Liebl, "Modeling, theoretical analysis, and coding [7] Guenther Liebl, "Modeling, theoretical analysis, and coding
for wireless packet erasure channels", Diploma Thesis, Inst. for for wireless packet erasure channels", Diploma Thesis, Inst. for
Communications Engineering, Munich University of Technology, Communications Engineering, Munich University of Technology,
1999. 1999.
[8] U. Horn, K. Stuhlmuller, M. Link, and B. Girod, "Robust [8] U. Horn, K. Stuhlmuller, M. Link, and B. Girod, "Robust
Internet video transmission based on scalable coding and unequal Internet video transmission based on scalable coding and unequal
error protection", Image Com., vol. 15, no. 1-2, pp. 77-94, Sep. error protection", Image Com., vol. 15, no. 1-2, pp. 77-94, Sep.
1999. 1999.
[9] S. Wenger, "H.26L over IP: The IP-Network Adaptation Layer", [9] S. Wenger, "H.26L over IP: The IP-Network Adaptation Layer",
Packet Video 2002, Pittsburgh, Pennsylvania, USA, April 24- Packet Video 2002, Pittsburgh, Pennsylvania, USA, April 24-
26,2002. 26,2002.
11. Acknowledgments 12. Acknowledgments
Many thanks to Philippe Gentric, Stephen Casner, and Hermann Many thanks to Philippe Gentric, Stephen Casner, and Hermann
Hellwagner for helpful comments and improvements. The authors Hellwagner for helpful comments and improvements. The authors
would like to thank Thomas Stockhammer who came up with the would like to thank Thomas Stockhammer who came up with the
original idea of UXP. Also, the help of Gero Baese, Frank original idea of UXP. Also, the help of Gero Baese, Frank
Burkert, and Minh Ha Nguyen for the development of UXP is well Burkert, and Minh Ha Nguyen for the development of UXP is well
acknowledged. acknowledged.
12. Author's Addresses 13. Author's Addresses
Guenther Liebl Guenther Liebl
Institute for Communications Engineering (LNT) Institute for Communications Engineering (LNT)
Munich University of Technology Munich University of Technology
D-80290 Munich D-80290 Munich
Germany Germany
Email: {liebl}@lnt.e-technik.tu-muenchen.de Email: {liebl}@lnt.e-technik.tu-muenchen.de
Marcel Wagner, Juergen Pandel, Wenrong Weng Marcel Wagner, Juergen Pandel, Wenrong Weng
Siemens AG - Corporate Technology CT IC 2 Siemens AG - Corporate Technology CT IC 2
D-81730 Munich D-81730 Munich
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/