RE: draft-mehta-rmt-flute-sdp-00.txt
<Rod.Walsh <at> nokia.com>
2004-09-07 06:27:31 GMT
Thanks Mike,
Good question!
Certainly better discussion and explanation is needed in the draft for 01.
These FEC parameters (of flute-sdp) are for capabilities description for the session. (Note, any
"FDT-like" fuller description of files in the session could give the FEC parameters per file). FLUTE's
FDT syntax (and codepoint header field usage) allows complete specification of these FEC parameters
in-band with FLUTE (per file). Thus machine configuration can be performed using FLUTE alone.
There are 5 main reasons that the FEC Encoding and instance IDs are optional capabilities descriptions:
1. It is not always necessary to explicitly describe the FEC capabilities in advance of the session - e.g.
for simple (and short) sessions it can be more elegant to discover this from the session (FDT) itself (even
when some mechanism for machine-readable session parameters, such as IP addresses and ports, is wanted
in advance)
2. There may be some other out-of-band discovery of FEC capability requirements (e.g. well
known-FEC/standardised capabilities for a certain application, verbal agreement between a group,
etc.) that provides the FEC capability information. We do not want to prevent this, and in this case
repeating the information in SDP would be unnecessary and wasteful (and probably result in
implementations not following the flute-sdp specification)
3. FLUTE defaults to null-fec and support for this is mandatory for FLUTE anyway so it is a given (capability
requirement) which does not need to be described by the SDP. In cases where only null-fec is required,
there is no use in specifying any FEC Enc(+Inst) IDs in the SDP (though it is allowed).
4. In cases where a FLUTE session description (SDP file) is not defined once for all time, it is possible that
the FEC usage is not known in advance and the FEC capabilities would only be added to the SDP in a later
(Continue reading)
RSS Feed