< draft-ietf-p2psip-sip-17.txt		draft-ietf-p2psip-sip-18.txt >
	P2PSIP C. Jennings		P2PSIP C. Jennings
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track B. Lowekamp		Intended status: Standards Track B. Lowekamp
	Expires: September 10, 2016 Skype		Expires: October 9, 2016 Skype
	E. Rescorla		E. Rescorla
	RTFM, Inc.		RTFM, Inc.
	S. Baset		S. Baset
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	T. Schmidt, Ed.		T. Schmidt, Ed.
	HAW Hamburg		HAW Hamburg
	March 9, 2016		April 7, 2016
	A SIP Usage for RELOAD		A SIP Usage for RELOAD
	draft-ietf-p2psip-sip-17		draft-ietf-p2psip-sip-18
	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 and includes a lookup service		registrar in a fully-distributed system and includes a lookup service
	for Address of Records (AORs) stored in the overlay. It also defines		for Address of Records (AORs) stored in the overlay. It also defines
	Globally Routable User Agent Uris (GRUUs) that allow the		Globally Routable User Agent URIs (GRUUs) that allow the
	registrations to map an AOR to a specific node reachable through the		registrations to map an AOR to a specific node reachable through the
	overlay. After such initial contact of a peer, the AppAttach method		overlay. After such initial contact of a peer, the RELOAD AppAttach
	is used to establish a direct connection between nodes through which		method is used to establish a direct connection between nodes through
	SIP messages are exchanged.		which SIP messages are exchanged.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 10, 2016.		This Internet-Draft will expire on October 9, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	his Node-ID in the overlay by applying a Store request for		his Node-ID in the overlay by applying a Store request for
	"bob@dht.example.com -> 1234".		"bob@dht.example.com -> 1234".
	2. Alice, operating Node-ID "5678", decides to call Bob. She		2. Alice, operating Node-ID "5678", decides to call Bob. She
	retrieves Node-ID "1234" by performing a Fetch request on		retrieves Node-ID "1234" by performing a Fetch request on
	"bob@dht.example.com".		"bob@dht.example.com".
	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 (ID "1234"). Bob responds with his own AppAttach and they		peer (ID "1234"). Bob responds with his own AppAttach and they
	set up a direct connection, as shown in Figure 1. Note that		set up a direct connection, as shown in Figure 1. Note that
	mutual ICE checks are invoked automatically from AppAttach		mutual Interactive Connectivity Establishment (ICE) checks are
	message exchange.		invoked automatically from AppAttach message exchange.
	Overlay		Overlay
	Alice Peer1 ... PeerN Bob		Alice Peer1 ... PeerN Bob
	(5678) (1234)		(5678) (1234)
	-------------------------------------------------		-------------------------------------------------
	AppAttach ->		AppAttach ->
	AppAttach ->		AppAttach ->
	AppAttach ->		AppAttach ->
	AppAttach ->		AppAttach ->
	<- AppAttach		<- AppAttach
	skipping to change at page 12, line 26 ¶		skipping to change at page 12, line 26 ¶
	possible that the peers already have a RELOAD connection mutually		possible that the peers already have a RELOAD connection mutually
	established. This MUST NOT be used for SIP messages unless it is a		established. This MUST NOT be used for SIP messages unless it is a
	SIP connection. A previously established SIP connection MAY be used		SIP connection. A previously established SIP connection MAY be used
	for a new call.		for a new call.
	Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted		Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted
	SIP messages over the connection as in normal SIP. A caller MAY		SIP messages over the connection as in normal SIP. A caller MAY
	choose to contact the callee using SIP or secure SIPS, but SHOULD		choose to contact the callee using SIP or secure SIPS, but SHOULD
	follow a preference indicated by the callee in its contact_prefs		follow a preference indicated by the callee in its contact_prefs
	attribute (see Section 3.2). A callee MAY choose to listen on both		attribute (see Section 3.2). A callee MAY choose to listen on both
	SIP and SIPS ports and accept calls from either SIP scheme, or select		SIP and SIPS ports and accept calls from either SIP schemes, or
	a single one. However, a callee that decides to accept SIPS calls,		select a single one. However, a callee that decides to accept SIPS
	only, SHOULD indicate its choice by setting the corresponding		calls, only, SHOULD indicate its choice by setting the corresponding
	attribute in its contact_prefs. It is noteworthy that according to		attribute in its contact_prefs. It is noteworthy that according to
	[RFC6940] all overlay links are built on (D)TLS secured transport.		[RFC6940] all overlay links are built on (D)TLS secured transport.
	While hop-wise encrypted paths do not prevent the use of plain SIP,		While hop-wise encrypted paths do not prevent the use of plain SIP,
	SIPS requires end-to-end protection that may include client links and		SIPS requires end-to-end protection that may include client links and
	endpoint certificates.		endpoint certificates.
	SIP messages carry the SIP URIs of actual overlay endpoints (e.g.,		SIP messages carry the SIP URIs of actual overlay endpoints (e.g.,
	"sip:alice@dht.example.com") in the Via and Contact headers, while		"sip:alice@dht.example.com") in the Via and Contact headers, while
	the communication continues via the RELOAD connection. However, a UA		the communication continues via the RELOAD connection. However, a UA
	can redirect its communication path by setting an alternate Contact		can redirect its communication path by setting an alternate Contact
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	traffic to keep NAT and Firewall states present and the connection		traffic to keep NAT and Firewall states present and the connection
	alive. Keepalives are a mandatory component of ICE (see Section 10		alive. Keepalives are a mandatory component of ICE (see Section 10
	of [RFC5245]) and no further operations are required. Applications		of [RFC5245]) and no further operations are required. Applications
	that want to assure maintenance of sessions individually need to		that want to assure maintenance of sessions individually need to
	follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-		follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-
	alive techniques in agreement with its transport binding as defined		alive techniques in agreement with its transport binding as defined
	in Section 3.5 of [RFC5626].		in Section 3.5 of [RFC5626].
	6. Using GRUUs		6. Using GRUUs
	Globally Routable User Agent Uris (GRUUs) [RFC5627] have been		Globally Routable User Agent URIs (GRUUs) [RFC5627] have been
	designed to allow direct routing without the indirection of a SIP		designed to allow direct routing without the indirection of a SIP
	proxy function. The concept is transferred to RELOAD overlays as		proxy function. The concept is transferred to RELOAD overlays as
	follows. GRUUs in RELOAD are constructed by embedding a		follows. GRUUs in RELOAD are constructed by embedding a
	base64-encoded destination list in the gr URI parameter of the GRUU.		base64-encoded destination list in the "gr" URI parameter of the
	The base64 encoding is done with the alphabet specified in table 1 of		GRUU. The base64 encoding is done with the alphabet specified in
	[RFC4648] with the exception that ~ is used in place of =.		table 1 of [RFC4648] with the exception that ~ is used in place of =.
	Example of a RELOAD GRUU:		Example of a RELOAD GRUU:
	alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~		alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~
	GRUUs do not require to store data in the Overlay Instance. Rather		GRUUs do not require to store data in the Overlay Instance. Rather
	when a peer needs to route a message to a GRUU in the same P2P		when a peer needs to route a message to a GRUU in the same P2P
	overlay, it simply uses the destination list and connects to that		overlay, it simply uses the destination list and connects to that
	peer. Because a GRUU contains a destination list, it can have the		peer. Because a GRUU contains a destination list, it can have the
	same contents as a destination list stored elsewhere in the resource		same contents as a destination list stored elsewhere in the resource
	dictionary.		dictionary.
	skipping to change at page 16, line 26 ¶		skipping to change at page 16, line 26 ¶
	10. Acknowledgments		10. Acknowledgments
	This document was generated in parts from initial drafts and		This document was generated in parts from initial drafts and
	discussions in the early specification phase of the P2PSIP base		discussions in the early specification phase of the P2PSIP base
	protocol. Significant contributions (in alphabetical order) were		protocol. Significant contributions (in alphabetical order) were
	from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan		from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan
	Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged.		Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged.
	Additional thanks go to all those who helped with ideas, discussions,		Additional thanks go to all those who helped with ideas, discussions,
	and reviews, in particular (in alphabetical order) Roland Bless,		and reviews, in particular (in alphabetical order) Roland Bless,
	Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, and		Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral
	Matthias Waehlisch.		Shirazipour, and Matthias Waehlisch.
	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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 18, line 13 ¶		skipping to change at page 18, line 13 ¶
	2016.		2016.
	[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-		[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-
	Driven Privacy Mechanism for SIP", RFC 5767,		Driven Privacy Mechanism for SIP", RFC 5767,
	DOI 10.17487/RFC5767, April 2010,		DOI 10.17487/RFC5767, April 2010,
	<http://www.rfc-editor.org/info/rfc5767>.		<http://www.rfc-editor.org/info/rfc5767>.
	[I-D.ietf-p2psip-share]		[I-D.ietf-p2psip-share]
	Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A		Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A
	Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf-		Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf-
	p2psip-share-07 (work in progress), November 2015.		p2psip-share-08 (work in progress), March 2016.
	Appendix A. Third Party Registration		Appendix A. Third Party Registration
	In traditional SIP, the mechanism of a third party registration		In traditional SIP, the mechanism of a third party registration
	(i.e., an assistant acting for a boss, changing users register a		(i.e., an assistant acting for a boss, changing users register a
	role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This		role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This
	is a REGISTER which uses the URI of the third-party in its From		is a REGISTER which uses the URI of the third-party in its From
	header and cannot be translated directly into a P2PSIP registration,		header and cannot be translated directly into a P2PSIP registration,
	because only the owner of the certificate can store a SIP-		because only the owner of the certificate can store a SIP-
	REGISTRATION in a RELOAD overlay.		REGISTRATION in a RELOAD overlay.
End of changes. 12 change blocks.
	20 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/