home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-avt-fec-00.txt < prev    next >
Text File  |  1997-08-05  |  27KB  |  720 lines
  1.  
  2.  
  3.  
  4. Internet Engineering Task Force                                   AVT WG
  5. Internet Draft                                 J.Rosenberg,H.Schulzrinne
  6. draft-ietf-avt-fec-00.txt                              Bell Laboratories
  7. July 1997
  8. Expires: January 1998
  9.  
  10.  
  11.  An A/V Profile Extension for Generic Forward Error Correction in RTP
  12.  
  13. STATUS OF THIS MEMO
  14.  
  15.    This document is an Internet-Draft. Internet-Drafts are working docu-
  16.    ments of the Internet Engineering Task Force (IETF), its areas, and
  17.    its working groups.  Note that other groups may also distribute work-
  18.    ing documents as Internet-Drafts.
  19.  
  20.    Internet-Drafts are draft documents valid for a maximum of six months
  21.    and may be updated, replaced, or obsoleted by other documents at any
  22.    time.  It is inappropriate to use Internet-Drafts as reference mate-
  23.    rial or to cite them other than as ``work in progress''.
  24.  
  25.    To learn the current status of any Internet-Draft, please check the
  26.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  27.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  28.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  29.    ftp.isi.edu (US West Coast).
  30.  
  31.    Distribution of this document is unlimited.
  32.  
  33. 1 Abstract
  34.  
  35.    This document specifies an extension to RFC 1890 which allows for
  36.    forward correction (FEC) of continuous media encapsulated in RTP. The
  37.    profile is engineered for FEC algorithms based on the exclusive or
  38.    (parity) operation, although it can be used with other techniques.
  39.    The profile extension allows end systems to transmit using arbitrary
  40.    block lengths and parity schemes. It also allows for the recovery of
  41.    both the payload and critical RTP header fields. It is backwards com-
  42.    patible with existing RFC 1890 implementations, so that receivers
  43.    which do not wish to implement FEC can just ignore the extensions.
  44.  
  45. 2 Background
  46.  
  47.    The quality of packet voice on the Internet has been mediocre due, in
  48.    part, to high packet loss rates. This is especially true on wide-area
  49.    connections. Unfortunately, the strict delay requirements of real-
  50.    time multimedia usually eliminate the possibility of retransmissions.
  51.    It is for this reason that forward error correction (FEC) has been
  52.  
  53.  
  54. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61. Internet Draft          Generic Error Correction               July 1997
  62.  
  63.  
  64.    proposed to compensate for packet loss in the Internet [1]. In par-
  65.    ticular, the use of traditional error correcting codes, such as par-
  66.    ity, Reed-Solomon, and Hamming codes, has attracted attention. To
  67.    support these mechanisms, protocol support is required.
  68.  
  69.    Budge, McKenzie, Mills, Diss, and Long have proposed a payload format
  70.    for RTP which allows for the encapsulation of FEC-protected media on
  71.    top of RTP [2]. We briefly summarize their proposal, and urge the
  72.    reader to consult their draft for more details. They define a new RTP
  73.    payload type which identifies the packet contents as FEC-protected
  74.    media. The RTP payload format in their proposal consists of two ele-
  75.    ments, the media-correction header and the payload. The media-
  76.    correction header is 24 bits, and consists of three fields. The first
  77.    is called the scheme, the second the mode, and the third, the length.
  78.    The scheme identifies the particular error correction scheme in use.
  79.    In particular, it defines the set of data packets over which the FEC
  80.    is applied, and the order in which the packets (data and FEC) are
  81.    sent. The mode identifies which packet in a group of data and FEC
  82.    packets (typically called a block) this particular one corresponds
  83.    to. For packets that contain just data (and not FEC), the length
  84.    field contains the length of the payload. For packets which contain
  85.    FEC, the length field contains the xor of the length fields of the
  86.    packets which are covered by the FEC. Since packets must be padded
  87.    out with zeroes (to be equal lengths) in order to perform the xor
  88.    operation, the length field allows recovery of the actual length of
  89.    the pre-padded packets.
  90.  
  91. 3 Motivation
  92.  
  93.    The payload format proposed in [2] works quite well, but has a number
  94.    of drawbacks:
  95.  
  96.      oIt does not indicate the media type of the actual data being pro-
  97.       tected. This is because the RTP PT field always indicates that the
  98.       payload format is "FEC-protected media". Since many applications
  99.       will need to change media payload types mid-stream (for example,
  100.       sending DTMF tones in-band), the presence of this field is impor-
  101.       tant.
  102.  
  103.      oThe RTP timestamp field and marker bit are not covered by FEC.
  104.       When a packet is lost and then reconstructed, the timestamp and
  105.       marker bits are copied from the another packet. Correct recovery
  106.       of these fields is important.
  107.  
  108.      oIt defines four very specific schemes (one of which is no error
  109.       correction), and assigns a value for the scheme field in the
  110.       header to each. New schemes must be registered with IANA, the
  111.       details written up, and receivers and senders alike must be
  112.  
  113.  
  114. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121. Internet Draft          Generic Error Correction               July 1997
  122.  
  123.  
  124.       upgraded to recognize and support them. This makes backwards com-
  125.       patibility difficult, requiring capabilities negotiation. It also
  126.       means that transmitters are restricted to using the schemes
  127.       defined thus far. The three non-null schemes defined in [2] use
  128.       heavy forward error correction. These schemes are not appropriate
  129.       for all loss conditions.
  130.  
  131.      oIt results in substantial overhead: an additional 24 bits per
  132.       packet.
  133.  
  134. It is our aim to generalize the payload format for forward error protec-
  135. tion. To do this, the details of the scheme are transmitted inside the
  136. data packets with minimal overhead. This allows sender-based adaptation
  137. of the FEC schemes. This adaptation can be static or dynamic, and based
  138. on any information available at the sender. Changing schemes mid-stream
  139. is then trivially supported, whereas special protocol support is
  140. required in [2]. Capability exchanges are avoided, simplifying the pro-
  141. tocol and eliminating compatibility problems.
  142.  
  143. 4 Protocol Overview
  144.  
  145.    Before discussing the profile, we define a few terms for clarity. A
  146.    media payload is a piece of raw, un-protected user data. A media
  147.    header is the RTP header which would be used for this media payload
  148.    if no error correction were to be applied. The combination of a media
  149.    payload and media header is called a media packet. The forward error
  150.    correction algorithms at the transmitter take the media packets as an
  151.    input. They output both the media packets that they are passed, and
  152.    new packets called FEC packets. The FEC packet contains an FEC header
  153.    and FEC payload. Each FEC packet is said to be associated with one or
  154.    more media packets when those media packets are used to generate the
  155.    FEC packet (by use of the exclusive or operation, for example).
  156.  
  157.    At the receiver, arriving FEC and media packets are used to generate
  158.    a stream of media packets for direct use by the application. This
  159.    results in a clean separation of error protection from the applica-
  160.    tion.
  161.  
  162.    The protocol operates by assuming that the error correction algorithm
  163.    works by applying some function f to one or more media payloads,
  164.    which are specified as the arguments to f. The result of this func-
  165.    tion is an FEC payload. When the function is applied to just a single
  166.    media payload, the result is that media payload (f(a) = a). When the
  167.    function is applied to multiple media payloads, the result is some
  168.    combination of those payloads (the exclusive or would be defined as:
  169.    f(a,b,c) = a xor b xor c). We assume f can combine any number of pay-
  170.    loads, each with arbitrary lengths. If some media packet xi is lost,
  171.    recovery of its payload pi is accomplished if f(p0,..,pn) is
  172.  
  173.  
  174. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Internet Draft          Generic Error Correction               July 1997
  182.  
  183.  
  184.    received, i < n, and the remaining n-1 payloads combined by f are
  185.    received. Any function which meets these assumptions can be used by
  186.    the protocol.
  187.  
  188.    We have been careful to avoid discussing how media headers are com-
  189.    bined to generate FEC headers. The details of this operation are
  190.    defined in Section 5.2.
  191.  
  192.    For example, consider the case where f is the exclusive or. Media
  193.    packets w,x,y, and z, with media payloads a,b,c and d are to be
  194.    transmitted. Pairs of media payloads will be xor'ed together to gen-
  195.    erate the FEC payloads. We would denote the resulting network payload
  196.    stream as:
  197.  
  198.  
  199.    a, b, f(a,b), c, d, f(c,d)
  200.  
  201.  
  202.  
  203.    In this example, the error correction scheme introduces a 50% over-
  204.    head. But if b is lost, a and f(a,b) can be used to recover b.
  205.  
  206.    The way in which the various schemes differ is in the set of media
  207.    payloads over which the exclusive-or (or more generally, f(.)) is
  208.    applied, and the order in which the resulting packets are sent. For
  209.    example, Budge et. al. describe four schemes, 0, 1, 2, and 3 which
  210.    take media payloads a,b,c,d, etc., and generate FEC payloads as fol-
  211.    lows:
  212.  
  213.  
  214.    Scheme 0
  215.    --------
  216.  
  217.    This scheme is null, and has no error correction. The scheme is
  218.    formally defined as:
  219.  
  220.    a,b,c,d, ...  -> a, b, c, d, ....
  221.  
  222.    Scheme 1
  223.    --------
  224.  
  225.    This scheme is the similar to the one in the example above. The
  226.    switching of the positions of f(b) and f(a,b) allow some bursts of two
  227.    consecutive packet losses to be recovered. It is defined as:
  228.  
  229.    a,b,c,d,e,f -> a, f(a,b), b, f(b,c), c, f(c,d), d, ...
  230.  
  231.    Scheme 2
  232.  
  233.  
  234. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241. Internet Draft          Generic Error Correction               July 1997
  242.  
  243.  
  244.    --------
  245.  
  246.    This scheme allows for recovery of all single packet losses and some
  247.    consecutive packet losses, but with less overhead than scheme 1:
  248.  
  249.    a,b,c,d,e,f,g -> f(a,b),f(a,c),f(a,b,c),f(c,d),f(c,e),f(c,d,e)...
  250.  
  251.    Scheme 3
  252.    --------
  253.  
  254.    This scheme requires 4 packet delays to recover the original media
  255.    payloads, but it can recover from 1,2, or 3 consecutive packet losses:
  256.  
  257.    a,b,c,d,e,f -> f(a),f(b),f(a,b,c),f(c),f(a,c,d),f(a,b,d),f(d), ...
  258.  
  259.  
  260.  
  261.    In order to decode the FEC payloads to media payloads, all that is
  262.    necessary is for the receiver to know the function being applied, and
  263.    the set of media payloads in each FEC payload to which it is applied.
  264.    This is exactly the information provided by the profile extension.
  265.  
  266.    To determine which media payloads are associated with the FEC pay-
  267.    load, the semantics of the Sequence Number (SN) field in the FEC
  268.    header are redefined. Instead of incrementing monotonically as in RFC
  269.    1890 [3], the SN field is defined to be the minimum of the SN fields
  270.    of the media headers of the media payloads associated with the FEC
  271.    packet. For example, assume two consecutive media packets x and y
  272.    have media payloads a and b, and media sequence numbers 5 and 6. An
  273.    FEC packet is to be transmitted with a network payload that is the
  274.    xor of a and b. The SN in the header of this FEC packet, z, will have
  275.    a SN which is min(5,6) = 5. Note that this will cause FEC packets to
  276.    frequently have the same sequence number as media packets which pre-
  277.    ceded them.
  278.  
  279.    An additional field is present in the FEC header, called the offset
  280.    mask. If bit k in the mask is set to 1, then the media packet with
  281.    sequence number M + k is associated with this FEC packet, where M is
  282.    defined as the value of the SN field in the FEC header. Based on the
  283.    definition of the SN field, bit zero of the offset mask is always a
  284.    one. From the example above, the offset mask in FEC packet z is set
  285.    to 0b11. This indicates that two media packets (with media sequence
  286.    numbers 5 and 5+1 = 6) are associated with this FEC packet.
  287.  
  288.    This modified SN field and offset mask are sufficient to signal
  289.    arbitary forward error correction schemes with little overhead.
  290.  
  291. 5 Protocol Specifics
  292.  
  293.  
  294. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301. Internet Draft          Generic Error Correction               July 1997
  302.  
  303.  
  304.    The following section fills in the details based on the general dis-
  305.    cussion above.
  306.  
  307. 5.1 RTP Media Packet Structure
  308.  
  309.    Not all packets transmitted by the source contain FEC. Many contain
  310.    just regular media information, which would be sent if no error cor-
  311.    rection were used. The syntax and semantics of the RTP header and
  312.    payload fields are identical to those defined in RFC 1889 and RFC
  313.    1890.
  314.  
  315. 5.2 RTP FEC Packet Structure
  316.  
  317.    When a packet is to be transmitted which contains FEC data (i.e., its
  318.    payload is derived from one or more media payloads), the semantics of
  319.    the RTP header are changed.
  320.  
  321.    The format of the FEC packets is as follows:
  322.  
  323.  
  324.        0                   1                   2                   3
  325.        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
  326.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  327.       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
  328.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  329.       |                           timestamp                           |
  330.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  331.       |           synchronization source (SSRC) identifier            |
  332.       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  333.       |            contributing source (CSRC) identifiers             |
  334.       |                             ....                              |
  335.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  336.       |      defined by profile       |           length              |
  337.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  338.       |     length recovery           |        Offset Mask            |
  339.       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  340.       |                    Additional Offset Mask                     |
  341.       |                             ....                              |
  342.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  343.  
  344.  
  345.  
  346.  
  347.    The semantics of these fields is as follows:
  348.  
  349.      oVersion. This field is always 2.
  350.  
  351.      oPadding. This field has the same semantics as RFC 1889.
  352.  
  353.  
  354. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 6]
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361. Internet Draft          Generic Error Correction               July 1997
  362.  
  363.  
  364.      oExtension. This bit is always set to 1, indicating the presence of
  365.       a header extension following the CSRC list.
  366.  
  367.      oCC. This field has the same semantics as in RFC 1889.
  368.  
  369.      oMarker. This bit is set to the f operator applied to the marker
  370.       bits of all the media packets associated with this FEC packet.
  371.  
  372.      oPT. This field is set to the f operator applied to the PT fields
  373.       of all of the media packets associated with this FEC packet.
  374.  
  375.      oSequence Number. This field is set to the minimum of the sequence
  376.       numbers of the media packets associated with this media packet.
  377.  
  378.      oTimestamp. This field is set to the f operator applied to the
  379.       timestamps of the media packets associated with this FEC packet.
  380.  
  381.      oSSRC. This field has the same semantics as in RFC 1889.
  382.  
  383.      oCSRC list. This field has the same semantics as in RFC 1889.
  384.  
  385.      oDefined by Profile. This field is part of the header extension. It
  386.       allows for end-systems to determine which extension mechanism is
  387.       in use. It is always set to 0x3a to identify this extension as
  388.       conforming to the syntax and semantics defined here.
  389.  
  390.      olength. This field is part of the header extension. It indicates
  391.       the number of 32-bit words in the extension. When it is one, a
  392.       single word follows, with 16 bits length recovery and 16 bits off-
  393.       set mask. When it is greater than one (say L), a 16 bit length
  394.       recovery field is present, followed by an offset mask of length
  395.       32*L - 16 bits.
  396.  
  397.      olength recovery. This field is set to be equal to the f operator
  398.       applied to the lengths of the media payloads associated with this
  399.       FEC packet. It allows for variable length payloads to be protected
  400.       by FEC.
  401.  
  402.      ooffset mask. This field indicates the sequence numbers of the
  403.       media packets associated with this FEC packet. If bit k in the
  404.       mask is set to 1, then the media packet with sequence number M+k
  405.       is associated with this FEC packet. This implies that its media
  406.       payload has been operated on by f to generate the FEC payload. It
  407.       also implies that its sequence number, timestamp, marker bit, and
  408.       PT field have been used to generate the sequence number, times-
  409.       tamp, marker bit, and PT field for the FEC packet. Since this
  410.       field is variable length, arbitrary media packets can be associ-
  411.       ated with any FEC packet.
  412.  
  413.  
  414. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 7]
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421. Internet Draft          Generic Error Correction               July 1997
  422.  
  423.  
  424. End systems which cannot recognize the extension should discard the FEC
  425. packet. This provides backwards compatibility. The media packets are
  426. still recognizable by any application. End systems which can recognize
  427. the extension can additionally process the FEC packets. This makes this
  428. extension ideally suited for multicast scenarios, where there are a mix
  429. of FEC-capable and non FEC-capable receivers. It also makes for good
  430. efficiency. Unlike in [2], the extra header fields are only present in
  431. FEC packets.
  432.  
  433. 5.3 Transmit Procedures
  434.  
  435.    This section describes how a transmitter sets the fields in the
  436.    header for FEC packets. It is assumed that a transmitter will ocas-
  437.    sionally send an FEC packet which is derived from one or more media
  438.    packets. The protocol does not in any way mandate when to send an FEC
  439.    packet, or determine which media packets the FEC is derived from. It
  440.    is assumed that transmitters generate FEC packets in a reasonable
  441.    fashion so that they can actually be used for recovery.
  442.  
  443.    Define the list of media packets over which the FEC is derived as T.
  444.    The FEC packet is generated as follows:
  445.  
  446.      1.   If the lengths of the payloads of packets in T are not equal,
  447.           they are padded with zeroes to be as long as the longest pay-
  448.           load. The original, unpadded length of each packet is stored.
  449.  
  450.      2.   The possibly padded payloads are operated on by f. The result
  451.           is placed in the FEC packet payload.
  452.  
  453.      3.   The SSRC, CC, version, padding, and CSRC list in the FEC
  454.           packet header are copied from one of the media packets in T.
  455.  
  456.      4.   The timestamp, marker bit, and PT fields in the FEC packet
  457.           header are computed by applying f to the corresponding fields
  458.           of the media packets in T.
  459.  
  460.      5.   The sequence number in the FEC packet is set to the minimum of
  461.           the sequence numbers of the media packets in T. Call this
  462.           sequence number M.
  463.  
  464.      6.   For each media packet in T, the difference between its
  465.           sequence number and M is computed. Call this difference k. Bit
  466.           k in the offset mask field is set to 1.
  467.  
  468.      7.   The length recovery field is set to f applied to the original,
  469.           unpadded lengths of the media packets in T.
  470.  
  471.      8.   The defined by profile field in the extension is set to 0x3a
  472.  
  473.  
  474. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 8]
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481. Internet Draft          Generic Error Correction               July 1997
  482.  
  483.  
  484. This procedure defines all of the fields in the FEC packet.
  485.  
  486. 5.4 Recovery Procedures
  487.  
  488.    The FEC packets allow end systems to recover from the loss of media
  489.    packets. Both the payload and the RTP header of the media packet can
  490.    be reconstructed. This section describes the procedure for performing
  491.    this recovery.
  492.  
  493.    Assume a receiver has received several media and FEC packets, but the
  494.    media packet with sequence number xi was lost. When an FEC packet
  495.    arrives (they are identified via the extension bit), the following
  496.    steps are taken:
  497.  
  498.      1.   The end system checks if the FEC packet can be used to recon-
  499.           struct packet xi. To do this, the sequence number from the FEC
  500.           packet is read (call it M). The list of media packets associ-
  501.           ated with this FEC packet, S, is initialized to be empty. The
  502.           bitmask is scanned. If bit k is 1, sequence number M+k is
  503.           added to the list.
  504.  
  505.      2.   If the list of sequence numbers includes xi, and the remaining
  506.           sequence numbers in the list correspond to media packets which
  507.           have all been received (or were recovered), this FEC packet
  508.           can be used to recover xi.
  509.  
  510.      3.   The payload of xi is recovered by applying the inverse of f to
  511.           the other received media payloads and the recently received
  512.           FEC payload. In the case of xor, this would imply xor'ing the
  513.           payloads together.
  514.  
  515.      4.   This payload may have padding in it. The length of the actual
  516.           payload is computed via the length recovery field. The f oper-
  517.           ator is applied to the length recovery fields in the other
  518.           received media packets and the recently received FEC packet.
  519.           The result is the unpadded payload length.
  520.  
  521.      5.   The timestamp, marker bit, and PT fields of the RTP header for
  522.           media packet xi are recovered in the same fashion. The inverse
  523.           of f is applied to the fields of the other received media
  524.           packets and the field in the recently received FEC packet.
  525.  
  526.      6.   The SSRC, CC, version, padding, and CSRC list for media packet
  527.           xi are copied from one of the media or FEC packets used to
  528.           recover it. This implies that end systems should not change
  529.           these fields frequently, as they may not be recovered prop-
  530.           erly.
  531.  
  532.  
  533.  
  534. J.Rosenberg,H.Schulzrinne    July 30, 1997                    [Page 9]
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541. Internet Draft          Generic Error Correction               July 1997
  542.  
  543.  
  544.      7.   The extension bit in the header of packet xi is set to zero.
  545.           This means that FEC cannot be applied to packets with other
  546.           header extensions.
  547.  
  548. This procedure completely recovers the lost packet, including the pay-
  549. load and RTP header fields.
  550.  
  551. 5.5 Example
  552.  
  553.    Consider 2 media packets to be sent, x and y. We wish to protect them
  554.    by sending one FEC packet which is derived from x and y. The f opera-
  555.    tor is implemented using xor. The three packets are:
  556.  
  557.  
  558.    Media Packet x
  559.    --------------
  560.  
  561.    Version:   2    (10)
  562.    Padding:   0    (0)
  563.    Extension: 0    (0)
  564.    Marker:    0    (0)
  565.    PTI:       11   (01011)
  566.    SN:        8    (1000)
  567.    TS:        3    (011)
  568.    SSRC:      2    (10)
  569.  
  570.    The payload length is 10 bytes.
  571.  
  572.    Media Packet y
  573.    --------------
  574.  
  575.    Version:   2    (10)
  576.    Padding:   0    (0)
  577.    Extension: 0    (0)
  578.    Marker:    1    (1)
  579.    PTI:       18   (10010)
  580.    SN:        9    (1001)
  581.    TS:        5    (101)
  582.    SSRC:      2    (10)
  583.  
  584.    The payload length is 11 bytes.
  585.  
  586.  
  587.  
  588.    The FEC packet is then:
  589.  
  590.  
  591.  
  592.  
  593.  
  594. J.Rosenberg,H.Schulzrinne    July 30, 1997                   [Page 10]
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601. Internet Draft          Generic Error Correction               July 1997
  602.  
  603.  
  604.    FEC Packet (contains a xor b)
  605.    -----------------------------
  606.  
  607.    Version:   2    (10)
  608.    Padding:   0    (0)
  609.    Extension: 1    (1)
  610.    Marker:    1    (1)     (NOTE: 0 xor 1 = 1)
  611.    PTI:       25   (11001) (NOTE: 11 xor 18 = 01011 xor 10010 = 11001)
  612.    SN:        8    (1000)  (NOTE: min(8,9) = 8)
  613.    TS:        6    (110)   (NOTE: 3 xor 5 = 011 xor 101 = 110)
  614.    SSRC:      2    (10)
  615.    ext. def.: 0x3a
  616.    length:    1
  617.    len. rec.: 1    (1)         (NOTE: 10 xor 11 = 1010 xor 1011 = 0001)
  618.    mask:      (00000000000000000000011)
  619.  
  620.    The payload length is 11 bytes.
  621.  
  622.  
  623.  
  624.  
  625. 6 Open Issues
  626.  
  627.    There are a number of open issues to be resolved. The change in defi-
  628.    nition of the RTP header fields will affect many of the parameters
  629.    sent in RTCP packets. For example, highest sequence number received
  630.    and jitter computations may have to exclude FEC packets. Octet counts
  631.    and number of transmitted packets probably should include FEC, how-
  632.    ever.
  633.  
  634.    To simplify some of the sequence number based computations, an alter-
  635.    nate sematic for the SN field in the FEC packets is possible. All
  636.    packets can have sequence numbers which are one higher than the pre-
  637.    vious transmitted packet, FEC or media. The offset mask field in FEC
  638.    packets then covers positive and negative offsets. This makes less
  639.    efficient use of the offset mask, but makes the sequence numbers more
  640.    meaningful.
  641.  
  642. 7 Conclusion
  643.  
  644.    This draft has presented an extension to RFC 1890 which allows for
  645.    forward error correction of audio visual media. It is generic, allow-
  646.    ing any sender defined error correction schemes to be used which
  647.    meets the required criteria (any xor based strategy meets the crite-
  648.    ria). It is also backwards compatible with existing implementations.
  649.    Receivers which cannot understand FEC can discard the FEC packets,
  650.    and still receive the media packets.
  651.  
  652.  
  653.  
  654. J.Rosenberg,H.Schulzrinne    July 30, 1997                   [Page 11]
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661. Internet Draft          Generic Error Correction               July 1997
  662.  
  663.  
  664. 8 Security Considerations
  665.  
  666.    There are no security considerations beyond those discussed in [3]
  667.    and [4].
  668.  
  669. 9 Author's Addresses
  670.  
  671.  
  672.    Jonathan Rosenberg
  673.    Lucent Technologies, Bell Laboratories
  674.    101 Crawfords Corner Rd.
  675.    Holmdel, NJ 07733
  676.    Rm. 4D-534B
  677.    email: jdrosen@bell-labs.com
  678.  
  679.    Henning Schulzrinne
  680.    Columbia University
  681.    M/S 0401
  682.    1214 Amsterdam Ave.
  683.    New York, NY 10027-7003
  684.    email: schulzrinne@cs.columbia.edu
  685.  
  686.  
  687.  
  688.  
  689. 10 Bibliography
  690.  
  691.    [1] J.-C. Bolot and A. Garcia, The case for fec-based error control
  692.    for packet audio in the internet,   Multimedia Systems , 1997.
  693.  
  694.    [2] D. Budge, R. McKenzie, W. Mills, and P. Long, Media-independent
  695.    error correction using rtp, (internet draft), Internet Engineering
  696.    Task Force, May 1996.  Work in Progress.
  697.  
  698.    [3] H. Schulzrinne, RTP profile for audio and video conferences with
  699.    minimal control, Request for Comments (Proposed Standard) RFC 1890,
  700.    Internet Engineering Task Force, Jan. 1996.
  701.  
  702.    [4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a
  703.    transport protocol for real-time applications, Request for Comments
  704.    (Proposed Standard) RFC 1889, Internet Engineering Task Force, Jan.
  705.    1996.
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714. J.Rosenberg,H.Schulzrinne    July 30, 1997                   [Page 12]
  715.  
  716.  
  717.  
  718.  
  719.  
  720.