< draft-rosenberg-sip-call-package-00.txt		draft-rosenberg-sip-call-package-01.txt >
	Internet Engineering Task Force SIP WG		Internet Engineering Task Force SIPPING WG
	Internet Draft Rosenberg,Schulzrinne		Internet Draft J. Rosenberg
	draft-rosenberg-sip-call-package-00.txt dynamicsoft,Columbia U.		dynamicsoft
	July 13, 2001		H. Schulzrinne
	Expires: February 2001		Columbia U.
			draft-rosenberg-sip-call-package-01.txt
			March 1, 2002
			Expires: September 2002
	SIP Event Packages for Call Leg and Conference State		SIP Event Packages for Call Leg and Conference State
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 42 ¶		skipping to change at page 1, line 45 ¶
	Abstract		Abstract
	This document defines two new event packages for the SIP Events		This document defines two new event packages for the SIP Events
	architecture, along with two new data formats used in notifications		architecture, along with two new data formats used in notifications
	for those packages. The first is a call-leg package, and the second		for those packages. The first is a call-leg package, and the second
	is a conference package. The call-leg package allows users to		is a conference package. The call-leg package allows users to
	subscribe to another user, an receive notifications about the changes		subscribe to another user, an receive notifications about the changes
	in state of call legs that the user is involved in. The conference		in state of call legs that the user is involved in. The conference
	package allows users to subscribe to a URL that is associated with a		package allows users to subscribe to a URL that is associated with a
	conference. Notifications are sent about changes in the membership of		conference. Notifications are sent about changes in the membership of
	this conference, changes in active speaker, and floor control		this conference, changes in active speaker, and media mixing
	information. We also define two new SIP headers, To-Replace and To-		information. These general purpose packages can enable many new SIP
	Join, that can be used to convey globally routable join and		services, including single line extension, automatic callback,
	replacement URLS. These general purpose packages and the new headers
	enable many new SIP services. We discuss how they can be used to
	support some of the more challenging services that have been
	discussed, including single line extension, automatic callback,
	unattended consultation-hold transfer, call park and pickup, and IM-		unattended consultation-hold transfer, call park and pickup, and IM-
	a-call.		a-call.
			Table of Contents
			1 Introduction ........................................ 5
			2 Dialog Event Package ................................ 6
			2.1 Event Package Name .................................. 6
			2.2 Event Package Parameters ............................ 6
			2.3 SUBSCRIBE Bodies .................................... 6
			2.4 Subscription Duration ............................... 6
			2.5 NOTIFY Bodies ....................................... 7
			2.6 Notifier Processing of SUBSCRIBE Requests ........... 7
			2.7 Notifier Generation of NOTIFY Requests .............. 8
			2.8 Subscriber Processing of NOTIFY Requests ............ 9
			2.9 Handling of Forked Requests ......................... 9
			2.10 Rate of Notifications ............................... 9
			2.11 State Agents ........................................ 9
			3 Dialog Data Format .................................. 9
			3.1 Structure of Dialog Information ..................... 10
			3.2 Dialog Sub-Elements ................................. 11
			3.2.1 Status .............................................. 12
			3.2.2 Local SDP ........................................... 12
			3.2.3 Remote SDP .......................................... 12
			3.2.4 Route Set ........................................... 13
			3.2.5 Remote Target ....................................... 13
			3.2.6 Local CSeq .......................................... 13
			3.2.7 Remote CSeq ......................................... 14
			4 Conference Event Package ............................ 14
			4.1 Event Package Name .................................. 15
			4.2 Event Package Parameters ............................ 15
			4.3 SUBSCRIBE Bodies .................................... 15
			4.4 Subscription Duration ............................... 15
			4.5 NOTIFY Bodies ....................................... 15
			4.6 Notifier Processing of SUBSCRIBE Requests ........... 16
			4.7 Notifier Generation of NOTIFY Requests .............. 16
			4.8 Subscriber Processing of NOTIFY Requests ............ 16
			4.9 Handling of Forked Requests ......................... 17
			4.10 Rate of Notifications ............................... 17
			4.11 State Agents ........................................ 17
			5 Conference Data Format .............................. 17
			5.1 Structute of the Format ............................. 17
			5.2 User Sub-Elements ................................... 18
			5.3 Example ............................................. 19
			6 Relationship to User Presence ....................... 20
			7 Open Issues and To-Dos .............................. 20
			8 Security Considerations ............................. 20
			9 IANA Considerations ................................. 20
			10 Acknowledgements .................................... 21
			11 Changes since -00 ................................... 21
			12 Authors Addresses ................................... 21
			13 Normative References ................................ 21
			14 Informative References .............................. 22
	1 Introduction		1 Introduction
	The SIP Events architecture [1] defines general mechanisms for		The SIP Events framework [1] defines general mechanisms for
	subscription to, and notification of, events within SIP networks. It		subscription to, and notification of, events within SIP networks. It
	introduces the notion of a package, which is a specific		introduces the notion of a package, which is a specific
	"instantiation" of the events mechanism for a well-defined set of		"instantiation" of the events mechanism for a well-defined set of
	events. Packages have been defined for user presence [2], watcher		events. Packages have been defined for user presence [3], watcher
	information [3], and message waiting indicators [4], amongst others.		information [4], and message waiting indicators [5], amongst others.
	Here, we define two new packages - one for call legs, and the other		Here, we define two new packages - one for dialogs, and the other for
	for conferences.		conferences.
	The need for these packages is driven based on the fact that many		The need for these packages is driven based on the fact that many
	applications are driven off of knowledge about the progress of calls		applications are driven off of knowledge about the progress of
	and conferences. In the case of call legs, we see many potential		dialogs and conferences. In the case of dialogs, we see many
	applications that require knowledge of call-leg state:		potential applications that require knowledge of dialog state:
	Automatic Callback: In this basic PSTN application, user A calls		Automatic Callback: In this basic PSTN application, user A calls
	user B. User B is busy. User A would like to get a callback		user B. User B is busy. User A would like to get a callback
	when user B hangs up. When B hangs up, user A's phone		when user B hangs up. When B hangs up, user A's phone
	rings. When A picks it up, they here ringing, and are being		rings. When A picks it up, they here ringing, and are being
	connected to B. In VoIP, this requires A to receive a		connected to B. In VoIP, this requires A to receive a
	notification when the call-legs at A are complete.		notification when the dialogs at A are complete.
	Presence-Enabled Conferencing: In this application, a user A		Presence-Enabled Conferencing: In this application, a user A
	wishes to set up a conference call with users B and C.		wishes to set up a conference call with users B and C.
	Rather than scheduling it, it is to be created		Rather than scheduling it, it is to be created
	automatically when A, B and C are all available. To do		automatically when A, B and C are all available. To do
	this, the server providing the application would like to		this, the server providing the application would like to
	know whether A, B and C are "online", not idle, and not in		know whether A, B and C are "online", not idle, and not in
	a phone call. Determining whether or not A, B and C are in		a phone call. Determining whether or not A, B and C are in
	calls can be done in two ways. In the first, the server		calls can be done in two ways. In the first, the server
	acts as a call stateful proxy for users A, B and C, and		acts as a call stateful proxy for users A, B and C, and
	therefore knows their call state. This won't always be		therefore knows their call state. This won't always be
	possible, however, and it introduces scalability,		possible, however, and it introduces scalability,
	reliability, and operational complexities. Rather, the		reliability, and operational complexities. Rather, the
	server would subscriber to the call state of those users,		server would subscriber to the dialog state of those users,
	and receive notifications as it changes. This enables the		and receive notifications as it changes. This enables the
	application to be provided in a distributed way; the server		application to be provided in a distributed way; the server
	need not reside in the same domain as the users.		need not reside in the same domain as the users.
	IM Conference Alerts: In this application, a user can get an IM		IM Conference Alerts: In this application, a user can get an IM
	sent to their phone whenever someone joins a conference		sent to their phone whenever someone joins a conference
	that the phone is involved in. The IM alerts are generated		that the phone is involved in. The IM alerts are generated
	by an application separate from the conference server.		by an application separate from the conference server.
	In general, defining call-leg and conference state packages allows		In general, defining dialog and conference state packages allows for
	for construction of distributed applications, where the application		construction of distributed applications, where the application
	requires information on call-leg and conference state, but is not		requires information on dialog and conference state, but is not co-
	co-resident with the end user or conference server. We think this is		resident with the end user or conference server. We think this is a
	a very important piece of the SIP services model.		very important piece of the SIP services model.
	2 Call-Leg Event Package		2 Dialog Event Package
	This section fills in the template that is needed in order to fully		This section provides the details for defining a SIP Events package,
	specify a SIP event package for call-leg state.		as specified by [1].
	2.1 Package Name		2.1 Event Package Name
	The name of this event package is "call-leg". This package name is		The name of this event package is "dialog". This package name is
	carried in the Event and Allow-Events header, as defined in [1].		carried in the Event and Allow-Events header, as defined in [1].
	2.2 SUBSCRIBE Bodies		2.2 Event Package Parameters
	A SUBSCRIBE for a call-leg package MAY contain a body. This body		This package does not define any event package parameters.
			2.3 SUBSCRIBE Bodies
			A SUBSCRIBE for a dialog package MAY contain a body. This body
	defines a filter to apply to the subscription.		defines a filter to apply to the subscription.
	A SUBSCRIBE for a call-leg package MAY be sent without a body. This		A SUBSCRIBE for a dialog package MAY be sent without a body. This
	implies the default subscription filtering policy. The default policy		implies the default subscription filtering policy. The default policy
	is:		is:
	o Notifications are generated every time there is any change in		o Notifications are generated every time there is any change in
	the state of any call legs for the user identified in the		the state of any dialogs for the user identified in the
	request URI of the SUBSCRIBE.		request URI of the SUBSCRIBE.
	o Notifications do not normally contain full state; rather, they		o Notifications do not normally contain full state; rather, they
	only indicate the state of the call-leg whose state has		only indicate the state of the dialog whose state has changed.
	changed. The exception is a NOTIFY sent in response to a		The exception is a NOTIFY sent in response to a SUBSCRIBE.
	SUBSCRIBE. These NOTIFYs contain the complete view of call leg		These NOTIFYs contain the complete view of dialog state.
	state.
	o The notifications contain the identities of the participants		o The notifications contain the identities of the participants
	in the call leg, the call-leg identifiers, and a join URL.		in the dialog, and the dialog identifiers. Additional
	Additional information, such as the route set, CSeq numbers,		information, such as the route set, remote target URI, CSeq
	SDP information, and so on, are not included normally unless		numbers, SDP information, and so on, are not included normally
	explicitly requested.		unless explicitly requested and/or explicitly authorized.
	2.3 Expiration		2.4 Subscription Duration
	Call leg state changes fairly quickly; once established, a typical		Dialog state changes fairly quickly; once established, a typical
	phone call lasts a few minutes (this is different for other session		phone call lasts a few minutes (this is different for other session
	types, of course). However, the interval between new calls is		types, of course). However, the interval between new calls is
	typically infrequent.		typically infrequent.
	We do note that there are two distinct use cases for call leg state.		We do note that there are two distinct use cases for dialog state.
	The first is when a subscriber is interested in the state of a		The first is when a subscriber is interested in the state of a
	specific call leg (and they are authorized to find out about just the		specific dialog (and they are authorized to find out about just the
	state of that call leg). In that case, when the call leg terminates,		state of that dialog). In that case, when the dialog terminates, so
	so too does the subscription. In these cases, the refresh interval		too does the subscription. In these cases, the refresh interval can
	can be very long, since there exists an easy alternative way to		be very long, since there exists an easy alternative way to destroy
	destroy subscription state. As a result, a default of one day for		subscription state. As a result, the default duration of these
	these subscriptions is RECOMMENDED.		subscriptions is one day. The subscriber MAY request other durations.
	In another case, a subscriber is interested in the state of all call		In another case, a subscriber is interested in the state of all call
	legs for a specific user. In these cases, a shorter interval makes		legs for a specific user. In these cases, a shorter interval makes
	more sense. One hour is RECOMMENDED as the default.		more sense. The default is one hour for these subscriptions.
	2.4 NOTIFY Bodies		OPEN ISSUE: We should probably have a single default
			subscription duration.
	The body of the notification contains a call-leg information		2.5 NOTIFY Bodies
	document. The format of this document is described in Section 3. All
	subscibers MUST support this format, and MUST list its type in an
	Accept header in the SUBSCRIBE.
	Other call leg information formats might be defined in the future. In		The body of the notification contains a dialog information document.
			The format of this document is described in Section 3. Its MIME type
			is "application/dialog-info+xml". All subscribers MUST support this
			format, and MUST list its type in any Accept header in the SUBSCRIBE.
			When no Accept header is present in the SUBSCRIBE, its default value
			is "application/dialog-info+xml".
			Other dialog information formats might be defined in the future. In
	that case, the subscriptions MAY indicate support for other formats.		that case, the subscriptions MAY indicate support for other formats.
	However, they MUST always support and list application/call-leg-		However, they MUST always support and list "application/dialog-
	info+xml as an allowed format.		info+xml" as an allowed format.
	Of course, the notifications generated by the server MUST be in one		Of course, the notifications generated by the server MUST be in one
	of the formats specified in the Accept header in the SUBSCRIBE		of the formats specified in the Accept header in the SUBSCRIBE
	request.		request.
	2.5 Authorization Considerations		2.6 Notifier Processing of SUBSCRIBE Requests
	The call-leg information for a user contains very sensitive		The dialog information for a user contains very sensitive
	information. Therefore, all subscriptions SHOULD be authenticated and		information. Therefore, all subscriptions SHOULD be authenticated and
	then authorized before approval. Authorization policy is at the		then authorized before approval. Authorization policy is at the
	discretion of the administrator, as always. However, a few		discretion of the administrator, as always. However, a few
	recommendations can be made.		recommendations can be made.
	It is RECOMMENDED that if the policy of a user is that A is called to		It is RECOMMENDED that if the policy of a user is that A is allowed
	call them, subscriptions from user A be allowed. However, the		to call them, dialog subscriptions from user A be allowed. However,
	information provided in the notifications does not contain any call		the information provided in the notifications does not contain any
	leg identification information; merely an indication of whether the		dialog identification information; merely an indication of whether
	user in in one or more calls, or not. Specifically, they should not		the user in in one or more calls, or not. Specifically, they should
	be able to find out any more information than if they sent an INVITE.		not be able to find out any more information than if they sent an
			INVITE.
	It is RECOMMENDED that if a user agent registers with the address-		It is RECOMMENDED that if a user agent registers with the address-
	of-record X, that this user agent authorize subscriptions that come		of-record X, that this user agent authorize subscriptions that come
	from any entity that can authenticate itself as X. Complete		from any entity that can authenticate itself as X. Complete
	information on the call leg state SHOULD be sent in this case. This		information on the dialog state SHOULD be sent in this case. This
	authorization behavior allows a group of devices representing a		authorization behavior allows a group of devices representing a
	single user to all become aware of each other's state.		single user to all become aware of each other's state. This is useful
			for applications such as single-line-extension.
	2.6 Generation of Notifications		2.7 Notifier Generation of NOTIFY Requests
	Notifications are generated for the call-leg package when a new		Notifications are generated for the dialog package when a new dialog
	call-leg comes into existence at a UA, or when the state of an		comes into existence at a UA, or when the state of an existing dialog
	existing call leg changes.		changes.
	For the purposes of this package, we define the states of a call leg		For the purposes of this package, we define the states of a dialog
	through numeric codes. These codes are equivalent to the most recent		through numeric codes. These codes are equivalent to the most recent
	SIP status codes sent in response to the INVITE which created the		SIP status codes sent in response to the INVITE which created the
	call leg. The status code "0" is reserved for the case where no		call leg. The status code "0" is reserved for the case where no
	response has yet been received or sent.		response has yet been received or sent.
	When a UAC initially creates an INVITE to establish a call, this		When a UAC initially creates an INVITE to establish a call, this
	causes a change to state "0". When it receives the first non-100		causes a change to state "0". When it receives the first non-100
	provisional response, the state changes to the value of that status		provisional response, the state changes to the value of that status
	code. Any further provisional responses cause the UA to change state		code. Any further provisional responses cause the UA to change state
	to the value of that status code. When a final response is received,		to the value of that status code. When a final response is received,
	the state changes to the value of that response. If the response was		the state changes to the value of that response. If the response was
	a non-200, the call-leg is considered terminated, and no further		a non-200, the dialog is considered terminated, and no further state
	state changes are possible. Multiple 2xx responses received create		changes are possible. Multiple 2xx responses received create
	additional call legs, each with the state of that specific 2xx.		additional dialogs, each with the state of that specific 2xx.
	When a UAS initially receives an INVITE to establish a call, this		When a UAS initially receives an INVITE to establish a call, this
	causes a change to the state of the provisional response which was		causes a change to the state of the provisional response which was
	sent. Any subequent provisional responses cause a change in state to		sent. Any subequent provisional responses cause a change in state to
	the value of that response. A final response causes a transition in		the value of that response. A final response causes a transition in
	state to that response code. There is no change in state when the ACK		state to that response code. There is no change in state when the ACK
	arrives. However, if no ACK is received, and the UAS destroys the		arrives. However, if no ACK is received, and the UAS destroys the
	call, the state changes to a value of -1.		call, the state changes to a value of -1.
	When the call is terminated as a result of a BYE, the state changes		When the call is terminated as a result of a BYE, the state changes
	to -1.		to -1.
	OPEN ISSUE: This is kind of ugly. We could alternately		OPEN ISSUE: This is kind of ugly. We could alternately
	define a more formal state machine.		define a more formal state machine.
	2.7 Rate Limitations on NOTIFY		2.8 Subscriber Processing of NOTIFY Requests
			The SIP Events framework expects packages to specify how a subscriber
			processes NOTIFY requests in any package specific ways, and in
			particular, how it uses the NOTIFY requests to contruct a coherent
			view of the state of the subscribed resource.
			Typically, the NOTIFY for the dialog package will only contain
			information about those dialogs whose state has changed. To construct
			a coherent view of the total state of all dialogs, a subscriber to
			the dialog package will need to combine NOTIFYs received over time.
			The subscriber maintains is complete dialog list in a table, indexed
			by the id. This ID is different from the formal dialog ID as defined
			in [2], which is the concatenation of the local tag, remote tag, and
			Call-Id. This ID is conveyed in the id attribute of the dialog
			element of the "application/dialog-info+xml" type. If the dialog
			information in a NOTIFY has a dialog listed with an ID not in the
			table, an entry is added to that table. The version number from the
			dialog element is also extracted, and placed in the table. If the
			dialog information in a NOTIFY has a dialog listed with an ID in the
			table, and the version in the NOTIFY is greater than the version
			stored in the table, the dialog information in the table for that
			dialog is updated, including the version number. If a dialog is
			updated such that its status is now "-1", that entry MAY be removed
			from the table at any time.
			2.9 Handling of Forked Requests
			A forked SUBSCRIBE request for dialog state can install multiple
			subscriptions. Subscribers to this package MUST be prepared to
			install subscription state for each NOTIFY generated as a result of a
			single SUBSCRIBE.
			2.10 Rate of Notifications
	For reasons of congestion control, it is important that the rate of		For reasons of congestion control, it is important that the rate of
	notifications not become excessive. As a result, it is RECOMMENDED		notifications not become excessive. As a result, it is RECOMMENDED
	that the server not generate notifications for a single subscriber at		that the server not generate notifications for a single subscriber at
	a rate faster than once every 5 seconds.		a rate faster than once every 5 seconds.
	3 Call-Leg Data Format		2.11 State Agents
	We specify an XML-based data format to describe the state of call
	legs. The MIME type for this format is application/call-leg-info+xml,
	consistent with the recommendations provided in RFC 3023 [5].
	3.1 Structure of Call Leg Information		Dialog state is ideally maintained in the user agents in which the
			dialog resides. Therefore, the elements that maintain the dialog are
			the ones best suited to handle subscriptions to it. Therefore, the
			usage of state agents is NOT RECOMMENDED for this package.
	A call-leg-info document starts with a user tag that identitifies the		3 Dialog Data Format
	user. Within that tag are a series of call-leg tags. Each of those		We specify an XML-based data format to describe the state of a
	use attributes to identify the call leg, using the local and remote		dialog. The MIME type for this format is "application/dialog-
	URIs, local and remote tags, and the Call-ID. Within the call leg		info+xml", consistent with the recommendations provided in RFC 3023
	tags are a single mandatory tag which contains the status, followed		[6].
	by a series of optional tags that contain additional information
	about the call leg. There is also an optional tag called join, which		3.1 Structure of Dialog Information
	contains a URL that can be used to join the conference associated
	with the call leg (and if there is none, one is created). There is		A dialog-info document starts with a user tag that identitifies the
	another pair of optional tags called replace-local and replace-		user. Within that tag are a series of dialog tags. Each of those use
	remote, which contain a URL to use that can replace the specific call		attributes to identify the dialog and provide its version number.
	leg at either side.		There are also attributes to provide the formal dialog identifier,
			using the local and remote tags, and the Call-ID. Additional
			attributes are present to specify the local and remote URIs. There is
			also an attribute that indicates whether the user initiated this
			dialog or not. Within the dialog tags are a single mandatory tag
			which contains the status, followed by a series of optional tags that
			contain additional information about the dialog.
	The top level tag is user:		The top level tag is user:
	<!ELEMENT user (call-leg*)>		<!ELEMENT user (dialog*)>
	<!ATTLIST user uri CDATA #REQUIRED>		<!ATTLIST user uri CDATA #REQUIRED>
	The mandatory uri attribute is the identifier of the user whose		The mandatory uri attribute is the identifier of the user whose
	call-leg state is being reported.		dialog state is being reported.
	What follows is a series of call-leg tags:		What follows is a series of dialog tags:
	<!ELEMENT call-leg (status,join?,replace-local?,replace-remote?,		<!ELEMENT dialog (status,local-sdp?,remote-sdp?,
	local-sdp?,remote-sdp?,		route-set?,remote-target?,local-cseq?,remote-cseq?)
	route-set?,local-cseq?,remote-cseq?>		<!ATTLIST dialog id CDATA #REQUIRED
	<!ATTLIST call-leg call-id CDATA #IMPLIED		version CDATA #REQUIRED
			call-id CDATA #IMPLIED
	local-uri CDATA #IMPLIED		local-uri CDATA #IMPLIED
	local-tag CDATA #IMPLIED		local-tag CDATA #IMPLIED
	remote-uri CDATA #IMPLIED		remote-uri CDATA #IMPLIED
	remote-tag CDATA #IMPLIED>		remote-tag CDATA #IMPLIED
			direction (iniatiator|recipient) #IMPLIED>
	The local-uri and local-tag specify the URL and tag placed in the		The local-uri, local-tag, remote-uri, remote-tag and call-id
	From field of outgoing INVITEs, and present in the From field of		attributes convey their corresponding components of the dialog state
	incoming INVITEs. The remote-uri and remote-tag specify the URL and		as defined in [2]. The direction attribute is "initiator" if the user
	tag placed in the To field of outgoing INVITEs, and present in the		initiated this dialog, and "recipient" if it did not. The remote tag
	From field of incoming INVITEs. The call-id is the Call-ID for the		attribute won't be present if there is only a "half-dialog",
	leg. The tag attributes are not present if the tag is not specified		resulting from generation of a request that can create a dialog.
	(or not yet specified).
	For example, if a UAC sends an INVITE that looks like, in part:		For example, if a UAC sends an INVITE that looks like, in part:
	INVITE sip:callee@foo.com SIP/2.0		INVITE sip:callee@foo.com SIP/2.0
	From: sip:caller@bar.com;tag=123		From: sip:caller@bar.com;tag=123
	To: sip:callee@foo.com		To: sip:callee@foo.com
	Call-ID: 987@1.2.3.4		Call-ID: 987@1.2.3.4
	the call-leg tag sent out in a notification might looks like:		the dialog tag sent out in a notification might looks like:
	<call-leg call-id="987@1.2.3.4" local-uri="sip:caller@bar.com"		<dialog id="as7d900as8" version="0" call-id="987@1.2.3.4"
	local-tag="123" remote-uri="sip:callee@foo.com">		local-uri="sip:caller@bar.com"
			local-tag="123" remote-uri="sip:callee@foo.com"
			direction="initiator">
	If a 200 OK is received, which looks like, in part:		If a 200 OK is received, which looks like, in part:
	INVITE sip:callee@foo.com SIP/2.0		SIP/2.0 200 OK
	From: sip:caller@bar.com;tag=123		From: sip:caller@bar.com;tag=123
	To: sip:callee@foo.com;tag=abc		To: sip:callee@foo.com;tag=abc
	Call-ID: 987@1.2.3.4		Call-ID: 987@1.2.3.4
	The call-leg ID is now complete, and the notification sent out will		The dialog is now confirmed, and the notification sent out will have
	have a call-leg tag which looks like:		a dialog tag which looks like:
	<call-leg call-id="987@1.2.3.4" local-uri="sip:caller@bar.com"		<dialog id="as7d900as8" version="0" call-id="987@1.2.3.4"
	local-tag="123" remote-uri="sip:callee@foo.com" remote-tag="abc">		local-uri="sip:caller@bar.com"
			local-tag="123" remote-uri="sip:callee@foo.com"
			remote-tag="abc" direction="initiator">
	3.2 Call Leg Subtags		3.2 Dialog Sub-Elements
	There are many subtags defined for the call-leg.		There are many sub-elements defined for the dialog element.
	3.2.1 Status		3.2.1 Status
	The only mandatory subtag of call-leg is status.		The only mandatory sub-element of dialog is status.
	<!ELEMENT status CDATA>		<!ELEMENT status CDATA>
	<!ATTLIST status code CDATA #REQUIRED>		<!ATTLIST status code CDATA #REQUIRED>
	The mandatory code attribute contains the status code. This is the		The mandatory code attribute contains the status code. This is the
	SIP response code last sent or received for this leg in the initial		SIP response code last sent or received for this leg in the initial
	INVITE that established the leg. If no response has been sent or		INVITE that established the leg. If no response has been sent or
	received, the value of zero is used. If the call ends, a value of -1		received, the value of zero is used. If the call ends, a value of -1
	is used.		is used.
	The value within the status tag is a textual phrase that can be		The value within the status tag is a textual phrase that can be
	rendered to described call status. The reason phrase from the		rendered to described call status. The reason phrase from the
	response is RECOMMENDED.		response is RECOMMENDED.
	Example:		Example:
	<status code="180">Ringing</status>		<status code="180">Ringing</status>
	3.2.2 Join		3.2.2 Local SDP
	The optional join tag provides a URL that can be used to join any
	conference associated with the call-leg. When the notifier receives
	an INVITE with this URL, it MUST treat that as a request to join the
	conference. The notifier can use any method to create the conference
	call, if it doesn't already exist. Several approaches are described
	in [6]. The format of the URL is at the discretion of the notifier.
	It is RECOMMENDED that it be structured so that the notifier can
	associate it with the specific call leg. As with any other
	invitiations, an INVITE received with this URL SHOULD be
	authenticated.
	The URL MUST be globally routable.
	OPEN ISSUE: Tall order. This means UAs will need a way to
	generate URLs which they know are globally routable to
	them.
	<!ELEMENT join >
	<!ATTLIST join uri CDATA #REQUIRED>
	Clearly, the notifier SHOULD only insert this tag if it can execute a
	multi-party conference call for the user.
	3.2.3 Replace Tags
	The optional replace-local and replace-remote tags provide URLs that
	can be used to replace the given call leg at either side. In other
	words, if A are B are in a call, and A generated a NOTIFY with a
	replace-local and replace-remote tag, the replace-local URL would get
	routed to A, and replace the call leg with B. The replace-remote URL
	would get routed to B, and replace the call leg with A.
	Replacement means that the new call leg is silently accepted, and a
	BYE is sent on the old call leg.
	<!ELEMENT replace-local >
	<!ELEMENT replace-remote >
	<!ATTLIST replace-local uri CDATA #REQUIRED>
	<!ATTLIST replace-remote uri CDATA #REQUIRED>
	This has the very interesting implication of removing the
	need for a separate Replaces header. Instead, the URI
	itself would indicate to the UA that a replaces for a
	specific call leg is desired. This is very much in the
	spirit of the web, and of RFC 3087 [7], where URLs are
	almost always server generated, and the semantics of the
	URL have meaning only within the context of the server that
	created them.
	Clearly, the notifier SHOULD only insert this tag if it can execute
	the call replacement.
	3.2.4 Discussion on Join and Replaces
	The inclusion of the join and replace tags merits discussion.
	Do we really need join and replaces as part of this specification? We
	could instead define a Join header, and revive the Replaces header
	draft. That has the benefit of being explicit. The benefit of the
	approach here is that we get to define a totally different URL. By
	making it globally routable, we fix the "unassisted transfer with
	consultation hold" problem [8]. Specifically, this transfer variant
	is hard since the transferor needs to pass, in the Refer-To header, a
	globally routable URL that reaches the specific UA that is the
	transfer target. Neither the Contact nor the To/From have this
	property. But, by defining a specific URL just for the purposes of
	replacement, we can, by definition, make it globally routable to the
	UA which generated it. That seems very, very useful. It means that,
	unlike Contact and To/From, this URL can be emailed, IM'd, REFERed,
	placed in html, or whatever, and it is guaranteed to get to the right
	place and do the right thing. Furthermore, by generating the URLs for
	each call, the notifier can embed information into the URLs for
	cookie functionality. Finally, using a separate URL means the join or
	replace requests can go to different hosts that the ones owning the
	call leg. Not sure if this is useful, though.
	The replace-remote URL can only be known to a notifier for call-leg
	events if its received from the other party in the call-leg in the
	INVITE or 200 OK. As such, we would also propose a To-Join and To-
	Replace header, which is present in either INVITE or 200 OK. It
	contains a URL that can be used to replace the call leg for each
	respective side. Putting them both in a NOTIFY means that other
	entities besides the participants in a call can get at them, which is
	possibly useful (operator barge-in, for example).
	Its worth observing that currently, there is an asymmetry between the
	way one joins a conference, and the way one replaces a call leg. To
	join a conference call, we have agreed that one sends an INVITE to a
	URL on a conference server which interprets that URL to mean "mix me
	into the call with everyone else that has used the same URL". This is
	exactly consistent with the approach here for joining. However, we
	have defined an explicit Replaces header. Why the difference? We
	should either have both a Join and Replaces header, or neither.
	Indeed, there is a problem right now with ad-hoc conferences that is
	related to the proposal here. Lets say A clicks a URL in a web page
	that says "click here to call". This results in some call being
	placed to B. At some point during the call, A decides to add another
	party, C. According to the multiparty conferencing models draft [6],
	A would obtain a URL for a conference server, and REFER B to that
	server. However, this is totally unneeded (and bad), if B is already
	a conference server! Indeed, A has no way, right now, of
	ascertaining whether that URL in the web page is for a single user,
	or to a conference server that automatically dials out to B. In one
	case (where its a user), A would need to obtain a conference URL, and
	REFER B to it. In the other, A could directly REFER C to the URL it
	used to call B.
	The problem is solved when we stop making assumptions about the
	semantics of the URL. URLs should ideally be handed to a user, either
	through interpersonal contact (i.e., on a business card), or through
	a transmission mechanism that defines a specific usage for those
	URLs. In the above scenario, if A wants to add C, A should not make
	any assumptions about whether the URL to call B can be used for
	adding users to a conference. Only B can know this. So, A needs to
	ask B what URL to use to join. That can be done using the
	SUBSCRIBE/NOTIFY mechanisms here (although this is a lot of overhead;
	these URLs could be passed directly in the INVITE and 200 OK). B
	would then provide the URL, which would be the same URL used to call
	it in the case of a dial-out conference server, or a new URL obtained
	by B, pointing to a conference server, if B was for an end user that
	didn't want to do endpoint mixing. Indeed, many different URLs could
	be used, and B is the ideal party to decide.
	3.2.5 Local SDP
	The local SDP tag contains the SDP used by the notifier for its end		The local SDP tag contains the SDP used by the notifier for its end
	of the call leg. This tag should generally NOT be included in the		of the dialog. This tag should generally NOT be included in the
	notifications, unless explicitly requested by the subscriber.		notifications, unless explicitly requested by the subscriber.
	<!ELEMENT local-sdp CDATA>		<!ELEMENT local-sdp CDATA>
	The SDP is included, verbatim, between the tags.		The SDP is included, verbatim, between the tags.
	3.2.6 Remote SDP		3.2.3 Remote SDP
	The remote SDP tag contains the SDP used by the notifier for the		The remote SDP tag contains the SDP used by the notifier for the
	other end of the call leg. This tag should generally NOT be included		other end of the dialog. This tag should generally NOT be included in
	in the notifications, unless explicitly requested by the subscriber.		the notifications, unless explicitly requested by the subscriber.
	<!ELEMENT remote-sdp CDATA>		<!ELEMENT remote-sdp CDATA>
	The SDP is included, verbatim, between the tags.		The SDP is included, verbatim, between the tags.
	3.2.7 Route Set		3.2.4 Route Set
	The route-set tag contains the route set, as defined in RFC 2543bis		The route-set tag contains the route set as constructed by the user
	[9]. It is the combination of the Record-Route and Contact headers		agent for this dialog, as defined in RFC BBBB [2]. It is constructed
	used for this call leg. This tag should generally NOT be included in		from the Record-Route header field used for this dialog. This tag
	the notifications, unless explicitly requested by the subscriber.		should generally NOT be included in the notifications, unless
			explicitly requested by the subscriber.
	<!ELEMENT route-set CDATA>		<!ELEMENT route-set CDATA>
	The route set is included verbatim. It is structured as a comma		The route set is included verbatim. It is structured as a comma
	separated list of URLs.		separated list of URLs.
	Example:		Example:
	<route-set>sip:user@host,sip:user@proxy</route-set>		<route-set>sip:proxy2.example.com;lr</route-set>
	3.2.8 Local CSeq		3.2.5 Remote Target
			The remote-target contains the remote-target URI as constructed by
			the user agent for this dialog, as defined in RFC BBBB [2]. It is
			constructed from the Contact header of the INVITE. This tag should
			generally not be included in notifications, unless explicitly
			requested by the subscriber.
			<!ELEMENT remote-target CDATA>
			The remote target URI is included verbatim between the tags.
			Example:
			<remote-target>sip:user@pc33.example.com</remote-target>
			3.2.6 Local CSeq
	The local-cseq tag contains the most recent value of the CSeq header		The local-cseq tag contains the most recent value of the CSeq header
	used by the UA in an outgoing request on the call leg. This tag		used by the UA in an outgoing request on the dialog. This tag should
	should generally NOT be included in the notifications, unless		generally NOT be included in the notifications, unless explicitly
	explicitly requested by the subscriber.		requested by the subscriber.
	<!ELEMENT local-cseq CDATA>		<!ELEMENT local-cseq CDATA>
	The numeric value of the CSeq is included as the CDATA.		The numeric value of the CSeq is included as the CDATA.
	3.2.9 Remote CSeq		3.2.7 Remote CSeq
	The remote-cseq tag contains the most recent value of the CSeq header		The remote-cseq tag contains the most recent value of the CSeq header
	seen by the UA in an incoming request on the call leg. This tag		seen by the UA in an incoming request on the dialog. This tag should
	should generally NOT be included in the notifications, unless		generally NOT be included in the notifications, unless explicitly
	explicitly requested by the subscriber.		requested by the subscriber.
	<!ELEMENT remote-cseq CDATA>		<!ELEMENT remote-cseq CDATA>
	The numeric value of the CSeq is included as the CDATA.		The numeric value of the CSeq is included as the CDATA.
	4 Conference Event Package		4 Conference Event Package
	The conference event package allows a user to subscribe to a		The conference event package allows a user to subscribe to a
	conference. A conference is a collection of users that are all able		conference. A conference is a collection of users that are all able
	to communicate with each other. Generally, when multicast is not		to communicate with each other. Generally, when multicast is not
	used, a conference is associated by a set of call legs that have		used, a conference is associated by a set of dialogs that have their
	their media mixed together. This is true for all of the non-multicast		media mixed together. This is true for all of the non-multicast
	models in [6]. However, some of the models use topologies where there		models in [7]. However, some of the models use topologies where there
	is no root to which all call-legs are connected. These topologies do		is no root to which all dialogs are connected. These topologies do
	not work well with the mechanism here.		not work well with the mechanism here.
	This package allows a user to subscribe to a conference, identified		This package allows a user to subscribe to a conference, identified
	by a SIP URL. Ideally, this SIP URL routes the SUBSCRIBE to the		by a SIP URI. Ideally, this SIP URI routes the SUBSCRIBE to the
	entity acting as the root of the topology (which is why it doesn't		entity acting as the root of the topology (which is why it doesn't
	work well for the non-centralized topologies). The notifications		work well for the non-centralized topologies). The notifications
	contain information on the participants in the conference. The		contain information on the participants in the conference. The
	specific information conveyed is:		specific information conveyed is:
	o The SIP URL identifying the user.		o The SIP URI identifying the user.
	o Their status in the conference (active, declined, departed).		o The dialog state associated with that users attachment to the
			conference.
	o The replace URLs for the call leg connecting to that user.		o Their status in the conference (active, declined, departed).
	o If floor control policies are in place, what the user's floor		o Their status in terms of receiving media in the conference.
	control status is.
	This section fills in the template that is needed in order to fully		This section provides the details for defining a SIP Events package,
	specify the SIP event package for conferences.		as specified by [1].
	4.1 Package Name		4.1 Event Package Name
	The name of this event package is "conference". This package name is		The name of this event package is "conference". This package name is
	carried in the Event and Allow-Events header, as defined in [1].		carried in the Event and Allow-Events header, as defined in [1].
	4.2 SUBSCRIBE Bodies		4.2 Event Package Parameters
	A SUBSCRIBE for a call-leg package MAY contain a body. This body		This event package does not define any event package parameters.
			4.3 SUBSCRIBE Bodies
			A SUBSCRIBE for a dialog package MAY contain a body. This body
	defines a filter to apply to the subscription.		defines a filter to apply to the subscription.
	A SUBSCRIBE for a conference package MAY be sent without a body. This		A SUBSCRIBE for a conference package MAY be sent without a body. This
	implies the default subscription filtering policy. The default policy		implies the default subscription filtering policy. The default policy
	is:		is:
	o Notifications are generated every time there is any change in		o Notifications are generated every time there is any change in
	the set of users participating in the conference, or a change		the set of users participating in the conference, or a change
	in floor control status (assuming floor control is in use).		their state (dialog state, media mixing state, etc.)
	o Notifications do not normally contain full state; rather, they		o Notifications do not normally contain full state; rather, they
	only indicate the state of the participant whose state has		only indicate the state of the participant whose state has
	changed. The exception is a NOTIFY sent in response to a		changed. The exception is a NOTIFY sent in response to a
	SUBSCRIBE. These NOTIFYs contain the complete view of		SUBSCRIBE. These NOTIFYs contain the complete view of
	conference state.		conference state.
	o For a given user, the notifications contain the identity		o For a given user, the notifications contain the identity
	information, status, and replace URLs. The floor control		information and status.
	information is not provided unless explicitly requested.
			4.4 Subscription Duration
	4.3 Expiration
	The default expiration time for a subscription to a conference is one		The default expiration time for a subscription to a conference is one
	hour. Of course, once the conference ends, all subscriptions to that		hour. Of course, once the conference ends, all subscriptions to that
	particular conference are terminated.		particular conference are terminated, with a reason of "noresource"
			[1].
	4.4 NOTIFY Bodies		4.5 NOTIFY Bodies
	The body of the notification contains a conference information		The body of the notification contains a conference information
	document. The format of this document is described in Section 5. All		document. The format of this document is described in Section 5. Its
	subscibers MUST support this format, and MUST list its type in an		MIME type is "application/conference-info+xml". All subscibers MUST
	Accept header in the SUBSCRIBE.		support this format, and MUST list its type in an Accept header in
			the SUBSCRIBE. The default value for the Accept header when it is not
			present in a request is "application/conference-info+xml".
	Other conference information formats might be defined in the future.		Other conference information formats might be defined in the future.
	In that case, the subscriptions MAY indicate support for other		In that case, the subscriptions MAY indicate support for other
	formats. However, they MUST always support and list		formats. However, they MUST always support and list
	application/conference-info+xml as an allowed format.		"application/conference-info+xml" as an allowed format.
	Of course, the notifications generated by the server MUST be in one		Of course, the notifications generated by the server MUST be in one
	of the formats specified in the Accept header in the SUBSCRIBE		of the formats specified in the Accept header in the SUBSCRIBE
	request.		request.
	4.5 Authorization Considerations		4.6 Notifier Processing of SUBSCRIBE Requests
	The conference information contains very sensitive information.		The conference information contains very sensitive information.
	Therefore, all subscriptions SHOULD be authenticated and then		Therefore, all subscriptions SHOULD be authenticated and then
	authorized before approval. Authorization policy is at the discretion		authorized before approval. Authorization policy is at the discretion
	of the administrator, as always. However, a few recommendations can		of the administrator, as always. However, a few recommendations can
	be made.		be made.
	It is RECOMMENDED that all users in the conference be allowed to		It is RECOMMENDED that all users in the conference be allowed to
	subscribe to the conference.		subscribe to the conference.
	4.6 Generation of Notifications		4.7 Notifier Generation of NOTIFY Requests
	Notifications are generated for the conference whenever a new		Notifications SHOULD be generated for the conference whenever a new
	participant joins, a participant leaves, a dial-out attempt succeeds		participant joins, a participant leaves, and a dial-out attempt
	or fails, floor control status changes, or the call leg replace URLs		succeeds or fails. Notifications MAY be generated for the conference
	change.		whenever the media mixing status of a user changes.
	4.7 Rate Limitations on NOTIFY		4.8 Subscriber Processing of NOTIFY Requests
			The SIP Events framework expects packages to specify how a subscriber
			processes NOTIFY requests in any package specific ways, and in
			particular, how it uses the NOTIFY requests to contruct a coherent
			view of the state of the subscribed resource.
			Typically, the NOTIFY for the conference package will only contain
			information about those users whose state has changed. To construct a
			coherent view of the total state of the entire conference, a
			subscriber to the conference package will need to combine NOTIFYs
			received over time. The subscriber maintains is complete user list in
			a table, indexed by the id in the dialog element. If the dialog
			information in a NOTIFY has a dialog listed with an ID not in the
			table, an entry is added to that table. The version number from the
			dialog element is also extracted, and placed in the table. If the
			dialog information in a NOTIFY has a dialog listed with an ID in the
			table, and the version in the NOTIFY is greater than the version
			stored in the table, the dialog information in the table for that
			dialog is updated, including the version number. If a dialog is
			updated such that its status is now "-1", that entry MAY be removed
			from the table at any time.
			4.9 Handling of Forked Requests
			By their nature, the conferences supported by this package are
			centralized. Therefore, SUBSCRIBE requests for a conference should
			not generally fork. Users of this package MUST NOT install more than
			a single subscription as a result of a single SUBSCRIBE request.
			4.10 Rate of Notifications
	For reasons of congestion control, it is important that the rate of		For reasons of congestion control, it is important that the rate of
	notifications not become excessive. As a result, it is RECOMMENDED		notifications not become excessive. As a result, it is RECOMMENDED
	that the server not generate notifications for a single subscriber at		that the server not generate notifications for a single subscriber at
	a rate faster than once every 5 seconds.		a rate faster than once every 5 seconds.
			4.11 State Agents
			Conference state is ideally maintained in the element in which the
			conference resides. Therefore, the elements that maintain the
			conference are the ones best suited to handle subscriptions to it.
			Therefore, the usage of state agents is NOT RECOMMENDED for this
			package.
	5 Conference Data Format		5 Conference Data Format
	The conference data format is an XML document of MIME type		The conference data format is an XML document of MIME type
	application/conference-info+xml, consistent with the recommendations		"application/conference-info+xml", consistent with the
	provided in RFC 3023 [5].		recommendations provided in RFC 3023 [6].
	5.1 Structute of the Format		5.1 Structute of the Format
	The conference data format has the top level tag of conference. It		The conference data format has the top level tag of conference. It
	consists of a set of sub-tags of type user, which contain information		consists of a set of sub-tags of type user, which contain information
	on the users in the conference. Each user tag contains the identity		on the users in the conference. Each user tag contains the identity
	of the user, their status, their replace URL, and their floor control		of the user, their dialog information, their status in the
	status.		conference, and their media reception information.
	The top level tag is conference:		The top level tag is conference:
	<!ELEMENT conference (user*)>		<!ELEMENT conference (user*)>
	<!ATTLIST conference uri CDATA #REQUIRED>		<!ATTLIST conference uri CDATA #REQUIRED>
	The mandatory uri attribute contains the URL used to join the		The mandatory uri attribute contains the URI used to join the
	conference call (and to subscribe to its state).		conference call (and to subscribe to its state).
	What follows are a series of user tags:		What follows are a series of user tags:
	<!ELEMENT user (status,replace?,floor-status?)>		<!ELEMENT user (status,dialog,media-status?)>
	<!ATTLIST user uri CDATA #REQUIRED		<!ATTLIST user uri CDATA #REQUIRED
	name CDATA #IMPLIED>		name CDATA #IMPLIED>
	The uri attribute contains the URL for the user. This is a logical		The uri attribute contains the URI for the user. This is a logical
	identifier, not a machine specific one (i.e., its taken from the		identifier, not a machine specific one (i.e., its taken from the
	To/From, not the Contact). The name is a textual name for rendering		To/From, not the Contact). The name is a textual name for rendering
	to a human. It is ususally taken from the display name.		to a human. It is ususally taken from the display name.
	5.2 User Sub-Elements		5.2 User Sub-Elements
	The sub-elements of the user tag are status, replace, and floor-		The sub-elements of the user tag are status, dialog aned media-
	status.		status.
	Status contains the status of the user in the conference.		Status contains the status of the user in the conference.
	<!ELEMENT status>		<!ELEMENT status>
	<!ATTLIST status		<!ATTLIST status
	value (active|departed|booted|failed) "active" >		value (active|departed|booted|failed) "active" >
	The statuses have the following meaning:		The statuses have the following meaning:
	active: The user is in an active call leg with the conference		active: The user is in an active dialog with the conference
	host.		host.
	departed: The user sent a BYE, thus leaving the conference.		departed: The user sent a BYE, thus leaving the conference.
	booted: The user was sent a BYE by the conference host, booting		booted: The user was sent a BYE by the conference host, booting
	them out of the conference.		them out of the conference.
	failed: The conference host is a dialout conference server, and		failed: The conference host is a dialout conference server, and
	its attempt to contact the specific user resulted in a		its attempt to contact the specific user resulted in a
	non-200 class final response.		non-200 class final response.
	The replace URL is the same replace-remote URL defined for the call		The dialog element is the same one from the dialog package above.
	leg package above. It is exposed through the conference server, so
	that subscribers have, if authorized, the ability to pull a user out
	of the conference.
	OPEN ISSUE: Do we really want or need this? The only real
	use I found was to back out of a centralized conference
	server, to a point-to-point call, when only two users
	remain. Is this sufficient need? Other uses?
	<!ELEMENT replace>
	<!ATTLIST url CDATA #IMPLIED>
	The floor-status contains the status of the user as far as floor
	control is concerned.
	<!ELEMENT floor-status>
	<!ATTLIST status
	value (owner|non-owner|chair) "non-owner" >
	The values have the following meaning:
	owner: The user has floor control.
	non-owner: The user does not have floor control.		The media-status attribute is a series of media streams. Each media
			stream is associated with a media type, a sending status, and a
			receiving status.
	chair: The user is the chair, and is the one who controls who		<!ELEMENT media-status (media-stream*)>
	gets floor control.		<!ELEMENT media-stream>
			<!ATTLIST media-stream
			type (audio|video|message|application) #REQUIRED
			send-status (received-by-all|muted) "received-by-all"
			recv-status (receiving-all|anchor-only) "receiving-all">
	OPEN ISSUE: Does this belong here? If we have a separate		If the send-status is "received-by-all", it means that the media for
	floor control protocol, perhaps the notifications of state		that stream that is being generated by the user is being mixed by the
	changes are in the specific protocol for floor control. Or,		server and sent to all recipients. "muted" means that no one is
	perhaps this is a separate package.		receiving their media. If the receive-status is "receiving-all" it
			means that the user is hearing all other participants. If it is
			"anchor-only", the user is hearing media from just a single
			participant.
	5.3 Example		5.3 Example
	The following is an example conference information document:		The following is an example conference information document:
	<conference>		<conference>
	<user uri="sip:jdrosen@dynamicsoft.com" name="Jonathan Rosenberg">		<user uri="sip:jdrosen@dynamicsoft.com" name="Jonathan Rosenberg">
	<status value="active"/>		<status value="active"/>
	<replace uri="sip:p09asd8asd-0-f88a70@dynamicsoft.com"/>		<dialog id="as7d900as8" version="0" call-id="987@1.2.3.4"
			local-uri="conference3@example.com"
			local-tag="123" remote-uri="sip:jdrosen@dynamicsoft.com"
			remote-tag="abc" direction="recipient"/>
			<media-status>
			<media-stream type="audio"/>
			</media-status>
	</user>		</user>
	<user uri="sip:hgs@cs.columbia.edu" name="Henning Schulzrinne">		<user uri="sip:hgs@cs.columbia.edu" name="Henning Schulzrinne">
	<status value="active"/>		<status value="active"/>
	<replace uri="sip:nj99999skasdka@cs.columbia.edu"/>		<dialog id="as7d900as8" version="0" call-id="654@8.8.7.7"
			local-uri="conference3@example.com"
			local-tag="xyz" remote-uri="sip:hgs@cs.columbia.edu"
			remote-tag="efg" direction="recipient"/>
	</user>		</user>
	</conference>		</conference>
	This document describes a conference with two users, both of which		This document describes a conference with two users, both of which
	are active.		are active.
	6 Relationship to User Presence		6 Relationship to User Presence
	The SIP events package for user presence [2] has a close relationship		The SIP events package for user presence [3] has a close relationship
	with these two event packages. It is fundamental to the presence		with these two event packages. It is fundamental to the presence
	model that the information used to obtain user presence is		model that the information used to obtain user presence is
	constructed from any number of different input sources. Examples of		constructed from any number of different input sources. Examples of
	such sources include SIP REGISTER requests and uploads of presence		such sources include SIP REGISTER requests and uploads of presence
	documents. These two packages can be considered another mechanism		documents. These two packages can be considered another mechanism
	that allows a presence agent to determine the presence state of the		that allows a presence agent to determine the presence state of the
	user. Specifically, a user presence server can act as a subscriber		user. Specifically, a user presence server can act as a subscriber
	for the call-leg and conference packages to obtain additional		for the dialog and conference packages to obtain additional
	information that can be used to construct a presence document.		information that can be used to construct a presence document.
	7 Example Services		7 Open Issues and To-Dos
	This section overviews some example services that can be enabled by
	the extensions described here.
	7.1 Automatic Callback
	Automatic callback is a simple service. User A calls user B. User B
	is already on the phone, and so returns a 486 Busy to the INVITE from
	A. Rather than continually trying to call B, user A asks for
	automatic callback. With this service, A's phone will ring when B is
	available. When A picks up, A hears ringing, which is B's phone.
	The call flow for this service is shown in Figure 1. In (1-3), A
	calls B, but B is busy. So, in (4), A sends a SUBSCRIBE to B. This
	results in a 200 OK (5) followed by a NOTIFY with the current call-
	leg state for B. This is a call state document which looks like:
	<user uri="sip:B@B.com">
	<call-leg>
	<status code="200"/>
	</call-leg>
	</user>
	The call leg identifiers are not included in this notification,
	because this is not information that A would normally be able to
	obtain by sending an INVITE.
	When B hangs up their call, this causes a second notify containing
	document 2:
	<user uri="sip:B@B.com">
	<call-leg>
	<status code="-1"/>
	</call-leg>
	</user>
	A can then try the INVITE again.
	7.2 Single Line Extension
	In the single line extension application, we wish to have a group of
	phones which are all treated as "extensions" of a single line. This
	means that a call for one rings them all. As soon as one picks up,
	the others stop ringing (all of that is standard forking behavior).
	The additional complexity is that once the call is answered, one of
	the extensions should be able to "pick up" and join the call. This
	emulates the home phone behavior.
	|(1) INVITE |
	|---------------------------->| B is in another call
	|(2) 486 Busy |
	|<----------------------------|
	|(3) ACK |
	|---------------------------->|
	| |
	user |(4) SUBSCRIBE Event:call-leg |
	requests|---------------------------->|
	cb |(5) 200 OK |
	|<----------------------------|
	|(6) NOTIFY doc1 |
	|<----------------------------|
	|(7) 200 OK |
	|---------------------------->|
	| |
	| |
	| |
	| |
	| |
	|(8) NOTIFY doc2 | B's other call
	|<----------------------------| ends
	A's phone rings|(9) 200 OK |
	|---------------------------->|
	A picks up |(10) INVITE |
	|---------------------------->| B's phone rings
	|(11) 200 OK |
	|<----------------------------|
	|(12) ACK |
	|---------------------------->|
	| |
	|(13) SUBSCRIBE Expires:0 |
	|---------------------------->|
	|(14) 200 OK |
	|<----------------------------|
	| |
	| |
	A B
	Figure 1: Automatic callback flow
	This feature is enabled by the mechanisms described in this draft.
	The basic idea is that the phones all share a common SIP URL, and
	there is a forking proxy that forwards calls to all of them. The
	belonging to the same extension group. The phones are also configured
	with the address of a standard conferencing server, as described in
	[10]. To support the feature, only the phones have to know about how
	to do it.
	The call flow for this feature is shown in Figures 2 and 3. First,
	the caller sends an INVITE to call a phone in the extension group
	(1). This is a normal INVITE, with a request URI of
	sip:joe@joeshouse.net, for example. This INVITE arrives at the proxy
	serving Joe's house. Since both extension 1 and extension 2 had
	registered contacts for this URL previously (not shown), the INVITE
	is forked to extension 1 (2) and extension 2 (3). Joe picks up
	extension 1, generating a 200 OK to the INVITE (4). The proxy
	forwards the 200 OK from extension 1 upstream (5), and cancels the
	other branch (6), which causes extension B to stop ringing, and then
	response 200 OK to the CANCEL (7), followed by a 487 to the INVITE
	(8). The proxy ACKs the 487 (9). The caller sends an ACK for the 200
	OK (10), and the caller is now talking to Joe on extension 1. In
	order to keep track of that call, so that its status can be displayed
	in its UI, extension 2 now generates a SUBSCRIBE for
	sip:joe@joeshouse.net. This goes to the proxy (11), which forks it as
	it would any normal request. It gets forked to extension 1 (12) and
	extension 2 (13). Extension 2 receives its own SUBSCRIBE, and
	generates a 482 Loop Detected error response (14). Extension 1
	accepts the SUBSCRIBE, and sends a 200 OK (15) (its assumed that the
	SUBSCRIBE was authenticated with the shared secret; the 401 and
	resubmission are not shown). The 200 OK is forwarded back to
	extension 2 (16). In the event that there were more than two
	extensions, only a single 200 OK would still be returned to extension
	2. However, as described in [1], the NOTIFY's that are generated will
	allow extension 2 to find out about all of the other extensions which
	accepted the subscription. In this case, its just one, extension 1.
	It generates a NOTIFY (17) that contains document 1, shown below:
	<user uri="sip:joe@joeshouse.net">
	<call-leg local-uri="sip:joe@joeshouse.net"
	remote-uri="sip:caller@foo.edu"
	local-tag="00a9"
	remote-tag="ffd2"
	call-id="aa9@1.2.3.4">
	<status code="200"/>
	<replace-local uri="sip:00a9.ffd2.aa9_1-2-3-4@ex1.joeshouse.net">
	<replace-remote uri="sip:ffd2.00a9.aa9_1-2-3-4@hispc.foo.edu">
	<join uri="sip:join-00a9.ffd2.aa9_1-2-3-4@ex1.joeshouse.net">
	</call-leg>
	</user>
	|(1) INVITE | | | |
	|-------------->|(2) INVITE | | |
	| |-------------->| | |
	| |(3) INVITE | | |
	| |------------------------------->| |
	| |(4) 200 OK | | |
	|(5) 200 OK |<--------------| | |
	|<--------------|(6) CANCEL | | |
	| |------------------------------->| |
	| |(7) 200 CANCEL | | |
	| |<-------------------------------| |
	| |(8) 487 | | |
	| |<-------------------------------| |
	| |(9) ACK | | |
	| |------------------------------->| |
	|(10) ACK | | | |
	|------------------------------>| | |
	| |(11) SUBSCRIBE | | |
	| |<-------------------------------| |
	| |(12) SUBSCRIBE | | |
	| |-------------->| | |
	| |(13) SUBSCRIBE | | |
	| |------------------------------->| |
	| |(14) 482 | | |
	| |<-------------------------------| |
	| |(15) 200 OK | | |
	| |<--------------| | |
	| |(16) 200 OK | | |
	| |------------------------------->| |
	| | |(17) NOTIFY doc1| |
	| | |--------------->| |
	| | |(18) 200 OK | |
	| | |<---------------| |
	| | | | |
	| | | | |
	Caller Proxy Extension Extension Conf.
	1 2 Server
	Figure 2: Single line extension flow: Part I
	This allows extension 2 to show that a call is active on the
	extension group, and a UI can be provided for the call to be picked
	up by someone on extension 2.
	At some point, Joe's wife picks up extension 2 in order to join the
	active call. That causes the phone to send an INVITE to the join URI
	in the notification it received. This INVITE (19) goes directly to
	extension 1. When extension 1 receives this, it knows this is a
	request to join the call. It challenges and authenticates the INVITE
	to make sure that its another extension in the group (not shown). It
	then redirects the call, providing a Contact header which is a new
	conference URI at the conference server (20). Presumably, each
	extension is configured with the domain name of the conference
	server, and can create conferences by choosing usernames that are
	globally unique in space and time. The resulting user@domain SIP URL
	can be used for ad-hoc conference calls, like this one. Extension 2
	ACKs the 300 (21). Extension 1 knows it needs to join that conference
	call. So, it sends an INVITE to the conference URL it just returned
	to extension 2 (23), which is accepted (25) and acknowledged (26).
	Extension 1 is now the only member of the call. In the meantime,
	extension 1 knows that it needs to get the caller into the conference
	as well. So, it sends out a REFER (22), containing a Refer-To URL
	that points to the conference URL being used. The REFER is accepted
	by the caller (24). Extension 2 recurses on the redirect it receives,
	and sends an INVITE to the conference URL (27), which is accepted
	(28) and acknowledged (29). Finally, the caller acts on the REFER,
	and generates an INVITE (30) that will join it into the conference as
	well. This is accepted (31) and acknowleged (32). Now, there is a
	three-party conference between the caller, extension 1 and extension
	2. The caller generates a NOTIFY as discussed in [8] (33) which is
	accepted (34). The NOTIFY tells extension 1 that the caller has been
	connected to the conference server. So, extension 1 terminates its
	direct call leg with the caller (35).
	If other extensions pick up, a similar thing happens - they are
	redirected to the conference URL. By using a conference server, we
	have the advantage that the call remains active as long as any one
	extension is in the call. This also emulates typical home phone line
	behavior.
	OPEN ISSUE: Its not clear that extension 1 should REFER the
	caller to the conference server. We want the change to the
	conference server to be transparent to the caller. A REFER
	will trigger a UI query at the caller, most likely. An
	alternative is to have extension 1 REFER the conference
	server to the caller, using the replaces URL learned from
	| | |(19) INVITE | |
	| | |<---------------| |
	| | |(20) 300 | |
	| | |--------------->| |
	| | |(21) ACK | |
	|(22) REFER | |<---------------| |
	|<------------------------------|(23) INVITE | |
	|(24) 200 OK | |------------------------------->|
	|------------------------------>|(25) 200 OK | |
	| | |<-------------------------------|
	| | |(26) ACK | |
	| | |------------------------------->|
	| | | |(27) INVITE |
	| | | |-------------->|
	| | | |(28) 200 OK |
	| | | |<--------------|
	| | | |(29) ACK |
	| | | |-------------->|
	|(30) INVITE | | | |
	|--------------------------------------------------------------->|
	|(31) 200 OK | | | |
	|<---------------------------------------------------------------|
	|(32) ACK | | | |
	|--------------------------------------------------------------->|
	|(33) NOTIFY | | | |
	|------------------------------>| | |
	|(34) 200 OK | | | |
	|<------------------------------| | |
	|(35) BYE | | | |
	|<------------------------------| | |
	|(36) 200 OK | | | |
	|------------------------------>| | |
	| | | | |
	| | | | |
	| | | | |
	Caller Proxy Extension Extension Conf.
	1 2 Server
	Figure 3: Single line extension flow: Part II
	the caller as the Refer-To header. This works better.
	However, the INVITE triggered from this will be challenged
	by the caller, and its not clear how the conference server
	will obtain credentials.
	7.3 Unattended Consultation-Hold Transfer
	In unattended consultation-hold transfer, A is talking to B. A wishes
	to transfer B to C. So, A first calls C, and talks to them to OK the
	transfer.If C agrees, B is connected to C.
	As discussed in [8], this flow is difficult. The main problem is that
	once the transfer has been verbally approved, A needs to send a REFER
	to C, containing B in the Refer-To header. However, what is desired
	is to refer C to that very specific instance of B. Placing the
	To/From with B into the Refer-To therefore won't work, since it won't
	necessarily route to the UA that user B is using. Putting the Contact
	at B may not work either, since it may not be globally routable.
	Our To-Replace header fixes this. By definition, it contains a
	globally routable URL which can be used to replace the specific call
	leg. B would return this in its 200 OK to A. When A REFERs C to B,
	this URL would be placed in the Refer-To header. The result is that
	the service executes perfectly.
	7.4 Call Park and Pickup
	In the PSTN, call park and pickup is defined as follows. Joe (using
	UA A) is talking to Bob (using UA B). Joe would like to walk over to
	another phone (UA C) that Joe can see, but doesn't have the number
	for, and pick continue on the call at that new phone. To do that, Joe
	places Bob on hold, walks over to the phone, picks it up, dials some
	numbers, and then talks to Bob.
	A SIP flow for call park is given in the service examples document
	[11]. However, that service only works when the parking phone is the
	same as the picking up phone (and thus is more like music-on-hold).
	There is also a flow for pickup. This relies on registrations to
	cause an in-progress INVITE to fork to the new phone. However, this
	only works for calls that haven't yet completed at the first phone.
	The flow for the call park and pickup service is shown in Figure 4.
	First, A calls B as a normal SIP call (1-3). The INVITE (1) contains
	a To-Replace header with the value sip:00a9.ffd2.aa9_1-2-3-
	4@mypc.company.com, and the 200 OK has a To-Replace header with value
	sip:ffd2.00a9.aa9_1-2-3-4@hispc.foo.edu. At some point, Joe decides
	to park the call for later pickup. A simply places B on hold (4-6).
	Joe walks over to another phone, C, and enters in his extension (i.e,
	the identity of the phone which the call is being retrieved from). To
	pickup, C needs to learn the call legs at A. So, it sends a SUBSCRIBE
	to A's extension (7). The SUBSCRIBE is authenticated (Joe will need
	to enter his own username and password), which is not shown, and the
	resubmitted SUBSCRIBE generates a 200 OK (8). That triggers a NOTIFY
	(9) which contains the call leg state at A:
	<user uri="sip:A@company.com">
	<call-leg local-uri="sip:A@company.com"
	remote-uri="sip:B@foo.edu"
	local-tag="00a9"
	remote-tag="ffd2"
	call-id="aa9@1.2.3.4">
	<status code="200"/>
	<replace-local uri="sip:00a9.ffd2.aa9_1-2-3-4@mypc.company.com">
	<replace-remote uri="sip:ffd2.00a9.aa9_1-2-3-4@hispc.foo.edu">
	</call-leg>
	</user>
	From this, C learns there is a single accepted call at A. The
	notification also contains a replace-remote URL, which can be used to
	replace the existing call leg at B with a new one. So, C takes that
	URL, and generates an INVITE for it (15). This is authenticated and
	authorized by B (specifically, B allows a call-leg to be replaced if
	the authenticated identity of the new leg matches the identity of the
	replaced leg), and then silently accepted (16). Now, Joe is talking
	to Bob using UA C. Since B has replaced its old call leg, it sends a
	BYE on it (18). UA A is now disconnected from the call.
	7.5 IM a call
	This service is a much "cooler" variant on transfer. A calls B, and
	they talk. During the call, A wants C to take over the call. Rather
	than sending a REFER to execute a transfer, A sends C an instant
	message. This IM has HTML inside of it, which asks C to click on a
	URL to take the call. When C clicks on it, they take over the call,
	and A is disconnected.
	The call flow for this is shown in Figure 5. A calls B using a		o There is a strong relationship between the dialog event
	standard INVITE sequence (1-3). The 200 OK from B contains a To-		package, and the notifications used by the REFER specification
	Replace URL. A decides to send the call to B using an IM. So, it		[8]. Should these be unified, so that a REFER basically
	sends a MESSAGE (4) that has an HTML body. This request looks like:		implies a subscription to the dialog state created by that
			REFER?.
	| |(1) INVITE |		o Reuse of dialogs for conference and dialog subscriptions needs
	| |--------------------->|		to be discussed. It has an implication for the dialog state
	| |(2) 200 OK |		package. Now, the session may be terminated, but the dialog
	| |<---------------------|		remains.
	| |(3) ACK |
	| |--------------------->|
	| |(4) INVITE hold |user A holds
	| |--------------------->|
	| |(5) 200 OK |
	| |<---------------------|
	| |(6) ACK |
	user A | |--------------------->|
	picks up |(7) SUBSCRIBE | |
	at C |-------------------->| |
	|(8) 200 OK | |
	|---------------------| |
	|(9) NOTIFY doc1 | |
	|<--------------------| |
	|(10) 200 OK | |
	|-------------------->| |
	|(11) SUBSCRIBE | |
	|------------------------------------------->|
	|(12) 200 OK | |
	|<-------------------------------------------|
	|(13) NOTIFY doc2 | |
	|<-------------------------------------------|
	|(14) 200 OK | |
	|------------------------------------------->|
	|(15) INVITE | |
	|------------------------------------------->|
	|(16) 200 OK | |
	|<-------------------------------------------|
	|(17) ACK | |
	|------------------------------------------->|
	| |(18) BYE |
	| |<---------------------|
	| |(19) 200 OK |
	| |--------------------->|
	| | |
	| | |
	C A B		o Need to add IANA considerations
	Figure 4: Call Park and Pickup		o Should we split this into two documents, or even four?
	|(1) INVITE | |		Probably two.
	|<----------------| |
	|(2) 200 OK | |
	|---------------->| |
	|(3) ACK | |
	|<----------------| |
	| |(4) MESSAGE |
	| |---------------->|
	| |(5) 200 OK |
	| |<----------------|
	| | |
	| | |
	| | |
	| | |
	| | |
	|(6) INVITE | |
	|<----------------------------------|
	|(7) 200 OK | |
	|---------------------------------->|
	|(8) ACK | |
	|<----------------------------------|
	|(9) BYE | |
	|---------------->| |
	|(10) 200 OK | |
	|-----------------| |
	| | |
	| | |
	| | |
	B A C		8 Security Considerations
	Figure 5: Call flow for IM-a-call		Subscriptions to dialog state and conference state can reveal very
			sensitive information. For this reason, the document recommends
			authentication and authorization, and provides guidelines on sensible
			authorization policies.
	MESSAGE sip:C@foo.com SIP/2.0		Since the data in notifications is sensitive as well, end-to-end SIP
	Via: SIP/2.0/UDP pc22.foo.com		encryption mechanisms using S/MIME SHOULD be used to protect it.
	From: sip:A@foo.com
	To: sip:C@foo.com
	Call-ID: 9as8da8s@1.2.3.4
	CSeq: 99 MESSAGE
	Content-Type: text/html
	Content-Length: ...
	<html>		9 IANA Considerations
	<body>
	Hi, Jack. Would you take this <a href="sip:hhggff@bar.com">call</a>?
	Thanks, Bob.
	</body>
	</html>
	Where sip:hhggff@bar.com is the URL from the To-Replace header in the		TODO.
	200 OK from B (message 2).
	C returns a 200 OK to this MESSAGE (5). At some time later, C clicks		10 Acknowledgements
	on the URL in the MESSAGE, which causes a call to be made to the
	replace URL. This goes to B. This is a standard INVITE sequence (7-
	9). Once done, since B knows this is a replace URL, it hangs up with
	A (10-11).
	8 Open Issues and To-Dos		The authors would like to thank Dan Petrie for his comments.
	There is a strong relationship between the call-leg event package,		11 Changes since -00
	and the notifications used by the REFER specification [8]. We believe
	that these should be unified, so that a REFER basically implies a
	subscription to the call leg state created by that REFER. That still
	needs to be done.
	There are many security issues to be worked out. Authentication of		o Alignment with bis and sip-events
	join and replaces INVITEs are complex, and need further
	investigation.
	The requirement for globally routable join and replaces URLs is a		o Added direction attribute to dialog format
	real issue. Its not clear how that can be done. Using the hostname of
	the UA won't work in general, since calls may need to flow through a
	proxy. This introduces the need for a UA to generate a new URL which
	contains the domain name of the top-level proxy in its network, yet
	is routed to that UA. The UA could then REGISTER this URL at its
	proxy. This might work in some networks, but not in more complex ones
	with multiple tiers of proxies, some of which use database queries to
	route calls to specific users. More thinking on this is needed.
	More details and examples are needed.		o Removed To-Join and To-Replace header, along with joining and
			replacing URIs from the various formats.
	9 Security Considerations		o Conference data format reuses dialog formats
	Subscriptions to call-leg state and conference state can reveal very		o Added media mixing information to conference format
	sensitive information. For this reason, the document recommends
	authentication and authorization, and provides guidelines on sensible
	authorization policies.
	Since the data in notifications is sensitive as well, end-to-end SIP		o Removal of example services (will go into service examples
	encryption mechanisms SHOULD be used to protect it.		specification)
	Furthermore, the To-Replace and To-Join URLs provide significant		o Removal of floor control from conference package; rather,
	power to any user that can obtain them. INVITEs to these URLs SHOULD		place it into a separate event package, as was done in
	be authenticated and authorized.
	10 Authors Addresses		12 Authors Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	72 Eagle Rock Avenue		72 Eagle Rock Avenue
	First Floor		First Floor
	East Hanover, NJ 07936		East Hanover, NJ 07936
	email: jdrosen@dynamicsoft.com		email: jdrosen@dynamicsoft.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	M/S 0401		M/S 0401
	1214 Amsterdam Ave.		1214 Amsterdam Ave.
	New York, NY 10027-7003		New York, NY 10027-7003
	email: schulzrinne@cs.columbia.edu		email: schulzrinne@cs.columbia.edu
	11 Bibliography		13 Normative References
	[1] A. Roach, "SIP specific event notification," Internet Draft,		[1] A. Roach et al. , "SIP-specific event notification," Internet
	Internet Engineering Task Force, July 2001. Work in progress.		Draft, Internet Engineering Task Force, Feb. 2002. Work in progress.
	[2] J. Rosenberg et al. , "SIP extensions for presence," Internet		[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
	Draft, Internet Engineering Task Force, Apr. 2001. Work in progress.		protocol," Internet Draft, Internet Engineering Task Force, Feb.
			2002. Work in progress.
	[3] J. Rosenberg, "A SIP event sub-package for watcher information,"		14 Informative References
			[3] J. Rosenberg, "SIP extensions for presence," Internet Draft,
			Internet Engineering Task Force, Nov. 2001. Work in progress.
			[4] J. Rosenberg, "A SIP event sub-package for watcher information,"
	Internet Draft, Internet Engineering Task Force, July 2001. Work in		Internet Draft, Internet Engineering Task Force, July 2001. Work in
	progress.		progress.
	[4] R. Mahy and I. Slain, "SIP extensions for message waiting		[5] R. Mahy and I. Slain, "SIP event package for message waiting
	indication," Internet Draft, Internet Engineering Task Force, Feb.		indication," Internet Draft, Internet Engineering Task Force, Nov.
	2001. Work in progress.		2001. Work in progress.
	[5] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request		[6] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request
	for Comments 3023, Internet Engineering Task Force, Jan. 2001.		for Comments 3023, Internet Engineering Task Force, Jan. 2001.
	[6] J. Rosenberg and H. Schulzrinne, "Models for multi party		[7] J. Rosenberg and H. Schulzrinne, "Models for multi party
	conferencing in SIP," Internet Draft, Internet Engineering Task		conferencing in SIP," Internet Draft, Internet Engineering Task
	Force, Nov. 2000. Work in progress.		Force, Nov. 2001. Work in progress.
	[7] J. Myers, "IMAP4 QUOTA extension," Request for Comments 2087,		[8] R. Sparks, "The refer method," Internet Draft, Internet
	Internet Engineering Task Force, Jan. 1997.		Engineering Task Force, Oct. 2001. Work in progress.
	[8] R. Sparks, "SIP call control," Internet Draft, Internet		Full Copyright Statement
	Engineering Task Force, Feb. 2001. Work in progress.
	[9] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:		Copyright (c) The Internet Society (2002). All Rights Reserved.
	Session initiation protocol," Internet Draft, Internet Engineering
	Task Force, Nov. 2000. Work in progress.
	[10] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application		This document and translations of it may be copied and furnished to
	server component architecture for SIP," Internet Draft, Internet		others, and derivative works that comment on or otherwise explain it
	Engineering Task Force, Mar. 2001. Work in progress.		or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
	[11] A. Johnston, R. Sparks, C. Cunningham, S. Donovan, and K.		The limited permissions granted above are perpetual and will not be
	Summers, "SIP service examples," Internet Draft, Internet Engineering		revoked by the Internet Society or its successors or assigns.
	Task Force, Mar. 2001. Work in progress.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 141 change blocks.
	847 lines changed or deleted		452 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/