< draft-ietf-cuss-sip-uui-11.txt		draft-ietf-cuss-sip-uui-12.txt >
	Network Working Group A. Johnston		Network Working Group A. Johnston
	Internet-Draft Avaya		Internet-Draft Avaya
	Intended status: Standards Track J. Rafferty		Intended status: Standards Track J. Rafferty
	Expires: April 24, 2014 Human Communications		Expires: July 29, 2014 Human Communications
	October 21, 2013		January 25, 2014
	A Mechanism for Transporting User to User Call Control Information in		A Mechanism for Transporting User to User Call Control Information in
	SIP		SIP
	draft-ietf-cuss-sip-uui-11		draft-ietf-cuss-sip-uui-12
	Abstract		Abstract
	There is a class of applications which benefit from using SIP to		There is a class of applications which benefit from using SIP to
	exchange User to User Information (UUI) data during session		exchange User to User Information (UUI) data during session
	establishment. This information, known as call control UUI data, is		establishment. This information, known as call control UUI data, is
	a small piece of data inserted by an application initiating the		a small piece of data inserted by an application initiating the
	session, and utilized by an application accepting the session. The		session, and utilized by an application accepting the session. The
	rules which apply for a specific application are defined by a UUI		rules which apply for a specific application are defined by a UUI
	package. This UUI data is opaque to SIP and its function is		package. This UUI data is opaque to SIP and its function is
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 April 24, 2014.		This Internet-Draft will expire on July 29, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3		3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3
	4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5		4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 6		4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5
	4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7		4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7
	4.3. Source Identity of UUI data . . . . . . . . . . . . . . . 7		4.3. Source Identity of UUI data . . . . . . . . . . . . . . . 7
	5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 8		5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9
	5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6.1. Registration of User-to-User Header Field . . . . . . . . 11		6.1. Registration of User-to-User Header Field . . . . . . . . 11
	6.2. Registration of User-to-User Header Field Parameters . . . 11		6.2. Registration of User-to-User Header Field Parameters . . . 11
	6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 11		6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 11
	6.4. Registration of UUI Content Parameters . . . . . . . . . . 12		6.4. Registration of UUI Content Parameters . . . . . . . . . . 12
	6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12		6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12
	6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 12		6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 14		8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 14
	8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 14		8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 14
	8.2. Why Other Protocol Encapsulation UUI Mechanisms are		8.2. Why Other Protocol Encapsulation UUI Mechanisms are
	Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 14		Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 15		8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 15
	8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 16		8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Informative References . . . . . . . . . . . . . . . . . . 16		10.1. Informative References . . . . . . . . . . . . . . . . . . 17
	10.2. Normative References . . . . . . . . . . . . . . . . . . . 17		10.2. Normative References . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Overview		1. Overview
	This document describes the transport of User to User Information		This document describes the transport of User to User Information
	(UUI) data using SIP [RFC3261]. A mechanism is defined for the		(UUI) data using SIP [RFC3261]. A mechanism is defined for the
	transport of general application UUI data and for the transport of		transport of general application UUI data and for the transport of
	call control related ITU-T Q.931 User to User Information Element (UU		call control related ITU-T Q.931 User to User Information Element (UU
	IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763]		IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763]
	data in SIP. UUI data is widely used in the PSTN today for contact		data in SIP. UUI data is widely used in the PSTN today for contact
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14, RFC 2119 [RFC2119].		14, RFC 2119 [RFC2119].
	3. Requirements Discussion		3. Requirements Discussion
	This section describes how the User-to-User header field meets the		This section describes how the User-to-User header field meets the
	requirements in [RFC6567]. The header field can be included in		requirements in [RFC6567]. The header field can be included in
	INVITE requests and responses and BYE requests and responses, meeting		INVITE requests and responses and BYE requests and responses, meeting
	REQ-1 and REQ-2.		REQ-1 and REQ-2.
	For redirection and referral use cases and REQ-3, the header field		For redirection and referral use cases and REQ-3, the header field is
	shall be included (escaped) into the Contact or Refer-To URI.		included (escaped) within the Contact or Refer-To URI. The details
	Currently, UAs that support attended transfer support the ability to		of this mechanism as it applies for redirection and referral use
	include a Replaces header field [RFC3891] into a Refer-To URI, and		cases are covered in Section 4.1.
	when acting upon this URI add the Replaces header field to the
	triggered INVITE. This logic and behavior is identical for the UUI
	header field. The UA processing the REFER or the 3xx to the INVITE
	will need to support the UUI mechanism, as UAs in general do not
	process unknown included header fields.
	Since SIP proxy forwarding and retargeting does not affect header		Since SIP proxy forwarding and retargeting does not affect header
	fields, the header field meets REQ-4.		fields, the header field meets REQ-4.
	The UUI header field will carry the UUI data and not a pointer to the		The UUI header field will carry the UUI data and not a pointer to the
	data, so REQ-5 is met.		data, so REQ-5 is met.
	Since the basic design of the UUI header field is similar to the ISDN		Since the basic design of the UUI header field is similar to the ISDN
	UUI service, interworking with PSTN protocols is straightforward and		UUI service, interworking with PSTN protocols is straightforward and
	is documented in a separate specification		is documented in a separate specification
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 33 ¶
	response. Consistent with the rules of SIP syntax, the syntax		response. Consistent with the rules of SIP syntax, the syntax
	defined in this document allows any combination of individual User-		defined in this document allows any combination of individual User-
	to-User header fields or User-to-User header fields with multiple		to-User header fields or User-to-User header fields with multiple
	comma separated UUI data elements. Any size limitations on the UUI		comma separated UUI data elements. Any size limitations on the UUI
	data for a particular purpose must be defined by the related UUI		data for a particular purpose must be defined by the related UUI
	package.		package.
	UAs SHOULD ignore UUI data from packages or encoding that they do not		UAs SHOULD ignore UUI data from packages or encoding that they do not
	understand.		understand.
	If an element supports this specification, it SHOULD include any UUI		For redirection and referral use cases, the header field is included
	data included in a redirection URI (if the UUI data and encoding is		(escaped) within the Contact or Refer-To URI. For example, if a UA
	understood). Note that redirection can occur multiple times to a		supports this specification, it SHOULD include any UUI data included
	request.		in a redirection URI (if the UUI data and encoding is understood).
			Note that redirection can occur multiple times to a request.
			Currently, UAs that support attended transfer support the ability to
			include a Replaces header field [RFC3891] into a Refer-To URI, and
			when acting upon this URI, add the Replaces header field to the
			triggered INVITE. This sort of logic and behavior shall also be
			utilized for the UUI header field (that is, the UUI header field is
			included in the triggered INVITE). The UA processing the REFER or
			the 3xx to the INVITE SHOULD support the UUI mechanism. If the REFER
			or redirect target does not support UUI, the UUI header will be
			discarded as per [RFC3261]. However, this may limit the utility of
			use cases which depend upon the UUI being supported by all elements.
	Here is an example of an included User-to-User header field from the		Here is an example of an included User-to-User header field from the
	redirection response F2 of Figure 2:		redirection response F2 of Figure 2:
	<allOneLine>		<allOneLine>
	Contact: <sip:+12125551212@gateway.example.com?User-to-User=		Contact: <sip:+12125551212@gateway.example.com?User-to-User=
	56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B		56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B
	content%3Dbar>		content%3Dbar>
	</allOneLine>		</allOneLine>
	skipping to change at page 13, line 31 ¶		skipping to change at page 13, line 36 ¶
	7. Security Considerations		7. Security Considerations
	User to user information can potentially carry sensitive information		User to user information can potentially carry sensitive information
	that might require privacy or integrity protection from third parties		that might require privacy or integrity protection from third parties
	that may wish to read or modify the UUI data. [RFC6567] describes		that may wish to read or modify the UUI data. [RFC6567] describes
	three security models which may be applicable for the UUI mechanism.		three security models which may be applicable for the UUI mechanism.
	One model treats the SIP layer as untrusted and requires end-to-end		One model treats the SIP layer as untrusted and requires end-to-end
	integrity protection and/or encryption. This model can be achieved		integrity protection and/or encryption. This model can be achieved
	by providing these security services at a layer above SIP. In this		by providing these security services at a layer above SIP. In this
	case, applications are encouraged to use their own integrity		case, applications are encouraged to use their own integrity and/or
	mechanisms such as encrypting the UUI data before passing it to the		encryption mechanisms before passing it to the SIP layer.
	SIP layer.
	The second approach is for the application to pass the UUI without		The second approach is for the application to pass the UUI without
	any protection to the SIP layer and require the SIP layer to provide		any protection to the SIP layer and require the SIP layer to provide
	this security. This approach is possible in theory, although its		this security. This approach is possible in theory, although its
	practical use would be extremely limited. To preserve multi-hop or		practical use would be extremely limited. To preserve multi-hop or
	end-to-end confidentiality and integrity of UUI data, approaches		end-to-end confidentiality and integrity of UUI data, approaches
	using S/MIME or IPSec can be used, as discussed in the review of		using S/MIME or IPSec can be used, as discussed in the review of
	REQ-13 and REQ-14 in section 3 of this document. However, the lack		REQ-13 and REQ-14 in section 3 of this document. However, the lack
	of deployment of these mechanisms means that applications cannot in		of deployment of these mechanisms means that applications cannot in
	general rely on them being present.		general rely on them being present.
	skipping to change at page 14, line 47 ¶		skipping to change at page 15, line 5 ¶
	to transport UUI data. Should one of these protocols be in use, and		to transport UUI data. Should one of these protocols be in use, and
	present in both User Agents, then utilizing these other protocols to		present in both User Agents, then utilizing these other protocols to
	transport UUI data might be a logical solution. Essentially, this is		transport UUI data might be a logical solution. Essentially, this is
	just adding an additional layer in the protocol stack. In these		just adding an additional layer in the protocol stack. In these
	cases, SIP is not transporting the UUI data; it is encapsulating		cases, SIP is not transporting the UUI data; it is encapsulating
	another protocol, and that protocol is transporting the UUI data.		another protocol, and that protocol is transporting the UUI data.
	Once a mechanism to transport that other protocol using SIP exists,		Once a mechanism to transport that other protocol using SIP exists,
	the UUI data transport function is essentially obtained without any		the UUI data transport function is essentially obtained without any
	additional effort or work.		additional effort or work.
	However, the authors believe that SIP needs to have its own native		However, the CUSS working group believes, consistent with its
	UUI data transport mechanism. It is not reasonable for a SIP UA to		charter, that SIP needs to have its own native UUI data transport
	have to implement another entire protocol (either ISDN or NSS, for		mechanism. It is not reasonable for a SIP UA to have to implement
	example) just to get the very simple UUI data transport service. Of		another entire protocol (either ISDN or NSS, for example) just to get
	course, this work does not preclude anyone from using other protocols		the very simple UUI data transport service. Of course, this work
	with SIP to transport UUI data.		does not preclude anyone from using other protocols with SIP to
			transport UUI data.
	8.3. MIME body Approach		8.3. MIME body Approach
	One method of transport is to use a MIME body. This is in keeping		One method of transport is to use a MIME body. This is in keeping
	with the SIP-T architecture [RFC3372] in which MIME bodies are used		with the SIP-T architecture [RFC3372] in which MIME bodies are used
	to transport ISUP information. Since the INVITE will normally have		to transport ISUP information. Since the INVITE will normally have
	an SDP message body, the resulting INVITE with SDP and UUI data will		an SDP message body, the resulting INVITE with SDP and UUI data will
	be multipart MIME. This is not ideal as many SIP UAs do not support		be multipart MIME. This is not ideal as many SIP UAs do not support
	multipart MIME INVITEs.		multipart MIME INVITEs.
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 44 ¶
	REQ-14.		REQ-14.
	9. Acknowledgements		9. Acknowledgements
	Joanne McMillen was a major contributor and co-author of earlier		Joanne McMillen was a major contributor and co-author of earlier
	versions of this document. Thanks to Paul Kyzivat for his		versions of this document. Thanks to Paul Kyzivat for his
	contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith		contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith
	Drage, Vijay Gurbani, and Laura Liess for their review of the		Drage, Vijay Gurbani, and Laura Liess for their review of the
	document. The authors wish to thank Roland Jesske, Celine Serrut-		document. The authors wish to thank Roland Jesske, Celine Serrut-
	Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen		Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
	Jennings, and Mahalingam Mani for their comments.		Jennings, and Mahalingam Mani for their comments. Thanks to Scott
			Kelly and Joel Halperin for their reviews.
	10. References		10. References
	10.1. Informative References		10.1. Informative References
	[Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part		[Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
	formats and codes",		formats and codes",
	http://www.itu.int/rec/T-REC-Q.931-199805-I/en .		http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
	[Q931] "ITU-T Q.931 User to User Information Element (UU IE)",		[Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
	http://www.itu.int/rec/T-REC-Q.931-199805-I/en .		http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
	[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol		[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
	skipping to change at page 17, line 28 ¶		skipping to change at page 17, line 33 ¶
	Torture Test Messages", RFC 4475, May 2006.		Torture Test Messages", RFC 4475, May 2006.
	[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process		[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
	for the Session Initiation Protocol (SIP) and the Real-		for the Session Initiation Protocol (SIP) and the Real-
	time Applications and Infrastructure Area", BCP 67,		time Applications and Infrastructure Area", BCP 67,
	RFC 5727, March 2010.		RFC 5727, March 2010.
	[I-D.ietf-cuss-sip-uui-isdn]		[I-D.ietf-cuss-sip-uui-isdn]
	Drage, K. and A. Johnston, "Interworking ISDN Call Control		Drage, K. and A. Johnston, "Interworking ISDN Call Control
	User Information with SIP",		User Information with SIP",
	draft-ietf-cuss-sip-uui-isdn-05 (work in progress),		draft-ietf-cuss-sip-uui-isdn-06 (work in progress),
	August 2013.		December 2013.
	[Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -		[Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
	Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/		Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
	sg11aap/history/q1980.1/q1980.1.html .		sg11aap/history/q1980.1/q1980.1.html .
	[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private		[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
	Extensions to the Session Initiation Protocol (SIP) for		Extensions to the Session Initiation Protocol (SIP) for
	Asserted Identity within Trusted Networks", RFC 3325,		Asserted Identity within Trusted Networks", RFC 3325,
	November 2002.		November 2002.
	skipping to change at page 18, line 13 ¶		skipping to change at page 18, line 23 ¶
	June 2002.		June 2002.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.		Initiation Protocol (SIP)", RFC 4474, August 2006.
	[I-D.ietf-sipcore-rfc4244bis]		[I-D.ietf-sipcore-rfc4244bis]
	Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.		Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.
	Holmberg, "An Extension to the Session Initiation Protocol		Holmberg, "An Extension to the Session Initiation Protocol
	(SIP) for Request History Information",		(SIP) for Request History Information",
	draft-ietf-sipcore-rfc4244bis-11 (work in progress),		draft-ietf-sipcore-rfc4244bis-12 (work in progress),
	January 2013.		October 2013.
	[RFC4916] Elwell, J., "Connected Identity in the Session Initiation		[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
	Protocol (SIP)", RFC 4916, June 2007.		Protocol (SIP)", RFC 4916, June 2007.
	[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,		[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
	"Indicating User Agent Capabilities in the Session		"Indicating User Agent Capabilities in the Session
	Initiation Protocol (SIP)", RFC 3840, August 2004.		Initiation Protocol (SIP)", RFC 3840, August 2004.
	[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation		[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
	Protocol (SIP) "Replaces" Header", RFC 3891,		Protocol (SIP) "Replaces" Header", RFC 3891,
End of changes. 16 change blocks.
	39 lines changed or deleted		45 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/