Re: [AVT] Commetns on draft-luby-avt-rtp-generic-fec-00.txt

[Ross Finlayson <finlayson at live.com>]

Magnus,

Thanks for the feedback.

> 2. Secondly, by using the RMT building block there is huge question of how 
> to ensure interoperability. To be able to use this in either a streaming 
> session one can only pray that the receiver will support the FEC decoder 
> that is needed. Certain application specification, like ISMA or 3GPP would 
> need to specify this to get it to work. For SIP there will be need to 
> define a way to actually perform negotiation of these in a suitable way.

Note that this draft requires a familiarity with the RMT Working Group's 
"FEC Building Block" work (RFC 3452), which it uses as a Normative 
Reference.  The issue of ensuring interoperability (of FEC implementations) 
is already completely addressed by that work.

In particular, each instantiation of the "FEC Building Block" completely 
defines a particular FEC scheme (algorithm), along with IANA registration 
of "FEC Encoding ID" and (where appropriate) "FEC Instance ID" 
parameters.  These parameters are also parameters to the RTP payload format 
defined by this draft.

Thus, any use of this RTP payload format completely defines the FEC scheme 
that is being used, including how "source blocks" are mapped to encoded 
"data packets" (and thus RTP packets), and vice versa.


However, one issue that is *not* currently addressed by the draft is: How 
to specify the type of the original source data - i.e., the type of data 
that is FEC-encoded at the sender end, and recovered by FEC decoding at the 
receiver end.  Note that it is possible for the original source data to be 
a sequence of RTP packets, but this is not a requirement.  (For example, 
the original source data could be something like a MPEG Transport 
Stream.)  However, for the particular (and likely to be common) case of the 
original source data being a RTP stream, there will need to be some way to 
define - within the SDP description - the RTP payload format of the 
original data.  As you noted, the UXP proposal had a solution for this - by 
including the RTP payload type code(s) for the original data on the "m=" 
line (along with that for the FEC payload type), and adding appropriate 
"a=rtpmap:" and "a=fmtp:" lines describing the original data 
stream.  However, we would be interested in hearing thoughts about whether 
this solution is adequate, and, if not, how this might be specified better.


Finally, regarding the "UXP" work: What is the status of this?  The 
Internet Draft for this has currently expired, and the only reasonably 
up-to-date draft that I was able to find online is
        http://www.rnp.br/ietf/internet-drafts/draft-ietf-avt-uxp-06.txt

Is this an AVT group work item?

IMHO, rather than trying to define a payload format specifically for one 
particular FEC scheme (Reed-Solomon), it would be better for Reed-Solomon 
to be defined as a RMT FEC Building Block instantiation (something that's 
currently underway, I believe), and then just use the generic FEC RTP 
payload format.

        Ross.



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt