home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-perkins-rtp-redundancy-02.txt < prev    next >
Text File  |  1997-01-06  |  19KB  |  518 lines
  1.  
  2.  
  3. INTERNET-DRAFT                               3 January 1997
  4.                                        Expire in six months
  5.  
  6.                                               Colin Perkins
  7.                                             Isidor Kouvelas
  8.                                               Vicky Hardman
  9.                                   University College London
  10.  
  11.                                                Mark Handley
  12.                                                         ISI
  13.  
  14.                                      Jean-Chrysostome Bolot
  15.                                          Andres Vega-Garcia
  16.                                         Sacha Fosse-Parisis
  17.                                      INRIA Sophia Antipolis
  18.  
  19.  
  20.  
  21.              RTP Payload for Redundant Audio Data
  22.               draft-perkins-rtp-redundancy-02.txt
  23.  
  24.  
  25. Status of this Memo
  26.  
  27.  
  28. This document is an Internet-Draft.  Internet-Drafts are working documents
  29. of the Internet Engineering Task Force (IETF), its areas, and its working
  30. groups.  Note that other groups may also distribute working documents as
  31. Internet-Drafts.
  32.  
  33. Internet-Drafts are draft documents valid for a maximum of six months and
  34. may be updated, replaced, or obsoleted by other documents at any time.  It
  35. is inappropriate to use Internet-Drafts as reference material or to cite
  36. them other than as ``work in progress''. To learn the current status of any
  37. Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in
  38. the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 
  39. (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  40. ftp.isi.edu (US West Coast).
  41.  
  42. Distribution of this document is unlimited.
  43.  
  44. Comments are solicited and should be addressed to the authors and/or
  45. the AVT working group's mailing list at rem-conf@es.net.
  46.  
  47.                          Abstract
  48.  
  49.     This document describes a payload type for use with the real-time
  50.     transport protocol (RTP), version 2, for encoding redundant data.  The
  51.     primary motivation for the scheme described herein is the development
  52.     of audio conferencing tools for use with lossy packet networks such as
  53.     the Internet Mbone, although this scheme is not limited to such
  54.     applications.
  55.  
  56.  
  57.  
  58. Perkins et al                                      Page 1
  59.  
  60.  
  61. INTERNET-DRAFT                              3 January 1997
  62.  
  63.  
  64. 1  Introduction
  65.  
  66. If multimedia conferencing is to become widely used by the Internet Mbone
  67. community, users must perceive the quality to be sufficiently good for most
  68. applications. We have identified a number of problems which impair the
  69. quality of conferences, the most significant of which is packet loss over
  70. the Internet Mbone.  Packet loss is a persistent problem, particularly
  71. given the increasing popularity, and therefore increasing load, of the
  72. Internet.  The disruption of speech intelligibility even at low loss rates
  73. which is currently experienced may convince a whole generation of users
  74. that multimedia conferencing over the Internet is not viable. The addition
  75. of redundancy to the data stream is offered as a solution [1]. If a packet
  76. is lost then the missing information may be reconstructed at the receiver
  77. from the redundant data that arrives in the following packet(s), provided
  78. that the average number of consequutively lost packet is small. Recent work
  79. [4,5] shows that packet loss patterns in the Internet are such that this
  80. scheme typically functions well.
  81.  
  82. This document proposes an RTP payload format for the transmission of data
  83. encoded in such a redundant fashion.
  84.  
  85.  
  86. 2  Requirements
  87.  
  88. The requirements for a redundant encoding scheme under RTP are as follows:
  89.  
  90.   o Packets have to carry a primary encoding and one or more redundant
  91.     encodings.
  92.  
  93.   o As a multitude of encodings may be used for redundant information,
  94.     each block of redundant encoding has to have an encoding type
  95.     identifier.
  96.  
  97.   o As the use of variable size encodings is desirable, each encoded
  98.     block in the packet has to have a length indicator.
  99.  
  100.   o The RTP header provides a timestamp field that corresponds to
  101.     the time of creation of the encoded data.  When redundant encodings
  102.     are used this timestamp field can refer to the time of creation
  103.     of the primary encoding data. Redundant blocks of data will correspond
  104.     to different time intervals than the primary data, and hence each
  105.     block of redundant encoding will require its own timestamp.  To
  106.     reduce the number of bytes needed to carry the timestamp, it can
  107.     be encoded as the difference of the timestamp for the redundant
  108.     encoding and the timestamp ofthe primary.
  109.  
  110. There are two essential means by which redundant audio may be added
  111. to the standard RTP specification:  a header extension may hold the
  112.  
  113.  
  114. Perkins et al                                      Page 2
  115.  
  116.  
  117. INTERNET-DRAFT                              3 January 1997
  118.  
  119.  
  120. redundancy, or one, or more, additional payload types may be defined.
  121. These are now discussed in turn.
  122.  
  123.  
  124. 3  Use of RTP Header Extension
  125.  
  126. The RTP specification [2] states that applications should be prepared
  127. to ignore a header extension.  Including all the redundancy information
  128. for a packet in a header extension would make it easy for applications
  129. that do not implement redundancy to discard it and just process the
  130. primary encoding data. There are, however, a number of disadvantages
  131. with this scheme:
  132.  
  133.   o There is a large overhead from the number of bytes needed for
  134.     the extension header (4) and the possible padding that is needed
  135.     at the end of the extension to round up to a four byte boundary
  136.     (up to 3 bytes). For many applications this overhead is unacceptable.
  137.  
  138.   o Use of the header extension limits applications to a single redundant
  139.     encoding, unless further structure is introduced into the extension.
  140.     This would result in further overhead.
  141.  
  142. For these reasons, the use of RTP header extension to hold redundant audio
  143. encodings is disregarded.
  144.  
  145.  
  146. 4  Use Of Additional RTP Payload Types
  147.  
  148.  
  149. The RTP profile for audio and video conferences [3] lists a set of
  150. payload types and provides for a dynamic range of 32 encodings that
  151. may be defined through a conference control protocol. This leads to
  152. two possible schemes for assigning additional RTP payload types for
  153. redundant audio applications:
  154.  
  155.   1.A dynamic encoding scheme maybe defined, for each combination
  156.     of primary/redundant payload types, using the RTP dynamic payload
  157.     type range.
  158.  
  159.   2.A single fixed payload type may be defined to represent a packet
  160.     with redundancy. This may then be assigned to either a static
  161.     RTP payload type, or the payload type for this may be assigned
  162.     dynamically.
  163.  
  164.  
  165. 4.1 Dynamic Encoding Schemes
  166.  
  167. It is possible to define a set of payload types that signify a particular
  168. combination of primary and secondary encodings for each of the 32 dynamic
  169. payload types provided. This would be a slightly restrictive yet feasible
  170.  
  171. Perkins et al                                      Page 3
  172.  
  173.  
  174. INTERNET-DRAFT                              3 January 1997
  175.  
  176.  
  177. solution for packets with a single block of redundancy as the number
  178. of possible combinations is not too large.  However the need for multiple
  179. blocks of redundancy greatly increases the number of encoding combinations
  180. and makes this solution not viable.
  181.  
  182. A modified version of the above solution could be to decide prior to the
  183. beginning of a conference on a set a 32 encoding combinations that will be
  184. used for the duration of the conference.  All tools in the conference can
  185. be initialized with this working set of encoding combinations. Communication 
  186. of the working set can be made through the use of an external, out of band,
  187. mechanism.  Setup is complicated as great care needs to be taken in
  188. starting tools with identical parameters. This scheme is more efficient as
  189. only one byte is used to identify combinations of encodings.
  190.  
  191. It is felt that the complication inherent in distributing the mapping
  192. of payload types onto combinations of redundant data preclude the use
  193. of this mechanism.
  194.  
  195.  
  196. 4.2 Payload Type to Mean ``Packet-With-Redundancy''
  197.  
  198. A more flexible solution is to have a single payload type which signifies a
  199. packet with redundancy and have each of the encoding blocks in the packet
  200. contain it's own payload type field:  such a packet acts as a container,
  201. encapsulating multiple packets into one.
  202.  
  203. Such a scheme is flexible, since any number of redundant encodings
  204. may be enclosed within a single packet.  There is, however, a small
  205. overhead since each encapsulated packet must be preceded by a header
  206. indicating the type of data enclosed. This is the preferred solution,
  207. since it is both flexible, extensible, and has a relatively low overhead.
  208. The remainder of this document describes this solution.
  209.  
  210.  
  211. 5  RTP payload type for redundant data
  212.  
  213. The assignment of an RTP payload type for this new packet format is
  214. outside the scope of this document, and will not be specified here.
  215. It is expected that the RTP profile for a particular class of applications
  216. will assign a payload type for this encoding, or if that is not done
  217. then a payload type in the dynamic range shall be chosen.
  218.  
  219. An RTP packet containing redundant data shall have a standard RTP header,
  220. with payload type indicating redundancy.  The other fields of the RTP
  221. header relate to the primary data block of the redundant data.
  222.  
  223. Following the RTP header are a number of additional headers, defined
  224. in the figure below, which specify the contents of each of the encodings
  225. carried by the packet. Following these additional headers are a number
  226. of data blocks, which contain the standard RTP payload data for these
  227.  
  228. Perkins et al                                      Page 4
  229.  
  230.  
  231. INTERNET-DRAFT                              3 January 1997
  232.  
  233.  
  234. encodings.  It is noted that all the headers are aligned to a 32 bit
  235. boundary, but that the payload data will typically not be aligned.
  236.  
  237.  0                   1                   2                   3
  238.  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
  239. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  240. |F|   block PT  |  timestamp offset         |   block length    |
  241. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  242.  
  243. The bits in the header are specified as follows:
  244.  
  245. F: 1 bit First bit in header indicates whether another header block
  246.     follows.  If 1 further header blocks follow, if 0 this is the
  247.     last header block.
  248.  
  249. block PT: 7 bits RTP payload type for this block.
  250.  
  251. timestamp offset:  14 bits Unsigned offset of timestamp of this block
  252.     relative to timestamp given in RTP header.  This uses the same
  253.     clock as the primary encoding. The use of an unsigned offset
  254.     implies that redundant data must be sent after the primary data,
  255.     and is hence a time to be subtracted from the current timestamp
  256.     to determine the timestamp of the data for which this block is
  257.     the redundancy.
  258.  
  259. block length:  10 bits Length in bytes of the corresponding data block
  260.     excluding header.
  261.  
  262. It is noted that the use of an unsigned timestamp offest limits the
  263. use of redundant data slightly: it is not possible to send redundancy
  264. before the primary encoding. This may affect schemes where a low bandwidth
  265. coding suitable for redundancy is produced early in the encoding process,
  266. and hence could feasibly be transmitted early.  However, the addition
  267. of a sign bit would unacceptably reduce the range of the timestamp
  268. offset, and increasing the size of the field above 14 bits limits the
  269. block length field. It seems that limiting redundancy to be transmitted
  270. after the primary will cause fewer problems than limiting the size
  271. of the other fields.
  272.  
  273. It is further noted that the block length and timestamp offset are
  274. 10 bits, and 14 bits respectively; rather than the more obvious 8 and
  275. 16 bits.  Whilst such an encoding complicates parsing the header information
  276. slightly, and adds some additional processing overhead, there are a
  277. number of problems involved with the more obvious choice:  An 8 bit
  278. block length field is sufficient for most, but not all, possible encodings:
  279. for example 80ms PCM and DVI audio packets comprise more than 256 bytes,
  280. and cannot be encoded with a single byte length field. It is possible
  281. to impose additional structure on the block length field (for example
  282. the high bit set could imply the lower 7 bits code a length in words,
  283. rather than bytes), however such schemes are complex.  The use of a
  284.  
  285. Perkins et al                                      Page 5
  286.  
  287.  
  288. INTERNET-DRAFT                              3 January 1997
  289.  
  290.  
  291. 10 bit block length field retains simplicity and provides an enlarged
  292. range, at the expense of a reduced range of timestamp values. A 14
  293. bit timestamp value does, however, allow for 4.5 complete packets delay
  294. with 48KHz audio, more at lower sampling rates, and it is felt that
  295. this is sufficient.
  296.  
  297. The primary encoding block header is placed last in the packet. It
  298. is therefore possible to omit the timestamp and block-length fields
  299. from the header of this block, since they may be determined from the
  300. RTP header and overall packet length.  The header for the primary (final)
  301. block comprises only a zero marker bit, and the block payload type
  302. information, a total of 8 bits.  This is illustrated in the figure
  303. below:
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342. Perkins et al                                      Page 6
  343.  
  344.  
  345. INTERNET-DRAFT                              3 January 1997
  346.  
  347.  
  348.  0 1 2 3 4 5 6 7
  349. +-+-+-+-+-+-+-+-+
  350. |0|   BlockPT   |
  351. +-+-+-+-+-+-+-+-+
  352.  
  353. The final header is followed, immediately, by the data blocks, stored
  354. in the same order as the headers.  There is no padding or other delimiter
  355. between the data blocks, and they are typically not 32 bit aligned.
  356. Again, this choice was made to reduce bandwidth overheads, at the expense
  357. of additional decoding time.
  358.  
  359.  
  360. 6  Limitations
  361.  
  362.  
  363. The RTP marker bit is not preserved for redundant data blocks. Hence
  364. if the primary (containing this marker) is lost, the marker is lost.
  365. It is believed that this will not cause undue problems: even if the
  366. marker bit was transmitted with the redundant information, there would
  367. still be the possibility of its loss, so applications would still have
  368. to be written with this in mind.
  369.  
  370. In addition, CSRC information is not preserved for redundant data.
  371. The CSRC data in the RTP header of a redundant audio packet relates
  372. to the primary only. Since CSRC data in an audio stream is expected
  373. to change relatively infrequently, it is recommended that applications
  374. which require this information assume that the CSRC data in the RTP
  375. header may be applied to the reconstructed redundant data.
  376.  
  377.  
  378. 7  Security Considerations
  379.  
  380.  
  381. RTP packets containing redundant information are subject to the security
  382. considerations discussed in the RTP specification [2], and any appropriate
  383. RTP profile (for example[3]).  This implies that confidentiality of
  384. the media streams is achieved by encryption.
  385.  
  386. Encryption of a redundant data-stream may occur in two ways:
  387.  
  388.  
  389.   1.The entire stream is to be secured, and all participants are expected
  390.     to have keys to decode the entire stream.  In this case, nothing
  391.     special need be done, and encryption is performed in the usual
  392.     manner.
  393.  
  394.   2.A portion of the stream is to be encrypted with a different key
  395.     to the remainder.  In this case a redundant copy of the last packet
  396.     of that portion cannot be sent, since there is no following packet
  397.     which is encrypted with the correct key in which to send it.  Similar
  398.     limitations may occur when enabling/disabling encryption.
  399.  
  400.  
  401.  
  402. Perkins et al                                      Page 7
  403.  
  404.  
  405. INTERNET-DRAFT                              3 January 1997
  406.  
  407.  
  408. The choice between these two is a matter for the encoder only.  Decoders
  409. can decrypt either form without modification.
  410.  
  411.  
  412. 8  Example Packet
  413.  
  414. An RTP audio data packet containing a DVI4 (8KHz) primary, and a single
  415. block of redundancy encoded using 8KHz LPC is illustrated:
  416.  
  417.  
  418.  0                   1                   2                   3
  419.  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 
  420. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421. |V=2|P|X| CC=0  |M|      PT     |  sequence number of primary   |
  422. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  423. |              timestamp of primary encoding                    |
  424. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  425. |           synchronization source (SSRC) identifier            |
  426. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  427. |1| block PT=7  |  timestamp offset         |   block length    |
  428. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  429. |0| block PT=5  |                                               |
  430. +-+-+-+-+-+-+-+-+                                               +
  431. |                                                               |
  432. +               LPC encoded redundant data (PT=7)               +
  433. |                                                               |
  434. +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  435. |                               |                               |
  436. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  437. |                                                               |
  438. +                                                               +
  439. |               DVI4 encoded primary data (PT=5)                |
  440. +                                                     +---------+
  441. |                                                     |
  442. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459. Perkins et al                                      Page 8
  460.  
  461.  
  462. INTERNET-DRAFT                              3 January 1997
  463.  
  464.  
  465. 9  Author's Addresses
  466.  
  467. Colin Perkins/Isidor Kouvelas/Vicky Hardman
  468. Department of Computer Science
  469. University College London
  470. London WC1E 6BT
  471. United Kingdom
  472. Email:  {c.perkins|i.kouvelas|v.hardman}@cs.ucl.ac.uk
  473.  
  474. Mark Handley
  475. USC Information Sciences Institute
  476. c/o MIT Laboratory for Computer Science
  477. 545 Technology Square
  478. Cambridge, MA 02139, USA
  479. Email:  mjh@isi.edu
  480.  
  481. Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis
  482. INRIA Sophia Antipolis
  483. 2004 Route des Lucioles, BP 93
  484. 06902 Sophia Antipolis
  485. France
  486. Email:  {bolot|avega}@sophia.inria.fr
  487.  
  488.  
  489. 10 References
  490.  
  491. [1] V.J. Hardman, M.A.Sasse, M. Handley and A. Watson; Reliable Audio
  492. for Use over the Internet; Proceedings INET'95, Honalulu, Oahu, Hawaii,
  493. September 1995.  http://www.isoc.org/in95prc/
  494.  
  495. [2] H. Schulzrinne, S.Casner, R. Frederick and V. Jacobson; RTP: A
  496. Transport Protocol for Real-Time Applications; RFC 1889, January 1996
  497.  
  498. [3] H. Schulzrinne; RTP Profile for Audio and Video Conferences with
  499. Minimal Control; RFC 1890, January 1996
  500.  
  501. [4] M. Yajnik, J.Kurose and D. Towsley; Packet loss correlation in
  502. the MBone multicast network; IEEE Globecom Internet workshop, London,
  503. November 1996
  504.  
  505. [5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error control
  506. for packet audio in the Internet; Multimedia Systems, 1997
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517. Perkins et al                                      Page 9
  518.