FECFrame Minutes


Greg Shepherd (GS) – Agenda and status

Framework draft should be ready for last call after the meeting

            But we missed the cake L


GS (for Mark Watson)


            Many comments on the list. Most were clarification of terms. IANA considerations defined. No large changes to the framework per se, just mostly clarifications. Should be ready for last call after this meeting.



Some minor clarifications, and updated contact info. Also should be ready for last call after the meeting.


Marshall Eubanks (ME):

            Should we have the framework document go through the whole last-call process?


GS: We had to rev it, due to so many comments on the list. So it will go through the last call process as it is now and will reflect any new comments agreed upon through the process.


Ali Begen (AB):


            Just a couple of issues in the previous version but were outside this draft, regarding grouping issues in SDP.

            MMUSIC has updated RFC3388bis so it should be going for last call, and accordingly updated RFC4756bis. We now have what we needed for the grouping semantics.

            I asked for last-call from MMUSIC for this draft. Waiting on people from this group to read and review. Please review so we can finalize RFC4756bis. It is a normative reference for the SDP-Elements draft.

            Second issue of the SDP draft was the priority of repair flows. Previously we had a priority parameter in SDP to indicate decoding order of the repair flows set by the sender side. But ÒpriorityÓ word had several prior meanings. So now weÕre going with preference level. It is optional. If you have multiple repair flows but you want your receivers to start decoding from a particular repair flow you can set the priority of decoding in SDP. Whether they follow the preference level is optional.

            One issue that came up on the list was about a textual representation of the FEC scheme-specific information field. Some think it should be a human-readable ASCII field and others think it should be binary. We need to make a decision.


ME: Are there any existing deployments?

ME: I have a mild preference to ASCII.

AB: I think you are an exception.

GS: From memory the only issue which arose was around the deployment of a middle box that needed to decode the FEC Scheme-specific information field.

AB: Still an open issue.


Collin Perkins (CP): If itÕs going into SDP in needs to be text.

            SDP work in the IETF has always defined to be ASCII human-readable

            If itÕs something that has been defined in another standards body as a binary block then we É.mumble, mumble..

            Show the counter example

            Ultimately it doesnÕt make much difference. ASCII may be easier to debug, binary may be more efficient – pick one and move on.


AB: The whole information field is maybe 10 digits


Room: Base64 – 1 hand

            ASCII – 7 hands


AB: WeÕre going to go with ASCII. This info will be included in the draft then IÕll ask to move to last call. Of course it will be waiting on the framework draft.


GS: On process, can we forward them all at the same time though they are dependent. Magnus? Can they progress together?


Magnus Westerlund (MW): Once youÕve established WG consensus, you can move them in parallel. Still need individual proto write-ups.


Ye-Kui Wank (YK): draft-zixuan-fecframe-source-mi-0 – presenting for colleagues


AB: Is it okay for the repair packet to have the FEC payload header – it must have something anyway – but you are adding this kind of header to the source packets?


YK: No, FEC payload header is not added to the source packet, itÕs added to the repair packet and the information mapping packet.


AB: Do we really need to consider non-framework capable receivers?


ME: I donÕt believe this violates our charter. But why are you doing this work?


YK: For RTP receivers not using FEC and not supporting the FECFramework, e.g. RFC 3948 receivers.


AB: We donÕt modify the source packets anyway so this is not a problem.


YK: The draft says it is recommended though optional to include this data.


AB: All the cenarios we are aware of already use RTP and have sequence numbers so donÕt need to include this data.


ME: Chairs should prepair a letter to the list for use cases to see if we have responses.


AB: This MIU would have to go into a separate datagram. What happens if it is lost or reordered. We need to be protected, robust at the receiver side.


YK: The draft does not specify ways for robustness.


Einat Yellin (EY): draft-galanos-fecframe-rtp-reedsolomon-mf-00


Dave Oran (DO): There is an obvious goal for video-conferencing which is not in your goal list which is low source delay. Low recovery delay obviously, but long block will add more delay so are you going to show how this also provides low source delay?


EY: Some background – trying to compensate for burst packet loss across multiple RTP flows.

            The motivation is for video but there is nothing in the draft specifying the application for video only so any RTP payload would work.


CP: Just trying to understand the use case. So you have an audio flow and a video flow and you want to generate one repair flow for the two or is it layered video flows? So all the flows are generated from the same host/user?


EY: Different video flows which could be layered video or multiple video for a 3D video.


CP: Just trying to see how they would map to RTP and it would be easier if they were in someway related rather than separate.


Bill Versteig (BV): Is this fundamentally about how they map mutiple flows in the FEC or is there something Reedsolomon specific? A method to combine flows and map to FEC is interesting in the broad sense outside of just Reedsolomon specifically.


EY: We donÕt specify the specification of Reedsolomon.


ME: It would be a good design goal to allow different FEC schemes to be dropped into this solution.


EY: It would be more useful to have one draft to define in the generic sense.


CP: YouÕre missing the case where you have multiple SSRCs in one RTP session


BV: letÕs fix these stream coralation problems in a non FEC-specific way so that we have a framework solution and we wonÕt have to do this for every FEC.


CP: Try to think of more general use cases provided it doesnÕt break this use case.


ME: If this is going to be applied in a more generic case then we should have some sort of registry.


CP: We have a registry – itÕs the MIME-type registry.


CP: You show repair window in microsecs? Perhaps RTP timestamp units instead, but complicated for multiple rows, that way it exactly maps onto the source flows.


CP: Great open issues as applied to RTP

            FEC across unrelated RTP (AVT) flows

            Strongly encouraged to bring to the RTP WG

            Great interest in solving these issues

            When you start trying to apply FEC across unrelated sessions then you have really big problems defining what is what and delineating things. ItÕs not clear that this can be fixed within how RTP works.

            This would fit better as an AVT draft to be reviewed by FECFrame. Most of the complexity is in the RTP integration, independent of any FEC.


Vincent Roca (VR): draft-roca-fecframe-rs-01


AB: DVB was working on un-equal protection for media flows. What happened to that? UpperLayer-FEC


Jeff Goldberg (JG): It changed chairs but should still be active


AB: 1&2 multiple source flows? (Yes)

            We should work together for a common

            Protection of multiple source flow doc is already a WG Item


VR: LDPC-staircase



            WG Item?


AB: Pub request of interleave draft

            1D/2D draft status?


JG: LIason sent to DVB

            DVB-AL FEC Draft

SMTP ref 2022 / draft is incomplete

DVB punting back to IETF $ SMPTE

            Time to complete our work

            No need to be contingent or wait on liason


VR: General RPT payload format?


CP: Definded by payload type

            Multiple flow protection trick to go to AVT