< draft-rosenberg-sipping-service-identification-02.txt		draft-rosenberg-sipping-service-identification-03.txt >
	SIPPING J. Rosenberg		SIPPING J. Rosenberg
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Best Current May 7, 2007		Intended status: Best Current July 9, 2007
	Practice		Practice
	Expires: November 8, 2007		Expires: January 10, 2008
	Identification of Communications Services in the Session Initiation		Identification of Communications Services in the Session Initiation
	Protocol (SIP)		Protocol (SIP)
	draft-rosenberg-sipping-service-identification-02		draft-rosenberg-sipping-service-identification-03
	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 36 ¶		skipping to change at page 1, line 36 ¶
	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 November 8, 2007.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document considers the problem of service identification in the		This document considers the problem of service identification in the
	Session Initiation Protocol (SIP). Service identification is the		Session Initiation Protocol (SIP). Service identification is the
	process of determining the user-level use case that is driving the		process of determining the user-level use case that is driving the
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Services and Service Identification . . . . . . . . . . . . . 4		3. Services and Service Identification . . . . . . . . . . . . . 4
	4. Example Services . . . . . . . . . . . . . . . . . . . . . . . 6		4. Example Services . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 6		4.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 6
	4.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 7		4.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 7
	4.3. Configuration vs. Pager Messaging . . . . . . . . . . . . 7		4.3. Configuration vs. Pager Messaging . . . . . . . . . . . . 7
	5. Using Service Identification . . . . . . . . . . . . . . . . . 7		5. Using Service Identification . . . . . . . . . . . . . . . . . 7
	5.1. Application Invocation in the User Agent . . . . . . . . . 8		5.1. Application Invocation in the User Agent . . . . . . . . . 8
	5.2. Application Invocation in the Network . . . . . . . . . . 8		5.2. Application Invocation in the Network . . . . . . . . . . 9
	5.3. Network Quality of Service Authorization . . . . . . . . . 9		5.3. Network Quality of Service Authorization . . . . . . . . . 9
	5.4. Service Authorization . . . . . . . . . . . . . . . . . . 10		5.4. Service Authorization . . . . . . . . . . . . . . . . . . 10
	5.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 10		5.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 10
	5.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 10		5.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 10
	5.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 11		5.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 11
	6. Key Principles of Service Identification . . . . . . . . . . . 11		6. Key Principles of Service Identification . . . . . . . . . . . 11
	6.1. Services are a By-Product of Signaling . . . . . . . . . . 11		6.1. Services are a By-Product of Signaling . . . . . . . . . . 11
	6.2. Perils of Explicit Identifiers . . . . . . . . . . . . . . 13		6.2. Perils of Explicit Identifiers . . . . . . . . . . . . . . 13
	6.2.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . 13		6.2.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.2.2. Systematic Interoperability Failures . . . . . . . . . 14		6.2.2. Systematic Interoperability Failures . . . . . . . . . 14
	6.2.3. Stifling of Service Innovation . . . . . . . . . . . . 15		6.2.3. Stifling of Service Innovation . . . . . . . . . . . . 16
	7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17		7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	11.2. Informational References . . . . . . . . . . . . . . . . . 18		11.2. Informational References . . . . . . . . . . . . . . . . . 18
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Session Initiation Protocol (SIP) [2] defines mechanisms for		The Session Initiation Protocol (SIP) [2] defines mechanisms for
	initiating and managing communications sessions between agents. SIP		initiating and managing communications sessions between agents. SIP
	allows for a broad array of session types between agents. It can		allows for a broad array of session types between agents. It can
	manage audio sessions, ranging from low bitrate voice-only up to		manage audio sessions, ranging from low bitrate voice-only up to
	multi-channel hi fidelity music. It can manage video sessions,		multi-channel hi fidelity music. It can manage video sessions,
	ranging from small, "talking-head" style video chat, up to high		ranging from small, "talking-head" style video chat, up to high
	definition multipoint video conferencing, to low bandwidth user-		definition multipoint video conferencing, to low bandwidth user-
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 35 ¶
	services available, for example, SIP or tel [15], in which case the		services available, for example, SIP or tel [15], in which case the
	scheme is less meaningful as a way of creating a summary. The reach		scheme is less meaningful as a way of creating a summary. The reach
	information could also indicate that certain application software has		information could also indicate that certain application software has
	to be invoked (such as a videogame), in which case that aspect of the		to be invoked (such as a videogame), in which case that aspect of the
	reach information would be useful for generating an iconic		reach information would be useful for generating an iconic
	representation of the game.		representation of the game.
	Essentially, the service is the user-visible use case that is driving		Essentially, the service is the user-visible use case that is driving
	the behavior of the user-agents and servers in the SIP network.		the behavior of the user-agents and servers in the SIP network.
	Being user-visible means that there is a difference in user		Being user-visible means that there is a difference in user
	experience between two services that are different. This user		experience between two services that are different. That user
	experience can be based on different media types (an audio call vs. a		experience can be part of the call, or outside of the call. Within a
	video chat), different content within a particular media type (stored		call, the user experience can be based on different media types (an
	content, such as a movie or TV session), different devices (a		audio call vs. a video chat), different content within a particular
	wireless device for "telephony" vs. a PC application for "voice-		media type (stored content, such as a movie or TV session), different
	chat"), different user interfaces (a buddy list view of voice on a PC		devices (a wireless device for "telephony" vs. a PC application for
	application vs. a software emulation of a hard phone), different		"voice-chat"), different user interfaces (a buddy list view of voice
	communities that can be accessed (voice chat with other users that		on a PC application vs. a software emulation of a hard phone),
	have the same voice chat client, vs. voice communications with any		different communities that can be accessed (voice chat with other
	endpoint on the PSTN), or different applications that are invoked by		users that have the same voice chat client, vs. voice communications
	the user (manually selecting a push-to-talk application from a		with any endpoint on the PSTN), or different applications that are
	wireless phone vs. a telephony application).		invoked by the user (manually selecting a push-to-talk application
			from a wireless phone vs. a telephony application). Outside of a
			call, the difference in user experience can be a billing one (cheaper
			for one service than other), a notification feature for one and not
			another (for example, an IM that gets sent whenever a user makes a
			call), and so on.
	In some cases, there is very little difference in the underlying		In some cases, there is very little difference in the underlying
	technology that will support two different services, and in other		technology that will support two different services, and in other
	cases, there are big differences. However, for purposes of this		cases, there are big differences. However, for purposes of this
	discussion, the key definition is that two services are distinct when		discussion, the key definition is that two services are distinct when
	there is a perceived difference by the user in the two services.		there is a perceived difference by the user in the two services.
	This leads naturally to the desire to perform service identification.		This leads naturally to the desire to perform service identification.
	Service identification is defined as the process of (1) determination		Service identification is defined as the process of (1) determination
	of the underlying service which is driving a particular signaling		of the underlying service which is driving a particular signaling
	skipping to change at page 11, line 37 ¶		skipping to change at page 11, line 41 ¶
	Almost always, the first solution that people consider is to add some		Almost always, the first solution that people consider is to add some
	kind of field to the signaling messages which indicates what the		kind of field to the signaling messages which indicates what the
	service is. This field would then be inserted by the user agent, and		service is. This field would then be inserted by the user agent, and
	then can be used by the proxies and other user agent as a service		then can be used by the proxies and other user agent as a service
	identifier.		identifier.
	This approach, however, misses a key point, which cannot be stressed		This approach, however, misses a key point, which cannot be stressed
	enough, and which represents the core architectural principle to be		enough, and which represents the core architectural principle to be
	understood here:		understood here:
	A service is the by-product of the signaling - the effects of the		A service is the by-product of the signaling and the context
	signaling message once launched into the network. The service		around it (the user profile, time-of-day and so on) - the effects
	identity is therefore always derivable from the signaling without		of the signaling message once launched into the network. The
	additional identifiers.		service identity is therefore always derivable from the signaling
			and its context without additional identifiers.
	When a user sends an INVITE request to the network, and targets that		When a user sends an INVITE request to the network, and targets that
	request at an IPTV server, and includes SDP for audio and video		request at an IPTV server, and includes SDP for audio and video
	streaming, the *result* of sending such an INVITE is that an IPTV		streaming, the *result* of sending such an INVITE is that an IPTV
	session occurs. The entire purpose of the INVITE is to establish		session occurs. The entire purpose of the INVITE is to establish
	such a session, and therefore, invoke the service. Thus, a service		such a session, and therefore, invoke the service. Thus, a service
	is not something that is different from the rest of the signaling		is not something that is different from the rest of the signaling
	message. A service is what the user gets after the network and other		message. A service is what the user gets after the network and other
	user agents have processed a signaling message.		user agents have processed a signaling message.
	skipping to change at page 17, line 45 ¶		skipping to change at page 18, line 8 ¶
	extensively in Section 6.2.1, that the usage of explicit service		extensively in Section 6.2.1, that the usage of explicit service
	identifiers inserted by a UA is NOT RECOMMENDED.		identifiers inserted by a UA is NOT RECOMMENDED.
	9. IANA Considerations		9. IANA Considerations
	There are no IANA considerations associated with this specification.		There are no IANA considerations associated with this specification.
	10. Acknowledgements		10. Acknowledgements
	This document is based on discussions with Paul Kyzivat and Andrew		This document is based on discussions with Paul Kyzivat and Andrew
	Allen, who contributed significantly to the ideas here.		Allen, who contributed significantly to the ideas here. Much of the
			content in this draft is a result of discussions amongst participants
			in the SIPPING mailing list, including Dean Willis, Tom Taylor, Eric
			Burger, Dale Worley, Christer Holmberg, and John Elwell, amongst many
			others.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	skipping to change at page 18, line 29 ¶		skipping to change at page 18, line 38 ¶
	[4] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of		[4] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of
	Extensions to the Session Initiation Protocol (SIP)", RFC 4485,		Extensions to the Session Initiation Protocol (SIP)", RFC 4485,
	May 2006.		May 2006.
	[5] Campbell, B., "The Message Session Relay Protocol",		[5] Campbell, B., "The Message Session Relay Protocol",
	draft-ietf-simple-message-sessions-19 (work in progress),		draft-ietf-simple-message-sessions-19 (work in progress),
	February 2007.		February 2007.
	[6] Rosen, B., "Framework for Emergency Calling in Internet		[6] Rosen, B., "Framework for Emergency Calling in Internet
	Multimedia", draft-ietf-ecrit-framework-00 (work in progress),		Multimedia", draft-ietf-ecrit-framework-01 (work in progress),
	October 2006.		March 2007.
	[7] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",		[7] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
	draft-ietf-ecrit-service-urn-05 (work in progress), August 2006.		draft-ietf-ecrit-service-urn-06 (work in progress), March 2007.
	[8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and		[8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
	D. Gurle, "Session Initiation Protocol (SIP) Extension for		D. Gurle, "Session Initiation Protocol (SIP) Extension for
	Instant Messaging", RFC 3428, December 2002.		Instant Messaging", RFC 3428, December 2002.
	Author's Address		Author's Address
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco		Cisco
	Edison, NJ		Edison, NJ
End of changes. 13 change blocks.
	28 lines changed or deleted		38 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/