RMT H. Mehta Internet-Draft R. Walsh Expires: May 9, 2005 I. Curcio Nokia J. Peltotalo S. Peltotalo Tampere University of Technology November 8, 2004 SDP Descriptors for FLUTE draft-mehta-rmt-flute-sdp-02 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 May 9, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 May 9, 2005 [Page 1] Internet-Draft SDP Descriptors for FLUTE November 2004 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 . . . . . . . . . . . . . . . 6 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 . 7 3.6 FEC Object Transmission Information . . . . . . . . . . . 9 3.7 Content Description . . . . . . . . . . . . . . . . . . . 11 3.7.1 Content Description Pointer . . . . . . . . . . . . . 11 3.7.2 The Media Types of Files . . . . . . . . . . . . . . . 11 4. SDP Syntax Examples . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1 Transport Protocol . . . . . . . . . . . . . . . . . . . . 15 6.2 Attribute Names . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 8.2 Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 21 Mehta, et al. Expires May 9, 2005 [Page 2] Internet-Draft SDP Descriptors for FLUTE November 2004 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 [17], 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 May 9, 2005 [Page 3] Internet-Draft SDP Descriptors for FLUTE November 2004 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 May 9, 2005 [Page 4] Internet-Draft SDP Descriptors for FLUTE November 2004 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 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 single SDP with the FLUTE/UDP protocol id as belonging to the same single FLUTE session. Each complete SDP session description will describe only one FLUTE session. An example of FLUTE protocol identifier is shown in section 4. Mehta, et al. Expires May 9, 2005 [Page 5] Internet-Draft SDP Descriptors for FLUTE November 2004 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: 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: sdp-flute-tsi-line = "a=flute-tsi:" value CRLF value = %d Mehta, et al. Expires May 9, 2005 [Page 6] Internet-Draft SDP Descriptors for FLUTE November 2004 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 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: sdp-flute-channel-line = "a=flute-ch:" value CRLF value = %d 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 Mehta, et al. Expires May 9, 2005 [Page 7] Internet-Draft SDP Descriptors for FLUTE November 2004 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 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 Mehta, et al. Expires May 9, 2005 [Page 8] Internet-Draft SDP Descriptors for FLUTE November 2004 as shown in the following example: m=application 12345 FLUTE/UDP 0 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 FEC-OTI MUST NOT be placed at both session and media levels. It is RECOMMENDED to place them at session-level. 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 (not both in the same SDP). If an instance exist 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 syntax for the attributes in ABNF is given below: sdp-fec-declaration-line = "a=FEC-declaration:" value SP fec-enc-id "; [SP fec-inst-id] CRLF value = %d (value is the identifier for FEC-declaration). fec-enc-id = "encoding-id=" value value = %d (value is the FEC Encoding ID used). fec-inst-id = "instance-id=" value value = %d (value is the FEC Instance ID used). Mehta, et al. Expires May 9, 2005 [Page 9] Internet-Draft SDP Descriptors for FLUTE November 2004 sdp-fec-line = "a=FEC:" value CRLF value = %d (value is the FEC-declaration identifier). 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 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). Mehta, et al. Expires May 9, 2005 [Page 10] Internet-Draft SDP Descriptors for FLUTE November 2004 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). 3.7 Content Description In the context of a FLUTE session, two forms of content description are important: o The out-of-band URI (content description pointer) that signals to the receiver that the FLUTE session is transmitting something of interest, and, o The media type(s) of the files being transmitted during the FLUTE session. 3.7.1 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. The syntax for the attribute in ABNF is given below: sdp-content-desc-line = "a=content-desc:" URI-reference CRLF URI-reference = as defined in [10]. An example of content description pointer is shown in section 4. 3.7.2 The Media Types of Files Mehta, et al. Expires May 9, 2005 [Page 11] Internet-Draft SDP Descriptors for FLUTE November 2004 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 0 c=IN IP6 FF1E:03AD::7F2E:172A:1E24 a=FEC:0 m=application 12346 FLUTE/UDP 0 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 TSI defined in the line "a=flute-tsi:3" describes the Transmission 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 May 9, 2005 [Page 12] Internet-Draft SDP Descriptors for FLUTE November 2004 The "a=content-desc" line describes the URI where the content description is stored. The line "m=data 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=data 12345 FLUTE/UDP 0 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 May 9, 2005 [Page 13] Internet-Draft SDP Descriptors for FLUTE November 2004 5. Security Considerations Mehta, et al. Expires May 9, 2005 [Page 14] Internet-Draft SDP Descriptors for FLUTE November 2004 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" 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 May 9, 2005 [Page 15] Internet-Draft SDP Descriptors for FLUTE November 2004 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: 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 May 9, 2005 [Page 16] Internet-Draft SDP Descriptors for FLUTE November 2004 7. Acknowledgements The authors would like to thank all the people who gave feedback on this document. Mehta, et al. Expires May 9, 2005 [Page 17] Internet-Draft SDP Descriptors for FLUTE November 2004 8. References 8.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-06 (work in progress), July 2004. [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 May 9, 2005 [Page 18] Internet-Draft SDP Descriptors for FLUTE November 2004 8.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-09 (work in progress), September 2004. [17] 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 May 9, 2005 [Page 19] Internet-Draft SDP Descriptors for FLUTE November 2004 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 May 9, 2005 [Page 20] Internet-Draft SDP Descriptors for FLUTE November 2004 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 (2004). 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 May 9, 2005 [Page 21]