draft-ietf-sip-hitchhikers-guide-03.txt   draft-ietf-sip-hitchhikers-guide-04.txt 
SIP J. Rosenberg SIP J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational July 5, 2007 Intended status: Informational November 15, 2007
Expires: January 6, 2008 Expires: May 18, 2008
A Hitchhiker's Guide to the Session Initiation Protocol (SIP) A Hitchhiker's Guide to the Session Initiation Protocol (SIP)
draft-ietf-sip-hitchhikers-guide-03 draft-ietf-sip-hitchhikers-guide-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2008. This Internet-Draft will expire on May 18, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Session Initiation Protocol (SIP) is the subject of numerous The Session Initiation Protocol (SIP) is the subject of numerous
specifications that have been produced by the IETF. It can be specifications that have been produced by the IETF. It can be
difficult to locate the right document, or even to determine the set difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP. This specification serves of Request for Comments (RFC) about SIP. This specification serves
as a guide to the SIP RFC series. It lists the specifications under as a guide to the SIP RFC series. It lists the specifications under
the SIP umbrella, briefly summarizes each, and groups them into the SIP umbrella, briefly summarizes each, and groups them into
categories. categories.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope of this Document . . . . . . . . . . . . . . . . . . . . 3 2. Scope of this Document . . . . . . . . . . . . . . . . . . . . 4
3. Core SIP Specifications . . . . . . . . . . . . . . . . . . . 4 3. Core SIP Specifications . . . . . . . . . . . . . . . . . . . 5
4. Public Switched Telephone Network (PSTN) Interworking . . . . 7 4. Public Switched Telephone Network (PSTN) Interworking . . . . 9
5. General Purpose Infrastructure Extensions . . . . . . . . . . 9 5. General Purpose Infrastructure Extensions . . . . . . . . . . 10
6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 11 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 12 7. Call Control Primitives . . . . . . . . . . . . . . . . . . . 13
8. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Event Framework . . . . . . . . . . . . . . . . . . . . . . . 14
9. Call Control Primitives . . . . . . . . . . . . . . . . . . . 14 9. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Event Framework and Packages . . . . . . . . . . . . . . . . . 15 10. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 16
11. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 16 11. Operations and Management . . . . . . . . . . . . . . . . . . 17
12. Operations and Management . . . . . . . . . . . . . . . . . . 17 12. SIP Compression . . . . . . . . . . . . . . . . . . . . . . . 17
13. SIP Compression . . . . . . . . . . . . . . . . . . . . . . . 17 13. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 18
14. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 18 14. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 19
15. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 19 15. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 20
16. Instant Messaging, Presence and Multimedia . . . . . . . . . . 20 16. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 23
17. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 21 17. Instant Messaging, Presence and Multimedia . . . . . . . . . . 24
18. Security Considerations . . . . . . . . . . . . . . . . . . . 21 18. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 24
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 19. Security Considerations . . . . . . . . . . . . . . . . . . . 25
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
21. Informative References . . . . . . . . . . . . . . . . . . . . 21 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 22. Informative References . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [1] is the subject of numerous The Session Initiation Protocol (SIP) [RFC3261] is the subject of
specifications that have been produced by the IETF. It can be numerous specifications that have been produced by the IETF. It can
difficult to locate the right document, or even to determine the set be difficult to locate the right document, or even to determine the
of Request for Comments (RFC) about SIP. Don't Panic! [42] This set of Request for Comments (RFC) about SIP. Don't Panic! [HGTTG]
specification serves as a guide to the SIP RFC series. It lists the This specification serves as a guide to the SIP RFC series. It lists
specifications under the SIP umbrella. For each specification, a the specifications under the SIP umbrella. For each specification, a
paragraph or so description is included that summarizes the purpose paragraph or so description is included that summarizes the purpose
of the specification. Each specification also includes a letter that of the specification. Each specification also includes a letter that
designates its category in the standards track [2]. These values designates its category in the standards track [RFC2026]. These
are: values are:
S: Standards Track (Proposed Standard, Draft Standard, or Standard) S: Standards Track (Proposed Standard, Draft Standard, or Standard)
E: Experimental E: Experimental
B: Best Current Practice B: Best Current Practice
I: Informational I: Informational
The specifications are grouped together by topic. Typically, SIP The specifications are grouped together by topic. The topics are:
extensions fit naturally into topic areas, and implementations
interested in a particular topic often implement many or all of the Core: The essential SIP specifications that are expected to be
specifications in that area. There are some specifications which utilized for every session or registration.
fall into multiple topic areas, in which case they are listed more
than once. PSTN Interop: Specifications related to interworking with the
telephone network.
General Purpose Infrastructure: General purpose extensions to SIP,
SDP and MIME, but ones that are not expected to always be used.
NAT Traversal: Specifications to deal with firewall and NAT
traversal.
Minor Extensions: Specifications that solve a narrow problem space
or provide an optimization.
Conferencing: Specifications for multimedia conferencing.
Call Control Primitives: Specifications for manipulating SIP dialogs
and calls.
Event Framework: Defines the core specifications for the SIP event
framework, providing for pub/sub capability.
Event Packages: Packages that utilize the SIP event framework.
Quality of Service: Specifications related to multimedia quality of
service (QoS).
Operations and Management: Specifications related to configuration
and monitoring of SIP deployments.
SIP Compression: Specifications to facilitate usage of SIP with the
Signaling Compression (Sigcomp) framework.
SIP Service URIs: Specifications on how to use SIP URIs to address
multimedia services.
Security Mechanisms: Specifications providing security functionality
for SIP.
Instant Messaging, Presence, and Multimedia: SIP extensions related
to IM, presence and multimedia. This covers only the SIP
extensions related to these topics. See [I-D.ietf-simple-simple]
for a full treatment of SIP for IM and Presence (SIMPLE).
Emergency Services: SIP extensions related to emergency services.
See [I-D.ietf-ecrit-framework] for a more complete treatment of
additional functionality related to emergency services.
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.
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 [HGTTG].
This document itself is not an update to RFC 3261 or an extension to This document itself is not an update to RFC 3261 or an extension to
SIP. It is an informational document, meant to guide newcomers, SIP. It is an informational document, meant to guide newcomers,
implementors and deployers to the SIP suite of specifications. implementors and deployers to the many of the specifications
associated with SIP.
2. Scope of this Document 2. Scope of this Document
It is very difficult to enumerate the set of SIP specifications. It is very difficult to enumerate the set of SIP specifications.
This is because there are many protocols that are intimately related This is because there are many protocols that are intimately related
to SIP and used by nearly all SIP implementations, but are not to SIP and used by nearly all SIP implementations, but are not
formally SIP extensions. As such, this document formally defines a formally SIP extensions. As such, this document formally defines a
"SIP specification" as: "SIP specification" as:
o Any specification that defines an extension to SIP itself, where o Any specification that defines an extension to RFC 3261, where an
an extension is a mechanism that changes or updates in some way a extension is a mechanism that changes or updates in some way a
behavior specified in RFC 3261 behavior specified there.
o The basic SDP specification, RFC 4566 [RFC4566], and any
specification that defines an extension to SDP whose primary
purpose is to support SIP.
o Any specification that defines an extension to SDP whose primary
purpose is to support SIP
o Any specification that defines a MIME object whose primary purpose o Any specification that defines a MIME object whose primary purpose
is to support SIP is to support SIP
Excluded from this list are requirements, architectures, registry Excluded from this list are requirements, architectures, registry
definitions, non-normative frameworks, and processes. Best Current definitions, non-normative frameworks, and processes. Best Current
Practices are included when they normatively define mechanisms for Practices are included when they normatively define mechanisms for
accomplishing a task. accomplishing a task.
The SIP change process [8] defines two types of extensions to SIP. The SIP change process [RFC3427] defines two types of extensions to
These are normal extensions and the so-called P-headers (where P SIP. These are normal extensions and the so-called P-headers (where
stands for "preliminary", "private", or "proprietary", and the "P-" P stands for "preliminary", "private", or "proprietary", and the "P-"
prefix is included in the header field name) are meant to be used in prefix is included in the header field name), which are meant to be
areas of limited applicability. P-headers cannot be defined in the used in areas of limited applicability. P-headers cannot be defined
standards track. For the most part, P-headers are not included in in the standards track. For the most part, P-headers are not
the listing here, with the exception of those which have seen general included in the listing here, with the exception of those which have
usage despite their P-header status. seen general usage despite their P-header status.
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.
3. Core SIP Specifications 3. Core SIP Specifications
The core SIP specifications represent the set of specifications whose The core SIP specifications represent the set of specifications whose
functionality is broadly applicable. An extension is broadly functionality is broadly applicable. An extension is broadly
applicable if it fits into one of the following categories: applicable if it fits into one of the following categories:
o For specifications that impact SIP session management, the o For specifications that impact SIP session management, the
extension would be used for almost every session initiated by a extension would be used for almost every session initiated by a
user agent user agent
skipping to change at page 4, line 42 skipping to change at page 6, line 17
would be used for almost every registration initiated by a user would be used for almost every registration initiated by a user
agent agent
o For specifications that impact SIP subscriptions, the extension o For specifications that impact SIP subscriptions, the extension
would be used for almost every subscription initiated by a user would be used for almost every subscription initiated by a user
agent agent
In other words, these are not specifications that are used just for In other words, these are not specifications that are used just for
some requests and not others; they are specifications that would some requests and not others; they are specifications that would
apply to each and every request that the extension is relevant for. apply to each and every request that the extension is relevant for.
In the galaxy of SIP, these specifications are like towels [42]. In the galaxy of SIP, these specifications are like towels [HGTTG].
RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the RFC 3261, The Session Initiation Protocol (S): [RFC3261] is the core
core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. SIP protocol itself. RFC 3261 is an update to [RFC2543]. It is
It is the president of the galaxy [42] as far as the suite of SIP the president of the galaxy [HGTTG] as far as the suite of SIP
specifications is concerned. specifications is concerned.
RFC 3263, Locating SIP Servers (S): RFC 3263 [10] provides DNS RFC 3263, Locating SIP Servers (S): [RFC3263] provides DNS
procedures for taking a SIP URI, and determining a SIP server that procedures for taking a SIP URI, and determining a SIP server that
is associated with that SIP URI. RFC 3263 is essential for any is associated with that SIP URI. RFC 3263 is essential for any
implementation using SIP with DNS. RFC 3263 makes use of both DNS implementation using SIP with DNS. RFC 3263 makes use of both DNS
SRV records [11] and NAPTR records [12]. SRV records [RFC2782] and NAPTR records [RFC2915].
RFC 3264, An Offer/Answer Model with the Session Description Protocol RFC 3264, An Offer/Answer Model with the Session Description Protocol
(S): RFC 3264 [4] defines how the Session Description Protocol (SDP) (S): [RFC3264] defines how the Session Description Protocol (SDP)
[78] is used with SIP to negotiate the parameters of a media [RFC4566] is used with SIP to negotiate the parameters of a media
session. It is in widespread usage and an integral part of the session. It is in widespread usage and an integral part of the
behavior of RFC 3261. behavior of RFC 3261.
RFC 3265, SIP-Specific Event Notification (S): RFC 3265 [13] defines RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the
the SUBSCRIBE and NOTIFY methods. These two methods provide a SUBSCRIBE and NOTIFY methods. These two methods provide a general
general event notification framework for SIP. To actually use the event notification framework for SIP. To actually use the
framework, extensions need to be defined for specific event framework, extensions need to be defined for specific event
packages. An event package defines a schema for the event data, packages. An event package defines a schema for the event data,
and describes other aspects of event processing specific to that and describes other aspects of event processing specific to that
schema. An RFC 3265 implementation is required when any event schema. An RFC 3265 implementation is required when any event
package is used. package is used.
RFC 3325, Private Extensions to SIP for Asserted Identity within RFC 3325, Private Extensions to SIP for Asserted Identity within
Trusted Networks (I): Though its P-header status implies that it has Trusted Networks (I): Though its P-header status implies that it has
limited applicability, RFC 3325 [15], which defines the limited applicability, [RFC3325], which defines the P-Asserted-
P-Asserted-ID header field has been widely deployed. It is used Identity header field, has been widely deployed. It is used as
as the basic mechanism for providing secure caller ID services. the basic mechanism for providing network asserted caller ID
services.
RFC 3327, SIP Extension Header Field for Registering Non-Adjacent RFC 3327, SIP Extension Header Field for Registering Non-Adjacent
Contacts (S): RFC 3327 [16] defines the Path header field. This Contacts (S): [RFC3327] defines the Path header field. This field
field is inserted by proxies between a client and their registrar. is inserted by proxies between a client and their registrar. It
It allows inbound requests towards that client to traverse these allows inbound requests towards that client to traverse these
proxies prior to being delivered to the user agent. It is proxies prior to being delivered to the user agent. It is
essential in any SIP deployment that has edge proxies, which are essential in any SIP deployment that has edge proxies, which are
proxies between the client and the home proxy or SIP registrar. proxies between the client and the home proxy or SIP registrar.
RFC 3581, An Extension to SIP for Symmetric Response Routing (S): RFC 3581, An Extension to SIP for Symmetric Response Routing (S):
RFC 3581 [17] defines the rport parameter of the Via header. It [RFC3581] defines the rport parameter of the Via header. It
is an essential piece of getting SIP through NAT. NAT traversal allows SIP responses to traverse NAT. It is one of several
for SIP is considered a core part of the specifications. specifications that are utilized for NAT traversal (see
Section 6).
RFC 3840, Indicating User Agent Capabilities in SIP (S): RFC 3840 RFC 3840, Indicating User Agent Capabilities in SIP (S): [RFC3840]
[33] defines a mechanism for carrying capability information about defines a mechanism for carrying capability information about a
a user agent in REGISTER requests and in dialog-forming requests user agent in REGISTER requests and in dialog-forming requests
like INVITE. It has found use with conferencing (the isfocus like INVITE. It has found use with conferencing (the isfocus
parameter declares that a user agent is a conference server) and parameter declares that a user agent is a conference server) and
with applications like push-to-talk. with applications like push-to-talk.
RFC 4320, Actions Addressing Issues Identified with the Non-INVITE RFC 4320, Actions Addressing Issues Identified with the Non-INVITE
Transaction in SIP (S): RFC 4320 [18] formally updates RFC 3261, and Transaction in SIP (S): [RFC4320] formally updates RFC 3261, and
modifies some of the behaviors associated with non-INVITE modifies some of the behaviors associated with non-INVITE
transactions. These address some problems found in timeout and transactions. This addresses some problems found in timeout and
failure cases. failure cases.
RFC 4474, Enhancements for Authenticated Identity Management in SIP RFC 4474, Enhancements for Authenticated Identity Management in SIP
(S): RFC 4474 [19] defines a mechanism for providing a (S): [RFC4474] defines a mechanism for providing a cryptographically
cryptographically verifiable identity of the calling party in a verifiable identity of the calling party in a SIP request. Known
SIP request. Known as "SIP Identity", this mechanism provides an as "SIP Identity", this mechanism provides an alternative to RFC
alternative to RFC 3325. It has seen little deployment so far, 3325. It has seen little deployment so far, but its importance as
but its importance as a key construct for anti-spam techniques a key construct for anti-spam techniques and new security
makes it a core part of the SIP specifications. mechanisms makes it a core part of the SIP specifications.
RFC XXXX, Obtaining and Using Globally Routable User Agent draft-ietf-sip-gruu, Obtaining and Using Globally Routable User Agent
Identifiers (GRUU) in SIP (S): RFC XXXX [20] defines a mechanism for Identifiers (GRUU) in SIP (S): [I-D.ietf-sip-gruu] defines a
directing requests towards a specific UA instance. GRUU is mechanism for directing requests towards a specific UA instance.
essential for features like transfer and provides another piece of GRUU is essential for features like transfer and provides another
the SIP NAT traversal story. piece of the SIP NAT traversal story.
RFC XXXX, Managing Client Initiated Connections through SIP (S): RFC draft-ietf-sip-outbound, Managing Client Initiated Connections
XXXX [21], also known as SIP outbound, defines important changes through SIP (S): [I-D.ietf-sip-outbound], also known as SIP
to the SIP registration mechanism which enable delivery of SIP outbound, defines important changes to the SIP registration
messages towards a UA when it is behind a NAT. This specification mechanism which enable delivery of SIP messages towards a UA when
is the cornerstone of the SIP NAT traversal strategy. it is behind a NAT. This specification is the cornerstone of the
SIP NAT traversal strategy.
RFC 4566, Session Description Protocol (S): RFC 4566 [78] defines a RFC 4566, Session Description Protocol (S): [RFC4566] defines a
format for representing multimedia sessions. SDP objects are format for representing multimedia sessions. SDP objects are
carried in the body of SIP messages, and based on the offer/answer carried in the body of SIP messages, and based on the offer/answer
model, are used to negotiate the media characteristics of a model, are used to negotiate the media characteristics of a
session between users. session between users.
RFC XXXX, SDP Capability Negotiation (S): RFC XXXX [105] defines a draft-ietf-mmusic-sdp-capability-negotiation, SDP Capability
set of extensions to SDP that allow for capability negotiation Negotiation (S): [I-D.ietf-mmusic-sdp-capability-negotiation]
within SDP. Capability negotiation can be used to select between defines a set of extensions to SDP that allow for capability
different profiles of RTP (secure vs. unsecure) or to negotiate negotiation within SDP. Capability negotiation can be used to
codecs such that an agent has to select one amongst a set of select between different profiles of RTP (secure vs. unsecure) or
supported codecs. to negotiate codecs such that an agent has to select one amongst a
set of supported codecs.
RFC 3388, Grouping of Media Lines in the Session Description Protocol
(S): RFC 3388 [79] 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.
RFC XXXX, Interactive Connectivity Establishment (ICE) (S): RFC XXXX draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE)
[5] defines a technique for NAT traversal of media sessions for (S): [I-D.ietf-mmusic-ice] defines a technique for NAT traversal of
protocols that make use of the offer/answer model. This media sessions for protocols that make use of the offer/answer
specification is the IETF recommended mechanism for NAT traversal model. This specification is the IETF recommended mechanism for
for SIP media streams, and is meant to be used even by endpoints NAT traversal for SIP media streams, and is meant to be used even
which are themselves never behind a NAT. A SIP option tag and by endpoints which are themselves never behind a NAT. A SIP
media feature tag RFC XXXX [108] have been defined for use with option tag and media feature tag [I-D.ietf-sip-ice-option-tag]
ICE. (also a core specification) have been defined for use with ICE.
RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session
Description Protocol (SDP) (S): RFC 3605 [80] defines a way to Description Protocol (SDP) (S): [RFC3605] defines a way to
explicitly signal, within an SDP message, the IP address and port explicitly signal, within an SDP message, the IP address and port
for RTCP, rather than using the port+1 rule in the Real Time for RTCP, rather than using the port+1 rule in the Real Time
Transport Protocol (RTP) [3]. It is needed for devices behind NAT Transport Protocol (RTP) [RFC3550]. It is needed for devices
and used by ICE. behind NAT and used by ICE.
RFC 4916, Connected Identity in the Session Initiation Protocol (SIP) RFC 4916, Connected Identity in the Session Initiation Protocol (SIP)
(S): RFC 4916 [81] defines an extension to SIP that allows a UAC to (S): [RFC4916] formally updates RFC 3261. It defines an extension
determine the identity of the UAS. Due to forwarding and 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 retargeting services, this may not be the same as the user that
the UAC was originally trying to reach. The mechanism works in the caller was originally trying to reach. The mechanism works in
tandem with the SIP identity specification [19] to provide tandem with the SIP identity specification [RFC4474] to provide
signatures over the connected party identity. 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.
RFC XXXX, The use of the SIPS URI Scheme in the Session Initiation RFC 3311, The SIP UPDATE Method (S): [RFC3311] defines the UPDATE
Protocol (SIP) (S): RFC XXXX [112] revises the processing of the method for SIP. This method is meant as a means for updating
SIPS URI, originally defined in RFC 3261, to fix many errors and session information prior to the completion of the initial INVITE
problems that have been encountered with that mechanism. transaction. It can also be used to update other information,
such as the identity of the participant [RFC4916], without
involving an updated offer/answer exchange. It was developed
initially to support [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.
draft-ietf-sip-sips, The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP) (S): [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.
Essential Corrections to SIP: A collection of fixes to SIP that Essential Corrections to SIP: A collection of fixes to SIP that
address important bugs and vulnerabilities. These include a fix address important bugs and vulnerabilities. These include a fix
requiring loop detection in any proxy that forks [82] and a requiring loop detection in any proxy that forks
clarification on how record-routing works [110]. [I-D.ietf-sip-fork-loop-fix] and a clarification on how record-
routing works [I-D.ietf-sip-record-route-fix].
4. Public Switched Telephone Network (PSTN) Interworking 4. Public Switched Telephone Network (PSTN) Interworking
Numerous extensions and usages of SIP related to interoperability and Numerous extensions and usages of SIP related to interoperability and
communications with or through the PSTN. communications with or through the PSTN.
RFC 2848, The PINT Service Protocol (S): RFC 2848 [22] is one of the RFC 2848, The PINT Service Protocol (S): [RFC2848] is one of the
earliest extensions to SIP. It defines procedures for using SIP earliest extensions to SIP. It defines procedures for using SIP
to invoke services that actually execute on the PSTN. Its main to invoke services that actually execute on the PSTN. Its main
application is for third party call control, allowing an IP host application is for third party call control, allowing an IP host
to set up a call between two PSTN endpoints. PINT has a to set up a call between two PSTN endpoints. PINT has a
relatively narrow focus and has not seen widespread deployment. relatively narrow focus and has not seen widespread deployment.
RFC 3910, The SPIRITS Protocol (S): Continuing the trend of naming RFC 3910, The SPIRITS Protocol (S): Continuing the trend of naming
PSTN related extensions with alcohol references, SPIRITS [23] PSTN related extensions with alcohol references, SPIRITS [RFC3910]
defines the inverse of PINT. It allows a switch in the PSTN to 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 ask an IP element about how to proceed with call waiting. It was
developed primarily to support Internet Call Waiting (ICW). developed primarily to support Internet Call Waiting (ICW).
Perhaps the next specification will be called the Pan Galactic Perhaps the next specification will be called the Pan Galactic
Gargle Blaster [42]. Gargle Blaster [HGTTG].
RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I): RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I):
SIP-T [24] defines a mechanism for using SIP between pairs of PSTN SIP-T [RFC3372] defines a mechanism for using SIP between pairs of
gateways. Its essential idea is to tunnel ISUP signaling between PSTN gateways. Its essential idea is to tunnel ISUP signaling
the gateways in the body of SIP messages. SIP-T motivated the between the gateways in the body of SIP messages. SIP-T motivated
development of INFO [30]. SIP-T has seen widespread the development of INFO [RFC2976]. SIP-T has seen widespread
implementation. implementation for the limited deployment model that it addresses.
As ISUP endpoints disappear from the network, the need for this
mechanism will decrease.
RFC 3398, ISUP to SIP Mapping (S): RFC 3398 [25] defines how to do RFC 3398, ISUP to SIP Mapping (S): [RFC3398] defines how to do
protocol mapping from the SS7 ISDN User Part (ISUP) signaling to 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. It is widely used in SS7 to SIP gateways and is part of the
SIP-T framework. SIP-T framework.
RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S): RFC 3578 RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S): [RFC3578]
[26] defines a mechanism to map overlap dialing into SIP. This defines a mechanism to map overlap dialing into SIP. This
specification is widely regarded as the ugliest SIP specification, specification is widely regarded as the ugliest SIP specification,
as the introduction to the specification itself advises that it as the introduction to the specification itself advises that it
has many problems. Overlap signaling (the practice of sending has many problems. Overlap signaling (the practice of sending
digits into the network as dialed instead of waiting for complete digits into the network as dialed instead of waiting for complete
collection of the called party number) is largely incompatible collection of the called party number) is largely incompatible
with SIP at some fairly fundamental levels. That said, RFC 3578 with SIP at some fairly fundamental levels. That said, RFC 3578
is mostly harmless and has seen some usage. is mostly harmless and has seen some usage.
RFC 3960, Early Media and Ringtone Generation in SIP (I): RFC 3960 RFC 3960, Early Media and Ringtone Generation in SIP (I): [RFC3960]
[27] defines some guidelines for handling early media - the defines some guidelines for handling early media - the practice of
practice of sending media from the called party towards the caller sending media from the called party or an application server
- prior to acceptance of the call. Early media is generated only towards the caller - prior to acceptance of the call. Early media
from the PSTN. is often generated from the PSTN. Early media is a complex topic,
and this specification does not fully address the problems
associated with it.
RFC 3959, Early Session Disposition Type for the Session Initiation RFC 3959, Early Session Disposition Type for the Session Initiation
Protocol (SIP) (S): RFC 3959 [83] defines a new session disposition Protocol (SIP) (S): [RFC3959] defines a new session disposition type
type for use with early media. It indicates that the SDP in the for use with early media. It indicates that the SDP in the body
body is for a special early media session. is for a special early media session. This has seen little usage.
RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204 RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): [RFC3204]
[84] defines MIME objects for representing SS7 signaling messages. defines MIME objects for representing SS7 and QSIG signaling
These are carried in the body of SIP messages when SIP-T is used. 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.
5. General Purpose Infrastructure Extensions 5. General Purpose Infrastructure Extensions
These extensions are general purpose enhancements to SIP, SDP and These extensions are general purpose enhancements to SIP, SDP and
MIME that can serve a wide variety of uses. However, they are not as MIME that can serve a wide variety of uses. However, they are not as
widely used or as essential as the core specifications. widely used or as essential as the core specifications.
RFC 3262, Reliability of Provisional Responses in SIP (S): SIP RFC 3262, Reliability of Provisional Responses in SIP (S): SIP
defines two types of responses to a request - final and defines two types of responses to a request - final and
provisional. Provisional responses are numbered from 100 to 199. provisional. Provisional responses are numbered from 100 to 199.
In SIP, these responses are not sent reliably. This choice was In SIP, these responses are not sent reliably. This choice was
made in RFC 2543 since the messages were meant to just be truly made in RFC 2543 since the messages were meant to just be truly
informational, and rendered to the user. However, subsequent work informational, and rendered to the user. However, subsequent work
on PSTN interworking demonstrated a need to map provisional on PSTN interworking demonstrated a need to map provisional
responses to PSTN messages that needed to be sent reliably. RFC responses to PSTN messages that needed to be sent reliably.
3262 [28] was developed to allow reliability of provisional [RFC3262] was developed to allow reliability of provisional
responses. The specification defines the PRACK method, used for responses. The specification defines the PRACK method, used for
indicating that a provisional response was received. Though it indicating that a provisional response was received. Though it
provides a generic capability for SIP, RFC 3262 implementations provides a generic capability for SIP, RFC 3262 implementations
have been most common in PSTN interworking devices. However, have been most common in PSTN interworking devices. However,
PRACK brings a great deal of complication for relatively small PRACK brings a great deal of complication for relatively small
benefit. As such, it has seen only mild levels of deployment. benefit. As such, it has seen only moderate levels of deployment.
RFC 3323, A Privacy Mechanism for the Session Initiation Protocol RFC 3323, A Privacy Mechanism for the Session Initiation Protocol
(SIP) (S): RFC 3323 [14] defines the Privacy header field, used by (SIP) (S): [RFC3323] defines the Privacy header field, used by
clients to request anonymity for their requests. Though it clients to request anonymity for their requests. Though it
defines numerous privacy services, the only one broadly used is defines several privacy services, the only one broadly used is the
the one that supports privacy of the P-Asserted-ID header field one that supports privacy of the P-Asserted-Identity header field
[15]. [RFC3325].
RFC 3311, The SIP UPDATE Method (S): RFC 3311 [29] 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 [59].
RFC 2976, The INFO Method (S): RFC 2976 [30] was defined as an RFC 2976, The INFO Method (S): [RFC2976] was defined as an extension
extension to RFC 2543. It defines a method, INFO, used to to RFC 2543. It defines a method, INFO, used to transport mid-
transport mid-dialog information that has no impact on SIP itself. dialog information that has no impact on SIP itself. Its driving
Its driving application was the transport of PSTN related application was the transport of PSTN related information when
information when using SIP between a pair of gateways. Though using SIP between a pair of gateways. Though originally conceived
originally conceived for broader use, it only found standardized for broader use, it only found standardized usage with SIP-T
usage with SIP-T [24]. It has been used to support numerous [RFC3372]. It has been used to support numerous proprietary and
proprietary and non-interoperable extensions due to its poorly non-interoperable extensions due to its poorly defined scope.
defined scope.
RFC 3326, The Reason header field for SIP (S): RFC 3326 [31] defines RFC 3326, The Reason header field for SIP (S): [RFC3326] defines the
the Reason header field. It is used in requests, such as BYE, to Reason header field. It is used in requests, such as BYE, to
indicate the reason that the request is being sent. indicate the reason that the request is being sent.
RFC 3420, Internet Media Type message/sipfrag (S): RFC 3420 [85] RFC 3388, Grouping of Media Lines in the Session Description Protocol
defines a MIME object that contains a SIP message fragment. Only (S): RFC 3388 [RFC3388] defines a framework for grouping together
certain header fields and parts of the SIP message are present. media streams in an SDP message. Such a grouping allows
For example, it is used to report back on the responses received relationships between these streams, such as which stream is the
to a request sent as a consequence of a REFER. audio for a particular video feed, to be expressed.
RFC 3420, Internet Media Type message/sipfrag (S): [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.
RFC 3608, SIP Extension Header Field for Service Route Discovery RFC 3608, SIP Extension Header Field for Service Route Discovery
During Registration (S): RFC 3608 [32] allows a client to determine, During Registration (S): [RFC3608] allows a client to determine,
from a REGISTER response, a path of proxies to use in requests it 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 sends outside of a dialog. It can also be used by proxies to
the Path header field, but has seen less usage since default verify the Route header in client initiated requests. In many
outbound proxies have been sufficient in many deployments. 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 3841, Caller Preferences for SIP (S): RFC 3841 [34] defines a RFC 3841, Caller Preferences for SIP (S): [RFC3841] defines a set of
set of headers that a client can include in a request to control headers that a client can include in a request to control the way
the way in which the request is routed downstream. It allows a in which the request is routed downstream. It allows a client to
client to direct a request towards a UA with specific direct a request towards a UA with specific capabilities, which a
capabilities. UA indicates using [RFC3840].
RFC 4028, Session Timers in SIP (S): RFC 4028 [35] defines a RFC 4028, Session Timers in SIP (S): [RFC4028] defines a keepalive
keepalive mechanism for SIP signaling. It is primarily meant to mechanism for SIP signaling. It is primarily meant to provide a
provide a way to cleanup old state in proxies that are holding way to cleanup old state in proxies that are holding call state
call state for calls from failed endpoints which were never for calls from failed endpoints which were never terminated
terminated normally. Despite its name, the session timer is not a normally. Despite its name, the session timer is not a mechanism
mechanism for detecting a network failure mid-call. Session for detecting a network failure mid-call. Session timers
timers introduces a fair bit of complexity for relatively little introduces a fair bit of complexity for relatively little gain,
gain, and has thus seen little deployment. and have seen moderate deployment.
RFC 4168, SCTP as a Transport for SIP (S): RFC 4168 [36] defines how RFC 4168, SCTP as a Transport for SIP (S): [RFC4168] defines how to
to carry SIP messages over the Stream Control Transmission carry SIP messages over the Stream Control Transmission Protocol
Protocol (SCTP). SCTP has seen very limited usage for SIP (SCTP) [RFC4960]. SCTP has seen very limited usage for SIP
transport. transport.
RFC 4244, An Extension to SIP for Request History Information (S): RFC 4244, An Extension to SIP for Request History Information (S):
RFC 4244 [37] defines the History-Info header field, which [RFC4244] defines the History-Info header field, which indicates
indicates information on how a call came to be routed to a information on how and why a call came to be routed to a
particular destination. Its primary application was in support of particular destination.
voicemail services.
RFC 4145, TCP-Based Media Transport in the Session Description RFC 4145, TCP-Based Media Transport in the Session Description
Protocol (SDP) (S): RFC 4145 [86] defines an extension to SDP for Protocol (SDP) (S): [RFC4145] defines an extension to SDP for
setting up TCP-based sessions between user agents. It defines who setting up TCP-based sessions between user agents. It defines who
sets up the connection and how its lifecycle is managed. It has sets up the connection and how its lifecycle is managed. It has
seen relatively little usage due to the small number of media seen relatively little usage due to the small number of media
types to date which use TCP. types to date which use TCP.
RFC 4091, The Alternative Network Address Types (ANAT) Semantics for RFC 4091, The Alternative Network Address Types (ANAT) Semantics for
the Session Description Protocol (SDP) Grouping Framework (S): RFC the Session Description Protocol (SDP) Grouping Framework (S):
4091 [87] defines a mechanism for including both IPv4 and IPv6 [RFC4091] defines a mechanism for including both IPv4 and IPv6
addresses for a media session as alternates. addresses for a media session as alternates. This mechanism has
been deprecated in favor of ICE [I-D.ietf-mmusic-ice].
RFC XXXX, SDP Media Capabilities Negotiation (S): RFC XXXX [106] draft-ietf-mmusic-sdp-media-capabilities, SDP Media Capabilities
defines an extension to the SDP capability negotiation framework Negotiation (S): [I-D.ietf-mmusic-sdp-media-capabilities] defines an
[105] for negotiating codecs, codec parameters, and media streams. extension to the SDP capability negotiation framework
[I-D.ietf-mmusic-sdp-capability-negotiation] for negotiating
codecs, codec parameters, and media streams.
6. NAT Traversal 6. NAT Traversal
These SIP extensions are primarily aimed at addressing NAT traversal These SIP extensions are primarily aimed at addressing NAT traversal
for SIP. for SIP.
RFC XXXX, Interactive Connectivity Establishment (ICE) (S): RFC XXXX draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE)
[5] defines a technique for NAT traversal of media sessions for (S): [I-D.ietf-mmusic-ice] defines a technique for NAT traversal of
protocols that make use of the offer/answer model. This media sessions for protocols that make use of the offer/answer
specification is the IETF recommended mechanism for NAT traversal model. This specification is the IETF recommended mechanism for
for SIP media streams, and is meant to be used even by endpoints NAT traversal for SIP media streams, and is meant to be used even
which are themselves never behind a NAT. A SIP option tag and by endpoints which are themselves never behind a NAT. A SIP
media feature tag RFC XXXX [108] have been defined for use with option tag and media feature tag [I-D.ietf-sip-ice-option-tag]
ICE. have been defined for use with ICE.
RFC XXXX, TCP Candidates with Interactive Connectivity Establishment draft-ietf-mmusic-ice-tcp, TCP Candidates with Interactive
(ICE) (S): RFC XXXX [88] specifies the usage of ICE for TCP streams. Connectivity Establishment (ICE) (S): [I-D.ietf-mmusic-ice-tcp]
This allows for selection of RTP-based voice ontop of TCP only specifies the usage of ICE for TCP streams. This allows for
when NAT or firewalls would prevent UDP-based voice from working. selection of RTP-based voice ontop of TCP only when NAT or
firewalls would prevent UDP-based voice from working.
RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session
Description Protocol (SDP) (S): RFC 3605 [80] defines a way to Description Protocol (SDP) (S): [RFC3605] defines a way to
explicitly signal, within an SDP message, the IP address and port explicitly signal, within an SDP message, the IP address and port
for RTCP, rather than using the port+1 rule in the Real Time for RTCP, rather than using the port+1 rule in the Real Time
Transport Protocol (RTP) [3]. It is needed for devices behind NAT Transport Protocol (RTP) [RFC3550]. It is needed for devices
and used by ICE. behind NAT and used by ICE.
RFC XXXX, Managing Client Initiated Connections through SIP (S): RFC draft-ietf-sip-outbound, Managing Client Initiated Connections
XXXX [21], also known as SIP outbound, defines important changes through SIP (S): [I-D.ietf-sip-outbound], also known as SIP
to the SIP registration mechanism which enable delivery of SIP outbound, defines important changes to the SIP registration
messages towards a UA when it is behind a NAT. This specification mechanism which enable delivery of SIP messages towards a UA when
is the cornerstone of the SIP NAT traversal strategy. it is behind a NAT.
RFC 3581, An Extension to SIP for Symmetric Response Routing (S): RFC 3581, An Extension to SIP for Symmetric Response Routing (S):
RFC 3581 [17] defines the rport parameter of the Via header. It [RFC3581] defines the rport parameter of the Via header. It
is an essential piece of getting SIP through NAT. NAT traversal allows SIP responses to traverse NAT.
for SIP is considered a core part of the specifications.
RFC XXXX, Obtaining and Using Globally Routable User Agent
Identifiers (GRUU) in SIP (S): RFC XXXX [20] 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.
7. 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 4488, Suppression of the SIP REFER Implicit Subscription (S):
RFC 4488 [38] 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 4538, Request Authorization through Dialog Identification in SIP
(S): RFC 4538 [39] 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 [77].
RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S):
RFC 4508 [40] 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 [41] 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 [43]
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 [44]
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.
RFC 4483, A Mechanism for Content Indirection in Session Initiation
Protocol (SIP) Messages (S): RFC 4483 [89] 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.
RFC 3890, A Transport Independent Bandwidth Modifier for the Session
Description Protocol (SDP) (S): RFC 3890 [90] specifies an SDP
extension that allows for the description of the bandwidth for a
media session that is independent of the underlying transport
mechanism. It has seen relatively little usage.
RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a
mechanism in SDP to signal floor control streams that use BFCP.
It is used for Push-To-Talk and conference floor control.
RFC XXXX, Connectivity Preconditions for Session Description Protocol
Media Streams (S): RFC XXXX [93] defines a usage of the precondition
framework [59]. The connectivity precondition makes sure that the
session doesn't get established until actual packet connectivity
is checked.
RFC 4796, The SDP (Session Description Protocol) Content Attribute
(S): RFC 4796 [94] 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.
8. Conferencing
Numerous SIP and SDP extensions are aimed at conferencing as their
primary application.
RFC 4574, The SDP (Session Description Protocol) Label Attribute
(S): RFC 4574 [95] 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.
RFC 3911, The SIP Join Header Field (S): RFC 3911 [49] 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 4575, A SIP Event Package for Conference State (S): RFC 4575
[56] defines a mechanism for learning about changes in conference
state, including group membership.
RFC XXXX, Conference Establishment Using Request-Contained Lists in draft-ietf-sip-gruu, Obtaining and Using Globally Routable User Agent
SIP (S): RFC XXXX [70] is similar to [68]. However, instead of Identifiers (GRUU) in SIP (S): [I-D.ietf-sip-gruu] defines a
subscribing to the resource, an INVITE request is sent to the mechanism for directing requests towards a specific UA instance.
resource, and it will act as a conference focus and generate an GRUU is essential for features like transfer and provides another
invitation to each recipient in the list. piece of the SIP NAT traversal story.
9. Call Control Primitives 7. Call Control Primitives
Numerous SIP extensions provide a toolkit of dialog and call Numerous SIP extensions provide a toolkit of dialog and call
management techniques. These techniques have been combined together management techniques. These techniques have been combined together
to build many SIP-based services. to build many SIP-based services.
RFC 3515, The REFER Method (S): REFER [45] defines a mechanism for RFC 3515, The REFER Method (S): REFER [RFC3515] defines a mechanism
asking a user agent to send a SIP request. Its a form of SIP 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 remote control, and is the primary tool used for call transfer in
SIP. 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.
RFC 3725, Best Current Practices for Third Party Call Control (3pcc) RFC 3725, Best Current Practices for Third Party Call Control (3pcc)
(B): RFC 3725 [46] defines a number of different call flows that (B): [RFC3725] defines a number of different call flows that allow
allow one SIP entity, called the controller, to create SIP one SIP entity, called the controller, to create SIP sessions
sessions amongst other SIP user agents. amongst other SIP user agents.
RFC 3911, The SIP Join Header Field (S): RFC 3911 [49] defines the RFC 3911, The SIP Join Header Field (S): [RFC3911] defines the Join
Join header field. When sent in an INVITE, it causes the header field. When sent in an INVITE, it causes the recipient to
recipient to join the resulting dialog into a conference with join the resulting dialog into a conference with another dialog in
another dialog in progress. progress.
RFC 3891, The SIP Replaces Header (S): RFC 3891 [47] defines a RFC 3891, The SIP Replaces Header (S): [RFC3891] defines a mechanism
mechanism that allows a new dialog to replace an existing dialog. that allows a new dialog to replace an existing dialog. It is
It is useful for certain advanced transfer services. useful for certain advanced transfer services.
RFC 3892, The SIP Referred-By Mechanism (S): RFC 3892 [48] defines RFC 3892, The SIP Referred-By Mechanism (S): [RFC3892] defines the
the Referred-By header field. It is used in requests triggered by Referred-By header field. It is used in requests triggered by
REFER, and provides the identity of the referring party to the REFER, and provides the identity of the referring party to the
referred-to party. referred-to party.
RFC 4117, Transcoding Services Invocation in SIP Using Third Party RFC 4117, Transcoding Services Invocation in SIP Using Third Party
Call Control (I): RFC 4117 [50] defines how to use 3pcc for the Call Control (I): [RFC4117] defines how to use 3pcc for the purposes
purposes of invoking transcoding services for a call. of invoking transcoding services for a call.
10. Event Framework and Packages 8. Event Framework
RFC 3265 defines a basic framework for event notification in SIP. It RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the
introduces the notion of an event package, which is a collection of SUBSCRIBE and NOTIFY methods. These two methods provide a general
related state and event information. Much of the state and events in event notification framework for SIP. To actually use the
SIP systems have event packages, allowing other entities to learn framework, extensions need to be defined for specific event
about changes in that state. 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 3903, SIP Extension for Event State Publication (S): RFC 3903 RFC 3903, SIP Extension for Event State Publication (S): [RFC3903]
[51] defines the PUBLISH method. It is not an event package, but defines the PUBLISH method. It is not an event package, but is
is used by all event packages as a mechanism for pushing an event used by all event packages as a mechanism for pushing an event
into the system. into the system.
RFC 4662, A Session Initiation Protocol (SIP) Event Notification RFC 4662, A Session Initiation Protocol (SIP) Event Notification
Extension for Resource Lists (S): RFC 4662 [67] defines an extension Extension for Resource Lists (S): [RFC4662] defines an extension to
to RFC 3265 that allows a client to subscribe to a list of RFC 3265 that allows a client to subscribe to a list of resources
resources using a single subscription. The server, called a using a single subscription. The server, called a Resource List
Resource List Server (RLS) will "expand" the subscription and Server (RLS) will "expand" the subscription and subscribe to each
subscribe to each individual member of the list. It has found individual member of the list. It has found applicability
applicability primarily in the area of presence, but can be used primarily in the area of presence, but can be used with any event
with any event package. package.
RFC XXXX, An Extension to Session Initiation Protocol (SIP) Events draft-ietf-sip-subnot-etags, An Extension to Session Initiation
for Conditional Event Notification (S): RFC XXXX [111] defines an Protocol (SIP) Events for Conditional Event Notification (S):
extension to RFC 3265 to optimize the performance of [I-D.ietf-sip-subnot-etags] defines an extension to RFC 3265 to
notifications. When a client subscribes, it can indicate what optimize the performance of notifications. When a client
version of a document it has, so that the server can skip sending subscribes, it can indicate what version of a document it has, so
a notification if the client is up to date. It is applicable to that the server can skip sending a notification if the client is
any event package. up to date. It is applicable to any event package.
RFC 3680, A SIP Event Package for Registrations (S): RFC 3680 [52] 9. Event Packages
These are event packages defined to utilize the SIP events framework.
Many of these are also listed elsewhere in their respective areas.
RFC 3680, A SIP Event Package for Registrations (S): [RFC3680]
defines an event package for finding out about changes in defines an event package for finding out about changes in
registration state. registration state.
RFC 3842, A Message Summary and Message Waiting Indication Event RFC 3842, A Message Summary and Message Waiting Indication Event
Package for SIP (S): RFC 3842 [65] defines a way for a user agent to Package for SIP (S): [RFC3482] defines a way for a user agent to
find out about voicemails and other messages that are waiting for find out about voicemails and other messages that are waiting for
it. Its primary purpose is to enable the voicemail waiting lamp it. Its primary purpose is to enable the voicemail waiting lamp
on most business telephones. on most business telephones.
RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [53] RFC 3856, A Presence Event Package for SIP (S): [RFC3856] defines an
defines an event package for indicating user presence through SIP. event package for indicating user presence through SIP.
RFC 3857, A Watcher Information Event Template Package for SIP (S): RFC 3857, A Watcher Information Event Template Package for SIP (S):
RFC 3857 [54], also known as winfo, provides a mechanism for a [RFC3857], also known as winfo, provides a mechanism for a user
user agent to find out what subscriptions are in place for a agent to find out what subscriptions are in place for a particular
particular event package. Its primary usage is with presence, but event package. Its primary usage is with presence, but it can be
it can be used with any event package. used with any event package.
RFC 4235, An INVITE Initiated Dialog Event Package for SIP (S): RFC RFC 4235, An INVITE Initiated Dialog Event Package for SIP (S):
4235 [55] defines an event package for learning the state of the [RFC4235] defines an event package for learning the state of the
dialogs in progress at a user agent, and is one of several RFCs dialogs in progress at a user agent, and is one of several RFCs
starting with the important number 42 [42]. starting with the important number 42 [HGTTG].
RFC 4575, A SIP Event Package for Conference State (S): RFC 4575 RFC 4575, A SIP Event Package for Conference State (S): [RFC4575]
[56] defines a mechanism for learning about changes in conference defines a mechanism for learning about changes in conference
state, including group membership. state, including conference membership.
RFC 4730, A SIP Event Package for Keypress Stimulus (KPML) (S): RFC RFC 4730, A SIP Event Package for Keypress Stimulus (KPML) (S):
4730 [57] defines a way for an application in the network to [RFC4730] defines a way for an application in the network to
subscribe to the set of keypresses made on the keypad of a subscribe to the set of keypresses made on the keypad of a
traditional telephone. traditional telephone. It, along with RFC 2833 [RFC2833], are the
two mechanisms defined for handling DTMF. RFC 4730 is a
signaling-path solution, and RFC 2833 is a media-path solution.
RFC XXXX, SIP Event Package for Voice Quality Reporting (S): RFC draft-ietf-sipping-rtcp-summary, SIP Event Package for Voice Quality
XXXX [58] defines a SIP event package that enables the collection Reporting (S): [I-D.ietf-sipping-rtcp-summary] defines a SIP event
and reporting of metrics that measure the quality for Voice over package that enables the collection and reporting of metrics that
Internet Protocol (VoIP) sessions. measure the quality for Voice over Internet Protocol (VoIP)
sessions.
RFC XXXX, A Session Initiation Protocol (SIP) Event Package for draft-ietf-sipping-policy-package, A Session Initiation Protocol
Session-Specific Session Policies (S): RFC XXXX [96] defines a SIP (SIP) Event Package for Session-Specific Session Policies (S):
event package that allows a proxy to notify a user agent about its [I-D.ietf-sipping-policy-package] defines a SIP event package that
desire for the UA to use certain codecs or generally obey certain allows a policy server to notify a user agent about its desire for
media session policies. the UA to use certain codecs or generally obey certain media
session policies.
RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions draft-ietf-sipping-pending-additions, The Session Initiation Protocol
Event Package (S): RFC XXXX [103] defines a SIP event package that (SIP) Pending Additions Event Package (S):
allows a UA to learn whether consent has been given for the [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 addition of an address to a SIP "mailing list". It is used in
conjunction with the SIP framework for consent [101]. conjunction with the SIP framework for consent
[I-D.ietf-sip-consent-framework].
11. Quality of Service 10. Quality of Service
Several specifications concern themselves with the interactions of Several specifications concern themselves with the interactions of
SIP with network Quality of Service (QoS) mechanisms. SIP with network Quality of Service (QoS) mechanisms.
RFC 3312, Integration of Resource Management and SIP (S): RFC 3312 RFC 3312, Integration of Resource Management and SIP (S): [RFC3312],
[59], updated by RFC 4032 [60] defines a way to make sure that the updated by [RFC4032] defines a way to make sure that the phone of
phone of the called party doesn't ring until a QoS reservation has the called party doesn't ring until a QoS reservation has been
been installed in the network. It does so by defining a general installed in the network. It does so by defining a general
preconditions framework, which defines conditions that must be preconditions framework, which defines conditions that must be
true in order for a SIP session to proceed true in order for a SIP session to proceed.
RFC 3313, Private SIP Extensions for Media Authorization (I): RFC RFC 3313, Private SIP Extensions for Media Authorization (I):
3313 [61] defines a P-header that provides a mechanism for passing [RFC3313] defines a P-header that provides a mechanism for passing
an authorization token between SIP and a network QoS reservation an authorization token between SIP and a network QoS reservation
protocol like RSVP. Its purpose is to make sure network QoS is 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 only granted if a client has made a SIP call through the same
providers network. This specification is sometimes referred to as providers network. This specification is sometimes referred to as
the SIP walled garden specification by the truly paranoid androids the SIP walled garden specification by the truly paranoid androids
in the SIP community. This is because it requires coupling of in the SIP community. This is because it requires coupling of
signaling and the underlying IP network. signaling and the underlying IP network.
RFC 3524, Mapping of Media Streams to Resource Reservation Flows RFC 3524, Mapping of Media Streams to Resource Reservation Flows
(S): RFC 3524 [97] defines a usage of the SDP grouping framework for (S): [RFC3524] defines a usage of the SDP grouping framework for
indicating that a set of media streams should be handled by a indicating that a set of media streams should be handled by a
single resource reservation. single resource reservation.
12. Operations and Management 11. Operations and Management
Several specifications have been defined to support operations and Several specifications have been defined to support operations and
management of SIP systems. These include mechanisms for management of SIP systems. These include mechanisms for
configuration and network diagnostics. configuration and network diagnostics.
RFC XXXX, Diagnostic Responses for SIP Hop Limit Errors (S): RFC draft-ietf-sipping-config-framework, A Framework for SIP User Agent
XXXX [98] defines a mechanism for including diagnostic information Profile Delivery (S): [I-D.ietf-sipping-config-framework] defines a
in a 483 response. This response is sent when the hop-count of a mechanism that allows a SIP user agent to bootstrap its
SIP request was exceeded. configuration from the network, and receive updates to its
configuration should it change. This is considered an essential
RFC XXXX, A Framework for SIP User Agent Profile Delivery (S): RFC piece of deploying a usable SIP network.
XXXX [62] 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, Extensions to the Session Initiation Protocol (SIP) User draft-ietf-sipping-rtcp-summary, SIP Event Package for Voice Quality
Agent Profile Delivery Change Notification Event Package for the Reporting (S): [I-D.ietf-sipping-rtcp-summary] defines a SIP event
Extensible Markup Language Language Configuration Access Protocol package that enables the collection and reporting of metrics that
(XCAP) (S): RFC XXXX [63] defines an extension to [62] for learning measure the quality for Voice over Internet Protocol (VoIP)
about changes in documents managed by XCAP. sessions.
RFC XXXX, SIP Event Package for Voice Quality Reporting (S): RFC 12. SIP Compression
XXXX [58] defines a SIP event package that enables the collection
and reporting of metrics that measure the quality for Voice over
Internet Protocol (VoIP) sessions.
13. SIP Compression Sigcomp [RFC3320] [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.
Sigcomp [6] was defined to allow compression of SIP messages over low RFC 3486, Compressing SIP (S): [RFC3486] defines a SIP URI parameter
bandwidth links. Sigcomp is not formally part of SIP. However, that can be used to indicate that a SIP server supports Sigcomp.
usage of Sigcomp with SIP has required extensions to SIP.
RFC 3486, Compressing SIP (S): RFC 3486 [64] defines a SIP URI draft-ietf-rohc-sigcomp-sip, Applying Signaling Compression (SigComp)
parameter that can be used to indicate that a SIP server supports to the Session Initiation Protocol (SIP) (S):
Sigcomp. [I-D.ietf-rohc-sigcomp-sip] defines how to apply Sigcomp to SIP.
14. SIP Service URIs 13. SIP Service URIs
Several extensions define well-known services that can be invoked by Several extensions define well-known services that can be invoked by
constructing requests with the specific structures for the Request constructing requests with the specific structures for the Request
URI, resulting in specific behaviors at the UAS. URI, resulting in specific behaviors at the UAS.
RFC 3087, Control of Service Context using Request URI (I): RFC 3087 RFC 3087, Control of Service Context using Request URI (I):
[66] introduced the context of using Request URIs, encoded [RFC3087] introduced the context of using Request URIs, encoded
appropriately, to invoke services. appropriately, to invoke services.
RFC 4662, A SIP Event Notification Extension for Resource Lists (S): RFC 4662, A SIP Event Notification Extension for Resource Lists (S):
RFC 4662 [67] defines a resource called a Resource List Server. A [RFC4662] defines a resource called a Resource List Server. A
client can send a subscribe to this server. The server will client can send a subscribe to this server. The server will
generate a series of subscriptions, and compile the resulting generate a series of subscriptions, and compile the resulting
information and send it back to the subscriber. The set of information and send it back to the subscriber. The set of
resources that the RLS will subscribe to is a property of the resources that the RLS will subscribe to is a property of the
request URI in the SUBSCRIBE request. request URI in the SUBSCRIBE request.
RFC XXXX, Subscriptions To Request-Contained Resource Lists in SIP draft-ietf-sip-uri-list-subscribe, Subscriptions To Request-Contained
(S): RFC XXXX [68] allows a client to subscribe to a resource called Resource Lists in SIP (S): [I-D.ietf-sip-uri-list-subscribe] allows
a Resource List Server. This server will generate a series of a client to subscribe to a resource called a Resource List Server.
subscriptions, and compile the resulting information and send it This server will generate a series of subscriptions, and compile
back to the subscriber. For this specification, the list of the resulting information and send it back to the subscriber. For
things to subscribe to is in the body of the SUBSCRIBE request. 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 draft-ietf-sip-uri-list-message, Multiple-Recipient MESSAGE Requests
[69] is similar to [68]. However, instead of subscribing to the in SIP (S): [I-D.ietf-sip-uri-list-message] is similar to
resource, a MESSAGE request is sent to the resource, and it will [I-D.ietf-sip-uri-list-subscribe]. However, instead of
send a copy to each recipient. 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 draft-ietf-sip-uri-list-conferencing, Conference Establishment Using
SIP (S): RFC XXXX [70] is similar to [68]. However, instead of Request-Contained Lists in SIP (S):
[I-D.ietf-sip-uri-list-conferencing] is similar to
[I-D.ietf-sip-uri-list-subscribe]. However, instead of
subscribing to the resource, an INVITE request is sent to the subscribing to the resource, an INVITE request is sent to the
resource, and it will act as a conference focus and generate an resource, and it will act as a conference focus and generate an
invitation to each recipient in the list. invitation to each recipient in the list.
RFC 4240, Basic Network Media Services with SIP (I): RFC 4240 [99] RFC 4240, Basic Network Media Services with SIP (I): [RFC4240]
defines a way for SIP application servers to invoke announcement defines a way for SIP application servers to invoke announcement
and conferencing services from a media server. This is and conferencing services from a media server. This is
accomplished through a set of defined URI parameters which tell accomplished through a set of defined URI parameters which tell
the media server what to do, such as what file to play and what the media server what to do, such as what file to play and what
language to render it in. language to render it in.
RFC 4458, Session Initiation Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice Response (IVR) (I):
[RFC4458] defines a way to invoke voicemail and IVR services by
using a SIP URI constructed in a particular way.
14. 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 4488, Suppression of the SIP REFER Implicit Subscription (S):
[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.
RFC 4538, Request Authorization through Dialog Identification in SIP
(S): [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
[I-D.ietf-sipping-app-interaction-framework].
RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S):
[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.
draft-ietf-sip-answermode, Requesting Answer Modes for SIP (S):
[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.
draft-ietf-sip-acr-code, Rejecting Anonymous Requests in SIP (S):
[I-D.ietf-sip-acr-code] 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.
draft-ietf-sip-multiple-refer, Referring to Multiple Resources in SIP
(S): [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.
RFC 4483, A Mechanism for Content Indirection in Session Initiation
Protocol (SIP) Messages (S): [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.
RFC 3890, A Transport Independent Bandwidth Modifier for the Session
Description Protocol (SDP) (S): [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.
RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
Control Protocol (BFCP) Streams (S): [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.
draft-ietf-mmusic-connectivity-precon, Connectivity Preconditions for
Session Description Protocol Media Streams (S):
[I-D.ietf-mmusic-connectivity-precon] defines a usage of the
precondition framework [RFC3312]. The connectivity precondition
makes sure that the session doesn't get established until actual
packet connectivity is checked.
RFC 4796, The SDP (Session Description Protocol) Content Attribute
(S): [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.
15. Security Mechanisms 15. Security Mechanisms
Several extensions provide additional security features to SIP. Several extensions provide additional security features to SIP.
RFC 3853, S/MIME AES Requirement for SIP (S): RFC 3853 [71] is a RFC 4474, Enhancements for Authenticated Identity Management in SIP
brief specification that updates the cryptography mechanisms used (S): [RFC4474] defines a mechanism for providing a cryptographically
in SIP S/MIME. However, SIP S/MIME has seen very little verifiable identity of the calling party in a SIP request. Known
deployment. 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.
RFC XXXX, Certificate Management Service for The Session Initiation RFC 3323, A Privacy Mechanism for the Session Initiation Protocol
Protocol (SIP) (S): RFC XXXX [100] defines a certificate service for (SIP) (S): [RFC3323] defines the Privacy header field, used by
SIP whose purpose is to facilitate the deployment of S/MIME. The clients to request anonymity for their requests. Though it
certificate service allows clients to store and retrieve their own defines several privacy services, the only one broadly used is the
certificates, in addition to obtaining the certificates for other one that supports privacy of the P-Asserted-Identity header field
users. [RFC3325].
RFC 4567, Key Management Extensions for Session Description Protocol
(SDP) and Real Time Streaming Protocol (RTSP) (S): [RFC4567] defines
extensions to SDP that allow tunneling of an key management
protocol, namely MIKEY [RFC3830], through offer/answer exchanges.
This mechanism is one of three SRTP keying techniques specified
for SIP, with DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework] having
been selected as the final solution.
RFC 4568, Session Description Protocol (SDP) Security Descriptions
for Media Streams (S): [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 [I-D.ietf-sip-dtls-srtp-framework] having been
selected as the final solution.
draft-ietf-sip-dtls-srtp-framework, Framework for Establishing an
SRTP Security Context using DTLS (S):
[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) [RFC4347] directly between
endpoints, over the media path. It is one of three SRTP keying
techniques specified for SIP, with DTLS-SRTP
[I-D.ietf-sip-dtls-srtp-framework] having been selected as the
final solution.
RFC 3853, S/MIME AES Requirement for SIP (S): [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.
draft-ietf-sip-certs, Certificate Management Service for The Session
Initiation Protocol (SIP) (S): [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.
RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity
Body (AIB) Format (S): RFC 3893 [7] defines a SIP message fragment Body (AIB) Format (S): [RFC3893] defines a SIP message fragment
which can be signed in order to provide an authenticated identity which can be signed in order to provide an authenticated identity
over a request. It was an early predecessor to [19], and over a request. It was an early predecessor to [RFC4474], and
consequently AIB has seen no deployment. consequently AIB has seen no deployment.
RFC XXXX, SIP SAML Profile and Binding (S): RFC XXXX [102] defines draft-ietf-sip-saml, SIP SAML Profile and Binding (S):
the usage of the Security Assertion Markup Language (SAML) within [I-D.ietf-sip-saml] defines the usage of the Security Assertion
SIP, and describes how to use it in conjunction with SIP identity Markup Language (SAML) within SIP, and describes how to use it in
[19] to provide authenticated assertions about a users role or conjunction with SIP identity [RFC4474] to provide authenticated
attributes. assertions about a users role or attributes.
RFC XXXX, A Framework for Consent-Based Communications in the Session draft-ietf-sip-consent-framework, A Framework for Consent-Based
Initiation Protocol (SIP) (S): RFC XXX [101] defines several Communications in the Session Initiation Protocol (SIP) (S):
extensions to SIP, including the Trigger-Consent and Permission- [I-D.ietf-sip-consent-framework] defines several extensions to
Missing header fields. These header fields, in addition to the SIP, including the Trigger-Consent and Permission-Missing header
other procedures defined in the document, define a way to manage fields. These header fields, in addition to the other procedures
membership on "SIP mailing lists" used for instant messaging or defined in the document, define a way to manage membership on "SIP
conferencing. In particular, it helps avoid the problem of using mailing lists" used for instant messaging or conferencing. In
such amplification services for the purposes of an attack on the particular, it helps avoid the problem of using such amplification
network, by making sure a user authorizes the addition of their services for the purposes of an attack on the network, by making
address onto such a service. sure a user authorizes the addition of their address onto such a
service.
RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions draft-ietf-sipping-pending-additions, The Session Initiation Protocol
Event Package (S): RFC XXXX [103] defines a SIP event package that (SIP) Pending Additions Event Package (S):
allows a UA to learn whether consent has been given for the [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 addition of an address to a SIP "mailing list". It is used in
conjunction with the SIP framework for consent [101]. conjunction with the SIP framework for consent
[I-D.ietf-sip-consent-framework].
RFC 3329, Security Mechanism Agreement for SIP (S): RFC 3329 [72] RFC 3329, Security Mechanism Agreement for SIP (S): [RFC3329]
defines a mechanism to prevent bid-down attacks in conjunction defines a mechanism to prevent bid-down attacks in conjunction
with SIP authentication. The mechanism has seen very limited with SIP authentication. The mechanism has seen very limited
deployment. It was defined as part of the 3gpp IMS specification deployment. It was defined as part of the 3gpp IMS specification
suite [109], and is needed only when there are a multiplicity of suite [3GPP.24.229], and is needed only when there is a
security mechanisms deployed at a particular server. In practice, multiplicity of security mechanisms deployed at a particular
this has not been the case. server. In practice, this has not been the case.
RFC XXXX, End-to-Middle Security in SIP (S): RFC XXXX [73] defines draft-ietf-sip-e2m-sec, End-to-Middle Security in SIP (S):
mechanisms for providing confidentiality and integrity for SIP [I-D.ietf-sip-e2m-sec] defines mechanisms for providing
message bodies sent from user agents to specific network confidentiality and integrity for SIP message bodies sent from
intermediaries. user agents to specific network intermediaries.
RFC 4572, Connection-Oriented Media Transport over the Transport RFC 4572, Connection-Oriented Media Transport over the Transport
Layer Security (TLS) Protocol in the Session Description Protocol Layer Security (TLS) Protocol in the Session Description Protocol
(SDP) (S): RFC 4572 [104] specifies a mechanism for signaling TLS- (SDP) (S): [RFC4572] specifies a mechanism for signaling TLS-based
based media streams between endpoints. It expands the TCP-based media streams between endpoints. It expands the TCP-based media
media signaling parameters defined in [86] to include fingerprint signaling parameters defined in [RFC4145] to include fingerprint
information for TLS streams, so that TLS can operate between end information for TLS streams, so that TLS can operate between end
hosts using self-signed certificates. hosts using self-signed certificates.
RFC XXXX, Security Preconditions for Session Description Protocol draft-ietf-mmusic-secruityprecondition, Security Preconditions for
Media Streams (S): RFC XXXX [92] defines a precondition for use with Session Description Protocol Media Streams (S):
the preconditions framework [59]. The security precondition [I-D.ietf-mmusic-securityprecondition] defines a precondition for
prevents a session from being established until a security media use with the preconditions framework [RFC3312]. The security
stream is set up. precondition prevents a session from being established until a
security media stream is set up.
16. Instant Messaging, Presence and Multimedia 16. Conferencing
Numerous SIP and SDP extensions are aimed at conferencing as their
primary application.
RFC 4574, The SDP (Session Description Protocol) Label Attribute
(S): [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.
RFC 3911, The SIP Join Header Field (S): [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.
RFC 4575, A SIP Event Package for Conference State (S): [RFC4575]
defines a mechanism for learning about changes in conference
state, including conference membership.
draft-ietf-sip-multiple-refer, Referring to Multiple Resources in SIP
(S): [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.
draft-ietf-sip-uri-list-conferencing, Conference Establishment Using
Request-Contained Lists in SIP (S):
[I-D.ietf-sip-uri-list-conferencing] is similar to
[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.
RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
Control Protocol (BFCP) Streams (S): [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.
17. Instant Messaging, Presence and Multimedia
SIP provides extensions for instant messaging, presence, and SIP provides extensions for instant messaging, presence, and
multimedia. multimedia.
RFC 3428, SIP Extension for Instant Messaging (S): RFC 3428 [74] RFC 3428, SIP Extension for Instant Messaging (S): [RFC3428] defines
defines the MESSAGE method, used for sending an instant message the MESSAGE method, used for sending an instant message without
without setting up a session (sometimes called "page mode"). setting up a session (sometimes called "page mode").
RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [53] RFC 3856, A Presence Event Package for SIP (S): [RFC3856] defines an
defines an event package for indicating user presence through SIP. event package for indicating user presence through SIP.
RFC 3857, A Watcher Information Event Template Package for SIP (S): RFC 3857, A Watcher Information Event Template Package for SIP (S):
RFC 3857 [54], also known as winfo, provides a mechanism for a [RFC3857], also known as winfo, provides a mechanism for a user
user agent to find out what subscriptions are in place for a agent to find out what subscriptions are in place for a particular
particular event package. Its primary usage is with presence, but event package. Its primary usage is with presence, but it can be
it can be used with any event package. used with any event package.
RFC XXXX, A Session Description Protocol (SDP) Offer/Answer Mechanism draft-ietf-mmusic-file-transfer-mech, A Session Description Protocol
to Enable File Transfer (S): RFC XXXX [107] defines a mechanism for (SDP) Offer/Answer Mechanism to Enable File Transfer (S):
[I-D.ietf-mmusic-file-transfer-mech] defines a mechanism for
signaling a file transfer session with SIP. signaling a file transfer session with SIP.
17. Emergency Services 18. Emergency Services
Emergency services here covers both emergency calling (for example, Emergency services here covers pre-emption services, which allow
911 in the United States), and pre-emption services, which allow
authorized individuals to gain access to network resources in time of authorized individuals to gain access to network resources in time of
emergency. emergency.
RFC 4411, Extending the SIP Reason Header for Preemption Events (S): RFC 4411, Extending the SIP Reason Header for Preemption Events (S):
RFC 4411 [75] defines an extension to the Reason header, allowing [RFC4411] defines an extension to the Reason header, allowing a UA
a UA to know that its dialog was torn down because a higher to know that its dialog was torn down because a higher priority
priority session came through. session came through.
RFC 4412, Communications Resource Priority for SIP (S): RFC 4412 RFC 4412, Communications Resource Priority for SIP (S): [RFC4412]
[76] defines a new header field, Resource-Priority, that allows a defines a new header field, Resource-Priority, that allows a
session to get priority treatment from the network. session to get priority treatment from the network.
18. Security Considerations 19. Security Considerations
This specification is an overview of existing specifications, and This specification is an overview of existing specifications, and
does not introduce any security considerations on its own. Of does not introduce any security considerations on its own. Of
course, the world would be far more secure if everyone would follow course, the world would be far more secure if everyone would follow
one simple rule: "Don't Panic!" [42]. one simple rule: "Don't Panic!" [HGTTG].
19. IANA Considerations 20. IANA Considerations
None. None.
20. Acknowledgements 21. Acknowledgements
The author would like to thank Spencer Dawkins for his comments on The author would like to thank Spencer Dawkins, Brian Stucker, John
this specification. Elwell and Avshalom Houri for their comments on this document.
21. Informative References 22. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
"RTP: A Transport Protocol for Real-Time Applications", Jacobson, "RTP: A Transport Protocol for Real-Time
RFC 3550, July 2003. Applications", RFC 3550, July 2003.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Session Description Protocol (SDP)", RFC 3264, June 2002. with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): [I-D.ietf-mmusic-ice]
A Protocol for Network Address Translator (NAT) Traversal for Rosenberg, J., "Interactive Connectivity Establishment
Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in (ICE): A Protocol for Network Address Translator (NAT)
progress), June 2007. Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[6] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Z., and J. Rosenberg, "Signaling Compression (SigComp)", Liu, Z., and J. Rosenberg, "Signaling Compression
RFC 3320, January 2003. (SigComp)", RFC 3320, January 2003.
[7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated [RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Identity Body (AIB) Format", RFC 3893, September 2004. Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[8] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
Rosen, "Change Process for the Session Initiation Protocol and B. Rosen, "Change Process for the Session Initiation
(SIP)", BCP 67, RFC 3427, December 2002. Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
"SIP: Session Initiation Protocol", RFC 2543, March 1999. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
(SIP): Locating SIP Servers", RFC 3263, June 2002. Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[12] Mealling, M. and R. Daniel, "The Naming Authority Pointer [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000. (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[14] Peterson, J., "A Privacy Mechanism for the Session Initiation [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[15] Jennings, C., Peterson, J., and M. Watson, "Private Extensions [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
to the Session Initiation Protocol (SIP) for Asserted Identity Extensions to the Session Initiation Protocol (SIP) for
within Trusted Networks", RFC 3325, November 2002. Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[16] Willis, D. and B. Hoeneisen, "Session Initiation Protocol [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent (SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002. Contacts", RFC 3327, December 2002.
[17] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Initiation Protocol (SIP) for Symmetric Response Routing", Session Initiation Protocol (SIP) for Symmetric Response
RFC 3581, August 2003. Routing", RFC 3581, August 2003.
[18] Sparks, R., "Actions Addressing Identified Issues with the [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Transaction", Session Initiation Protocol's (SIP) Non-INVITE
RFC 4320, January 2006. Transaction", RFC 4320, January 2006.
[19] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Identity Management in the Session Initiation Protocol (SIP)", Authenticated Identity Management in the Session
RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[20] Rosenberg, J., "Obtaining and Using Globally Routable User [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-14 (work in progress), June 2007. (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[21] Jennings, C. and R. Mahy, "Managing Client Initiated [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-09 (work in progress), June 2007. draft-ietf-sip-outbound-10 (work in progress), July 2007.
[22] Petrack, S. and L. Conroy, "The PINT Service Protocol: [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call Extensions to SIP and SDP for IP Access to Telephone Call
Services", RFC 2848, June 2000. Services", RFC 2848, June 2000.
[23] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu, H., [RFC3910] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu,
and M. Unmehopa, "The SPIRITS (Services in PSTN requesting H., and M. Unmehopa, "The SPIRITS (Services in PSTN
Internet Services) Protocol", RFC 3910, October 2004. requesting Internet Services) Protocol", RFC 3910,
October 2004.
[24] Vemuri, A. and J. Peterson, "Session Initiation Protocol for [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
Telephones (SIP-T): Context and Architectures", BCP 63, for Telephones (SIP-T): Context and Architectures",
RFC 3372, September 2002. BCP 63, RFC 3372, September 2002.
[25] Camarillo, G., Roach, A., Peterson, J., and L. Ong, [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
"Integrated Services Digital Network (ISDN) User Part (ISUP) "Integrated Services Digital Network (ISDN) User Part
to Session Initiation Protocol (SIP) Mapping", RFC 3398, (ISUP) to Session Initiation Protocol (SIP) Mapping",
December 2002. RFC 3398, December 2002.
[26] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping [RFC3578] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
of Integrated Services Digital Network (ISDN) User Part (ISUP) "Mapping of Integrated Services Digital Network (ISDN)
Overlap Signalling to the Session Initiation Protocol (SIP)", User Part (ISUP) Overlap Signalling to the Session
RFC 3578, August 2003. Initiation Protocol (SIP)", RFC 3578, August 2003.
[27] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
RFC 3960, December 2004. RFC 3960, December 2004.
[28] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Responses in Session Initiation Protocol (SIP)", RFC 3262, Provisional Responses in Session Initiation Protocol
June 2002. (SIP)", RFC 3262, June 2002.
[29] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[30] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000.
[31] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
[32] Willis, D. and B. Hoeneisen, "Session Initiation Protocol [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Service Route Discovery (SIP) Extension Header Field for Service Route Discovery
During Registration", RFC 3608, October 2003. During Registration", RFC 3608, October 2003.
[33] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
User Agent Capabilities in the Session Initiation Protocol "Indicating User Agent Capabilities in the Session
(SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[34] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[35] Donovan, S. and J. Rosenberg, "Session Timers in the Session [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Initiation Protocol (SIP)", RFC 4028, April 2005. Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[36] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
Control Transmission Protocol (SCTP) as a Transport for the Stream Control Transmission Protocol (SCTP) as a Transport
Session Initiation Protocol (SIP)", RFC 4168, October 2005. for the Session Initiation Protocol (SIP)", RFC 4168,
October 2005.
[37] Barnes, M., "An Extension to the Session Initiation Protocol [RFC4244] Barnes, M., "An Extension to the Session Initiation
(SIP) for Request History Information", RFC 4244, Protocol (SIP) for Request History Information", RFC 4244,
November 2005. November 2005.
[38] Levin, O., "Suppression of Session Initiation Protocol (SIP) [RFC4488] Levin, O., "Suppression of Session Initiation Protocol
REFER Method Implicit Subscription", RFC 4488, May 2006. (SIP) REFER Method Implicit Subscription", RFC 4488,
May 2006.
[39] Rosenberg, J., "Request Authorization through Dialog [RFC4538] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)", Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006. RFC 4538, June 2006.
[40] Levin, O. and A. Johnston, "Conveying Feature Tags with the [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with
Session Initiation Protocol (SIP) REFER Method", RFC 4508, the Session Initiation Protocol (SIP) REFER Method",
May 2006. RFC 4508, May 2006.
[41] Willis, D. and A. Allen, "Requesting Answering Modes for the [I-D.ietf-sip-answermode]
Session Initiation Protocol (SIP)", Willis, D. and A. Allen, "Requesting Answering Modes for
draft-ietf-sip-answermode-04 (work in progress), June 2007. the Session Initiation Protocol (SIP)",
draft-ietf-sip-answermode-06 (work in progress),
September 2007.
[42] Adams, D., "The Hitchhiker's Guide to the Galaxy", [HGTTG] Adams, D., "The Hitchhiker's Guide to the Galaxy",
September 1979. September 1979.
[43] Rosenberg, J., "Rejecting Anonymous Requests in the Session [I-D.ietf-sip-acr-code]
Initiation Protocol (SIP)", draft-ietf-sip-acr-code-04 (work Rosenberg, J., "Rejecting Anonymous Requests in the
in progress), March 2007. Session Initiation Protocol (SIP)",
draft-ietf-sip-acr-code-05 (work in progress), July 2007.
[44] Camarillo, G., "Referring to Multiple Resources in the Session [I-D.ietf-sip-multiple-refer]
Initiation Protocol (SIP)", draft-ietf-sip-multiple-refer-01 Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M.,
(work in progress), January 2007. and H. Khartabil, "Referring to Multiple Resources in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-multiple-refer-02 (work in progress),
November 2007.
[45] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[46] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004. BCP 85, RFC 3725, April 2004.
[47] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[48] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP)
Mechanism", RFC 3892, September 2004. Referred-By Mechanism", RFC 3892, September 2004.
[49] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
"Join" Header", RFC 3911, October 2004. (SIP) "Join" Header", RFC 3911, October 2004.
[50] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van
"Transcoding Services Invocation in the Session Initiation Wijk, "Transcoding Services Invocation in the Session
Protocol (SIP) Using Third Party Call Control (3pcc)", Initiation Protocol (SIP) Using Third Party Call Control
RFC 4117, June 2005. (3pcc)", RFC 4117, June 2005.
[51] Niemi, A., "Session Initiation Protocol (SIP) Extension for [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[52] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004. Package for Registrations", RFC 3680, March 2004.
[53] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[54] Rosenberg, J., "A Watcher Information Event Template-Package [RFC3857] Rosenberg, J., "A Watcher Information Event Template-
for the Session Initiation Protocol (SIP)", RFC 3857, Package for the Session Initiation Protocol (SIP)",
August 2004. RFC 3857, August 2004.
[55] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005. Protocol (SIP)", RFC 4235, November 2005.
[56] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State", Initiation Protocol (SIP) Event Package for Conference
RFC 4575, August 2006. State", RFC 4575, August 2006.
[57] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[58] Pendleton, A., "Session Initiation Protocol Package for Voice [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol
Quality Reporting Event", draft-ietf-sipping-rtcp-summary-02 (SIP) Event Package for Key Press Stimulus (KPML)",
(work in progress), May 2007. RFC 4730, November 2006.
[59] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of [I-D.ietf-sipping-rtcp-summary]
Resource Management and Session Initiation Protocol (SIP)", Pendleton, A., "Session Initiation Protocol Package for
RFC 3312, October 2002. Voice Quality Reporting Event",
draft-ietf-sipping-rtcp-summary-02 (work in progress),
May 2007.
[60] Camarillo, G. and P. Kyzivat, "Update to the Session [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
Initiation Protocol (SIP) Preconditions Framework", RFC 4032, "Integration of Resource Management and Session Initiation
March 2005. Protocol (SIP)", RFC 3312, October 2002.
[61] Marshall, W., "Private Session Initiation Protocol (SIP) [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Extensions for Media Authorization", RFC 3313, January 2003. Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005.
[62] Petrie, D. and S. Channabasappa, "A Framework for Session [RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP)
Initiation Protocol User Agent Profile Delivery", Extensions for Media Authorization", RFC 3313,
draft-ietf-sipping-config-framework-12 (work in progress), January 2003.
June 2007.
[63] Petrie, D., "Extensions to the Session Initiation Protocol [I-D.ietf-sipping-config-framework]
(SIP) User Agent Profile Delivery Change Notification Event Channabasappa, S., "A Framework for Session Initiation
Package for the Extensible Markup Language Language Protocol User Agent Profile Delivery",
Configuration Access Protocol (XCAP)", draft-ietf-sipping-config-framework-13 (work in progress),
draft-ietf-sip-xcap-config-00 (work in progress), October 2007.
October 2006.
[64] Camarillo, G., "Compressing the Session Initiation Protocol [RFC3486] Camarillo, G., "Compressing the Session Initiation
(SIP)", RFC 3486, February 2003. Protocol (SIP)", RFC 3486, February 2003.
[65] Foster, M., McGarry, T., and J. Yu, "Number Portability in the [RFC3482] Foster, M., McGarry, T., and J. Yu, "Number Portability in
Global Switched Telephone Network (GSTN): An Overview", the Global Switched Telephone Network (GSTN): An
RFC 3482, February 2003. Overview", RFC 3482, February 2003.
[66] Campbell, B. and R. Sparks, "Control of Service Context using [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
SIP Request-URI", RFC 3087, April 2001. using SIP Request-URI", RFC 3087, April 2001.
[67] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
[68] Camarillo, G., "Subscriptions to Request-Contained Resource [I-D.ietf-sip-uri-list-subscribe]
Lists in the Session Initiation Protocol (SIP)", Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
draft-ietf-sip-uri-list-subscribe-01 (work in progress), Request-Contained Resource Lists in the Session Initiation
January 2007. Protocol (SIP)", draft-ietf-sip-uri-list-subscribe-02
(work in progress), November 2007.
[69] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient [I-D.ietf-sip-uri-list-message]
MESSAGE Requests in the Session Initiation Protocol (SIP)", Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
draft-ietf-sip-uri-list-message-01 (work in progress), MESSAGE Requests in the Session Initiation Protocol
January 2007. (SIP)", draft-ietf-sip-uri-list-message-02 (work in
progress), November 2007.
[70] Camarillo, G. and A. Johnston, "Conference Establishment Using [I-D.ietf-sip-uri-list-conferencing]
Request-Contained Lists in the Session Initiation Protocol Camarillo, G. and A. Johnston, "Conference Establishment
(SIP)", draft-ietf-sip-uri-list-conferencing-01 (work in Using Request-Contained Lists in the Session Initiation
progress), January 2007. Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02
(work in progress), November 2007.
[71] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)", Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004. RFC 3853, July 2004.
[72] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003. Initiation Protocol (SIP)", RFC 3329, January 2003.
[73] Ono, K. and S. Tachimoto, "End-to-middle Security in the [I-D.ietf-sip-e2m-sec]
Session Initiation Protocol (SIP)", draft-ietf-sip-e2m-sec-05 Ono, K. and S. Tachimoto, "End-to-middle Security in the
(work in progress), March 2007. Session Initiation Protocol (SIP)",
draft-ietf-sip-e2m-sec-06 (work in progress), July 2007.
[74] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[75] Polk, J., "Extending the Session Initiation Protocol (SIP) [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
Reason Header for Preemption Events", RFC 4411, February 2006. and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[76] Schulzrinne, H. and J. Polk, "Communications Resource Priority [RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP)
for the Session Initiation Protocol (SIP)", RFC 4412, Reason Header for Preemption Events", RFC 4411,
February 2006. February 2006.
[77] Rosenberg, J., "A Framework for Application Interaction in the [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[I-D.ietf-sipping-app-interaction-framework]
Rosenberg, J., "A Framework for Application Interaction in
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-05 (work in draft-ietf-sipping-app-interaction-framework-05 (work in
progress), July 2005. progress), July 2005.
[78] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[79] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
"Grouping of Media Lines in the Session Description Protocol Schulzrinne, "Grouping of Media Lines in the Session
(SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[80] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
Session Description Protocol (SDP)", RFC 3605, October 2003. in Session Description Protocol (SDP)", RFC 3605,
October 2003.
[81] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
[82] Sparks, R., "Addressing an Amplification Vulnerability in [I-D.ietf-sip-fork-loop-fix]
Sparks, R., "Addressing an Amplification Vulnerability in
Session Initiation Protocol (SIP) Forking Proxies", Session Initiation Protocol (SIP) Forking Proxies",
draft-ietf-sip-fork-loop-fix-05 (work in progress), draft-ietf-sip-fork-loop-fix-05 (work in progress),
March 2007. March 2007.
[83] Camarillo, G., "The Early Session Disposition Type for the [RFC3959] Camarillo, G., "The Early Session Disposition Type for the
Session Initiation Protocol (SIP)", RFC 3959, December 2004. Session Initiation Protocol (SIP)", RFC 3959,
December 2004.
[84] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG F., Watson, M., and M. Zonoun, "MIME media types for ISUP
Objects", RFC 3204, December 2001. and QSIG Objects", RFC 3204, December 2001.
[85] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, [RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
November 2002. RFC 3420, November 2002.
[86] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
Session Description Protocol (SDP)", RFC 4145, September 2005. the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[87] Camarillo, G. and J. Rosenberg, "The Alternative Network [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005. Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[88] Rosenberg, J., "TCP Candidates with Interactive Connectivity [I-D.ietf-mmusic-ice-tcp]
Establishment (ICE", draft-ietf-mmusic-ice-tcp-03 (work in Rosenberg, J., "TCP Candidates with Interactive
progress), March 2007. Connectivity Establishment (ICE",
draft-ietf-mmusic-ice-tcp-04 (work in progress),
July 2007.
[89] Burger, E., "A Mechanism for Content Indirection in Session [RFC4483] Burger, E., "A Mechanism for Content Indirection in
Initiation Protocol (SIP) Messages", RFC 4483, May 2006. Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006.
[90] Westerlund, M., "A Transport Independent Bandwidth Modifier [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
for the Session Description Protocol (SDP)", RFC 3890, Modifier for the Session Description Protocol (SDP)",
September 2004. RFC 3890, September 2004.
[91] Camarillo, G., "Session Description Protocol (SDP) Format for [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
Binary Floor Control Protocol (BFCP) Streams", RFC 4583, for Binary Floor Control Protocol (BFCP) Streams",
November 2006. RFC 4583, November 2006.
[92] Andreasen, F. and D. Wing, "Security Preconditions for Session [I-D.ietf-mmusic-securityprecondition]
Description Protocol (SDP) Media Streams", Andreasen, F. and D. Wing, "Security Preconditions for
draft-ietf-mmusic-securityprecondition-03 (work in progress), Session Description Protocol (SDP) Media Streams",
October 2006. draft-ietf-mmusic-securityprecondition-04 (work in
progress), July 2007.
[93] Andreasen, F., "Connectivity Preconditions for Session [I-D.ietf-mmusic-connectivity-precon]
Andreasen, F., "Connectivity Preconditions for Session
Description Protocol Media Streams", Description Protocol Media Streams",
draft-ietf-mmusic-connectivity-precon-02 (work in progress), draft-ietf-mmusic-connectivity-precon-02 (work in
June 2006. progress), June 2006.
[94] Hautakorpi, J. and G. Camarillo, "The Session Description [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description
Protocol (SDP) Content Attribute", RFC 4796, February 2007. Protocol (SDP) Content Attribute", RFC 4796,
February 2007.
[95] Levin, O. and G. Camarillo, "The Session Description Protocol [RFC4574] Levin, O. and G. Camarillo, "The Session Description
(SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[96] Hilt, V. and G. Camarillo, "A Session Initiation Protocol [I-D.ietf-sipping-policy-package]
(SIP) Event Package for Session-Specific Session Policies.", Hilt, V. and G. Camarillo, "A Session Initiation Protocol
draft-ietf-sipping-policy-package-03 (work in progress), (SIP) Event Package for Session-Specific Session
February 2007. Policies", draft-ietf-sipping-policy-package-04 (work in
progress), August 2007.
[97] Camarillo, G. and A. Monrad, "Mapping of Media Streams to [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to
Resource Reservation Flows", RFC 3524, April 2003. Resource Reservation Flows", RFC 3524, April 2003.
[98] Lawrence, S., "Diagnostic Responses for Session Initiation [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Protocol Hop Limit Errors", Media Services with SIP", RFC 4240, December 2005.
draft-ietf-sip-hop-limit-diagnostics-03 (work in progress),
June 2006.
[99] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media
Services with SIP", RFC 4240, December 2005.
[100] Jennings, C., "Certificate Management Service for The Session [I-D.ietf-sip-certs]
Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in Jennings, C., "Certificate Management Service for The
progress), March 2007. Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-04 (work in progress), July 2007.
[101] Rosenberg, J., "A Framework for Consent-Based Communications [I-D.ietf-sip-consent-framework]
in the Session Initiation Protocol (SIP)", Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
draft-ietf-sip-consent-framework-01 (work in progress), for Consent-based Communications in the Session Initiation
November 2006. Protocol (SIP)", draft-ietf-sip-consent-framework-03 (work
in progress), November 2007.
[102] Tschofenig, H., "SIP SAML Profile and Binding", [I-D.ietf-sip-saml]
Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-02 (work in progress), May 2007. draft-ietf-sip-saml-02 (work in progress), May 2007.
[103] Camarillo, G., "The Session Initiation Protocol (SIP) Pending [I-D.ietf-sipping-pending-additions]
Additions Event Package", Camarillo, G., "The Session Initiation Protocol (SIP)
draft-ietf-sipping-pending-additions-02 (work in progress), Pending Additions Event Package",
April 2007. draft-ietf-sipping-pending-additions-03 (work in
progress), November 2007.
[104] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[105] Andreasen, F., "SDP Capability Negotiation", [I-D.ietf-mmusic-sdp-capability-negotiation]
draft-ietf-mmusic-sdp-capability-negotiation-05 (work in Andreasen, F., "SDP Capability Negotiation",
progress), March 2007. draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
progress), October 2007.
[106] Andreasen, F., "SDP media capabilities Negotiation", [I-D.ietf-mmusic-sdp-media-capabilities]
Andreasen, F., "SDP media capabilities Negotiation",
draft-ietf-mmusic-sdp-media-capabilities-01 (work in draft-ietf-mmusic-sdp-media-capabilities-01 (work in
progress), February 2007. progress), February 2007.
[107] Garcia-Martin, M., "A Session Description Protocol (SDP) [I-D.ietf-mmusic-file-transfer-mech]
Offer/Answer Mechanism to Enable File Transfer", Garcia-Martin, M., Isomaki, M., Camarillo, G., and S.
draft-ietf-mmusic-file-transfer-mech-03 (work in progress), Loreto, "A Session Description Protocol (SDP) Offer/Answer
Mechanism to Enable File Transfer",
draft-ietf-mmusic-file-transfer-mech-04 (work in
progress), October 2007.
[I-D.ietf-sip-ice-option-tag]
Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session
Initiation Protocol (SIP)",
draft-ietf-sip-ice-option-tag-02 (work in progress),
June 2007. June 2007.
[108] Rosenberg, J., "Indicating Support for Interactive [3GPP.24.229]
Connectivity Establishment (ICE) in the Session Initiation 3GPP, "Internet Protocol (IP) multimedia call control
Protocol (SIP)", draft-ietf-sip-ice-option-tag-02 (work in protocol based on Session Initiation Protocol (SIP) and
progress), June 2007. Session Description Protocol (SDP); Stage 3", 3GPP
TS 24.229 5.20.0, September 2007.
[109] 3GPP, "Internet Protocol (IP) multimedia call control protocol [I-D.ietf-sip-record-route-fix]
based on Session Initiation Protocol (SIP) and Session Froment, T. and C. Lebel, "Addressing Record-Route issues
Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.19.0, in the Session Initiation Protocol (SIP)",
June 2007. draft-ietf-sip-record-route-fix-01 (work in progress),
November 2007.
[110] Froment, T. and C. Lebel, "Addressing Record-Route issues in [I-D.ietf-sip-subnot-etags]
the Session Initiation Protocol (SIP)", Niemi, A., "An Extension to Session Initiation Protocol
draft-ietf-sip-record-route-fix-00 (work in progress), (SIP) Events for Conditional Event Notification",
July 2007. draft-ietf-sip-subnot-etags-01 (work in progress),
August 2007.
[111] Niemi, A., "An Extension to Session Initiation Protocol (SIP) [I-D.ietf-sip-sips]
Events for Conditional Event Notification", Audet, F., "The use of the SIPS URI Scheme in the Session
draft-ietf-sip-subnot-etags-00 (work in progress), May 2007. Initiation Protocol (SIP)", draft-ietf-sip-sips-06 (work
in progress), August 2007.
[112] Audet, F., "The use of the SIPS URI Scheme in the Session [RFC4896] Surtees, A., West, M., and A. Roach, "Signaling
Initiation Protocol (SIP)", draft-ietf-sip-sips-05 (work in Compression (SigComp) Corrections and Clarifications",
progress), June 2007. RFC 4896, June 2007.
[I-D.ietf-rohc-sigcomp-sip]
Bormann, C., Liu, Z., Price, R., and G. Camarillo,
"Applying Signaling Compression (SigComp) to the Session
Initiation Protocol (SIP)",
draft-ietf-rohc-sigcomp-sip-08 (work in progress),
September 2007.
[I-D.ietf-simple-simple]
Rosenberg, J., "SIMPLE made Simple: An Overview of the
IETF Specifications for Instant Messaging and Presence
using the Session Initiation Protocol (SIP)",
draft-ietf-simple-simple-00 (work in progress), July 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[I-D.ietf-sip-dtls-srtp-framework]
Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing an SRTP Security Context using DTLS",
draft-ietf-sip-dtls-srtp-framework-00 (work in progress),
November 2007.
[I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-03 (work in
progress), September 2007.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833,
May 2000.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
 End of changes. 253 change blocks. 
810 lines changed or deleted 1091 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/