|
|
SIP RFC's
1. Core SIP
Specifications
2. Public Switched Telephone Network (PSTN)
Interworking
3. General Purpose Infrastructure Extensions
4. NAT Traversal
5. Minor Extensions
6. Conferencing
7. Call
Control Primitives
8. Event
Framework and Packages
9. Quality
of Service
10. Operations
and Management
11. SIP
Compression
12. SIP
Service URIs
13. Security
Mechanisms
14. Instant
Messaging, Presence and Multimedia
15. Emergency Services
16. IP Multimedia Sub-systems
1.
Core SIP Specifications
RFC
3261, The
Session Initiation Protocol (S): RFC 3261 [1] is
the
core SIP protocol itself. RFC 3261 is an update to RFC 2543
[9].
It is the president of the galaxy [42] as far as the suite of SIP
specifications is concerned.
RFC 3263, Locating SIP Servers
(S): RFC 3263 [10] provides DNS
procedures for
taking a SIP URI, and determining a SIP server that
is associated with
that SIP URI. RFC 3263 is essential for any
implementation using
SIP with DNS. RFC 3263 makes use of both DNS
SRV records [11] and
NAPTR records [12].
RFC 3264, An Offer/Answer Model with the
Session Description Protocol
(S): RFC 3264 [4] defines how the
Session Description Protocol (SDP)
[78] is used with
SIP to negotiate the parameters of a media
session.
It is in widespread usage and an integral part of the
behavior of RFC 3261.
RFC 3265, SIP-Specific Event Notification
(S): RFC 3265 [13] defines
the SUBSCRIBE and
NOTIFY methods. These two methods provide a
general event
notification framework for SIP. To actually use the
framework,
extensions need to be defined for specific event
packages.
An event package defines a schema for the event data,
and describes other
aspects of event processing specific to that
schema. An
RFC 3265 implementation is required when any event
package is used.
RFC 3325, Private Extensions to SIP for
Asserted Identity within
Trusted
Networks (I): Though its P-header status implies
that it has
limited
applicability, RFC 3325 [15], which defines the
P-Asserted-ID header
field has been widely deployed. It is used
as the basic
mechanism for providing secure caller ID services.
RFC 3327, SIP Extension Header Field for
Registering Non-Adjacent
Contacts
(S): RFC 3327 [16] defines the Path header field.
This
field is inserted by
proxies between a client and their registrar.
It allows inbound
requests towards that client to traverse these
proxies prior to
being delivered to the user agent. It is
essential in any SIP
deployment that has edge proxies, which are
proxies between the
client and the home proxy or SIP registrar.
RFC 3581, An Extension to SIP for Symmetric
Response Routing (S):
RFC 3581 [17]
defines the rport parameter of the Via header. It
is an essential
piece of getting SIP through NAT. NAT traversal
for SIP is
considered a core part of the specifications.
RFC 3840, Indicating User Agent
Capabilities in SIP (S): RFC 3840
[33] defines a
mechanism for carrying capability information about
a user agent in
REGISTER requests and in dialog-forming requests
like
INVITE. It has found use with conferencing (the isfocus
parameter declares
that a user agent is a conference server) and
with applications
like push-to-talk.
RFC 4320, Actions Addressing Issues
Identified with the Non-INVITE
Transaction
in SIP (S): RFC 4320 [18] formally updates RFC
3261, and
modifies some of the
behaviors associated with non-INVITE
transactions. These address some problems found in timeout and
failure cases.
RFC 4474, Enhancements for Authenticated
Identity Management in SIP
(S): RFC 4474 [19] defines a
mechanism for providing a
cryptographically
verifiable identity of the calling party in a
SIP
request. Known as "SIP Identity", this mechanism provides an
alternative to RFC
3325. It has seen little deployment so far,
but its importance
as a key construct for anti-spam techniques
makes it a core part
of the SIP specifications.
RFC
4566, Session
Description Protocol (S): RFC 4566 [78] defines a
format for
representing multimedia sessions. SDP objects are
carried in the body
of SIP messages, and based on the offer/answer
model, are used to
negotiate the media characteristics of a
session between
users.
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
3605, Real
Time Control Protocol (RTCP) Attribute in the Session
Description Protocol (SDP)
(S): RFC 3605 [80] defines a way to
explicitly signal,
within an SDP message, the IP address and port
for RTCP, rather
than using the port+1 rule in the Real Time
Transport Protocol
(RTP) [3]. It is needed for devices behind NAT
and used by ICE.
RFC 4916, Connected Identity in the Session
Initiation Protocol (SIP)
(S): RFC 4916 [81]
defines an extension to SIP that allows a UAC to
determine the
identity of the UAS. Due to forwarding and
retargeting
services, this may not be the same as the user that
the UAC was
originally trying to reach. The mechanism works in
tandem with the SIP
identity specification [19] to provide
signatures over the
connected party identity.
draft-ietf-sip-gruu-14,
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.
draft-ietf-sip-outbound-10,
Managing Client Initiated Connections through SIP
(S): RFC
XXXX [21], also
known as SIP outbound, defines important changes
to the SIP
registration mechanism which enable delivery of SIP
messages towards a
UA when it is behind a NAT. This specification
is the cornerstone
of the SIP NAT traversal strategy.
draft-ietf-mmusic-sdp-capability-negotiation-06,
SDP
Capability Negotiation (S): RFC XXXX [105]
defines a
set of extensions to
SDP that allow for capability negotiation
within
SDP. Capability negotiation can be used to select between
different profiles
of RTP (secure vs. unsecure) or to negotiate
codecs such that an
agent has to select one amongst a set of
supported codecs.
draft-ietf-mmusic-ice-17., Interactive Connectivity
Establishment (ICE) (S): RFC XXXX
[5] defines a
technique for NAT traversal of media sessions for
protocols that make
use of the offer/answer model. This
specification is the
IETF recommended mechanism for NAT traversal
for SIP media
streams, and is meant to be used even by endpoints
which are themselves
never behind a NAT. A SIP option tag and
media feature tag
RFC XXXX [108] have been defined for use with
ICE.
draft-ietf-sip-sips-05,
The use of the SIPS URI Scheme in the Session Initiation
Protocol (SIP) (S): RFC
XXXX [112] 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.
2. Public Switched Telephone Network
(PSTN) Interworking
RFC
2848, The
PINT Service Protocol
(S): RFC 2848 [22] is one of the
earliest extensions
to SIP. It defines procedures for using SIP
to invoke services
that actually execute on the PSTN. Its main
application is for
third party call control, allowing an IP host
to set up a call
between two PSTN endpoints. PINT has a
relatively narrow
focus and has not seen widespread deployment.
RFC 3910, The SPIRITS Protocol
(S): Continuing the trend of naming
PSTN related
extensions with alcohol references, SPIRITS [23]
defines the inverse
of PINT. It allows a switch in the PSTN to
ask an IP element
about how to proceed with call waiting. It was
developed primarily
to support Internet Call Waiting (ICW).
Perhaps the next
specification will be called the Pan Galactic
Gargle Blaster [42].
RFC 3372, SIP for Telephones (SIP-T):
Context and Architectures (I):
SIP-T [24] defines a
mechanism for using SIP between pairs of PSTN
gateways.
Its essential idea is to tunnel ISUP signaling between
the gateways in the
body of SIP messages. SIP-T motivated the
development of INFO
[30]. SIP-T has seen widespread
implementation.
RFC 3398, ISUP to SIP Mapping
(S): RFC 3398 [25] defines how to do
protocol mapping
from the SS7 ISDN User Part (ISUP) signaling to
SIP. It is
widely used in SS7 to SIP gateways and is part of the
SIP-T framework.
RFC 3578, Mapping of ISUP Overlap Signaling
to SIP (S): RFC 3578
[26] defines a
mechanism to map overlap dialing into SIP. This
specification is
widely regarded as the ugliest SIP specification,
as the introduction
to the specification itself advises that it
has many
problems. Overlap signaling (the practice of sending
digits into the
network as dialed instead of waiting for complete
collection of the
called party number) is largely incompatible
with SIP at some
fairly fundamental levels. That said, RFC 3578
is mostly harmless
and has seen some usage.
RFC 3960, Early Media and Ringtone
Generation in SIP (I): RFC 3960
[27] defines some
guidelines for handling early media - the
practice of sending
media from the called party towards the caller
- prior to
acceptance of the call. Early media is generated only
from the PSTN.
RFC 3959, Early Session Disposition Type
for the Session Initiation
Protocol (SIP) (S): RFC 3959 [83] defines a new
session
disposition type for
use with early media. It indicates that
the SDP in the body
is for a special early media session.
RFC 3204, MIME Media Types for ISUP and
QSIG Objects (S): RFC 3204
[84] defines MIME
objects for representing SS7 signaling messages.
These are carried in
the body of SIP messages when SIP-T is used.
3. General Purpose Infrastructure
Extensions
RFC 3262, Reliability of
Provisional Responses in SIP (S): SIP
defines two types of
responses to a request - final and
provisional. Provisional responses are numbered from 100 to
199.
In SIP, these
responses are not sent reliably. This choice was
made in RFC 2543
since the messages were meant to just be truly
informational, and
rendered to the user. However, subsequent work
on PSTN interworking
demonstrated a need to map provisional
responses to PSTN
messages that needed to be sent reliably. RFC
3262 [28] was
developed to allow reliability of provisional
responses.
The specification defines the PRACK method, used for
indicating that a
provisional response was received. Though it
provides a generic
capability for SIP, RFC 3262 implementations
have been most
common in PSTN interworking devices. However,
PRACK brings a great
deal of complication for relatively small
benefit.
As such, it has seen only mild levels of deployment.
RFC 3323, A Privacy
Mechanism for the Session Initiation Protocol
(SIP) (S): RFC 3323 [14]
defines the Privacy header field, used by
clients to request
anonymity for their requests. Though it
defines numerous
privacy services, the only one broadly used is
the one that
supports privacy of the P-Asserted-ID header field
[15].
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
extension to RFC
2543. It defines a method, INFO, used to
transport mid-dialog
information that has no impact on SIP itself.
Its driving
application was the transport of PSTN related
information when
using SIP between a pair of gateways. Though
originally conceived
for broader use, it only found standardized
usage with SIP-T
[24]. It has been used to support numerous
proprietary and
non-interoperable extensions due to its poorly
defined scope.
RFC 3326, The Reason header
field for SIP (S): RFC 3326 [31] defines
the Reason header
field. It is used in requests, such as BYE, to
indicate the reason
that the request is being sent.
RFC 3420, Internet Media
Type message/sipfrag (S): RFC 3420 [85]
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
During Registration (S):
RFC 3608 [32] allows a client to determine,
from a REGISTER
response, a path of proxies to use in requests it
sends outside of a
dialog. In many respects, it is the inverse of
the Path header
field, but has seen less usage since default
outbound proxies
have been sufficient in many deployments.
RFC 3841, Caller
Preferences for SIP (S): RFC 3841 [34] defines a
set of headers that
a client can include in a request to control
the way in which the
request is routed downstream. It allows a
client to direct a
request towards a UA with specific
capabilities.
RFC 4028, Session Timers in
SIP (S): RFC 4028 [35] defines a
keepalive mechanism
for SIP signaling. It is primarily meant to
provide a way to
cleanup old state in proxies that are holding
call state for calls
from failed endpoints which were never
terminated
normally. Despite its name, the session timer is not a
mechanism for
detecting a network failure mid-call. Session
timers introduces a
fair bit of complexity for relatively little
gain, and has thus
seen little deployment.
RFC 4168, SCTP as a
Transport for SIP (S): RFC 4168 [36] defines how
to carry SIP
messages over the Stream Control Transmission
Protocol
(SCTP). SCTP has seen very limited usage for SIP
transport.
RFC 4244, An Extension to
SIP for Request History Information (S):
RFC 4244 [37]
defines the History-Info header field, which
indicates
information on how a call came to be routed to a
particular
destination. Its primary application was in support of
voicemail services.
RFC 4145, TCP-Based Media
Transport in the Session Description
Protocol (SDP) (S): RFC
4145 [86] defines an extension to SDP for
setting up TCP-based
sessions between user agents. It defines who
sets up the
connection and how its lifecycle is managed. It has
seen relatively
little usage due to the small number of media
types to date which
use TCP.
RFC 4091, The Alternative
Network Address Types (ANAT) Semantics for
the Session Description Protocol (SDP) Grouping
Framework (S): RFC
4091 [87] defines a
mechanism for including both IPv4 and IPv6
addresses for a
media session as alternates.
draft-ietf-mmusic-sdp-media-capabilities-01,
SDP Media Capabilities Negotiation
(S): RFC XXXX [106]
defines an extension
to the SDP capability negotiation framework
[105] for
negotiating codecs, codec parameters, and media streams.
4. NAT Traversal
draft-ietf-mmusic-ice-17, Interactive Connectivity
Establishment (ICE) (S): RFC XXXX
[5] defines a
technique for NAT traversal of media sessions for
protocols that make
use of the offer/answer model. This
specification is the
IETF recommended mechanism for NAT traversal
for SIP media
streams, and is meant to be used even by endpoints
which are themselves
never behind a NAT. A SIP option tag and
media feature tag
RFC XXXX [108] have been defined for use with
ICE.
draft-ietf-mmusic-ice-tcp-04,
TCP Candidates with Interactive Connectivity Establishment
(ICE) (S): RFC XXXX [88]
specifies the usage of ICE for TCP streams.
This allows for
selection of RTP-based voice ontop of TCP only
when NAT or
firewalls would prevent UDP-based voice from working.
RFC 3605, Real Time Control
Protocol (RTCP) Attribute in the Session
Description Protocol (SDP) (S):
RFC 3605 [80] defines a way to
explicitly signal,
within an SDP message, the IP address and port
for RTCP, rather
than using the port+1 rule in the Real Time
Transport Protocol
(RTP) [3]. It is needed for devices behind NAT
and used by ICE.
draft-ietf-sip-outbound-10, Managing Client Initiated
Connections through SIP (S): RFC
XXXX [21], also
known as SIP outbound, defines important changes
to the SIP
registration mechanism which enable delivery of SIP
messages towards a
UA when it is behind a NAT. This specification
is the cornerstone
of the SIP NAT traversal strategy.
RFC 3581, An Extension to
SIP for Symmetric Response Routing (S):
RFC 3581 [17]
defines the rport parameter of the Via header. It
is an essential
piece of getting SIP through NAT. NAT traversal
for SIP is
considered a core part of the specifications.
draft-ietf-sip-gruu-14, 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.
5. Minor Extensions
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.
draft-ietf-sip-answermode-04,
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.
draft-ietf-sip-acr-code-05,
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.
draft-ietf-sip-multiple-refer-01,
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.
draft-ietf-mmusic-connectivity-precon-02,
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.
6.
Conferencing
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
[56] defines a
mechanism for learning about changes in conference
state, including
group membership.
draft-ietf-sip-uri-list-conferencing-01,
Conference Establishment Using
Request-Contained Lists in
SIP (S): RFC XXXX [70] is similar to
[68]. 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.
(S): RFC 4575
7.
Call Control Primitives
RFC 3515, The REFER Method
(S): REFER [45] defines a mechanism for
asking a user agent
to send a SIP request. Its a form of SIP
remote control, and
is the primary tool used for call transfer in
SIP.
RFC 3725, Best Current
Practices for Third Party Call Control (3pcc)
(B): RFC 3725 [46] defines a number of
different call flows that
allow one SIP
entity, called the controller, to create SIP
sessions amongst
other SIP user agents.
RFC 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 3891, The SIP Replaces
Header (S): RFC 3891 [47] defines a
mechanism that
allows a new dialog to replace an existing dialog.
It is useful for
certain advanced transfer services.
RFC 3892, The SIP
Referred-By Mechanism (S): RFC 3892 [48] defines
the Referred-By
header field. It is used in requests triggered by
REFER, and provides
the identity of the referring party to the
referred-to party.
RFC 4117, Transcoding
Services Invocation in SIP Using Third Party
Call Control (I): RFC 4117 [50]
defines how to use 3pcc for the
purposes of invoking
transcoding services for a call.
8.
Event Framework and Packages
RFC 3265 defines a basic
framework for event notification in SIP. It
introduces the notion of an event package, which
is a collection of
related state and event information.
Much of the state and events in
SIP systems have event packages, allowing other
entities to learn
about changes in that state.
RFC 3903, SIP Extension for
Event State Publication
[51] defines the
PUBLISH method. It is not an event package, but
is used by all event
packages as a mechanism for pushing an event
into the system.
RFC 4662, A Session
Initiation Protocol (SIP) Event Notification
Extension for Resource Lists (S): RFC 4662 [67]
defines an extension
to RFC 3265 that
allows a client to subscribe to a list of
resources using a
single subscription. The server, called a
Resource List Server
(RLS) will "expand" the subscription and
subscribe to each
individual member of the list. It has found
applicability
primarily in the area of presence, but can be used
with any event
package.
draft-ietf-sip-subnot-etags-00,
An Extension to Session Initiation
Protocol (SIP) Events
for Conditional Event Notification
(S): RFC XXXX [111] defines an
extension to RFC
3265 to optimize the performance of
notifications. When a client subscribes, it can indicate what
version of a
document it has, so that the server can skip sending
a notification if
the client is up to date. It is applicable to
any event package.
RFC 3680, A SIP Event
Package for Registrations (S): RFC 3680 [52]
defines an event
package for finding out about changes in
registration state.
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
find out about
voicemails and other messages that are waiting for
it. Its
primary purpose is to enable the voicemail waiting lamp
on most business
telephones.
RFC 3856, A Presence Event
Package for SIP (S): RFC 3856 [53]
defines an event
package for indicating user presence through SIP.
RFC 3857, A Watcher
Information Event Template Package for SIP (S):
RFC 3857 [54], also
known as winfo, provides a mechanism for a
user agent to find
out what subscriptions are in place for a
particular event
package. Its primary usage is with presence, but
it can be used with
any event package.
RFC 4235, An INVITE
Initiated Dialog Event Package for SIP (S): RFC
4235 [55] defines an
event package for learning the state of the
dialogs in progress
at a user agent, and is one of several RFCs
starting with the
important number 42 [42].
RFC 4575, A SIP Event
Package for Conference State
[56] defines a
mechanism for learning about changes in conference
state, including
group membership.
RFC 4730, A SIP Event
Package for Keypress Stimulus (KPML) (S): RFC
4730 [57] defines a
way for an application in the network to
subscribe to the set
of keypresses made on the keypad of a
traditional
telephone.
draft-ietf-sipping-rtcp-summary-02,
SIP Event Package for Voice Quality
Reporting (S): RFC
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.
draft-ietf-sipping-policy-package-03,
A Session Initiation Protocol (SIP)
Event Package for
Session-Specific Session Policies
(S): RFC XXXX [96] defines a SIP
event package that
allows a proxy to notify a user agent about its
desire for the UA to
use certain codecs or generally obey certain
media session
policies.
draft-ietf-sipping-pending-additions-02,
The Session Initiation Protocol (SIP)
Pending Additions
Event Package (S): RFC XXXX [103]
defines a SIP event package that
allows a UA to learn
whether consent has been given for the
addition of an
address to a SIP "mailing list". It is used in
conjunction with the
SIP framework for consent [101].
9.
Quality of Service
RFC 3312, Integration of
Resource Management and SIP (S): RFC 3312
[59], updated by RFC
4032 [60] defines a way to make sure that the
phone of the called
party doesn't ring until a QoS reservation has
been installed in
the network. It does so by defining a general
preconditions
framework, which defines conditions that must be
true in order for a
SIP session to proceed
RFC 3313, Private SIP
Extensions for Media Authorization (I): RFC
3313 [61] defines a
P-header that provides a mechanism for passing
an authorization
token between SIP and a network QoS reservation
protocol like
RSVP. Its purpose is to make sure network QoS is
only granted if a
client has made a SIP call through the same
providers
network. This specification is sometimes referred to as
the SIP walled
garden specification by the truly paranoid androids
in the SIP
community. This is because it requires coupling of
signaling and the
underlying IP network.
RFC 3524, Mapping of Media
Streams to Resource Reservation Flows
(S): RFC 3524 [97] defines a usage of
the SDP grouping framework for
indicating that a
set of media streams should be handled by a
single resource
reservation.
10.
Operations and Management
draft-ietf-sip-hop-limit-diagnostics-03,
Diagnostic Responses for SIP Hop Limit
Errors (S): RFC
XXXX [98] defines a
mechanism for including diagnostic information
in a 483
response. This response is sent when the hop-count of a
SIP request was
exceeded.
draft-ietf-sipping-config-framework-12,
A Framework for SIP User Agent Profile
Delivery (S): RFC
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.
draft-ietf-sipping-xcap-config-00,
Extensions to the Session Initiation Protocol
(SIP) User
Agent Profile Delivery Change Notification Event Package for the
Extensible Markup Language Language Configuration Access Protocol
(XCAP) (S): RFC XXXX [63] defines an extension
to [62] for learning
about changes in
documents managed by XCAP.
draft-ietf-sipping-rtcp-summary-02,
SIP Event Package for Voice Quality
Reporting (S): RFC
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.
11.
SIP Compression
RFC
3486, Compressing SIP
(S): RFC 3486 [64] defines a SIP URI
parameter that can
be used to indicate that a SIP server supports
Sigcomp.
12.
SIP Service URIs
RFC 3087, Control of
Service Context using Request URI (I): RFC 3087
[66] introduced the
context of using Request URIs, encoded
appropriately, to
invoke services.
RFC 4662, A SIP Event
Notification Extension for Resource Lists (S):
RFC 4662 [67]
defines a resource called a Resource List Server. A
client can send a
subscribe to this server. The server will
generate a series of
subscriptions, and compile the resulting
information and send
it back to the subscriber. The set of
resources that the
RLS will subscribe to is a property of the
request URI in the
SUBSCRIBE request.
draft-ietf-sip-uri-list-subscribe-01,
Subscriptions To Request-Contained
Resource Lists in SIP
(S): RFC XXXX [68]
allows a client to subscribe to a resource called
a Resource List
Server. This server will generate a series of
subscriptions, and
compile the resulting information and send it
back to the
subscriber. For this specification, the list of
things to subscribe
to is in the body of the SUBSCRIBE request.
draft-ietf-sip-uri-list-message-01,
Multiple-Recipient MESSAGE Requests in
SIP (S): RFC XXXX
[69] is similar to
[68]. However, instead of subscribing to the
resource, a MESSAGE
request is sent to the resource, and it will
send a copy to each
recipient.
draft-ietf-sip-uri-list-conferencing-01,
Conference Establishment Using
Request-Contained Lists in
SIP (S): RFC XXXX [70] is similar to
[68]. 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 4240, Basic Network
Media Services with SIP (I): RFC 4240 [99]
defines a way for
SIP application servers to invoke announcement
and conferencing
services from a media server. This is
accomplished through
a set of defined URI parameters which tell
the media server
what to do, such as what file to play and what
language to render
it in.
13.
Security Mechanisms
RFC 3853, S/MIME AES
Requirement for SIP (S): RFC 3853 [71] 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-04,
Certificate Management Service for The
Session Initiation
Protocol (SIP) (S): RFC XXXX [100]
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
Body (AIB) Format (S): RFC 3893 [7] defines a
SIP message fragment
which can be signed
in order to provide an authenticated identity
over a
request. It was an early predecessor to [19], and
consequently AIB has
seen no deployment.
draft-ietf-sip-saml-02,
SIP SAML Profile and Binding
(S): RFC XXXX [102] defines
the usage of the
Security Assertion Markup Language (SAML) within
SIP, and describes
how to use it in conjunction with SIP identity
[19] to provide
authenticated assertions about a users role or
attributes.
draft-ietf-sip-consent-framework-02,
A Framework for Consent-Based
Communications in the Session
Initiation Protocol (SIP) (S): RFC
XXX [101] defines several
extensions to SIP,
including the Trigger-Consent and Permission-
Missing header
fields. These header fields, in addition to the
other procedures
defined in the document, define a way to manage
membership on "SIP
mailing lists" used for instant messaging or
conferencing. In particular, it helps avoid the problem of
using
such amplification
services for the purposes of an attack on the
network, by making
sure a user authorizes the addition of their
address onto such a
service.
draft-ietf-sipping-pending-additions-02,
The Session Initiation Protocol (SIP)
Pending Additions
Event Package (S): RFC XXXX [103]
defines a SIP event package that
allows a UA to learn
whether consent has been given for the
addition of an
address to a SIP "mailing list". It is used in
conjunction with the
SIP framework for consent [101].
RFC 3329, Security
Mechanism Agreement for SIP (S): RFC 3329 [72]
defines a mechanism
to prevent bid-down attacks in conjunction
with SIP
authentication. The mechanism has seen very limited
deployment. It was defined as part of the 3gpp IMS
specification
suite [109], and is
needed only when there are a multiplicity of
security mechanisms
deployed at a particular server. In practice,
this has not been
the case.
draft-ietf-sip-e2m-sec-06,
End-to-Middle Security in SIP
(S): RFC XXXX [73] defines
mechanisms for
providing confidentiality and integrity for SIP
message bodies sent
from user agents to specific network
intermediaries.
RFC 4572,
Connection-Oriented Media Transport over the Transport
Layer Security (TLS) Protocol in the Session Description
Protocol
(SDP) (S): RFC 4572 [104] specifies a
mechanism for signaling TLS-
based media streams
between endpoints. It expands the TCP-based
media signaling
parameters defined in [86] to include fingerprint
information for TLS
streams, so that TLS can operate between end
hosts using
self-signed certificates.
draft-ietf-mmusic-securityprecondition-04,
Security Preconditions for Session
Description Protocol
Media Streams (S): RFC XXXX [92]
defines a precondition for use with
the preconditions
framework [59]. The security precondition
prevents a session
from being established until a security media
stream is set up.
14.
Instant Messaging, Presence and Multimedia
RFC 3428, SIP Extension for
Instant Messaging (S): RFC 3428 [74]
defines the MESSAGE
method, used for sending an instant message
without setting up a
session (sometimes called "page mode").
RFC 3856, A Presence Event
Package for SIP (S): RFC 3856 [53]
defines an event
package for indicating user presence through SIP.
RFC 3857, A Watcher
Information Event Template Package for SIP (S):
RFC 3857 [54], also
known as winfo, provides a mechanism for a
user agent to find
out what subscriptions are in place for a
particular event
package. Its primary usage is with presence, but
it can be used with
any event package.
draft-ietf-mmusic-file-transfer-mech-03,
A Session Description Protocol (SDP)
Offer/Answer Mechanism
to Enable File Transfer (S): RFC XXXX
[107] defines a mechanism for
signaling a file
transfer session with SIP.
15.
Emergency Services
RFC 4411, Extending the SIP
Reason Header for Preemption Events (S):
RFC 4411 [75]
defines an extension to the Reason header, allowing
a UA to know that
its dialog was torn down because a higher
priority session
came through.
RFC 4412, Communications
Resource Priority for SIP
[76] defines a new
header field, Resource-Priority, that allows a
session to get
priority treatment from the network.
16. IP Multimedia Sub-Systems
RFC 3455, Private Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) (S):
This document describes a set of private Session Initiation Protocol
(SIP) headers (P-headers) used by the 3rd-Generation Partnership
Project (3GPP), along with their applicability, which is limited to
particular environments. The P-headers are for a variety of purposes
within the networks that the partners use, including charging and
information about the networks a call traverses.
|
