SIPPING J. Rosenberg
Internet-Draft Cisco Systems
Expires: January 18, 2006 H. Schulzrinne
Columbia University
July 17, 2005
Architecture and Design Principles of the Session Initiation Protocol
(SIP)
draft-rosenberg-sipping-sip-arch-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Session Initiation Protocol (SIP) and its many extensions and
supporting technologies define a solution for multimedia
communications on the Internet. Much of the design and architecture
for SIP is based on a key set of architectural principles which,
while commonly discussed on mailing lists and other forums, have not
been explicitly captured. This document seeks to rectify that gap by
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 1]
Internet-Draft SIP Architecture July 2005
outlining the key set of architectural and design principles
underlying SIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 New Features and Services . . . . . . . . . . . . . . . . 3
2.2 Not a PSTN Replacement . . . . . . . . . . . . . . . . . . 4
2.3 Client Heterogeneity . . . . . . . . . . . . . . . . . . . 4
2.4 Client Multiplicity . . . . . . . . . . . . . . . . . . . 5
2.5 Multimedia . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architectural Principles . . . . . . . . . . . . . . . . . . . 5
3.1 Proxies are for Routing . . . . . . . . . . . . . . . . . 5
3.2 Endpoint Call State and Features . . . . . . . . . . . . . 6
3.3 Dialog Models, not Call Models . . . . . . . . . . . . . . 7
3.4 Endpoint Fate Sharing . . . . . . . . . . . . . . . . . . 8
3.5 Component Based Design . . . . . . . . . . . . . . . . . . 8
3.6 Logical Components, not Physical . . . . . . . . . . . . . 9
3.7 Designed for the Internet . . . . . . . . . . . . . . . . 9
3.8 Generality over Efficiency . . . . . . . . . . . . . . . . 10
3.9 Separation of Signaling and Media . . . . . . . . . . . . 10
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Proxies are Method, Body and Header Independent . . . . . 10
4.2 Full State Nature of INVITE . . . . . . . . . . . . . . . 11
4.3 SIP URIs Identify Resources . . . . . . . . . . . . . . . 11
4.4 Extensibility and Compatibility . . . . . . . . . . . . . 11
4.5 Internationalization . . . . . . . . . . . . . . . . . . . 12
4.6 Explicit Intermediaries . . . . . . . . . . . . . . . . . 12
4.7 Guided Proxy Routing . . . . . . . . . . . . . . . . . . . 13
4.8 Transport Protocol Independence . . . . . . . . . . . . . 13
4.9 Protocol Reuse . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 2]
Internet-Draft SIP Architecture July 2005
1. Introduction
The Session Initiation Protocol (SIP) [1] and its many extensions and
supporting technologies (for example, [2] [3] [4] [6]) define a
solution for multimedia communications on the Internet. Much of the
design and architecture for SIP is based on a key set of
architectural principles which, while commonly discussed on mailing
lists and other forums, have not been explicitly captured.
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
integrated system, but rather a component of an overall solution. It
also mentions that SIP does not provide services, but rather,
provides primitives which can be used to build up more complex
services.
The guidelines for authors of SIP extensions [7] provides additional
guidance in Section 3.2. In particular, it mentions session
independence, signaling and media path decoupling, multi-provider and
multi-hop as key design principles in SIP. It also touches on some
proxy principles, such as method and body independence and
transactional processing. It defines some of the characteristics of
SIP methods - the full-state nature of INVITE, and the usage of of
the request-URI as the key for forwarding. Finally, it mentions the
importance of heterogeneity and generality over efficiency.
This document expands upon many of these principles, and mentions
some of the other ones that are key to the SIP design philosophy.
2. Objectives
SIP's design is based around certain key objectives, including new
features and services (and its corollary, that SIP is not a PSTN
replacement), client heterogeneity, client multiplicity and
multimedia.
2.1 New Features and Services
Perhaps the most important objective behind SIP is the desire to
provide new communications features and services to users. SIP does
more than just provide the ability to make voice calls between
endpoints that look and feel like traditional telephones. It
provides new features that take advantage of smart endpoints,
multimedia and broadband connectivity.
One example is presence. SIP provides a generic event framework [5]
on which presence is defined [8]. Presence allows SIP endpoints to
obtain information on the ability, willingness and desire of another
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 3]
Internet-Draft SIP Architecture July 2005
user to communicate. In addition, SIP provides instant messaging
capabilities, including a Short Message Service (SMS) style messaging
[9] and a session mode [10].
Another example is the application interaction framework [11]. This
framework allows for endpoints to interact with network based
applications that utilize scripted user interfaces. One example if
such a usage would be a web front end that allows a user to control a
prepaid calling service.
Another example is the SIP caller preferences specification [12].
This specification allows a caller to direct call handling, and in
particular cause the call to be routed to specific types of
destination endpoints based on capabilities and characteristics.
2.2 Not a PSTN Replacement
A corollary to Section 2.1 is that SIP was not designed as a PSTN
replacement. It provides many features and services the PSTN cannot
provide, and it provides many services that the PSTN can provide, but
in a much different manner. It has not been a goal of SIP to be able
to directly map every message in ISUP or QSIG to SIP, or to be able
to map each ISUP parameter into a SIP parameter. SIP was designed to
facilitate communications in a way consistent with the architecture
of the Internet, and the underlying network characteristics of the
Internet result in a different technical solution.
2.3 Client Heterogeneity
The types of endpoints that connect to the Internet are extremely
diverse, ranging from the latest gaming PCs to small appliances with
barely enough memory and CPU for an IP stack. Similarly, devices
vary widely in their capabilities to render media, interact with the
user, and display information to the user. For this reason, SIP
itself was designed to support heterogenous clients with highly
variable capabilities.
SIP accomplishes this by providing an extension and capability
negotiation framework covering many aspects of the protocol.
Endpoints can negotiate support for new SIP option tags, new body
types, new SIP methods, new codecs, and so on. That baseline
framework can be leveraged for more complex situations. For example,
the app interaction framework uses MIME type negotiation to indicate
support for different types of scripts that control user interfaces.
This, in turn, allows the framework to negotiate user interface
capabilities with applications in the network.
In order to provide interoperability, SIP supports (and in many cases
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 4]
Internet-Draft SIP Architecture July 2005
mandates) fallback behaviors that allow differing endpoints to find a
common ground.
2.4 Client Multiplicity
SIP was built under the assumption that users would have multiple
clients at their disposal - softphones, hardphones, cell phones,
PDAs, and so on, and that these devices could be in use
simultaneously. Users can make multiple calls at the same time, each
from a different user agent. Similarly, users can receive calls that
"ring" each device at the same time or in sequence. Forking, which
allows multiple devices to be rung at once, is a key part of the
baseline SIP specification.
2.5 Multimedia
Although much actual usage of SIP is in support of voice
communications, SIP was designed to be media agnostic, and thus
facilitate the deployment of multimedia. Audio, video, text and
messaging are all possible with SIP. Nothing in SIP itself depends
on or assumes a particular media stream type.
3. Architectural Principles
This section discusses the key SIP architectural principles - the
usage of proxies for routing, the relegation of call state to
endpoints, the usage of dialog models and not call models, endpoint
fate sharing, component based design, logical roles, Internet-based
design, generality over efficiency, and separation of signaling and
media.
3.1 Proxies are for Routing
When designing a distributed system, one of the primary decisions is
to determine what functionality will be assigned to which components
of the system. SIP is a distributed system, composed of user agents
and proxies. Proxies usually run "in the network" and their role is
to faciliate rendezvous between users. The assumption in SIP is that
users can be reachable at many differing devices, each of which
provides a different set of features and capabilities. The problem,
then, is to determine how to route a SIP message from a caller to a
recipient, taking into account the desires of the caller, the
recipient, and the policies of the providers in between. Each proxy
on the path of a SIP request is responsible for executing the routing
logic based on the desires of the entities on whose behalf it is
acting. The final call routing decision is a composition of the
decisions made by each of the proxies along the request path.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 5]
Internet-Draft SIP Architecture July 2005
Because the role of the proxy is to connect users together in order
to communicate, once they are connected, the proxy's task is usually
done. SIP assumes that the IP network provides connectivity between
the endpoints, and therefore, any additional signaling that takes
place will frequently go end-to-end. This is not always the case;
NATs and firewalls break the end-to-end connectivity model, and thus
proxies frequently remain in the signaling path to facilitate the
exchange of SIP messages.
It is important to understand that a proxy is not a switch in the
traditional telephony sense. It does not maintain call state, and
thus many of the capabilities switches provide that derive from
management of call state are not provided by proxies. Switches do
provide call routing functions, and that aspect of switch behavior is
also provided by proxies. Furthermore, switch features traditionally
associated with routing are also commonly placed in proxies.
There were many factors driving the decision for proxies to take on
the role of rendezvous, as opposed to endpoint control and
management. Some of them include:
Availability: Because proxies do not need to maintain call state,
they can fail in the middle of a call without impacting calls in
progress. This makes SIP systems highly available at very low
cost.
Scalability: Proxies can be deployed in clusters, where any one of
the proxies in the cluster can serve a request. No state sharing
is needed across elements in the cluster, and proxies can be added
or removed from a cluster as capacity needs require. This results
in perfect linear scalability.
Flexibility: By relagating call state and many features to endpoints,
they can manifest themselves in ways that are appropriate for the
capabilities of user interfaces of the endpoint in question. This
gives SIP the flexibility to truly deal with diverse endpoints.
3.2 Endpoint Call State and Features
Since the role of the proxy is to facilitate rendezvous, the rest of
the capabilities needed in communications systems fall to the
endpoints. In particular, SIP endpoints are responsible for
maintaining call state, and for implementing features that require
awareness and management of that call state.
As an example, consider call waiting. In SIP, call waiting
functionality exists in the endpoints. This is because it is
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 6]
Internet-Draft SIP Architecture July 2005
relatively easy for endpoints to receive a new call while one is in
progress, alert the user, and then select which media stream to
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
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
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
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
hear. The interface may be different once again for a television set
top box, which may render information about an incoming call on the
TV screen, and then use a button on the remote to indicate that the
call should be taken.
In order to allow each of these endpoints to handle call waiting in
the way that is appropriate for that endpoint, the feature
intelligence needs to reside in the endpoint itself. In a
centralized switch type of architecture, such as those provided by
the Media Gateway Control Protocol (MGCP) [13] and Megaco [14], the
endpoint is a slave to the controller, and the feature intelligence
resides in the controller based on an assumed model of the user
interface and capabilities of the devices. Those architectures
fundamentally limit endpoint innovation because they provide no
ability for endpoints to differentiate themselves by providing better
features or enhanced user experiences; all of that resides in the
controller. In order for SIP to provide heterogeneous clients and
benefit from endpoint capabilities and innovation, it makes the
opposite design choice on purpose.
This aspect of SIP's design is often summarized as "smart endpoints".
3.3 Dialog Models, not Call Models
SIP does not define a "call model" in the traditional PSTN sense.
SIP does define a dialog model [15]. This model defines the state
associated with a communications context between a pair of endpoints.
However, there is a fundamental difference between a call model and
the dialog model. A call model encompasses nearly all of the
fullness of the application state machine that is executing based on
the underlying protocols. In SIP, this is not so. SIP presumes that
it is being used by some higher layer application that is making
sense of the various dialogs and SIP messages that are being
exchanged. The state machine governing the operation of that
application is not standardized by SIP, and purposefully so. By
allowing it to be endpoint and application specific, SIP allows for
numerous applications and usages not originally envisioned in the
original design of the protocol.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 7]
Internet-Draft SIP Architecture July 2005
This particular facet of SIP's design has allowed it to be applied to
problems as diverse as Push-to-Talk and home automation. Though
sometimes these usages are not really a good fit for SIP, they are
demonstrable validations of this design goal.
A direct consequence of this design approach is that SIP doesn't
generally standardize features. In many cases, features can execute
within an endpoint without any involvement or awareness from other
endpoints. Call waiting is a good example of that. In other cases,
a feature requires some kind of communications with other elements in
the network. In those cases, SIP prefers to specify a generic
primitive that can support many features.
3.4 Endpoint Fate Sharing
A benefit of the smart endpoint model described in Section 3.2 is
that call state and application state is co-located with the
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.
Of course, if the endpoints fail, the call is over in any case. This
allows for fate sharing, and it allows SIP systems to be highly
available.
3.5 Component Based Design
Section 3.3 alludes to another important principle behind SIP design
- the use of protocol components and primitives. Generally speaking,
SIP does not specify a vertical communications system. Rather, SIP
itself is just a component in any complete communications system.
SIP is designed to work hand-in-hand with other components, such as
session descriptions like the Session Description Protocol (SDP) [6],
media transport like the Real Time Transport Protocol (RTP) [17] and
signaling compression like SigComp [18].
SIP itself provides capabilities through component functions that can
be composed together to provide more complex functions. As an
example, most of the call control capabilities SIP enables are done
through a combination of two classes of components - notification and
manipulation. SIP provides a generic event framework [5] that allows
a user agent to learn about state elsewhere in the network. That
framework is used to support notifications about registration state
[19], dialog state [15], conference state [16], messaging state [20],
presence state [8] and subscription state [21]. The content of the
notifications across these packages allow an endpoint to gain
awareness about the state of much of a SIP system (subject to
authorization, of course).
With awareness about the state of parts of the SIP system, several
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 8]
Internet-Draft SIP Architecture July 2005
SIP components allow an endpoint to manipulate that state. The REFER
method [22] allows endpoints to ask other endpoints to generate SIP
requests. The Join [24] and Replaces [23] header fields allow an
endpoint to merge and split dialogs.
As an example of building more complex features from these
primitives, consider single line extension, as described in [25].
This feature is possible by having each line in the group use the
dialog event package to learn about calls made to and from the other
lines (the notification part), and then the Join mechanism for adding
a line to an existing call (the manipulation part).
3.6 Logical Components, not Physical
SIP defines its functionality by defining the exchange of messages
between logical components in a distributed system. These components
- user agents, proxies, redirect servers and registrars, are only
logical, not physical. SIP does not dictate that these components be
deployed as distinct servers. The expectation is that actual
products will combine many logical functions into a single "box" as
defined by business needs.
Indeed, many SIP specifications define logical functions that are
purely logical; in other words, they must be co-located with some
other logical component, usually a proxy or a user agent. The
privacy service [26] and the authentication service [27] are two
examples of this.
3.7 Designed for the Internet
SIP was designed for operation on the public Internet. That is not
to say that it can't also be used on private IP networks; it can.
However, the public Internet introduces a number of constraints and
also a number of benefits that have been taken into account in SIPs
design.
As an example on the constraints, SIP signaling needs to be
congestion controlled in order to run cooperatively on the Internet.
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
delays.
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
[3], load balancing and reliability, DHCP for client configuration
[28] [29], and a certificate infrastructure for SIP over TLS [1].
SIP does not require any of these to operate, but it leverages them
when SIP runs on an IP network where they are available.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 9]
Internet-Draft SIP Architecture July 2005
3.8 Generality over Efficiency
When designing network protocols, there is often a tradeoff between
efficiency (measured in terms of bandwidth, memory or processing) and
generality. SIP was designed under the assumption that continuous
improvements in CPU, memory and bandwidth availability, fueled by
Moore's law and its related principles, would make efficiency a
transient benefit, while generality is a permanent one. As a result,
SIP generally prefers to build for generality at the expense of
efficiency. This is not an absolute truth, but it has served as a
general guideline.
As a specific example, SIP has not tried to be parsimonious in its
usage of bits in message fields. Rather, in environments where
message overhead is an issue (such as wireless systems), message
compression is handled in a shim layer using Sigcomp so that it does
not need to pervade every extension that gets defined.
3.9 Separation of Signaling and Media
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
packets. This separation allows for the IP network to deliver the
media packets using the most direct and appropriate route it can,
while the signaling packets, which are not as latency sensitive, can
follow a series of proxy elements needed for the processing of the
request. By separating the two, more complex proxy topologies can be
utilized without concern for the impact on voice quality.
4. Design Principles
This section discusses some of the design principles used in SIP's
design. They are not as fundamental as the architectural principles,
but represent key design choices that were made.
4.1 Proxies are Method, Body and Header Independent
Since the role of the proxy is to provide rendezvous, the primary
information from the message used by the proxy is the request URI,
Via, Route and Record-Route header fields. Extensions can also
define new header fields that are relevant for proxy processing, such
as the Accept-Contact and Request-Disposition header fields [12].
However, except for the notable exceptions of ACK and CANCEL, proxy
routing of a request does not normally depend on the request method.
This allows SIP's rendezvous functions to be provided to other
functions besides session initiation. The same is true for SIP
bodies, which are of interest end-to-end and not used by proxies.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 10]
Internet-Draft SIP Architecture July 2005
That said, the specifications do not prohibit proxies from invoking
special routing logic based on method or other information in the
message. Such behaviors are typical of distributed proxy networks
where the overall processing of a SIP user agent is distributed
across multiple components, and a proxy is used to route messages to
the appropriate component.
4.2 Full State Nature of INVITE
One of the important design choices made by SIP is that each INVITE
request within a dialog conveys the full state of the session. For
example, instead of a re-INVITE indicating that a video session
should be added, a re-INVITE would state that the session is being
updated and now includes audio and video. This characteristic of the
INVITE method is useful for systems that perform inspection of the
INVITE message in order to manipulate some underlying network state.
An example of this is the MIDCOM framework [30].
4.3 SIP URIs Identify Resources
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
user, a device, a service or some combination thereof. Traditional
SIP addresses-of-records (AOR) identify users, but URIs have been
defined that identify user agent instances [31], and voicemail
services [32], for example.
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,
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
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
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
resource, and to use the URI to parameterize the service that gets
invoked [33]. Ideally, a SIP URI is handed out and discovered
through other means, such as presence or on a business card.
However, it is not desirable for a SIP URI to be constructed based on
pre-determined awareness of the type of resources provided by a
domain.
4.4 Extensibility and Compatibility
Extensibility has been a key design goal for SIP. SIP assumed that
many usages would arise which could not be forseen at the time SIP
was specified. SIP needed to be able to support those future needs,
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 11]
Internet-Draft SIP Architecture July 2005
yet still be interoperable with older implementations. It is for
this reason that SIP provides a fairly complex extensibility
framework. New methods can be defined, new header fields, new body
types, and new parameters. Several header fields, including the
Accept, Accept-Language, Allow, Supported, Require, Proxy-Require,
Accept-Encoding and Unsupported header fields, have been defined to
facilitate negotiation of support for extensions.
SIP provides two general modes for usage of extensions - "asking
permission" and "asking forgiveness". In the former modality, an
endpoint first discovers the capabilities of a peer, either through
an OPTIONS message or through capability header fields exchanged
during dialog establishment. Once they are discovered, those
extensions can be safely used. In the latter modality, an initial
request makes use of an extension, and then through either the
Require or Proxy-Require header field, tells the peer to reject the
request if the extension is not supported.
SIP also differentiates between extensions that are specific to user
agents, and those that are specific to proxies. This is due to the
differing roles of proxies and user agents in the SIP network.
In all cases, interoperability is only achieved by being able to fall
back to or support baseline behavior. This is discussed extensively
in [7]. An implementation that uses an extension but does not
provide fallback is not compliant to the SIP specifications, and
should be considered no better than proprietary.
4.5 Internationalization
SIP is meant to be used in an international setting. It supports
UTF-8 encoding of freeform text and declaration and negotiation of
languages.
4.6 Explicit Intermediaries
Proxies represent a form of intermediary that operates on requests on
behalf of users. However, unlike other intermediaries like NATs and
firewalls, which are invisible to participants in the protocol,
proxies are visible. They declare themselves through Via and Record-
Route header fields, their roles are well defined and bounded, and
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
agent or another proxy. An element which intercepts a SIP message
not addressed to can not ever be considered a compliant proxy.
Furthermore, when proxies need to provide additional functions on
behalf of user agents, this is always best done by explicit
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 12]
Internet-Draft SIP Architecture July 2005
communications with the endpoints, rather than implicit behaviors.
Explicit cooperation with endpoints guarantess that SIP can continue
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
of audio codecs used by a user agent, it is far better to use the
session policy mechanisms [34] to ask the client to discard the
codec, than for the proxy to attempt to modify the SDP in an INVITE
message as it goes by.
4.7 Guided Proxy Routing
Many SIP capabilities are provided by having an entity, either a user
agent or a proxy server, predetermine a set of downstream proxy
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.
The main task in loose routing is the discovery of the URI to use.
SIP provides several techniques for that, including the Record-Route
mechanism in RFC 3261, the Path header field [35], and the Service-
Route header field [36].
4.8 Transport Protocol Independence
Another design choice made by SIP is its ability to run over several
different transport protocols. These include, at the moment, UDP,
TCP and SCTP. The transport protocol must be capable of providing
just a minimal set of capabilities - the transport of 8-bit messages
of at least around 1500 bytes. [[EDITORS NOTE: In hindsight its not
clear that this flexibility has been worth the cost of complexity.
Mention this?]]
4.9 Protocol Reuse
SIP has attempted to reuse many other protocol components as part of
its design. SIP uses MIME [37] for transport and encoding of body
parts, reuses many of the HTTP [38] header fields and semantics,
makes use of the URI framework [39], including non-SIP URIs like the
tel URI [40], uses standardized transport protocols like SCTP [41]
and existing security protocols, like TLS [42] and SMIME [43].
This reuse flattens the learning curve for SIP and eases
implementation by allowing developers to use off-the-shelf
implementations of its component parts.
5. Security Considerations
This specification does not introduce any new security considerations
for the Internet. However, SIP does introduce new considerations,
and those are discussed in the SIP specification and its extensions.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 13]
Internet-Draft SIP Architecture July 2005
6. IANA Considerations
This specification does not introduce any IANA considerations.
7. Acknowledgements
The authors would like to thank Cary Fitzgerald for his "Tao of SIP"
list.
8. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[7] Rosenberg, J., "Guidelines for Authors of Extensions to the
Session Initiation Protocol (SIP)",
draft-ietf-sip-guidelines-09 (work in progress), February 2005.
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[10] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10 (work in progress),
February 2005.
[11] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)",
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 14]
Internet-Draft SIP Architecture July 2005
draft-ietf-sipping-app-interaction-framework-04 (work in
progress), February 2005.
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[13] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[14] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.
[15] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-06 (work in progress),
April 2005.
[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.
[17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003.
[18] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)",
RFC 3320, January 2003.
[19] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[20] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
[21] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857,
August 2004.
[22] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[23] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 15]
Internet-Draft SIP Architecture July 2005
[24] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
[25] Johnston, A. and R. Sparks, "Session Initiation Protocol
Service Examples", draft-ietf-sipping-service-examples-08 (work
in progress), February 2005.
[26] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[27] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-05 (work in progress), May 2005.
[28] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-
for-IPv4) Option for Session Initiation Protocol (SIP)
Servers", RFC 3361, August 2002.
[29] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", RFC 3319, July 2003.
[30] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002.
[31] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-03 (work in progress),
February 2005.
[32] Jennings, C., "SIP Conventions for Voicemail URIs",
draft-jennings-sip-voicemail-uri-03 (work in progress),
October 2004.
[33] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[34] Hilt, V., "Session Initiation Protocol (SIP) Session Policies -
Document Format and Session-Independent Delivery Mechanism",
draft-ietf-sipping-session-indep-policy-02 (work in progress),
February 2005.
[35] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 16]
Internet-Draft SIP Architecture July 2005
[36] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003.
[37] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[38] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[39] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[40] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[41] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[42] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[43] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
Authors' Addresses
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 17]
Internet-Draft SIP Architecture July 2005
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027
US
Email: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 18]
Internet-Draft SIP Architecture July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg & Schulzrinne Expires January 18, 2006 [Page 19]