Subject: RE: [MMUSIC] SDP Session Description for FLUTE Sessions

From: [email-masked]
Date: Tue, 11 May 2004 15:54:21 +0300

Thanks Steve

Yes, that's the critical point. It boils down to whether m=application and the careful use (and registry) of the <fmt list> is sufficient to select the right application. If not, then m=video, etc, would be required. If so then we have the option to only use m=application.

I has to be said that an obvious group of FLUTE applications are those which don't consume the data at all and are just instructed to get all, or criteria-matching, files from a FLUTE session. These "applications" do not need or want to know about "application selection" and, more importantly, may not be the only kind of application on the receiving end of the session (some clients may be interested only in video clips, others are "crawling" to get everything). So there is a clear (and not exclusive) case where SDP would be primarily responsible for providing session parameters, but not so much the application selection.

A quick look at...
http://www.iana.org/assignments/media-types/index.html
...reveals that whatever path we go down some registration of subtypes is necessary. My main concern is that most of the multimedia types are registered as video and audio subtypes and not under application. So a serious, non-technical issue, is the invisible barrier of having to register many subtypes under application if application is all we use. The result would be that mostly "null" ("-"?) would be given and some "higher process" of service/media discovery would prepare the client with details of which application to choose for the "application-less" SDP (and IANA registration would be an orthogonal issue, time wise). (I'm happy with that, but I'm more pragmatic than perfect :)

Although I want an easy and simple solution (i.e. kill as many options as possible), I'm not convinced that disallowing other-than-application media type makes sense (unless it's to get rapid agreement).

So I propose that an I-D specifying "SDP for FLUTE" will say this:

"
SDP [] and IANA [] specify several media types which may be used in the media field(s) of an SDP description. It is generally RECOMMENDED to use the "application" media type for FLUTE [] media ("m=application...").

The Further Media Type (fmt) list of the SDP media field is used to describe media subtypes and thus may be used to select an appropriate application with which to receive the FLUTE session (in the case of applications which are specialised to certain content types and include FLUTE reception capabilities). The list may include, or consist entirely of, a single null subtype, represented by "-" (without the quotes). This serves the purpose of indicating that some other means is assumed of selecting the FLUTE application for reception, for some or all the files of a FLUTE session. Examples of another means include interrogating the FDT (File Description Table) Instance(s) of the FLUTE session and an alternative service description, as part of a service/media discovery framework, that would describe the content types. [Ed. this new "-" subtype could/should be IANA registered and selection of "-", "null", "0" needs consensus]

To avoid placing limitations on the selection of any congestion control (CC) building block (BB) [] used with FLUTE, it is STRONGLY RECOMMENDED to use the same media type and fmt list for all media of a FLUTE session. An exception to this could be if the CC BB where to channelise the FLUTE session according to file type. [Ed. no such CCBB has been proposed in RMT as far as I am aware]

These mechanisms implicitly provide a client with the ability to evaluate its capability to consume the included content types, and thus assess whether the session content is not render'able though lack of application support, potentially enabling pre-fetch of additional application codecs, and the like. However, archiving unusable files maybe of use to any caching host where capabilities may be modified at a later time, or the content may be subsequently forwarded to a capable host.

[Ed. the [] points represent a reference unless given earlier. Also does fmt mean further media types?]
"

Cheers, Rod.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Stephen Casner
> Sent: Friday, May 07, 2004 7:27 PM
> To: Walsh Rod (Nokia-NRC/Tampere)
> Cc: [email-masked]
> Subject: RE: [MMUSIC] SDP Session Description for FLUTE Sessions
> 
> 
> On Fri, 7 May 2004 [email-masked] wrote:
> 
> > > From: ext Colin Perkins [mailto:[email-masked]]
> > > I think that sometimes allowing a MIME content type, and sometimes
> > > using "m=data" will be very confusing. We should have a single
> > > definition, if possible.
> >
> > It boils down to what is needed to configure the FLUTE receiver
> > application. For mixed content FLUTE receivers a we need to have
> > "content is mixed or unspecified" description (either "m=data" or
> > "m=application" with null fmt would do the job. For single content
> > session receivers (e.g. a video player) we could allow multiple
> > media types which may simplify receiver operation but does
> > complicate (confuse) the SDP. I think this would be fine to only
> > allow "mixed content" media type.
> >
> > Is anyone unhappy if we only allow "mixed content" media type (in
> > the m="media type") and disallow specifics (audio, video, ...)?
> 
> Well, the original design and application of SDP in the MBone was to
> allow selection of the right application to receive an advertised
> stream.  Mark Handley has made this point on numerous occasions in the
> past.  There is a distinction between the information needed to select
> the right receiving application, and then the details that the
> application needs to configure itself.  We get into trouble because
> that boundary is not always clear, or not the same over the space of
> all applications.
> 
> To answer specifically for FLUTE, is it likely that there will be
> different applications to be invoked for receiving video via FLUTE
> versus, say, file download?  My guess is the answer would be yes.  So,
> unless the expected design for FLUTE applications is that there would
> be some front end that is required to be able to receive (or at least
> consider receiving) anything, and it is responsible for dispatching to
> another level, I think we need to make a distinction at the SDP level.
> 
> In particular, if there is a video simulcast with multiple
> transmission methods, one of which is FLUTE and the other is some
> other protocol, and I have a FLUTE file download receiver on my box
> but no capability to receive video via FLUTE, I might not be able to
> make an informed decision about which of the simulcast streams to
> choose.
> 
>                                                         -- Steve
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic