RMT R. Walsh
Internet-Draft I. Curcio
Expires: December 3, 2010 Nokia Research Center
J. Peltotalo
S. Peltotalo
Tampere University of Technology
H. Mehta
June 2010
SDP Descriptors for FLUTE
draft-mehta-rmt-flute-sdp-06
Abstract
This document specifies the use of SDP to describe the parameters
required to begin, join, receive data from, and/or end FLUTE
sessions. It also provides a Composite Session SDP media grouping
semantic for grouping media streams into protocol-specific sessions,
such as multiple-channel FLUTE sessions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Walsh, et al. Expires December 3, 2010 [Page 1]
Internet-Draft SDP Descriptors for FLUTE June 2010
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Walsh, et al. Expires December 3, 2010 [Page 2]
Internet-Draft SDP Descriptors for FLUTE June 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. FLUTE Descriptors . . . . . . . . . . . . . . . . . . . . . . 6
3.1. FLUTE Protocol Identifier . . . . . . . . . . . . . . . . 7
3.2. Composite Session Semantics . . . . . . . . . . . . . . . 8
3.2.1. Composite Session Semantics for FLUTE Sessions . . . . 8
3.2.2. Composite Session Semantics for Protocols other
than FLUTE . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Source IP Address . . . . . . . . . . . . . . . . . . . . 10
3.4. Transport Session Identifier . . . . . . . . . . . . . . . 11
3.5. Session Timing Parameters . . . . . . . . . . . . . . . . 12
3.6. Channelisation Descriptors . . . . . . . . . . . . . . . . 12
3.6.1. Number of Channels . . . . . . . . . . . . . . . . . . 12
3.6.2. Destination IP Address and Port Number for Channels . 13
3.7. FEC Object Transmission Information . . . . . . . . . . . 15
3.8. Content Description Pointer . . . . . . . . . . . . . . . 16
3.9. Bandwidth Specification . . . . . . . . . . . . . . . . . 16
3.9.1. Bandwidth Specification for Composite Sessions . . . . 17
3.10. SDP Specific Parameters . . . . . . . . . . . . . . . . . 17
4. SDP Syntax Examples . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.1. Transport Protocol . . . . . . . . . . . . . . . . . . . . 22
6.1.1. Media formats ("fmt") . . . . . . . . . . . . . . . . 22
6.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 22
6.3. Composite Session Token to Differentiate FLUTE Sessions . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Use of FEC attributes with RTP sessions
(informative) . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Further Design Logic for FEC-OTI Descriptors . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Walsh, et al. Expires December 3, 2010 [Page 3]
Internet-Draft SDP Descriptors for FLUTE June 2010
1. Introduction
The Session Description Protocol (SDP) [RFC4566] provides a general-
purpose format for describing multimedia sessions in announcements or
invitations. SDP uses an entirely textual data format (the US-ASCII
subset of UTF-8 [RFC3629]) to maximize portability among transports.
SDP does not define a protocol, but only the syntax to describe a
multimedia session with sufficient information to participate in that
session. Session descriptions may be sent using arbitrary existing
application protocols for transport (e.g. FLUTE
[I-D.ietf-rmt-flute-revised], SAP [RFC2974], SIP [RFC3261], RTSP
[RFC2326], HTTP [RFC2616], email etc.).
SDP defines two protocol identifiers that represent unreliable
connectionless protocols. These are RTP/AVP and UDP. These are
appropriate choices for multimedia streams. [RFC4145] defines
protocol identifiers for connection-oriented reliable transports: TCP
and TCP/TLS.
This document defines a new protocol identifier for File Delivery
over Unidirectional Transport (FLUTE) protocol
[I-D.ietf-rmt-flute-revised] and other required SDP attributes for
initiating a FLUTE session. The formal ABNF syntax [RFC5234] is used
for the attributes. This SDP syntax is independent of Any Source
Multicast (ASM) or Source Specific Multicast (SSM) is used to route
the media.
Note, this document may also be used to describe sessions of the
experimental FLUTE specification [RFC3926].
Walsh, et al. Expires December 3, 2010 [Page 4]
Internet-Draft SDP Descriptors for FLUTE June 2010
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Walsh, et al. Expires December 3, 2010 [Page 5]
Internet-Draft SDP Descriptors for FLUTE June 2010
3. FLUTE Descriptors
The FLUTE specification [I-D.ietf-rmt-flute-revised] describes the
optional and required parameters for a FLUTE session. This document
specifies the SDP parameters for FLUTE sessions that can be used for
the discovery of FLUTE download and/or service announcement sessions.
Listed below are the required and optional SDP parameters for FLUTE
sessions (the parameters introduced, or made mandatory, by this
specification but not inherited from the FLUTE specification are
marked with an asterisk "*").
The required parameters are:
o The source IP address;
o The number of channels in the session;
o The destination IP address and port number for each channel in the
session;
o The Transport Session Identifier (TSI) of the session;
o An indication that the session is a FLUTE session;
* The start time and end time of the session.
The optional parameters are:
o FEC Object Transmission Information;
o Some information that tells receiver in the first place, that the
session contains files that are of interest;
o Definition and configuration of congestion control mechanism for
the session [Editorial note: under consideration];
o Security parameters relevant for the session [Editorial note:
under consideration];
* Bandwidth specification.
(Note, best practise to provide parameters for FLUTE's optional
content encoding of FDT Instance is in-band within FLUTE session and
is therefore not specified using SDP.)
(Note, the out-of-band FEC Object Transmission Information useful for
FLUTE sessions is limited to capabilities describing FEC Encoding
ID(s) and FEC Instance ID(s) as FLUTE provides header fields for
Walsh, et al. Expires December 3, 2010 [Page 6]
Internet-Draft SDP Descriptors for FLUTE June 2010
machine configuration for object reception. This specification also
provides a "fec-oti-extension", as an informative appendix, so that
the same SDP syntax can be used to describe sessions using protocols
other than FLUTE that do not have an in-band mechanism for FEC
machine configuration.)
The semantics of a FLUTE session within an SDP description differ
slightly from that of the well-establish RTP session descriptions. A
FLUTE session includes one or more FLUTE channels which are each a
distinct media stream. (Note, SDP specification [RFC4566] use of the
term media stream is semantically equivalent to the FLUTE
specification use of the term channel.) Generally, each RTP media is
recognised as a distinct RTP media session. Hence, to preserve
harmony with RTP media sessions within SDP descriptions, the optional
Composite Session mechanism is specified, using the grouping
framework [RFC5888].
The description of these parameters in SDP is presented in the
following sections.
3.1. FLUTE Protocol Identifier
The following is the ABNF syntax for an "m=" line, as specified by
RFC4566 [RFC4566]:
media-field = "m=" media SP port ["/" integer] SP
proto 1*(SP fmt) CRLF
We define a new value for the "proto" sub-field: FLUTE/UDP. The
FLUTE/UDP protocol identifier specifies that the session being
described will use the FLUTE [I-D.ietf-rmt-flute-revised] protocol on
top of a UDP connection.
As described below, more than one FLUTE session may be described by a
single SDP using the Composite Session mechanism.
The fmt (format) list may be ignored for FLUTE. The fmt list of
FLUTE "m=" lines MAY contain a single "*" character to indicate that
miscellaneous and unspecified MIME types (file formats) are contained
in the FLUTE session. Use of any other values (MIME types) in a
FLUTE fmt list is out of scope of this specification. "0" is known to
be used in the fmt list to represent the same as "*", in a non
standard way, and so implementers may take this into account. An
example of FLUTE/UDP protocol identifier is shown in Section 4.
FLUTE is a general file delivery protocol and so it is not considered
necessary to identify a list of media types per FLUTE session or
channel in the session description. [Editorial note: as part of the
Walsh, et al. Expires December 3, 2010 [Page 7]
Internet-Draft SDP Descriptors for FLUTE June 2010
revised FLUTE (FDT schema) version discussion we may consider using
fmt values (1 and 2) to describe FLUTE/FDT version number.]
3.2. Composite Session Semantics
The Composite Session mechanism enables the grouping of media lines
in to distinct sessions. The complete Composite Session semantics
are protocol-specific - as determined by the protocol id of the
grouped media lines. This section defines the Composite Session
semantic generically and protocol id independently. Subsection
3.2.1. defines the FLUTE/UDP protocol identifier specific semantic.
This mechanism is useful where multiple FLUTE sessions are described
as part of a larger service or application, and so where maintaining
and delivering session descriptions together (with a shared delivery
fate) is good practice. It may also improve bandwidth efficiency by
eliminating repetition of redundant descriptors that would be
necessary with multiple discrete SDP instances.
The Composite Session mechanism inherits the "group" and "mid"
attributes from the SDP grouping framework [RFC5888] and introduces
the "CS" (Composite Session) token as a "semantics-extension".
When the Composite Session mechanism is used: the SDP grouping
framework [RFC5888] MUST be used (and requirements from that are
inherited); and the "CS" token MUST be used with the "group"
attribute to indicate a Composite Session grouping. The SDP grouping
framework declares groups at session-level and labels media (with the
"mid" attribute) at media-level. Hence, all media identified by
their "mid" values by an "a=group:CS" line belong to the same
Composite Session group and inherit the grouping specified for that
value at session-level.
The first media line declared for a Composite Session group is the
Primary Media. Just as session-level attributes are inherited to
media-level declarations (unless specifically overwritten by an
additional media-level attribute), Primary Media attributes SHALL be
inherited to all media of a particular Composite Session group and
these MAY be overwritten where an attribute syntax allows.
[Editorial note: unless we discover problems with existing
implementations, "The first media line declared..." will be changed
to: "The first (leftmost) mid value declared..."]
3.2.1. Composite Session Semantics for FLUTE Sessions
When a complete SDP description specifies only one FLUTE session,
using the Composite Session mechanism is OPTIONAL. When a complete
SDP description specifies more than one FLUTE session, using the
Walsh, et al. Expires December 3, 2010 [Page 8]
Internet-Draft SDP Descriptors for FLUTE June 2010
Composite Session mechanism is REQUIRED.
The Composite Session provides an unambiguous way to define multiple
FLUTE sessions as distinct from multiple the media-sessions semantics
of RTP. It is useful for describing more than one FLUTE session in
an SDP instance and so its use and support are OPTIONAL. For SDP
instances which describe multiple FLUTE sessions, the Composite
Session semantics MUST be used. Whenever an SDP describes just one
FLUTE session with more than a single media stream of FLUTE protocol
identifier (i.e. a FLUTE channel), use of Composite Session semantics
is RECOMMENDED.
To support simple applications, as well as ensure harmony with FLUTE
SDP standards outside of the IETF [3GPP.26.346], when the Composite
Session mechanism is not used for media of the UDP/FLUTE protocol,
exactly one FLUTE session is specified within the SDP description and
all UDP/FLUTE media that SDP description belong to the same FLUTE
session (this is known as the Restricted Behaviour).
The Composite Session mechanism SHOULD NOT be used where the target
clients are expected to include simpler FLUTE SDP parsers, such as in
3GPP MBMS [3GPP.26.346]. In this Restricted Behaviour only UDP/FLUTE
media SHALL be described.
A partial example of using the Composite Session mechanism for FLUTE
is shown below.
<other session-level attributes>
a=group:CS 1 2
a=group:CS 3
m=application 12345 FLUTE/UDP *
a=mid:1
<other media-level attributes>
m=application 12346 FLUTE/UDP *
a=mid:2
<other media-level attributes>
m=application 56789 FLUTE/UDP *
a=mid:3
<other media-level attributes>
The example shows two groups with the 1st and 3rd media ("m=") lines
(mid values 1 and 3) being the Primary Media for each group
respectively. In the example, the media with mid value "2" inherits
attributes of the media with mid value "1".) Each of these groups
identifies a separate FLUTE Session. Several of the attributes
subsequently specified in this document use this feature of Primary
Media inheritance to all media of a Composite Session.
Walsh, et al. Expires December 3, 2010 [Page 9]
Internet-Draft SDP Descriptors for FLUTE June 2010
3.2.2. Composite Session Semantics for Protocols other than FLUTE
The Composite Session mechanism solves the problem of describing
multiple FLUTE sessions in a single SDP instance. However, this does
not place any restrictions on the use of the Composite Session
mechanism with transport protocols other than FLUTE/UDP, nor on
whether a complete SDP would include media of other transport
protocols too. Specification of semantics beyond the use of FLUTE
sessions is outside the scope of this document.
3.3. Source IP Address
The Asynchronous Layered Coding (ALC) [RFC5775] and the Layered
Coding Transport (LCT) [RFC5651] specifications require that all the
channels of a single ALC/LCT session are from the same source IP
address. [Editorial note: we believe this text to be correct but
have open the question to the mailing group to verify that the single
sender is identical to the single source IP address.] Hence, there
MUST be exactly one source IP address per FLUTE session, and
therefore one source IP address per each description of a FLUTE
session description. Restricted behaviour is one source IP address
per each complete SDP. Where multiple FLUTE sessions are described
within one SDP instance this means one source IP address per each
Composite Session.
The source IP address MUST be defined according to the source-filter
attribute ("a=source-filter") [RFC4570], with the following
exceptions:
o The source-filter attribute MUST be included in any SDP describing
FLUTE per FLUTE session described.
o The number of source-filter attributes in any SDP describing FLUTE
must be exactly equal to the number of FLUTE sessions described in
that SDP.
o In the restricted behaviour of only one FLUTE session description
in an SDP and no use of the Composite Session mechanism: The
source-filter attribute MUST be in the session part of the session
description and MUST NOT be given per media. Note, the
requirement that there must not be more than a single source-
filter attribute in the session part is inherited from [RFC4570].
o Where the Composite Session mechanism is used: The source-filter
attribute MUST be in the media part of Primary Media of each
distinct FLUTE session, and MUST NOT be given in other media
declarations but these, nor in the session-level part of the SDP.
Walsh, et al. Expires December 3, 2010 [Page 10]
Internet-Draft SDP Descriptors for FLUTE June 2010
o Exactly one source address is specified by any instance of this
attribute. Exactly one source address MUST be given in an
inclusive-mode "src-list". Exclusive-mode MUST NOT be used.
o The "*" value MUST be used for the "dest-address" sub-field, even
when the FLUTE session employs only a single channel (e.g. a
multicast group).
An example of the use of this attribute is:
a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9
This example uses the source-filter attribute to describe an IPv6
source address.
3.4. Transport Session Identifier
The combination of the TSI and the source IP address identifies a
FLUTE session. Each TSI MUST uniquely identify a FLUTE session for a
given source IP address during the time that the session is active
and also for a large time before and after the active session time.
[Editorial note: SDP specification guidance is to expire sessions 30
minutes after the time given in the t-field and as the t-field is
mandatory with SDP we are consulting to try and tighten this time
requirement for well bounded sessions to something more familiar to
the SDP world - "60 minutes" instead of "large time". For unbounded
sessions (end time = "0") the amorphous "large time" recommendation
will remain in force.] This requirement is inherited from LCT
[RFC5651]. The TSI MUST be described by the "flute-tsi" attribute.
There MUST be exactly one occurrence of the "flute-tsi" attribute per
FLUTE session description of a SDP description.
o The number of "flute-tsi" attributes in any SDP describing FLUTE
must be exactly equal to the number of FLUTE sessions described in
that SDP.
o In the restricted behaviour of only one FLUTE session description
in an SDP and no use of the Composite Session mechanism: The
"flute-tsi" attribute MUST be in the session part of the session
description and MUST NOT be given per media. A "flute-tsi"
attribute in the session-part SHALL be used to identify restricted
behaviour.
o Where the Composite Session mechanism is used: The "flute-tsi"
attribute MUST be in the media part of Primary Media of each
distinct FLUTE session, and MUST NOT be given in other media
declarations but these, and MUST NOT be given in the session-level
Walsh, et al. Expires December 3, 2010 [Page 11]
Internet-Draft SDP Descriptors for FLUTE June 2010
part of the SDP.
The syntax for the attribute in ABNF is given below:
flute-tsi-line = "a=flute-tsi:" tsi CRLF
tsi = 1*DIGIT
3.5. Session Timing Parameters
The SDP timing field "t=" [RFC4566] MUST be used to indicate the
FLUTE session start and end times. This value applies to all FLUTE
and transport sessions defined in a single SDP instance and, thus,
FLUTE sessions of different timing values need to be declared in
different SDP instances.
3.6. Channelisation Descriptors
This section specifies the description of the channel(s) used within
a FLUTE session. The required parameters for channelisation
description are:
o Number of channels
o Destination IP address and port number for channels
3.6.1. Number of Channels
The FLUTE specification allows the use of multiple channels (e.g.
multicast groups) to transport the files of a single FLUTE session.
This is referred to as FLUTE session channelisation in this document.
A FLUTE channel is equivalent to an ALC/LCT channel. An ALC/LCT
channel is defined by the combination of a sender and an address
associated with the channel by the sender. Details of each channel
are defined by SDP media-level information also described in this
document. The number of channels is calculated by summing the number
of unique destination IP address and port number pairs for a certain
FLUTE session (assignment of media to FLUTE sessions is done with
presence of absence of the Composite Session grouping).
The OPTIONAL "flute-ch" attribute describes the number of channels
used by the source to transmit the FLUTE session. When present, it
is used to validate the channel number calculation based on the
number of destination address/port pairs, and it is expected to be
used where SDP proxies and other automatic and manual editing that
introduces errors would cause bad failure conditions at the client.
When the "flute-ch" attribute is used:
Walsh, et al. Expires December 3, 2010 [Page 12]
Internet-Draft SDP Descriptors for FLUTE June 2010
o The number of "flute-ch" attributes in any SDP describing FLUTE
MUST be exactly equal to the number of FLUTE sessions described in
that SDP. A client SHOULD discard all of an SDP instance if this
condition is not met. Alternative behaviour, such as retries at
delivery, error reporting and partial use of SDP instances known
to include errors, are beyond the scope of this document.
o In the restricted behaviour of only one FLUTE session description
in an SDP and no use of the Composite Session mechanism: The
"flute-ch" attribute MUST be in the session part of the session
description and MUST NOT be given per media.
o Where the Composite Session mechanism is used: The "flute-ch"
attribute MUST be in the media part of Primary Media of each
distinct FLUTE session, and MUST NOT be given in other media
declarations but these, nor in the session-level part of the SDP.
The syntax for the attribute in ABNF is given below:
flute-channel-line = "a=flute-ch:" ch CRLF
ch = integer
;integer is as defined in [RFC4566], and its value is the number of
;channels used by the source to transmit data in a FLUTE session.
3.6.2. Destination IP Address and Port Number for Channels
SDP media-level information describes one or more channels. The
channel parameters MUST be given per channel and are:
o Destination IP address
o Destination port number
The destination IP address MUST be defined according to the
connection data field ("c=") of SDP [RFC4566]. The destination port
number MUST be defined according to the "port" sub-field of the media
description field ("m=") of SDP [RFC4566].
A "c=" line can describe multiple addresses by using "number of
addresses" sub-field, and also an "m=" line can describe multiple
ports by using "number of ports" sub-field. So multiple channels can
be described by using one "c=" line and one "m=" line (called "slash
notation").
When more than one channel is used in a multicast FLUTE session, it
is RECOMMENDED that the channels are differentiated based on
destination IP address, and channels are not differentiated based on
destination port (although those ports could be same or different for
Walsh, et al. Expires December 3, 2010 [Page 13]
Internet-Draft SDP Descriptors for FLUTE June 2010
each of the channels). Whenever destination port number is used to
differentiate between FLUTE channels, the same destination IP address
MUST be used for all channels in that FLUTE session. Note, when more
than one channel is used in a unicast FLUTE session, the channels
have to be differentiated based on destination ports, as only one
destination IP address could be used.
In the case (always with a unicast session) where the same
destination IP address is used for all the channels of the session
and only the destination port number differentiates channels, the
destination IP address MAY be given by the connection data field at
session-level for all channels (if so, the connection data field MUST
NOT be used at media-level).
In the case where each channel has a different destination IP
address, the destination IP addresses MUST be given at media-level,
i.e. following an "m=" line.
The sequence of multiple channels MUST be determined by the order in
which their media descriptions are defined in the session description
(i.e. the first media description gives the first channel in the
sequence). This applies individually to each FLUTE session of an SDP
whether one or more FLUTE sessions are described. In the case of the
slash notation usage for specifying multiple destination addresses or
ports, the order of the channel sequence MUST be lowest value first
and highest last. Note, slash notation for both destination IP
address and port would be incompatible with requirement to not use
both destination IP address and port to differentiate channels in a
FLUTE session and thus slash notation for both destination IP address
and port is not allowed for a single FLUTE session - i.e. for a
single composite session (when the SDP describes multiple FLUTE
sessions) or for a single SDP (when only one FLUTE session is
described).
Also we need to indicate the presence of a FLUTE session on a certain
channel. This is done by using the "m=" line in the SDP description
as shown in the following example:
m=application 12345 FLUTE/UDP *
c=IN IP6 FF33::8000:1
In the above SDP attributes, the "m=" line indicates the media used
and the "c=" line together with "m=" line's "port" sub-field
indicates the corresponding channel's address and port respectively.
Thus, in the above example, the media is transported on a channel
that uses FLUTE over UDP. Further, the "c=" line indicates the
channel's address, which, in this case, is an IPv6 address, and "m="
line indicates the channel's port (12345).
Walsh, et al. Expires December 3, 2010 [Page 14]
Internet-Draft SDP Descriptors for FLUTE June 2010
Note, the value of the destination IP address can indicate whether a
multicast media belongs to an ASM or a SSM group as described by
[RFC4607].
3.7. FEC Object Transmission Information
An SDP description for a FLUTE session MAY include FEC Object
Transmission Information (FEC-OTI) [RFC5052]. FEC parameters can be
placed either at session-level or at media-level, although it is
RECOMMENDED to place them at session-level. Furthermore, if FEC
parameters are placed at media level (contrary to the recommendation)
and the Composite Session mechanism is used, they SHOULD only be
placed in the Primary Media for any FLUTE session description. If
FEC declarations on both session and media level use the same
reference number (fec-ref) then the media level declaration takes
precedence for that media component. FEC parameters include:
o FEC Encoding ID
o FEC Instance ID (for FEC Encoding IDs 128-255)
Where FEC-OTI is given, FEC parameters MUST be described in a "FEC-
declaration" attribute. Multiple instances of this attribute MAY
exist both at session-level and media-level. If an instance exists
at session-level (or in a Primary Media), a reference to it MAY be
used at media-level, and an attribute "FEC" MUST be defined for this
purpose.
The syntax for the attributes in ABNF is given below:
fec-declaration-line = "a=FEC-declaration:" fec-ref SP
fec-enc-id [";" SP fec-inst-id] CRLF
fec-ref = 1*3DIGIT
;value is the SDP-internal identifier for FEC-declaration
fec-enc-id = "encoding-id=" enc-id
enc-id = 1*DIGIT
;value is the FEC Encoding ID used
fec-inst-id = "instance-id=" inst-id
inst-id = 1*DIGIT
;value is the FEC Instance ID used
fec-line = "a=FEC:" fec-ref CRLF
Examples of FEC-OTI are shown in Section 4.
The FEC parameters are for capabilities description for the session.
Walsh, et al. Expires December 3, 2010 [Page 15]
Internet-Draft SDP Descriptors for FLUTE June 2010
These parameters do not mandate a certain machine configuration but
instead indicate which capabilities might be needed for successful
reception of objects from specific channels. (Note, any "FDT-like"
fuller description of files in the session could give the FEC
parameters per file). FLUTE's FDT syntax (and codepoint header field
usage) allows complete specification of these FEC parameters in-band
with FLUTE (per file). Thus machine configuration can be performed
using FLUTE alone.
More complete list of notes on the design logic for the FEC-OTI
descriptors is provided as an appendix to this document.
The identification and description of any congestion control (CC)
instance related to layered media (multiple FLUTE channels) is
orthogonal to the FEC declarations and other aspects of this
document. Hence, CC descriptions are not in scope of this document.
3.8. Content Description Pointer
The syntax of the information that tells receiver, in the first
place, that the session contains files that are of interest is out of
scope of this document. However, the SDP MAY include a content
description pointer at the session-level and/or media-level
(including Primary Media of Composite Sessions) to enable efficient
linkage to such information.
The content description pointer attribute describes to the
receiver(s) the URI where the content description is stored. The
content description pointer MUST be defined according to the
"content-desc" attribute.
The syntax for the attribute in ABNF is given below:
content-desc-line = "a=content-desc:" URI-reference CRLF
;URI-reference is as defined in [RFC3986].
An example of content description pointer is shown in Section 4.
3.9. Bandwidth Specification
The specification of bandwidth (data rate) is OPTIONAL and where
included in the SDP it SHALL adhere to the following rules.
The maximum bit-rate required by a particular FLUTE media line (one
or more FLUTE channels, depending on the usage or IP address and port
ranges) MAY be specified. In this case it is RECOMMENDED to use the
TIAS bandwidth modifier [RFC3890] on media-level, although the AS
bandwidth modifier [RFC4566] MAY be used on media-level.
Walsh, et al. Expires December 3, 2010 [Page 16]
Internet-Draft SDP Descriptors for FLUTE June 2010
The session bit-rate MAY also be specified. In this case it is
RECOMMENDED to use the TIAS bandwidth modifier and the "a=maxprate"
attribute for the session, and again AS is optional but not
recommended.
TIAS is generally preferred as it allows the calculation of the bit-
rate in environments with translation of IP version or transport
protocol, where as AS does not and thus adds significant complexity
in such environments.
Any Transport Independent (TIAS) bandwidth SHALL be the largest sum
of the sizes of all FLUTE/UDP packets transmitted during any one
second long period of the FLUTE session, depending on which level it
is being used, expressed as kilobits. The size of the packet SHALL
include all FLUTE, ALC, LCT and any extensions headers and payload.
IP and UDP headers are excluded from the TIAS bit-rate calculation.
Any Application Specific (AS) bandwidth SHALL be the largest sum of
the sizes of all FLUTE/UDP packets transmitted during any one second
long period for the related media line(s), expressed as kilobits.
The size of the packet SHALL be the complete packet, i.e. IP, UDP
and FLUTE headers, and the data payload.
3.9.1. Bandwidth Specification for Composite Sessions
Where the multimedia session bit-rate is specified (at SDP session
level) this applies to all media, irrespective of whether the
Composite Session mechanism is used to describe multiple sessions
(e.g. multiple FLUTE sessions). So if multiple Composite Sessions
are described in a single SDP and SDP session-level bit-rate is
described, this session-level bit-rate would not relate to any single
Composite Session.
A normal TIAS or AS bit-rate declaration at the Primary Media level
is to be interpreted as media-specific and not imply any inheritance
to other media of the same Composite Session. It is RECOMMENDED that
aggregate Composite Session bandwidth is calculated as the sum of all
constituent media bit-rate declarations. Specification of a
descriptor specifically for aggregate Composite Session bandwidth is
beyond the scope of this document.
3.10. SDP Specific Parameters
SDP [RFC4566] also mandates three parameters ("v=", "o=" and "s=")
that would be present in every FLUTE SDP description regardless of
their usefulness to the FLUTE session description.
Walsh, et al. Expires December 3, 2010 [Page 17]
Internet-Draft SDP Descriptors for FLUTE June 2010
4. SDP Syntax Examples
This section gives examples of the use of SDP attributes to describe
a FLUTE session.
v=0
o=user123 2890844526 2890842807 IN IP6 2001:0DB8::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9
a=flute-tsi:3
a=flute-ch:2
a=FEC-declaration:0 encoding-id=0
a=FEC-declaration:1 encoding-id=129; instance-id=0
a=content-desc:http://www.example.com/flute-sessions/session001
m=application 12345 FLUTE/UDP *
c=IN IP6 FF33::8000:1
a=FEC:0
m=application 12346 FLUTE/UDP *
c=IN IP6 FF33::8000:2
a=FEC:1
Figure 1: An SDP for FLUTE Session with Two Channels
Figure 1 shows an example SDP description for FLUTE session with two
channels.
The attribute defined in the line "a=source-filter: incl IN IP6 *
2001:0DB8:1:2:240:96FF:FE25:8EC9" describes a source filter. In this
example the source indicates that the receiver(s) should include the
given IP address (2001:0DB8:1:2:240:96FF:FE25:8EC9) into the session.
It should be noted that although other possibilities may be used, in
this case only the incl and * attributes may be used in the above
attribute.
The attribute defined in the line "a=flute-tsi:3" describes the
Transport Session Identifier for the session. The pair made of the
source IP address and the TSI together uniquely identifies a FLUTE
session.
The source indicates in the above example that it will transmit data
in the FLUTE session on two channels (a=flute-ch:2). The source then
specifies the channels.
The "a=FEC-declaration" lines describes two different FEC schemes
used in the FLUTE session.
Walsh, et al. Expires December 3, 2010 [Page 18]
Internet-Draft SDP Descriptors for FLUTE June 2010
The "a=content-desc" line describes the URI where the content
description is stored.
The line "m=application 12345 FLUTE/UDP *" indicates the media used
for the channel. In this example, there are two "m=" lines for the
two channels described.
The destination addresses for the channels are given in the "c="
lines. These also show to the receiver(s) that the channels are two
(maybe more in other cases) consecutive channels.
The "a=FEC" lines at media-level reference FEC declarations at
session-level ("a=FEC-declaration").
v=0
o=user123 2890844526 2890842807 IN IP6 2001:0DB8::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9
a=flute-tsi:2
a=flute-ch:1
m=application 12345 FLUTE/UDP *
c=IN IP6 FF33::8000:1
a=FEC-declaration:0 encoding-id=129; instance-id=0
Figure 2: An SDP for FLUTE Session with One Channel
Figure 2 shows an example SDP description for FLUTE session with one
channel.
Walsh, et al. Expires December 3, 2010 [Page 19]
Internet-Draft SDP Descriptors for FLUTE June 2010
v=0
o=user123 2890844526 2890842807 IN IP6 2001:0DB8::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9
a=FEC-declaration:0 encoding-id=0
a=FEC-declaration:1 encoding-id=129; instance-id=0'
a=group:CS 1 2
a=group:CS 3 4
m=application 12345 FLUTE/UDP *
c=IN IP6 FF33::8000:1
a=flute-tsi:1
a=FEC:0
a=mid:1
m=application 12346 FLUTE/UDP *
c=IN IP6 FF33::8000:2
a=mid:2
m=application 12347 FLUTE/UDP *
c=IN IP6 FF33::8000:3
a=flute-tsi:2
a=FEC:1
a=mid:3
m=application 12348 FLUTE/UDP *
c=IN IP6 FF33::8000:4
a=mid:4
Figure 3: An SDP for composite FLUTE session
Figure 3 shows an example SDP description for composite FLUTE
session.
Walsh, et al. Expires December 3, 2010 [Page 20]
Internet-Draft SDP Descriptors for FLUTE June 2010
5. Security Considerations
See [RFC4566] for security considerations specific to the Session
Description Protocol in general. See also [RFC4570] for security
consideration related to source address filters. [Editorial note:
section under review]
Walsh, et al. Expires December 3, 2010 [Page 21]
Internet-Draft SDP Descriptors for FLUTE June 2010
6. IANA Considerations
6.1. Transport Protocol
The "proto" sub-field of the media description field ("m=") describes
the transport protocol used. This document registers one value:
"FLUTE/UDP" is a reference to FLUTE [I-D.ietf-rmt-flute-revised]
running over UDP/IP.
6.1.1. Media formats ("fmt")
FLUTE media using the "FLUTE/UDP" proto value may use the character
"*" as their "fmt" value. The "*" character represents a wild card
which indicates that miscellaneous and unspecified MIME types are
contained in the FLUTE session. Alternatively a list of MIME types
(file formats) may be given in the "fmt" list. These formats SHOULD
be registered. Use of an existing MIME subtype for the format is
encouraged. If no MIME subtype exists, it is RECOMMENDED that a
suitable one is registered through the IETF process (RFC 2048).
[Editorial note: wording of this section is under review pending
FLUTE/FDT version discussion.]
6.2. Attribute Names
As recommended by [RFC4566], the new attribute names "flute-tsi",
"flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" and
"content-desc" should be registered with IANA, as follows:
The following contact information shall be used for all registrations
included here:
Contact: Rod Walsh
EMail: rod.walsh (at) nokia.com
SDP Attribute ("att-field"):
Attribute name: flute-tsi
Long form: FLUTE Transport Session Identifier
Type of name: att-field
Type of attribute: Session level or media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
SDP Attribute ("att-field"):
Attribute name: flute-ch
Long form: Number of Channels in a FLUTE Session
Type of name: att-field
Walsh, et al. Expires December 3, 2010 [Page 22]
Internet-Draft SDP Descriptors for FLUTE June 2010
Type of attribute: Session level or media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
SDP Attribute ("att-field"):
Attribute name: FEC-declaration
Long form: Forward Error Correction Declaration
Type of name: att-field
Type of attribute: Session level or media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
SDP Attribute ("att-field"):
Attribute name: FEC
Long form: A Reference to FEC Declaration
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
SDP Attribute ("att-field"):
Attribute name: FEC-OTI-extension
Long form: FEC Object Transmission Information extension
Type of name: att-field
Type of attribute: Session level or media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
SDP Attribute ("att-field"):
Attribute name: content-desc
Long form: Content Description Pointer
Type of name: att-field
Type of attribute: Session level or media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
Walsh, et al. Expires December 3, 2010 [Page 23]
Internet-Draft SDP Descriptors for FLUTE June 2010
6.3. Composite Session Token to Differentiate FLUTE Sessions
IANA needs to register the following new 'semantics' attribute for
the SDP grouping framework [RFC5888]:
Semantics Token Reference
--------------------------------- ----- ---------
Composite Session CS This document
It should be registered in the SDP parameters registry
(http://www.iana.org/assignments/sdp-parameters) under Semantics for
the "group" SDP Attribute.
Walsh, et al. Expires December 3, 2010 [Page 24]
Internet-Draft SDP Descriptors for FLUTE June 2010
7. Acknowledgements
The authors would like to thank all the people who gave feedback on
this document.
Walsh, et al. Expires December 3, 2010 [Page 25]
Internet-Draft SDP Descriptors for FLUTE June 2010
8. Contributors
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm
Sweden
EMail: Magnus.Westerlund (at) ericsson.com
Joerg Ott
Aalto University
Otakaari 5A
FI-02150 Espoo
Finland
EMail: jo (at) netlab.tkk.fi
Walsh, et al. Expires December 3, 2010 [Page 26]
Internet-Draft SDP Descriptors for FLUTE June 2010
9. References
9.1. Normative References
[I-D.ietf-rmt-flute-revised]
Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport",
draft-ietf-rmt-flute-revised-11 (work in progress),
March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
April 2010.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol
(SDP) Source Filters", RFC 4570, July 2006.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
Schemes", RFC 5445, March 2009.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)",
RFC 3890, September 2004.
Walsh, et al. Expires December 3, 2010 [Page 27]
Internet-Draft SDP Descriptors for FLUTE June 2010
9.2. Informative References
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[3GPP.26.346]
3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346 6.13.0, March 2009.
Walsh, et al. Expires December 3, 2010 [Page 28]
Internet-Draft SDP Descriptors for FLUTE June 2010
Appendix A. Use of FEC attributes with RTP sessions (informative)
The "FEC-declaration" and "FEC" attributes provide general FEC-OTI
information in FEC Encoding ID and FEC Instance ID values. These may
also be used for RTP sessions employing same FEC Building Block (as
is done for 3GPP MBMS [3GPP.26.346]). However, semantics of RTP are
different from FLUTE (FEC is per session not per object) and RTP does
not have in-band mechanism to signal FEC OTI extensions. Thus, RTP
FEC declarations are expected to be used for machine configuration as
well as capability requirements specification (for FLUTE it is
generally only the latter).
Hence, the FLUTE SDP, defined in this document, may be extended using
a "FEC-OTI-extension" attribute, depending on the configuration needs
of the FEC decoder used and the lack of an alternative means to
signal the extended FEC-OTI information. The purpose of extended
FEC-OTI information is to define FEC code/instance-specific OTI
required for receiver FEC payload configuration. The contents of
such an extension would be FEC code-specific and exact specification,
beyond adherence to the ABNF below, needs to be specified by any FEC
code using this attribute, and hence is outside the scope of this
Appendix.
A "FEC-OTI-extension" attribute must be immediately preceded by its
associated "FEC-declaration" attribute and so the full FEC-OTI,
including extension, will be found in two neighbouring attribute
lines. The fec-ref value binds a "FEC-OTI-extension" and "FEC-
declaration attribute" pair.
The syntax for the attribute in ABNF is given below:
fec-oti-extension-line = "a=FEC-OTI-extension:" fec-ref SP
oti-extension CRLF
oti-extension = base64
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
Walsh, et al. Expires December 3, 2010 [Page 29]
Internet-Draft SDP Descriptors for FLUTE June 2010
Appendix B. Further Design Logic for FEC-OTI Descriptors
There are several reasons that the FEC Encoding and Instance IDs are
optional capabilities descriptions:
1. It is not always necessary to explicitly describe the FEC
capabilities in advance of the session - e.g. for simple (and
short) sessions it can be more elegant to discover this from the
session (FDT) itself (even when some mechanism for machine-
readable session parameters, such as IP addresses and ports, is
wanted in advance).
2. There may be some other out-of-band discovery of FEC capability
requirements (e.g. well known-FEC/standardised capabilities for a
certain application, verbal agreement between a group, etc.) that
provides the FEC capability information. This document does not
want to prevent this, and in this case repeating the information
in SDP would be unnecessary and wasteful (and probably result in
implementations not following the flute-sdp specification).
3. FLUTE defaults to Compact No-Code FEC [RFC5445] and support for
this is mandatory for FLUTE anyway so it is a given (capability
requirement) which does not need to be described by the SDP. In
cases where only Compact No-Code FEC is required, there is no use
in specifying any FEC Encoding (and Instance) IDs in the SDP
(though it is allowed). [Editorial note: RFC5445 is currently
under normative section and we believe that it should be under
informative section. This needs checking.]
4. In cases where a FLUTE session description (SDP file) is not
defined once for all time, it is possible that the FEC usage is
not known in advance and the FEC capabilities would only be added
to the SDP in a later version of that SDP file when the FEC codes
have been selected (e.g. a larger audience may suggest stronger
FEC to make FLUTE delivery more reliable, whereas additional bi-
directional messages may be scalable for smaller groups).
5. Also, in cases where a FLUTE session description (SDP file) is
very static (e.g. once for all time for that session), it is
possible that the FEC usage is not known in advance and it needs
to be left to some other mechanism (e.g. FDT) to discover any
FEC capability requirements set closer to the session
transmission - with the same examples as mentioned above.
Also, in a complex case of very many FEC codes being used in the
session giving a full list in SDP is not seen as being reasonable
(but this is likely to be a rare case anyway).
Walsh, et al. Expires December 3, 2010 [Page 30]
Internet-Draft SDP Descriptors for FLUTE June 2010
Authors' Addresses
Rod Walsh
Nokia Research Center
P.O. Box 100 (Visiokatu 1)
Tampere FI-33721
Finland
Email: rod.walsh (at) nokia.com
Igor D.D. Curcio
Nokia Research Center
P.O. Box 88 (Tieteenkatu 1)
Tampere FI-33721
Finland
Email: igor.curcio (at) nokia.com
Jani Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FI-33101
Finland
Email: jani.peltotalo (at) tut.fi
Sami Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FI-33101
Finland
Email: sami.peltotalo (at) tut.fi
Harsh Mehta
Email: harsh.mehta (at) gmail.com
Walsh, et al. Expires December 3, 2010 [Page 31]