< draft-ietf-cuss-sip-uui-isdn-06.txt		draft-ietf-cuss-sip-uui-isdn-07.txt >
	Network Working Group K. Drage, Ed.		CUSS K. Drage, Ed.
	Internet-Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Standards Track A. Johnston		Intended status: Standards Track A. Johnston
	Expires: June 19, 2014 Avaya		Expires: August 18, 2014 Avaya
	December 16, 2013		February 14, 2014
	Interworking ISDN Call Control User Information with SIP		Interworking ISDN Call Control User Information with SIP
	draft-ietf-cuss-sip-uui-isdn-06		draft-ietf-cuss-sip-uui-isdn-07
	Abstract		Abstract
	The motivation and use cases for interworking and transporting ITU-T		The motivation and use cases for interworking and transporting ITU-T
	DSS1 User-user information element data in SIP are described in the		DSS1 User-user information element data in SIP are described in the
	"Problem Statement and Requirements for Transporting User to User		"Problem Statement and Requirements for Transporting User to User
	Call Control Information in SIP" document. As networks move to SIP		Call Control Information in SIP" document. As networks move to SIP
	it is important that applications requiring this data can continue to		it is important that applications requiring this data can continue to
	function in SIP networks as well as the ability to interwork with		function in SIP networks as well as the ability to interwork with
	this ISDN service for end-to-end transparency. This document defines		this ISDN service for end-to-end transparency. This document defines
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 June 19, 2014.		This Internet-Draft will expire on August 18, 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
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6		4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
	5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6		5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6
	6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7		6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7
	7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 8		7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 8
	8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9		8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9
	9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10. Considerations for ISDN interworking gateways . . . . . . . . 11		10. Considerations for ISDN interworking gateways . . . . . . . . 11
	11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12		11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12
	12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12		12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 13		14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	16. Changes since previous versions . . . . . . . . . . . . . . . 14		16. Changes since previous versions . . . . . . . . . . . . . . . 14
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 18		17.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	17.2. Informative References . . . . . . . . . . . . . . . . . . 18		17.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Terminology		1. 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 BCP 14, RFC 2119		document are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119].		[RFC2119].
	2. Overview		2. Overview
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 9 ¶
	The UAS MAY include the User-to-User header field in responses to the		The UAS MAY include the User-to-User header field in responses to the
	initial INVITE request, or the BYE requests or responses for the		initial INVITE request, or the BYE requests or responses for the
	dialog, only where the original INVITE request included a User-to-		dialog, only where the original INVITE request included a User-to-
	User header field with the "purpose" header field parameter set to		User header field with the "purpose" header field parameter set to
	"isdn-uui", or where no "purpose" header field parameter was		"isdn-uui", or where no "purpose" header field parameter was
	included. When sending UUI for the ISDN package, the UAS SHOULD set		included. When sending UUI for the ISDN package, the UAS SHOULD set
	the User-to-User "purpose" header field parameter to "isdn-uui".		the User-to-User "purpose" header field parameter to "isdn-uui".
	Non-inclusion of the "purpose" header field parameter is permitted,		Non-inclusion of the "purpose" header field parameter is permitted,
	but this is primarily to allow earlier implementations to support		but this is primarily to allow earlier implementations to support
	this package. The UAS MUST NOT include more than one User-to-User		this package.
	header field for this package in any SIP request or response.
			When sending UUI for the ISDN package, if the "purpose" header field
			is included, the UAS MUST set the User-to-User "purpose" header field
			parameter to "isdn-uui". The UAS MUST NOT include more than one
			User-to-User header field for this package in any SIP request or
			response.
	The "isdn-interwork" value for purpose parameter was used in		The "isdn-interwork" value for purpose parameter was used in
	Internet-Drafts that have led to the publication of the present		Internet-Drafts that have led to the publication of the present
	document. Although these documents had no other status than "work in		document. Although these documents had no other status than "work in
	progress", this value is implemented by some vendors. While not		progress", this value is implemented by some vendors. While not
	defined by this document, implementations could find it useful for		defined by this document, implementations could find it useful for
	interoperability purposes to support parsing and interpreting "isdn-		interoperability purposes to support parsing and interpreting "isdn-
	interwork" the same way as "isdn-uui" when receiving messages.		interwork" the same way as "isdn-uui" when receiving messages.
	Where the UAS is acting as a redirect server, the UAS MUST NOT		Where the UAS is acting as a redirect server, the UAS MUST NOT
	include the User-to-User header field in the header URI parameter in		include the User-to-User header field in the header URI parameter in
	a 3xx response to an incoming request.		a 3xx response to an incoming request.
	When receiving UUI, when a User-to-User header field is received in a		When receiving UUI, when a User-to-User header field is received in a
	request that is not from the originating user with the "purpose"		request that is not from the originating user with the "purpose"
	header field parameter to "isdn-uui", or with no "purpose" header		header field parameter to "isdn-uui", or with no "purpose" header
	field parameter, the UAC MUST discard this header field.		field parameter, the UAS MUST discard this header field.
	When receiving UUI, when multiple User-to-User header fields are		When receiving UUI, when multiple User-to-User header fields are
	received from the originating user in the same request with the		received from the originating user in the same request with the
	"purpose" header field parameter to "isdn-uui", or with no "purpose"		"purpose" header field parameter to "isdn-uui", or with no "purpose"
	header field parameter, or with some combination of these, the UAC		header field parameter, or with some combination of these, the UAS
	MUST discard all these header fields. There are no mechanisms for		MUST discard all these header fields. There are no mechanisms for
	determining which was the intended data packet so all are discarded.		determining which was the intended data packet so all are discarded.
	9. UUI contents		9. UUI contents
	These requirements apply when the "purpose" header field parameter is		These requirements apply when the "purpose" header field parameter is
	set to "isdn-uui", or with no "purpose" header field parameter.		set to "isdn-uui", or with no "purpose" header field parameter.
	Processing for User-to-User header fields sent or received with		Processing for User-to-User header fields sent or received with
	values other than this value are outside the scope of this document,		values other than this value are outside the scope of this document,
	and the appropriate package document for that value applies.		and the appropriate package document for that value applies.
	skipping to change at page 14, line 47 ¶		skipping to change at page 15, line 7 ¶
	thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen		thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
	Jennings, Mahalingam Mani and Celine Serrut-Valette for their		Jennings, Mahalingam Mani and Celine Serrut-Valette for their
	comments.		comments.
	16. Changes since previous versions		16. Changes since previous versions
	Note to RFC editor: This section is to be deleted before final		Note to RFC editor: This section is to be deleted before final
	publication.		publication.
	Changes since made in the creation of the		Changes since made in the creation of the
			draft-ietf-cuss-sip-uui-isdn-07 version from the
			draft-ietf-cuss-sip-uui-isdn-06 version.
			In the UAS requirements section, a new requirement has been added
			to set the purpose parameter to "uui-isdn" if it is included.
			This matches an equivalent requirement for the UAC.
			In the UAS requirements section, two instances of UAC have been
			corrected to UAS.
			Changes since made in the creation of the
	draft-ietf-cuss-sip-uui-isdn-06 version from the		draft-ietf-cuss-sip-uui-isdn-06 version from the
	draft-ietf-cuss-sip-uui-isdn-05 version.		draft-ietf-cuss-sip-uui-isdn-05 version.
	A new paragraph of informative material has been added in section		A new paragraph of informative material has been added in section
	8 relating to older implementations generating "ISDNinterwork" as		8 relating to older implementations generating "ISDNinterwork" as
	a purpose value.		a purpose value.
	A number of editorial changes have been made.		A number of editorial changes have been made.
	Changes since made in the creation of the		Changes since made in the creation of the
	skipping to change at page 18, line 39 ¶		skipping to change at page 19, line 10 ¶
	for Telephones (SIP-T): Context and Architectures",		for Telephones (SIP-T): Context and Architectures",
	BCP 63, RFC 3372, September 2002.		BCP 63, RFC 3372, September 2002.
	[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.
	[I-D.ietf-cuss-sip-uui]		[I-D.ietf-cuss-sip-uui]
	Johnston, A. and J. Rafferty, "A Mechanism for		Johnston, A. and J. Rafferty, "A Mechanism for
	Transporting User to User Call Control Information in		Transporting User to User Call Control Information in
	SIP", draft-ietf-cuss-sip-uui-11 (work in progress),		SIP", draft-ietf-cuss-sip-uui-12 (work in progress),
	October 2013.		January 2014.
	[Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling		[Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling
	System No. 1 - Network layer; ISDN user-network interface		System No. 1 - Network layer; ISDN user-network interface
	layer 3 specification for basic call control",		layer 3 specification for basic call control",
	http://www.itu.int/rec/T-REC-Q.931-199805-I/en .		http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
	17.2. Informative References		17.2. Informative References
	[RFC6567] Johnston, A. and L. Liess, "Problem Statement and		[RFC6567] Johnston, A. and L. Liess, "Problem Statement and
	Requirements for Transporting User-to-User Call Control		Requirements for Transporting User-to-User Call Control
End of changes. 12 change blocks.
	14 lines changed or deleted		30 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/