Re: [MMUSIC] Re: SDP descriptors for ALC

[inline]

On 7 Feb 2006, at 15:41, [email protected] wrote:
> 3 issues: a=flute-tsi; "*" fmt; ALC/UDP rules.
...
> ALC/UDP rules...
>
> I'm not sure I fully grip the point. ALC is underspecified. E.g. OMA's
> use of ALC is only feasible as they create a fully specified version
> (actually by binding it to ESG metadata - a little beyond IETF  
> Transport
> Area's mandate), and for some reason they like to still call it ALC
> giving a confusing impression that it's underspecified. Check out the
> LCT and ALC RFCs or revised I-Ds and you come across a host of  
> options,
> most of which FLUTE bangs down to fully specified or leaves for
> flute-sdp to fill in the parameters. Use of the checkpoint field is
> totally open in ALC and in some fully specified versions it'll make a
> sense to give a mapping in the session description (SDP) and in others
> not. This is one example of something I simply do not want to touch
> since fancy use of this field is not backed up by the same kind of
> implementation rigour we have already got for FLUTE. OTOH, much of the
> flute-sdp semantics could be used for LCT sessions in general and  
> making
> this explicit has its distinct advantages (I won't be picking up the
> pieces of OMA-IETF divergence if it occurs, and having fought the for
> DVB+3GPP+IETF I'm not sure I would recommend the job for it's fun  
> factor
> :)
>
> So allowing underspecified ALC/UDP media means that two or more hosts
> can "out-of-band" figure out what the full-spec would be and still use
> the session description of underspecified ALC.
>
> And this brings us onto the reason I've taken these 3 points out of
> order. ALC vs. LCT. ALC is LCT with a few header extensions. If you  
> were
> to question why have separate LCT and ALC specifications and not just
> one combined one you wouldn't be the first and certainly not the  
> last as
> there is no attempt to combine them and disturb mature specification
> text and standards progress (you'd get verbose emails like this all  
> over
> the place :). It's LCT which defined the basic session semantics  
> and ALC
> and FLUTE add some more expectations of senders and recievers. As  
> such,
> I think I made and error in my response to Imed in that I should have
> suggested "lct" instead of "alc" in the text string. My mind is  
> mulling
> this over during my short commutes so I may have an epiphany before
> tomorrow.
>
> Practically, if underspecified ALC or LCT is OK then we can bundle  
> these
> basics into flute-sdp, if not then forget it and let's stonewall the
> whole discussion until the 3GPP+DVB+IETF aligned flute-sdp has been
> published. (I am certainly unwilling to work on two at once and  
> judging
> by the number of actual text writters this may be a bit of a problem).

Is it useful to signal under-specified ALC or LCT transport? Unless I  
misunderstood, wouldn't that be signalling an incomplete building block?

Colin