Subject: [MMUSIC] SDP Session Description for FLUTE Sessions

From: [email-masked]
Date: Thu, 6 May 2004 12:44:20 +0300

To summarise the discussion so far:

Media descriptions (a "m=" line and a "a=" line) can be used to specify the group/destination address & port of FLUTE session channels.

We need a new protocol id for FLUTE. It will be either FLUTE/UDP or UDP/FLUTE and the difference seems trivial to implementations.

We need to understand how media types work with FLUTE. It is possible to allow any media types (of SDP and IANA) as long at the FLUTE transported files adhere to this. It is also possible to recommend that "application" media is used.

The <fmt> can be used to specify the reciever application type (e.g. "wb" for whiteboard). A "null" (i.e. dummy) fmt value could be used to say 'the application has to work out the file MIME types some other way', which is the expected use in many cases. FLUTE's FDT is one way to 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. I've seen "0" used for a fmt "null" value - is that common practice?

So we might be looking at...
   m=application 32416 FLUTE/UDP 0
   a=
...in a typical case. Note, "m=data..." is also on the cards for the typical case.

Personally I see:

   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
for homogeneous single content-specific FLUTE sessions

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.

(Note "FLUTE/UDP", "data" and fmt values "0" are not currently IANA registered).

Since making channels content specific would interact with the LCT congestion control building block used, it's probably wise to strongly recommend that this is only done by a congestion control building block and not allow SDP to interfere with that. Thus, I propose that the same media type and fmt value is used for all "m=" lines with the FLUTE protocol id in a singe SDP description.

It doesn't harm to have the links in one handly place:
FLUTE: http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-07.txt
SDP: http://www.ietf.org/rfc/rfc2327.txt
SDP with IPv6: http://www.ietf.org/rfc/rfc3266.txt
SDP-NEW: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-15.txt
IANA/MIME Media Types: http://www.iana.org/assignments/media-types/index.html

Cheers, Rod.

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 6 May 2004 13:44:23 +0100

On Thursday 06 May 2004 10:44, [email-masked] wrote:
> Media descriptions (a "m=" line and a "a=" line) can be used to specify
> the group/destination address & port of FLUTE session channels.
>
> We need a new protocol id for FLUTE. It will be either FLUTE/UDP or
> UDP/FLUTE and the difference seems trivial to implementations.
>
> We need to understand how media types work with FLUTE. It is possible to
> allow any media types (of SDP and IANA) as long at the FLUTE transported
> files adhere to this. It is also possible to recommend that
> "application" media is used.

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.

> The <fmt> can be used to specify the reciever application type (e.g.
> "wb" for whiteboard). A "null" (i.e. dummy) fmt value could be used to
> say 'the application has to work out the file MIME types some other
> way', which is the expected use in many cases. FLUTE's FDT is one way to
> 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.

> I've seen "0" used for a fmt "null" value - is that common 
> practice?

I'd prefer something like "-" to make it clear this is distinct from a MIME 
sub-type or RTP payload type number.

> for generic FLUTE receivers which include the user rendering interface,
> so "integtrated multimedia applciations"...
>

How are these different at the protocol level?

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

-- 
Colin Perkins
http://csperkins.org/