draft-ietf-p2psip-sip-02.txt   draft-ietf-p2psip-sip-03.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 9, 2010 MYMIC LLC Expires: April 25, 2010 MYMIC LLC
E. Rescorla E. Rescorla
Network Resonance Network Resonance
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
October 6, 2009 October 22, 2009
A SIP Usage for RELOAD A SIP Usage for RELOAD
draft-ietf-p2psip-sip-02 draft-ietf-p2psip-sip-03
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 9, 2010. This Internet-Draft will expire on April 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 8, line 26 skipping to change at page 8, line 26
Note that this structure explicitly allows one Node-ID to forward to Note that this structure explicitly allows one Node-ID to forward to
another Node-ID. For instance, Alice could set calls to her desk another Node-ID. For instance, Alice could set calls to her desk
phone to ring at her cell phone. It's not clear that this is useful phone to ring at her cell phone. It's not clear that this is useful
in this case, but may be useful if Alice has two AORs. in this case, but may be useful if Alice has two AORs.
In order to prevent hijacking, registrations are subject to access In order to prevent hijacking, registrations are subject to access
control rules. Before a Store is permitted, the storing peer MUST control rules. Before a Store is permitted, the storing peer MUST
check that: check that:
o The certificate contains a username that is a SIP AOR that hashes o The certificate contains a username that is a SIP AOR that hashes
to the Resource-ID being stored at. to the Resource-ID it is being stored at.
o The certificate contains a Node-ID that is the same as the o The certificate contains a Node-ID that is the same as the
dictionary key being stored at. dictionary key it is being stored at.
Note that these rules permit Alice to forward calls to Bob without Note that these rules permit Alice to forward calls to Bob without
his permission. However, they do not permit Alice to forward Bob's his permission. However, they do not permit Alice to forward Bob's
calls to her. See Section 8.2.2 for more on this point. calls to her. See Section 8.2.2 for more on this point.
4. Looking up an AOR 4. Looking up an AOR
When a RELOAD user wishes to call another user, starting with a non- When a RELOAD user wishes to call another user, starting with a non-
GRUU AOR, he follows the following procedure. (GRUUs are discussed GRUU AOR, he follows the following procedure. (GRUUs are discussed
in Section 6). in Section 6).
1. Check to see if the domain part of the AOR matches the domain 1. Check to see if the domain part of the AOR matches the domain
name of an overlay of which he is a member. If not, then this is name of an overlay of which he is a member. If not, then this is
an external AOR, and he MUST do one of the following: an external AOR, and he MUST do one of the following:
* Fail the call. * Fail the call.
* Use ordinary SIP procedures. * Use ordinary SIP procedures.
* Attempt to become a member of the overlay indicated by the * Attempt to become a member of the overlay indicated by the
domain part, if that overlay is a RELOAD overlay.) domain part, if that overlay is a RELOAD overlay.)
2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID 2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID
corresponding to the AOR. This Fetch SHOULD NOT indicate any corresponding to the AOR. This Fetch SHOULD NOT indicate any
dictionary keys, which will result in fetching all the stored dictionary keys, so that it will fetch all the stored values.
values.
3. If any of the results of the Fetch are non-GRUU AORs, then repeat 3. If any of the results of the Fetch are non-GRUU AORs, then repeat
step 1 for that AOR. step 1 for that AOR.
4. Once only GRUUs and destination lists remain, the peer removes 4. Once only GRUUs and destination lists remain, the peer removes
duplicate destination lists and GRUUs from the list and forms a duplicate destination lists and GRUUs from the list and forms a
SIP connection to the appropriate peers as described in the SIP connection to the appropriate peers as described in the
following sections. If there are also external AORs, the peer following sections. If there are also external AORs, the peer
follows the appropriate procedure for contacting them as well. follows the appropriate procedure for contacting them as well.
5. Forming a Direct Connection 5. Forming a Direct Connection
skipping to change at page 11, line 36 skipping to change at page 11, line 36
This draft is a merge of the "REsource LOcation And Discovery This draft is a merge of the "REsource LOcation And Discovery
(RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B. (RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B.
Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen
Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security
Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick,
the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia
Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP)
draft by Salman A. Baset, Henning Schulzrinne, and Marcin draft by Salman A. Baset, Henning Schulzrinne, and Marcin
Matuszewski. Matuszewski.
Thanks to the many people who contributed including: Michael Chen, Thanks to Michael Chen for his contributions.
TODO - fill in.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
 End of changes. 8 change blocks. 
10 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/