draft-ietf-p2psip-sip-05.txt   draft-ietf-p2psip-sip-06.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: January 10, 2011 MYMIC LLC Expires: January 8, 2012 Skype
E. Rescorla E. Rescorla
Network Resonance RTFM, Inc.
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
July 9, 2010 July 7, 2011
A SIP Usage for RELOAD A SIP Usage for RELOAD
draft-ietf-p2psip-sip-05 draft-ietf-p2psip-sip-06
Abstract Abstract
This document defines a SIP Usage for REsource LOcation And Discovery This document defines a SIP Usage for REsource LOcation And Discovery
(RELOAD), The SIP Usage provides the functionality of a SIP proxy or (RELOAD), The SIP Usage provides the functionality of a SIP proxy or
registrar in a fully-distributed system. The SIP Usage provides registrar in a fully-distributed system. The SIP Usage provides
lookup service for AoRs stored in the overlay. The SIP Usage also lookup service for AoRs stored in the overlay. The SIP Usage also
defines GRUUs that allow the registrations to map an AoR to a defines GRUUs that allow the registrations to map an AoR to a
specific node reachable through the overlay. The AppAttach method is specific node reachable through the overlay. The AppAttach method is
used to establish a direct connection between nodes through which SIP used to establish a direct connection between nodes through which SIP
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 10, 2011. This Internet-Draft will expire on January 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 23 skipping to change at page 4, line 23
The SIP Usage involves two basic functions: The SIP Usage involves two basic functions:
Registration: SIP UAs can use the RELOAD data storage Registration: SIP UAs can use the RELOAD data storage
functionality to store a mapping from their AOR to their Node-ID functionality to store a mapping from their AOR to their Node-ID
in the overlay, and to retrieve the Node-ID of other UAs. in the overlay, and to retrieve the Node-ID of other UAs.
Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it
wishes to call, it can use the RELOAD message routing system to wishes to call, it can use the RELOAD message routing system to
set up a direct connection which can be used to exchange SIP set up a direct connection which can be used to exchange SIP
messages. messages.
For instance, Bob could register his Node-ID, "1234", under his AOR, For instance, Bob could register his Node-ID, "1234", under his AOR,
"sip:bob@dht.example.com". When Alice wants to call Bob, she queries "bob@dht.example.com". When Alice wants to call Bob, she queries the
the overlay for "sip:bob@dht.example.com" and gets back Node-ID 1234. overlay for "bob@dht.example.com" and gets back Node-ID 1234. She
She then uses the overlay to establish a direct connection with Bob then uses the overlay to establish a direct connection with Bob and
and can use that direct connection to perform a standard SIP INVITE. can use that direct connection to perform a standard SIP INVITE. The
The way this works is as follows: way this works is as follows:
1. Bob, operating Node-ID 1234, stores a mapping from his URI to his 1. Bob, operating Node-ID 1234, stores a mapping from his URI to his
Node-ID in the overlay. I.e., "sip:bob@dht.example.com -> 1234". Node-ID in the overlay. I.e., "bob@dht.example.com -> 1234".
2. Alice, operating Node-ID 5678, decides to call Bob. She looks up 2. Alice, operating Node-ID 5678, decides to call Bob. She looks up
"sip:bob@dht.example.com" in the overlay and retrieves "1234". "bob@dht.example.com" in the overlay and retrieves "1234".
3. Alice uses the overlay to route an AppAttach message to Bob's 3. Alice uses the overlay to route an AppAttach message to Bob's
peer. Bob responds with his own AppAttach and they set up a peer. Bob responds with his own AppAttach and they set up a
direct connection, as shown below. direct connection, as shown below.
Alice Peer1 Overlay PeerN Bob Alice Peer1 Overlay PeerN Bob
(5678) (1234) (5678) (1234)
------------------------------------------------- -------------------------------------------------
AppAttach -> AppAttach ->
AppAttach -> AppAttach ->
AppAttach -> AppAttach ->
skipping to change at page 5, line 36 skipping to change at page 5, line 36
checks complete and the connection is established, then ordinary SIP checks complete and the connection is established, then ordinary SIP
is used. In particular, the establishment of the media channel for is used. In particular, the establishment of the media channel for
the phone call happens via the usual SIP mechanisms, and RELOAD is the phone call happens via the usual SIP mechanisms, and RELOAD is
not involved. Media never goes over the overlay. After the not involved. Media never goes over the overlay. After the
successful exchange of SIP messages, call peers run ICE connectivity successful exchange of SIP messages, call peers run ICE connectivity
checks for media. checks for media.
As well as allowing mappings from AORs to Node-IDs, the SIP Usage As well as allowing mappings from AORs to Node-IDs, the SIP Usage
also allows mappings from AORs to other AORs. For instance, if Bob also allows mappings from AORs to other AORs. For instance, if Bob
wanted his phone calls temporarily forwarded to Charlie, he could wanted his phone calls temporarily forwarded to Charlie, he could
store the mapping "sip:bob@dht.example.com -> store the mapping "bob@dht.example.com -> charlie@dht.example.com".
sip:charlie@dht.example.com". When Alice wants to call Bob, she When Alice wants to call Bob, she retrieves this mapping and can then
retrieves this mapping and can then fetch Charlie's AOR to retrieve fetch Charlie's AOR to retrieve his Node-ID.
his Node-ID.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
We use the terminology and definitions from Concepts and Terminology We use the terminology and definitions from Concepts and Terminology
for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base
Protocol [I-D.ietf-p2psip-base] extensively in this document. Protocol [I-D.ietf-p2psip-base] extensively in this document.
The term AOR is the SIP "Address of Record" used to inditify a user
in SIP. For example, alice@example.com could be the AOR for Alice.
For the purposes of this specification, an AOR is consiered not to
include the scheme (e.g sip:) as the AOR needs to match the
rfc822Name in the X509v3 certificates.
3. Registering AORs 3. Registering AORs
In ordinary SIP, a UA registers its AOR and location with a In ordinary SIP, a UA registers its AOR and location with a
registrar. In RELOAD, this registrar function is provided by the registrar. In RELOAD, this registrar function is provided by the
overlay as a whole. To register its location, a RELOAD peer stores a overlay as a whole. To register its location, a RELOAD peer stores a
SipRegistration structure under its own AOR. This uses the SIP- SipRegistration structure under its own AOR. This uses the SIP-
REGISTRATION Kind-ID, which is formally defined in Section 7. REGISTRATION Kind-ID, which is formally defined in Section 7.
Note: GRUUs are handled via a separate mechanism, as described in Note: GRUUs are handled via a separate mechanism, as described in
Section 6. Section 6.
As a simple example, if Alice's AOR were "sip:alice@dht.example.com" As a simple example, if Alice's AOR were "alice@dht.example.com" and
and her Node-ID were "1234", she might store the mapping her Node-ID were "1234", she might store the mapping
"sip:alice@example.org -> 1234". This would tell anyone who wanted "alice@example.org -> 1234". This would tell anyone who wanted to
to call Alice to contact node "1234". call Alice to contact node "1234".
RELOAD peers MAY store two kinds of SIP mappings: RELOAD peers MAY store two kinds of SIP mappings:
o From AORs to destination lists (a single Node-ID is just a trivial o From AORs to destination lists (a single Node-ID is just a trivial
destination list.) destination list.)
o From AORs to other AORs. o From AORs to other AORs.
The meaning of the first kind of mapping is "in order to contact me, The meaning of the first kind of mapping is "in order to contact me,
form a connection with this peer." The meaning of the second kind of form a connection with this peer." The meaning of the second kind of
mapping is "in order to contact me, dereference this AOR". This mapping is "in order to contact me, dereference this AOR". This
allows for forwarding. For instance, if Alice wants calls to her to allows for forwarding. For instance, if Alice wants calls to her to
be forwarded to her secretary, Sam, she might insert the following be forwarded to her secretary, Sam, she might insert the following
mapping "sip:alice@dht.example.org -> sip:sam@dht.example.org". mapping "alice@dht.example.org -> sam@dht.example.org".
The contents of a SipRegistration structure are as follows: The contents of a SipRegistration structure are as follows:
enum {sip_registration_uri (1), sip_registration_route (2), enum {sip_registration_uri (1), sip_registration_route (2),
(255)} SipRegistrationType; (255)} SipRegistrationType;
select (SipRegistration.type) { select (SipRegistration.type) {
case sip_registration_uri: case sip_registration_uri:
opaque uri<0..2^16-1>; opaque uri<0..2^16-1>;
skipping to change at page 8, line 9 skipping to change at page 8, line 9
RELOAD explicitly supports multiple registrations for a single AOR. RELOAD explicitly supports multiple registrations for a single AOR.
The registrations are stored in a Dictionary with the dictionary keys The registrations are stored in a Dictionary with the dictionary keys
being Node-IDs. Consider, for instance, the case where Alice has two being Node-IDs. Consider, for instance, the case where Alice has two
peers: peers:
o her desk phone (1234) o her desk phone (1234)
o her cell phone (5678) o her cell phone (5678)
Alice might store the following in the overlay at resource Alice might store the following in the overlay at resource
"sip:alice@dht.example.com". "alice@dht.example.com".
o A SipRegistration of type "sip_registration_route" with dictionary o A SipRegistration of type "sip_registration_route" with dictionary
key "1234" and value "1234". key "1234" and value "1234".
o A SipRegistration of type "sip_registration_route" with dictionary o A SipRegistration of type "sip_registration_route" with dictionary
key "5678" and value "5678". key "5678" and value "5678".
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.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
used. Once the AppAttach succeeds, the peer sends SIP messages over used. Once the AppAttach succeeds, the peer sends SIP messages over
the connection as in normal SIP. the connection as in normal SIP.
6. GRUUs 6. GRUUs
GRUUs do not require storing data in the Overlay Instance. Rather, GRUUs do not require storing data in the Overlay Instance. Rather,
they are constructed by embedding a base64-encoded destination list they are constructed by embedding a base64-encoded destination list
in the gr URI parameter of the GRUU. The base64 encoding is done in the gr URI parameter of the GRUU. The base64 encoding is done
with the alphabet specified in table 1 of RFC 4648 with the exception with the alphabet specified in table 1 of RFC 4648 with the exception
that ~ is used in place of =. An example GRUU is that ~ is used in place of =. An example GRUU is
"sip:alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer "alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer
needs to route a message to a GRUU in the same P2P network, it simply needs to route a message to a GRUU in the same P2P network, it simply
uses the destination list and connects to that peer. uses the destination list and connects to that peer.
Because a GRUU contains a destination list, it MAY have the same Because a GRUU contains a destination list, it MAY have the same
contents as a destination list stored elsewhere in the resource contents as a destination list stored elsewhere in the resource
dictionary. dictionary.
Anonymous GRUUs are done in roughly the same way but require either Anonymous GRUUs are done in roughly the same way but require either
that the enrollment server issue a different Node-ID for each that the enrollment server issue a different Node-ID for each
anonymous GRUU required or that a destination list be used that anonymous GRUU required or that a destination list be used that
includes a peer that compresses the destination list to stop the includes a peer that compresses the destination list to stop the
Node-ID from being revealed. Node-ID from being revealed.
7. SIP-REGISTRATION Kind Definition 7. SIP-REGISTRATION Kind Definition
This section defines the SIP-REGISTRATION kind. This section defines the SIP-REGISTRATION kind.
Name SIP-REGISTRATION Name SIP-REGISTRATION
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 SipRegistration, which can
can contain either another URI or a destination list to the peer contain either another URI or a destination list to the peer which
which is acting for the user. 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. Note that this matches the SIP AOR Access Control USER-NODE-MATCH. Note that this matches the SIP AOR
against the rfc822Name in the X509v3 certificate. The rfc822Name against the rfc822Name in the X509v3 certificate. The rfc822Name
does not include the scheme so that "sip:" prefix needs to be does not include the scheme so that "sip:" prefix needs to be
removed from the SIP AOR before matching. removed from the SIP AOR before matching.
skipping to change at page 11, line 48 skipping to change at page 11, line 48
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
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-00 (work in Base Protocol", draft-ietf-p2psip-base-16 (work in
progress), October 2008. progress), July 2011.
11.2. Informative References 11.2. Informative References
[I-D.ietf-p2psip-concepts] [I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP", Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-02 (work in progress), draft-ietf-p2psip-concepts-03 (work in progress),
July 2008. October 2010.
Appendix A. Change Log Appendix A. Change Log
A.1. Changes since draft-ietf-p2psip-reload-00 A.1. Changes since draft-ietf-p2psip-reload-00
o Split SIP Usage from combined draft into new draft. o Split SIP Usage from combined draft into new draft.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com Email: fluffy@cisco.com
Bruce B. Lowekamp (editor) Bruce B. Lowekamp (editor)
MYMIC LLC Skype
1040 University Blvd., Suite 100 Palo Alto, CA
Portsmouth, VA 23703
USA USA
Email: bbl@lowekamp.net Email: bbl@lowekamp.net
Eric Rescorla Eric Rescorla
Network Resonance RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Phone: +1 650 320-8549 Phone: +1 650 678 2350
Email: ekr@networkresonance.com Email: ekr@rtfm.com
Salman A. Baset Salman A. Baset
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY New York, NY
USA USA
Email: salman@cs.columbia.edu Email: salman@cs.columbia.edu
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
 End of changes. 21 change blocks. 
37 lines changed or deleted 41 lines changed or added

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