Re: [rtcweb] [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction

"Mo Zanaty (mzanaty)" <> Fri, 08 December 2017 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1AE3128B38; Fri, 8 Dec 2017 10:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r-SiZG_hNqRi; Fri, 8 Dec 2017 10:52:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33A34128B8E; Fri, 8 Dec 2017 10:52:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=32185; q=dns/txt; s=iport; t=1512759154; x=1513968754; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D6ioEaPly2C/UqpwDqT7GAdGGyIo5w965SDsW6rv5Bo=; b=ZhdisYbWBC86ILrlXAJdEL0ijAEjmzPCwhQ7CXD/aTbrQ736pLOGyICc C9D5HpNSr+WBxkO+M1IKKGFXm00Q/8Nd+BpqwsrbUIf9QfJc70nGeA/Kw 0k6AHsKXsGLDI15EF2x8bblIXKNgzBs6NYygHRm96yBS0rTz/FyVCtplR 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AADu3Spa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS9mdCcHjhyPAYF9lwwUggEKGAEKhElPAoRfPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUiAQEBAQMBAStBCw4CAgEIEQMBAhYLBwcbDAsUCQgCBAENBQmJO2QQq?= =?us-ascii?q?jMmij4BAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYNWgguBVoFpgyuCWEsmgRERHDg?= =?us-ascii?q?fhTkFikWYQwKHd40nghaGEos5ikCCSIknAhEZAYE6AR85JoEpbxU6gikJgkYfG?= =?us-ascii?q?YFOeIkhgRUBAQE?=
X-IronPort-AV: E=Sophos; i="5.45,378,1508803200"; d="scan'208,217"; a="41626922"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 18:52:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vB8IqXMF016055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 18:52:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 12:52:32 -0600
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Fri, 8 Dec 2017 12:52:32 -0600
From: "Mo Zanaty (mzanaty)" <>
To: Magnus Westerlund <>, Roni Even <>, "" <>
CC: "" <>
Thread-Topic: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction
Thread-Index: AQHTcFW0HojzYcah6EWMBE4vaDiXiA==
Date: Fri, 8 Dec 2017 18:52:32 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D65040BB7693Dmzanatyciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [rtcweb] [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Dec 2017 18:52:38 -0000

Hi Magnus,

Thank you for the review and comments. We are updating the draft to address your comments as noted below (see Mo: inline).


From: payload <<>> on behalf of 'Magnus Westerlund' <<>>
Date: Friday, December 8, 2017 at 7:50 AM
To: Roni Even <<>>, "<>" <<>>
Cc: "<>" <<>>
Subject: Re: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction


Sorry for being a day late, but here are my WGLC comments.

I thought this was in better shape, but clearly not ready. I actually have not reviewed all in detail. I hope I will have time to do that when you have addressed these issues.

1. Section 4.2:

            |          IP Header           |
            |       Transport Header       |
            |          RTP Header          | __
            +------------------------------+   |
            |          FEC Header          |    \
            +------------------------------+     > RTP Payload
            |        Repair Symbols        |    /
            +------------------------------+ __|

                    Figure 9: Format of repair packets

The bracket appears to big as it indicates that parts of the RTP header is payload. I would prefer drawing this like this:

            |          IP Header           |
            |       Transport Header       |
            |          RTP Header          |
            +------------------------------+ --+
            |          FEC Header          |    \
            +------------------------------+     > RTP Payload
            |        Repair Symbols        |    /
            +------------------------------+ --+

                    Figure 9: Format of repair packets

Mo: Agreed, we will update the ASCII art.

2. Section 4.2:

   o  Synchronization Source (SSRC): The SSRC value SHALL be randomly
      assigned as suggested by [RFC3550].

I would suggest that you make it clear that the SSRC value should be set randomly for a particular Repair flow, to avoid the misinterpretation that each packet should have a random SSRC value.

Mo: Agreed, will do.

3. Section 4.2:

This allows the sender to
      multiplex the source and repair flows on the same port, or
      multiplex multiple repair flows on a single port.

I would suggest that you rewrite this like this:

This allows the sender to
      multiplex the source and repair flows in the same RTP session, or
      multiplex multiple repair flows in a single RTP session.

Mo: Agreed, we will reword as suggested.

4. Section 4.2:

The repair
      flows SHOULD use the RTCP CNAME field to associate themselves with
      the source flow.

I think you should reformulate this to be more precise to say:

The repair
      flows SHOULD use the same RTCP SDES CNAME value as the source flows to associate them when
source and repair flows originate from the same endpoint.

Mo: Per the point below, I am inclined to remove CNAME guidance or restrictions entirely, since they seem irrelevant.

5. Section 4.2:

      In some networks, the RTP Source, which produces the source
      packets and the FEC Source, which generates the repair packets
      from the source packets may not be the same host.  In such
      scenarios, using the same CNAME for the source and repair flows
      means that the RTP Source and the FEC Source MUST share the same
      CNAME (for this specific source-repair flow association).  A
      common CNAME may be produced based on an algorithm that is known
      both to the RTP and FEC Source [RFC7022].  This usage is compliant
      with [RFC3550].

I think this may actually be the wrong way of handling this. Is it really important that the CNAME can be used to determine which SSRC are plausible as source flows for a given repair flow. If we skip that feature, one can use CNAMES as usual where they are primarily depending on the endpoint that originates the RTP flow with a given SSRC and the synchronization context. As the repair packet is indicating explicitly which source packets, this should not be a real issue.

Thus, I suggest that the above text removes sentence with MUST. Instead one could add the following sentence directly after the propsed sentence in issue 4:

However, repair flows that protects source flows from multiple different endpoints SHOULD instead use a CNAME value associated with the Repair Flow sending endpoint.

And the above text could be deleted.

Mo: Since all source and repair streams must be in the same RTP session, I agree CNAME is mostly irrelevant, and I am inclined to remove all mention of CNAME, except maybe to say it should follow RFC 7022.

6. Section 4.2:

Figure 9 should include the CSRC list and the FEC payload formats use of the CSRC list should be listed prior to Figure 10. This as the CSRC list is part of the RTP header.

Mo: Agreed, the text on CSRC_i / list will move up before Figure 10.

7. Section 4.2:

   o  The SN base_i (16 bits) field indicates the lowest sequence
      number, taking wrap around into account, of the source packets for
      a particular SSSRC (indicated in CSRC_i) protected by this repair

Note spelling SSSRC / SSRC.

Mo: Noted.

8. Label on Figures 12, 13, 15:

They all says "Protocol format for ..."

While I think for clarity they should say: "Payload FEC header format for ..."

Mo: Ok, we will rename the labels.

9. Section 4.2:

   Note that the parsing of this packet is different.  The sequence
   number (SN base_i) replaces the length recovery in the FEC packet.
   The CSRC Count (CC) which would be 1, M and N would be set to 0, and
   the reserved bits from the FEC header are removed.  By doing this, we
   save 64 bits.

I actually don't fully understand this paragraph:

In the third sentence: Why will the CC field be 1? This is the CC field value of the reconstructed (retransmitted) packet, isn't it? Thus, you can't say anything about its original value here? The CC field value in the RTP header of the FEC packet will have CC = 1, but not this field.

Then you have a confusion around what M and N is. Actually, I think the M (Columns) needs to change letter to something that isn't used in the packet already. M is colliding with M (marker bit) recovery field, thus please change the letter.

Mo: We will clarify this by splitting into separate sections for each repair format variant, and perhaps use L/D instead of M/N (to match the SDP parameters L/D).

10. Figure 15:

When retransmitting an packet, where is the source packets CSRC list going? That should be indicated in this figure for clarity. Same is true for RTP header Extensions present in the source packet.

Mo: We will clarify this by splitting into separate sections for each repair format variant. For all variants, all bytes after 12 (including any CSRC list or extension headers) are considered "payload" (we will find a better word for this since payload is obviously very overloaded).

11. Section 6.2:

   The FEC header includes 12 octets (or upto 28 octets when the longer
   optional masks are used).

This is not strictly true, it is dependent on the number of SSRCs that the packet repairs.

Mo: Yes, we will clarify this.

12. Section 6.2:

Missing discussion of what to do with source packet CSRC list and RTP header extension.

Mo: Yes, the updates to section 4.2 will be echoed in 6.2.

13. Section 6.3.2:

Missing text for recovery of source packets CSRC list and RTP header extensions.

Mo: Yes, we will add this.

14. Section 6.2:

   Due to this possible padding and mandatory FEC header, a repair
   packet has a larger size than the source packets it protects.  This
   may cause problems if the resulting repair packet size exceeds the
   Maximum Transmission Unit (MTU) size of the path over which the
   repair flow is sent.

I think this should add a recommendation that the media encoding and RTP payload packetization for source packets should be adjusted to a lower maximum packet size to allow space for the FEC headers to avoid forcing them into being fragmented. This of course only is possible in cases where the source packet generating endpoint is aware of the addition of the FEC packets and its strategy of combining them.

Mo: Agreed, this seems like an appropriate recommendation, so we will add it.



Den 2017-11-17 kl. 03:35, skrev Roni Even:
I would like to start a three week WGLC on RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05<>;.
The WGLC will end on November 7th

Mo has posted some clarifications to the payload WG mailing list  payload mailing list archives<>

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

Roni Even
Payload WG co-chair

rtcweb mailing list<>


Magnus Westerlund

Media Technologies, Ericsson Research
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto:<>