One document matched: draft-mehta-rmt-flute-sdp-03.txt
Differences from draft-mehta-rmt-flute-sdp-02.txt
RMT H. Mehta
Internet-Draft R. Walsh
Expires: January 1, 2006 I. Curcio
Nokia
J. Peltotalo
S. Peltotalo
Tampere University of Technology
June 30, 2005
SDP Descriptors for FLUTE
draft-mehta-rmt-flute-sdp-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies the use of SDP to describe the parameters
required to begin, join, receive data from, and end FLUTE sessions.
Mehta, et al. Expires January 1, 2006 [Page 1]
Internet-Draft SDP Descriptors for FLUTE June 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. FLUTE Descriptors . . . . . . . . . . . . . . . . . . . . . . 5
3.1 FLUTE Protocol Identifier . . . . . . . . . . . . . . . . 5
3.2 Source IP Address . . . . . . . . . . . . . . . . . . . . 6
3.3 Transport Session Identifier . . . . . . . . . . . . . . . 7
3.4 Session Timing Parameters . . . . . . . . . . . . . . . . 7
3.5 Channelisation Descriptors . . . . . . . . . . . . . . . . 7
3.5.1 Number of Channels . . . . . . . . . . . . . . . . . . 7
3.5.2 Destination IP Address and Port Number for Channels . 8
3.6 FEC Object Transmission Information . . . . . . . . . . . 9
3.7 Content Description Pointer . . . . . . . . . . . . . . . 12
3.8 Bandwidth Specification . . . . . . . . . . . . . . . . . 13
4. SDP Syntax Examples . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1 Transport Protocol . . . . . . . . . . . . . . . . . . . . 17
6.2 Attribute Names . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1 Normative References . . . . . . . . . . . . . . . . . . . 21
9.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24
Mehta, et al. Expires January 1, 2006 [Page 2]
Internet-Draft SDP Descriptors for FLUTE June 2005
1. Introduction
The Session Description Protocol (SDP) [6] 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 [9]) 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 [1], SAP [13], SIP
[14], RTSP [18], HTTP [15], 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. [16] defines protocol
identifiers for connection-oriented reliable transports: TCP and TCP/
TLS. RFC 3266 [7] describes SDP support for IPv6.
This document defines a new protocol identifier for File Delivery
over Unidirectional Transport (FLUTE) protocol [1] and other required
SDP attributes for initiating a FLUTE session. The formal ABNF
syntax [5] is used for the attributes.
Mehta, et al. Expires January 1, 2006 [Page 3]
Internet-Draft SDP Descriptors for FLUTE June 2005
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 [2].
Mehta, et al. Expires January 1, 2006 [Page 4]
Internet-Draft SDP Descriptors for FLUTE June 2005
3. FLUTE Descriptors
The FLUTE specification [1] 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.
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 The start time and end time of the session
Optionally, the following parameters may be associated with the
session:
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 Bandwidth specification
The description of these parameters in SDP is presented in the
following sections. Note also that "v=", "o=" and "s=" lines are
mandatory for SDP descriptions [6].
3.1 FLUTE Protocol Identifier
The following is the ABNF syntax for an "m=" line, as specified by
RFC 2327 [6]:
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 [1] protocol on top of a UDP connection.
The default behaviour of a host shall be to group all media of a
Mehta, et al. Expires January 1, 2006 [Page 5]
Internet-Draft SDP Descriptors for FLUTE June 2005
single SDP with the FLUTE/UDP protocol identifier as belonging to the
same single FLUTE session. Each complete SDP session description
will describe only one FLUTE session.
Note, describing multiple FLUTE sessions per SDP is not considered
useful and so is outside the scope of this document.
The fmt list of FLUTE "m=" lines SHOULD contain a single "*"
character, like [17]. Use of any other parameters 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, in a non standard way, and so
implementors 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.
3.2 Source IP Address
The Asynchronous Layered Coding (ALC) [3] and the Layered Coding
Transport (LCT) [4] specifications require that all the channels of a
single ALC/LCT session are from the same source IP address. Hence,
there MUST be exactly one source IP address per FLUTE session, and
therefore one source IP address per each complete SDP description of
a FLUTE session.
The source IP address MUST be defined according to the source-filter
attribute ("a=source-filter") [8], with the following exceptions:
o A source-filter attribute MUST be included in any SDP describing
FLUTE.
o 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 [8].
o Exactly one source address is specified by 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:
Mehta, et al. Expires January 1, 2006 [Page 6]
Internet-Draft SDP Descriptors for FLUTE June 2005
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
This example uses the source-filter attribute to describe an IPv6
source address.
3.3 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.
This requirement is also specified by [4]. The TSI MUST be described
by the "flute-tsi" attribute. There MUST be exactly one occurrence
of the "flute-tsi" attribute in a complete FLUTE session SDP
description and it MUST appear at the session-level.
The syntax for the attribute in ABNF is given below:
flute-tsi-line = "a=flute-tsi:" tsi CRLF
tsi = 1*DIGIT
3.4 Session Timing Parameters
The SDP timing field "t=" [6] MUST be used to indicate the FLUTE
session start and end times.
3.5 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.5.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. FLUTE session
channelisation is defined according to a new SDP attribute at
Mehta, et al. Expires January 1, 2006 [Page 7]
Internet-Draft SDP Descriptors for FLUTE June 2005
session-level as specified in this document. Details of each channel
are defined by SDP media-level information also described in this
document.
The "flute-ch" attribute describes the number of channels used by the
source to transmit. It MAY also be used to check that right amount
of channel descriptions exists in the session description. For
example, if the value of this attribute is 2, then there should be 2
channels specified by the "m=" line(s) and the "c=" line(s). An
example is given in section 4.
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 [6].
value is the number of channels used by the source to transmit data
in a FLUTE session.
In the absence of this attribute, a receiver MUST understand that
exactly one channel is used for the FLUTE session.
3.5.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 [6]. The destination port number
MUST be defined according to the "port" sub-field of the media
description field ("m=") of SDP [6].
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 (slash
notation).
Exactly one destination port MUST be used per channel. When more
than one channel is used in a multicast session, it is RECOMMENDED
that the channels are differentiated based on destination IP address,
and channel differentiation based on destination port with the same
Mehta, et al. Expires January 1, 2006 [Page 8]
Internet-Draft SDP Descriptors for FLUTE June 2005
destination address is considered unnecessary, complex and
potentially harmful. When more than one channel is used in a unicast
session, the channels have to be differentiated based on destination
ports.
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 have 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). 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; and in the case
of slash notation for both destination address and port of a media-
level description the channel sequence MUST be from the lowest
address value and incremented through the range.
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 FF1E:03AD::7F2E:172A:1E24
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).
3.6 FEC Object Transmission Information
An SDP description for a FLUTE session MAY include FEC Object
Transmission Information (FEC-OTI) [12]. FEC parameters can be
placed either at session-level or at media-level, although it is
RECOMMENDED to place them at session-level. If FEC declarations on
both session and media level use the same reference number (fec-ref)
Mehta, et al. Expires January 1, 2006 [Page 9]
Internet-Draft SDP Descriptors for FLUTE June 2005
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, a reference to it MAY be used at media-level, and
an attribute "FEC" MUST be defined for this purpose. The absence of
a both a "FEC-declaration" and a "FEC" attribute at media-level MUST
be interpreted as the default FEC (Compact No-Code FEC [11] for
FLUTE).
The "FEC-declaration" attribute provides general FEC-OTI information
in FEC Encoding ID and FEC Instance ID values. This may be extended
using a "FEC-OTI-extension" attribute, depending on the needs of the
FEC code used and the lack of an alternative means to signal the
extended OTI information. The purpose of extended FEC-OTI
information 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
document.
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 attributes in ABNF is given below:
Mehta, et al. Expires January 1, 2006 [Page 10]
Internet-Draft SDP Descriptors for FLUTE June 2005
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
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 / "+" / "/"
Examples of FEC-OTI are shown in section 4.
The FEC parameters are for capabilities description for the session.
(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.
There are five main 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
Mehta, et al. Expires January 1, 2006 [Page 11]
Internet-Draft SDP Descriptors for FLUTE June 2005
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 [11] 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 (+Instance) IDs in the SDP (though
it is allowed).
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 in (4).
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).
<The description of layered media and identification of any
congestion control (CC) instance related to them is orthogonal to the
FEC declarations and other aspect of this document. Hence, the
authors assume layering and CC descriptions are not in scope of this
document. This assumption is subject to further study.>
3.7 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 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.
Mehta, et al. Expires January 1, 2006 [Page 12]
Internet-Draft SDP Descriptors for FLUTE June 2005
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 [10].
An example of content description pointer is shown in section 4.
3.8 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 this FLUTE session shall be specified
using the "AS" bandwidth modifier [6] on session level. 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) shall
be specified using the "AS" bandwidth modifier [1] on media level.
The Application Specific (AS) bandwidth shall be the largest sum of
the sizes of all packets transmitted during any one second long
period of the session or media-line, depending on which level it is
being used, expressed as kilobits. The size of the packet shall be
the complete packet, i.e. IP, UDP and FLUTE headers, and the data
payload.
Mehta, et al. Expires January 1, 2006 [Page 13]
Internet-Draft SDP Descriptors for FLUTE June 2005
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 2201:056D::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
a=flute-tsi:1
a=flute-ch:2
a=FEC-declaration:0 encoding-id=0
a=FEC-declaration:1 encoding-id=128; instance-id=0
a=content-desc:http://www.example.com/flute-sessions/session001
m=application 12345 FLUTE/UDP *
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
a=FEC:0
m=application 12346 FLUTE/UDP *
c=IN IP6 FF1E:03AD::7F2E:172A:1E25
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:210: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:210: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.
Mehta, et al. Expires January 1, 2006 [Page 14]
Internet-Draft SDP Descriptors for FLUTE June 2005
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 2201:056D::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
a=flute-tsi:2
a=flute-ch:1
m=application 12345 FLUTE/UDP *
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
a=FEC-declaration:0 encoding-id=128; 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.
Mehta, et al. Expires January 1, 2006 [Page 15]
Internet-Draft SDP Descriptors for FLUTE June 2005
5. Security Considerations
See [6] for security considerations specific to the Session
Description Protocol in general. See also [8] for security
consideration related to source address filters.
Mehta, et al. Expires January 1, 2006 [Page 16]
Internet-Draft SDP Descriptors for FLUTE June 2005
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 [1] running over UDP/IP.
6.2 Attribute Names
As recommended by [6], 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
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
Type of attribute: Session 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
Mehta, et al. Expires January 1, 2006 [Page 17]
Internet-Draft SDP Descriptors for FLUTE June 2005
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
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
Mehta, et al. Expires January 1, 2006 [Page 18]
Internet-Draft SDP Descriptors for FLUTE June 2005
7. Acknowledgements
The authors would like to thank all the people who gave feedback on
this document.
Mehta, et al. Expires January 1, 2006 [Page 19]
Internet-Draft SDP Descriptors for FLUTE June 2005
8. Contributors
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm
Sweden
EMail: Magnus.Westerlund (at) ericsson.com
Mehta, et al. Expires January 1, 2006 [Page 20]
Internet-Draft SDP Descriptors for FLUTE June 2005
9. References
9.1 Normative References
[1] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[4] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,
and J. Crowcroft, "Layered Coding Transport (LCT) Building
Block", RFC 3451, December 2002.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[7] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in
Session Description Protocol (SDP)", RFC 3266, June 2002.
[8] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP)
Source Filters", draft-ietf-mmusic-sdp-srcfilter-09 (work in
progress), June 2005.
[9] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[11] Luby, M. and L. Vicisano, "Compact Forward Error Correction
(FEC) Schemes", RFC 3695, February 2004.
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "Forward Error Correction (FEC) Building
Block", RFC 3452, December 2002.
Mehta, et al. Expires January 1, 2006 [Page 21]
Internet-Draft SDP Descriptors for FLUTE June 2005
9.2 Informative References
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"Session Initiation Protocol", RFC 3261, June 2002.
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., Berners-Lee, T., and E. Schooler, "Hypertext Tansfer
Protocol -- HTTP/1.1", RFC 3261, June 2002.
[16] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
in the Session Descript Protocol (SDP)",
draft-ietf-mmusic-sdp-comedia-10 (work in progress),
November 2004.
[17] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005.
[18] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
Authors' Addresses
Harsh Mehta
Nokia
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
Email: harsh.mehta (at) nokia.com
Rod Walsh
Nokia
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
Email: rod.walsh (at) nokia.com
Mehta, et al. Expires January 1, 2006 [Page 22]
Internet-Draft SDP Descriptors for FLUTE June 2005
Igor D.D. Curcio
Nokia
P.O. Box 88 (Tieteenkatu 1)
Tampere FIN-33721
Finland
Email: igor.curcio (at) nokia.com
Jani Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
Email: jani.peltotalo (at) tut.fi
Sami Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
Email: sami.peltotalo (at) tut.fi
Mehta, et al. Expires January 1, 2006 [Page 23]
Internet-Draft SDP Descriptors for FLUTE June 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mehta, et al. Expires January 1, 2006 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 01:11:32 |