One document matched: draft-peterson-pidf-ice-00.txt
SIMPLE WG J. Peterson
Internet-Draft NeuStar
Expires: January 10, 2005 July 12, 2004
Advertising Interactive Connectivity Establishment (ICE) Services
with Presence
draft-peterson-pidf-ice-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Many presence applications use availability information about a
presentity to show a watcher their readiness to communicate. In the
case of real-time multimedia communications, the readiness of the
presentity to communicate does not entail that the network topography
will permit communication to occur. Accordingly, this document
specifies a means to integrate Interactive Connectivity Establishment
(ICE) with presence. Presentities employing the Presence Information
Data Format (PIDF) can use the extensions in this draft to advertise
their ability to undergo a preliminary ICE check, and thus allow
Peterson Expires January 10, 2005 [Page 1]
Internet-Draft ICE and Presence July 2004
watchers to instigate ICE tests to ascertain whether or not the
intervening network is friendly to real-time multimedia
communication. In a presence application, the results of this test
could be displayed to watchers as the relative "connectivity status"
of the presentity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The 'ice' Presence Capability . . . . . . . . . . . . . . . . 3
3. Using ICE Prior to Session Establishment . . . . . . . . . . . 4
4. Using the Results of ICE in a Presence Application . . . . . . 5
5. XML Schema for the 'ice' Stanza . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
9.2 Informative References . . . . . . . . . . . . . . . . . . . 8
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Peterson Expires January 10, 2005 [Page 2]
Internet-Draft ICE and Presence July 2004
1. Introduction
Interactive Connectivity Establishment (ICE, [1]) is a mechanism that
employs the testing algorithms of STUN (Simple Traversal of UDP for
NATs, [2]) to determine how two applications on the Internet can
exchange real-time multimedia traffic through network topologies that
include Network Address Translators (NATs, [8]) and other impediments
to direct end-to-end connectivity. It is based on the use of a
higher-layer signaling protocol (such as SIP, [9]) which carries
session descriptions (such as SDP, [10]) between endpoints. The
description of the session, which includes the network address and
port at which media will be received by the respective endpoints,
serves as input to the ICE process, and is used to make a bilateral
determination of endpoint reachability. The results of these ICE
tests might influence the selection of a network address (when
multiple network interfaces are present), the usage of relays to
circumvent NATs, and so on.
In its initially-envisioned use, ICE is employed immediately prior to
the establishment of a real-time media session between endpoints.
For example, when a SIP INVITE is sent, and an offer/answer exchange
of SDP is shared, both parties to a session employ the ICE mechanism
to determine whether or not end-to-end connectivity is possible.
Presence [11]) information depicts the status and disposition of a
presentity towards a particular watcher. It encompasses availability
on the network (can I be reached now?), attitude towards
communication (do I want to be reached now?), and to some degree
application capability (what kinds of communication do I support
now?). However, these traditional attributes do not give any
indication of whether or not network topology allows communication to
be possible.
Accordingly, this specification provides a means for presence to
communicate a presentity's capability to perform ICE tests prior to
any session establishment. The results of ICE tests could be
rendered to the watcher to give them some idea of whether or not the
initiation of a real-time multimedia session with a protocol like SIP
is likely to be successful. This mechanism communicates a
presentity's ability to receive ICE tests by extending the Presence
Information Data Format (PIDF), a document format for transmitting
presence information.
2. The 'ice' Presence Capability
This specification extends the Presence Capabilities (or 'prescaps')
framework [7] for PIDF with a new element called 'ice'. Transmission
of the 'ice' stanza in a PIDF presence notification takes the place
Peterson Expires January 10, 2005 [Page 3]
Internet-Draft ICE and Presence July 2004
of the 'initiate' message in ICE processing. The 'ice' element
contains an XML representation of all the data that would appear in
an 'initiate' message - in fact, this schema is imported directly
from the canonical syntax of the 'initiate' message.
The construction of the 'ice' element follows the rules of the ICE
specification, section 5.4. Since the presentity is not actually
formulating an SDP message with a bounded set of desired media
streams, the presentity must find some other way of determining how
to populate the media-streams element. When the 'ice' element is
used in concert with the remainder of the prescaps framework,
implementations SHOULD advertise the availability of one media stream
per media capability advertised by prescaps. The advertised media
capabilities of prescaps are, broadly, the top-level MIME types
advertised in the m= lines of an SDP offer. Consequently, this is
roughly comparable to mirroring what an SDP offer might show.
Network addresses and ports to be used in the media-streams element
SHOULD be selected in the same manner as the presentity application
would ordinarily select ports for constructing a session description.
Note that this can entail the use of STUN or other mechanisms that
help endpoints to unilaterally discover appropriate relay addresses.
3. Using ICE Prior to Session Establishment
As stated above, the transmission of the 'ice' stanza of prescaps
serves the same purpose as the ICE 'initiate' message, and contains
the same information. The remaining ICE procedures are largely
identical to those described in the ICE specification - except that
ICE tests are only performed by the responder.
Prior to sending a presence notification with an 'ice' stanza,
presentities MUST perform the steps described in Section 5.1, 5.2 and
5.3 of the ICE specification. The steps in Section 5.4 are followed
as the presence notification is constructed. Similarly, when a
compliant watcher receives a NOTIFY containing a PIDF document with
an 'ice' stanza, it MUST perform the steps described in Section 5.5
of the ICE specification. However, the watcher SHOULD NOT perform
the responder steps described in Section 5.6 of the ICE
specification, including the transmission of an ICE 'accept' message,
nor any of the steps specified in subsequent subsections of Section
5.
While this makes the use of ICE in this context somewhat
unidirectional, even the unidirectional ICE tests determine whether
or not round-trip connectivity is possible. For presence, only a
watcher requires that the connectivity status of their presence-list
be determined and displayed; since presence subscriptions are not
Peterson Expires January 10, 2005 [Page 4]
Internet-Draft ICE and Presence July 2004
necessarily reciprocal, it might not be the case that any given
presentity would be interested to know the connectivity status of
some of their watchers. Presentities that are interested in the
connectivity status of watchers should maintain reciprocal presence
subscriptions with those watchers (this situation is, in most
presence applications, the norm anyway).
Note that the mechanism above will trigger an ICE test in a watcher
whenever a presence notification containing a PIDF document with an
'ice' stanza is received - no more or less frequently. Thus, if the
network topology surrounding the watcher or presentity changes
without the transmission of any new presence notification from the
presentity, the results of the ICE test may become outdated. There
is, however, no reasonable way for the presentity to monitor overall
network topology with respect to each potential watcher in order to
time the transmission of presence notifications. This is, therefore,
a limitation of the mechanism. It is RECOMMENDED that applications
transmit new presence notifications when there are known changes to
the manner in which they interface with the network, including
expiration of DHCP leases or acquisition of new network interfaces,
including VPNs. However, implementations SHOULD NOT attempt to
monitor network topology through other means, and MUST NOT use
constant pings or similar invasive monitoring techniques to determine
the necessity of triggering a new ICE test.
On the flip side, sending presence notifications expressing ICE
capability too frequently could results in redundant and unnecessary
ICE tests, which could unnecessarily burden the applications or
intervening network. The frequency of presence notifications is
generally bounded by applications, but could have a minimum interval
as low a second. Presence notifications containing a 'ice' stanza
SHOULD NOT be sent more frequently than once a minute.
4. Using the Results of ICE in a Presence Application
Once the ICE tests have been performed, a watcher's application MAY
render the results of the tests to the watcher. The manner in which
it does so is application-specific, and not a subject of
standardization. For informative purposes, an example application
result is given here.
A watcher application might express four states associated with a
presentity in a presence-list: question-mark, green, yellow, and red.
These states could be displayed as icons alongside the presentity's
name, where:
question-mark signifies that the presentity does not support the
'ice' prescap, or that no presence notifications have been
received containing that prescap, and therefore the connectivity
Peterson Expires January 10, 2005 [Page 5]
Internet-Draft ICE and Presence July 2004
status of the presentity is unknown
green signifies that there is a clean path of connectivity between
the presentity and the watcher; the establishment of real-time
multimedia sessions between the two would most likely be
successful
yellow signifies that there are network or transport-layer
disparities between the presentity and the watcher, but that known
and available relays can be used to traverse these disparities;
connectivity is possible through these relays
red signifies that there are network or transport-layer
disparities between the presentity and the watcher than cannot be
circumvented with the tools known to the watcher; new relays or
other middleboxes would need to be engaged to make real-time
multimedia sessions possible
When a presentity publishes presence from multiple sources, rendering
of the results of an ICE test naturally lends itself to the 'device
view' of presence. For example, it could be used in concert with
other preference information in presence to prioritize the devices at
which the presentity could be reached.
5. XML Schema for the 'ice' Stanza
The ICE specification already gives an XML Schema for the ICE
'initiate' message (in Section 7). Accordingly, this schema is
imported into the 'ice' prescaps element. Note that the only valid
message type that can appear in the 'ice' prescap element is the
'initiate' message.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-prescaps-ext:ice"
xmlns:tns="urn:ietf:params:xml:ns:simple-prescaps-ext:ice"
xmlns:icens="urn:ietf:params:xml:ns:ice"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="ice" type="tns:ice-elem"/>
<xs:complexType name="ice-elem">
<xs:element "ice" type="icens:message">
</xs:element>
</xs:complexType>
</xs:schema>
</xml>
Peterson Expires January 10, 2005 [Page 6]
Internet-Draft ICE and Presence July 2004
6. Security Considerations
Providing network addresses and ports in presence potentially exposes
device information that end users might not want to divulge. In this
respect, the information provided in the 'ice' presence capability
shares the privacy concerns common to most forms of presence
information. Fortunately, presence authorization has been
well-studied, and numerous mechanisms exist to prevent the
distribution of presence attributes to undesired parties.
Implementers and end-users of presence applications employing this
mechanism should be careful to treat the 'ice' presence capability
with the same privacy preferences as other forms of presence.
Presence notifications in SIP can supply confidentiality properties
(through baseline security mechanisms, including S/MIME) that prevent
eavesdroppers from overhearing addresses sent to authorization
watchers.
The Security Considerations of the ICE specification note the
importance of integrity protection to the ICE process. Without
integrity protection, it would be possible for an attacker to modify
the 'ice' stanza of a presence notification in transit, and by
substituting bad addresses the attacker might persuade the watcher
that connectivity with the presentity is impossible. Presence
notifications in SIP can supply integrity properties (through
baseline security mechanisms, including S/MIME) that prevent
men-in-the-middle from modifying the contents of a presence
notification.
7. Examples
[Ed. Note: TBD]
8. IANA Considerations
This document registers a new XML namespaces for the 'ice' stanza of
the prescaps extension to PIDF.
[Ed. Note: Registration details TBD]
9. References
9.1 Normative References
[1] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
draft-ietf-mmusic-ice-01 (work in progress), February 2004.
Peterson Expires January 10, 2005 [Page 7]
Internet-Draft ICE and Presence July 2004
[2] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
[3] Rosenberg, J., Huitema, C. and R. Mahy, "Traversal Using Relay
NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress),
February 2004.
[4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "CPIM Presence Information Data Format",
draft-ietf-impp-cpim-pidf-07 (work in progress), August 2001.
[5] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[6] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January
2004.
[7] Lonnfors, M. and K. Kiss, "User Agent Capability Extension to
Presence Information Data Format (PIDF)",
draft-ietf-simple-prescaps-ext-01 (work in progress), May 2004.
9.2 Informative References
[8] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[10] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
Peterson Expires January 10, 2005 [Page 8]
Internet-Draft ICE and Presence July 2004
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Appendix A. Acknowledgments
Thanks to Jonathan Rosenberg for some useful advice on ICE.
Peterson Expires January 10, 2005 [Page 9]
Internet-Draft ICE and Presence July 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.
Peterson Expires January 10, 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 09:13:16 |