draft-ietf-p2psip-sip-03.txt | draft-ietf-p2psip-sip-04.txt | |||
---|---|---|---|---|
P2PSIP C. Jennings | P2PSIP C. Jennings | |||
Internet-Draft Cisco | Internet-Draft Cisco | |||
Intended status: Standards Track B. Lowekamp, Ed. | Intended status: Standards Track B. Lowekamp, Ed. | |||
Expires: April 25, 2010 MYMIC LLC | Expires: September 9, 2010 MYMIC LLC | |||
E. Rescorla | E. Rescorla | |||
Network Resonance | Network Resonance | |||
S. Baset | S. Baset | |||
H. Schulzrinne | H. Schulzrinne | |||
Columbia University | Columbia University | |||
October 22, 2009 | March 8, 2010 | |||
A SIP Usage for RELOAD | A SIP Usage for RELOAD | |||
draft-ietf-p2psip-sip-03 | draft-ietf-p2psip-sip-04 | |||
Abstract | ||||
This document defines a SIP Usage for REsource LOcation And Discovery | ||||
(RELOAD), The SIP Usage provides the functionality of a SIP proxy or | ||||
registrar in a fully-distributed system. The SIP Usage provides | ||||
lookup service for AoRs stored in the overlay. The SIP Usage also | ||||
defines GRUUs that allow the registrations to map an AoR to a | ||||
specific node reachable through the overlay. The AppAttach method is | ||||
used to establish a direct connection between nodes through which SIP | ||||
messages are exchanged. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. | |||
from IETF Documents or IETF Contributions published or made publicly | ||||
available before November 10, 2008. The person(s) controlling the | ||||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
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 | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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 25, 2010. | This Internet-Draft will expire on September 9, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | ||||
described in the BSD License. | ||||
This document defines a SIP Usage for REsource LOcation And Discovery | This document may contain material from IETF Documents or IETF | |||
(RELOAD), The SIP Usage provides the functionality of a SIP proxy or | Contributions published or made publicly available before November | |||
registrar in a fully-distributed system. The SIP Usage provides | 10, 2008. The person(s) controlling the copyright in some of this | |||
lookup service for AoRs stored in the overlay. The SIP Usage also | material may not have granted the IETF Trust the right to allow | |||
defines GRUUs that allow the registrations to map an AoR to a | modifications of such material outside the IETF Standards Process. | |||
specific node reachable through the overlay. The AppAttach method is | Without obtaining an adequate license from the person(s) controlling | |||
used to establish a direct connection between nodes through which SIP | the copyright in such materials, this document may not be modified | |||
messages are exchanged. | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | ||||
it for publication as an RFC or to translate it into languages other | ||||
than English. | ||||
Table of Contents | Table of Contents | |||
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Registering AORs . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Registering AORs . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 9 | 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 9 | |||
6. GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 6. GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 9 | 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 9 | |||
skipping to change at page 10, line 17 | skipping to change at page 10, line 17 | |||
Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the | Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the | |||
AOR of the user. The data stored is a SipRegistrationData, which | AOR of the user. The data stored is a SipRegistrationData, which | |||
can contain either another URI or a destination list to the peer | can contain either another URI or a destination list to the peer | |||
which is acting for the user. | which is acting for the user. | |||
Data Model The data model for the SIP-REGISTRATION Kind-ID is | Data Model The data model for the SIP-REGISTRATION Kind-ID is | |||
dictionary. The dictionary key is the Node-ID of the storing | dictionary. The dictionary key is the Node-ID of the storing | |||
peer. This allows each peer (presumably corresponding to a single | peer. This allows each peer (presumably corresponding to a single | |||
device) to store a single route mapping. | device) to store a single route mapping. | |||
Access Control USER-NODE-MATCH. | Access Control USER-NODE-MATCH. Note that this matches the SIP AOR | |||
against the rfc822Name in the X509v3 certificate. The rfc822Name | ||||
does not include the scheme so that "sip:" prefix needs to be | ||||
removed from the SIP AOR before matching. | ||||
Data stored under the SIP-REGISTRATION kind is of type | Data stored under the SIP-REGISTRATION kind is of type | |||
SipRegistration. This comes in two varieties: | SipRegistration. This comes in two varieties: | |||
sip_registration_uri | sip_registration_uri | |||
a URI which the user can be reached at. | a URI which the user can be reached at. | |||
sip_registration_route | sip_registration_route | |||
a destination list which can be used to reach the user's peer. | a destination list which can be used to reach the user's peer. | |||
End of changes. 9 change blocks. | ||||
31 lines changed or deleted | 40 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |