draft-ietf-avt-uxp-05.txt   draft-ietf-avt-uxp-06.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-05.txt Document: draft-ietf-avt-uxp-06.txt
March 2003 M. Wagner, J. Pandel, October 2003 M. Wagner, J. Pandel,
W. Weng W. Weng
Expires: September 2003 Siemens AG, Munich Expires: April 2004 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 ?
1. Introduction.................................................2 1. Introduction.................................................2
2. Conventions used in this Document............................3 2. Conventions used in this Document............................3
3. Reed-Solomon Codes...........................................6 3. Reed-Solomon Codes...........................................6
4. Progressive Source Coding....................................7 4. Progressive Source Coding....................................7
5. General Structure of UXP Schemes.............................8 5. General Structure of UXP Schemes.............................8
Liebl,Wagner,Pandel,Weng [Page1] Liebl,Wagner,Pandel,Weng [Page1]
6. RTP payload structure.......................................13 6. RTP payload structure.......................................13
7. Indication of UXP in SDP....................................20 7. Indication of UXP in SDP....................................20
8. Security Considerations.....................................21 8. Security Considerations.....................................21
9. Application Statement.......................................21 9. Application Statement.......................................22
10. Intellectual Property Considerations.......................23 10. Intellectual Property Considerations.......................23
11. References.................................................23 11. References.................................................23
12. Acknowledgments............................................24 12. Acknowledgments............................................24
13. Author's Addresses.........................................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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
complex with respect to the gain in performance. Finally, in [1] complex with respect to the gain in performance. Finally, in [1]
it is assumed that consecutive RTP packets can have variable it is assumed that consecutive RTP packets can have variable
length, which would cause significant segmentation overhead at length, which would cause significant segmentation overhead at
the link layer of almost all wireless systems. the link layer of almost all wireless systems.
This document defines a payload format for RTP, such that This document defines a payload format for RTP, such that
different elements in a progressively encoded multimedia stream different elements in a progressively encoded multimedia stream
can be protected against packet erasures according to their can be protected against packet erasures according to their
respective quality-of-service requirement. The general principle, respective quality-of-service requirement. The general principle,
including the use of Reed-Solomon codes together with an including the use of Reed-Solomon codes together with an
appropriate interleaving scheme for adding redundancy, follows appropriate interleaving scheme for adding redundancy, follows
the ideas already presented in [2], but allows for finer the ideas already presented in [3], but allows for finer
granularity in the structure of the progressive media stream. The granularity in the structure of the progressive media stream. The
proposed scheme is generic in the way that it (1) is independent proposed scheme is generic in the way that it (1) is independent
of the type of media stream, be it audio or video, and (2) can be of the type of media stream, be it audio or video, and (2) can be
adapted to varying transmission quality very quickly by use of adapted to varying transmission quality very quickly by use of
inband-signaling. inband-signaling.
2. Conventions used in this Document 2. Conventions used in this Document
The following terms are used throughout this document: The following terms are used throughout this document:
1.) Segment: denotes a link layer transport unit. 1.) Segment: denotes a link layer transport unit.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC-2119. RFC-2119.
3. Reed-Solomon Codes 3. Reed-Solomon Codes
Reed-Solomon (RS) codes are a special class of linear nonbinary Reed-Solomon (RS) codes are a special class of linear nonbinary
block codes, which are known to offer maximum erasure correction block codes, which are known to offer maximum erasure correction
capability with minimum amount of redundancy. capability with minimum amount of redundancy.
An arbitrary t-erasure-correcting (n,k) RS code defined over An arbitrary t-erasure-correcting (n,k) RS code defined over
Galois field GF(q) has the following parameters [3]: Galois field GF(q) has the following parameters [2]:
- Block length: n=q-1 - Block length: n=q-1
- No. of information symbols in a codeword: k - No. of information symbols in a codeword: k
- No. of parity-check symbols in a codeword: n-k=t - No. of parity-check symbols in a codeword: n-k=t
- Minimum distance: d=t+1 - Minimum distance: d=t+1
In what follows, only systematic RS codes over GF(2^8) shall be In what follows, only systematic RS codes over GF(2^8) shall be
considered, i.e. the symbols of interest can be directly related considered, i.e. the symbols of interest can be directly related
to a tuple of eight bits, which is commonly called an octet in to a tuple of eight bits, which is commonly called an octet in
packet transmission. The principle structure of a codeword is packet transmission. The principle structure of a codeword is
shown in Fig. 1. shown in Fig. 1.
skipping to change at page 13, line 46 skipping to change at page 14, line 5
its value is 0. its value is 0.
All other fields in the RTP header are set to those values All other fields in the RTP header are set to those values
proposed for regular multimedia transmission using the RTP-format proposed for regular multimedia transmission using the RTP-format
of the media stream which is protected by UXP, e.g for MPEG-4 of the media stream which is protected by UXP, e.g for MPEG-4
Visual as specified in RFC 3016. Visual as specified in RFC 3016.
6.2. Structure of the UXP Header 6.2. Structure of the UXP Header
The UXP header shall consist of 2 octets, and is shown in Fig. 4: The UXP header shall consist of 2 octets, and is shown in Fig. 4:
0 1 1 1 1 1 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| block PT | block length n| |X| block PT | block length n|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 4: Proposed UXP header Fig. 4: Proposed UXP header
The fields in the UXP header are defined as follows: The fields in the UXP header are defined as follows:
- X (bit 0): extension bit, reserved for future enhancements, - X (bit 0): extension bit, reserved for future enhancements,
currently not in use -> default value: 0 currently not in use -> default value: 0
- block PT (bits 1-7): regular RTP payload type to indicate the - block PT (bits 1-7): regular RTP payload type to indicate the
skipping to change at page 16, line 42 skipping to change at page 16, line 45
additional control traffic, or prevents quick changes of the additional control traffic, or prevents quick changes of the
profile between successive TBs, an in-band signaling procedure is profile between successive TBs, an in-band signaling procedure is
desired. desired.
Since without knowledge of the correct redundancy profile, the Since without knowledge of the correct redundancy profile, the
decoding process cannot be applied to any of the erasure decoding process cannot be applied to any of the erasure
protection classes, the redundancy profile has to be protected at protection classes, the redundancy profile has to be protected at
least as strongly as the most important element in the info least as strongly as the most important element in the info
stream. Therefore, an additional class EPC_P is used in the stream. Therefore, an additional class EPC_P is used in the
signaling TSB, where the number of parity symbols is by default signaling TSB, where the number of parity symbols is by default
set to the following value: set to the following value:
P=ceil(n/2) P=ceil(n/2.0)
Hence, up to 50% of the RTP packets can be lost, before the Hence, up to 50% of the RTP packets can be lost, before the
redundancy profile cannot be recovered anymore. This seems to be redundancy profile cannot be recovered anymore. This seems to be
a reasonable value for the lowest point of operation over a lossy a reasonable value for the lowest point of operation over a lossy
link. Alternatively, P may be explicitly signaled during session link. Alternatively, P may be explicitly signaled during session
setup by means of SDP or H.245 protocol. setup by means of SDP or H.245 protocol.
Consequently, since all other classes must have equal or less Consequently, since all other classes must have equal or less
erasure protection capability, the maximum allowable value for erasure protection capability, the maximum allowable value for
class EPC_T in the data TSB is now limited to T<=P. class EPC_T in the data TSB is now limited to T<=P.
The signaling of the erasure protection vector is accomplished by The signaling of the erasure protection vector is accomplished by
means of descriptors. In the following we describe an efficient means of descriptors. In the following we describe an efficient
encoding scheme for the descriptors. encoding scheme for the descriptors.
For each class EPC_i with R_i>0, there is a descriptor DP_i For each class EPC_i with R_i>0, there is a descriptor DP_i
providing information about the size of class EPC_i (i.e. the providing information about the size of class EPC_i (i.e. the
value of R_i) and establishing a relationship between the erasure value of R_i) and establishing a relationship between the erasure
protection of class EPC_i and that of the class EPC_(i+j), where protection of class EPC_i and that of the class EPC_(i+j), where
j>0 and j is the smallest value for which R_(i+j)>0 is true. A j>0 and j is the smallest value for which R_(i+j)>0 is true. A
descriptor DP_i is mapped onto one octet, which is sub-divided descriptor DP_i is mapped onto one octet, which is sub-divided
into two half-octets (i.e. the higher and the lower four bits). into two half-octets (i.e. the higher and the lower four bits).
The first half-octet is of type unsigned and contains the 4-bit The first half-octet is of type unsigned and contains the 4-bit
representation of the decimal value R_i. The second half-octet is representation of the decimal value R_i. The second half-octet is
of type signed and contains the difference in erasure protection of type signed and contains the difference in erasure protection
skipping to change at page 21, line 4 skipping to change at page 21, line 6
Here, PT 98 indicates that the payload consists of UXP with the Here, PT 98 indicates that the payload consists of UXP with the
corresponding info stream "MP4V-ES". Alternatively, PT 99 can be corresponding info stream "MP4V-ES". Alternatively, PT 99 can be
used which indicates "MP4V-ES" without UXP. used which indicates "MP4V-ES" without UXP.
Since UXP is generic, several payload types can be protected. The Since UXP is generic, several payload types can be protected. The
lines lines
m = video 8000 RTP/AVP 98 99 100 m = video 8000 RTP/AVP 98 99 100
a = rtpmap:98 UXP/90000 a = rtpmap:98 UXP/90000
a = rtpmap:99 MP4V-ES/90000 a = rtpmap:99 MP4V-ES/90000
a = rtpmap:100 H263-1998/90000 a = rtpmap:100 H263-1998/90000
mean that UXP can be used with either "MP4V-ES" or "H263-1998" as 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 info stream (indicated by PT 98 in the RTP-Header and either
block PT=99 or block PT=100 in the UXP-Header). Alternatively, 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 PT=99 or PT=100 in the RTP-Header means the use of "MP4V-ES" or
"H263-1998" without UXP. "H263-1998" without UXP.
As described in Sect. 6.4., the parameter P has the default value 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 P=ceil(n/2.0), if not otherwise stated. The parameter P MAY be
specified explicitly by means of SDP: specified explicitly by means of SDP:
a = fmtp:98 UXP-prof: f a = fmtp:98 UXP-prof: fvalue
where f is a number in the interval (1,0) and specifies P by where fvalue is a floating point number in the interval (0 <
P=ceil(n*f). For example, if we set f=0.5, fvalue <1) and specifies P by P=ceil(n*fvalue). For example, if
we set fvalue=0.5,
a = fmtp:98 UXP-prof: 0.5 a = fmtp:98 UXP-prof: 0.5
we get the default value for P, since P=ceil(n/2). we get the default value for P, since P=ceil(n/2.0).
The ABNF for fvalue according to RFC 2234 is
fvalue = "0" "." 1*2DIGIT
8. Security Considerations 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
skipping to change at page 23, line 24 skipping to change at page 23, line 28
correction capability. correction capability.
10. 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.
11. References 11. References
Normative 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] Shu Lin and Daniel J. Costello, Error Control Coding:
"Priority encoding transmission", IEEE Trans. Inform. Theory,
vol. 42, no. 6, pp. 1737-1744, Nov. 1996.
[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.
Informative References
[3] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan,
"Priority encoding transmission", IEEE Trans. Inform. Theory,
vol. 42, no. 6, pp. 1737-1744, Nov. 1996.
[4] W. Li: "Streaming video profile in MPEG-4", IEEE Trans. on [4] W. Li: "Streaming video profile in MPEG-4", IEEE Trans. on
Circuits and Systems for Video Technology, Vol. 11, no. 3, 301- Circuits and Systems for Video Technology, Vol. 11, no. 3, 301-
317, March 2001. 317, March 2001.
[5] G. Blaettermann, G. Heising, and D. Marpe: "A Quality [5] G. Blaettermann, G. Heising, and D. Marpe: "A Quality
Scalable Mode for H.26L", ITU-T SG16, Q.15, Q15-J24, Osaka, May Scalable Mode for H.26L", ITU-T SG16, Q.15, Q15-J24, Osaka, May
2000. 2000.
[6] F. Burkert, T. Stockhammer, and J. Pandel, "Progressive A/V [6] F. Burkert, T. Stockhammer, and J. Pandel, "Progressive A/V
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.
12. 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.
 End of changes. 

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