draft-ietf-avt-rtp-and-rtcp-mux-00.txt | draft-ietf-avt-rtp-and-rtcp-mux-01.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Updates: 3550 (if approved) M. Westerlund | Updates: 3550 (if approved) M. Westerlund | |||
Expires: April 2, 2007 Ericsson | Intended status: Standards Track Ericsson | |||
September 29, 2006 | Expires: April 23, 2007 October 20, 2006 | |||
Multiplexing RTP Data and Control Packets on a Single Port | Multiplexing RTP Data and Control Packets on a Single Port | |||
draft-ietf-avt-rtp-and-rtcp-mux-00.txt | draft-ietf-avt-rtp-and-rtcp-mux-01.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on April 2, 2007. | This Internet-Draft will expire on April 23, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This memo discusses issues that arise when multiplexing RTP data | This memo discusses issues that arise when multiplexing RTP data | |||
packets and RTP control protocol (RTCP) packets on a single UDP port. | packets and RTP control protocol (RTCP) packets on a single UDP port. | |||
It updates RFC 3550 to describe when such multiplexing is, and is | It updates RFC 3550 to describe when such multiplexing is, and is | |||
skipping to change at page 2, line 13 ¶ | skipping to change at page 2, line 13 ¶ | |||
(SDP) can be used to signal multiplexed sessions. | (SDP) can be used to signal multiplexed sessions. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 | 4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 | |||
5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5 | 5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5 | |||
5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6 | 5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 7 | 5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6 | |||
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 7 | 5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7 | |||
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 8 | 5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7 | |||
5.1.4. Interactions with Header Compression . . . . . . . . . 7 | ||||
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8 | ||||
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 8 | ||||
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9 | ||||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 10 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 12 | Intellectual Property and Copyright Statements . . . . . . . . . . 13 | |||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [1] comprises two components: | The Real-time Transport Protocol (RTP) [1] comprises two components: | |||
a data transfer protocol, and an associated control protocol (RTCP). | a data transfer protocol, and an associated control protocol (RTCP). | |||
Historically, RTP and RTCP have been run on separate UDP ports. With | Historically, RTP and RTCP have been run on separate UDP ports. With | |||
increased use of Network Address Translation (NAT) this has become | increased use of Network Address Translation (NAT) this has become | |||
problematic, since opening multiple NAT pinholes can be costly. This | problematic, since opening multiple NAT pinholes can be costly. This | |||
memo discusses how the RTP and RTCP flows for a single media type can | memo discusses how the RTP and RTCP flows for a single media type can | |||
be run on a single port, to ease NAT traversal, and considers when | be run on a single port, to ease NAT traversal, and considers when | |||
skipping to change at page 6, line 10 ¶ | skipping to change at page 6, line 10 ¶ | |||
The procedures for multiplexing RTP and RTCP on a single port depend | The procedures for multiplexing RTP and RTCP on a single port depend | |||
on whether the session is a unicast session or a multicast session. | on whether the session is a unicast session or a multicast session. | |||
For a multicast sessions, also depends whether ASM or SSM multicast | For a multicast sessions, also depends whether ASM or SSM multicast | |||
is to be used. | is to be used. | |||
5.1. Unicast Sessions | 5.1. Unicast Sessions | |||
It is acceptable to multiplex RTP and RTCP packets on a single UDP | It is acceptable to multiplex RTP and RTCP packets on a single UDP | |||
port to ease NAT traversal for unicast sessions, provided the RTP | port to ease NAT traversal for unicast sessions, provided the RTP | |||
payload types used in the session are chosen according to the rules | payload types used in the session are chosen according to the rules | |||
in Section 4. | in Section 4. The following sections describe how such multiplexed | |||
sessions can be signalled using the Session Initiation Protocol (SIP) | ||||
with the offer/answer model. | ||||
5.1.1. SDP Signalling | ||||
When the Session Description Protocol (SDP) [8] is used to negotiate | When the Session Description Protocol (SDP) [8] is used to negotiate | |||
RTP sessions according to the offer/answer model [9], the "a=rtcp:" | RTP sessions according to the offer/answer model [9], the "a=rtcp:" | |||
attribute [10] is used to indicate the port chosen for RTCP traffic, | attribute [10] is used to indicate the port chosen for RTCP traffic | |||
if the default of using an odd/even port pair is not desirable. If | if the default of using an odd/even port pair is not desirable. If | |||
RTP and RTCP are to be multiplexed on a single port, this attribute | RTP and RTCP are to be multiplexed on a single port, this attribute | |||
MUST be included in the initial SDP offer, and MUST indicate the the | MUST be included in the initial SDP offer, and MUST indicate the same | |||
same port as included in the "m=" line. For example: | port as included in the "m=" line. For example: | |||
v=0 | v=0 | |||
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e | o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e | |||
s=- | s=- | |||
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e | c=IN IP6 2001:DB8::211:24ff:fea3:7a2e | |||
t=1153134164 1153137764 | t=1153134164 1153137764 | |||
m=audio 49170 RTP/AVP 97 | m=audio 49170 RTP/AVP 97 | |||
a=rtpmap:97 iLBC/8000 | a=rtpmap:97 iLBC/8000 | |||
a=rtcp:49170 | a=rtcp:49170 | |||
This offer denotes a unicast voice-over-IP session using the RTP/AVP | This offer denotes a unicast voice-over-IP session using the RTP/AVP | |||
profile with iLBC coding. The answerer is requested to send both RTP | profile with iLBC coding. The answerer is requested to send both RTP | |||
and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. | and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. | |||
If the answerer supports multiplexing of RTP and RTCP onto a single | If the answerer supports multiplexing of RTP and RTCP onto a single | |||
port it MUST include an "a=rtcp:" attribute in the answer. The port | port it MUST include an "a=rtcp:" attribute in the answer, and the | |||
specified in that attribute MUST be the same as that used for RTP in | port specified in that attribute MUST be the same as that used for | |||
the "m=" line of the answer. The RTP payload types used MUST conform | RTP in the "m=" line of the answer. The RTP payload types used in | |||
to the rules in Section 4, and the answer MUST be rejected if there | the answer MUST conform to the rules in Section 4. | |||
is a conflict between the chosen RTP payload types and the expected | ||||
RTCP packet types. | ||||
If the answer does not contain an "a=rtcp:" attribute, the offerer | If the answer does not contain an "a=rtcp:" attribute, the offerer | |||
MUST NOT multiplex RTP and RTCP packets on a single port. Instead, | MUST NOT multiplex RTP and RTCP packets on a single port. Instead, | |||
it must send and receive RTCP on a port allocated according to the | it must send and receive RTCP on a port allocated according to the | |||
usual port pair rules. This will occur when talking to a peer that | usual port pair rules. This will occur when talking to a peer that | |||
does not understand the "a=rtcp:" attribute or this specification. | does not understand the "a=rtcp:" attribute or this specification. | |||
If the answer contains an "a=rtcp:" attribute, but that attribute | ||||
specifies a different port for RTCP than for RTP, then the answer | ||||
MUST be rejected, and the session re-negotiated using separate RTP | ||||
and RTCP ports. | ||||
Answerers which support the "a=rtcp:" attribute but do not understand | Answerers which support the "a=rtcp:" attribute but do not understand | |||
this memo should reject sessions where the RTP and RTCP ports are the | this memo should return an answer which does not contain an "a=rtcp:" | |||
same (Section 11 of [1] prohibits such sessions unless the mechanisms | attribute (since Section 11 of [1] prohibits such sessions unless the | |||
described in this memo are used). It is likely that this is a poorly | mechanisms described in this memo are used). It is likely that this | |||
tested feature of older implementations, however, and implementations | is a poorly tested feature of older implementations, however, and | |||
should be robust to unexpected behaviour. If the offerer suspects a | implementations should be robust to unexpected behaviour. | |||
session was rejected due to the presence of multiplexed RTP and RTCP, | ||||
it MAY retry the offer using separate ports for RTP and RTCP. | ||||
When using SIP with a forking proxy, it is possible that multiple 200 | 5.1.2. Interactions with SIP forking | |||
(OK) answers will be received, some supporting multiplexed RTP and | ||||
RTCP, some not. This is not an issue if a separate RTP session is | ||||
established with each answerer, since multiplexing occurs on a per | ||||
session basis, but does prevent a single RTP session being opened | ||||
between the offerer and all answerers. | ||||
TODO: expand this discussion. Does SIP define if this should be a | When using SIP with a forking proxy, it is possible that an INVITE | |||
single RTP session or multiple sessions? | request may result in multiple 200 (OK) responses. If RTP and RTCP | |||
multiplexing is offered in that INVITE, it is important to be aware | ||||
that some answerers may support multiplexed RTP and RTCP, some not. | ||||
This will require the offerer listen for RTCP on both the RTP port | ||||
and the usual RTCP port, and to send RTCP on both ports, unless | ||||
branches of the call that support multiplexing are re-negotiated to | ||||
use separate RTP and RTCP ports. | ||||
TODO: discuss interactions between multiplexed RTP and RTCP, and | 5.1.3. Interactions with ICE | |||
Interactive Connectivity Establishment (ICE) [15]. | ||||
It is common to use the Interactive Connectivity Establishment (ICE) | ||||
[15] methodology to establish RTP sessions in the presence of Network | ||||
Address Translation (NAT) devices or other middleboxes. An RTP media | ||||
stream usually comprises two components in ICE (one for RTP and one | ||||
for RTCP), and connectivity checks are performed for each component. | ||||
The RTCP port must always be explicitly signalled using the "a=rtcp:" | ||||
attribute when using ICE. | ||||
When RTP and RTCP are to be multiplexed on a single UDP port, there | ||||
is no need to perform ICE checks for the RTCP traffic. Accordingly, | ||||
each RTP stream MUST be treated as comprising only a single component | ||||
when multiplexing is in use (this can be detected by the port on the | ||||
"a=rtcp:" line matching that on the "m=" line). Multiplexing RTP and | ||||
RTCP therefore cuts the number of ICE checks that must be performed | ||||
in half. | ||||
5.1.4. Interactions with Header Compression | ||||
Multiplexing RTP and RTCP packets onto a single port may negatively | ||||
impact header compression schemes, for example Compressed RTP (CRTP) | ||||
[16] and RObust Header Compression (ROHC) [17]. Header compression | ||||
exploits patterns of change in the RTP headers of consecutive packets | ||||
to send an indication that the packet changed in the expected way, | ||||
rather than sending the complete header each time. This can lead to | ||||
significant bandwidth savings if flows have uniform behaviour. The | ||||
presence of RTCP packets multiplexed with RTP data packets disrupts | ||||
these patterns, however, and can significantly reduce the gains | ||||
available due to header compression. | ||||
This effect may be especially significant in those environments, such | ||||
as some wireless telephony systems, which rely on the efficiency of | ||||
header compression to match the media to a limited capacity channel. | ||||
The implications of multiplexing RTP and RTCP should be carefully | ||||
considered before use in such environments. | ||||
5.2. Any Source Multicast Sessions | 5.2. Any Source Multicast Sessions | |||
The problem of NAT traversal is less severe for any source multicast | The problem of NAT traversal is less severe for any source multicast | |||
(ASM) RTP sessions than for unicast RTP sessions, and the benefit of | (ASM) RTP sessions than for unicast RTP sessions, and the benefit of | |||
using separate ports for RTP and RTCP is greater, due to the ability | using separate ports for RTP and RTCP is greater, due to the ability | |||
to support third party RTCP only monitors. Accordingly, RTP and RTCP | to support third party RTCP only monitors. Accordingly, RTP and RTCP | |||
packets SHOULD NOT be multiplexed onto a single port when using ASM | packets SHOULD NOT be multiplexed onto a single port when using ASM | |||
multicast RTP sessions, and SHOULD instead use separate ports and | multicast RTP sessions, and SHOULD instead use separate ports and | |||
multicast groups. | multicast groups. | |||
skipping to change at page 8, line 38 ¶ | skipping to change at page 9, line 21 ¶ | |||
packets on the SSM channel, even if sent on a separate port). | packets on the SSM channel, even if sent on a separate port). | |||
6. Multiplexing, Bandwidth, and Quality of Service | 6. Multiplexing, Bandwidth, and Quality of Service | |||
Multiplexing RTP and RTCP has implications on the use of Quality of | Multiplexing RTP and RTCP has implications on the use of Quality of | |||
Service (QoS) mechanism that handles flow that are determined by a | Service (QoS) mechanism that handles flow that are determined by a | |||
three or five tuple (protocol, port and address for source and/or | three or five tuple (protocol, port and address for source and/or | |||
destination). In these cases the RTCP flow will be merged with the | destination). In these cases the RTCP flow will be merged with the | |||
RTP flow when multiplexing them together. Thus the RTCP bandwidth | RTP flow when multiplexing them together. Thus the RTCP bandwidth | |||
requirement needs to be considered when doing QoS reservations for | requirement needs to be considered when doing QoS reservations for | |||
the combinded RTP and RTCP flow. However from an RTCP perspective it | the combined RTP and RTCP flow. However from an RTCP perspective it | |||
is beneficial to receive the same treatment of RTCP packets as for | is beneficial to receive the same treatment of RTCP packets as for | |||
RTP as it provides more accurate statistics for the measurements | RTP as it provides more accurate statistics for the measurements | |||
performed by RTCP. | performed by RTCP. | |||
The bandwidth required for a multiplexed stream comprises the session | The bandwidth required for a multiplexed stream comprises the session | |||
bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the | bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the | |||
usual case, the RTP session bandwidth is signalled in the SDP "b=AS:" | usual case, the RTP session bandwidth is signalled in the SDP "b=AS:" | |||
line, and the RTCP traffic is limited to 5% of this value. Any QoS | line, and the RTCP traffic is limited to 5% of this value. Any QoS | |||
reservation SHOULD therefore be made for 105% of the "b=AS:" value. | reservation SHOULD therefore be made for 105% of the "b=AS:" value. | |||
If a non-standard RTCP bandwidth fraction is used, signalled by the | If a non-standard RTCP bandwidth fraction is used, signalled by the | |||
skipping to change at page 9, line 31 ¶ | skipping to change at page 10, line 14 ¶ | |||
have been demultiplexed, cryptographic processing happens in the | have been demultiplexed, cryptographic processing happens in the | |||
usual manner. | usual manner. | |||
8. IANA Considerations | 8. IANA Considerations | |||
No IANA actions are required. | No IANA actions are required. | |||
9. Acknowledgements | 9. Acknowledgements | |||
We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar | We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar | |||
Hellstrom, Randell Jesup, Hadriel Kaplan and Harikishan Desineni for | Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, and | |||
their comments on this memo. This work is supported in part by the | Stephan Wenger for their comments on this memo. This work is | |||
UK Engineering and Physical Sciences Research Council. | supported in part by the UK Engineering and Physical Sciences | |||
Research Council. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, | [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, | |||
"RTP: A Transport Protocol for Real-Time Applications", STD 64, | "RTP: A Transport Protocol for Real-Time Applications", STD 64, | |||
RFC 3550, July 2003. | RFC 3550, July 2003. | |||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
skipping to change at page 11, line 5 ¶ | skipping to change at page 11, line 34 ¶ | |||
[14] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM | [14] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM | |||
SIGCOMM Computer Communication Review, Volume 22, Number 3, | SIGCOMM Computer Communication Review, Volume 22, Number 3, | |||
July 1992. | July 1992. | |||
[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A | [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A | |||
Methodology for Network Address Translator (NAT) Traversal for | Methodology for Network Address Translator (NAT) Traversal for | |||
Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in | Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in | |||
progress), August 2006. | progress), August 2006. | |||
[16] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for | ||||
Low-Speed Serial Links", RFC 2508, February 1999. | ||||
[17] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., | ||||
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., | ||||
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., | ||||
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): | ||||
Framework and four profiles: RTP, UDP, ESP, and uncompressed", | ||||
RFC 3095, July 2001. | ||||
Authors' Addresses | Authors' Addresses | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | Department of Computing Science | |||
17 Lilybank Gardens | 17 Lilybank Gardens | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
Magnus Westerlund | Magnus Westerlund | |||
Ericsson | Ericsson | |||
Torshamgatan 23 | Torshamgatan 23 | |||
Stockholm SE-164 80 | Stockholm SE-164 80 | |||
Sweden | Sweden | |||
Email: magnus.westerlund@ericsson.com | Email: magnus.westerlund@ericsson.com | |||
Intellectual Property Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2006). | ||||
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 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 | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | 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 | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 12, line 29 ¶ | skipping to change at page 13, line 45 ¶ | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | 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 (2006). 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 | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 21 change blocks. | ||||
66 lines changed or deleted | 112 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |