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