draft-ietf-bliss-problem-statement-00.txt		draft-ietf-bliss-problem-statement-01.txt
	BLISS J. Rosenberg		BLISS J. Rosenberg
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Informational July 26, 2007		Intended status: Informational November 19, 2007
	Expires: January 27, 2008		Expires: May 22, 2008
	Basic Level of Interoperability for Session Initiation Protocol (SIP)		Basic Level of Interoperability for Session Initiation Protocol (SIP)
	Services (BLISS) Problem Statement		Services (BLISS) Problem Statement
	draft-ietf-bliss-problem-statement-00		draft-ietf-bliss-problem-statement-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 January 27, 2008.		This Internet-Draft will expire on May 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Session Initiation Protocol (SIP) has been designed as a general		The Session Initiation Protocol (SIP) has been designed as a general
	purpose protocol for establishing and managing multimedia sessions.		purpose protocol for establishing and managing multimedia sessions.
	It provides many core functions and extensions in support of features		It provides many core functions and extensions in support of features
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 15		5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 15
	6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16		6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Informative References . . . . . . . . . . . . . . . . . . . . 17		9. Informative References . . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The Session Initiation Protocol (SIP) [1] has been designed as a		The Session Initiation Protocol (SIP) [RFC3261] has been designed as
	general purpose protocol for establishing and managing multimedia		a general purpose protocol for establishing and managing multimedia
	sessions. In this role, it provides many core functions and		sessions. In this role, it provides many core functions and
	extensions to support "session management features". In this		extensions to support "session management features". In this
	context, session management features (or just features in this		context, session management features (or just features in this
	specification) are operations, typically invoked by the user, that		specification) are operations, typically invoked by the user, that
	provide some form value-added functionality within the context of a		provide some form value-added functionality within the context of a
	multimedia session. Examples of features include putting a call on		multimedia session. Examples of features include putting a call on
	hold (possibly with music), transferring calls, creating ad-hoc		hold (possibly with music), transferring calls, creating ad-hoc
	conferences, having calls automatically forwarded, and so on.		conferences, having calls automatically forwarded, and so on.
	The SIP specification itself includes primitives to support some of		The SIP specification itself includes primitives to support some of
	these features. For example, RFC 3264 [2] defines SDP signaling		these features. For example, RFC 3264 [RFC3264] defines SDP
	parameters for placing a call on hold. Numerous SIP extensions have		signaling parameters for placing a call on hold. Numerous SIP
	been developed which focus on functionality needed for session		extensions have been developed which focus on functionality needed
	management features. The REFER specification, RFC 3515 [3], defines		for session management features. The REFER specification, RFC 3515
	a primitive operation for a user agent to ask another user agent to		[RFC3515], defines a primitive operation for a user agent to ask
	send a SIP request, typically to initiate a session. REFER is used		another user agent to send a SIP request, typically to initiate a
	to support many features, such as transfer, park, and refer. The		session. REFER is used to support many features, such as transfer,
	Replaces specification, RFC 3891 [4], allows one dialog to replace		park, and refer. The Replaces specification, RFC 3891 [RFC3891],
	another. This header field is useful for consultation transfer		allows one dialog to replace another. This header field is useful
	features. The dialog event package, RFC 4235 [5], allows one UA to		for consultation transfer features. The dialog event package, RFC
	learn about the dialog states on another UA. This package is useful		4235 [RFC4235], allows one UA to learn about the dialog states on
	for features such as shared line.		another UA. This package is useful for features such as shared line.
	However, despite this veritable plethora of specifications that can		However, despite this veritable plethora of specifications that can
	support session management features, in practice, interoperability		support session management features, in practice, interoperability
	has been quite poor for these kinds of functions. One user agents		has been quite poor for these kinds of functions. One user agents
	from one vendor are connected to servers and user agents from other		from one vendor are connected to servers and user agents from other
	vendors, very few of these types of features actually work. In most		vendors, very few of these types of features actually work. In most
	cases, call hold and basic transfer are broadly interoperable, but		cases, call hold and basic transfer are broadly interoperable, but
	more advanced features such as park and resume, music-on-hold, and		more advanced features such as park and resume, music-on-hold, and
	shared line appearances, do not work.		shared line appearances, do not work.
	skipping to change at page 8, line 42		skipping to change at page 8, line 42
	this INVITE to UA Y. The user does not answer. So, after a timeout,		this INVITE to UA Y. The user does not answer. So, after a timeout,
	the UA acts like a proxy and sends the INVITE back to P, this time		the UA acts like a proxy and sends the INVITE back to P, this time
	with a Request-URI identifying Z. The proxy forwards this to Z, and		with a Request-URI identifying Z. The proxy forwards this to Z, and
	the call completes.		the call completes.
	3.1.4. Approach IV: Call Processing Language		3.1.4. Approach IV: Call Processing Language
	In this approach, the proxy implements the call forwarding logic.		In this approach, the proxy implements the call forwarding logic.
	However, instead of the logic being configured through a web page, it		However, instead of the logic being configured through a web page, it
	has been uploaded to the proxy server through a Call Processing		has been uploaded to the proxy server through a Call Processing
	Language (CPL) [6] script that the UA included in its registration		Language (CPL) [RFC3880] script that the UA included in its
	request.		registration request.
	The basic call flow for this approach is shown in Figure 5.		The basic call flow for this approach is shown in Figure 5.
	UA X Proxy UA Y UA Z		UA X Proxy UA Y UA Z
	| |(1) REGISTER | |		| |(1) REGISTER | |
	| |with CPL | |		| |with CPL | |
	| |<-------------| |		| |<-------------| |
	| |(2) 200 OK | |		| |(2) 200 OK | |
	| |------------->| |		| |------------->| |
	|(3) INVITE Y | | |		|(3) INVITE Y | | |
	skipping to change at page 15, line 38		skipping to change at page 15, line 38
	Indeed, if a particular functional primitive requires any		Indeed, if a particular functional primitive requires any
	functionality to be present in any node that goes beyond the "common"		functionality to be present in any node that goes beyond the "common"
	functions in RFC 3261, the recommendations need to state that. For		functions in RFC 3261, the recommendations need to state that. For
	example, if a particular feature can be implemented using S/MIME, and		example, if a particular feature can be implemented using S/MIME, and
	the group decides that S/MIME is the required everywhere for this		the group decides that S/MIME is the required everywhere for this
	feature to work, that recommendation should be clearly stated.		feature to work, that recommendation should be clearly stated.
	In some cases, only a part of a specification is required in order		In some cases, only a part of a specification is required in order
	for the features in a feature group to be interoperable. In that		for the features in a feature group to be interoperable. In that
	case, the group should identify which parts it is. In the example of		case, the group should identify which parts it is. In the example of
	CPL, RFC 3880 [6], the ability to support non-signalling controls is		CPL, RFC 3880 [RFC3880], the ability to support non-signalling
	not neccesary to achieve an implementation of this feature group.		controls is not neccesary to achieve an implementation of this
	So, the recommendation could be that this part is not required.		feature group. So, the recommendation could be that this part is not
			required.
	Another key part of the recommendations that get made in this phase,		Another key part of the recommendations that get made in this phase,
	are recommendations around capability discovery. If a decision is		are recommendations around capability discovery. If a decision is
	made that says there are multiple different ways that a feature can		made that says there are multiple different ways that a feature can
	work, and it is necessary to know which one is in use, some kind of		work, and it is necessary to know which one is in use, some kind of
	capability exchange is required. Consider once more CFNA. If the		capability exchange is required. Consider once more CFNA. If the
	recommendation of the group is that all proxies have to implement the		recommendation of the group is that all proxies have to implement the
	logic associated with the feature, but phones can also optionally do		logic associated with the feature, but phones can also optionally do
	it, the UA needs to determine whether it has to be responsible for		it, the UA needs to determine whether it has to be responsible for
	this feature or not. Otherwise, the failure mode in Section 3.1.5.2		this feature or not. Otherwise, the failure mode in Section 3.1.5.2
	skipping to change at page 17, line 19		skipping to change at page 17, line 20
	Interoperability of security functions is also a critical part of the		Interoperability of security functions is also a critical part of the
	overall interoperability problem, and must be considered as well.		overall interoperability problem, and must be considered as well.
	8. IANA Considerations		8. IANA Considerations
	There are no IANA considerations associated with this specification.		There are no IANA considerations associated with this specification.
	9. Informative References		9. Informative References
	[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		A., Peterson, J., Sparks, R., Handley, M., and E.
	Session Initiation Protocol", RFC 3261, June 2002.		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	Session Description Protocol (SDP)", RFC 3264, June 2002.		with Session Description Protocol (SDP)", RFC 3264,
			June 2002.
	[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer		[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
	Method", RFC 3515, April 2003.		Method", RFC 3515, April 2003.
	[4] 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, September 2004.		Protocol (SIP) "Replaces" Header", RFC 3891,
			September 2004.
	[5] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-		[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
	Initiated Dialog Event Package for the Session Initiation		Initiated Dialog Event Package for the Session Initiation
	Protocol (SIP)", RFC 4235, November 2005.		Protocol (SIP)", RFC 4235, November 2005.
	[6] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing		[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
	Language (CPL): A Language for User Control of Internet		Language (CPL): A Language for User Control of Internet
	Telephony Services", RFC 3880, October 2004.		Telephony Services", RFC 3880, October 2004.
	Author's Address		Author's Address
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco		Cisco
	Edison, NJ		Edison, NJ
	US		US
End of changes. 13 change blocks.
	33 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/