SIP J. Rosenberg
Internet-Draft Cisco Systems
Expires: August 31, 2006 February 27, 2006
A Hitchhikers Guide to the Session Initiation Protocol (SIP)
draft-rosenberg-sip-hitchhikers-guide-00
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 August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) is the subject of numerous
specifications that have been produced by the IETF. It can be
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP. Don't Panic! This
specification serves as a guide to the SIP RFC series. It lists the
specifications under the SIP umbrella, briefly summarizes each, and
groups them into categories.
Rosenberg Expires August 31, 2006 [Page 1]
Internet-Draft Hitchhikers Guide to SIP February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope of this Document . . . . . . . . . . . . . . . . . . . . 3
3. Core SIP Specifications . . . . . . . . . . . . . . . . . . . 5
4. Public Switched Telephone Network (PSTN) Interworking . . . . 7
5. General Purpose Infrastructure Extensions . . . . . . . . . . 8
6. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 10
7. Call Control Primitives . . . . . . . . . . . . . . . . . . . 10
8. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 12
10. Operations and Management . . . . . . . . . . . . . . . . . 13
11. SIP Compression . . . . . . . . . . . . . . . . . . . . . . 13
12. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . 13
13. Security Mechanisms . . . . . . . . . . . . . . . . . . . . 14
14. Instant Messaging and Presence . . . . . . . . . . . . . . . 15
15. Emergency Services . . . . . . . . . . . . . . . . . . . . . 15
16. Security Considerations . . . . . . . . . . . . . . . . . . 15
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
18. Informative References . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Rosenberg Expires August 31, 2006 [Page 2]
Internet-Draft Hitchhikers Guide to SIP February 2006
1. Introduction
The Session Initiation Protocol (SIP) [1] is the subject of numerous
specifications that have been produced by the IETF. It can be
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP. Don't Panic! This
specification serves as a guide to the SIP RFC series. It lists the
specifications under the SIP umbrella. For each specification, a
paragraph or so description is included that summarizes the purpose
of the specification. Each specification also includes a letter that
designates its category in the standards track [2]. These values
are:
S: Standards Track (Proposed Standard, Draft Standard, or Standard)
E: Experimental
B: Best Current Practice
I: Informational
The specifications are grouped together by topic. Typically, SIP
extensions fit naturally into topic areas, and implementations
interested in a particular topic often implement many or all of the
specifications in that area.
This document itself is not an update to RFC 3261 or an extension to
SIP. It is an informational document, meant to guide newcomers and
implementors to the SIP suite of specifications.
2. Scope of this Document
It is very difficult to enumerate the set of SIP specifications.
This is because there are many protocols that are intimately related
to SIP and used by nearly all SIP implementations, but are not
formally SIP extensions. As such, this document formally defines a
"SIP specification" as any specification that defines an extension to
SIP itself, where an extension is a mechanism that changes or updates
in some way a behavior specified in RFC 3261. This is in contrast to
the "SIP family of specifications", which represent the set of
specifications that define protocols that are integral parts of any
SIP deployment, but are not SIP extensions per se. The SIP family of
specifications includes the following specifications and their
respective extensions:
Rosenberg Expires August 31, 2006 [Page 3]
Internet-Draft Hitchhikers Guide to SIP February 2006
RFC 3550: Real Time Transport Protocol (RTP) RTP [4] is the
specification that started it all. It is the first in a long line
of IETF specifications related to multimedia communications. Its
initial version, RFC 1889 [3] was first specified in January of
1996. RTP is used to carry multimedia traffic, including voice,
video and text, and is set up by SIP. There are countless
extensions and payload formats (possibly as many as 42) defined
for RTP.
RFC 2327: The Session Description Protocol (SDP) RFC 2327 [5] defines
the payload carried in SIP messages for describing a multimedia
session. Closely related to SDP is the Offer/Answer mechanism,
defined in RFC 3264 [6]. This mechanism defines how SDP is
exchanged between a set of peers to agree on the makeup of a
session. SDP itself has numerous extensions, including
Interactive Connectivity Establishment (ICE) [7], which is the
primary mechanism for NAT traversal for RTP streams set up by SIP.
RFC 3320: Signaling Compression (Sigcomp) RFC 3320 [8] defines a
mechanism for compressing SIP messages over low bandwidth links.
Sigcomp is not specific to SIP, though it was designed explicitly
for SIP. Sigcomp has several extensions defined for improved
compression.
RFC 3761: Telephone Number Mapping (ENUM) RFC 3761 [9] defines a
mechanism to look up a phone number in DNS and obtain a URI, such
as a SIP URI. ENUM defines numerous enum services, which
represent particular types of information that can be obtained
from the DNS related to that phone number.
RFC 3966: The tel URI scheme RFC 3966 [10] defines the tel URI
scheme, used to identify phone numbers. The tel URI is carried
primarily in SIP messages, and has numerous extensions defined for
it.
RFC 3863: The Presence Information Data Format (PIDF) PIDF [11]
defines an XML-based format for representing presence information.
It is carried in SIP NOTIFY requests. Numerous extensions have
been defined to PIDF for conveying additional pieces of presence
information.
RFC XXXX: The Message Session Relay Protocol (MSRP) MSRP [12]
provides a way to carry instant messages between agents. MSRP is
to instant messages as RTP is to voice and video. It is a
transport that is set up by SIP.
Rosenberg Expires August 31, 2006 [Page 4]
Internet-Draft Hitchhikers Guide to SIP February 2006
RFC XXXX: Simple Traversal of UDP Through NAT (STUN) STUN [13]
defines a basic toolkit for facilitating NAT traversal for
protocols such as SIP. Extensions have been defined to STUN for
functions such as packet relaying.
RFC XXXX: XML Configuration Access Protocol (XCAP) XCAP [14] provides
a means for clients to read and write XML-based application data
in the network. It was originally conceived for managing buddy
lists and presence authorization lists.
RFC 3219: Telephony Routing over IP (TRIP) TRIP [15] defines a
mechanism for exchanging SIP routes between administrative
domains. Its derived from BGP.
Despite the importance of the SIP family of specifications, this
document concerns itself entirely with defining the set of
specifications that make up SIP itself. Excluded from this list are
requirements, architectures, registry definitions, non-normative
frameworks, and processes. Best Current Practices are included when
they are effectively standard mechanisms for accomplishing a task.
Also excluded are definitions of MIME objects that are used by SIP,
such as the Authenticated Identity Body (AIB) [16] and various XML
documents and extensions used by SIP. Though they are used by SIP,
they are not extensions to SIP. [[OPEN ISSUE: Is this arbitrary?
Maybe they should be included if they are specific to SIP.]]
The SIP change process [17] defines two types of extensions to SIP.
These are normal extensions and the so-called P-headers, which are
meant to be used in areas of limited applicability. P-headers cannot
be defined in the standards track. For the most part, P-headers are
not included in the listing here, with the exception of those which
have seen general usage despite their P-header status.
3. Core SIP Specifications
The core SIP specifications represent essential functionality for
almost any implementation.
RFC 3261: The Session Initiation Protocol (S) This is the core SIP
protocol itself. RFC 3261 is an update to RFC 2543 [18]. It is
the president of the galaxy as far as the suite of SIP
specifications is concerned.
RFC 3263: Locating SIP Servers (S) RFC 3263 [19] provides DNS
procedures for taking a SIP URI, and determining a SIP server that
is associated with that SIP URI. RFC 3263 is essential for any
implementation using SIP with DNS. RFC 3263 makes use of both DNS
Rosenberg Expires August 31, 2006 [Page 5]
Internet-Draft Hitchhikers Guide to SIP February 2006
SRV records [20] and NAPTR records [21].
RFC 3265: SIP-Specific Event Notification RFC 3265 defines the
SUBSCRIBE and NOTIFY methods. These two methods provide a general
event notification framework for SIP. To actually use the
framework, extensions need to be defined for specific event
packages. An event package defines a schema for the event data,
and describes other aspects of event processing specific to that
schema. An RFC 3265 implementation is required when any event
package is used.
RFC 3323: A Privacy Mechanism for the Session Initiation Protocol
(SIP) (S) RFC 3323 [23] defines the Privacy header field, used by
clients to request anonymity for their requests. Though it
defines numerous privacy services, the only one broadly used is
the one that supports privacy of the P-Asserted-ID header field
[24].
RFC 3325: Private Extensions to SIP for Asserted Identity within
Trusted Networks (I) Though its P-header status implies that it has
limited applicability, RFC 3325 [24], which defines the
P-Asserted-ID header field has been widely deployed. It is used
as the basic mechanism for providing secure caller ID services.
RFC 3327: SIP Extension Header Field for Registering Non-Adjacent
Contacts (S) RFC 3327 [25] defines the Path header field. This field
is inserted by proxies between a client and their registrar. It
allows inbound requests towards that client to traverse these
proxies prior to being delivered to the user agent. It is
essential in any SIP deployment that has edge proxies, which are
proxies between the client and the home proxy or SIP registrar.
It is also instrumental in the SIP NAT traversal specifications.
RFC 3581: An Extension to SIP for Symmetric Response Routing RFC 3581
[26] defines the rport parameter of the Via header. It is an
essential piece of getting SIP through NAT. NAT traversal for SIP
is considered a core part of the specifications.
RFC 4320: Actions Addressing Issues Identified with the Non-INVITE
Transaction in SIP (S) RFC 4320 [27] formally updates RFC 3261, and
modifies some of the behaviors associated with non-INVITE
transactions. These address some problems found in timeout and
failure cases.
RFC XXXX: Enhancements for Authenticated Identity Management in SIP
(S) RFC XXXX [28] defines a mechanism for providing a
cryptographically verifiable identity of the calling party in a
SIP request. Also known as "SIP Identity", this mechanism
Rosenberg Expires August 31, 2006 [Page 6]
Internet-Draft Hitchhikers Guide to SIP February 2006
provides an alternative to RFC 3325. It has seen little
deployment so far, but its importance as a key construct for
almost also anti-spam techniques makes it a core part of the SIP
specifications.
RFC XXXX: Obtaining and Using Globally Routable User Agent
Identifiers (GRUU) in SIP (S) RFC XXXX [29] defines a mechanism for
directing requests towards a specific UA instance. GRUU is
essential for features like transfer and provides another piece of
the SIP NAT traversal story.
RFC XXXX: Managing Client Initiated Connections through SIP (S) RFC
XXXX [30], also known as SIP outbound, defines important changes
to the SIP registration mechanism which enable delivery of SIP
messages towards a UA when it is behind a NAT. This specification
is the cornerstone of the SIP NAT traversal strategy.
4. Public Switched Telephone Network (PSTN) Interworking
Numerous extensions and usages of SIP related to interoperability and
communications with or through the PSTN.
RFC 2848: The PINT Service Protocol (P) This is one of the earliest
extensions to SIP. It defines procedures for using SIP to invoke
services that actually execute on the PSTN. Its main application
is for third party call control, allowing an IP host to set up a
call between two PSTN endpoints. PINT has a relatively narrow
focus and has not seen widespread deployment.
RFC 3910: The SPIRITS Protocol (P) Continuing the trend of naming
PSTN related extensions with alcohol references, SPIRITS [32]
defines the inverse of PINT. It allows a switch in the PSTN to
ask an IP element about how to proceed with call waiting. It was
developed primarily to support Internet Call Waiting (ICW).
Perhaps the next specification will be called the PGGB.
RFC 3372: SIP for Telephones (SIP-T): Context and Architectures
(I) SIP-T [33] defines a mechanism for using SIP between pairs of
PSTN gateways. Its essential idea is to tunnel ISUP signaling
between the gateways in the body of SIP messages. SIP-T motivated
the development of INFO [39]. SIP-T has seen widespread
implementation.
RFC 3398: ISUP to SIP Mapping (P) RFC 3398 [34] defines how to do
protocol mapping from the SS7 ISDN User Part (ISUP) signaling to
SIP. It is widely used in SS7 to SIP gateways and is part of the
SIP-T framework.
Rosenberg Expires August 31, 2006 [Page 7]
Internet-Draft Hitchhikers Guide to SIP February 2006
RFC 3578: Mapping of ISUP Overlap Signaling to SIP RFC 3578 [35]
defines a mechanism to map overlap dialing into SIP. This
specification is widely regarded as the ugliest SIP specification,
as the introduction to the specification itself advises that it
has many problems. Overlap signaling (the practice of sending
digits into the network as dialed instead of waiting for complete
collectoin of the called party number) is largely incompatible
with SIP at some fairly fundamental levels. That said, RFC 3578
is mostly harmless and has seen some usage.
RFC 3960: Early Media and Ringtone Generation in SIP (I) RFC 3960
defines some guidelines for handling early media - the practice of
sending media from the called party towards the caller - prior to
acceptance of the call. Early media is generated only from the
PSTN.
5. General Purpose Infrastructure Extensions
These extensions are general purpose enhancements to SIP that can
serve a wide variety of uses. However, they are not as widely used
or as essential as the core specifications.
RFC 3262: Reliability of Provisional Responses in SIP (S) SIP defines
two types of responses to a request - final and provisional.
Provisional responses are numbered from 100 to 199. In SIP, these
responses are not sent reliably. This choice was made in RFC 2543
since the messages were meant to just be truly informational, and
rendered to the user. However, subsequent work on PSTN
interworking demonstrated a need to map provisional responses to
PSTN messages that needed to be sent reliably. RFC 3262 [37] was
developed to allow reliability of provisional responses. The
specification defines the PRACK method, used for indicating that a
provisional response was received. Though it provides a generic
capability for SIP, RFC 3262 implementations have been most common
in PSTN interworking devices. However, PRACK brings a great deal
of complication for relatively small benefit. As such, it has
seen only mild levels of deployment.
RFC 3311: The SIP UPDATE Method (S) RFC 3311 [38] defines the UPDATE
method for SIP. This method is meant as a means for updating
session information prior to the completion of the initial INVITE
transaction. It was developed primarily to support RFC 3312 [68].
RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an
extension to RFC 2543. It defines a method, INFO, used to
transport mid-dialog information that has no impact on SIP itself.
Its driving application was the transport of PSTN related
Rosenberg Expires August 31, 2006 [Page 8]
Internet-Draft Hitchhikers Guide to SIP February 2006
information when using SIP between a pair of gateways. Though
originally conceived for broader use, it only found standardized
usage with SIP-T [33]. It has been used to support numerous
proprietary and non-interoperable extensions due to its poorly
defined scope.
RFC 3326: The Reason header field for SIP (S) RFC 3326 [40] defines
the Reason header field. It is used in requests, such as BYE, to
indicate the reason that the request is being sent.
RFC 3608: SIP Extension Header Field for Service Route Discovery
During Registration RFC 3608 [41] allows a client to determine, from
a REGISTER response, a path of proxies to use in requests it sends
outside of a dialog. In many respects, it is the inverse of the
Path header field, but has seen less usage since default outbound
proxies have been sufficient in many deployments.
RFC 3840: Indicating User Agent Capabilities in SIP (S) RFC 3840
defines a mechanism for carrying capability information about a
user agent in REGISTER requests and in dialog-forming requests
like INVITE. It has found use with conferencing (the isfocus
parameter declares that a user agent is a conference server) and
with applications like push-to-talk.
RFC 3841: Caller Preferences for SIP (S) RFC 3841 [43] defines a set
of headers that a client can include in a request to control the
way in which the request is routed downstream. It allows a client
to direct a request towards a UA with specific capabilities.
RFC 4028: Session Timers in SIP (S) RFC 4028 [44] defines a keepalive
mechanism for SIP signaling. It is primarily meant to provide a
way to cleanup old state in proxies that are holding call state
for calls from failed endpoints which were never terminated
normally. Despite its name, the session timer is not a mechanism
for detecting a network failure mid-call. Session timers
introduces a fair bit of complexity for relatively little gain,
and has thus seen little deployment.
RFC 4168: SCTP as a Transport for SIP RFC 4168 [45] defines how to
carry SIP messages over the Stream Control Transmission Protocol
(SCTP). SCTP has seen very limited usage for SIP transport.
RFC 4244: An Extension to SIP for Request History Information (S) RFC
4244 [46] defines the History-Info, which indicates information on
how a call came to be routed to a particular destination. Its
primary application was in support of voicemail services.
Rosenberg Expires August 31, 2006 [Page 9]
Internet-Draft Hitchhikers Guide to SIP February 2006
6. Minor Extensions
These SIP extensions don't fit easily into a single specific use
case. They have somewhat general applicability, but they solve a
relatively small problem or provide an optimization.
RFC XXXX: Suppression of the SIP REFER Implicit Subscription (S) RFC
XXXX [47] defines an enhancement to REFER. REFER normally creates
an implicit subscription to the target of the REFER. This
subscription is used to pass back updates on the progress of the
referral. This extension allows that implicit subscription to be
bypassed as an optimization.
RFC XXXX: Request Authorization through Dialog Identification in SIP
(S) RFC XXXX [48] provides a mechanism that allows a UAS to authorize
a request because the requestor proves it knows a dialog that is
in progress with the UAS. The specification is useful in
conjunction with the SIP application interaction framework [85].
RFC XXXX: Conveying Feature Tags with the REFER Method in SIP (S) RFC
XXXX [49] defines a mechanism for carrying RFC 3840 feature tags
in REFER. It is useful for informing the target of the REFER
about the characteristics of the REFER target.
RFC XXXX: Requesting Answer Modes for SIP (S) RFC XXXX [50] defines
an extension for indicating to the called party whether or not the
phone should ring and/or be answered immediately. This is useful
for push-to-talk and for diagnostic applications.
RFC XXXX: Rejecting Anonymous Requests in SIP (S) RFC XXXX [51]
defines a mechanism for a called party to indicate to the calling
party that a call was rejected since the caller was anonymous.
This is needed for implementation of the Anonymous Call Rejection
(ACR) feature in SIP.
RFC XXXX: Referring to Multiple Resources in SIP (S) RFC XXXX [52]
allows a UA sending a REFER to ask the recipient of the REFER to
generate multiple SIP requests, not just one. This is useful for
conferencing, where a client would like to ask a conference server
to eject multiple users.
7. Call Control Primitives
Numerous SIP extensions provide a toolkit of dialog and call
management techniques. These techniques have been combined together
to build many SIP-based services.
Rosenberg Expires August 31, 2006 [Page 10]
Internet-Draft Hitchhikers Guide to SIP February 2006
RFC 3515: The REFER Method (S) REFER [53] defines a mechanism for
asking a user agent to send a SIP request. Its a form of SIP
remote control, and is the primary tool used for call transfer in
SIP.
RFC 3725: Best Current Practices for Third Party Call Control (3pcc)
(B) RFC 3725 [54] defines a number of different call flows that allow
one SIP entity, called the controller, to create SIP sessions
amongst other SIP user agents.
RFC 3891: The SIP Replaces Header RFC 3891 [55] defines a mechanism
that allows a new dialog to replace an existing dialog. It is
useful for certain advanced transfer services.
RFC 3892: The SIP Referred-By Mechanism (S) RFC 3892 [56] defines the
Referred-By header field. It is used in requests triggered by
REFER, and provides the identity of the referring party to the
referred-to party.
RFC 3911: The SIP Join Header Field (S) RFC 3911 [57] defines the
Join header field. When sent in an INVITE, it causes the
recipient to join the resulting dialog into a conference with
another dialog in progress.
RFC 4117: Transcoding Services Invocation in SIP Using Third Party
Call Control (I) RFC 4117 [58] defines how to use 3pcc for the
purposes of invoking transcoding services for a call.
8. Event Packages
RFC 3265 defines a basic framework for event notification in SIP. It
introduces the notion of an event package, which is a collection of
related state and event information. Much of the state and events in
SIP systems have event packages, allowing other entities to learn
about changes in that state.
RFC 3903: SIP Extension for Event State Publication (S) RFC 3903 [59]
defines the PUBLISH method. It is not an event package, but is
used by all event packages as a mechanism for pushing an event
into the system.
RFC 3680: A SIP Event Package for Registrations (S) RFC 3680 [60]
defines an event package for finding out about changes in
registration state.
Rosenberg Expires August 31, 2006 [Page 11]
Internet-Draft Hitchhikers Guide to SIP February 2006
RFC 3842: A Message Summary and Message Waiting Indication Event
Package for SIP (S) RFC 3842 [73] defines a way for a user agent to
find out about voicemails and other messages that are waiting for
it. Its primary purpose is to enable the voicemail waiting lamp
on most business telephones.
RFC 3856: A Presence Event Package for SIP (S) RFC 3856 [62] defines
an event package for indicating user presence through SIP.
RFC 3857: A Watcher Information Event Template Package for SIP
(S) RFC 3857 [63], also known as winfo, provides a mechanism for a
user agent to find out what subscriptions are in place for a
particular event package. Its primary usage is with presence, but
it can be used with any event package.
RFC 4235: An INVITE Initiated Dialog Event Package for SIP (S) RFC
4235 [64] defines an event package for learning the state of the
dialogs in progress at a user agent.
RFC XXXX: A SIP Event Package for Conference State (S) RFC XXXX [65]
defines a mechanism for learning about changes in conference
state, including group membership.
RFC XXXX: A SIP Event Package for Keypress Stimulus (KPML) (S) RFC
XXXX [66] defines a way for an application in the network to
subscribe to the set of keypresses made on the keypad of a
traditional telephone.
RFC XXXX: SIP Event Package for Voice Quality Reporting (S) RFC XXXX
[67] defines a SIP event package that enables the collection and
reporting of metrics that measure the quality for Voice over
Internet Protocol (VoIP) sessions.
9. Quality of Service
Several specifications concern themselves with the interactions of
SIP with network Quality of Service (QoS) mechanisms.
RFC 3312:Integration of Resource Management and SIP (S) RFC 3312
[68], updated by RFC 4032 [69] defines a way to make sure that
the phone of the called party doesn't ring until a QoS reservation
has been installed in the network. It does so by defining a
general preconditions framework, which defines conditions that
must be true in order for a SIP session to proceed
Rosenberg Expires August 31, 2006 [Page 12]
Internet-Draft Hitchhikers Guide to SIP February 2006
RFC 3313: Private SIP Extensions for Media Authorization (I) RFC 3313
[70] defines a P-header that provides a mechanism for passing an
authorization token between SIP and a network QoS reservation
protocol like RSVP. Its purpose is to make sure network QoS is
only granted if a client has made a SIP call through the same
providers network. This specification is sometimes referred to as
the SIP walled garden specification by the truly paranoid androids
in the SIP community. This is because it requires coupling of
signaling and the underlying IP network.
10. Operations and Management
Several specifications have been defined to support operations and
management of SIP systems. These include mechanisms for
configuration and network diagnostics.
RFC XXXX: Diagnostic Responses for SIP Hop Limit Errors (S) RFC XXXX
defines a mechanism for including diagnostic information in a 483
response. This response is sent when the hop-count of a SIP
request was exceeded.
RFC XXXX: A Framework for SIP User Agent Profile Delivery (S) RFC
XXXX [71] defines a mechanism that allows a SIP user agent to
bootstrap its configuration from the network, and receive updates
to its configuration should it change. This is considered an
essential piece of deploying a usable SIP network.
RFC XXXX: SIP Event Package for Voice Quality Reporting (S) RFC XXXX
[67] defines a SIP event package that enables the collection and
reporting of metrics that measure the quality for Voice over
Internet Protocol (VoIP) sessions.
11. SIP Compression
Sigcomp [8] was defined to allow compression of SIP messages over low
bandwidth links. Sigcomp is not formally part of SIP. However,
usage of Sigcomp with SIP has required extensions to SIP.
RFC 3486: Compressing SIP (S) RFC 3486 [72] defines a SIP URI
parameter that can be used to indicate that a SIP server supports
Sigcomp.
12. SIP Service URIs
Several extensions define well-known services that can be invoked by
Rosenberg Expires August 31, 2006 [Page 13]
Internet-Draft Hitchhikers Guide to SIP February 2006
constructing requests with the specific structures for the Request
URI, resulting in specific behaviors at the UAS.
RFC 3087: Control of Service Context using Request URI (I) RFC 3087
[74] introduced the context of using Request URIs, encoded
appropriately, to invoke services.
RFC XXXX: A SIP Event Notification Extension for Resource Lists
(S) RFC XXXX [75] defines a resource called a Resource List
Server. A client can send a subscribe to this server. The server
will generate a series of subscriptions, and compile the resulting
information and send it back to the subscriber. The set of
resources that the RLS will subscribe to is a property of the
request URI in the SUBSCRIBE request.
RFC XXXX: Subscriptions To Request-Contained Resource Lists in SIP
(S) RFC XXXX [76] allows a client to subscribe to a resource called a
Resource List Server. This server will generate a series of
subscriptions, and compile the resulting information and send it
back to the subscriber. For this specification, the list of
things to subscribe to is in the body of the SUBSCRIBE request.
RFC XXXX: Multiple-Recipient MESSAGE Requests in SIP (S) RFC XXXX
[77] is similar to [76]. However, instead of subscribing to the
resource, a MESSAGE request is sent to the resource, and it will
send a copy to each recipient.
RFC XXXX: Conference Establishment Using Request-Contained Lists in
SIP (S) RFC XXXX [78] is similar to [76]. However, instead of
subscribing to the resource, an INVITE request is sent to the
resource, and it will act as a conference focus and generate an
invitation to each recipient in the list.
13. Security Mechanisms
Several extensions provide additional security features to SIP.
RFC 3853: S/MIME AES Requirement for SIP RFC 3853 [79] is a brief
specification that updates the cryptography mechanisms used in SIP
S/MIME. However, SIP S/MIME has seen very little deployment.
RFC 3329: Security Mechanism Agreement for SIP (S) RFC 3329 [80]
defines a mechanism to prevent bid-down attacks in conjunction
with SIP authentication. The mechanism has seen very limited
deployment. It was defined as part of the 3gpp IMS specification
suite, and is needed only when there are a multiplicity of
security mechanisms deployed at a particular server. In practice,
Rosenberg Expires August 31, 2006 [Page 14]
Internet-Draft Hitchhikers Guide to SIP February 2006
this has not been the case.
RFC XXXX: End-to-Middle Security in SIP (S) RFC XXXX [81] defines
mechanisms for encrypting content from user agents to specific
network intermediaries.
14. Instant Messaging and Presence
SIP provides extensions for instant messaging and presence.
RFC 3428: SIP Extension for Instant Messaging RFC 3428 [82] defines
the MESSAGE method, used for sending a page mode instant message.
RFC 3856: A Presence Event Package for SIP (S) RFC 3856 [62] defines
an event package for indicating user presence through SIP.
RFC 3857: A Watcher Information Event Template Package for SIP
(S) RFC 3857 [63], also known as winfo, provides a mechanism for a
user agent to find out what subscriptions are in place for a
particular event package. Its primary usage is with presence, but
it can be used with any event package.
15. Emergency Services
Emergency services here covers both emergency calling (for example,
911 in the United States), and pre-emption services, which allow
authorized individuals to gain access to network resources in time of
emergency.
RFC 4411: Extending the SIP Reason Header for Preemption Events
(S) RFC 4411 [83] defines an extension to the Reason header,
allowing a UA to know that its dialog was torn down because a
higher priority session came through.
RFC 4412: Communications Resource Priority for SIP (S) RFC 4412 [84]
defines a new header field, Resource-Priority, that allows a
session to get priority treatment from the network.
16. Security Considerations
This specification is an overview of existing specifications, and
does not introduce any security considerations on its own.
Rosenberg Expires August 31, 2006 [Page 15]
Internet-Draft Hitchhikers Guide to SIP February 2006
17. IANA Considerations
None.
18. 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] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in
progress), October 2005.
[8] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)",
RFC 3320, January 2003.
[9] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[11] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
[12] Campbell, B., "The Message Session Relay Protocol",
Rosenberg Expires August 31, 2006 [Page 16]
Internet-Draft Hitchhikers Guide to SIP February 2006
draft-ietf-simple-message-sessions-13 (work in progress),
December 2005.
[13] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02
(work in progress), July 2005.
[14] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-08 (work in progress), October 2005.
[15] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[16] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[17] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[18] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[19] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[20] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[21] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[22] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[23] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[24] 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.
[25] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
Rosenberg Expires August 31, 2006 [Page 17]
Internet-Draft Hitchhikers Guide to SIP February 2006
[26] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing",
RFC 3581, August 2003.
[27] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Transaction",
RFC 4320, January 2006.
[28] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
[29] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-06 (work in progress),
October 2005.
[30] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-01 (work in progress), October 2005.
[31] Petrack, S. and L. Conroy, "The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call
Services", RFC 2848, June 2000.
[32] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu, H.,
and M. Unmehopa, "The SPIRITS (Services in PSTN requesting
Internet Services) Protocol", RFC 3910, October 2004.
[33] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63,
RFC 3372, September 2002.
[34] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated
Services Digital Network (ISDN) User Part (ISUP) to Session
Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[35] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of
Integrated Services Digital Network (ISDN) User Part (ISUP)
Overlap Signalling to the Session Initiation Protocol (SIP)",
RFC 3578, August 2003.
[36] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004.
[37] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
Rosenberg Expires August 31, 2006 [Page 18]
Internet-Draft Hitchhikers Guide to SIP February 2006
June 2002.
[38] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[39] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[40] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[41] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003.
[42] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[43] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[44] Donovan, S. and J. Rosenberg, "Session Timers in the Session
Initiation Protocol (SIP)", RFC 4028, April 2005.
[45] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream
Control Transmission Protocol (SCTP) as a Transport for the
Session Initiation Protocol (SIP)", RFC 4168, October 2005.
[46] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244,
November 2005.
[47] Levin, O., "Suppression of Session Initiation Protocol REFER
Method Implicit Subscription",
draft-ietf-sip-refer-with-norefersub-04 (work in progress),
January 2006.
[48] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
draft-ietf-sip-target-dialog-03 (work in progress),
December 2005.
[49] Levin, O. and A. Johnston, "Conveying Feature Tags with Session
Initiation Protocol REFER Method",
draft-ietf-sip-refer-feature-param-01 (work in progress),
January 2006.
Rosenberg Expires August 31, 2006 [Page 19]
Internet-Draft Hitchhikers Guide to SIP February 2006
[50] Willis, D. and A. Allen, "Requesting Answering Modes for the
Session Initiation Protocol (SIP)",
draft-ietf-sip-answermode-00 (work in progress), December 2005.
[51] Rosenberg, J., "Rejecting Anonymous Requests in the Session
Initiation Protocol (SIP)", draft-ietf-sip-acr-code-00 (work in
progress), January 2006.
[52] Camarillo, G., "Refering to Multiple Resources in the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-multiple-refer-04 (work in progress),
October 2005.
[53] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[54] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004.
[55] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[56] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004.
[57] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
[58] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk,
"Transcoding Services Invocation in the Session Initiation
Protocol (SIP) Using Third Party Call Control (3pcc)",
RFC 4117, June 2005.
[59] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[60] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[61] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
[62] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
Rosenberg Expires August 31, 2006 [Page 20]
Internet-Draft Hitchhikers Guide to SIP February 2006
[63] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857,
August 2004.
[64] Santesson, S. and R. Housley, "Internet X.509 Public Key
Infrastructure Authority Information Access Certificate
Revocation List (CRL) Extension", RFC 4325, December 2005.
[65] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.
[66] Burger, E., "A Session Initiation Protocol (SIP) Event Package
for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-07
(work in progress), December 2004.
[67] Pendleton, A., "SIP Service Quality Reporting Event",
draft-ietf-sipping-rtcp-summary-00 (work in progress),
December 2005.
[68] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)",
RFC 3312, October 2002.
[69] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation
Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[70] Marshall, W., "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization", RFC 3313, January 2003.
[71] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-07
(work in progress), July 2005.
[72] Camarillo, G., "Compressing the Session Initiation Protocol
(SIP)", RFC 3486, February 2003.
[73] Foster, M., McGarry, T., and J. Yu, "Number Portability in the
Global Switched Telephone Network (GSTN): An Overview",
RFC 3482, February 2003.
[74] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[75] Roach, A., Rosenberg, J., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", draft-ietf-simple-event-list-07 (work in
Rosenberg Expires August 31, 2006 [Page 21]
Internet-Draft Hitchhikers Guide to SIP February 2006
progress), January 2005.
[76] Camarillo, G., "Subscriptions to Request-Contained Resource
Lists in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-subscribe-04 (work in progress),
October 2005.
[77] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-06 (work in progress),
January 2006.
[78] Camarillo, G. and A. Johnston, "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol
(SIP)", draft-ietf-sipping-uri-list-conferencing-04 (work in
progress), October 2005.
[79] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004.
[80] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003.
[81] Ono, K. and S. Tachimoto, "End-to-middle Security in the
Session Initiation Protocol (SIP)", draft-ietf-sip-e2m-sec-01
(work in progress), October 2005.
[82] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[83] Polk, J., "Extending the Session Initiation Protocol (SIP)
Reason Header for Preemption Events", RFC 4411, February 2006.
[84] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)", RFC 4412,
February 2006.
[85] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-05 (work in
progress), July 2005.
Rosenberg Expires August 31, 2006 [Page 22]
Internet-Draft Hitchhikers Guide to SIP February 2006
Author's Address
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 Expires August 31, 2006 [Page 23]
Internet-Draft Hitchhikers Guide to SIP February 2006
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 (2006). 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 Expires August 31, 2006 [Page 24]