Re: [payload] [rtcweb] Second WGLC on draft-ietf-payload-flexible-fec-scheme

["Mo Zanaty (mzanaty)" <[e-mail]>]

Hi Magnus,

Thanks for the review. In general, I agree with your comments, and will update the draft accordingly. See Mo: inline for details.

Mo

From: payload <[e-mail]<mailto:[e-mail]>> on behalf of 'Magnus Westerlund' <[e-mail]<mailto:[e-mail]>>
Date: Monday, June 11, 2018 at 10:15 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [payload] [rtcweb] Second WGLC on draft-ietf-payload-flexible-fec-scheme


Hi,

I have now reviewed -07. It is not ready yet. A significant issue appear to exist around how one recovers CSRC lists or header extensions.

1. Section 4.2.2, Figure 13:

The R and F bits are swapped. To my understanding this figure should use R=0 and F=1, i.e. 0 1 in the two first bits.

Mo: Yes, the figure should use R=0 and F=1 to match the text. I will correct this.


2. Section 4.2.2, Figure 15:

So when R=1, why is F=1? As neither of the F values apply when R=1, why not simply define that F=0, which would result in that the RTP payload would be equal to the complete RTP packet being retransmitted?

Mo: Yes, R=1 can be redefined to use F=0 instead of F=1, to simplify copying the complete source RTP packet being transmitted. I will make this change, unless anyone objects.


3. Section 4.2.2, Figure 15:

Why isn't the CSRC list or packet header extension of the retransmitted packet included in the figure, they will be there if P or X bits of the Retransmission is present? Or are they counted as part of the retransmission / repair payload?

Mo: The CSRC list and header extensions of the original source packet are part of the retransmission "payload". I will clarify this with more explicit wording, namely that retransmission "payload" (in quotes) includes everything following the fixed 12-byte RTP header of the source packet.


4. Section 6.2:

   The repair packet payload consists of the bits that are generated by
   applying the XOR operation on the payloads of the source RTP packets.
   If the payload lengths of the source packets are not equal, each
   shorter packet MUST be padded to the length of the longest packet by
   adding octet 0's at the end.

The repair packet does not appear to protect the source packets packet extension or CSRC list. I think what is missing here is the need to be explicit that the repair payload will be XOR of the source packets' CSRC list, extension header and payload?

The reverse thus need to be explicitly said in the recovery section also.

Mo: Same as the prior comment. The CSRC list and header extensions of the original source packet are protected as part of the repair "payload". I will clarify this with more explicit wording, namely that repair "payload" (in quotes) used in the XOR operation includes everything following the fixed 12-byte RTP header of the source packet.


Cheers

Magnus


Den 2018-03-22 kl. 17:41, skrev Roni Even (A):
Hi,
I would like to start a three week second WGLC on RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-07<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-07>07>.
The WGLC will end on April 11th , 2018

Note that the first WGLC was on the 05 version  and the 06,07 are incremental updates.
The slides from the IETF 101 payload session describe the changes see https://datatracker.ietf.org/meeting/101/materials/slides-101-payload-flexible-fec-00 .

Please send comments to the payload mailing list.
The double posting is to  notify RTCweb WG that the second  WGLC has started since this document is needed for RTCweb


Roni Even
Payload WG co-chair




_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/rtcweb


--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------