Network Working Group J. Rosenberg
Internet-Draft Cisco
Intended status: Standards Track February 15, 2008
Expires: August 18, 2008
NICE: Non Session Initiation Protocol (SIP) usage of Interactive
Connectivity Establishment (ICE)
draft-rosenberg-mmusic-ice-nonsip-00
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 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Interative Connectivity Establishment (ICE) has been specified as a
NAT traversal mechanism for protocols based on the offer/answer
exchange model. In practice, only the Session Initiation Protocol
(SIP) has been based on the offer/answer model. This document
defines a SIP independent subset of ICE, called NICE, which can be
used with any protocol wishing to establish a direct host-to-host
relationship through NAT. Protocol specifications need only
Rosenberg Expires August 18, 2008 [Page 1]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
reference this document, and include the object defined here in their
messages, in order to achieve NAT traversal.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Can My Protocol Use NICE? . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
5. Differences between ICE and NICE . . . . . . . . . . . . . . . 6
6. Gathering Candidates . . . . . . . . . . . . . . . . . . . . . 8
7. Sending an Initiate Message . . . . . . . . . . . . . . . . . 8
8. Receiving an Initiate Message . . . . . . . . . . . . . . . . 9
9. Receiving an Accept Message . . . . . . . . . . . . . . . . . 9
10. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 10
11. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . . 10
12. Subsequent Messaging . . . . . . . . . . . . . . . . . . . . . 10
13. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 10
14. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 10
15. The NICE Object . . . . . . . . . . . . . . . . . . . . . . . 11
16. Security Considerations . . . . . . . . . . . . . . . . . . . 12
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
18. Tongue Twister . . . . . . . . . . . . . . . . . . . . . . . . 13
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
19.1. Normative References . . . . . . . . . . . . . . . . . . 13
19.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Rosenberg Expires August 18, 2008 [Page 2]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
1. Introduction
Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice]
has been specified by the IETF as a mechanism for NAT traversal for
protocols based on the offer/answer model [RFC3264], which exchanges
Session Description Protocol (SDP) [RFC4566] objects to negotiate
media sessions.
ICE has many benefits. It is automated, relying on very little
configuration. It works through an extremely broad range of network
and NAT topologies. It is robust, establishing connections in many
challenging environments. It is efficient, utilizing relays and
intermediaries only when other options will not work. At the time of
writing, ICE has seen widespread usage on the Internet for traversal
of Voice over IP, primarily based on the Session Initiation Protocol
(SIP) [RFC3261]
However, SIP is not the only protocol that requires the establishment
of host-to-host relationships for communications. Consequently, ICE
has recently been considered as the NAT traversal technique for other
protocols. These include Peer-to-Peer SIP (P2PSIP)
[I-D.bryan-p2psip-reload], Host Identity Protocol (HIP)
[I-D.manyfolks-hip-sturn] and Mobile IP v6 [I-D.tschofenig-mip6-ice].
In each case, the protocol in question provides a mechanism for two
hosts to rendezvous through some intermediary, and then needs a host-
to-host connection established. This fits the NAT traversal
capability provided by ICE.
Unfortunately, the ICE specification itself is intertwined with SDP
and the offer/answer model, and is not immediately usable by
protocols that do not utilize offer/answer. For this reason, each of
these protocols has needed to define its own usage of ICE. This
results in duplicate work and inconsistent solutions for NAT
traversal.
To remedy this, this document defines a generic NAT traversal
solution based on ICE, called NICE. It does so by referencing the
specific parts of the ICE specification that are needed. It also
defines a simply object that can be exchanged in other protocols.
Consequently, protocols that fit the design pattern for NICE need
only reference this document, and provide a way to include the
defined object in their messages. With that, they have a solution
for NAT traversal.
2. Can My Protocol Use NICE?
Not all protocols can make use of NICE. NICE works only with
Rosenberg Expires August 18, 2008 [Page 3]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
protocols that fit the pattern of a session protocol. A session
protocol is one in which there exists some kind of rendezvous
service, typically through a server on the Internet, by which hosts
can contact each other. Through the rendezvous service, hosts can
exchange information for the purposes of negotiating a direct host to
host connection. Each host is assumed to have an identifier by which
it is known to the rendezvous service, and by which other hosts can
identify it. There is typically some kind of registration operation,
by which a host connects to the rendezvous service and identifies
itself. This protocol design pattern is shown in Figure 1.
+--------------+
| |
| |
> | Rendezvous | \
/ | Service | \
/ | | \
/ | | \
/ | | \
/ +--------------+ \
/ \
/ Connect \
/ To Y \
/ \
+--------+ +--------+
| | | |
| | | |
| Host | ......................... | Host |
| ID:X | | ID:Y |
| | | |
+--------+ +--------+
Figure 1: Session Protocols
If hosts can reach each other through the rendezvous service, why
create direct connections? Typically, the rendezvous service
provides an indirect connection, and may be very suboptimal in terms
of latency and other path metrics. The rendezvous service may also
have limited bandwidth, and not be capable of supporting the volume
of data required to flow between the hosts.
As an example, in SIP, the rendezvous service is the SIP server. The
identifier is the SIP URI. The registration process is supported
using the REGISTER method. Connections are established using the
INVITE method.
Rosenberg Expires August 18, 2008 [Page 4]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
For a protocol to use NICE, it must exhibit the properties of a
session protocol as described above. Furthermore, it must provide a
mechanism for exchanging MIME objects between the hosts for purposes
of establishing the connection. It must provide for, at least, one
message from the initiator to the other host, and one message back.
If all of these criteria are met, NICE can be used.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, this document introduces the following terms:
Session Initiator: A software or hardware entity on a host that
wishes to establish establish communications with another host,
called the session responder. A session initiator is also called
an initiator.
Initiator: Another term for a session initiator.
Session Responder: A software or hardware entity on a host that
receives a request for establishment of communications from the
session initiator, and either accepts or declines the request. A
session responder is also called a responder.
Responder: Another term for a session responder.
Client: Either the initiator or responder.
Peer: From the perspective of one of the clients in a session, its
peer is the other client. Specifically, from the perspective of
the initiator, the peer is the responder. From the perspective of
the responder, the peer is the initiator.
Rendezvous Service: A protocol service provided to the clients that
allows them to identify each other using a well known identifier,
and then send messages back and forth.
Initiate Message: The message in the rendezvous protocol used by an
initiator to establish communications. It contains the ICE
parameters needed to establish communications.
Rosenberg Expires August 18, 2008 [Page 5]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
Accept Message: The message in the rendezvous protocol used by a
responder to establish communications. It contains the ICE
parameters needed to establish communications.
4. Overview of Operation
To utilize NICE, one host, the INITIATOR, sends a message using the
rendezvous protocol. This message is addressed towards another host,
the RESPONDER. This message is called the Initiate message. That
message contains a MIME object, specified in Section 15, which
includes the information needed by NICE. In particular, it contains
a set of candidates for the purposes of establishing a single
"stream". This stream is a host-to-host UDP association or TCP
connection. The rendezvous service delivers the Initiate message to
the RESPONDER. It sends a message back to the initiator, called the
Accept message. This message also carries the same object,
containing information from the Responder for the purposes of
establishing the stream.
NICE uses server reflexive and relayed candidates learned from
Session Traversal Utilities for NAT (STUN) STUN
[I-D.ietf-behave-rfc3489bis] and Traversal Using Relay through NAT
(TURN) [I-D.ietf-behave-turn] servers. These functions can be
provided by the rendezvous service, or by traditional STUN and TURN
servers in the network. The candidates learned from these servers
are what is included in the objects exchanged through the rendezvous
protocol.
Once exchanged, the clients perform connectivity checks. These
checks probe for connectivity between the pairs of candidates
signaled through the rendezvous protocol. Once a match is found, the
Initiator sends an updated connectivity check, indicating that a pair
has been selected. At that point, packets can flow between initiator
and responder.
5. Differences between ICE and NICE
NICE differs from ICE in two fundamental ways. Firstly, it is
abstracted from SDP and RTP specifics. Secondly, it is subsetted.
This subsetting operation removes many of the features in ICE that
are there for reasons having to do with the nuances of SIP, or the
need for real-time operation. In particular, the following ICE
features are not used in NICE:
o ICE has the notion of a default candidate. This default candidate
is used for backwards compatibility with pre-ICE SIP
Rosenberg Expires August 18, 2008 [Page 6]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
implementations. That mechanism is very specific to SDP backwards
compatibility techniques, and is not used here. Instead, if the
protocol using NICE requires backwards compatibility, it needs to
define its own mechanisms for such.
o ICE supports the notion of updated offers and answers that can
modify information. Indeed, it requires such an update when the
pair selected by ICE does not match the default. The notion of
default has been removed in NICE, as has the ability to update the
ICE information. This update allowed for mid-call changes in
connectivity, a frequent occurrence in events like call transfer.
If a protocol using NICE requires a connection to a different
host, it has to start a totally new and unrelated ICE session.
This can result in discontinuous connectivity while the checks re-
run. Continuous operation is needed for real-time usage, but not
more generally.
o Simllarly, ICE restarts are not supported in NICE. Restarts are
an artifact of sending updated offers and answers.
o ICE provides some guidance for handling SIP forking. This is a
case where a single offer elicits multiple answers. Forking is
specific to SIP, and so this capability is removed from NICE.
NICE allows connectivity to be set up only between a pair of
hosts.
o ICE defines a lite mode of operation for supporting ease of
implementation. Since NICE is already simpler by the removal of
several large ICE features (most notably updated offers and
answers), this simplified mode seems unneeded. It seems better to
simplify NICE overall rather than define complexity in the normal
mode in order to introduce a simplified lite mode.
o ICE supports the notion of multiple streams and multiple
components per stream. This was done specifically to address the
needs of multimedia. NICE provides the ability to establish a
single connection between a pair of hosts. Consequently, that
capability is not present in NICE.
o ICE defines an algorithm called the Frozen algorithm. This
algorithm exists to speed up completion of ICE in cases where
multiple candidates share similar properties. For example, when
an audio and video candidate are on the same host IP address.
Since NICE only supports a single candidate and a single
component, the use cases for the Frozen algorithm diminish
significantly. Furthermore, the Frozen algorithm is entirely
about speed and is not as much an issue for more general non-real
tiem protocols . Thus, this algorithm is not used by NICE. It
Rosenberg Expires August 18, 2008 [Page 7]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
falls out by using the algorithm defined in ICE, but by setting
each foundation to a unique value.
o ICE defines SDP attributes for "remote-candidates". These are
used to resolve a race condition between a subsequent offer/answer
and the ICE checks. Since NICE does not use any subsequent
rendezvous signaling, this attribute and its procedures are not
used in NICE.
o ICE defines an SDP attribute called "ice-mismatch". This detects
an ICE failure case due to the presence of signaling
intermediaries that don't support ICE. This problem is specific
to SIP and thus this attribute and associated procedures are not
used in NICE.
6. Gathering Candidates
When a client wishes to establish a connection, it follows the
process of gathering candidates as described in Section 4.1 of ICE
[I-D.ietf-mmusic-ice]. However, the client MUST follow those rules
under the assumption of a single media stream and a single component
for that stream. This simplification means that component ID for an
ICE candidate is always one. In addition, the rules in Section
4.1.1.3 MUST be ignored; instead, each candidate MUST have a unique
foundation, assigned arbitrarily by the client.
If the client wishes to establish a TCP connection and not a UDP
stream, or wishes to try both, the client MUST implement ICE-tcp
[I-D.ietf-mmusic-ice], and MUST follow the procedures defined there
for gathering of TCP candidates, again assuming a single component.
The default candidate selection described in Section 4.1.3 of ICE
MUST be ignored; defaults are not signaled or utilized here.
The ICE specification assumes that an ICE agent is configured with,
or somehow knows of, TURN and STUN servers. Protocols using ICE need
to describe how such information is learned by clients.
7. Sending an Initiate Message
Section 4.3 of ICE describes procedures for encoding the SDP.
Instead of actually encoding an SDP, the candidate information (IP
address and port and transport protocol, priority, foundation,
component ID, type and related address) is carried within the object
defined in Section 15. Similarly, the username fragment and password
are carried in this object. This object does not contain any default
Rosenberg Expires August 18, 2008 [Page 8]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
candidates or the ice-lite attribute, as these features of ICE are
not used in NICE. The object does contain a Next-Protocol field.
This field is a string that contains the protocol name that is to be
run over the TCP or UDP association created by ICE. These names are
drawn from the list of protocols defined by IANA at
http://www.iana.org/assignments/port-numbers. Note that, since NICE
will cause STUN and this protocol to be multiplexed on the same port,
NICE can only be used to negotiate protocols that can be
differentiated from STUN by inspection. If the desired protocol
cannot be differentiated, it MUST be shimmed with a field that allows
such differentiation, and the resulting protocol MUST be given a new
name.
8. Receiving an Initiate Message
A responder MUST take the role of controlled. The role determination
mechanism in Section 5.2 of ICE is not used with NICE. The ICE
verification step in Section 5.1 is not used either. Instead,
protocols using this specification will need to describe how to
handle interoperability between clients which are using it, and ones
which are not.
The responder follows the procedures in Section 6 to gather
candidates. It then forms an Accept message and includes the object
defined in Section 15.
The responder MUST follow the procedures in Section 5.7 and 5.8 of
ICE, following the full implementation requirements and behaving as
if there was a single media stream with a single component. Because
there is only a single media stream and single component in NICE, the
states described in Section 5.7.4 will become simplified. There will
only be a single check list, and none of the candidate pairs will
ever have the state of Frozen; all pairs will start in the Waiting
state.
9. Receiving an Accept Message
When the initiator receives a response message, it extracts and NICE
object from the message. The initiator MUST take the role of
controlled, and then MUST follow the procedures of Section 5.7 and
5.8 of ICE, following the full implementation requirements and
behaving as if there was a single media stream with a single
component.
Rosenberg Expires August 18, 2008 [Page 9]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
10. Connectivity Checks
The process of performing connectivity checks, as described in
Section 7 of ICE, is used here without change. This means that STUN
connectivity checks will contain the ICE-CONTROLLED and ICE-
CONTROLLING attributes. Strictly speaking, these are not needed.
However, they are retained here to allow for the possibility of
gatewaying between NICE and ICE (for example, in the event that H.323
decided to utilize NICE).
11. Concluding ICE
The controlling client MUST utilize regular nomination. This is to
ensure consistent state on the final selected pairs without the need
for additional signaling.
The procedures in Section 8 of ICE are followed to conclude ICE, with
the following exceptions:
o The controlling agent MUST NOT attempt to send an updated offer
once the state of its single media stream reaches Completed.
o Once the state of ICE reaches Completed, the agent can immediately
free all unused candidates. This is because the concept of
forking is not used here, and thus the three second delay in
Section 8.3 of ICE does not apply.
12. Subsequent Messaging
A client MUST NOT send additional Initiate or Accept messages. Thus,
the procedures in Section 9 of ICE MUST be ignored. A client that
needs to modify its connection parameters in some way MUST establish
a completely new connection by starting a totally new Initiate/Accept
exchange and ICE connectivity checks.
13. Keepalives
A NICE client MUST utilize STUN for the keepalives described in
Section 10 of ICE.
14. Sending and Receiving Data
A client follows the procedures of Section 11.1.1 of ICE to determine
when it can proceed to send data. However, in this case, the "media"
Rosenberg Expires August 18, 2008 [Page 10]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
takes the form of application layer protocols. The concept of a
previous selected pair for a component does not apply to NICE, since
ICE restarts are not used. A client MUST be prepared to receive data
at any time.
15. The NICE Object
NICE operates by exchaning a MIME object, called the NICE object, in
an initiate and response message. The syntax of that object is
described here using the BNF defined in [RFC5234].
NICE-obj = nice-ufrag CRLF
nice-pwd CRLF
nice-proto CRLF
1*(nice-cand CRLF)
*(nice-opts CRLF)
*(nice-ext CRLF)
nice-ufrag = ice-pwd-att
nice-pwd = ice-ufrag-att
nice-cand = candidate-attribute
nice-opts = ice-options
nice-proto = "nextproto:" token
nice-ext = ext-name ":" ext-value
ext-name = token
ext-value = byte-string
The BNF productions for ice-pwd-att, ice-ufrag-att, candidate-
attribute and ice-options are defined in [I-D.ietf-mmusic-ice]. The
NICE object also contains an extensibility mechanism, allowing new
parameters to be defined which follow the form of name:value. The
grammar for the name and its value follow those for SDP attributes.
This allows for a direct copying of any future ICE-related SDP
extensions into NICE without translations or specifications; the
attribute is simply placed into the bottom of the NICE object using
the grammar defined for it in the ICE extension.
The nextproto field contains an indication of the protocol that is to
be multiplexed with STUN over the established connection. In some
cases there is only one choice, based on the rendezvous protocol.
STUN connectivity checks between agents are authenticated using the
short term credential mechanism defined for STUN
[I-D.ietf-behave-rfc3489bis]. This mechanism relies on a username
and password that are exchanged through protocol machinery between
the client and server. With NICE, the Initiate and Accept exchange
is used to exchange them. The username part of this credential is
Rosenberg Expires August 18, 2008 [Page 11]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
formed by concatenating a username fragment from each agent,
separated by a colon. Each agent also provides a password, used to
compute the message integrity for requests it receives. The username
fragment and password are exchanged in the nice-ufrag and nice-pwd
attributes, respectively. In addition to providing security, the
username provides disambiguation and correlation of checks to media
streams.
16. Security Considerations
ICE provides an extensive discussion on security considerations.
That discussion applies here as well.
In particular, ICE security depends in part on message integrity and
confidentiality of the offer/answer exchange. In the case of NICE,
the rendezvous protocol carrying the ICE object needs to provide
confidentiality and message integrity. Rendezvous protocols
utilizing ICE MUST implement and SHOULD use some kind of mechanism to
achieve that.
17. IANA Considerations
This specification registers a new MIME type, "message/nice",
according to the procedures of RFC 2048 [RFC2048]. This allows NICE
to readily be used with protocols that provide MIME transport, though
MIME transport is not required to use NICE.
MIME media type name: message
MIME subtype name: nice
Mandatory parameters: None
Optional parameters: None.
Encoding considerations: None
Security considerations: See Section 16 of RFC XXXX [[RFC EDITOR:
Replace with RFC number of this specification]].
Interoperability considerations: none.
Published specification: RFC XXXX [[NOTE TO RFC EDITOR: Please
replace XXXX with the published RFC number of this
specification.]].
Rosenberg Expires August 18, 2008 [Page 12]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
Applications which use this media type: This media type is used in
the NICE protocol defined in in RFC XXXX [[NOTE TO RFC EDITOR:
Please replace XXXX with the published RFC number of this
specification.]].
Additional Information:
Magic Number: None
File Extension: .nic
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.
18. Tongue Twister
Say this five times fast: "ICE is nice, but NICE is nicer ICE".
19. References
19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-14 (work in progress),
February 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Rosenberg Expires August 18, 2008 [Page 13]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-06 (work in progress),
January 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
19.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[I-D.bryan-p2psip-reload]
Jennings, C., Lowekamp, B., Rescorla, E., and J.
Rosenberg, "REsource LOcation And Discovery (RELOAD)",
draft-bryan-p2psip-reload-02 (work in progress),
November 2007.
[I-D.manyfolks-hip-sturn]
Nikander, P., Melen, J., Komu, M., and M. Bagnulo,
"Mapping STUN and TURN messages on HIP",
draft-manyfolks-hip-sturn-01 (work in progress),
November 2007.
[I-D.tschofenig-mip6-ice]
Tschofenig, H. and G. Bajko, "Mobile IP Interactive
Connectivity Establishment (M-ICE)",
draft-tschofenig-mip6-ice-01 (work in progress),
July 2007.
Rosenberg Expires August 18, 2008 [Page 14]
Internet-Draft NICE: ICE for non-SIP Protocols February 2008
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires August 18, 2008 [Page 15]
Internet-Draft NICE: ICE for non-SIP Protocols 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).
Rosenberg Expires August 18, 2008 [Page 16]