Re: [payload] Payload WG notes - Please read

[Varun Singh <[e-mail]>]

On Wed, Jul 22, 2015 at 10:52 AM, Jonathan Lennox <[e-mail]> wrote:
>
> On Jul 22, 2015, at 9:43 AM, Varun Singh <[e-mail]> wrote:
>
> Below is the outcome of the side meeting: provide corrections if I the
> summary is inaccurate.
>
> It was decided that
> 1. We will need to revisit how FEC operates with PERC-enabled middleboxes.
> This is currently a non-goal.
> 2. an identifier will be in the FEC payload. For now this is SSRC. However,
> if a needed this could be replaced by another identifier (e.g., RSID). .
>
> 3. keep the encapsulated length as 16 bits. Add the 4 bits of SSRC Counter
> elsewhere, this is still TBD.
>
> To summarise the version 3/3 in the slides was accepted.
>
> On point 2 — my opinion in the side meeting was that even if we define
> identifiers like RSID in the future, the identifier in FlexFEC should
> nonetheless remain an SSRC.  The reason is that the FEC receiver needs to
> know, after an SSRC change, whether the packets being FEC’d come from the
> old SSRC or the new SSRC.

If there is agreement on SSRC, I will not put any editor's note or
placeholder for replacing it.

>
> It was also pointed out that the FEC format, as a degenerate case, can also
> perform retransmission (by creating a FEC packet that covers only a single
> source packet).  This may be able to resolve some of the annoyances of the
> RFC 4588 RTX format, notably in a BUNDLE context — it avoids payload type
> explosion (because the source PT is in the packet), and gives you stream
> association automatically.

True, I will add some text related to this. However, if we want to use
this in rtcweb, rtp-usage may want to express an opinion on using this
in addition to RFC4588?


-- 
http://www.callstats.io