1. Each original packet is placed in the source block. In doing so, the Source FEC Payload ID information to be included in the FEC payload ID of the FEC source packet can be determined. In the source block the identity of the packet's flow is marked using the Flow ID. See Section 5 of RFC 6681 for details.
2. The FEC source packet is constructed according to clause 8.2.2.4. The identity of the original flow is maintained by the source packet through the use of the destination UDP port number and destination IP address, which has been advertised (for example using SDP), as carrying FEC source packets generated from an original stream of a particular protocol (e.g. RTP, RTCP, SRTP, MIKEY etc.). See clause 8.2.2.13.
3. The generated FEC source packet is sent using UDP.

1. If a FEC source packet is received (as indicated by the UDP port on which it was received):
   1. The original source packet is reconstructed by removing the Source FEC Payload ID. The resulting packet is buffered to allow time for the FEC repair.
   2. The resulting packet is placed into the source block according to the information in the Source FEC Payload ID and the source block format described in Section 5 of RFC 6681. The UDP port the packet was received on is used to determine the Flow ID written into the source block.
2. If an FEC repair packet is received (as indicated by the UDP port), the contained encoding symbols are placed into an FEC encoding block according to the Repair FEC Payload ID. In case the received FEC repair packet is empty, there are no repair symbols to be placed in the FEC encoding block.
3. If at least one source packet is missing, then FEC decoding may be desirable. The FEC decoder determines if the encoding block constructed in steps 1 and 2 contains enough symbols from the source and repair packets for decoding and, if so, performs the decoding operation. If only empty FEC repair packets are received, the receiver may start immediately some procedures to conceal the effect of missing media data.
4. Any missing source packets that were reconstructed during the decoding operation are then buffered as normal received packets (see step 1a above).

• the maximum source block length, in symbols
• the symbol size, in bytes

1. The hypothetical FEC decoding buffer is initially empty.
2. Each FEC source packet and FEC repair packet, starting from the first packet in transmission order, is inserted into a FEC source block at its transmission time. The FEC source block generation is done as specified in Section 6.2.3 of RFC 6681. The FEC source block resides in the hypothetical FEC decoding buffer.
3. When both the last FEC source packet and the last FEC repair packet of an FEC source block are transmitted, any elements of the FEC source block that are not original UDP packets (e.g. FEC repair packets and potential padding bytes) are removed from the hypothetical FEC decoding buffer.
4. Original UDP packets are not removed from the hypothetical FEC decoding buffer before the signalled initial buffering delay has expired. Then, the first original UDP packet in sequence number order is output and removed from the hypothetical FEC decoding buffer immediately. Each succeeding original UDP packet is output and removed when the following conditions are true:
   1. The following time (in seconds) since the removal of the previous packet has elapsed:
      8 × (size of the previous original UDP packet including UDP/IP header in bytes) / (1 000 × (value of "b=AS" SDP attribute for the stream))
   2. All the packets in the same FEC source block as the original UDP packet have been transmitted.

• If several user services are bundled together they are indicated as a sequence of services in the User Service Bundle Description. See clause 11.2.
• A separate SDP describing the FEC repair stream and all the flow IDs referenced from the User Service Bundle Description. See clauses 11.2 and 8.2.2.14.
• SDP protocol identifiers and attributes to indicate the usage of the source packet format, how the FEC payload ID is configured and other FEC parameters such as minimal buffering delay, for the RTP/RTCP streams. See clause 8.2.2.13a.
• Security description extensions to indicate usage of FEC source packet format, and the FEC parameters. See clauses 11.3 and 8.2.2.13a.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          0xBEDE               |           length=1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID   | len=2 |            timestamp-offset                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1. Exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and inclusive-mode shall use exactly one source address in the <src-list>.
2. There shall be exactly one source-filter attribute per complete MBMS streaming session SDP description, and this shall be in the session part of the session description (i.e. not per media).
3. The * value shall be used for the <dest-address> subfield.

• IP destination address.
• Destination port number(s).

