[AVT] FW: [Rmt] Session Description for FLUTE Sessions (aka FLUTE SDP)

[Rod.Walsh at nokia.com]

Just in case someone's interested in SDP for FLUTE and gets AVT more regularly than MMUSIC or RMT emails...

-----Original Message-----
From: rmt-admin@ietf.org [mailto:rmt-admin@ietf.org]On Behalf Of ext
Rod.Walsh@nokia.com
Sent: Wednesday, April 28, 2004 8:42 PM
To: mmusic@ietf.org; rmt@ietf.org
Subject: [Rmt] Session Description for FLUTE Sessions (aka FLUTE SDP)


Hello World

I would like to ask for ideas and opinions on a session description for FLUTE sessions. (FLUTE is the unidirectional file delivery protocol from the Reliable Multicast Transport WG - draft-ietf-rmt-flute-07.txt - like an RTP for files at a small stretch of the imagination).

In short, to use FLUTE certain out-of-band information is mandatory and optional. Although this can be sought by any number of proprietary and closed methods, it's likely to be a big help to have an open document on how to describe this in a way also suitable for the general Internet. Thus, I want to build up some initial expert (and novice) opinions on the semantics and syntax of what would be needed.

FLUTE and ALC provide a starter-kit of data items which can easily be turned into a semantic description. For syntax, it seems SDP is the natural choice and SDP already comes with a decent tool kit of attributes to reuse. (This is not to say SDPng and others would be inappropriate, just that to start the work now SDP seems to be the only show in town).

Some other relevant context is that 3GPP (MBMS/SA4) has identified the need for such a FLUTE session description, and the time constraints of 3GPP release 6 (September freeze) offer a minimal window to do a 2 way swap of ideas and agreement before a standard is needed. I certainly have no experience in turning out RFC's in 5 months flat (anyone? :), but a serious attempt to work on the issue in the next few months would be an excellent way of ensuring a single interoperable method (and open standard). In addition, I am expecting ETSI/DVB to make a "call for technologies" in this area within a few weeks so the benefits of rapid progress should be pretty obvious (but don't shoot me for suggesting it :)

Who wants to get involved?

Cheers, Rod.

_______________________________________________
Rmt mailing list
Rmt@ietf.org
https://www1.ietf.org/mailman/listinfo/rmt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt