Subject: [Fecframe] SDP parameters and Media Type registrations

From: Mark Watson <[email-masked]>
Date: Tue, 21 Oct 2008 12:23:41 -0700

All,

In editing drafts for tomorrow, I have come across the following issue with
respect to FEC parameters.

We have defined a number of FECFRAME level SDP elements in
draft-ietf-fecframe-sdp-elements-01.txt, including the FEC Encoding Id,
repair-window and FEC Scheme Specific Object Tran smission Information.

I notice that in the media type registrations in the existing drafts, some
of this information is duplicated in media type parameters. Specifically,
the FEC Encoding Id is effectively duplicated in the media subtype, the
repair-window seems to be explicitly duplicated and in the 1D interleaved
scheme, at least, information which should be in the FEC Scheme-Specific
Object Transmission Information is signalled in explicit L and D parameters
(and in fact the Scheme-Specific information for this scheme is not
defined).

We should have some guidelines for determining which information should be
signalled using the generic FECFRAME SDP elements and what should be in the
media type-specific elements.

The basic issue is that where you rely on media type elements this implies
that the scheme can ONLY be used with protocols that are based on media
types, specifically RTP and SDP. The object of the FEC Framework was to
allow FEC Schemes to be used with any protocol compliant to the FEC
Framework. I guess it is OK if particular schemes want to be protocol
specific, but this rather misses the point of the framework.

...Mark
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 22 Oct 2008 00:07:06 -0700

Hi Mark,

When a scheme is defined in an RTP payload format draft, the media type
parameters are used to configure the fec scheme (L and D values in the
1d interleaved fec scheme, for example). This is the conventional way
for RTP. The elements we define in the sdp elements draft can be used by
schemes that are not using RTP.

But, I agree we should have some guidelines. There is also some missing
(possibly confusing) information in the sdp elements draft. We can
discuss these issues tomorrow in the meeting.

-acbegen

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Watson
Sent: Tuesday, October 21, 2008 12:24 PM
To: [email-masked]
Subject: [Fecframe] SDP parameters and Media Type registrations

All,

In editing drafts for tomorrow, I have come across the following issue
with respect to FEC parameters.

I notice that in the media type registrations in the existing drafts,
some of this information is duplicated in media type parameters.
Specifically, the FEC Encoding Id is effectively duplicated in the media
subtype, the repair-window seems to be explicitly duplicated and in the
1D interleaved scheme, at least, information which should be in the FEC
Scheme-Specific Object Transmission Information is signalled in explicit
L and D parameters (and in fact the Scheme-Specific information for this
scheme is not defined).

We should have some guidelines for determining which information should
be signalled using the generic FECFRAME SDP elements and what should be
in the media type-specific elements.

The basic issue is that where you rely on media type elements this
implies that the scheme can ONLY be used with protocols that are based
on media types, specifically RTP and SDP. The object of the FEC
Framework was to allow FEC Schemes to be used with any protocol
compliant to the FEC Framework. I guess it is OK if particular schemes
want to be protocol specific, but this rather misses the point of the
framework.

...Mark

---

From: Mark Watson <[email-masked]>
Date: Wed, 22 Oct 2008 08:36:22 -0700

Ali,

The term ³scheme² does not have any meaning for RTP. We have defined the
term ³FEC Scheme² for FECFRAME.

For RTP, yes, media types can define parameters for the media type, but this
is different from defining parameters for the FEC Scheme: obviously the RTP
people didn¹t know anything about FEC Schemes.

There are two points: we have defined a way for FEC Schemes to define
parameters, within the FEC Object Transmission Information. When an FEC
Scheme is used over RTP I don¹t see any reason to duplicate this information
in media type parameters: it just duplicates information and introduces FEC
Scheme-dependent formats where otherwise there would not be any.

Secondly, are your new RTP formats intended to be FEC Schemes ? If not, then
they can go straight to AVT without involving FECFRAME. If you want them to
be FEC Schemes you need to follow the framework.

...Mark

On 10/22/08 12:07 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

> parameters are used to configure the fec scheme (L and D values in the 1d
> interleaved fec scheme, for example). This is the conventional way for RTP.
> The elements we define in the sdp elements draft can be used by schemes that
> are not using RTP.
>  
> (possibly confusing) information in the sdp elements draft. We can discuss
> these issues tomorrow in the meeting.
>  
> -acbegen
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Watson
> I notice that in the media type registrations in the existing drafts, some of
> this information is duplicated in media type parameters. Specifically, the FEC
> Encoding Id is effectively duplicated in the media subtype, the repair-window
> seems to be explicitly duplicated and in the 1D interleaved scheme, at least,
> information which should be in the FEC Scheme-Specific Object Transmission
> Information is signalled in explicit L and D parameters (and in fact the
> Scheme-Specific information for this scheme is not defined).
> 
> that the scheme can ONLY be used with protocols that are based on media types,
> specifically RTP and SDP. The object of the FEC Framework was to allow FEC
> Schemes to be used with any protocol compliant to the FEC Framework. I guess
> it is OK if particular schemes want to be protocol specific, but this rather
> misses the point of the framework.
> 
> ...Mark 
>