Internet DRAFT - draft-rosenberg-sipping-sip-arch

draft-rosenberg-sipping-sip-arch






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]