1. RTP Payload Format for Multiple Flows FEC draft-peck-fecframe-rtp-mf-01 Orly Peck, RADVISION orlyp@radvision.com IETF 77 – March 2010

2. Background protecting RTP packets from multiple source flows This draft – FEC scheme generic – Specifies RTP payload format for such FEC packets – Aims to solve source-synchronization problems – Multiple Flows includes Multi-Session and Multi- Source Transmission

3. Main changes from draft 00 Remove use of Marker-bit in RTP header Added L-bit in fec-mf header instead FEC-Scheme param in SDP moved to a=fmtp line Implementation considerations added Offer-Answer considerations added Security considerations added

4. FEC-MF header for repair packets 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Num Flows | FID | FID | FID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | FID | padding | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC identifiers (Optional) | |... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ – L-Bit – indicating whether a list of SSRC identifiers is appended to the FEC-MF header. – Num Flows – number of flows protected by this FEC block – FID – flow ID. Determined by SDP. Correlated to a FEC header appended to the MF-Header. Number of FIDs = Num Flows. – SSRC Identifiers – list of SSRC identifiers from the source RTP headers. Number of SSRC identifiers is 0 if L-bit is set to 0. Otherwise, equals Num Flows * 4 bytes for each SSRC identifier (taken from RTP header of protected source flow).

5. IANA Registration Register subtype name fec-mf for application type Required parameters – fmtp line starts with the FEC-scheme parameter indicating which fec scheme is used for FEC encoding. Following is a list of the required fec scheme specific parameters.

6. Example – SDP v=0 o=orly 1122334455 1122334466 IN IP4 fec.example.com s= MF FEC Example t=0 0 a=group:FEC S1 S2 R1 m=video 30000 RTP/AVP 100 c=IN IP4 224.1.1.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=0 a=mid:S1 m=video 30002 RTP/AVP 100 c=IN IP4 224.1.1.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=1 a=mid:S2 m=application 30000 RTP/AVP 110 c=IN IP4 224.1.2.1/127 a=rtpmap:110 fec-mf/90000 a=fmtp:110 FEC-scheme:reed-solomon-fec; max_N:5; repair-window:200000; symbol-size:8 a=mid:R1

7. Implementation Considerations For applications with low-latency requirement, protecting multiple flows can reduce FEC bandwidth overhead (while decreasing FEC protection strength). Example – protecting 2D + depth frames in 3D interactive video (requires FEC block to include not more than a single video frame). Can be used to increase FEC strength (for example protecting 8 packets with 2 FEC packets instead of protecting each 4 packets with a single FEC packet. Example for application not suitable for using multi-flow FEC protection – two flows where one of them suffers from high packet loss rate, and the other does not.

8. Offer-Answer Considerations Sender can offer several FEC-schemes for a multi-flow fec protection. Offer same FEC-scheme with different parameters. Receivers not supporting fec-mf must ignore fec-mf lines.

9. Questions & Comments