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

Magnus Westerlund <> Fri, 08 December 2017 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46786124B17; Fri, 8 Dec 2017 04:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I97wrQIwAUGE; Fri, 8 Dec 2017 04:48:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E795C124D68; Fri, 8 Dec 2017 04:48:29 -0800 (PST)
X-AuditID: c1b4fb3a-3d5ff70000003538-b5-5a2a8a1b3558
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 40.91.13624.B1A8A2A5; Fri, 8 Dec 2017 13:48:28 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 8 Dec 2017 13:48:27 +0100
To: Roni Even <>, "" <>
CC: "" <>
References: <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Fri, 8 Dec 2017 13:50:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060606050603090003020403"
X-Originating-IP: []
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2J7lK5Ml1aUQU8jq8Wli2eZLD4dO89i sfZfO7sDs0fLkbesHkuW/GQKYIrisklJzcksSy3St0vgynh3oIWtYN0vxor2ed9ZGhiXXmDs YuTkkBAwkei8dB7I5uIQEjjMKPFj0TZ2CGczo0TL/Q4mkCphgQiJ549us4HYIgLeEhunH2cH sZkF1CXuLD4HZgsJBEv8vDEBrJ5NwELi5o9GsHpeAXuJz2ePgm1jEVCRODJnMSuILSoQI3G4 ZzorRI2gxMmZT1hAbE6BEImlj/tZQI5gFuhmlNjw8h0rxAJtiYamDlaIs5Ukrs+7zjKBUWAW kv5ZyHpmgR0YJrHj4QUmCFtcounLSqi4rcSdubuZIWxtiWULX0PZuhKLtq1gxxS3lpjx6yAb hK0oMaX7IVSNqcTrox8ZIWwjiXd7GtkXMPKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiM wYNbflvtYDz43PEQowAHoxIP77okrSgh1sSy4srcQ4wqQHMebVh9gVGKJS8/L1VJhJfLHyjN m5JYWZValB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2ampBahFMlomDU6qBUXyN9Ksls/QU J/2ziryb6SB1IntrsMm/MwEbfiuvjZOoudfe27qam3P7v0sLHr8zftHy72kKS7yRzT8Hr7e1 5ruTMiY8j5pfmtGkW9cfvSqyoexVYOu368xzzpU8qti25fZ6kZ3GT69o/9e83HLghpcGw3eZ i7J9LxizN7RVtP1d8cM0691bIyWW4oxEQy3mouJEAGXQwKzJAgAA
Archived-At: <>
Subject: Re: [rtcweb] 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 12:48:34 -0000


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

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.

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.

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.

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.

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.

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.

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 ..."

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.

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.

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.

12. Section 6.2:

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

13. Section 6.3.2:

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

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.



Den 2017-11-17 kl. 03:35, skrev Roni Even:
> Hi,
> 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 7^th
> 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: