One document matched: draft-ietf-sip-hitchhikers-guide-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc symrefs='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc ipr="full3978" category="info">
<front>
<title abbrev="Hitchhiker's Guide to SIP">
A Hitchhiker's Guide to the Session Initiation Protocol (SIP)
</title>
<author initials="J.R." surname="Rosenberg"
fullname="Jonathan Rosenberg">
<organization>Cisco</organization>
<address>
<postal>
<city>Edison</city> <region>NJ</region>
<country>US</country>
</postal>
<email>jdrosen@cisco.com</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<date month="February" year="2008" />
<area>RAI</area>
<workgroup>SIP</workgroup>
<keyword>SIP</keyword>
<keyword>Guide</keyword>
<keyword>42</keyword>
<keyword>Don't Panic</keyword>
<keyword>Overview</keyword>
<abstract>
<t>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. 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Session Initiation Protocol (SIP) <xref target="RFC3261"/> 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! <xref target="HGTTG"/> 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 <xref target="RFC2026"/>. These values are: </t>
<list style="hanging">
<t hangText="S:">Standards Track (Proposed Standard, Draft Standard, or
Standard)</t>
<t hangText="E:">Experimental</t>
<t hangText="B:">Best Current Practice</t>
<t hangText="I:">Informational</t>
</list>
<t>
The specifications are grouped together by topic. The topics are:
<list style="hanging">
<t hangText="Core:"> The essential SIP specifications that are expected
to be utilized for every session or registration.</t>
<t hangText="PSTN Interop:"> Specifications related to interworking
with the telephone network.
</t>
<t hangText="General Purpose Infrastructure:"> General purpose
extensions to SIP, SDP and MIME, but ones that are not expected to
always be used.
</t>
<t hangText="NAT Traversal:"> Specifications to deal with firewall and
NAT traversal.
</t>
<t hangText="Minor Extensions:"> Specifications that solve a narrow
problem space or provide an optimization.
</t>
<t hangText="Conferencing:"> Specifications for multimedia
conferencing.
</t>
<t hangText="Call Control Primitives:"> Specifications for
manipulating SIP dialogs and calls.
</t>
<t hangText="Event Framework:"> Defines the core specifications for
the SIP event framework, providing for pub/sub capability.
</t>
<t hangText="Event Packages:"> Packages that utilize the SIP event
framework.
</t>
<t hangText="Quality of Service:"> Specifications related to
multimedia quality of service (QoS).
</t>
<t hangText="Operations and Management:"> Specifications related to
configuration and monitoring of SIP deployments.
</t>
<t hangText="SIP Compression:"> Specifications to facilitate usage of
SIP with the Signaling Compression (Sigcomp) framework.
</t>
<t hangText="SIP Service URIs:"> Specifications on how to use SIP URIs
to address multimedia services.
</t>
<t hangText="Security Mechanisms:"> Specifications providing security
functionality for SIP.
</t>
<t hangText="Instant Messaging, Presence, and Multimedia:"> SIP
extensions related to IM, presence and multimedia. This covers only
the SIP extensions related to these topics. See
<xref target="I-D.ietf-simple-simple"/> for a full treatment of SIP
for IM and Presence (SIMPLE).
</t>
<t hangText="Emergency Services:"> SIP extensions related to emergency
services. See <xref target="I-D.ietf-ecrit-framework"/> for a more
complete treatment of additional functionality related to emergency
services.
</t>
</list>
</t>
<t>Typically, SIP
extensions fit naturally into topic areas, and implementers
interested in a particular topic often implement many or all of the
specifications in that area. There are some specifications which fall
into multiple topic areas, in which case they are listed more than
once.
</t>
<t>Do not print all the specs cited here at once, as they
might share the fate of the rules of Brockian Ultracricket
when bound together: collapse under their own gravity and
form a black hole <xref target="HGTTG"/>.
</t>
<t>
This document itself is not an update to RFC 3261 or an extension to
SIP. It is an informational document, meant to guide newcomers,
implementors and deployers to the many of the specifications
associated with SIP.
</t>
</section>
<section title="Scope of this Document">
<t>
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:
</t>
<list style="symbols">
<t>RFC 3261 and any specification that defines an extension to it,
where an extension is a mechanism that changes or updates in
some way a behavior specified there.
</t>
<t>The basic SDP specification, RFC 4566 <xref target="RFC4566"/>, and
any specification that defines an extension to SDP whose primary
purpose is to support SIP.
</t>
<t>Any specification that defines a MIME object whose primary purpose
is to support SIP
</t>
</list>
<t>
Excluded from this list are requirements, architectures, registry
definitions, non-normative frameworks, and processes. Best Current
Practices are included when they normatively define mechanisms for
accomplishing a task, or provide significant description of the
usage of the normative specifications, such as call flows.
</t>
<t> The SIP change process <xref target="RFC3427"/> defines two types
of extensions to SIP. These are normal extensions and the so-called
P-headers (where P stands for "preliminary", "private", or
"proprietary", and the "P-" prefix is included in the header field
name), 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.
</t>
<t>
This document includes specifications which have already
been approved by the IETF and granted an RFC number, in addition
to Internet Drafts which are still under development within IETF and
will eventually finish and get an RFC number. Inclusion of Internet
Drafts here helps encourage early implementation and demonstrations of
interoperability of the protocol, and thus aids in the standards
setting process. Inclusion of these also identifes where the IETF is
targetting a solution at a particular problem space. Note that final
IANA assignment of codepoints (such as option tags and header field
names) does not take place until shortly before
publication as an RFC, and thus codepoint assignments may change.
</t>
</section>
<section title="Core SIP Specifications">
<t>
The core SIP specifications represent the set of specifications whose
functionality is broadly applicable. An extension is broadly
applicable if it fits into one of the following categories:
</t>
<list style="symbols">
<t>For specifications that impact SIP session management, the
extension would be used for almost every session initiated by a user
agent
</t>
<t>For specifications that impact SIP registrations, the extension
would be used for almost every registration initiated by a user agent
</t>
<t>For specifications that impact SIP subscriptions, the extension
would be used for almost every subscription initiated by a user agent
</t>
</list>
<t>In other words, these are not specifications that are used just for
some requests and not others; they are specifications that would
apply to each and every request that the extension is relevant
for. In the galaxy of SIP, these specifications are like towels <xref
target="HGTTG"/>.
</t>
<list style="hanging">
<t hangText="RFC 3261, The Session Initiation Protocol (S):">
<xref target="RFC3261"/> is the core SIP protocol
itself. RFC 3261 is an update to <xref target="RFC2543"/>. It is the
president of the galaxy <xref
target="HGTTG"/> as
far as the suite of SIP specifications is concerned.
</t>
<t hangText="RFC 3263, Locating SIP Servers (S):"><xref
target="RFC3263"/> 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 SRV records <xref target="RFC2782"/> and NAPTR
records <xref target="RFC2915"/>.
</t>
<t hangText="RFC 3264, An Offer/Answer Model with the Session
Description Protocol (S):"> <xref target="RFC3264"/>
defines how the Session Description Protocol (SDP) <xref
target="RFC4566"/> is used with SIP to negotiate the
parameters of a media session. It is in widespread usage and an
integral part of the behavior of RFC 3261.
</t>
<t hangText="RFC 3265, SIP-Specific Event Notification (S):"> <xref
target="RFC3265"/>
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.
</t>
<t hangText="RFC 3325, Private Extensions to SIP for Asserted Identity
within Trusted Networks (I):"> Though its P-header status implies that
it has limited applicability, <xref target="RFC3325"/>, which
defines the P-Asserted-Identity header field, has been widely deployed. It is
used as the basic mechanism for providing network asserted caller ID
services. Its update, <xref target="I-D.ietf-sipping-update-pai"/>,
clarifies its usage for connected party identification as well.
</t>
<t hangText="RFC 3327, SIP Extension Header Field for Registering
Non-Adjacent Contacts (S):"> <xref target="RFC3327"/> 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.
</t>
<t hangText="RFC 3581, An Extension to SIP for Symmetric Response
Routing (S):"> <xref target="RFC3581"/> defines the rport
parameter of the Via header. It allows SIP responses to traverse
NAT. It is one of several specifications that are utilized for NAT
traversal (see <xref target="sec-nat"/>).
</t>
<t hangText="RFC 3840, Indicating User Agent Capabilities in SIP (S):">
<xref target="RFC3840"/> 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.
</t>
<t hangText="RFC 4320, Actions Addressing Issues Identified with the
Non-INVITE Transaction in SIP (S):"> <xref target="RFC4320"/>
formally updates RFC 3261, and modifies some of the behaviors
associated with non-INVITE transactions. This addresses some problems
found in timeout and failure cases.
</t>
<t hangText="RFC 4474, Enhancements for Authenticated Identity
Management in SIP (S):"> <xref
target="RFC4474"/> defines a mechanism for providing a
cryptographically verifiable identity of the calling party in a SIP
request. Known as "SIP Identity", this mechanism provides an
alternative to RFC 3325. It has seen little deployment so far, but its
importance as a key construct for anti-spam techniques
and new security mechanisms makes it a core part of the SIP specifications.
</t>
<t hangText="draft-ietf-sip-gruu, Obtaining and Using Globally Routable User
Agent Identifiers (GRUU) in SIP (S):"> <xref
target="I-D.ietf-sip-gruu"/> 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.
</t>
<t hangText="draft-ietf-sip-outbound, Managing Client Initiated
Connections through SIP (S):">
<xref target="I-D.ietf-sip-outbound"/>, 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.
</t>
<t hangText="RFC 4566, Session Description Protocol (S):"> <xref
target="RFC4566"/> defines a format for
representing multimedia sessions. SDP objects are carried in the body
of SIP messages, and based on the offer/answer model, are used to
negotiate the media characteristics of a session between users.
</t>
<t hangText="draft-ietf-mmusic-sdp-capability-negotiation, SDP
Capability Negotiation (S):"> <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"/>
defines a set of extensions to SDP that allow for capability
negotiation within SDP. Capability negotiation can be used to select
between different profiles of RTP (secure vs. unsecure) or to
negotiate codecs such that an agent has to select one amongst a set of
supported codecs.
</t>
<t hangText="draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE)
(S):"> <xref target="I-D.ietf-mmusic-ice"/> defines a
technique for NAT traversal of media sessions for protocols that make
use of the offer/answer model. This specification is the IETF
recommended mechanism for NAT traversal for SIP media streams, and is
meant to be used even by endpoints which are themselves never behind a
NAT. A SIP option tag and media feature tag <xref
target="I-D.ietf-sip-ice-option-tag"/> (also a core specification)
have been defined for use with
ICE.
</t>
<t hangText="RFC 3605, Real Time Control Protocol (RTCP) Attribute in
the Session Description Protocol (SDP) (S):"> <xref
target="RFC3605"/> defines a way to explicitly signal,
within an SDP message, the IP address and port for RTCP, rather than
using the port+1 rule in the Real Time Transport Protocol (RTP) <xref
target="RFC3550"/>. It is needed for devices behind NAT and used by
ICE.
</t>
<t hangText="RFC 4916, Connected Identity in the Session Initiation
Protocol (SIP) (S):"> <xref
target="RFC4916"/> formally updates RFC 3261. It defines an
extension to SIP that allows a calling user to determine the identity of the
final called user (connected party). Due to forwarding and retargeting services, this may not be the
same as the user that the caller was originally trying to reach. The
mechanism works in tandem with the SIP identity specification <xref
target="RFC4474"/> to provide signatures over the
connected party identity. It can also be used
if a party identity changes mid call due to third party call control
actions or PSTN behavior.
</t>
<t hangText="RFC 3311, The SIP UPDATE Method (S):"> <xref
target="RFC3311"/> 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 can also be used to
update other information, such as the identity of the participant
<xref target="RFC4916"/>,
without involving an updated offer/answer exchange. It was developed
initially to support <xref target="RFC3312"/> but has found
other uses. In particular, its usage with RFC 4916 means it will
typically be used as part of every session, to convey a secure
connected identity.
</t>
<t hangText="draft-ietf-sip-sips, The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)
(S):"> <xref target="I-D.ietf-sip-sips"/>
formally updated RFC 3261. It revises the processing of
the SIPS URI, originally
defined in RFC 3261, to fix many errors and problems
that have been encountered with that mechanism.
</t>
<t hangText="RFC 3665, Session Initiation Protocol (SIP) Basic Call
Flow Examples (B):"> <xref target="RFC3665"/> contains
best practice call flow examples for basic SIP
interactions - call establishment, termination, and
registration.
</t>
<t hangText="Essential Corrections to SIP:"> A collection of fixes to
SIP that address important bugs and vulnerabilities. These include a
fix requiring loop detection in any proxy that
forks <xref target="I-D.ietf-sip-fork-loop-fix"/>, a
clarification on how record-routing works
<xref target="I-D.ietf-sip-record-route-fix"/>, and a correction to
the IPv6 BNF <xref target="I-D.ietf-sip-ipv6-abnf-fix"/>.
</t>
</list>
</section>
<section title="Public Switched Telephone Network (PSTN)
Interworking">
<t>
Numerous extensions and usages of SIP related to interoperability and
communications with or through the PSTN.
</t>
<list style="hanging">
<t hangText="RFC 2848, The PINT Service Protocol (S):"> <xref
target="RFC2848"/> 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.
</t>
<t hangText="RFC 3910, The SPIRITS Protocol (S):"> Continuing the trend
of naming PSTN related extensions with alcohol references, SPIRITS
<xref target="RFC3910"/> 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 Pan Galactic
Gargle Blaster <xref target="HGTTG"/>.
</t>
<t hangText="RFC 3372, SIP for Telephones (SIP-T): Context and
Architectures (I):"> SIP-T <xref target="RFC3372"/> 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 <xref
target="RFC2976"/>. SIP-T has seen widespread implementation for the
limited deployment model that it addresses. As ISUP endpoints
disappear from the network, the need for this mechanism will
decrease. </t>
<t hangText="RFC 3398, ISUP to SIP Mapping (S):"> <xref
target="RFC3398"/> 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.
</t>
<t hangText="RFC 4497, Interworking between the Session Initiation
Protocol (SIP) and QSIG (B):"> <xref target="RFC4497"/>
defines how to do protocol mapping from Q.SIG, used for
PBX signaling, to SIP. </t>
<t hangText="RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S):">
<xref target="RFC3578"/> 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 collection 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.
</t>
<t hangText="RFC 3960, Early Media and Ringtone Generation in SIP
(I):"> <xref target="RFC3960"/> defines some guidelines for handling
early media - the practice of sending media from the called party or
an application server towards the caller - prior to acceptance of the
call. Early media is often generated from the PSTN. Early media is
a complex topic, and this specification does not fully address the
problems associated with it. </t>
<t hangText="RFC 3959, Early Session Disposition Type for the Session
Initiation Protocol (SIP) (S):"> <xref target="RFC3959"/> defines a
new session disposition type for use with early
media. It indicates that the SDP in the body is for a special early
media session. This has seen little usage.
</t>
<t hangText="RFC 3204, MIME Media Types for ISUP and QSIG Objects
(S):"> <xref target="RFC3204"/> defines MIME objects for representing
SS7 and QSIG signaling messages. SS7 signaling messages are carried in
the body of SIP messages when SIP-T is used. QSIG signaling messages
can be carried in a similar way.
</t>
<t hangText="RFC3666, Session Initiation Protocol (SIP) Public
Switched Telephone Network (PSTN) Call Flows (B):">
<xref target="RFC3666"/> provides best practice call
flows around interworking with the PSTN.
</t>
</list>
</section>
<section title="General Purpose Infrastructure Extensions">
<t>
These extensions are general purpose enhancements to SIP, SDP and MIME that can
serve a wide variety of uses. However, they are not used for every
session or registration, as the core specifications are.
</t>
<list style="hanging">
<t hangText="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. <xref
target="RFC3262"/> 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
moderate levels of deployment.
</t>
<t hangText="RFC 3323, A Privacy Mechanism for the Session Initiation
Protocol (SIP) (S):"> <xref target="RFC3323"/> defines the
Privacy header field, used by clients to request anonymity for their
requests. Though it defines several privacy services, the only one
broadly used is the one that supports privacy of the P-Asserted-Identity
header field <xref target="RFC3325"/>.
</t>
<t hangText="draft-ietf-sip-ua-privacy, UA-Driven Privacy Mechanism
for SIP (S):"> <xref target="I-D.ietf-sip-ua-privacy"/>
defines a mechanism for achieving
anonymous calls in SIP. It is an alternative to
<xref target="RFC3323"/>, and instead places more
intelligence in the endpoint to craft anonymous messages
by directly accessing network services.
</t>
<t hangText="RFC 2976, The INFO Method (S):"> <xref
target="RFC2976"/> 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 information when using SIP between a pair of
gateways. Though originally conceived for broader use, it only found
standardized usage with SIP-T <xref target="RFC3372"/>. It has been
used to support numerous proprietary and non-interoperable
extensions due to its poorly defined scope.
</t>
<t hangText="RFC 3326, The Reason header field for SIP (S):">
<xref target="RFC3326"/> defines the Reason header field. It is used
in requests, such as BYE, to indicate the reason that the request is
being sent.
</t>
<t hangText="RFC 3388, Grouping of Media Lines in the Session
Description Protocol (S):"> <xref target="RFC3388">RFC 3388</xref>
defines a framework for grouping together media streams in an SDP
message. Such a grouping allows relationships between these streams,
such as which stream is the audio for a particular video feed, to be
expressed.
</t>
<t hangText="RFC 3420, Internet Media Type message/sipfrag (S):">
<xref target="RFC3420"/> defines a MIME object that
contains a SIP message fragment. Only certain header fields and parts
of the SIP message are present. For example, it is used to
report back on the responses received to a request sent as a
consequence of a REFER.
</t>
<t hangText="RFC 3608, SIP Extension Header Field for Service Route
Discovery During Registration (S):"> <xref target="RFC3608"/>
allows a client to determine, from a REGISTER response, a path of
proxies to use in requests it sends outside of a dialog. It can also
be used by proxies to verify the Route header in client initiated
requests. 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. </t>
<t hangText="RFC 3841, Caller Preferences for SIP (S):"> <xref
target="RFC3841"/> 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, which a UA indicates using
<xref target="RFC3840"/>. </t>
<t hangText="RFC 4028, Session Timers in SIP (S):"> <xref
target="RFC4028"/> 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
have seen moderate deployment.
</t>
<t hangText="RFC 4168, SCTP as a Transport for SIP (S):"> <xref
target="RFC4168"/> defines how to carry SIP messages over the Stream
Control Transmission Protocol (SCTP) <xref target="RFC4960"/>. SCTP
has seen very limited usage for SIP transport.
</t>
<t hangText="RFC 4244, An Extension to SIP for Request History
Information (S):"> <xref target="RFC4244"/> defines the History-Info
header field, which
indicates information on how and why a call came to be routed to
a particular destination.
</t>
<t hangText="RFC 4145, TCP-Based Media Transport in the Session
Description Protocol (SDP) (S):"> <xref target="RFC4145"/> defines an
extension to SDP for setting up TCP-based
sessions between user agents. It defines who sets up the connection
and how its lifecycle is managed. It has seen relatively little usage
due to the small number of media types to date which use TCP.
</t>
<t hangText="RFC 4091, The Alternative Network Address Types (ANAT) Semantics
for the Session Description Protocol (SDP) Grouping Framework (S):">
<xref target="RFC4091"/> defines a mechanism for
including both IPv4 and IPv6 addresses for a media session as
alternates. This mechanism has been deprecated in favor of ICE
<xref target="I-D.ietf-mmusic-ice"/>.
</t>
<t hangText="draft-ietf-mmusic-sdp-media-capabilities, SDP Media
Capabilities Negotiation (S):"> <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"/>
defines an extension to the SDP capability negotiation framework <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"/> for negotiating
codecs, codec parameters, and media streams.
</t>
<t hangText="draft-ietf-sip-body-handling, Message Body Handling in
the Session Initiation Protocol (SIP):">
<xref target="I-D.ietf-sip-body-handling"/> clarifies
handling of bodies in SIP, focusing primarily on
multi-part behavior, which was underspecified in SIP.
</t>
</list>
</section>
<section anchor="sec-nat" title="NAT Traversal">
<t>
These SIP extensions are primarily aimed at addressing NAT traversal
for SIP.
</t>
<list style="hanging">
<t hangText="draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE)
(S):"> <xref target="I-D.ietf-mmusic-ice"/> defines a
technique for NAT traversal of media sessions for protocols that make
use of the offer/answer model. This specification is the IETF
recommended mechanism for NAT traversal for SIP media streams, and is
meant to be used even by endpoints which are themselves never behind a
NAT. A SIP option tag and media feature tag <xref
target="I-D.ietf-sip-ice-option-tag"/> have been defined for use with
ICE.
</t>
<t hangText="draft-ietf-mmusic-ice-tcp, TCP Candidates with
Interactive Connectivity
Establishment (ICE) (S):"> <xref target="I-D.ietf-mmusic-ice-tcp"/>
specifies the usage of ICE for TCP streams. This allows
for selection of RTP-based voice ontop of TCP only when NAT or
firewalls would prevent UDP-based voice from working.
</t>
<t hangText="RFC 3605, Real Time Control Protocol (RTCP) Attribute in
the Session Description Protocol (SDP) (S):"> <xref
target="RFC3605"/> defines a way to explicitly signal,
within an SDP message, the IP address and port for RTCP, rather than
using the port+1 rule in the Real Time Transport Protocol (RTP) <xref
target="RFC3550"/>. It is needed for devices behind NAT and used by
ICE.
</t>
<t hangText="draft-ietf-sip-outbound, Managing Client Initiated
Connections through
SIP (S):"> <xref target="I-D.ietf-sip-outbound"/>, 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.
</t>
<t hangText="RFC 3581, An Extension to SIP for Symmetric Response
Routing (S):"> <xref target="RFC3581"/> defines the rport
parameter of the Via header. It allows SIP responses to traverse
NAT.
</t>
<t hangText="draft-ietf-sip-gruu, Obtaining and Using Globally Routable User
Agent Identifiers (GRUU) in SIP (S):"> <xref
target="I-D.ietf-sip-gruu"/> 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.
</t>
</list>
</section>
<section title="Call Control Primitives">
<t>
Numerous SIP extensions provide a toolkit of dialog and call
management techniques. These techniques have been combined together to
build many SIP-based services.
</t>
<list style="hanging">
<t hangText="RFC 3515, The REFER Method (S):">REFER
<xref target="RFC3515"/> defines a mechanism for asking a user agent
to send a SIP request. It's a form of SIP remote control, and is the
primary tool used for call transfer in SIP. Beware that not all
potential uses of REFER (neither for all methods nor for all URI
schemes) are well defined. Implementors should only use the well-defined
ones, and should not second guess or freely assume behavior for the others
to avoid unexpected behavior of remote UAs, interoperability issues,
and other bad surprises.
</t>
<t hangText="RFC 3725, Best Current Practices for Third Party Call
Control (3pcc) (B):"> <xref target="RFC3725"/> defines a
number of different call flows that allow one SIP entity, called the
controller, to create SIP sessions amongst other SIP user agents.
</t>
<t hangText="RFC 3911, The SIP Join Header Field (S):"> <xref
target="RFC3911"/> 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.
</t>
<t hangText="RFC 3891, The SIP Replaces Header (S):"> <xref
target="RFC3891"/> defines a mechanism that allows a new dialog to
replace an existing dialog. It is useful for certain advanced transfer
services.
</t>
<t hangText="RFC 3892, The SIP Referred-By Mechanism (S):">
<xref target="RFC3892"/> 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.
</t>
<t hangText="RFC 4117, Transcoding Services Invocation in SIP Using
Third Party Call Control (I):"> <xref target="RFC4117"/> defines
how to use 3pcc for the purposes of invoking transcoding services for
a call.
</t>
</list>
</section>
<section title="Event Framework">
<list style="hanging">
<t hangText="RFC 3265, SIP-Specific Event Notification (S):"> <xref
target="RFC3265"/>
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.
</t>
<t hangText="RFC 3903, SIP Extension for Event State Publication (S):">
<xref target="RFC3903"/> 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.
</t>
<t hangText="RFC 4662, A Session Initiation Protocol (SIP) Event
Notification Extension for Resource Lists (S):"> <xref
target="RFC4662"/> defines an
extension to RFC 3265 that allows a client to subscribe to a list of
resources using a single subscription. The server, called a Resource
List Server (RLS) will "expand" the subscription and subscribe to each
individual member of the list. It has found applicability primarily in
the area of presence, but can be used with any event package.
</t>
<t hangText="draft-ietf-sip-subnot-etags, An Extension to Session
Initiation Protocol
(SIP) Events for Conditional Event Notification (S):">
<xref target="I-D.ietf-sip-subnot-etags"/> defines an
extension to RFC 3265 to optimize the performance of
notifications. When a client subscribes, it can indicate what
version of a document it has, so that the server can skip sending a
notification if the client is up to date. It is applicable to any
event package.
</t>
</list>
</section>
<section title="Event Packages">
<t>
These are event packages defined to utilize the SIP events
framework. Many of these are also listed elsewhere in their respective
areas.
</t>
<list style="hanging">
<t hangText="RFC 3680, A SIP Event Package for Registrations (S):">
<xref target="RFC3680"/> defines an event package for finding out
about changes in registration state.
</t>
<t hangText="draft-ietf-sipping-gruu-reg-event (S):">
<xref target="I-D.ietf-sipping-gruu-reg-event"/> is an extension to
the registration event package <xref target="RFC3680"/> that allows
user agents to learn about their GRUUs. It is particularly useful in
helping to synchronize a client and its registrar with its currently
valid temporary GRUU.
</t>
<t hangText="RFC 3842, A Message Summary and Message Waiting
Indication Event Package for SIP (S):"> <xref
target="RFC3482"/> 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.
</t>
<t hangText="RFC 3856, A Presence Event Package for SIP (S):">
<xref target="RFC3856"/> defines an event package for indicating user
presence through SIP.
</t>
<t hangText="RFC 3857, A Watcher Information Event Template Package
for SIP (S):"> <xref target="RFC3857"/>, 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.
</t>
<t hangText="RFC 4235, An INVITE Initiated Dialog Event Package for
SIP (S):"> <xref target="RFC4235"/> defines an event package for
learning the state of the dialogs in progress at a user agent, and is
one of several RFCs starting with the important number 42 <xref
target="HGTTG"/>.
</t>
<t hangText="RFC 4575, A SIP Event Package for Conference State (S):">
<xref target="RFC4575"/> defines
a mechanism for learning about changes in conference state, including
conference membership.
</t>
<t hangText="RFC 4730, A SIP Event Package for Keypress Stimulus
(KPML) (S):"> <xref target="RFC4730"/> defines a
way for an application in the network to subscribe to the set of
keypresses made on the keypad of a traditional telephone. It, along
with RFC 2833 <xref target="RFC2833"/>, are the two mechanisms
defined for handling DTMF. RFC 4730 is a signaling-path solution,
and RFC 2833 is a media-path solution.
</t>
<t hangText="draft-ietf-sipping-rtcp-summary, SIP Event Package for
Voice Quality Reporting
(S):"> <xref target="I-D.ietf-sipping-rtcp-summary"/> defines
a SIP event package that enables the collection
and reporting of metrics that measure the quality for Voice over
Internet Protocol (VoIP) sessions.
</t>
<t hangText="draft-ietf-sip-session-policy-framework, A Framework for
Session Initiation Protocol (SIP) Session Policies (S):">
<xref target="I-D.ietf-sip-session-policy-framework"/> defines a
framework for session policies. In this framework, policy servers are
used to tell user agents about the media characteristics required for
a particular session. The session policy framework has not been widely
implemented.
</t>
<t hangText="draft-ietf-sipping-policy-package, A Session Initiation
Protocol (SIP) Event
Package for Session-Specific Session Policies (S):"> <xref
target="I-D.ietf-sipping-policy-package"/> defines a SIP
event package used in conjunction with the session policy framework
<xref target="I-D.ietf-sip-session-policy-framework"/>.
</t>
<t hangText="draft-ietf-sipping-pending-additions, The Session
Initiation Protocol (SIP) Pending
Additions Event Package (S):"> <xref
target="I-D.ietf-sipping-pending-additions"/> defines a
SIP event package that allows a UA to learn whether consent has been
given for the addition of an address to a SIP "mailing list". It is
used in conjunction with the SIP framework for consent <xref
target="I-D.ietf-sip-consent-framework"/>.
</t>
</list>
</section>
<section title="Quality of Service">
<t>
Several specifications concern themselves with the interactions of SIP
with network Quality of Service (QoS) mechanisms.
</t>
<list style="hanging">
<t hangText="RFC 3312, Integration of Resource Management and SIP (S):">
<xref target="RFC3312"/>, updated by <xref
target="RFC4032"/> 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.</t>
<t hangText="draft-ietf-mmusic-qos-identification, Quality of Service
(QoS) Mechanism Selection in the Session Description Protocol
(SDP) (S):">
<xref target="I-D.ietf-mmusic-qos-identification"/> defines a
way for user agents to negotiate what type of end-to-end QoS
mechanism to use for a session. At this time, there are two
that can be used - RSVP and NSIS. This negotiation is done
through an SDP extension. Due to limited deployment of RSVP
and even more limited deployment of NSIS, this extension has
not been widely used. </t>
<t hangText="RFC 3313, Private SIP Extensions for Media Authorization
(I):"> <xref target="RFC3313"/> 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. </t>
<t hangText="RFC 3524, Mapping of Media Streams to Resource
Reservation Flows (S):"> <xref target="RFC3524"/>
defines a usage of the SDP grouping framework for indicating that a
set of media streams should be handled by a single resource
reservation.
</t>
</list>
</section>
<section title="Operations and Management">
<t>
Several specifications have been defined to support operations and
management of SIP systems. These include mechanisms for configuration
and network diagnostics.
</t>
<list style="hanging">
<t hangText="draft-ietf-sipping-config-framework, A Framework for SIP
User Agent Profile Delivery
(S):"> <xref target="I-D.ietf-sipping-config-framework"/>
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.
</t>
<t hangText="draft-ietf-sipping-rtcp-summary, SIP Event Package for
Voice Quality Reporting
(S):"> <xref target="I-D.ietf-sipping-rtcp-summary"/> defines
a SIP event package that enables the collection
and reporting of metrics that measure the quality for Voice over
Internet Protocol (VoIP) sessions.
</t>
</list>
</section>
<section title="SIP Compression">
<t>
Sigcomp <xref target="RFC3320"/> <xref target="RFC4896"/> 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.
</t>
<list style="hanging">
<t hangText="RFC 3486, Compressing SIP (S):"> <xref
target="RFC3486"/> defines a SIP URI parameter that can be used to
indicate that a SIP server supports Sigcomp.
</t>
<t hangText="draft-ietf-rohc-sigcomp-sip, Applying Signaling
Compression (SigComp) to the
Session Initiation Protocol (SIP) (S):">
<xref target="I-D.ietf-rohc-sigcomp-sip"/> defines how to
apply
Sigcomp to SIP.
</t>
</list>
</section>
<section title="SIP Service URIs">
<t>
Several extensions define well-known services that can be invoked by
constructing requests with the specific structures for the Request
URI, resulting in specific behaviors at the UAS.
</t>
<list style="hanging">
<t hangText="RFC 3087, Control of Service Context using Request URI
(I):"> <xref target="RFC3087"/> introduced the context of
using Request URIs, encoded appropriately, to invoke services.
</t>
<t hangText="RFC 4662, A SIP Event Notification Extension for Resource
Lists (S):"> <xref target="RFC4662"/>
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.
</t>
<t hangText="draft-ietf-sipping-uri-services, Framework and Security Considerations for Session Initiation Protocol
(SIP) Uniform Resource Identifier (URI)-List Services (S):">
<xref target="I-D.ietf-sipping-uri-services"/> defines the
framework for list services in SIP. In this framework, a UA
can include an XML list object in the body of various
requests and the server provides list-oriented services as a
consequence. For example, a SUBSCRIBE with a list subscribes
to the URI in the list. </t>
<t hangText="draft-ietf-sip-uri-list-subscribe, Subscriptions To
Request-Contained Resource Lists in SIP (S):">
<xref target="I-D.ietf-sip-uri-list-subscribe"/> uses the
URI list framework
<xref target="I-D.ietf-sipping-uri-services"/> and allows
a client to subscribe to a resource called a Resource
List Server. This server will generate subscriptions to
the URI in the list, and compile the resulting
information and send it back to the subscriber.
</t>
<t hangText="draft-ietf-sip-uri-list-message, Multiple-Recipient
MESSAGE Requests in SIP
(S):"><xref target="I-D.ietf-sip-uri-list-message"/> uses the URI list
framework <xref target="I-D.ietf-sipping-uri-services"/>
and allows a client to send a MESSAGE to a number of
recipients.
</t>
<t hangText="draft-ietf-sip-uri-list-conferencing, Conference
Establishment Using
Request-Contained Lists in SIP (S):">
<xref target="I-D.ietf-sip-uri-list-conferencing"/> uses
the URI list framework
<xref target="I-D.ietf-sipping-uri-services"/> and allows a
client to ask the server to act as a conference focus and
send an invitation to each recipient in the list.
</t>
<t hangText="RFC 4240, Basic Network Media Services with SIP (I):">
<xref target="RFC4240"/> defines a way for SIP
application servers to invoke announcement and conferencing services
from a media server. This is accomplished through a set of defined URI
parameters which tell the media server what to do, such as what file
to play and what language to render it in.
</t>
<t hangText="RFC 4458, Session Initiation Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice Response (IVR) (I):">
<xref target="RFC4458"/> defines a way to invoke voicemail and IVR
services by using a SIP URI constructed in a particular way.
</t>
</list>
</section>
<section title="Minor Extensions">
<t>
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.
</t>
<list style="hanging">
<t hangText="RFC 4488, Suppression of the SIP REFER Implicit
Subscription (S):"> <xref
target="RFC4488"/> 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.
</t>
<t hangText="RFC 4538, Request Authorization through Dialog
Identification in SIP (S):"> <xref
target="RFC4538"/> 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 <xref
target="I-D.ietf-sipping-app-interaction-framework"/>.
</t>
<t hangText="RFC 4508, Conveying Feature Tags with the REFER Method in
SIP (S):"> <xref target="RFC4508"/>
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 intentended target of the referred request.
</t>
<t hangText="draft-ietf-sip-answermode, Requesting Answer Modes for
SIP (S):"> <xref target="I-D.ietf-sip-answermode"/>
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.
</t>
<t hangText="RFC 5079, Rejecting Anonymous Requests in
SIP (S):"> <xref target="RFC5079"/> 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.
</t>
<t hangText="draft-ietf-sip-multiple-refer, Referring to Multiple
Resources in SIP (S):">
<xref target="I-D.ietf-sip-multiple-refer"/> 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.
</t>
<t hangText="RFC 4483, A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages (S):"> <xref target="RFC4483"/>
defines a mechanism for content indirection. Instead of
carrying an object within a SIP body, a URL reference is carried
instead, and the recipient dereferences the URL to obtain the
object. The specification has potential applicability for sending
large instant messages, but has yet to find much actual use.
</t>
<t hangText="RFC 3890, A Transport Independent Bandwidth Modifier for
the Session Description Protocol (SDP) (S):"> <xref
target="RFC3890"/> specifies an SDP extension that
allows for the description of the bandwidth for a media session that
is independent of the underlying transport mechanism.
</t>
<t hangText="RFC 4583, Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams (S):"> <xref
target="RFC4583"/> defines a mechanism
in SDP to signal floor control streams that use BFCP. It is used for
Push-To-Talk and conference floor control.
</t>
<t hangText="draft-ietf-mmusic-connectivity-precon, Connectivity
Preconditions for Session
Description Protocol Media Streams (S):"> <xref
target="I-D.ietf-mmusic-connectivity-precon"/> defines a
usage of the precondition framework <xref target="RFC3312"/>. The
connectivity precondition makes sure that the session doesn't get
established until actual packet connectivity is checked.
</t>
<t hangText="RFC 4796, The SDP (Session Description Protocol) Content
Attribute (S):"> <xref target="RFC4796"/> defines an SDP attribute for
describing the purpose of a
media stream. Examples include a slide view, the speaker, a sign
language feed, and so on.
</t>
<t hangText="draft-ietf-sipping-v6-transition, IPv6 Transition in the
Session Initiation Protocol (SIP) (S):">
<xref target="I-D.ietf-sipping-v6-transition"/> defines practices
for interworking between IPv6 and IPv6 user agents. This is done
through multi-homed proxies which interwork IPv4 and IPv6, along
with ICE <xref target="I-D.ietf-mmusic-ice"/> for media
traversal. The specification includes
some minor extensions and clarifications to SDP in order to cover
some additional cases. </t>
<t hangText="draft-ietf-sip-connect-reuse, Connection Reuse in the
Session Initiation Protocol (SIP) (S):">
<xref target="I-D.ietf-sip-connect-reuse"/> defines an
extension to SIP that allows a TLS connection between
servers to be reused for requests in both
directions. Normally two connections are set up between a
pair of servers, one for requests in each direction.
</t>
</list>
</section>
<section title="Security Mechanisms">
<t>
Several extensions provide additional security features to SIP.
</t>
<list style="hanging">
<t hangText="RFC 4474, Enhancements for Authenticated Identity
Management in SIP (S):"> <xref
target="RFC4474"/> defines a mechanism for providing a
cryptographically verifiable identity of the calling party in a SIP
request. Known as "SIP Identity", this mechanism provides an
alternative to RFC 3325. It has seen little deployment so far, but its
importance as a key construct for anti-spam techniques
and new security mechanisms makes it a core part of the SIP specifications.
</t>
<t hangText="RFC 4916, Connected Identity in the Session Initiation
Protocol (SIP) (S):"> <xref
target="RFC4916"/> formally updates RFC 3261. It defines an
extension to SIP that allows a calling user to determine the identity of the
final called user (connected party). Due to forwarding and retargeting services, this may not be the
same as the user that the caller was originally trying to reach. The
mechanism works in tandem with the SIP identity specification <xref
target="RFC4474"/> to provide signatures over the
connected party identity. It can also be used
if a party identity changes mid call due to third party call control
actions or PSTN behavior.
</t>
<t hangText="draft-ietf-sip-sips, The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)
(S):"> <xref target="I-D.ietf-sip-sips"/>
formally updated RFC 3261. It revises the processing of
the SIPS URI, originally
defined in RFC 3261, to fix many errors and problems
that have been encountered with that mechanism.
</t>
<t hangText="draft-ietf-sip-domain-certs, Domain Certificates in the
Session Initiation Protocol (SIP) (B):">
<xref target="I-D.ietf-sip-domain-certs"/> clarifies the
usage of SIP over TLS with regards to certificate
handling, and defines additional procedures needed for
interoperability.
</t>
<t hangText="RFC 3323, A Privacy Mechanism for the Session Initiation
Protocol (SIP) (S):"> <xref target="RFC3323"/> defines the
Privacy header field, used by clients to request anonymity for their
requests. Though it defines several privacy services, the only one
broadly used is the one that supports privacy of the P-Asserted-Identity
header field <xref target="RFC3325"/>.
</t>
<t hangText="RFC 4567, Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP) (S):"> <xref target="RFC4567"/> defines
extensions to SDP that allow tunneling of an key
management protocol, namely MIKEY
<xref target="RFC3830"/>, through offer/answer
exchanges. This mechanism is one of three SRTP keying
techniques specified for SIP, with DTLS-SRTP
<xref target="I-D.ietf-sip-dtls-srtp-framework"/> having
been selected as the final solution.
</t>
<t hangText="RFC 4568, Session Description Protocol (SDP)
Security Descriptions for Media Streams (S):">
<xref target="RFC4568"/> defines extensions to SDP that allow for
the negotiation of keying material directly through offer/answer,
without a separate key management protocol. This mechanism,
sometimes called sdescriptions, has the drawback that the media keys
are available to any entity that has visibility to the SDP. It is
one of three SRTP keying techniques specified for SIP, with
DTLS-SRTP <xref target="I-D.ietf-sip-dtls-srtp-framework"/> having
been selected as the final solution.
</t>
<t hangText="draft-ietf-sip-dtls-srtp-framework, Framework for
Establishing an SRTP Security Context using DTLS (S):">
<xref target="I-D.ietf-sip-dtls-srtp-framework"/> defines
the overall framework and SDP and SIP processing required
to perform key management for RTP using Datagram TLS
(DTLS) <xref target="RFC4347"/> directly between
endpoints, over the media path. It is
one of three SRTP keying techniques specified for SIP, with
DTLS-SRTP <xref target="I-D.ietf-sip-dtls-srtp-framework"/> having
been selected as the final solution.
</t>
<t hangText="draft-ietf-mmusic-sdp-dtls, Session Description Protocol
(SDP) Indicators for Datagram Transport Layer Security
(DTLS) (S):"> <xref target="I-D.ietf-mmusic-sdp-dtls"/>
defines the usage of SDP with DTLS-SRTP.
</t>
<t hangText="RFC 3853, S/MIME AES Requirement for SIP (S):"> <xref
target="RFC3853"/> formally updates RFC 3261. It is a brief
specification that updates the
cryptography mechanisms used in SIP S/MIME. However, SIP S/MIME has
seen very little deployment.
</t>
<t hangText="draft-ietf-sip-certs, Certificate Management Service for
The Session
Initiation Protocol (SIP) (S):"> <xref target="I-D.ietf-sip-certs"/>
defines a certificate service for SIP whose purpose is to
facilitate the deployment of S/MIME. The certificate service allows
clients to store and retrieve their own certificates, in addition to
obtaining the certificates for other users.
</t>
<t hangText="RFC 3893, Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format (S):"> <xref target="RFC3893"/> defines a
SIP message fragment which can be signed in
order to provide an authenticated identity over a request. It was an
early predecessor to <xref target="RFC4474"/>, and
consequently AIB has seen no deployment.
</t>
<t hangText="draft-ietf-sip-saml, SIP SAML Profile and Binding (S):"> <xref
target="I-D.ietf-sip-saml"/> defines the usage of the
Security Assertion Markup Language (SAML) within SIP, and describes
how to use it in conjunction with SIP identity <xref
target="RFC4474"/> to provide authenticated assertions about a users
role or attributes.
</t>
<t hangText="draft-ietf-sip-consent-framework, A Framework for
Consent-Based Communications in
the Session Initiation Protocol (SIP) (S):"> <xref
target="I-D.ietf-sip-consent-framework"/> defines
several extensions to SIP, including the Trigger-Consent and
Permission-Missing header fields. These header fields, in addition to
the other procedures defined in the document, define a way to manage
membership on "SIP mailing lists" used for instant messaging or
conferencing. In particular, it helps avoid the problem of using such
amplification services for the purposes of an attack on the network,
by making sure a user authorizes the addition of their address onto
such a service.
</t>
<t hangText="draft-ietf-sipping-consent-format, A Document Format for
Requesting Consent (S):">
<xref target="I-D.ietf-sipping-consent-format"/> defines
an XML object used by the consent framework. Consent
documents are sent from SIP "mailing list servers" to
users to allow them to manage their membership on lists.
</t>
<t hangText="draft-ietf-sipping-pending-additions, The Session
Initiation Protocol (SIP) Pending
Additions Event Package (S):"> <xref
target="I-D.ietf-sipping-pending-additions"/> defines a
SIP event package that allows a UA to learn whether consent has been
given for the addition of an address to a SIP "mailing list". It is
used in conjunction with the SIP framework for consent <xref
target="I-D.ietf-sip-consent-framework"/>.
</t>
<t hangText="RFC 3329, Security Mechanism Agreement for SIP (S):">
<xref target="RFC3329"/> 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 <xref target="3GPP.24.229"/>, and is needed only
when there is a multiplicity
of security mechanisms deployed at a particular server. In practice,
this has not been the case.
</t>
<t hangText="draft-ietf-sip-e2m-sec, End-to-Middle Security in SIP
(S):"> <xref target="I-D.ietf-sip-e2m-sec"/> defines
mechanisms for
providing confidentiality and integrity for SIP message bodies sent
from user agents to specific network intermediaries.
</t>
<t hangText="RFC 4572, Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Description
Protocol (SDP) (S):"> <xref target="RFC4572"/> specifies a mechanism
for signaling TLS-based media
streams between endpoints. It expands the TCP-based media signaling
parameters defined in <xref target="RFC4145"/> to include fingerprint
information for TLS streams, so that TLS can operate between end hosts
using self-signed certificates.
</t>
<t hangText="RFC 5027, Security
Preconditions for Session Description
Protocol Media Streams (S):"> <xref
target="RFC5027"/> defines
a precondition for use with the preconditions framework <xref
target="RFC3312"/>. The security precondition prevents a session from
being established until a security media stream is set up.
</t>
</list>
</section>
<section title="Conferencing">
<t>
Numerous SIP and SDP extensions are aimed at conferencing as their
primary application.
</t>
<list style="hanging">
<t hangText="RFC 4574, The SDP (Session Description Protocol) Label
Attribute (S):"> <xref target="RFC4574"/> defines an SDP attribute for providing an opaque label for
media streams. These labels can be referred to by external documents,
and in particular, by conference policy documents. This allows a UA to
tie together documents it may obtain through conferencing mechanisms
to media streams to which they refer.
</t>
<t hangText="RFC 3911, The SIP Join Header Field (S):"> <xref
target="RFC3911"/> 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.
</t>
<t hangText="RFC 4575, A SIP Event Package for Conference State (S):">
<xref target="RFC4575"/> defines
a mechanism for learning about changes in conference state, including
conference membership.
</t>
<t hangText="draft-ietf-sip-multiple-refer, Referring to Multiple
Resources in SIP (S):">
<xref target="I-D.ietf-sip-multiple-refer"/> 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.
</t>
<t hangText="draft-ietf-sip-uri-list-conferencing, Conference
Establishment Using
Request-Contained Lists in SIP (S):"> <xref
target="I-D.ietf-sip-uri-list-conferencing"/> is
similar to <xref
target="I-D.ietf-sip-uri-list-subscribe"/>. 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.
</t>
<t hangText="RFC4579, Session Initiation Protocol (SIP) Call Control -
Conferencing for User Agents (B):">
<xref target="RFC4579"/> defines best practice procedures
and call flows for conferencing. This includes conference
creation, joining, and dial out, amongst other
capabilities.
</t>
<t hangText="RFC 4583, Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams (S):"> <xref
target="RFC4583"/> defines a mechanism
in SDP to signal floor control streams that use BFCP. It is used for
Push-To-Talk and conference floor control.
</t>
</list>
</section>
<section title="Instant Messaging, Presence and Multimedia">
<t>
SIP provides extensions for instant messaging, presence, and
multimedia.
</t>
<list style="hanging">
<t hangText="RFC 3428, SIP Extension for Instant Messaging (S):">
<xref target="RFC3428"/> defines the MESSAGE method, used for sending
an instant message without setting up a session (sometimes called
"page mode").
</t>
<t hangText="RFC 3856, A Presence Event Package for SIP (S):">
<xref target="RFC3856"/> defines an event package for indicating user
presence through SIP.
</t>
<t hangText="RFC 3857, A Watcher Information Event Template Package
for SIP (S):"> <xref target="RFC3857"/>, 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.
</t>
<t hangText="draft-ietf-mmusic-file-transfer-mech, A Session
Description Protocol (SDP)
Offer/Answer Mechanism to Enable File Transfer (S):"> <xref
target="I-D.ietf-mmusic-file-transfer-mech"/> defines a
mechanism for signaling a file transfer session with SIP.
</t>
</list>
</section>
<section title="Emergency Services">
<t>
Emergency services include pre-emption features, which allow
authorized individuals to gain access to network resources in time of
emergency, along with traditional emergency calling.
</t>
<list style="hanging">
<t hangText="RFC 4411, Extending the SIP Reason Header for Preemption
Events (S):"> <xref target="RFC4411"/> 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.
</t>
<t hangText="RFC 4412, Communications Resource Priority for SIP (S):">
<xref target="RFC4412"/> defines a new header field,
Resource-Priority, that allows a session to get priority treatment
from the network.
</t>
<t hangText="draft-ietf-sip-location-conveyance, Location Conveyance
for the Session Initiation Protocol (S):">
<xref target="I-D.ietf-sip-location-conveyance"/> defines
a mechanism for carrying location objects in SIP
messages. This is used to convey location from a UA to an
emergency call taker. </t>
</list>
</section>
<section title="Security Considerations">
<t>
This specification is an overview of existing specifications, and does
not introduce any security considerations on its own. Of course, the
world would be far more secure if everyone would follow one simple
rule: "Don't Panic!" <xref target="HGTTG"/>.
</t>
</section>
<section title="IANA Considerations">
<t>
None.
</t>
</section>
<section title="Acknowledgements">
<t>
The author would like to thank Spencer Dawkins, Brian Stucker, Keith
Drage, John Elwell and Avshalom Houri for their comments on this document.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.2026"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.I-D.ietf-mmusic-ice"?>
<?rfc include="reference.RFC.3320"?>
<?rfc include="reference.RFC.3893"?>
<?rfc include="reference.RFC.3427"?>
<?rfc include="reference.RFC.2543"?>
<?rfc include="reference.RFC.3263"?>
<?rfc include="reference.RFC.2782"?>
<?rfc include="reference.RFC.2915"?>
<?rfc include="reference.RFC.3265"?>
<?rfc include="reference.RFC.3323"?>
<?rfc include="reference.RFC.3325"?>
<?rfc include="reference.RFC.3327"?>
<?rfc include="reference.RFC.3581"?>
<?rfc include="reference.RFC.4320"?>
<?rfc include="reference.RFC.4474"?>
<?rfc include="reference.I-D.ietf-sip-gruu"?>
<?rfc include="reference.I-D.ietf-sip-outbound"?>
<?rfc include="reference.RFC.2848"?>
<?rfc include="reference.RFC.3910"?>
<?rfc include="reference.RFC.3372"?>
<?rfc include="reference.RFC.3398"?>
<?rfc include="reference.RFC.3578"?>
<?rfc include="reference.RFC.3960"?>
<?rfc include="reference.RFC.3262"?>
<?rfc include="reference.RFC.3311"?>
<?rfc include="reference.RFC.2976"?>
<?rfc include="reference.RFC.3326"?>
<?rfc include="reference.RFC.3608"?>
<?rfc include="reference.RFC.3840"?>
<?rfc include="reference.RFC.3841"?>
<?rfc include="reference.RFC.4028"?>
<?rfc include="reference.RFC.4168"?>
<?rfc include="reference.RFC.4244"?>
<?rfc include="reference.RFC.4488"?>
<?rfc include="reference.RFC.4538"?>
<?rfc include="reference.RFC.4508"?>
<?rfc include="reference.I-D.ietf-sip-answermode"?>
<reference anchor="HGTTG">
<front>
<title>The Hitchhiker's Guide to the Galaxy</title>
<author initials="D." surname="Adams"
fullname="Douglas Adams">
</author>
<date month="September" year="1979" />
</front>
</reference>
<?rfc include="reference.RFC.5079"?>
<?rfc include="reference.I-D.ietf-sip-multiple-refer"?>
<?rfc include="reference.RFC.3515"?>
<?rfc include="reference.RFC.3725"?>
<?rfc include="reference.RFC.3891"?>
<?rfc include="reference.RFC.3892"?>
<?rfc include="reference.RFC.3911"?>
<?rfc include="reference.RFC.4117"?>
<?rfc include="reference.RFC.3903"?>
<?rfc include="reference.RFC.3680"?>
<?rfc include="reference.RFC.3856"?>
<?rfc include="reference.RFC.3857"?>
<?rfc include="reference.RFC.4235"?>
<?rfc include="reference.RFC.4575"?>
<?rfc include="reference.RFC.4730"?>
<?rfc include="reference.I-D.ietf-sipping-rtcp-summary"?>
<?rfc include="reference.RFC.3312"?>
<?rfc include="reference.RFC.4032"?>
<?rfc include="reference.RFC.3313"?>
<?rfc include="reference.I-D.ietf-sipping-config-framework"?>
<?rfc include="reference.RFC.3486"?>
<?rfc include="reference.RFC.3482"?>
<?rfc include="reference.RFC.3087"?>
<?rfc include="reference.RFC.4662"?>
<?rfc include="reference.I-D.ietf-sip-uri-list-subscribe"?>
<?rfc include="reference.I-D.ietf-sip-uri-list-message"?>
<?rfc include="reference.I-D.ietf-sip-uri-list-conferencing"?>
<?rfc include="reference.RFC.3853"?>
<?rfc include="reference.RFC.3329"?>
<?rfc include="reference.I-D.ietf-sip-e2m-sec"?>
<?rfc include="reference.RFC.3428"?>
<?rfc include="reference.RFC.4411"?>
<?rfc include="reference.RFC.4412"?>
<?rfc include="reference.I-D.ietf-sipping-app-interaction-framework"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.3388"?>
<?rfc include="reference.RFC.3605"?>
<?rfc include="reference.RFC.4916"?>
<?rfc include="reference.I-D.ietf-sip-fork-loop-fix"?>
<?rfc include="reference.RFC.3959"?>
<?rfc include="reference.RFC.3204"?>
<?rfc include="reference.RFC.3420"?>
<?rfc include="reference.RFC.4145"?>
<?rfc include="reference.RFC.4091"?>
<?rfc include="reference.I-D.ietf-mmusic-ice-tcp"?>
<?rfc include="reference.RFC.4483"?>
<?rfc include="reference.RFC.3890"?>
<?rfc include="reference.RFC.4583"?>
<?rfc include="reference.RFC.5027"?>
<?rfc include="reference.I-D.ietf-mmusic-connectivity-precon"?>
<?rfc include="reference.RFC.4796"?>
<?rfc include="reference.RFC.4574"?>
<?rfc include="reference.I-D.ietf-sipping-policy-package"?>
<?rfc include="reference.RFC.3524"?>
<?rfc include="reference.RFC.4240"?>
<?rfc include="reference.I-D.ietf-sip-certs"?>
<?rfc include="reference.I-D.ietf-sip-consent-framework"?>
<?rfc include="reference.I-D.ietf-sip-saml"?>
<?rfc include="reference.I-D.ietf-sipping-pending-additions"?>
<?rfc include="reference.RFC.4572"?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-capability-negotiation"?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-media-capabilities"?>
<?rfc include="reference.I-D.ietf-mmusic-file-transfer-mech"?>
<?rfc include="reference.I-D.ietf-sip-ice-option-tag"?>
<?rfc include="reference.3gpp.24.229"?>
<?rfc include="reference.I-D.ietf-sip-record-route-fix"?>
<?rfc include="reference.I-D.ietf-sip-subnot-etags"?>
<?rfc include="reference.I-D.ietf-sip-sips"?>
<?rfc include="reference.RFC.4896"?>
<?rfc include="reference.I-D.ietf-rohc-sigcomp-sip"?>
<?rfc include="reference.I-D.ietf-simple-simple"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.4567"?>
<?rfc include="reference.RFC.4568"?>
<?rfc include="reference.I-D.ietf-sip-dtls-srtp-framework"?>
<?rfc include="reference.I-D.ietf-ecrit-framework"?>
<?rfc include="reference.RFC.2833"?>
<?rfc include="reference.RFC.4458"?>
<?rfc include="reference.RFC.3830"?>
<?rfc include="reference.RFC.4347"?>
<?rfc include="reference.I-D.ietf-sipping-v6-transition"?>
<?rfc include="reference.I-D.ietf-sipping-update-pai"?>
<?rfc include="reference.RFC.3665"?>
<?rfc include="reference.RFC.3666"?>
<?rfc include="reference.I-D.ietf-sip-ipv6-abnf-fix"?>
<?rfc include="reference.RFC.4497"?>
<?rfc include="reference.I-D.ietf-sip-ua-privacy"?>
<?rfc include="reference.I-D.ietf-sip-body-handling"?>
<?rfc include="reference.I-D.ietf-sip-domain-certs"?>
<?rfc include="reference.I-D.ietf-sipping-gruu-reg-event"?>
<?rfc include="reference.I-D.ietf-sip-session-policy-framework"?>
<?rfc include="reference.I-D.ietf-mmusic-qos-identification"?>
<?rfc include="reference.I-D.ietf-sipping-uri-services"?>
<?rfc include="reference.I-D.ietf-sip-connect-reuse"?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-dtls"?>
<?rfc include="reference.I-D.ietf-sipping-consent-format"?>
<?rfc include="reference.RFC.4579"?>
<?rfc include="reference.I-D.ietf-sip-location-conveyance"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 17:43:59 |