< draft-burger-sipping-netann-10.txt		draft-burger-sipping-netann-11.txt >
	SIPPING E. Burger (Ed.)		SIPPING E. Burger (Ed.)
	Internet-Draft J. Van Dyke		Internet-Draft J. Van Dyke
	Expires: April 25, 2005 A. Spitzer		Expires: August 24, 2005 A. Spitzer
	Brooktrout Technology, Inc.		Brooktrout Technology, Inc.
	October 25, 2004		February 20, 2005
	Basic Network Media Services with SIP		Basic Network Media Services with SIP
	draft-burger-sipping-netann-10		draft-burger-sipping-netann-11
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any 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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 37 ¶
	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 April 25, 2005.		This Internet-Draft will expire on August 24, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	In SIP-based networks, there is a need to provide basic network media		In SIP-based networks, there is a need to provide basic network media
	services. Such services include network announcements, user		services. Such services include network announcements, user
	interaction, and conferencing services. These services are basic		interaction, and conferencing services. These services are basic
	building blocks, from which one can construct interesting		building blocks, from which one can construct interesting
	applications. In order to have interoperability between servers		applications. In order to have interoperability between servers
	offering these building blocks (also known as Media Servers) and		offering these building blocks (also known as Media Servers) and
	application developers, one needs to be able to locate and invoke		application developers, one needs to be able to locate and invoke
	such services in a well defined manner.		such services in a well defined manner.
	This document describes a mechanism for providing an interoperable		This document describes a mechanism for providing an interoperable
	protocol interface between Application Servers, which provide		interface between Application Servers, which provide application
	application services to SIP-based networks, and Media Servers, which		services to SIP-based networks, and Media Servers, which provide the
	provide the basic media processing building blocks.		basic media processing building blocks.
	Conventions used in this document		Conventions used in this document
	RFC2119 [1] provides the interpretations for the key words "MUST",		RFC2119 [2] provides the interpretations for the key words "MUST",
	"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",		"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
	"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.		"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
	Table of Contents		Table of Contents
	1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Announcement Service . . . . . . . . . . . . . . . . . . . . . 5		3. Announcement Service . . . . . . . . . . . . . . . . . . . . 6
	3.1 Operation . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1 Operation . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . 8		3.2 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . 9
	3.3 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 8		3.3 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 9
	4. Prompt and Collect Service . . . . . . . . . . . . . . . . . . 10		4. Prompt and Collect Service . . . . . . . . . . . . . . . . . 11
	4.1 Formal Syntax for Prompt and Collect Service . . . . . . . 11		4.1 Formal Syntax for Prompt and Collect Service . . . . . . . 12
	5. Conference Service . . . . . . . . . . . . . . . . . . . . . . 12		5. Conference Service . . . . . . . . . . . . . . . . . . . . . 13
	5.1 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . 13		5.1 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . 14
	5.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 15		5.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 16
	6. The User Part . . . . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. The User Part . . . . . . . . . . . . . . . . . . . . . . . 16
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . 19
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
	10.1 Normative References . . . . . . . . . . . . . . . . . . . . 19		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.2 Informative References . . . . . . . . . . . . . . . . . . . 19		11.1 Normative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20		11.2 Informative References . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
			Intellectual Property and Copyright Statements . . . . . . . 23
	1. Overview		1. Overview
	In SIP-based media networks (RFC3261 [2]), there is a need to provide		In SIP-based media networks (RFC3261 [6]), there is a need to provide
	basic network media services. Such services include playing		basic network media services. Such services include playing
	announcements, initiating a media mixing session (conference), and		announcements, initiating a media mixing session (conference), and
	prompting and collecting information with a user.		prompting and collecting information with a user.
	These services are basic in nature, are few in number, and		These services are basic in nature, are few in number, and
	fundamentally have not changed in 25 years of enhanced telephony		fundamentally have not changed in 25 years of enhanced telephony
	services. Moreover, given their elemental nature, one would not		services. Moreover, given their elemental nature, one would not
	expect them to change in the future.		expect them to change in the future.
	Multifunction media servers provide network media services to clients		Multifunction media servers provide network media services to clients
	using server protocols such as SIP, often in conjunction with markup		using server protocols such as SIP, often in conjunction with markup
	languages such as VoiceXML [10], KPML [11], and MSCML [12]. This		languages such as VoiceXML [15] and MSCML [16]. This document
	document describes how to identify to a multifunction media server		describes how to identify to a multifunction media server what sort
	what sort of session the client is requesting, without modifying the		of session the client is requesting, without modifying the SIP
	SIP protocol.		protocol.
			It is critically important to note that the mechanism described here
			in no way modifies the SIP protocol, the meaning or definition of a
			SIP Request URI, or does it put any restrictions, in any way, on
			devices that do not implement this convention.
	Announcements are media played to the user. Announcements can be		Announcements are media played to the user. Announcements can be
	static media files, media files generated in real-time, media streams		static media files, media files generated in real-time, media streams
	generated in real-time, multimedia objects, or combinations of the		generated in real-time, multimedia objects, or combinations of the
	above.		above.
	Media mixing is the act of mixing different RTP streams, as described		Media mixing is the act of mixing different RTP streams, as described
	in RFC1889 [13]. Note that the service described here suffices for		in RFC1889 [9]. Note that the service described here suffices for
	simple mixing of media for a basic conferencing service. This		simple mixing of media for a basic conferencing service. This
	service does not address enhanced conferencing services, such as		service does not address enhanced conferencing services, such as
	floor control, gain control, muting, subconferences, etc. MSCML [12]		floor control, gain control, muting, subconferences, etc. MSCML [16]
	addresses enhanced conferencing. However, that is beyond the scope		addresses enhanced conferencing. However, that is beyond the scope
	of this document. Interested readers should read		of this document. Interested readers should read
	conferencing-framework [14] for details on the IETF SIP conferencing		conferencing-framework [17] for details on the IETF SIP conferencing
	framework.		framework.
	Prompt and collect is where the server prompts the user for some		Prompt and collect is where the server prompts the user for some
	information, as in an announcement, and then collects the user's		information, as in an announcement, and then collects the user's
	response. This can be a one-step interaction, for example by playing		response. This can be a one-step interaction, for example by playing
	an announcement, "Please enter your pass code", followed by		an announcement, "Please enter your pass code", followed by
	collecting a string of digits. It can also be a more complex		collecting a string of digits. It can also be a more complex
	interaction, specified, for example, by VoiceXML [10] or MSCML [12].		interaction, specified, for example, by VoiceXML [15] or MSCML [16].
	2. Mechanism		2. Mechanism
	In the context of SIP control of media servers, we take advantage of		In the context of SIP control of media servers, we take advantage of
	the fact that the standard SIP URI has a user part. Multifunction		the fact that the standard SIP URI has a user part. Multifunction
	media servers do not have users. Thus we use the user address, or		media servers do not have users. Thus we use the user address, or
	the left-hand-side of the URI, as a service indicator.		the left-hand-side of the URI, as a service indicator.
			The use of the user part of the SIP Request URI has a number of
			useful properties:
			o There is no change to core SIP.
			o Only devices that choose to conform to this standard have to
			implement it.
			o This document only applies to multifunction SIP-controlled media
			servers.
			o This document has no impact on non-multifunction SIP-controlled
			media servers.
			o The mechanism described in this document has absolutely no impact
			on SIP devices other than media servers.
			The last bullet point is cruical. In particular, the user part
			convention described here places absolutely no restrictions on any
			SIP user agent, proxy, B2BUA, or any future device. The user parts
			defined here only apply to multifunction media servers that chose to
			implement the convention. With the exception of a conforming media
			server, these user names and conventions have no impact on the user
			part namespace. They do not restrict the use of these user names at
			devices other than a multifunction media server.
	Note that the set of services is small, well defined, and well		Note that the set of services is small, well defined, and well
	contained. The section The User Part (Section 6) discusses the		contained. The section The User Part (Section 7) discusses the
	issues with using a fixed set of user-space names.		issues with using a fixed set of user-space names.
	For per-service security, the media server SHOULD use the security		For per-service security, the media server SHOULD use the security
	protocols described in RFC3261 [2].		protocols described in RFC3261 [6].
	The media server MAY issue 401 challenges for authentication. The		The media server MAY issue 401 challenges for authentication. The
	media server SHOULD support the sips: scheme for the announcement		media server SHOULD support the sips: scheme for the announcement
	service. The media server MUST support the sips: scheme for the		service. The media server MUST support the sips: scheme for the
	dialog and conference services. The level of authentication to		dialog and conference services. The level of authentication to
	require for each service is a matter of local policy.		require for each service is a matter of local policy.
	The media server, upon receiving the INVITE, notes the service		The media server, upon receiving an INVITE, notes the service
	indicator. Depending on the service indicator, the media server will		indicator. Depending on the service indicator, the media server will
	either honor the request or return a failure response code.		either honor the request or return a failure response code.
	The service indicator is the concatenation of the service name and an		The service indicator is the concatenation of the service name and an
	optional service instance identifier, separated by an equal sign.		optional service instance identifier, separated by an equal sign.
	Per RFC3261 [2], the service indicator is case insensitive. The		Per RFC3261 [6], the service indicator is case insensitive. The
	service name MUST be from the set alphanumeric characters plus dash		service name MUST be from the set alphanumeric characters plus dash
	(US-ASCII %2C). The service name MUST NOT include an equal sign		(US-ASCII %2C). The service name MUST NOT include an equal sign
	(US-ASCII %3D).		(US-ASCII %3D).
	The service name MAY have long- and short-forms, as SIP does for		The service name MAY have long- and short-forms, as SIP does for
	headers.		headers.
	A given service indicator MAY have an associated set of parameters.		A given service indicator MAY have an associated set of parameters.
	Such parameters MUST follow the convention set out for SIP URI		Such parameters MUST follow the convention set out for SIP URI
	parameters. That is, a semi-colon separated list of keyword=value		parameters. That is, a semi-colon separated list of keyword=value
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 39 ¶
	If the media server can perform the requested service, it does so,		If the media server can perform the requested service, it does so,
	following the processing steps described in the service definition		following the processing steps described in the service definition
	document.		document.
	If the media server cannot perform the requested service or does not		If the media server cannot perform the requested service or does not
	recognize the service indicator, it MUST respond with the response		recognize the service indicator, it MUST respond with the response
	code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to		code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to
	a problem with the user part of the URI. Moreover, 606 is not		a problem with the user part of the URI. Moreover, 606 is not
	appropriate, as some other media server may be able to satisfy the		appropriate, as some other media server may be able to satisfy the
	request. RFC3261 [2] describes the 488 and 606 response codes.		request. RFC3261 [6] describes the 488 and 606 response codes.
	Some services require a unique identifier. Most services		Some services require a unique identifier. Most services
	automatically create a service instance upon the first INVITE with		automatically create a service instance upon the first INVITE with
	the given identifier. However, if a service requires an existing		the given identifier. However, if a service requires an existing
	service instance, and no such service instance exists on the media		service instance, and no such service instance exists on the media
	server, the media server MUST respond with the response code 404 NOT		server, the media server MUST respond with the response code 404 NOT
	FOUND. This is appropriate as the service itself exists on the media		FOUND. This is appropriate as the service itself exists on the media
	server, but the particular service instance does not. It is as if		server, but the particular service instance does not. It is as if
	the user was not home.		the user was not home.
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 49 ¶
	explanatory text explaining what failed.		explanatory text explaining what failed.
	The Request URI fully describes the announcement service through the		The Request URI fully describes the announcement service through the
	use of the user part of the address and additional URI parameters.		use of the user part of the address and additional URI parameters.
	The user portion of the address, "annc", specifies the announcement		The user portion of the address, "annc", specifies the announcement
	service on the media server. The service has several associated URI		service on the media server. The service has several associated URI
	parameters that control the content and delivery of the announcement.		parameters that control the content and delivery of the announcement.
	These parameters are described below:		These parameters are described below:
	play Specifies the resource or announcement sequence to be played.		play Specifies the resource or announcement sequence to be played.
	repeat Specifies how many times the media server should repeat the		repeat Specifies how many times the media server should repeat the
	announcement or sequence named by the "play=" parameter. A		announcement or sequence named by the "play=" parameter. The
	negative value means the media server repeats the announcement		value "forever" means the repeat should be effectively unbounded.
	forever. In this case, it is RECOMMENDED the media server		In this case, it is RECOMMENDED the media server implements some
	implements some local policy, such as limiting what "forever"		local policy, such as limiting what "forever" means, to ensure
	means, to ensure errant clients do not create a denial of service		errant clients do not create a denial of service attack.
	attack.
	delay Specifies a delay interval between announcement repetitions.		delay Specifies a delay interval between announcement repetitions.
	The delay is measured in milliseconds.		The delay is measured in milliseconds.
	duration Specifies the maximum duration of the announcement. The		duration Specifies the maximum duration of the announcement. The
	media server will discontinue the announcement and end the call if		media server will discontinue the announcement and end the call if
	the maximum duration has been reached. The duration is measured		the maximum duration has been reached. The duration is measured
	in milliseconds.		in milliseconds.
	locale Specifies the language and optionally country variant of the		locale Specifies the language and optionally country variant of the
	announcement sequence named in the "play=" parameter. RFC3066 [3]		announcement sequence named in the "play=" parameter. RFC3066 [5]
	specifies the locale tag. The locale tag is usually a two- or		specifies the locale tag. The locale tag is usually a two- or
	three-letter code per ISO 639-1 [4]. The country variant is also		three-letter code per ISO 639-1 [7]. The country variant is also
	often a two-letter code per ISO 3166-1 [5]. These elements are		often a two-letter code per ISO 3166-1 [8]. These elements are
	concatenated with a single under bar (%x5F) character, such as		concatenated with a single under bar (%x5F) character, such as
	"en_CA". If only the language is specified, such as locale=en,		"en_CA". If only the language is specified, such as locale=en,
	the choice of country variant is an implementation matter.		the choice of country variant is an implementation matter.
	Implementations SHOULD provide the best possible match between the		Implementations SHOULD provide the best possible match between the
	requested locale and the available languages in the event the		requested locale and the available languages in the event the
	media server cannot honor the locale request precisely. For		media server cannot honor the locale request precisely. For
	example, if the request has locale=ca_FR but the media server only		example, if the request has locale=ca_FR but the media server only
	has fr_FR available, the media server should use the fr_FR		has fr_FR available, the media server should use the fr_FR
	variant. Implementations SHOULD provide a default locale to use		variant. Implementations SHOULD provide a default locale to use
	if no language variants are available.		if no language variants are available.
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 30 ¶
	requested locale and the available languages in the event the		requested locale and the available languages in the event the
	media server cannot honor the locale request precisely. For		media server cannot honor the locale request precisely. For
	example, if the request has locale=ca_FR but the media server only		example, if the request has locale=ca_FR but the media server only
	has fr_FR available, the media server should use the fr_FR		has fr_FR available, the media server should use the fr_FR
	variant. Implementations SHOULD provide a default locale to use		variant. Implementations SHOULD provide a default locale to use
	if no language variants are available.		if no language variants are available.
	param[n] Provides a mechanism for passing values that are to be		param[n] Provides a mechanism for passing values that are to be
	substituted into an announcement sequence. Up to 9 parameters		substituted into an announcement sequence. Up to 9 parameters
	("param1=" through "param9=") may be specified. The mechanics of		("param1=" through "param9=") may be specified. The mechanics of
	announcement sequences are beyond the scope of this document.		announcement sequences are beyond the scope of this document.
	extension Provides a mechanism for extending the parameter set. If		extension Provides a mechanism for extending the parameter set. If
	the media server receives an extension it does not understand, it		the media server receives an extension it does not understand, it
	MUST silently ignore the extension parameter and value.		MUST silently ignore the extension parameter and value.
	The "play=" parameter is mandatory and MUST be present. All other		The "play=" parameter is mandatory and MUST be present. All other
	parameters are OPTIONAL.		parameters are OPTIONAL.
	NOTE: Some encodings are not self-describing. Thus the		NOTE: Some encodings are not self-describing. Thus the
	implementation relies on filename extension conventions for		implementation relies on filename extension conventions for
	determining the media type.		determining the media type.
	Note that RFC3261 [2] implies that proxies are supposed to pass		Note that RFC3261 [6] implies that proxies are supposed to pass
	parameters through unchanged. However, be aware that non-conforming		parameters through unchanged. However, be aware that non-conforming
	proxies may strip Request-URI parameters. That said, given the		proxies may strip Request-URI parameters. That said, given the
	likely scenarios for the mechanisms presented in this document, this		likely scenarios for the mechanisms presented in this document, this
	should not be an issue. Most likely, the proxy inserting the		should not be an issue. Most likely, the proxy inserting the
	parameters is the last proxy before the media server. If the service		parameters is the last proxy before the media server. If the service
	provider deploys a proxy for load balancing or service location		provider deploys a proxy for load balancing or service location
	purposes, the service provider should ensure their choice of proxy		purposes, the service provider should ensure their choice of proxy
	preserves parameters.		preserves parameters.
	The form of the SIP Request URI for announcements is as follows.		The form of the SIP Request URI for announcements is as follows.
	skipping to change at page 7, line 48 ¶		skipping to change at page 8, line 26 ¶
	The scenarios below assume there is a SIP Proxy, application server,		The scenarios below assume there is a SIP Proxy, application server,
	or media gateway controller between the caller and the media server.		or media gateway controller between the caller and the media server.
	However, the announcement service works as described below even if		However, the announcement service works as described below even if
	the caller invokes the service directly. We chose to discuss the		the caller invokes the service directly. We chose to discuss the
	proxy case, as it will be the most common case.		proxy case, as it will be the most common case.
	The caller issues an INVITE to the serving SIP Proxy. The SIP Proxy		The caller issues an INVITE to the serving SIP Proxy. The SIP Proxy
	determines what audio prompt to play to the caller. The proxy		determines what audio prompt to play to the caller. The proxy
	responds to the caller with 100 TRYING.		responds to the caller with 100 TRYING.
			It is important to note that the mechanism described here in no way
			modifies the behavior of SIP [6]. In particular, this convention
			does not modify SDP negotiation [14].
	The proxy issues an INVITE to the media server, requesting the		The proxy issues an INVITE to the media server, requesting the
	appropriate prompt to play coded in the play= parameter. The media		appropriate prompt to play coded in the play= parameter. The media
	server responds with 200 OK. The proxy relays the 200 OK to the		server responds with 200 OK. The proxy relays the 200 OK to the
	caller. The caller then issues an ACK. The proxy then relays the		caller. The caller then issues an ACK. The proxy then relays the
	ACK to the media server.		ACK to the media server.
	With the call established, the media server plays the requested		With the call established, the media server plays the requested
	prompt. When the media server completes the play of the prompt, it		prompt. When the media server completes the play of the prompt, it
	issues a BYE to the proxy. The proxy then issues a BYE to the		issues a BYE to the proxy. The proxy then issues a BYE to the
	caller.		caller.
	skipping to change at page 8, line 30 ¶		skipping to change at page 9, line 24 ¶
	| ACK | |		| ACK | |
	|----------------------->| ACK |		|----------------------->| ACK |
	| |----------------------->|		| |----------------------->|
	| | |		| | |
	| Play Announcement (RTP) |		| Play Announcement (RTP) |
	|<================================================|		|<================================================|
	| | |		| | |
	| | BYE |		| | BYE |
	| BYE |<-----------------------|		| BYE |<-----------------------|
	|<-----------------------| |		|<-----------------------| |
	| 200 OK | 200 OK |		| 200 OK | |
	|----------------------->|----------------------->|		|----------------------->| 200 OK |
			| |----------------------->|
	| | |		| | |
	3.3 Formal Syntax		3.3 Formal Syntax
	The following syntax specification uses the augmented Backus-Naur		The following syntax specification uses the augmented Backus-Naur
	Form (BNF) as described in RFC2234 [6].		Form (BNF) as described in RFC2234 [3].
	ANNC-URL = sip-ind annc-ind "@" hostport		ANNC-URL = sip-ind annc-ind "@" hostport
	annc-parameters uri-parameters		annc-parameters uri-parameters
	sip-ind = "sip:" / "sips:"		sip-ind = "sip:" / "sips:"
	annc-ind = "annc"		annc-ind = "annc"
	annc-parameters = ";" play-param [ ";" content-param ]		annc-parameters = ";" play-param [ ";" content-param ]
	[ ";" delay-param]		[ ";" delay-param]
	[ ";" duration-param ]		[ ";" duration-param ]
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 46 ¶
	sip-ind = "sip:" / "sips:"		sip-ind = "sip:" / "sips:"
	annc-ind = "annc"		annc-ind = "annc"
	annc-parameters = ";" play-param [ ";" content-param ]		annc-parameters = ";" play-param [ ";" content-param ]
	[ ";" delay-param]		[ ";" delay-param]
	[ ";" duration-param ]		[ ";" duration-param ]
	[ ";" repeat-param ]		[ ";" repeat-param ]
	[ ";" locale-param ]		[ ";" locale-param ]
	[ ";" variable-params ]		[ ";" variable-params ]
	[ ";" extension-params ]		[ ";" extension-params ]
	play-param = "play=" prompt-url		play-param = "play=" prompt-url
	content-param = "content-type=" MIME-type		content-param = "content-type=" MIME-type
	delay-param = "delay=" delay-value		delay-param = "delay=" delay-value
	delay-value = 1*DIGIT		delay-value = 1*DIGIT
	duration-param = "duration=" duration-value		duration-param = "duration=" duration-value
	duration-value = 1*DIGIT		duration-value = 1*DIGIT
	repeat-param = "repeat=" repeat-value		repeat-param = "repeat=" repeat-value
	repeat-value = 1*DIGIT		repeat-value = 1*DIGIT | "forever"
	locale-param = "locale=" token		locale-param = "locale=" token
	; per RFC3066, usually		; per RFC3066, usually
	; ISO639-1_ISO3166-1		; ISO639-1_ISO3166-1
	; e.g., en, en_US, en_UK, etc.		; e.g., en, en_US, en_UK, etc.
	variable-params = param-name "=" variable-value		variable-params = param-name "=" variable-value
	param-name = "param" DIGIT ; e.g., "param1"		param-name = "param" DIGIT ; e.g., "param1"
	variable-value = 1*(ALPHA | DIGIT)		variable-value = 1*(ALPHA | DIGIT)
	extension-params = extension-param [ ";" extension-params ]		extension-params = extension-param [ ";" extension-params ]
	extension-param = token "=" token		extension-param = token "=" token
	"uri-parameters" is the SIP Request-URI parameter list as described		"uri-parameters" is the SIP Request-URI parameter list as described
	in RFC3261 [2]. All parameters of the Request URI are part of the		in RFC3261 [6]. All parameters of the Request URI are part of the
	URI matching algorithm.		URI matching algorithm.
	The MIME-type is the MIME [7] content type for the announcement, such		The MIME-type is the MIME [1] content type for the announcement, such
	as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on.		as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on.
	To date, none of the IETF audio MIME registrations have parameters.		To date, none of the IETF audio MIME registrations have parameters.
	Vendor-specific registrations, such as audio/x-wav, do have		Vendor-specific registrations, such as audio/x-wav, do have
	parameters. However, they are not strictly needed for prompt		parameters. However, they are not strictly needed for prompt
	fetching.		fetching.
	On the other hand, the prevalence of parameters may change in the		On the other hand, the prevalence of parameters may change in the
	future. In addition, existing video registrations have parameters,		future. In addition, existing video registrations have parameters,
	such as video/DV. To accommodate this, and retain compatibility with		such as video/DV. To accommodate this, and retain compatibility with
	the SIP URI structure, the MIME-type parameter separator (semicolon,		the SIP URI structure, the MIME-type parameter separator (semicolon,
	%3b) and value separator (equal, %d3) MUST be escaped. For example:		%3b) and value separator (equal, %d3) MUST be escaped. For example:
	sip:annc@ms.example.net; \		sip:annc@ms.example.net; \
	play=file://fs.example.net/clips/my-intro.dvi; \		play=file://fs.example.net/clips/my-intro.dvi; \
	content-type=video/mpeg%3bencode%d3314M-25/625-50		content-type=video/mpeg%3bencode%d3314M-25/625-50
	The locale-value consists of a tag as specified in RFC3066 [3].		The locale-value consists of a tag as specified in RFC3066 [5].
	The definition of hostport is as specified by RFC3261 [2].		The definition of hostport is as specified by RFC3261 [6].
	The syntax of prompt-url consists of a URL scheme as specified by		The syntax of prompt-url consists of a URL scheme as specified by
	RFC2396 [8] or a special token indicating a provisioned announcement		RFC2396 [4] or a special token indicating a provisioned announcement
	sequence. For example, the URL scheme MAY include any of the		sequence. For example, the URL scheme MAY include any of the
	following.		following.
	o http/https		o http/https
	o ftp		o ftp
	o file (referencing a local, NFS (RFC3010 [15]), or AFS file)		o file (referencing a local or NFS (RFC3010 [12]) object)
	o nfs (RFC2224 [16])		o nfs (RFC2224 [10])
	If a provisioned announcement sequence is to be played the value of		If a provisioned announcement sequence is to be played the value of
	prompt-url will have the following form:		prompt-url will have the following form:
	prompt-url = "/provisioned/" announcement-id		prompt-url = "/provisioned/" announcement-id
	announcement-id = 1*(ALPHA | DIGIT)		announcement-id = 1*(ALPHA | DIGIT)
	Note that the scheme "/provisioned/" was chosen because of a		Note that the scheme "/provisioned/" was chosen because of a
	hesitation to register a "provisioned:" URI scheme.		hesitation to register a "provisioned:" URI scheme.
	skipping to change at page 11, line 27 ¶		skipping to change at page 12, line 20 ¶
	such, the VoiceXML browser implementation on the media server MUST		such, the VoiceXML browser implementation on the media server MUST
	support https fetching of grammars and subsequent documents.		support https fetching of grammars and subsequent documents.
	Returned information often is sensitive. For example, the		Returned information often is sensitive. For example, the
	information could be financial information or instructions. Thus the		information could be financial information or instructions. Thus the
	media server MUST support https posting of results.		media server MUST support https posting of results.
	4.1 Formal Syntax for Prompt and Collect Service		4.1 Formal Syntax for Prompt and Collect Service
	The following syntax specification uses the augmented Backus-Naur		The following syntax specification uses the augmented Backus-Naur
	Form (BNF) as described in RFC2234 [6].		Form (BNF) as described in RFC2234 [3].
	DIALOG-URL = sip-ind dialog-ind "@" hostport		DIALOG-URL = sip-ind dialog-ind "@" hostport
	dialog-parameters		dialog-parameters
	sip-ind = "sip:" / "sips:"		sip-ind = "sip:" / "sips:"
	dialog-ind = "dialog"		dialog-ind = "dialog"
	dialog-parameters = ";" dialog-param [ vxml-parameters ]		dialog-parameters = ";" dialog-param [ vxml-parameters ]
	[ uri-parameters ]		[ uri-parameters ]
	skipping to change at page 12, line 19 ¶		skipping to change at page 13, line 11 ¶
	The media server presents the parameters as environment variables in		The media server presents the parameters as environment variables in
	the connection object. Specifically, the parameter appears in the		the connection object. Specifically, the parameter appears in the
	connection.sip tree.		connection.sip tree.
	If the Media Server does not support the passing of keyword-value		If the Media Server does not support the passing of keyword-value
	pairs to the VoiceXML interpreter session, it MUST ignore the		pairs to the VoiceXML interpreter session, it MUST ignore the
	parameters.		parameters.
	"uri_parameters" is the SIP Request-URI parameter list as described		"uri_parameters" is the SIP Request-URI parameter list as described
	in RFC3261 [2]. All parameters in the parameter list, whether they		in RFC3261 [6]. All parameters in the parameter list, whether they
	come from uri-parameters or from vxml-keyworks, are part of the URI		come from uri-parameters or from vxml-keyworks, are part of the URI
	matching algorithm.		matching algorithm.
	5. Conference Service		5. Conference Service
	One identifies mixing sessions through their SIP request URIs. To		One identifies mixing sessions through their SIP request URIs. To
	create a mixing session, one sends an INVITE to a request URI that		create a mixing session, one sends an INVITE to a request URI that
	represents the session. If the URI does not already exist on the		represents the session. If the URI does not already exist on the
	media server and the requested resources are available, the media		media server and the requested resources are available, the media
	server creates a new mixing session. If there is an existing URI for		server creates a new mixing session. If there is an existing URI for
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 38 ¶
	The left-hand side of the request URI is actually the username of the		The left-hand side of the request URI is actually the username of the
	request in the request URI and the To header. The host portion of		request in the request URI and the To header. The host portion of
	the URI identifies a particular media server. The "conf" user name		the URI identifies a particular media server. The "conf" user name
	conveys to the media server that this is a request for the mixing		conveys to the media server that this is a request for the mixing
	service. The uniqueIdentifier can be any value that is compliant		service. The uniqueIdentifier can be any value that is compliant
	with the SIP URI specification. It is the responsibility of the		with the SIP URI specification. It is the responsibility of the
	conference control application to ensure the identifier is unique		conference control application to ensure the identifier is unique
	within the scope of any potential conflict.		within the scope of any potential conflict.
	In the terminology of the conferencing framework		In the terminology of the conferencing framework
	conferencing-framework [14], this URI convention tells the media		conferencing-framework [17], this URI convention tells the media
	server that the application server is requesting it to act as a		server that the application server is requesting it to act as a
	Focus. The conf-id value identifies the particular focus instance.		Focus. The conf-id value identifies the particular focus instance.
	As a focus in the conferencing framework, the media server MUST		As a focus in the conferencing framework, the media server MUST
	support the ";isfocus" parameter in the Request URI. Note however,		support the ";isfocus" parameter in the Request URI. Note however,
	that the presence or absence of the ";isfocus" parameter has no		that the presence or absence of the ";isfocus" parameter has no
	protocol impact at the media server.		protocol impact at the media server.
	It is worth noting that the conference URI shared between the		It is worth noting that the conference URI shared between the
	application and media servers provides enhanced security, as the SIP		application and media servers provides enhanced security, as the SIP
	control interface does not have to be exposed to participants. It		control interface does not have to be exposed to participants. It
	also allows the assignment of a specific media server to be delayed		also allows the assignment of a specific media server to be delayed
	as long as possible, thereby simplifying resource management.		as long as possible, thereby simplifying resource management.
	One can add additional legs to the conference by INVITEing them to		One can add additional legs to the conference by INVITEing them to
	the above mentioned request URI. Per the matching rules of RFC3261		the above mentioned request URI. Per the matching rules of RFC3261
	[2], the conf-id parameter is part of the matching string.		[6], the conf-id parameter is part of the matching string.
	Conversely, one can remove legs by issuing a BYE in the corresponding		Conversely, one can remove legs by issuing a BYE in the corresponding
	dialog. The mixing session, and thus the conference-specific request		dialog. The mixing session, and thus the conference-specific request
	URI, remains active so long as there is at least one SIP dialog		URI, remains active so long as there is at least one SIP dialog
	associated with the given request URI.		associated with the given request URI.
	If the Request-URI has "conf" as the user part, but does not have a		If the Request-URI has "conf" as the user part, but does not have a
	conf-id parameter, the media server MUST respond with a 404 NOT		conf-id parameter, the media server MUST respond with a 404 NOT
	FOUND.		FOUND.
	NOTE: The media server could create a unique conference instance		NOTE: The media server could create a unique conference instance
	and return the conf-id string to the UAC if there is no conf-id		and return the conf-id string to the UAC if there is no conf-id
	present. However, such an operation may have other operational		present. However, such an operation may have other operational
	issues, such as permissions and billing. Thus an application		issues, such as permissions and billing. Thus an application
	server or proxy is a better place to do such an operation.		server or proxy is a better place to do such an operation.
	Moreover, such action would make the media server into a		Moreover, such action would make the media server into a
	Conference Factory in the terminology of conference-framework		Conference Factory in the terminology of conference-framework
	[14]. That is not the appropriate behavior for a media server.		[17]. That is not the appropriate behavior for a media server.
	Since some conference use cases, such as business conferencing, have		Since some conference use cases, such as business conferencing, have
	billing implications, the media server SHOULD authenticate the		billing implications, the media server SHOULD authenticate the
	application server or proxy. At a minimum, the media server MUST		application server or proxy. At a minimum, the media server MUST
	implement sip: digest authentication and sips:.		implement sips:.
	5.1 Protocol Diagram		5.1 Protocol Diagram
	This diagram shows the establishment of a three-way conference. This		This diagram shows the establishment of a three-way conference. This
	section is informative. It is only one method of establishing a		section is informative. It is only one method of establishing a
	conference. This example shows a simple back-to-back user agent.		conference. This example shows a simple back-to-back user agent.
	The conference-framework [14] describes additional parameters and		The conference-framework [17] describes additional parameters and
	behaviors of the Application Server. For example, the first INVITE		behaviors of the Application Server. For example, the first INVITE
	from P1 to the Application Server would include the ";isfocus"		from P1 to the Application Server would include the ";isfocus"
	parameter; the Application Server would act as a Conference Factory;		parameter; the Application Server would act as a Conference Factory;
	and so on. However, none of that protocol machinery has an impact on		and so on. However, none of that protocol machinery has an impact on
	the operation of the Application Server to Media Server interface,		the operation of the Application Server to Media Server interface,
	which is the focus of this protocol document.		which is the focus of this protocol document.
	P1 P2 P3 Application Server Media Server		P1 P2 P3 Application Server Media Server
	| | | | |		| | | | |
	| INVITE sip:public-conf@as.example.net |		| INVITE sip:public-conf@as.example.net |
	|---------------------------------->| |		|---------------------------------->| |
	| | | INVITE sip:conf=123@ms.example.net |		| | | INVITE sip:conf=123@ms.example.net |
	| | | |------------------>|		| | | |------------------>|
	| | | | 200 OK |		| | | | 200 OK |
	| 200 OK | |<------------------|		| 200 OK | |<------------------|
	|<----------------------------------| |		|<----------------------------------| |
			| ACK | | | |
			|---------------------------------->| ACK |
			| | | |------------------>|
	| | | RTP w/ P1 | |		| | | RTP w/ P1 | |
	|<=====================================================>|		|<=====================================================>|
	| | | | |		| | | | |
	| INVITE sip:public-conf@as.example.net |		| INVITE sip:public-conf@as.example.net |
	| |-------------------------->| |		| |-------------------------->| |
	| | | INVITE sip:conf=123@ms.example.net |		| | | INVITE sip:conf=123@ms.example.net |
	| | | |------------------>|		| | | |------------------>|
	| | | | 200 OK |		| | | | 200 OK |
	| | 200 OK | |<------------------|		| | 200 OK | |<------------------|
	| |<--------------------------| |		| |<--------------------------| |
			| | ACK | | |
			| |-------------------------->| ACK |
			| | | |------------------>|
	| | | | |		| | | | |
	| | | RTP w/ P1+P2-P2 | |		| | | RTP w/ P1+P2-P2 | |
	| |<=============================================>|		| |<=============================================>|
	| | | RTP w/ P1+P2-P1 | |		| | | RTP w/ P1+P2-P1 | |
	|<=====================================================>|		|<=====================================================>|
	| | | | |		| | | | |
	| INVITE sip:public-conf@as.example.net |		| INVITE sip:public-conf@as.example.net |
	| | |----------------->| |		| | |----------------->| |
	| | INVITE sip:conf=123@ms.example.net |		| | | INVITE sip:conf=123@ms.example.net |
	| | | |------------------>|		| | | |------------------>|
	| | | | 200 OK |		| | | | 200 OK |
	| | | 200 OK |<------------------|		| | | 200 OK |<------------------|
	| | |<-----------------| |		| | |<-----------------| |
			| | | ACK | |
			| | |----------------->| ACK |
			| | | |------------------>|
	| | | | |		| | | | |
	| | | RTP w/ P1+P2+P3-P3 |		| | | RTP w/ P1+P2+P3-P3 |
	| | |<====================================>|		| | |<====================================>|
	| | | RTP w/ P1+P2+P3-P2 |		| | | RTP w/ P1+P2+P3-P2 |
	| |<=============================================>|		| |<=============================================>|
	| | | RTP w/ P1+P2+P3-P1 |		| | | RTP w/ P1+P2+P3-P1 |
	|<=====================================================>|		|<=====================================================>|
	| | | | |		| | | | |
	| | | | |		| | | | |
	Using the terminology of conference-framework [14], the Application		Using the terminology of conference-framework [17], the Application
	Server is the Conference Factory and the Media Server is the		Server is the Conference Factory and the Media Server is the
	Conference Focus.		Conference Focus.
	Note that the above call flow does not show any 100 TRYING messages		Note that the above call flow does not show any 100 TRYING messages
	that would typically flow from the Application Server to the UAC's,		that would typically flow from the Application Server to the UAC's,
	nor does it show the ACK's from the UAC's to the Application Server		nor does it show the ACK's from the UAC's to the Application Server
	or from the Application Server to the Media Server.		or from the Application Server to the Media Server.
	Each leg can drop out either under the supervision of the UAC by the		Each leg can drop out either under the supervision of the UAC by the
	UAC sending a BYE or under the supervision of the Application Server		UAC sending a BYE or under the supervision of the Application Server
	skipping to change at page 15, line 25 ¶		skipping to change at page 16, line 26 ¶
	Application Server can mute legs, create side conferences, and so		Application Server can mute legs, create side conferences, and so
	forth.		forth.
	Note that the Application Server is a server to the participants		Note that the Application Server is a server to the participants
	(UAC's). However, the Application Server is a client for mixing		(UAC's). However, the Application Server is a client for mixing
	services to the Media Server.		services to the Media Server.
	5.2 Formal Syntax		5.2 Formal Syntax
	The following syntax specification uses the augmented Backus-Naur		The following syntax specification uses the augmented Backus-Naur
	Form (BNF) as described in RFC2234 [6].		Form (BNF) as described in RFC2234 [3].
	CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport		CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport
	[ uri_parameters ]		[ uri_parameters ]
	sip-ind = "sip:" / "sips:"		sip-ind = "sip:" / "sips:"
	conf-ind = "conf"		conf-ind = "conf"
	instance-id = token		instance-id = token
	"uri-parameters" is the SIP Request-URI parameter list as described		"uri-parameters" is the SIP Request-URI parameter list as described
	in RFC3261 [2]. All parameters in the parameter list are part of the		in RFC3261 [6]. All parameters in the parameter list are part of the
	URI matching algorithm.		URI matching algorithm.
	6. The User Part		6. IANA Considerations
	There has been considerable debate about the wisdom of using fixed		None.
	user parts in a request URI. The most common objection is that the
	user part should be opaque and a local matter. The other objection		7. The User Part
	is that using a fixed user part removes those specified user
	addresses from the user address space.		There has been considerable discussion about the wisdom of using
			fixed user parts in a request URI. The most common objection is that
			the user part should be opaque and a local matter. The other
			objection is that using a fixed user part removes those specified
			user addresses from the user address space.
	We address the latter issue first. The common example is the		We address the latter issue first. The common example is the
	Postmaster address defined by RFC2821 [17]. The objection is that by		Postmaster address defined by RFC2821 [11]. The objection is that by
	using the Postmaster token for something special, one removes that		using the Postmaster token for something special, one removes that
	token for anyone. Thus, the Postmaster General of the United States,		token for anyone. Thus, the Postmaster General of the United States,
	for example, cannot have the mail address Postmaster@usps.gov. One		for example, cannot have the mail address Postmaster@usps.gov. One
	may debate whether this is a significant limitation, however.		may debate whether this is a significant limitation, however.
	One may point out that "annc", for example, has the potential for		This document explicitly addresses this issue. The user names
	conflict. Clearly, with the use of underbars, sip, and a hyphen,		described in the text, namely annc, ivr, dialog, and conf are
	this conflict is much smaller than the potential for a conflict like		available for whatever local use a given SIP user agent or proxy
	"Postmaster".		wishes for them. What this document does is give special meaning for
			these user names at media servers that implement this specification.
			If a media server choses not to implement this specification, nothing
			breaks. If a user wishes to use one of the user names described in
			this document at their SIP user agent, nothing breaks and their user
			agent will work as expected.
	The key point is, one cannot confuse the namespace at a Media Server		The key point is, one cannot confuse the namespace at a Media Server
	with the namespace for an organization.		with the namespace for an organization. For example, let us take the
			case where a network offers services for "Ann Charles". She likes to
			use the name "annc", and thus she would like to use
			"sip:annc@example.net". We offer there is ABSOLUTELY NO NAME
			COLLISION WHATSOEVER. Why is this so? This is so because
			sip:annc@example.net will resolve to the specific user at a specific
			device for Ann. As an example, example.net's SIP Proxy Server
			resolves sip:annc@example.net to annc@anns-phone.example.net .
			Conversely, one directs requests for the media service annc directly
			to the Media Server, e.g., sip:annc@ms21.ap.example.net . Moreover,
			by definition, requests for Ann Charles, or anything other than the
			announcement service, will NEVER be directly sent to the Media
			Server. If that were not true, no phone in the world could use the
			user part "eburger", as eburger is a reserved user part in the
			Brooktrout domain. This clearly is not the case.
	For example, let us take the case where a network offers services for		If one wishes to make their media server accessible to the global
	"Ann Charles". She likes to use the name "annc", and thus she would		Internet, but retain one of the Media Server-specific user names in
	like to use "sip:annc@example.net". We offer that there is		the domain, a SIP Proxy can easily translate whatever opaque name one
	ABSOLUTELY NO NAME COLLISION WHATSOEVER. Why is this so? This is so		choses to the Media Server-specific user name. For example, if a
	because sip:annc@example.net will resolve to the specific user at a		domain whishes to offer services for the above mentioned Ann Charles
	specific device for Ann. As an example, example.net's SIP Proxy		at sip:annc@example.com, they can offer the announcement service at
	Server resolves sip:annc@example.net to annc@anns-phone.example.net .		sip:my-special-announcement-service@example.com . The former
	One directs requests for the media service annc directly to the Media		address, sip:annc@example.com, would resolve to the actual device
	Server, e.g., sip:annc@ms21.ap.example.net . Moreover, by		where annc resides. The latter would resolve to the media server
	definition, Ann Charles, or anything other than the announcement		announcement server address, sip:annc@mediaserver.example.com, as an
	service, will NEVER be directly on the Media Server. If that were		example. Note that this convention makes it easier to provision this
	not true, no phone in the world could use the user part "eburger", as		service. With a fixed mapping at the multifunction media server,
	eburger is a reserved user part in the SnowShore domain.		there are less provisioning data elements to get wrong.
	Here is another way of looking at this issue. Unix reserves the		Here is another way of looking at this issue. Unix reserves the
	special user "root". Just about all Unix machines have a user root,		special user "root". Just about all Unix machines have a user root,
	who has an address "root@a-specific-machine.example.com", where		who has an address "root@a-specific-machine.example.com", where
	"a-specific-machine" is the fully-qualified domain name (FQDN) of a		"a-specific-machine" is the fully-qualified domain name (FQDN) of a
	particular instance of a machine. There are very well-defined		particular instance of a machine. There are very well-defined
	semantics for the "root" user.		semantics for the "root" user.
	Even though most every Unix machine has a "root" user, often there is		Even though most every Unix machine has a "root" user, often there is
	no mapping for a "root" user in a domain, such as "root@example.com".		no mapping for a "root" user in a domain, such as "root@example.com".
	skipping to change at page 17, line 9 ¶		skipping to change at page 18, line 33 ¶
	considered obfuscating the user name by prepending "__sip-" to the		considered obfuscating the user name by prepending "__sip-" to the
	user name. However, as explained above, this obfuscation is not		user name. However, as explained above, this obfuscation is not
	necessary. There is a fundamental difference between a user name at		necessary. There is a fundamental difference between a user name at
	a device and a user name at a MX record (SMTP) or Address-of-Record		a device and a user name at a MX record (SMTP) or Address-of-Record
	(SIP). Again, there is no possibility that the name on the device		(SIP). Again, there is no possibility that the name on the device
	may "leak out" into the SIP routing network.		may "leak out" into the SIP routing network.
	The most important thing to note about this convention is that the		The most important thing to note about this convention is that the
	left-hand side of the request URI is opaque to the network. The only		left-hand side of the request URI is opaque to the network. The only
	network elements that need to know about the convention are the Media		network elements that need to know about the convention are the Media
	Server and client.		Server and client. Even proxies doing mapping resolution, as in the
			example above for public announcement services, do not need to be
			aware of the convention. The convention is purely a matter of
			provisioning.
	Some have proposed that such naming be a pure matter of local		Some have proposed that such naming be a pure matter of local
	convention. For example, the thesis of the informational RFC3087		convention. For example, the thesis of the informational RFC RFC3087
	[18] is that you can address services using a request URI. However,		[13] is that you can address services using a request URI. However,
	some have taken the examples in the document to an extreme. Namely,		some have taken the examples in the document to an extreme. Namely,
	that the only way to address services is via arbitrary, opaque, long		that the only way to address services is via arbitrary, opaque, long
	user parts. It is possible to provision the service names, rather		user parts. Clearyly, it is possible to provision the service names,
	than fixed names. While this can work in a closed network, where the		rather than fixed names. While this can work in a closed network,
	Application Servers and Media Servers are in the same administrative		where the Application Servers and Media Servers are in the same
	domain, this does not work across domains, such as in the Internet.		administrative domain, this does not work across domains, such as in
	This is because the client of the media service has to know the local		the Internet. This is because the client of the media service has to
	name for each service / domain pair. This is particularly onerous		know the local name for each service / domain pair. This is
	for situations where there is an ad hoc relationship between the		particularly onerous for situations where there is an ad hoc
	application and the media service. Without a well-known relationship		relationship between the application and the media service. Without
	between service and service address, how would the client locate the		a well-known relationship between service and service address, how
	service?		would the client locate the service?
	One very important result of using the user part as the service		One very important result of using the user part as the service
	descriptor is that we can use all of the standard SIP machinery,		descriptor is that we can use all of the standard SIP machinery,
	without modification. For example, Media Servers with different		without modification. For example, Media Servers with different
	capabilities can SIP Register their capabilities as users. For		capabilities can SIP Register their capabilities as users. For
	example, a mixing-only device will register the "conf" user, while a		example, a VoiceXML-only device will register the "dialog" user,
	multi-purpose Media Server will register all of the users. Note that		while a multi-purpose Media Server will register all of the users.
	this is why the URI to play is a parameter. Doing otherwise would		Note that this is why the URI to play is a parameter. Doing
	overburden a normal SIP proxy or redirect server. Conversely, having		otherwise would overburden a normal SIP proxy or redirect server.
	the conference ID being part of the user part gives an indication		Conversely, having the conference ID being part of the user part
	that requests get routed similarly (as opposed to requiring a GRUU,		gives an indication that requests get routed similarly (as opposed to
	which would restrict routing to the same device).		requiring a GRUU, which would restrict routing to the same device).
	Likewise, this scheme lets us leverage the standard SIP proxy		Likewise, this scheme lets us leverage the standard SIP proxy
	behavior of using an intelligent redirect server or proxy server to		behavior of using an intelligent redirect server or proxy server to
	provide high-available services. For example, two Media Servers can		provide high-available services. For example, two Media Servers can
	register with a SIP redirect server for the annc user. If one of the		register with a SIP redirect server for the annc user. If one of the
	Media Servers fails, the registration will expire and all requests		Media Servers fails, the registration will expire and all requests
	for the announcement service ("calls to the annc user") get sent to		for the announcement service ("calls to the annc user") get sent to
	the surviving Media Server.		the surviving Media Server.
	7. Security Considerations		8. Security Considerations
	Exposing network services with well-known addresses may not be		Exposing network services with well-known addresses may not be
	desirable. The Media Server SHOULD authenticate and authorize		desirable. The Media Server SHOULD authenticate and authorize
	requesting endpoints per local policy.		requesting endpoints per local policy.
	Some interactions in this document result in the transfer of		Some interactions in this document result in the transfer of
	confidential information. Moreover, many of the interactions require		confidential information. Moreover, many of the interactions require
	integrity protection. Thus the Media Server MUST implement digest		integrity protection. Thus the Media Server MUST implement the sips:
	authentication for the sip: scheme and MUST implement the sips:
	scheme. In addition, application developers are RECOMMENDED to use		scheme. In addition, application developers are RECOMMENDED to use
	the security services offered by the Media Server to ensure the		the security services offered by the Media Server to ensure the
	integrity and confidentiality of their user's data, as appropriate.		integrity and confidentiality of their user's data, as appropriate.
	Untrusted network elements could use the protocol described here for		Untrusted network elements could use the convention described here
	providing information services. Many extant billing arrangements are		for providing information services. Many extant billing arrangements
	for completed calls. Successful call completion occurs with a 2xx		are for completed calls. Successful call completion occurs with a
	result code. This can be an issue for the early media announcement		2xx result code. This can be an issue for the early media
	service. This is one of the reasons why the early media announcement		announcement service. This is one of the reasons why the early media
	service is deprecated.		announcement service is deprecated.
	Services such as repeating an announcement forever create the		Services such as repeating an announcement forever create the
	possibility for denial of service attacks. The media server SHOULD		possibility for denial of service attacks. The media server SHOULD
	have local policies to deal with this, such as time-limiting how long		have local policies to deal with this, such as time-limiting how long
	"forever" is, analyzing where multiple requests come from,		"forever" is, analyzing where multiple requests come from,
	implementing white-lists for such a service, and so on.		implementing white-lists for such a service, and so on.
	8. Contributors		9. Contributors
	Jeff Van Dyke and Andy Spitzer of SnowShore did just about all of the		Jeff Van Dyke and Andy Spitzer of SnowShore did just about all of the
	work developing netann, in conjunction with many application		work developing netann, in conjunction with many application
	developers, media server manufacturers, and service providers, some		developers, media server manufacturers, and service providers, some
	of whom are listed in the Acknowledgements section. All I did was do		of whom are listed in the Acknowledgements section. All I did was do
	the theory and write it up. That also means all of the mistakes are		the theory and write it up. That also means all of the mistakes are
	mine, as well.		mine, as well.
	9. Acknowledgements		10. Acknowledgements
	We would like to thank Kevin Summers and Ravindra Kabre of Sonus		We would like to thank Kevin Summers and Ravindra Kabre of Sonus
	Networks for their constructive comments, as well as Jonathan		Networks for their constructive comments, as well as Jonathan
	Rosenberg of Dynamicsoft and Tim Melanchuk of Convedia for their		Rosenberg of Dynamicsoft and Tim Melanchuk of Convedia for their
	encouragement. In addition, the discussion at the Las Vegas Interim		encouragement. In addition, the discussion at the Las Vegas Interim
	Workgroup Meeting in 2002 was invaluable for clearing up the issues		Workgroup Meeting in 2002 was invaluable for clearing up the issues
	surrounding the left-hand-side of the request URI. Christer Holmberg		surrounding the left-hand-side of the request URI. Christer Holmberg
	helped tune the language of the multimedia announcement service.		helped tune the language of the multimedia announcement service.
	Orit Levin from Radvision gave a close read on the most recent		Orit Levin from Radvision gave a close read on the most recent
	version of the draft document. Pete Danielsen from Lucent has		version of the draft document. Pete Danielsen from Lucent has
	skipping to change at page 19, line 9 ¶		skipping to change at page 20, line 36 ¶
	versions of this document.		versions of this document.
	Pascal Jalet provided the theoretical underpinning and David Rio		Pascal Jalet provided the theoretical underpinning and David Rio
	provided the experimental evidence for why the conference identifier		provided the experimental evidence for why the conference identifier
	belongs in the user part of the request-URI.		belongs in the user part of the request-URI.
	I am particularly indebted to Alan Johnston for his review of this		I am particularly indebted to Alan Johnston for his review of this
	document and ensuring its conformance with the SIP conference control		document and ensuring its conformance with the SIP conference control
	work in the IETF.		work in the IETF.
			Mary Barnes, as usual, found the holes and showed how to fix them.
	The authors would like to give a special thanks to Walter O'Connor		The authors would like to give a special thanks to Walter O'Connor
	for doing much of the initial implementation.		for doing much of the initial implementation.
	10. References		Note that at the time of this writing, there are 7 known independent
			server implementations that are interoperable with 23 known client
	10.1 Normative References		implementations. Our appologies if we did not count your
			implementation.
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.
	[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.
	[3] Alvestrand, H., "Tags for the Identification of Languages", BCP
	47, RFC 3066, January 2001.
	[4] ISO, "Codes for the representation of names of languages -- Part
	1: Alpha-2 code", ISO 639-1, July 2002.
	[5] ISO, "Codes for the representation of names of countries and		11. References
	their subdivisions -- Part 1: Country codes", ISO 3166-1,
	October 1997.
	[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax		11.1 Normative References
	Specifications: ABNF", RFC 2234, November 1997.
	[7] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail		[1] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
	Extensions) Part One: Mechanisms for Specifying and Describing		Extensions) Part One: Mechanisms for Specifying and Describing
	the Format of Internet Message Bodies", RFC 1521, September		the Format of Internet Message Bodies", RFC 1521, September
	1993.		1993.
	[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Identifiers (URI): Generic Syntax", RFC 2396, August 1998.		Levels", BCP 14, RFC 2119, March 1997.
	[9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional		[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Responses in Session Initiation Protocol (SIP)", RFC 3262, June		Specifications: ABNF", RFC 2234, November 1997.
	2002.
	10.2 Informative References		[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
			Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
	[10] World Wide Web Consortium, "Voice Extensible Markup Language		[5] Alvestrand, H., "Tags for the Identification of Languages",
	(VoiceXML) Version 2.0", W3C Candidate Recommendation ,		BCP 47, RFC 3066, January 2001.
	February 2003,
	<http://www.w3.org/TR/2003/CR-voicexml20-20030220/>.
	[11] Burger, E. and M. Dolly, "Keypad Stimulus Protocol (KPML)",		[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	draft-ietf-sipping-kpml-02 (work in progress), February 2004.		Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
			Session Initiation Protocol", RFC 3261, June 2002.
	[12] Burger, E., Van Dyke, J. and A. Spitzer, "Media Server Control		[7] International Organization for Standardization, "Codes for the
	Markup Language and Protocol", draft-vandyke-mscml-03 (work in		representation of names of languages -- Part 1: Alpha-2 code",
	progress), July 2003.		ISO Standard 639-1, July 2002.
	[13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,		[8] International Organization for Standardization, "Codes for the
	"RTP: A Transport Protocol for Real-Time Applications", RFC		representation of names of countries and their subdivisions --
	1889, January 1996.		Part 1: Country codes", ISO Standard 3166-1, October 1997.
	[14] Rosenberg, J., "A Framework for Conferencing with the Session		11.2 Informative References
	Initiation Protocol",
	draft-ietf-sipping-conferencing-framework-00 (work in
	progress), May 2003.
	[15] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,		[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
	C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC		"RTP: A Transport Protocol for Real-Time Applications",
	3010, December 2000.		RFC 1889, January 1996.
	[16] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.		[10] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
	[17] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April		[11] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
	2001.		2001.
	[18] Campbell, B. and R. Sparks, "Control of Service Context using		[12] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
			C., Eisler, M. and D. Noveck, "NFS version 4 Protocol",
			RFC 3010, December 2000.
			[13] Campbell, B. and R. Sparks, "Control of Service Context using
	SIP Request-URI", RFC 3087, April 2001.		SIP Request-URI", RFC 3087, April 2001.
	[19] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,		[14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
	"SIP: Session Initiation Protocol", RFC 2543, March 1999.		Session Description Protocol (SDP)", RFC 3264, June 2002.
	[20] Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van		[15] Burnett, D., Hunt, A., McGlashan, S., Porter, B., Lucas, B.,
	Wijk, "User Requirements for the Session Initiation Protocol		Ferrans, J., Rehor, K., Carter, J., Danielsen, P. and S.
	(SIP) in Support of Deaf, Hard of Hearing and Speech-impaired		Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version
	Individuals", RFC 3351, August 2002.		2.0", W3C REC REC-voicexml20-20040316, March 2004.
			[16] Van Dyke, J., Burger, E., Ed. and A. Spitzer, "Media Server
			Control Markup Language (MSCML) and Protocol",
			Internet-Draft draft-vandyke-mscml-06, December 2004.
			[17] Rosenberg, J., "A Framework for Conferencing with the Session
			Initiation Protocol",
			Internet-Draft draft-ietf-sipping-conferencing-framework-03,
			October 2004.
	Authors' Addresses		Authors' Addresses
	Eric Burger		Eric Burger
	Brooktrout Technology, Inc.		Brooktrout Technology, Inc.
	18 Keewayding Dr.		18 Keewaydin Dr.
	Salem, NH 03079		Salem, NH 03079
	USA		USA
	EMail: eburger@brooktrout.com		Email: eburger@brooktrout.com
	Jeff Van Dyke		Jeff Van Dyke
	Brooktrout Technology, Inc.		Brooktrout Technology, Inc.
	18 Keewayding Dr.		18 Keewaydin Dr.
	Salem, NH 03079		Salem, NH 03079
	USA		USA
	EMail: jvandyke@brooktrout.com		Email: jvandyke@brooktrout.com
	Andy Spitzer		Andy Spitzer
	Brooktrout Technology, Inc.		Brooktrout Technology, Inc.
	18 Keewayding Dr.		18 Keewaydin Dr.
	Salem, NH 03079		Salem, NH 03079
	USA		USA
	EMail: woof@brooktrout.com		Email: woof@brooktrout.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 22, line 41 ¶		skipping to change at page 23, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 94 change blocks.
	199 lines changed or deleted		257 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/