One document matched: draft-marjou-mmusic-sdp-rtsp-01.txt
Differences from draft-marjou-mmusic-sdp-rtsp-00.txt
MMUSIC Working Group X. Marjou
Internet-Draft France Telecom
Expires: August 28, 2008 J. Lindquist
Ericsson
P. Rajagopal
Motorola
M. Said
France Telecom
S. Ganesan
Motorola
February 25, 2008
Session Description Protocol (SDP) Offer/Answer Model For Media Control
Protocol
draft-marjou-mmusic-sdp-rtsp-01
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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Marjou, et al. Expires August 28, 2008 [Page 1]
Internet-Draft SDP Offer/Answer February 2008
Abstract
This draft presents an approach to content on demand that relies on a
session management protocol and SDP offer/answer model [6] to
establish media control and media delivery flows. this approach would
be beneficial for some applications such as IPTV or applications that
require a mix of real-time and streaming flows.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Characteristics . . . . . . . . . . . . . . . . . . . 4
5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 5
8. Establishment of Media Control and Media Delivery Channels . . 6
8.1. Procedures at the SDP Offerer . . . . . . . . . . . . . . 6
8.1.1. Media Control Client as SDP offerer . . . . . . . . . 6
8.1.2. Media Control Server as SDP offerer . . . . . . . . . 7
8.2. Procedures at SDP Answerer . . . . . . . . . . . . . . . . 8
8.2.1. Media Control Server as SDP answerer . . . . . . . . . 8
8.2.2. Media Control Client as SDP answerer . . . . . . . . . 9
9. Media Control Protocol . . . . . . . . . . . . . . . . . . . . 9
9.1. Procedures at the Media Control Client . . . . . . . . . . 10
9.1.1. Media Playback Initiation Procedure . . . . . . . . . 10
9.1.2. Media Playback Modification Procedure . . . . . . . . 10
9.1.3. Media Playback Information Retrieval and Setting
Procedure . . . . . . . . . . . . . . . . . . . . . . 10
9.1.4. Media Event Notification Procedure . . . . . . . . . . 11
9.2. Procedures at Media Control Server . . . . . . . . . . . . 11
10. Modification of Media Delivery Channel(s) . . . . . . . . . . 11
11. Teardown of Media Control and Media Delivery Channels . . . . 11
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
13. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
15. Security Considerations . . . . . . . . . . . . . . . . . . . 12
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Marjou, et al. Expires August 28, 2008 [Page 2]
Internet-Draft SDP Offer/Answer February 2008
1. Introduction
IP-based networks are continually improving in terms of bandwidth
capacity and transport quality of service. At the same time,
broadband services are continually expanding globally - both in terms
of reach and value-added services. These developments are leading to
an increase in the number and variety of deployment scenarios for
streaming media applications. Many of these scenarios impose
challenging new requirements on the signaling protocols used for
these applications in terms of flexibility, scalability and network
independence. This ID describes the establishment of a streaming
session using session management protocol and SDP offer/answer model
[6] to establish media control and media delivery flows. The media
control protocol could based on a lightweight Real Time Streaming
Protocol (RTSP) [3] compatible protocol as described in this
document. The justification for using session management protocol
such as SIP [2] and lightweight version of a streaming protocol such
as RTSP is that SIP is used as a rendez-vous mechanism (among other
capabilities to go through NAT, to restrict a media session to a
given user), while RTSP is used for the trick-play mechanism within a
multimedia session. While this approach has created some controversy
as RTSP and SIP are not used in the same context and RTSP is a basic
protocol for a large number of commercial Video on demand and content
players, the protocol presented here is required by a growing number
of Internet Protocol Television (IPTV) implementations. It remains
fully compatible with standard SIP and RTSP.
2. Problem Analysis
Although RTSP works perfectly well as a standalone solution, there
are some use cases when it is desirable to establish RTSP-like
session with the SDP offer/answer model.
A first example of use-case is a scenario mixing video-surveillance
with a regular call: a user monitors a remote scene, possibly with
trick play commands, and when a remote user appears at the remote
scene, he engages a multimedia conversation with this remote user.
A second example of use-case is a scenario where trick play commands
are possible within a conference. A user joins a conference late and
uses a fast rewind command to come back to the beginning of the
presentation and possibly learn the names of the participants.This is
also reflected by the convergence in industry between essentially the
telecommunications (where signaling SIP is dominant) and
entertainment (where RTSP streaming is the favored solution).
A last exemple of use-case is a scenario where the network wants to
Marjou, et al. Expires August 28, 2008 [Page 3]
Internet-Draft SDP Offer/Answer February 2008
control the usage of content of demand by the user and may initiate
network-initiated deactivation of streaming session.
The use-cases clearly show that most of the time RTSP only or another
media control protocol is not sufficient. The use cases also show
that that the session setup negotiations are usually independent of
the media controls.
It is also important to to note that other Standards Developing
Organizations (SDOs) like the European Telecommunications Standards
Institute (ETSI) TISPAN are considering an using an integrated SIP/
RTSP approach for delivering IPTV services with SIP/SDP being used
used for session management and RTSP for media control. RTSPhas been
widely adopted, has been proven successful and provides a good
"running code and rough consensus" reason to keep it for media
controls within SIP sessions. Although this draft investigates the
use of SDP to convey RTSP media control information, this does not
preclude the option of using this approach for other media control
protocols.
3. Requirements
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"will", "will NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, [1] and indicate requirement levels for
compliant implementations.
4. Protocol Characteristics
The following section provides an overview of the design goals of the
protocol
o The session management protocol should be able to initiate/modify/
terminate media control and media delivery flows from client and
server side using SDP offer/answer mechanism
o The media control protocol for the delivery of A/V must be
negotiated using SDP offer/answer mechanism
o The media control protocol must have the possibility to select the
controlled media among the different media of the session (ie:
media grouping)
o The media control protocol must allow for trick-play commands such
as PLAY, REWIND, FORWARD, PAUSE commands
o The media control protocol must allow for asynchronous media event
notifications (eg: end-of-stream)"
Marjou, et al. Expires August 28, 2008 [Page 4]
Internet-Draft SDP Offer/Answer February 2008
o The media control protocol should work over tcp
5. Terminology
Media Control Client : Entity that is consumer of the media streams.
It implements a lightweight version of RTSP client and uses SDP
offer-answer model to negotiate the media control channel.
Media Control Server: Entity that is consumer of the media streams.
It implements a lightweight version of RTSP server and uses SDP
offer-answer model to negotiate the media control channel.
Media Control Channel: End-to-end communication channel between the
Media Control Client and Media Control Serverused for carrying media
trick play commands such as play,pause, rewind etc.
Media Delivery Channel:End-to-end communication channel between the
Media Control Client and Media Control Serverfor carrying the
streaming media
Agent:Refers to Media Control Server or Media Control Client
See [3] and [2] for terminology.
6. Acronyms
COD Content on demand
7. Overall Operation
The overall operation is as follows:-
Establishment of Media Control and Media Delivery Channels :The Media
Control Client uses the session management protocol associated to the
SDP offer-answer exchange with the Media Control Serverin order to
establish the relevant media control channel and one or more media
delivery channels that are to be controlled by the RTSP media control
channel. The relevant SDP parameters such as media type, transport
etc. required for establishing the content delivery channels may be
obtained apriori by the Media Control Client via HTTP from content
guide server, EPG server etc. or may even be delivered as part of
initial SDP exchange.
Media control :Once the media control session is established, media
playback controls are issued directly using the media control
Marjou, et al. Expires August 28, 2008 [Page 5]
Internet-Draft SDP Offer/Answer February 2008
protocol (e.g. subset of RTSP) as well as handling of any media
events. This includes trick play commands. If a subset of RTSP is
used, examples of commands would be RTSP PAUSE,RTSP PLAY etc. Note
that in the future other media control protocols than RTSP-based may
be used for media playback control.
Modification of Media Delivery channel(s) : Once established, the
Media Control Client or Media Control Servermay add/remove/modify any
of the media delivery channels using the session management protocol
by updating SDP description.
Teardown of Media Control and associated Media Delivery Channel :
Teardown of media control and associated media delivery channels may
be initiated by the Media Control Client or the Media Control
Serverusing the session management protocol. This is used to release
all resources associated with the media control channel and the media
delivery channels.
8. Establishment of Media Control and Media Delivery Channels
This section describes the procedures to be performed at an agent for
establishing Media Control Channel session and associated Media
Delivery Channel using SDP offer/answer model.
8.1. Procedures at the SDP Offerer
8.1.1. Media Control Client as SDP offerer
If the Media Control Client is the SDP offerer, then the procedures
in this section MUST be followed to establish the media control
session and one or more media delivery channels. The SDP offer is
per SDP specification [7]. The media line for RTSP media control
channel is included with following values-
o The media field MUST have a value of "application".
o The port field MUST indicate a TCP port, it MUST be set to a value
of 9, which is the discard port.
o This specification defines two new values for the transport field:
TCP/LTW_RTSP and TCP/TLS/LTW_RTSP. The former is used when RTSP
runs directly on top of TCP and the latter is used when RTSP runs
on top of TLS, which in turn runs on top of TCP.
o The fmt parameter MUST be included and MUST indicate the media
control protocol. This document defines "control_ltw_rtsp".
An "a=setup" attribute must be present and set to "active"
An "a= connection" attribute must be present and set as "new"
Marjou, et al. Expires August 28, 2008 [Page 6]
Internet-Draft SDP Offer/Answer February 2008
The SDP offer MUST additionally include at least one media delivery
channel descriptions by specifying the relative m-line(s)
It MUST include a "a=recvonly" attribute.
It MAY include a "b=" line indicating the bandwidth necessary to
handle this media delivery channel.
The SDP offer MAY indicate the association between the Media Control
channel and the Media Delivery Channels that are under its control.
If not included, it is assumed that all described Media Delivery
Channel are under its control. If not, it MUST be explicitly
indicated. [OPEN ISSUE1: Further analysis is required on how to
specify the association of media delivery channels with the
lightweight RTSP media control channel.This is to allow SDP
description to interleave media delivery streams that are associated
with lightweight RTSP media control channels with those media
delivery channels that are not controlled]
When receiving any SDP answer, the Media Control Client MUST examine
the media parameters in the received SDP. The Media Control Client
MUST use received SDP parameters for media control procedures as
described in section [TBD]
8.1.2. Media Control Server as SDP offerer
If the Media Control Serveris the SDP offerer, then the procedures in
this section MUST be followed to establish the Media Control Channel
and at least one Media Delivery Channel.This SDP offer is specified
as per the SDP specification [7].The media line for RTSP media
control channel is included with following values-
o The media field MUST have a value of "application".
o The port field MUST be a TCP port and is set to the port allocated
by the Media Control Server.
o This specification defines two new values for the transport field:
TCP/LTW_RTSP and TCP/TLS/LTW_RTSP. The former is used when RTSP
runs directly on top of TCP and the latter is used when RTSP runs
on top of TLS, which in turn runs on top of TCP.
o The fmt parameter will be set to cotrol_ltw rtsp
An "a=setup" attribute MUST be present and set as "passive"
An "a=connection" attribute MUST be present and set as "new"
One or more a=fmtp lines representing RTSP specific attributes set as
follows
Marjou, et al. Expires August 28, 2008 [Page 7]
Internet-Draft SDP Offer/Answer February 2008
o a "fmtp:control_ltw_rtsp h-session" attribute representing the
session Id of the RTSP session
o a "fmtp:control_ltw_rtsp h-uri" attribute will be set to the RTSP
URL to be used in the RTSP requests The h-uri can be in form of
absolute or relative URI. If absolute URI is specified then it is
used as is in subsequent RTSP requests by UE. If relative URI is
specified in form of a media path, then the RTSP absolute URL is
constructed by the Media Control Client using the IPAddress (from
c-line) and port (from m-line) as the base followed by h-uri value
for the media path.
o Optionally a "fmtp:control_ltw_rtsp h-offset" attribute may be
included to specify the playback position
The SDP offer MUST additionally include at least one Media Delivery
Channel descriptions by specifying the relative m-line(s)
It MUST include a "a=sendonly" attribute.
It MAY include a "b=" line indicating the bandwidth necessary to
handle this media delivery channel.
8.2. Procedures at SDP Answerer
8.2.1. Media Control Server as SDP answerer
If the Media Control Serveris the SDP answerer, then the procedures
in this section MUST be followed to establish the Media Control
Channel and at least one Media Delivery channel. The SDP answer is
per SDP specification [7]. The media line for RTSP media control
channel is included with following values-
o The media field will have a value of "application".
o The port field MUST be a TCP port and is set to the port allocated
by the Media Control Server.
A "a=setup" attribute MUST be present and set as "passive"
A "a= connection" attribute MUST be present and set as "new"
One or more a=fmtp lines representing RTSP media control specific
attributes set as follows:
o a "fmtp:control_ltw_rtsp h-uri" attribute MUST be set to the RTSP
URL to be used in the RTSP media control requests The h-uri can be
in form of absolute or relative URI. If absolute URI is specified
then it is used as by Media Control Client as-is in subsequent
RTSP requests. If relative URI is specified in form of a media
path, then the RTSP absolute URL could be constructed by the Media
Control Client using the IPAddress (from c-line) and port (from
Marjou, et al. Expires August 28, 2008 [Page 8]
Internet-Draft SDP Offer/Answer February 2008
m-line) as the base followed by h-uri value for the media path.
o a "fmtp:control_ltw_rtsp h-session" attribute representing the
session Id of the RTSP session
o Optionally a "fmtp:control_ltw_rtsp h-offset" attribute may be
included to specify the current playback position.
8.2.2. Media Control Client as SDP answerer
If the Media Control Client is the SDP answerer, then the procedures
in this section MUST be followed to establish the Media Control
Channel and at least one Media Delivery Channel. The SDP answer is
per SDP specification [7]. A media line for RTSP media control
channel is included with following values-
o The media field MUST have a value of "application".
o The port field MUST indicate a TCP port, it MUST be set to a value
of 9, which is the discard port.
o This specification defines two new values for the transport field:
TCP/LTW_RTSP and TCP/TLS/LTW_RTSP. The former is used when RTSP
runs directly on top of TCP and the latter is used when RTSP runs
on top of TLS, which in turn runs on top of TCP.
o The fmt parameter MUST indicate the media control protocol. This
document defines the value of control_ltw_rtsp.
9. Media Control Protocol
This section describes procedures to be performed at an agent for
controlling the media delivery channels that have been established
using SDP procedures specified in section [TBD] using light weight
version of RTSP streaming protocol
All the RTSP requests MUST use the same session id as specified in
the SDP h-session attribute during media control session
establishment.
The following RTSP methods MUST be supported for media playback
control and media event notifications :
o RTSP PLAY(Media Control Client ->Media Control Server)
o RTSP PAUSE(Media Control Client -> Media Control Server)
o RTSP GET_PARAMETER(Media Control Client -> Media Control Server)
o RTSP SET_PARAMETER(Media Control Client -> Media Control Server)
o RTSP ANNOUNCE (Media Control Server-> Media Control Client)(TBD:
Add reference)
o RTSP OPTION (Media Control Client > Media Control Server)
Marjou, et al. Expires August 28, 2008 [Page 9]
Internet-Draft SDP Offer/Answer February 2008
9.1. Procedures at the Media Control Client
9.1.1. Media Playback Initiation Procedure
The Media Control Client MUST follow procedures in this section to
initiate media playback using RTSP PLAY method.The RTSP fields in the
RTSP PLAY message will be filled as follows:
o The RTSP URL will be set to the value retrieved from the h-uri
attribute in the SDP response from Media Control Serverin the case
of an absolute URI. If the value of h-url is a relative URI that
is in the form of a media path, then the RTSP absolute URL is
constructed by the Media Control Client using the SDP IPAddress
(from c-line) and port (from m-line) as the base followed by h-uri
value for the media path. If the value of h-url is a absolute URL
the Media Control Client shall not perform DNS lookup. The IP
header for the RTSP PLAY message shall be set to the IP address
from the connection line ("c=") in the SDP answer and the port
from the media line ("m="). Note-The Media Control Client should
not perform DNS lookup in order to avoid misaligning the
information conveyed in the SDP with whats obtained from DNS
lookup. If the IP address provided after the DNS lookup differs
from the ones conveyed in the connection and media line the Media
Control Client would be required to renegotiate the media control
channel in order to open proxies and firewalls that may be in the
path
o The Range parameter MAY be present and set to the value retrieved
from the SDP h-offset attribute.
9.1.2. Media Playback Modification Procedure
The Media Control Client MUST follow procedures in this section to
change the modify media playback. The direction and/or speed of
media playback is modified by including a Scale header within the
RTSP PLAY request as specified in [3] and [4]
9.1.3. Media Playback Information Retrieval and Setting Procedure
The Media Control Client may retrieve the following information using
RTSP GET_PARAMETER:
o Position: The position in the media in seconds.
o Scale: The allowed scales that can be used in the PLAY request.
An empty body is allowed for RTSP keep alive.The Media Control Client
may also set the position parameter by sending the RTSP SET_PARAMETER
request.
Marjou, et al. Expires August 28, 2008 [Page 10]
Internet-Draft SDP Offer/Answer February 2008
9.1.4. Media Event Notification Procedure
If the Media Control Client receives a RTSP ANNOUNCE with a notice-
code that it does not recognize, it simply will ignore the request.
9.2. Procedures at Media Control Server
The Media Control ServerMUST answer as defined in [3] and [2]
The Media Control Server may use an RTSP ANNOUNCE to notify the Media
Control Client of any asynchronous events related to the media stream
(for example, end-of-stream).
10. Modification of Media Delivery Channel(s)
Modification of the media delivery channels including adding,
removing or modifying media parameters associated with media delivery
channels may be initiated by the Media Control Client or Media
Control Server.
The Media Control Client and the Media Control Server MUST not modify
RTSP control channel m-line description in the SDP if the media
delivery streams controlled by RTSP are not removed(port not set to
zero in m-lines) in the SDP.
11. Teardown of Media Control and Media Delivery Channels
Teardown of the RTSP media control and associated media delivery
channels (if any) MAY be initiated by the Media Control Client or
Media Control Server.
Before any session termination request at session management protocol
level, the Media Control Client or the Media Control ServerMUST close
he underlying TCP connection if one exists (such as in case of
persistent TCP connection)
12. Examples
TBD: Some examples of protocol usage to be included
13. Recommendations
We propose that further consideration for standardisation in MMUSIC
be given to this ID as it is being actively pursued by other IPTV
Marjou, et al. Expires August 28, 2008 [Page 11]
Internet-Draft SDP Offer/Answer February 2008
standardization bodies for IPTV delivery.
14. IANA Considerations
ANy new encoding'encoding format' and the media attributes may need
to be registered.
15. Security Considerations
TBD.
16. Acknowledgements
The authors would like to acknowledge those who provided valuable
inputs namely Steven Whitehead from Verizon , Marie-Jose Montpetit
from Motorola, David Ress from Nortel, Darren Loher, C. Steck, Osher
Hmelnizky, Jonathan Rosenberg, Ravishankar Shiroor, Martti Mela,
Alexandre Carinhas and Xupei Li.
17. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Schulzrinne, H., Rao, A., and R. Lanphier, "RTSP: Real Time
Streaming Protocol", RFC 2326, April 1998.
[4] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and A.
Narasimhan, "Real Time Streaming Protocol 2.0 (RTSP)",
October 2005.
[5] Shanmugan, S., Monaco, P., and B. Eberman, "A Media Resource
Control Protocol (MRCP)", RFC 4463, April 2006.
[6] Schulzrinne, H. and J. Rosenberg, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Session Description Protocol (SDP)", RFC 4145, September
2005 2005.
Marjou, et al. Expires August 28, 2008 [Page 12]
Internet-Draft SDP Offer/Answer February 2008
Authors' Addresses
Xavier Marjou
France Telecom
2, avenue Pierre Marzin
Lannion 22307
France
Email: xavier.marjou@orange-ftgroup.com
Lindquist
Ericsson
Tellusborgsvaegen 83-87
Hagersten, Hagersten 12637
Sweden
Email: jan.lindquist@ericsson.com
Priya Rajagopal
Motorola
900 Chelmsford street ; T1;09
Lowell, MA 01891
USA
Email: priya.rajagopal@motorola.com
Mikhael Said
France Telecom
38-40 rue du General Leclerc
Issy Moulineaux 92794
France
Email: mikhael.said@orange-ftgroup.com
Sam Ganesan
Motorola
80, Central street
Boxboro, MA 01719
USA
Email: Sam.Ganesan@motorola.com
Marjou, et al. Expires August 28, 2008 [Page 13]
Internet-Draft SDP Offer/Answer February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Marjou, et al. Expires August 28, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 21:23:47 |