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

From: [email-masked]
Date: Fri, 7 May 2004 13:03:30 +0300

Please see in-line...

> 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, ...)?

> > do this. An out-of-flute-session-band method would also be 
> desirable to
> > allow a multitude of different content-specialised FLUTE receiver
> > applications on a host, but it seems that this is out of 
> SDP 'for FLUTE'
> > scope. 
> Why? If there is a need for an out-of-band way of conveying 
> FDT, then it 
> would seem that SDP is an appropriate place to put it.

My applications need to specify it outside of the FLUTE session SDP anyway (and not bound to SDP syntax). In general, content selection preceeds session configuration and initiation so allowing content description within SDP (to bind content and session) solves only a subset of use cases (not that it isn't a good idea to support communication of content-type capability requirements). FLUTE itself can give you this information in the FDT Instances (XML descriptions of the files in in the FLUTE session).

Allowing a URI (in the SDP) to point to content descriptions would be sufficient for the FLUTE usage I anticipate, but if someone has a practical (not only theroetical) need to describe content-types in FLUTE sessions for capability description I would be interested. (Note, I do not believe describing the files themsleves in the SDP is a sensible approach, even when they are known sufficiently in advance to make this possible.)

> > I've seen "0" used for a fmt "null" value - is that common 
> I'd prefer something like "-" to make it clear this is 
> distinct from a MIME 
> sub-type or RTP payload type number.

"-" it is - any objections? Would we need to IANA register this or just add to sdp-new?

On this subject, it seems fine to include "-" in a list so as to partially specify media types, e.g. <fmt list> = "sdp xml - zip" (if sdp were the default). Comments?

> >    m=data 32416 FLUTE/UDP 0
> > for generic FLUTE receivers which are distinct from the 
> user rendering
> > interface...
> >
> >    m=application 32416 FLUTE/UDP 0
> > for generic FLUTE receivers which include the user 
> rendering interface, so "integtrated multimedia applciations"...
> >
> >    m=application 32416 FLUTE/UDP pdf
> >    m=video 32416 FLUTE/UDP mpeg
> How are these different at the protocol level?

No difference at transport protocol level, only at paylaod (file) type.

> > Unfortunately, except in extremely tightly controlled 
> closed systems, a
> > FLUTE sender would not require the first two to be 
> differentiated (it's
> > upto the reciever to deal with mixed content), so both "data" or
> > "application + fmt=null" will mean exactly the same thing.
> Which would imply that we should have a single way of 
> signalling this, no?

Yes. And the only problem with this is the SDP (and sdp-new) comparative description of data and application. To allow only application, would this changed sdp-new description be feasible:

The difference between "application" and "data" is that the former is a media flow, which may or may not be displayed to the user, such as whiteboard information. The latter is bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user. 

If "data" were deprecited that would also solve the problem.

Cheers, Rod.

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

---

From: Stephen Casner <[email-masked]>
Date: Fri, 7 May 2004 09:27:23 -0700 (PDT)

On Fri, 7 May 2004 [email-masked] wrote:

> > 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