< draft-ietf-sipping-conferencing-models-00.txt		draft-ietf-sipping-conferencing-models-01.txt >
	Internet Engineering Task Force SIPPING WG		Internet Engineering Task Force SIPPING WG
	Internet Draft J.Rosenberg,H.Schulzrinne		Internet Draft J. Rosenberg
	draft-ietf-sipping-conferencing-models-00.txt dynamicsoft,Columbia U.		dynamicsoft
	November 5, 2001		H. Schulzrinne
	Expires: May 2002		Columbia U.
			draft-ietf-sipping-conferencing-models-01.txt
			July 1, 2002
			Expires: January 2003
	Models for Multi Party Conferencing in SIP		Models for Multi Party Conferencing in SIP
	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 39 ¶		skipping to change at page 2, line 5 ¶
	To view the list Internet-Draft Shadow Directories, see		To view the list Internet-Draft Shadow Directories, see
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	The Session Initiation Protocol (SIP) can support multi-party		The Session Initiation Protocol (SIP) can support multi-party
	conferencing in many different ways. In this draft, we define the		conferencing in many different ways. In this draft, we define the
	various multi-party conferencing models, and for each, discuss how		various multi-party conferencing models, and for each, discuss how
	they are used and then analyze their relative benefits and drawbacks.		they are used and then analyze their relative benefits and drawbacks.
			Table of Contents
			1 Introduction ........................................ 4
			2 End System Mixing ................................... 4
			2.1 Inviting Users to Join .............................. 6
			2.2 Users Joining ....................................... 7
			2.3 Scalability ......................................... 7
			2.4 Location of Service Logic ........................... 8
			2.5 Discovering Participant Identities .................. 8
			3 Large-Scale Multicast Conferences ................... 8
			3.1 Inviting Users to Join .............................. 9
			3.2 Users Joining ....................................... 9
			3.3 Scalability ......................................... 9
			3.4 Location of Service Logic ........................... 10
			3.5 Discovering Participant Identities .................. 10
			4 Dial-In Conference Servers .......................... 10
			4.1 Inviting Users to Join .............................. 12
			4.2 Users Joining ....................................... 13
			4.3 Scalability ......................................... 13
			4.4 Location of Service Logic ........................... 14
			4.5 Discovering Participant Identities .................. 14
			5 Ad-hoc Centralized Conferences ...................... 14
			5.1 Inviting Users to Join .............................. 16
			5.2 Users Joining ....................................... 16
			5.3 Scalability ......................................... 16
			5.4 Location of Service Logic ........................... 19
			5.5 Discovering Participant Identities .................. 19
			6 Dial-Out Conferences ................................ 19
			6.1 Inviting Users to Join .............................. 19
			6.2 Users Joining ....................................... 19
			6.3 Scalability ......................................... 20
			6.4 Location of Service Logic ........................... 21
			6.5 Discovering Participant Identities .................. 21
			7 Centralized Signaling, Distributed Media ............ 21
			7.1 Inviting Users to Join .............................. 24
			7.2 Users Joining ....................................... 24
			7.3 Scalability ......................................... 24
			7.4 Location of Service Logic ........................... 24
			7.5 Discovering Participant Identities .................. 25
			8 Summary of Models ................................... 25
			9 Security Considerations ............................. 25
			10 Conclusion .......................................... 26
			11 Acknowledgements .................................... 26
			12 Authors Addresses ................................... 26
			13 Normative References ................................ 26
			14 Informative References .............................. 27
	1 Introduction		1 Introduction
	The Session Initiation Protocol (SIP) [1] has been defined for the		The Session Initiation Protocol (SIP) [1] has been defined for the
	establishment, maintenance, and termination of calls between one or		establishment, maintenance, and termination of calls between one or
	more users. However, despite its origins as a large scale multiparty		more users. However, despite its origins as a large scale multiparty
	conferencing protocol, SIP is used today primarily for point to point		conferencing protocol, SIP is used today primarily for point to point
	calls. This configuration is the focus of the SIP specification and		calls. This configuration is the focus of the SIP specification and
	most of its extensions. As a result, there is a lot of confusion		most of its extensions. As a result, there is a lot of confusion
	about how SIP supports multi-party conferencing.		about how SIP supports multi-party conferencing.
	skipping to change at page 2, line 42 ¶		skipping to change at page 5, line 4 ¶
	completely separate SIP call. This call uses a different Call-ID,		completely separate SIP call. This call uses a different Call-ID,
	different tags, etc. There is no call set up directly between B and		different tags, etc. There is no call set up directly between B and
	C. A receives media streams from both B and C, and mixes them. A		C. A receives media streams from both B and C, and mixes them. A
	sends a stream containing A's and C's streams to B, and a stream		sends a stream containing A's and C's streams to B, and a stream
	stream containing A's and B's streams to C.		stream containing A's and B's streams to C.
	This model is depicted graphically in Figure 1.		This model is depicted graphically in Figure 1.
	Basically, user A handles both signaling and media mixing. B and C		Basically, user A handles both signaling and media mixing. B and C
	are unaware of the multi-party call, from a SIP perspective at least.		are unaware of the multi-party call, from a SIP perspective at least.
			+----------+
			| |
			-- | |
			--- | B |
			SIP call --- | |
			--- .. | |
			--- .. +----------+
			-- ...
			...
			+----------+ .. RTP
			| | ..
			| |
			| A | ..
			| | ..
			| | .. RTP
			+----------+ ..
			-- ..
			-- ..
			--- . +----------+
			-- | |
			-- | |
			SIP call -- | |
			| C |
			| |
			+----------+
			Figure 1: Three Way Calling using End System Mixing
	From an RTP perspective, A is a mixer, and so the RTCP reports from A		From an RTP perspective, A is a mixer, and so the RTCP reports from A
	will contain SDES information that indicates the existence of an		will contain SDES information that indicates the existence of an
	additional party in the media stream.		additional party in the media stream.
	Note that this model has the serious drawback that the conference		Note that this model has the serious drawback that the conference
	ends when the mixing UA leaves the call.		ends when the mixing UA leaves the call.
	OPEN ISSUE: Another problem with this approach is that		OPEN ISSUE: Another problem with this approach is that
	there is no specific way for A to determine when a		there is no specific way for A to determine when a
	signaling message it receives was meant just for it, or for		signaling message it receives was meant just for it, or for
	skipping to change at page 8, line 6 ¶		skipping to change at page 11, line 6 ¶
	Dial-In conference servers closely mirror dial-in conference bridges		Dial-In conference servers closely mirror dial-in conference bridges
	in the traditional PSTN.		in the traditional PSTN.
	A dial-in conference server acts as a normal SIP UA. Users call it,		A dial-in conference server acts as a normal SIP UA. Users call it,
	and the server maintains point to point SIP relationships with each		and the server maintains point to point SIP relationships with each
	user that calls in. The server takes the media from the users who		user that calls in. The server takes the media from the users who
	dial into the same conference, mixes them, and sends out the		dial into the same conference, mixes them, and sends out the
	appropriate mixed stream to each participant separately.		appropriate mixed stream to each participant separately.
			+-----+
			| |
			| A |
			| |
			+-----+
			| .
			| .
			| .
			| .
			| .
			+---------+
			+-----+ | | +-----+
			| |---------| Conf. |---------| |
			| D | | Server | | B |
			| |.........| |.........| |
			+-----+ | | +-----+
			+---------+
			| .
			| .
			| .
			| .
			+-----+
			| |
			| C |
			| |
			+-----+
			Figure 3: Dial-In Conference Servers
	The model is depicted in Figure 3. Note that each UA (A,B,C,D) has a		The model is depicted in Figure 3. Note that each UA (A,B,C,D) has a
	point to point SIP and RTP relationship with the conference server.		point to point SIP and RTP relationship with the conference server.
	Each call has a different Call-ID. Each user sends their own media to		Each call has a different Call-ID. Each user sends their own media to
	the server. The media delivered to user A by the server is the media		the server. The media delivered to user A by the server is the media
	mixed from users B,C and D. The media delivered to user B by the		mixed from users B,C and D. The media delivered to user B by the
	server is the media mixed from users A, C and D. The media delivered		server is the media mixed from users A, C and D. The media delivered
	to user C by the server is the media mixed from users A, B and D. The		to user C by the server is the media mixed from users A, B and D. The
	media delivered to user D is the media mixed from users A, B and C		media delivered to user D is the media mixed from users A, B and C
	(this is also known as a mix-minus configuration).		(this is also known as a mix-minus configuration).
	skipping to change at page 13, line 5 ¶		skipping to change at page 16, line 34 ¶
	OPEN ISSUE: There is no way for A to know that the entire		OPEN ISSUE: There is no way for A to know that the entire
	conference has transitioned. Also, as above, its not clear		conference has transitioned. Also, as above, its not clear
	that a REFER from the conference server wouldn't be better.		that a REFER from the conference server wouldn't be better.
	Once the conference has been formed, further operation is identical		Once the conference has been formed, further operation is identical
	to the dial-in conferencing model of Section 4. The only difference		to the dial-in conferencing model of Section 4. The only difference
	in the conferences is that the conference identifier is dynamic in		in the conferences is that the conference identifier is dynamic in
	this case, and static in Section 4. This makes users asynchronously		this case, and static in Section 4. This makes users asynchronously
	joining nearly impossible.		joining nearly impossible.
			5.1 Inviting Users to Join
			Once the ad-hoc conference has been created on the server, inviting
			users proceeds as defined in Section 4.1.
			5.2 Users Joining
			Once the ad-hoc conference has been created on the server, joining
			proceeds as defined in Section 4.2.
			5.3 Scalability
			The scalability of this conference model is identical to that of
			dial-in conference servers, as described in Section 4.3.
	A B Conference C		A B Conference C
	Server		Server
	|(1) INVITE | | |		|(1) INVITE | | |
	|-------------->| | |		|-------------->| | |
	|(2) 200 OK | | |		|(2) 200 OK | | |
	|<--------------| | |		|<--------------| | |
	|(3) ACK | | |		|(3) ACK | | |
	|-------------->| | |		|-------------->| | |
	| |(4) INVITE | |		| |(4) INVITE | |
	| |-------------->| |		| |-------------->| |
	skipping to change at page 15, line 5 ¶		skipping to change at page 19, line 5 ¶
	| | | |(18) ACK |		| | | |(18) ACK |
	| | | |------------->|		| | | |------------->|
	| | | | |		| | | | |
	| | | | |		| | | | |
	A B C D Conf.		A B C D Conf.
	Server		Server
	Figure 5: Adhoc transition from end-system mixed: part I		Figure 5: Adhoc transition from end-system mixed: part I
	5.1 Inviting Users to Join
	Once the ad-hoc conference has been created on the server, inviting
	users proceeds as defined in Section 4.1.
	5.2 Users Joining
	Once the ad-hoc conference has been created on the server, joining
	proceeds as defined in Section 4.2.
	5.3 Scalability
	The scalability of this conference model is identical to that of
	dial-in conference servers, as described in Section 4.3.
	5.4 Location of Service Logic		5.4 Location of Service Logic
	The logic for handling the transition process must be located in at		The logic for handling the transition process must be located in at
	least one UA in the conference. All UAs that are mixers in a end		least one UA in the conference. All UAs that are mixers in a end
	system mixed conference must know to propagate the REFER requests		system mixed conference must know to propagate the REFER requests
	they receive during the transition.		they receive during the transition.
	5.5 Discovering Participant Identities		5.5 Discovering Participant Identities
	Once the ad-hoc conference is established, conference identities are		Once the ad-hoc conference is established, conference identities are
	skipping to change at page 16, line 5 ¶		skipping to change at page 19, line 39 ¶
	Once the users accept or reject the call from the dial out server,		Once the users accept or reject the call from the dial out server,
	the behavior of this system is identical to the dial-in server case		the behavior of this system is identical to the dial-in server case
	of Section 4. Thus, a dial-out conference server will generally need		of Section 4. Thus, a dial-out conference server will generally need
	to support dial-in access for the same conference, if it wishes to		to support dial-in access for the same conference, if it wishes to
	allow joining after the conference begins.		allow joining after the conference begins.
	Note that, from the participants perspective, they will learn the		Note that, from the participants perspective, they will learn the
	conference identity (the URL) from the From field in the INVITE		conference identity (the URL) from the From field in the INVITE
	messages received from the server.		messages received from the server.
			OPEN ISSUE: Or is the Contact more appropriate?
			6.1 Inviting Users to Join
			Once the conference is established, inviting users to join is
			identical to the scenario described in Section 4.1. Note that the URL
			to be used in the REFER is obtained from the From field of the INVITE
			received from the dial-out server.
			6.2 Users Joining
			Once the conference is established, joining is identical to the
			scenario described in Section 4.2. Note that the URL to be used in
	|(19) NOTIFY | | | |		|(19) NOTIFY | | | |
	|<-------------| | | |		|<-------------| | | |
	|(20) 200 OK | | | |		|(20) 200 OK | | | |
	|------------->| | | |		|------------->| | | |
	|(21) NOTIFY | | | |		|(21) NOTIFY | | | |
	|<----------------------------| | |		|<----------------------------| | |
	|(22) 200 OK | | | |		|(22) 200 OK | | | |
	|---------------------------->| | |		|---------------------------->| | |
	|(23) BYE | | | |		|(23) BYE | | | |
	|------------->| | | |		|------------->| | | |
	skipping to change at page 16, line 48 ¶		skipping to change at page 20, line 47 ¶
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | | | |		| | | | |
	A B C D Conf.		A B C D Conf.
	Server		Server
	Figure 6: Adhoc transition from end-system mixed: part II		Figure 6: Adhoc transition from end-system mixed: part II
	OPEN ISSUE: Or is the Contact more appropriate?
	6.1 Inviting Users to Join
	identical to the scenario described in Section 4.1. Note that the URL
	to be used in the REFER is obtained from the From field of the INVITE
	received from the dial-out server.
	6.2 Users Joining
	Once the conference is established, joining is identical to the
	scenario described in Section 4.2. Note that the URL to be used in
	the INVITE of new participants is obtained from the From field of the		the INVITE of new participants is obtained from the From field of the
	INVITE received from the dial-out server by the initial participants.		INVITE received from the dial-out server by the initial participants.
	6.3 Scalability
	The scalability of this conference model is identical to that of		The scalability of this conference model is identical to that of
	dial-in conference servers, as described in Section 4.3.		dial-in conference servers, as described in Section 4.3.
	6.4 Location of Service Logic		6.4 Location of Service Logic
	The SIP UA of the conference participants does not require any		The SIP UA of the conference participants does not require any
	special processing. The RTP implementation in those clients, however,		special processing. The RTP implementation in those clients, however,
	should support RTCP and be prepared to receive contributing sources.		should support RTCP and be prepared to receive contributing sources.
	All of the new logic for providing this service resides in the		All of the new logic for providing this service resides in the
	skipping to change at page 19, line 6 ¶		skipping to change at page 22, line 42 ¶
	two already in use by C) using address/port D2. The response (11)		two already in use by C) using address/port D2. The response (11)
	contains a new address/port to send media to B. Call this port B3. In		contains a new address/port to send media to B. Call this port B3. In
	the re-INVITE to A (13), the server adds an additional media line		the re-INVITE to A (13), the server adds an additional media line
	using address/port D3. The response (14) contains a new address/port		using address/port D3. The response (14) contains a new address/port
	to send media to A. Call this port A3.		to send media to A. Call this port A3.
	Finally, the server sends a re-INVITE (15) to the new party. This		Finally, the server sends a re-INVITE (15) to the new party. This
	re-INVITE takes all three streams off hold, and updates their		re-INVITE takes all three streams off hold, and updates their
	connection addresses and ports with C3, B3, and A3, respectively. The		connection addresses and ports with C3, B3, and A3, respectively. The
	200 OK response (16) returns the same ports and addresses returned in		200 OK response (16) returns the same ports and addresses returned in
	message (5) (as noted in [14], these addresses/ports MUST NOT		message (5) (as noted in [14], these addresses/ports MUST NOTchange).
	change). Now, D can send media to A,B and C.		Now, D can send media to A,B and C.
	The result of these manipulations is, indeed, a full mesh of unicast		The result of these manipulations is, indeed, a full mesh of unicast
	RTP streams between all participants. Unlike the case of end system		RTP streams between all participants. Unlike the case of end system
	mixing, the stream sent by any participant to all of the others is		mixing, the stream sent by any participant to all of the others is
	identical. Each particpant needs to mix, but it mixes the media it		identical. Each particpant needs to mix, but it mixes the media it
	receives, and plays that out the speakers. This is normal behavior		receives, and plays that out the speakers. This is normal behavior
	for multiple streams of the same type. Note that the SIP relationship		for multiple streams of the same type. Note that the SIP relationship
	is still point-to-point. There are four calls at the end of Figure 7,		is still point-to-point. There are four calls at the end of Figure 7,
			| | | |(1) INV D |
			| | | |-------------->|
			| | | |(2) 200 hold |
			| | | |<--------------|
			| | | |(3) ACK |
			| | | |-------------->|
			| | | |(4) INV 3held |
			| | | |<--------------|
			| | | |(5) 200 3recv |
			| | | |-------------->|
			| | | |(6) ACK |
			| | | |<--------------|
			| | | (7) INV +D1 | |
			| | |<------------------------------|
			| | | (8) 200 +C3 | |
			| | |------------------------------>|
			| | | (9) ACK | |
			| | |<------------------------------|
			| |(10) INV +D2 | | |
			| |<---------------------------------------------|
			| |(11) 200 +B3 | | |
			| |--------------------------------------------->|
			| |(12) ACK | | |
			| |<---------------------------------------------|
			|(13) INV +D3 | | | |
			|<-----------------------------------------------------------|
			|(14) 200 +A3 | | | |
			|----------------------------------------------------------->|
			|(15) ACK | | | |
			|<-----------------------------------------------------------|
			| | | |(16) INV A3,B3,C3
			| | | |<--------------|
			| | | |(17) 200 |
			| | | |-------------->|
			| | | |(18) ACK |
			| | | |<--------------|
			| | | | |
			| | | | |
			| | | | |
			| | | | |
			| | | | |
			| | | | |
			A B C D Server
			Figure 7: Centralized Signaling, Decentralized Media
	one from each participant to the server, each with a different Call-		one from each participant to the server, each with a different Call-
	ID.		ID.
	Note that hybrids are easily possible. Certain users can instead be		Note that hybrids are easily possible. Certain users can instead be
	mixed (sending audio to the conference server), while others are set		mixed (sending audio to the conference server), while others are set
	to send audio to each other.		to send audio to each other.
	7.1 Inviting Users to Join		7.1 Inviting Users to Join
	Inviting users to join works identically to the dial-in conference		Inviting users to join works identically to the dial-in conference
	skipping to change at page 20, line 41 ¶		skipping to change at page 25, line 29 ¶
	Conference identities are discovered through RTCP. Each user will		Conference identities are discovered through RTCP. Each user will
	receive N-1 RTP streams, each of which has its own RTCP channel that		receive N-1 RTP streams, each of which has its own RTCP channel that
	carries the participant identification.		carries the participant identification.
	8 Summary of Models		8 Summary of Models
	Table 1 shows a summary of the differences between the various		Table 1 shows a summary of the differences between the various
	models.		models.
	9 Security Considerations
	The use of a server that performs the mixing on behalf of other
	users, which is the case for all but one of the conference models
	described here, introduces security risks. That entity must be
	trusted by the others to properly mix the media - not omitting a
	stream, for example. As such, it is recommended that participants in
	a conference authenticate the identity of the server. In the dial-in,
	dial-out, and decentralized conferences, this will require
	authentication of responses by participants.
	Table 1: Summary of Models		Table 1: Summary of Models
	Name signaling media inviting joining discovering scale		Name signaling media inviting joining discovering scale
	End-Mixing tree tree normal normal RTCP small		End-Mixing tree tree normal normal RTCP small
	invite invite		invite invite
	Multicast pairs m-cast normal multicast RTCP large		Multicast pairs m-cast normal multicast RTCP large
	invite join		invite join
	Dial-Up star star refer normal RTCP medium		Dial-Up star star refer normal RTCP medium
	invite		invite
	Ad-Hoc star star refer normal RTCP medium		Ad-Hoc star star refer normal RTCP medium
	invite		invite
	Dial-Out star star refer normal RTCP medium		Dial-Out star star refer normal RTCP medium
	invite		invite
	Decentral star fullmesh refer + normal RTCP medium		Decentral star fullmesh refer + normal RTCP medium
	server invite and		server invite and
	messaging server msg.		messaging server msg.
			9 Security Considerations
			The use of a server that performs the mixing on behalf of other
			users, which is the case for all but one of the conference models
			described here, introduces security risks. That entity must be
			trusted by the others to properly mix the media - not omitting a
			stream, for example. As such, it is recommended that participants in
			a conference authenticate the identity of the server. In the dial-in,
			dial-out, and decentralized conferences, this will require
			authentication of responses by participants.
	Mixing also eliminates the privacy possible with end-to-end media		Mixing also eliminates the privacy possible with end-to-end media
	transport with mixing in the receivers. Such privacy is still		transport with mixing in the receivers. Such privacy is still
	possible in the large-scale multicast conferences, but requires		possible in the large-scale multicast conferences, but requires
	shared keying material for the conference. Doing this for highly		shared keying material for the conference. Doing this for highly
	dynamic groups is still an open research problem.		dynamic groups is still an open research problem.
	10 Conclusion		10 Conclusion
	In this draft, we have shown how to use baseline SIP (assuming		In this draft, we have shown how to use baseline SIP (assuming
	endpoints that support the mixing and/or third party call control		endpoints that support the mixing and/or third party call control
	feature sets) to construct several multiparty conferencing models.		feature sets) to construct several multiparty conferencing models.
	These include end system mixing, large-scale multicast conferences,		These include end system mixing, large-scale multicast conferences,
	dial-in conference servers, dial-out conferences, ad-hoc centralized		dial-in conference servers, dial-out conferences, ad-hoc centralized
	conferences, and centralized signaling, distributed media		conferences, and centralized signaling, distributed media
	conferences.		conferences.
	11 Acknowledgements		11 Acknowledgements
	We would like to thank Mary Barnes for her comments and input.		We would like to thank Mary Barnes for her comments and input.
	12 Changes since -00		12 Authors Addresses
	o Added call flow examples.
	o Added open issues within text.
	o Added additional call flow for adding users to conference, by
	sending REFER to conference server with Refer-To of new
	participant.
	o Discussed conference servers generating RTCP based on
	authenticated SIP identities.
	13 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
	14 Bibliography		13 Normative References
			14 Informative References
	[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:		[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
	session initiation protocol," Request for Comments 2543, Internet		protocol," Internet Draft, Internet Engineering Task Force, Feb.
	Engineering Task Force, Mar. 1999.		2002. Work in progress.
	[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a		[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
	transport protocol for real-time applications," Request for Comments		transport protocol for real-time applications," RFC 1889, Internet
	1889, Internet Engineering Task Force, Jan. 1996.		Engineering Task Force, Jan. 1996.
	[3] M. Handley and V. Jacobson, "SDP: session description protocol,"		[3] M. Handley and V. Jacobson, "SDP: session description protocol,"
	Request for Comments 2327, Internet Engineering Task Force, Apr.		RFC 2327, Internet Engineering Task Force, Apr. 1998.
	1998.
	[4] M. Handley, C. Perkins, and E. Whelan, "Session announcement		[4] M. Handley, C. Perkins, and E. Whelan, "Session announcement
	protocol," Request for Comments 2974, Internet Engineering Task		protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.
	Force, Oct. 2000.
	[5] D. Thaler, M. Handley, and D. Estrin, "The internet multicast		[5] D. Thaler, M. Handley, and D. Estrin, "The internet multicast
	address allocation architecture," Request for Comments 2908, Internet		address allocation architecture," RFC 2908, Internet Engineering Task
	Engineering Task Force, Sept. 2000.		Force, Sept. 2000.
	[6] W. Fenner, "Internet group management protocol, version 2,"		[6] W. Fenner, "Internet group management protocol, version 2," RFC
	Request for Comments 2236, Internet Engineering Task Force, Nov.		2236, Internet Engineering Task Force, Nov. 1997.
	1997.
	[7] D. Waitzman, C. Partridge, and S. E. Deering, "Distance vector		[7] D. Waitzman, C. Partridge, and S. E. Deering, "Distance vector
	multicast routing protocol," Request for Comments 1075, Internet		multicast routing protocol," RFC 1075, Internet Engineering Task
	Engineering Task Force, Nov. 1988.		Force, Nov. 1988.
	[8] J. Rosenberg and H. Schulzrinne, "Timer reconsideration for		[8] J. Rosenberg and H. Schulzrinne, "Timer reconsideration for
	enhanced RTP scalability," in Proceedings of the Conference on		enhanced RTP scalability," in Proceedings of the Conference on
	Computer Communications (IEEE Infocom) , (San Francisco, California),		Computer Communications (IEEE Infocom) , (San Francisco, California),
	March/April 1998.		March/April 1998.
	[9] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application		[9] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
	server component architecture for SIP," Internet Draft, Internet		server component architecture for SIP," Internet Draft, Internet
	Engineering Task Force, Mar. 2001. Work in progress.		Engineering Task Force, Mar. 2001. Work in progress.
	[10] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,		[10] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,
	A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest		A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest
	access authentication," Request for Comments 2617, Internet		access authentication," RFC 2617, Internet Engineering Task Force,
	Engineering Task Force, June 1999.		June 1999.
	[11] R. Sparks, "SIP call control," Internet Draft, Internet		[11] R. Sparks, "The SIP refer method," Internet Draft, Internet
	Engineering Task Force, Feb. 2001. Work in progress.		Engineering Task Force, June 2002. Work in progress.
	[12] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service		[12] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
	location protocol, version 2," Request for Comments 2608, Internet		location protocol, version 2," RFC 2608, Internet Engineering Task
	Engineering Task Force, June 1999.		Force, June 1999.
	[13] J. Rosenberg et al. , "SIP extensions for presence," Internet		[13] J. Rosenberg, "Session initiation protocol (SIP) extensions for
	Draft, Internet Engineering Task Force, Apr. 2001. Work in progress.		presence," Internet Draft, Internet Engineering Task Force, May 2002.
			Work in progress.
	[14] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo,		[14] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo,
	"Third party call control in SIP," Internet Draft, Internet		"Third party call control in SIP," Internet Draft, Internet
	Engineering Task Force, Mar. 2001. Work in progress.		Engineering Task Force, Nov. 2001. Work in progress.
			Full Copyright Statement
			Copyright (c) The Internet Society (2002). All Rights Reserved.
			This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			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.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
			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. 27 change blocks.
	85 lines changed or deleted		225 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/