< draft-rosenberg-sipping-sip-arch-00.txt		draft-rosenberg-sipping-sip-arch-01.txt >
	SIPPING J. Rosenberg		SIPPING J. Rosenberg
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: August 15, 2005 H. Schulzrinne		Expires: January 18, 2006 H. Schulzrinne
	Columbia University		Columbia University
	February 14, 2005		July 17, 2005
	Architecture and Design Principles of the Session Initiation Protocol		Architecture and Design Principles of the Session Initiation Protocol
	(SIP)		(SIP)
	draft-rosenberg-sipping-sip-arch-00		draft-rosenberg-sipping-sip-arch-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 15, 2005.		This Internet-Draft will expire on January 18, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The Session Initiation Protocol (SIP) and its many extensions and		The Session Initiation Protocol (SIP) and its many extensions and
	supporting technologies define a solution for multimedia		supporting technologies define a solution for multimedia
	communications on the Internet. Much of the design and architecture		communications on the Internet. Much of the design and architecture
	skipping to change at page 3, line 8 ¶		skipping to change at page 3, line 8 ¶
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Informative References . . . . . . . . . . . . . . . . . . . . 14		8. Informative References . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . 19
	1. Introduction		1. Introduction
	The Session Initiation Protocol (SIP) [1] and its many extensions and		The Session Initiation Protocol (SIP) [1] and its many extensions and
	supporting technologies (for example, [2][3][4][6]) define a solution		supporting technologies (for example, [2] [3] [4] [6]) define a
	for multimedia communications on the Internet. Much of the design		solution for multimedia communications on the Internet. Much of the
	and architecture for SIP is based on a key set of architectural		design and architecture for SIP is based on a key set of
	principles which, while commonly discussed on mailing lists and other		architectural principles which, while commonly discussed on mailing
	forums, have not been explicitly captured.		lists and other forums, have not been explicitly captured.
	Section 2 of RFC 3261 briefly mentions a few of the design principles		Section 2 of RFC 3261 briefly mentions a few of the design principles
	behind SIP. In particular, it mentions that SIP is not a vertically		behind SIP. In particular, it mentions that SIP is not a vertically
	integrated system, but rather a component of an overall solution. It		integrated system, but rather a component of an overall solution. It
	also mentions that SIP does not provide services, but rather,		also mentions that SIP does not provide services, but rather,
	provides primitives which can be used to build up more complex		provides primitives which can be used to build up more complex
	services.		services.
	The guidelines for authors of SIP extensions [7] provides additional		The guidelines for authors of SIP extensions [7] provides additional
	guidance in Section 3.2. In particular, it mentions session		guidance in Section 3.2. In particular, it mentions session
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	common ground.		common ground.
	2.4 Client Multiplicity		2.4 Client Multiplicity
	SIP was built under the assumption that users would have multiple		SIP was built under the assumption that users would have multiple
	clients at their disposal - softphones, hardphones, cell phones,		clients at their disposal - softphones, hardphones, cell phones,
	PDAs, and so on, and that these devices could be in use		PDAs, and so on, and that these devices could be in use
	simultaneously. Users can make multiple calls at the same time, each		simultaneously. Users can make multiple calls at the same time, each
	from a different user agent. Similarly, users can receive calls that		from a different user agent. Similarly, users can receive calls that
	"ring" each device at the same time or in sequence. Forking, which		"ring" each device at the same time or in sequence. Forking, which
	allows multiple devices to be wrong at once, is a key part of the		allows multiple devices to be rung at once, is a key part of the
	baseline SIP specification.		baseline SIP specification.
	2.5 Multimedia		2.5 Multimedia
	Although much actual usage of SIP is in support of voice		Although much actual usage of SIP is in support of voice
	communications, SIP was designed to be media agnostic, and thus		communications, SIP was designed to be media agnostic, and thus
	facilitate the deployment of multimedia. Audio, video, text and		facilitate the deployment of multimedia. Audio, video, text and
	messaging are all possible with SIP. Nothing in SIP itself depends		messaging are all possible with SIP. Nothing in SIP itself depends
	on or assumes a particular media stream type.		on or assumes a particular media stream type.
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	render based on that selection. Indeed, the way in which the user is		render based on that selection. Indeed, the way in which the user is
	"alerted" and the mechanism by which they select the stream to render		"alerted" and the mechanism by which they select the stream to render
	may vary widely depending on the type of endpoint. A dumb phone may		may vary widely depending on the type of endpoint. A dumb phone may
	do what is done today in the PSTN - provide an audio cue to alert the		do what is done today in the PSTN - provide an audio cue to alert the
	user, and then use the hookflash to switch between calls. However,		user, and then use the hookflash to switch between calls. However,
	on a PC-based softphone, a window pop can be used to alert the user		on a PC-based softphone, a window pop can be used to alert the user
	to an incoming call, and then the user can use a mouse to select the		to an incoming call, and then the user can use a mouse to select the
	call (perhaps represented as an object in a window) that they wish to		call (perhaps represented as an object in a window) that they wish to
	hear. The interface may be different once again for a television set		hear. The interface may be different once again for a television set
	top box, which may render information about an incoming call on the		top box, which may render information about an incoming call on the
	TV screen, and then use a button the remote to indicate that the call		TV screen, and then use a button on the remote to indicate that the
	should be taken.		call should be taken.
	In order to allow each of these endpoints to handle call waiting in		In order to allow each of these endpoints to handle call waiting in
	the way that is appropriate for that endpoint, the feature		the way that is appropriate for that endpoint, the feature
	intelligence needs to reside in the endpoint itself. In a		intelligence needs to reside in the endpoint itself. In a
	centralized switch type of architecture, such as those provided by		centralized switch type of architecture, such as those provided by
	the Media Gateway Control Protocol (MGCP) [13] and Megaco [14], the		the Media Gateway Control Protocol (MGCP) [13] and Megaco [14], the
	endpoint is a slave to the controller, and the feature intelligence		endpoint is a slave to the controller, and the feature intelligence
	resides in the controller based on an assumed model of the user		resides in the controller based on an assumed model of the user
	interface and capabilities of the devices. Those architectures		interface and capabilities of the devices. Those architectures
	fundamentally limit endpoint innovation because they provide no		fundamentally limit endpoint innovation because they provide no
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	a feature requires some kind of communications with other elements in		a feature requires some kind of communications with other elements in
	the network. In those cases, SIP prefers to specify a generic		the network. In those cases, SIP prefers to specify a generic
	primitive that can support many features.		primitive that can support many features.
	3.4 Endpoint Fate Sharing		3.4 Endpoint Fate Sharing
	A benefit of the smart endpoint model described in Section 3.2 is		A benefit of the smart endpoint model described in Section 3.2 is
	that call state and application state is co-located with the		that call state and application state is co-located with the
	endpoints of the call itself. This means that the only way in which		endpoints of the call itself. This means that the only way in which
	the call or application can fail is if the endpoints themselves fail.		the call or application can fail is if the endpoints themselves fail.
	Of course, if the endpoints fail, the call is over even in any case.		Of course, if the endpoints fail, the call is over in any case. This
	This allows for fate sharing, and it allows SIP systems to be highly		allows for fate sharing, and it allows SIP systems to be highly
	available.		available.
	3.5 Component Based Design		3.5 Component Based Design
	Section 3.3 alludes to another important principle behind SIP design		Section 3.3 alludes to another important principle behind SIP design
	- the use of protocol components and primitives. Generally speaking,		- the use of protocol components and primitives. Generally speaking,
	SIP does not specify a vertical communications system. Rather, SIP		SIP does not specify a vertical communications system. Rather, SIP
	itself is just a component in any complete communications system.		itself is just a component in any complete communications system.
	SIP is designed to work hand-in-hand with other components, such as		SIP is designed to work hand-in-hand with other components, such as
	session descriptions like the Session Description Protocol (SDP) [6],		session descriptions like the Session Description Protocol (SDP) [6],
	skipping to change at page 9, line 49 ¶		skipping to change at page 9, line 49 ¶
	As an example on the constraints, SIP signaling needs to be		As an example on the constraints, SIP signaling needs to be
	congestion controlled in order to run cooperatively on the Internet.		congestion controlled in order to run cooperatively on the Internet.
	The public Internet also means that SIP cannot assume a particular IP		The public Internet also means that SIP cannot assume a particular IP
	network topology, and needs to work in the face of packet loss and		network topology, and needs to work in the face of packet loss and
	delays.		delays.
	As an example of the benefits, SIP can make use of many of the core		As an example of the benefits, SIP can make use of many of the core
	Internet services. SIP uses the DNS for discovery of SIP servers		Internet services. SIP uses the DNS for discovery of SIP servers
	[3], load balancing and reliability, DHCP for client configuration		[3], load balancing and reliability, DHCP for client configuration
	[28][29], and a certificate infrastructure for SIP over TLS [1]. SIP		[28] [29], and a certificate infrastructure for SIP over TLS [1].
	does not require any of these to operate, but it leverages them when		SIP does not require any of these to operate, but it leverages them
	SIP runs on an IP network where they are available.		when SIP runs on an IP network where they are available.
	3.8 Generality over Efficiency		3.8 Generality over Efficiency
	When designing network protocols, there is often a tradeoff between		When designing network protocols, there is often a tradeoff between
	efficiency (measured in terms of bandwidth, memory or processing) and		efficiency (measured in terms of bandwidth, memory or processing) and
	generality. SIP was designed under the assumption that continuous		generality. SIP was designed under the assumption that continuous
	improvements in CPU, memory and bandwidth availability, fueled by		improvements in CPU, memory and bandwidth availability, fueled by
	Moore's law and its related principles, would make efficiency a		Moore's law and its related principles, would make efficiency a
	transient benefit, while generality is a permanent one. As a result,		transient benefit, while generality is a permanent one. As a result,
	SIP generally prefers to build for generality at the expense of		SIP generally prefers to build for generality at the expense of
	efficiency. This is not an absolute truth, but it has served as a		efficiency. This is not an absolute truth, but it has served as a
	general guideline.		general guideline.
	As a specific example, SIP has not tried to parsimonious in its usage		As a specific example, SIP has not tried to be parsimonious in its
	of bits in message fields. Rather, in environments where message		usage of bits in message fields. Rather, in environments where
	overhead is an issue (such as wireless systems), message compression		message overhead is an issue (such as wireless systems), message
	is handled in a shim layer using Sigcomp so that it does not need to		compression is handled in a shim layer using Sigcomp so that it does
	pervade every extension that gets defined.		not need to pervade every extension that gets defined.
	3.9 Separation of Signaling and Media		3.9 Separation of Signaling and Media
	It is fundamental to the design of SIP that the path followed by the		It is fundamental to the design of SIP that the path followed by the
	media packets is independent of the path followed by the signaling		media packets is independent of the path followed by the signaling
	packets. This separation allows for the IP network to deliver the		packets. This separation allows for the IP network to deliver the
	media packets using the most direct and appropriate route it can,		media packets using the most direct and appropriate route it can,
	while the signaling packets, which are not as latency sensitive, can		while the signaling packets, which are not as latency sensitive, can
	follow a series of proxy elements needed for the processing of the		follow a series of proxy elements needed for the processing of the
	request. By separating the two, more complex proxy topologies can be		request. By separating the two, more complex proxy topologies can be
	skipping to change at page 11, line 32 ¶		skipping to change at page 11, line 32 ¶
	4.3 SIP URIs Identify Resources		4.3 SIP URIs Identify Resources
	SIP URIs are an important part of SIPs design. The SIP URI is an		SIP URIs are an important part of SIPs design. The SIP URI is an
	identifier for a communications resource, and that resource can be a		identifier for a communications resource, and that resource can be a
	user, a device, a service or some combination thereof. Traditional		user, a device, a service or some combination thereof. Traditional
	SIP addresses-of-records (AOR) identify users, but URIs have been		SIP addresses-of-records (AOR) identify users, but URIs have been
	defined that identify user agent instances [31], and voicemail		defined that identify user agent instances [31], and voicemail
	services [32], for example.		services [32], for example.
	Genreally speaking, it is not (and should not) be possible to inspect		Generally speaking, it is not (and should not) be possible to inspect
	a URI and conclude whether or not the URI identifies a user, device,		a URI and conclude whether or not the URI identifies a user, device,
	or a specific type of service. Only the owner of the domain on the		or a specific type of service. Only the owner of the domain on the
	right hand side of the @ sign can interpret or define the meaning of		right hand side of the @ sign can interpret or define the meaning of
	the resource identified on the left hand side. The owner of a domain		the resource identified on the left hand side. The owner of a domain
	must be able to, at will, change the nature of the resource		must be able to, at will, change the nature of the resource
	identified by any specific token on the left hand side of the @ sign.		identified by any specific token on the left hand side of the @ sign.
	It is quite appropriate for a SIP URI to identify a fairly complex		It is quite appropriate for a SIP URI to identify a fairly complex
	resource, and to use the URI to parameterize the service that gets		resource, and to use the URI to parameterize the service that gets
	invoked [33]. Ideally, a SIP URI is handed out and discovered		invoked [33]. Ideally, a SIP URI is handed out and discovered
	skipping to change at page 12, line 43 ¶		skipping to change at page 12, line 43 ¶
	SIP is meant to be used in an international setting. It supports		SIP is meant to be used in an international setting. It supports
	UTF-8 encoding of freeform text and declaration and negotiation of		UTF-8 encoding of freeform text and declaration and negotiation of
	languages.		languages.
	4.6 Explicit Intermediaries		4.6 Explicit Intermediaries
	Proxies represent a form of intermediary that operates on requests on		Proxies represent a form of intermediary that operates on requests on
	behalf of users. However, unlike other intermediaries like NATs and		behalf of users. However, unlike other intermediaries like NATs and
	firewalls, which are invisible to participants in the protocol,		firewalls, which are invisible to participants in the protocol,
	proxies are visible. They declare themselves through Via and		proxies are visible. They declare themselves through Via and Record-
	Record-Route header fields, their roles are well defined and bounded,		Route header fields, their roles are well defined and bounded, and
	and they are meant to act in concert with user agents. A proxy is		they are meant to act in concert with user agents. A proxy is
	involved in request processing only by the explicit request of a user		involved in request processing only by the explicit request of a user
	agent or another proxy. An element which intercepts a SIP message		agent or another proxy. An element which intercepts a SIP message
	not addressed to can not ever be considered a compliant proxy.		not addressed to can not ever be considered a compliant proxy.
	Furthermore, when proxies need to provide additional functions on		Furthermore, when proxies need to provide additional functions on
	behalf of user agents, this is always best done by explicit		behalf of user agents, this is always best done by explicit
	communications with the endpoints, rather than implicit behaviors.		communications with the endpoints, rather than implicit behaviors.
	Explicit cooperation with endpoints guarantess that SIP can continue		Explicit cooperation with endpoints guarantess that SIP can continue
	to provide the end-to-end security features that are important to its		to provide the end-to-end security features that are important to its
	design. As an example of this, if a proxy needs to restrict the set		design. As an example of this, if a proxy needs to restrict the set
	skipping to change at page 13, line 21 ¶		skipping to change at page 13, line 21 ¶
	message as it goes by.		message as it goes by.
	4.7 Guided Proxy Routing		4.7 Guided Proxy Routing
	Many SIP capabilities are provided by having an entity, either a user		Many SIP capabilities are provided by having an entity, either a user
	agent or a proxy server, predetermine a set of downstream proxy		agent or a proxy server, predetermine a set of downstream proxy
	resource that must be visited prior to completion of the request.		resource that must be visited prior to completion of the request.
	This is known as loose routing, and is a key part of SIPs design.		This is known as loose routing, and is a key part of SIPs design.
	The main task in loose routing is the discovery of the URI to use.		The main task in loose routing is the discovery of the URI to use.
	SIP provides several techniques for that, including the Record-Route		SIP provides several techniques for that, including the Record-Route
	mechanism in RFC 3261, the Path header field [35], and the		mechanism in RFC 3261, the Path header field [35], and the Service-
	Service-Route header field [36].		Route header field [36].
	4.8 Transport Protocol Independence		4.8 Transport Protocol Independence
	Another design choice made by SIP is its ability to run over several		Another design choice made by SIP is its ability to run over several
	different transport protocols. These include, at the moment, UDP,		different transport protocols. These include, at the moment, UDP,
	TCP and SCTP. The transport protocol must be capable of providing		TCP and SCTP. The transport protocol must be capable of providing
	just a minimal set of capabilities - the transport of 8-bit messages		just a minimal set of capabilities - the transport of 8-bit messages
	of at least around 1500 bytes. [[EDITORS NOTE: In hindsight its not		of at least around 1500 bytes. [[EDITORS NOTE: In hindsight its not
	clear that this flexibility has been worth the cost of complexity.		clear that this flexibility has been worth the cost of complexity.
	Mention this?]]		Mention this?]]
	4.9 Protocol Reuse		4.9 Protocol Reuse
	SIP has attempted to reuse many other protocol components as part of		SIP has attempted to reuse many other protocol components as part of
	its design. SIP uses MIME [37] for transport and encoding of body		its design. SIP uses MIME [37] for transport and encoding of body
	parts, reuses many of the HTTP [38] header fields and semantics,		parts, reuses many of the HTTP [38] header fields and semantics,
	makes use of the URI framework [39], including non-SIP URI like the		makes use of the URI framework [39], including non-SIP URIs like the
	tel URI [40], uses standardized transport protocols like SCTP [41]		tel URI [40], uses standardized transport protocols like SCTP [41]
	and existing security protocols, like TLS [42] and SMIME [43].		and existing security protocols, like TLS [42] and SMIME [43].
	This reuse flattens the learning curve for SIP and eases		This reuse flattens the learning curve for SIP and eases
	implementation by allowing developers to use off-the-shelf		implementation by allowing developers to use off-the-shelf
	implementations of its component parts.		implementations of its component parts.
	5. Security Considerations		5. Security Considerations
	This specification does not introduce any new security considerations		This specification does not introduce any new security considerations
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 14 ¶
	6. IANA Considerations		6. IANA Considerations
	This specification does not introduce any IANA considerations.		This specification does not introduce any IANA considerations.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Cary Fitzgerald for his "Tao of SIP"		The authors would like to thank Cary Fitzgerald for his "Tao of SIP"
	list.		list.
	8 Informative References		8. Informative References
	[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional		[2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
	Responses in Session Initiation Protocol (SIP)", RFC 3262, June		Responses in Session Initiation Protocol (SIP)", RFC 3262,
	2002.		June 2002.
	[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol		[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
	(SIP): Locating SIP Servers", RFC 3263, June 2002.		(SIP): Locating SIP Servers", RFC 3263, June 2002.
	[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with		[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
	Session Description Protocol (SDP)", RFC 3264, June 2002.		Session Description Protocol (SDP)", RFC 3264, June 2002.
	[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event		[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
	Notification", RFC 3265, June 2002.		Notification", RFC 3265, June 2002.
	[6] Handley, M. and V. Jacobson, "SDP: Session Description		[6] Handley, M. and V. Jacobson, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	[7] Rosenberg, J., "Guidelines for Authors of Extensions to the		[7] Rosenberg, J., "Guidelines for Authors of Extensions to the
	Session Initiation Protocol (SIP)",		Session Initiation Protocol (SIP)",
	draft-ietf-sip-guidelines-08 (work in progress), July 2004.		draft-ietf-sip-guidelines-09 (work in progress), February 2005.
	[8] Rosenberg, J., "A Presence Event Package for the Session		[8] Rosenberg, J., "A Presence Event Package for the Session
	Initiation Protocol (SIP)", RFC 3856, August 2004.		Initiation Protocol (SIP)", RFC 3856, August 2004.
	[9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and		[9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
	D. Gurle, "Session Initiation Protocol (SIP) Extension for		D. Gurle, "Session Initiation Protocol (SIP) Extension for
	Instant Messaging", RFC 3428, December 2002.		Instant Messaging", RFC 3428, December 2002.
	[10] Campbell, B., "The Message Session Relay Protocol",		[10] Campbell, B., "The Message Session Relay Protocol",
	draft-ietf-simple-message-sessions-09 (work in progress),		draft-ietf-simple-message-sessions-10 (work in progress),
	October 2004.		February 2005.
	[11] Rosenberg, J., "A Framework for Application Interaction in the		[11] Rosenberg, J., "A Framework for Application Interaction in the
	Session Initiation Protocol (SIP)",		Session Initiation Protocol (SIP)",
	draft-ietf-sipping-app-interaction-framework-03 (work in		draft-ietf-sipping-app-interaction-framework-04 (work in
	progress), October 2004.		progress), February 2005.
	[12] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller		[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
	Preferences for the Session Initiation Protocol (SIP)", RFC		Preferences for the Session Initiation Protocol (SIP)",
	3841, August 2004.		RFC 3841, August 2004.
	[13] Andreasen, F. and B. Foster, "Media Gateway Control Protocol		[13] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
	(MGCP) Version 1.0", RFC 3435, January 2003.		(MGCP) Version 1.0", RFC 3435, January 2003.
	[14] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, "Gateway		[14] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
	Control Protocol Version 1", RFC 3525, June 2003.		Control Protocol Version 1", RFC 3525, June 2003.
	[15] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for		[15] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
	the Session Initiation Protocol (SIP)",		the Session Initiation Protocol (SIP)",
	draft-ietf-sipping-dialog-package-05 (work in progress),		draft-ietf-sipping-dialog-package-06 (work in progress),
	November 2004.		April 2005.
	[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event		[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
	Package for Conference State",		Package for Conference State",
	draft-ietf-sipping-conference-package-08 (work in progress),		draft-ietf-sipping-conference-package-12 (work in progress),
	December 2004.		July 2005.
	[17] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,		[17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
	"RTP: A Transport Protocol for Real-Time Applications", RFC		"RTP: A Transport Protocol for Real-Time Applications",
	3550, July 2003.		RFC 3550, July 2003.
	[18] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z.		[18] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
	and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,		Z., and J. Rosenberg, "Signaling Compression (SigComp)",
	January 2003.		RFC 3320, January 2003.
	[19] Rosenberg, J., "A Session Initiation Protocol (SIP) Event		[19] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
	Package for Registrations", RFC 3680, March 2004.		Package for Registrations", RFC 3680, March 2004.
	[20] Mahy, R., "A Message Summary and Message Waiting Indication		[20] Mahy, R., "A Message Summary and Message Waiting Indication
	Event Package for the Session Initiation Protocol (SIP)", RFC		Event Package for the Session Initiation Protocol (SIP)",
	3842, August 2004.		RFC 3842, August 2004.
	[21] Rosenberg, J., "A Watcher Information Event Template-Package		[21] Rosenberg, J., "A Watcher Information Event Template-Package
	for the Session Initiation Protocol (SIP)", RFC 3857, August		for the Session Initiation Protocol (SIP)", RFC 3857,
	2004.		August 2004.
	[22] Sparks, R., "The Session Initiation Protocol (SIP) Refer		[22] Sparks, R., "The Session Initiation Protocol (SIP) Refer
	Method", RFC 3515, April 2003.		Method", RFC 3515, April 2003.
	[23] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation		[23] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
	Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.		Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
	[24] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)		[24] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
	"Join" Header", RFC 3911, October 2004.		"Join" Header", RFC 3911, October 2004.
	[25] Johnston, A. and R. Sparks, "Session Initiation Protocol		[25] Johnston, A. and R. Sparks, "Session Initiation Protocol
	Service Examples", draft-ietf-sipping-service-examples-07 (work		Service Examples", draft-ietf-sipping-service-examples-08 (work
	in progress), July 2004.		in progress), February 2005.
	[26] Jennings, C., Peterson, J. and M. Watson, "Private Extensions		[26] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
	to the Session Initiation Protocol (SIP) for Asserted Identity		to the Session Initiation Protocol (SIP) for Asserted Identity
	within Trusted Networks", RFC 3325, November 2002.		within Trusted Networks", RFC 3325, November 2002.
	[27] Peterson, J., "Enhancements for Authenticated Identity		[27] Peterson, J. and C. Jennings, "Enhancements for Authenticated
	Management in the Session Initiation Protocol (SIP)",		Identity Management in the Session Initiation Protocol (SIP)",
	draft-ietf-sip-identity-03 (work in progress), September 2004.		draft-ietf-sip-identity-05 (work in progress), May 2005.
	[28] Schulzrinne, H., "Dynamic Host Configuration Protocol		[28] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-
	(DHCP-for-IPv4) Option for Session Initiation Protocol (SIP)		for-IPv4) Option for Session Initiation Protocol (SIP)
	Servers", RFC 3361, August 2002.		Servers", RFC 3361, August 2002.
	[29] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration		[29] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
	Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)		Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
	Servers", RFC 3319, July 2003.		Servers", RFC 3319, July 2003.
	[30] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.		[30] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
	Rayhan, "Middlebox communication architecture and framework",		Rayhan, "Middlebox communication architecture and framework",
	RFC 3303, August 2002.		RFC 3303, August 2002.
	[31] Rosenberg, J., "Obtaining and Using Globally Routable User		[31] Rosenberg, J., "Obtaining and Using Globally Routable User
	Agent (UA) URIs (GRUU) in the Session Initiation Protocol		Agent (UA) URIs (GRUU) in the Session Initiation Protocol
	(SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004.		(SIP)", draft-ietf-sip-gruu-03 (work in progress),
			February 2005.
	[32] Jennings, C., "SIP Conventions for Voicemail URIs",		[32] Jennings, C., "SIP Conventions for Voicemail URIs",
	draft-jennings-sip-voicemail-uri-03 (work in progress), October		draft-jennings-sip-voicemail-uri-03 (work in progress),
	2004.		October 2004.
	[33] Campbell, B. and R. Sparks, "Control of Service Context using		[33] Campbell, B. and R. Sparks, "Control of Service Context using
	SIP Request-URI", RFC 3087, April 2001.		SIP Request-URI", RFC 3087, April 2001.
	[34] Hilt, V., "Session-Independent Session Initiation Protocol		[34] Hilt, V., "Session Initiation Protocol (SIP) Session Policies -
	(SIP) Policies - Mechanism and Policy Schema",		Document Format and Session-Independent Delivery Mechanism",
	draft-ietf-sipping-session-indep-policy-01 (work in progress),		draft-ietf-sipping-session-indep-policy-02 (work in progress),
	October 2004.		February 2005.
	[35] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)		[35] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
	Extension Header Field for Registering Non-Adjacent Contacts",		Extension Header Field for Registering Non-Adjacent Contacts",
	RFC 3327, December 2002.		RFC 3327, December 2002.
	[36] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)		[36] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
	Extension Header Field for Service Route Discovery During		Extension Header Field for Service Route Discovery During
	Registration", RFC 3608, October 2003.		Registration", RFC 3608, October 2003.
	[37] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[37] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message Bodies",		Extensions (MIME) Part One: Format of Internet Message Bodies",
	RFC 2045, November 1996.		RFC 2045, November 1996.
	[38] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,		[38] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
	Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --		Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
	HTTP/1.1", RFC 2616, June 1999.		HTTP/1.1", RFC 2616, June 1999.
	[39] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform		[39] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,		Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
	January 2005.		January 2005.
	[40] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,		[40] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
	December 2004.		December 2004.
	[41] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,		[41] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
	H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,		H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
	"Stream Control Transmission Protocol", RFC 2960, October 2000.		Paxson, "Stream Control Transmission Protocol", RFC 2960,
			October 2000.
	[42] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC		[42] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	2246, January 1999.		RFC 2246, January 1999.
	[43] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions		[43] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
	(S/MIME) Version 3.1 Message Specification", RFC 3851, July		(S/MIME) Version 3.1 Message Specification", RFC 3851,
	2004.		July 2004.
	Authors' Addresses		Authors' Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco Systems		Cisco Systems
	600 Lanidex Plaza		600 Lanidex Plaza
	Parsippany, NJ 07054		Parsippany, NJ 07054
	US		US
	Phone: +1 973 952-5000		Phone: +1 973 952-5000
	EMail: jdrosen@cisco.com		Email: jdrosen@cisco.com
	URI: http://www.jdrosen.net		URI: http://www.jdrosen.net
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	M/S 0401		M/S 0401
	1214 Amsterdam Ave.		1214 Amsterdam Ave.
	New York, NY 10027		New York, NY 10027
	US		US
	EMail: schulzrinne@cs.columbia.edu		Email: schulzrinne@cs.columbia.edu
	URI: http://www.cs.columbia.edu/~hgs		URI: http://www.cs.columbia.edu/~hgs
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 48 change blocks.
	92 lines changed or deleted		93 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/