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

["Roni Even (A)" <[e-mail]>]

Hi Mo,
I hope you noticed Magnus comments
Can you please respond.
I will be happy if we can finish the work on this document soon
Roni Even (A)
Payload WG co-chair


From: payload [mailto:[e-mail]] On Behalf Of Magnus Westerlund
Sent: Monday, June 11, 2018 5:15 PM
To: [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.

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?

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?

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.

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]>

----------------------------------------------------------------------