• sdp-fec-oti-extension-line = "a=FEC-OTI-extension:" fec-ref SP oti-extension CRLF
• fec-ref = 1*3DIGIT (the SDP-internal identifier for the associated FEC-declaration).
• oti-extension = base64
• base64 = *base64-unit [base64-pad]
• base64-unit = 4base64-char
• base64-pad = 2base64-char "==" / 3base64-char "="
• base64-char = ALPHA / DIGIT / "+" / "/"

• sdp-fec-parameter-line = "a=mbms-repair:" 0*1SP fec-ref SP parameter-list CRLF
• parameter-list = parameter-spec *(1*SP parameter-spec)
• parameter-spec = name "=" value;
• name = 1*(ALPHA / DIGIT / "-")
• value = 1*(safe) ; safe defined in RFC 4566

Min-buffer-time-parameter-name = "min-buffer-time"
Min-buffer-time-parameter-value = 1*8DIGIT ;Wallclock time in milliseconds.

• "a=X-initpredecbufperiod:<initial pre-decoder buffering period>"

• Interleaving="X-3gpp-FEC-Interleaving:" SP flow_interleaving *("," flow_interleaving) CRLF
• flow_interleaving=flowID "=" ["ordered" / "mixed" / "reverse"]

• QoE-Metrics-line = "a" "=" "3GPP-QoE-Metrics:" att-measure-spec *("," att-measure-spec)) CRLF
• att-measure-spec = Metrics ";" Sending-rate [";" Measure-Range]
  [";" Measure-Resolution] *([";" Parameter-Ext])
• Metrics = "metrics" "=" "{"Metrics-Name *("|" Metrics-Name) " }"
• Metrics-Name = 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}"
• Sending-Rate = "rate" "=" 1*DIGIT / "End" / "Periodic"
• Measure-Resolution = "resolution" "=" 1*DIGIT ; in seconds
• Measure-Range = "range" ":" Ranges-Specifier
• Parameter-Ext = (1*DIGIT ["." 1*DIGIT]) / (1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e))
• Ranges-Specifier = as defined in RFC 2326.

• it is a refresh frame (does not reference any previously decoded frames AND where none of the subsequently decoded frames reference any frames decoded prior to X); or
• does not reference any previously decoded frames; or
• only references previously decoded "good frames".

1. A good frame can be derived by the client using the codec layer, in which case the codec layer signals the decoding of a good frame to the client. A good frame could also be derived by error tracking methods, but decoding quality evaluation methods shall not be used. An error tracking method may derive that a frame is a good frame even when it references previously decoded corrupted frames, as long as all the referenced pixels for generating the prediction signal were correctly reconstructed when decoding the reference frames. A decoding quality evaluation method may derive that a frame is a good frame even one or more pixels of the frame have not been correctly reconstructed, as long as the decoding quality is considered by the method as acceptable. Such a frame is not a good frame according to the definition above, which shall be strictly followed.
2. In the absence of information from the codec layer, a good frame should be derived according to N, where N is optionally signalled from MBMS streaming server (via SDP) to the MBMS Client and represents the maximum duration, in presentation time, between two subsequent refresh frames in milliseconds. After a corrupted frame, if all subsequent frames within N milliseconds in presentation time have been completely received, then the next frame is a good frame.
3. N is not signalled, then it defaults to ¥ (for video) or to one frame duration (for audio).
   The optional parameter D is defined to indicate which of options a) and b) is in use. D is signalled from the client to the server. When D is equal to "a", option a) shall be in use, and the optional parameter T shall be present. When D is equal to "b", option b) shall be in use and the optional parameter T shall not be present.

• D = "D" "=" "a" / "b"
• N = "N" "=" 1*DIGIT

• FR = "FR" "=" 1*DIGIT "." 1*DIGIT

• T = "T" "=" {+/-} 1*DIGIT
• B = "B" "=" {+/-} 1*DIGIT
• S = "S" "=" 1*DIGIT

• Y = "Y" "=" 1*DIGIT
• Z = "Z" "=" 1*DIGIT