RFCs related to SIP (page 2 of 4)
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4028
04/2005
(28 p.)
[html]
[pdf(2)] |
S. Donovan
J. Rosenberg |
SIP |
| Session Timers in SIP |
This document defines an extension to SIP.
This extension allows for a periodic refresh of SIP sessions
through a re-INVITE or UPDATE request. The refresh allows both user
agents and proxies to determine whether the SIP session is still
active. The extension defines two new header fields:
"Session-Expires",
which conveys the lifetime of the session, and
"Min-SE",
which conveys the minimum allowed value for the session
timer.
This document defines the 'timer' SIP option tag
and the 422 Session Interval Too Small response code.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4032
03/2005
(10 p.)
[html]
[pdf(2)] |
G. Camarillo
P. Kyzivat |
SIP |
| Update to SIP
Preconditions Framework |
|
This document updates RFC 3312,
which defines the framework for
preconditions in SIP. It provides guidelines for authors of new
precondition types and describes how to use SIP preconditions in
situations that involve session mobility.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4079
07/2005
(7 p.)
[html]
[pdf(2)] |
J. Peterson |
GEOPRIV |
|
A Presence Architecture for the Distribution of GEOPRIV Location Objects |
|
GEOPRIV defines the concept of a 'using protocol' -- a protocol that
carries GEOPRIV location objects. GEOPRIV also defines various
scenarios for the distribution of location objects that require the
concepts of subscriptions and asynchronous notifications. This
document examines some existing IETF work on the concept of presence,
shows how presence architectures map onto GEOPRIV architectures, and
moreover demonstrates that tools already developed for presence could
be reused to simplify the standardization and implementation of
GEOPRIV.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4083
05/2005
(36 p.)
[html]
[pdf(2)] |
M. Garcia-Martin |
SIPPING |
|
Input 3GPP Release 5 Requirements on SIP |
|
The 3rd-Generation Partnership Project (3GPP) has selected SIP
as the session establishment protocol for
the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of
Release 5 of the 3GPP specifications. Although SIP is a protocol
that fulfills most of the requirements for establishing a session in
an IP network, SIP has never been evaluated against the specific 3GPP
requirements for operation in a cellular network. In this document,
we express the requirements identified by 3GPP to support SIP for
Release 5 of the 3GPP IMS in cellular networks.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4092
06/2005
(6 p.)
[html]
[pdf(2)] |
G. Camarillo
J. Rosenberg |
SIP |
| Usage of SDP
Alternative Network Address Types (ANAT) Semantics
in SIP |
|
This document describes how to use the Alternative Network Address
Types (ANAT) semantics of SDP
grouping framework in SIP. In particular, we define the
'sdp-anat' SIP option tag.
This SIP option-tag ensures that SDP session
descriptions that use ANAT are only handled by SIP entities with ANAT
support. To justify the need for such a SIP option-tag, we describe
what could possibly happen if an ANAT-unaware SIP entity tried to
handle media lines grouped with ANAT.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4119
12/2005
(24 p.)
[html]
[pdf(2)] |
J. Peterson |
GEOPRIV |
|
A Presence-based GEOPRIV Location Object Format |
|
This document describes an object format for carrying geographical
information on the Internet. This location object extends the
Presence Information Data Format (PIDF), which was designed for
communicating privacy-sensitive presence information and which has
similar properties.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4122
07/2005
(32 p.)
[html]
[pdf(2)] |
P. Leach
M. Mealling
R. Salz |
- |
|
A Universally Unique IDentifier (UUID) URN Namespace |
This specification defines a Uniform Resource Name namespace for
UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
Unique IDentifier). A UUID is 128 bits long, and can guarantee
uniqueness across space and time. UUIDs were originally used in the
Apollo Network Computing System and later in the Open Software
Foundation's (OSF) Distributed Computing Environment (DCE), and then
in Microsoft Windows platforms.
This specification is derived from the DCE specification with the
kind permission of the OSF (now known as The Open Group).
Information from earlier versions of the DCE specification have been
incorporated into this document.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4123
07/2005
(16 p.)
[html]
[pdf(2)] |
H. Schulzrinne
C. Agboh |
SIP |
| SIP-H.323 Interworking Requirements |
|
This document describes the requirements for the logical entity known
as the Session Initiation Protocol (SIP)-H.323 Interworking Function
(SIP-H.323 IWF) that will allow the interworking between SIP and
H.323.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4145
09/2005
(15 p.)
[html]
[pdf(2)] |
D. Yon
G. Camarillo |
MMUSIC |
| TCP-Based Media Transport in SDP |
|
This document describes how to express media transport over TCP using
SDP. It defines the SDP 'TCP'
protocol identifier, the SDP 'setup' attribute, which describes the
connection setup procedure, and the SDP 'connection' attribute, which
handles connection reestablishment.
|
|
|
| |
| Up |
Status: | Proposed Standard -- updated by
RFC4572 |
|
|
|
|
|
|
|
|
| | | |
RFC4168
10/2005
(10 p.)
[html]
[pdf(2)] |
J. Rosenberg
H. Schulzrinne
G. Camarillo |
SIP |
| The Stream Control Transmission
Protocol (SCTP) as a Transport for SIP |
This document specifies a mechanism for usage of SCTP (the Stream
Control Transmission Protocol) as the transport mechanism between SIP
(Session Initiation Protocol) entities. SCTP is a new protocol that
provides several features that may prove beneficial for transport
between SIP entities that exchange a large amount of messages,
including gateways and proxies. As SIP is transport-independent,
support of SCTP is a relatively straightforward process, nearly
identical to support for TCP.
This RFC adds the SIPS+D2S NAPTR service field value to the registry defined in
RFC 3263.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4169
11/2005
(13 p.)
[html]
[pdf(2)] |
V. Torvinen
J. Arkko
M. Naslund |
HTTP |
| HTTP Digest Authentication using
Authentication and Key Agreement (AKA) Version-2 |
|
HTTP Digest, as specified in
RFC 2617, is known to be vulnerable to
man-in-the-middle attacks if the client fails to authenticate the
server in TLS, or if the same passwords are used for authentication
in some other context without TLS. This is a general problem that
exists not just with HTTP Digest, but also with other IETF protocols
that use tunneled authentication. This document specifies version 2
of the HTTP Digest AKA algorithm (RFC 3310).
This algorithm can be
implemented in a way that it is resistant to the man-in-the-middle
attack.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4189
10/2005
(12 p.)
[html]
[pdf(2)] |
K. Ono
S. Tachimoto |
SIPPING |
| Requirements for End-to-Middle Security for SIP |
|
A Session Initiation Protocol (SIP) User Agent (UA) does not always
trust all intermediaries in its request path to inspect its message
bodies and/or headers contained in its message. The UA might want to
protect the message bodies and/or headers from intermediaries, except
those that provide services based on its content. This situation
requires a mechanism called "end-to-middle security" to secure the
information passed between the UA and intermediaries, which does not
interfere with end-to-end security. This document defines a set of
requirements for a mechanism to achieve end-to-middle security.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4190
11/2005
(28 p.)
[html]
[pdf(2)] |
K. Carlberg
I. Brown
C. Beard |
IEPREP |
| Framework for Supporting
Emergency Telecommunications Service (ETS) in IP Telephony |
|
This document presents a framework for supporting authorized,
emergency-related communication within the context of IP telephony.
We present a series of objectives that reflect a general view of how
authorized emergency service, in line with the Emergency
Telecommunications Service (ETS), should be realized within today's
IP architecture and service models. From these objectives, we
present a corresponding set of protocols and capabilities, which
provide a more specific set of recommendations regarding existing
IETF protocols. Finally, we present two scenarios that act as
guiding models for the objectives and functions listed in this
document. These models, coupled with an example of an existing
service in the Public Switched Telephone Network (PSTN), contribute
to a constrained solution space.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4215
10/2005
(24 p.)
[html]
[pdf(2)] |
J. Wiljakka |
V6OPS |
|
Analysis on IPv6 Transition in 3GPP Networks |
This document analyzes the transition to IPv6 in Third Generation
Partnership Project (3GPP) packet networks. These networks are based
on General Packet Radio Service (GPRS) technology, and the radio
network architecture is based on Global System for Mobile
Communications (GSM) or Universal Mobile Telecommunications System
(UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
The focus is on analyzing different transition scenarios and
applicable transition mechanisms and finding solutions for those
transition scenarios. In these scenarios, the User Equipment (UE)
connects to other nodes, e.g., in the Internet, and IPv6/IPv4
transition mechanisms are needed.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4235
11/2005
(39 p.)
[html]
[pdf(2)] |
J. Rosenberg
H. Schulzrinne
R. Mahy |
SIPPING |
|
An INVITE-Initiated Dialog Event Package for SIP |
This document defines the 'dialog' event package for the SIP Events architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another
user and to receive notification of the changes in state of INVITE-initiated
dialog usages in which the subscribed-to user is involved.
This RFC registers a new MIME type, application/ dialog-info+xml.
It also registers two new Media feature tags,
sip.byeless (19) and
sip.rendering (20),
placed into the SIP Media Feature Tag Registration Tree,
which is defined in RFC 3840.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4240
12/2005
(24 p.)
[html]
[pdf(2)] |
E. Burger
J. Van Dyke
A. Spitzer |
SIPPING |
| Basic Network Media Services with SIP |
In SIP-based networks, there is a need to provide basic network media
services. Such services include network announcements, user
interaction, and conferencing services. These services are basic
building blocks, from which one can construct interesting
applications. In order to have interoperability between servers
offering these building blocks (also known as Media Servers) and
application developers, one needs to be able to locate and invoke
such services in a well defined manner.
This document describes a mechanism for providing an interoperable
interface between Application Servers, which provide application
services to SIP-based networks, and Media Servers, which provide the
basic media processing building blocks.
This specification adds new values to the IANA registration in
the "SIP/SIPS URI Parameters" registry as defined in
RFC 3969:
"play", "content-type", "delay", "duration", "repeat", "locale",
"param[n]",
and "voicexml".
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4244
11/2005
(44 p.)
[html]
[pdf(2)] |
M. Barnes |
SIP |
| An Extension to SIP
for Request History Information |
This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing
the information as to how and why a call arrives at a specific
application or user. This document defines a new optional SIP
header,
"History-Info",
for capturing the history information in
requests.
This specification defines the 'histinfo' SIP option tag.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4245
11/2005
(12 p.)
[html]
[pdf(2)] |
O. Levin
R. Even |
SIPPING |
| High-Level Requirements for Tightly Coupled SIP Conferencing |
|
This document examines a wide range of conferencing requirements for
tightly coupled SIP conferences. Separate documents will map the
requirements to existing protocol primitives, define new protocol
extensions, and introduce new protocols as needed. Together, these
documents will provide a guide for building interoperable SIP
conferencing applications.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4317
12/2005
(24 p.)
[html]
[pdf(2)] |
A. Johnston
R. Sparks |
MMUSIC |
|
SDP Offer/Answer Examples |
|
This document gives examples of Session Description Protocol (SDP)
offer/answer exchanges. Examples include codec negotiation and
selection, hold and resume, and addition and deletion of media
streams. The examples show multiple media types, bidirectional,
unidirectional, inactive streams, and dynamic payload types. Common
Third Party Call Control (3pcc) examples are also given.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4320
01/2006
(7 p.)
[html]
[pdf(2)] |
R. Sparks |
SIP |
| Actions Addressing Identified Issues with the
SIP Non-INVITE Transaction |
|
This document describes modifications to the Session Initiation
Protocol (SIP) to address problems that have been identified with the
SIP non-INVITE transaction. These modifications reduce the
probability of messages losing the race condition inherent in the
non-INVITE transaction and reduce useless network traffic. They also
improve the robustness of SIP networks when elements stop responding.
These changes update behavior defined in RFC 3261.
|
|
|
| |
| Up |
Status: | Proposed Standard -- updates
RFC3261 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4353
02/2006
(29 p.)
[html]
[pdf(2)] |
J. Rosenberg |
SIPPING |
| A Framework for Conferencing with SIP |
|
The Session Initiation Protocol (SIP) supports the initiation,
modification, and termination of media sessions between user agents.
These sessions are managed by SIP dialogs, which represent a SIP
relationship between a pair of user agents. Because dialogs are
between pairs of user agents, SIP's usage for two-party
communications (such as a phone call), is obvious. Communications
sessions with multiple participants, generally known as conferencing,
are more complicated. This document defines a framework for how such
conferencing can occur. This framework describes the overall
architecture, terminology, and protocol components needed for multi-party
conferencing.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4354
01/2006
(21 p.)
[html]
[pdf(2)] |
M. Garcia-Martin |
SIPPING |
| A SIP Event Package and Data Format
for Various Settings in Support
for the Push-to-Talk over Cellular (PoC) Service |
The Open Mobile Alliance (OMA) is defining the Push-to-talk over
Cellular (PoC) service where SIP is the protocol used to establish
half-duplex media sessions across different participants, to send
instant messages, etc. This document defines the 'poc-settings'
SIP event package to
support publication, subscription, and notification of additional
capabilities required by the PoC service. This SIP event package is
applicable to the PoC service and may not be applicable to the
general Internet.
This document registers a new MIME type, application/ poc-settings+xml.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4376
02/2006
(14 p.)
[html]
[pdf(2)] |
P. Koskelainen
J. Ott
H. Schulzrinne
X. Wu |
XCON |
| Requirements for Floor Control Protocols |
|
Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols. This
document defines the requirements for a floor control protocol for
multiparty conferences in the context of an existing framework.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4411
02/2006
(22 p.)
[html]
[pdf(2)] |
J. Polk |
SIPPING |
| Extending SIP
Reason Header for Preemption Events |
This document proposes an IANA Registration extension to the SIP Reason Header
(RFC 3326)
to be included in a BYE
Method Request as a result of a session preemption event, either at a
user agent (UA), or somewhere in the network involving a
reservation-based protocol such as the Resource ReSerVation Protocol
(RSVP) or Next Steps in Signaling (NSIS). This document does not
attempt to address routers failing in the packet path; instead, it
addresses a deliberate tear down of a flow between UAs, and informs
the terminated UA(s) with an indication of what occurred.
This RFC defines a new protocol value: Preemption to the "Reason
Protocols" sub-registry.
It also defines the
http://www.iana.org/assignments/preemption-namespace registry,
with 4 defined cause codes.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4412
02/2006
(36 p.)
[html]
[pdf(2)] |
H. Schulzrinne
J. Polk |
SIP |
| Communications Resource Priority for SIP |
This document defines two new SIP header fields for communicating
resource priority, namely
"Resource-Priority"
and
"Accept-Resource-Priority".
The "Resource-Priority" header field can influence the
behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies.
It does not directly influence the
forwarding behavior of IP routers.
This document defines the 'resource-priority' SIP option tag and
the 417 Unknown Resource-Priority Response Code.
This RFC defines two new sub-registries labeled "Resource-Priority Namespaces", and
"Resource-Priority Priority-values"
under
http://www.iana.org/assignments/sip-parameters.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4453
04/2006
(8 p.)
[html]
[pdf(2)] |
J. Rosenberg
G. Camarillo
D. Willis |
SIPPING |
| Requirements for Consent-Based Communications in SIP |
|
The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant
messaging, and presence. In its current form, it allows session
invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the
recipient. Without such consent, it is possible for SIP to be used
for malicious purposes, including spam and denial-of-service attacks.
This document identifies a set of requirements for extensions to SIP
that add consent-based communications.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4457
04/2006
(8 p.)
[html]
[pdf(2)] |
G. Camarillo
G. Blanco |
SIPPING |
|
The SIP P-User-Database Private-Header (P-Header) |
|
This document specifies the SIP
"P-User-Database"
Private-Header (P-header). This header field is used
in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia
Subsystem) to provide SIP registrars and SIP proxy servers with the
address of the database that contains the user profile of the user
that generated a particular request.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4458
04/2006
(21 p.)
[html]
[pdf(2)] |
C. Jennings
F. Audet
J. Elwell |
SIP |
| SIP URIs for Applications
such as Voicemail and Interactive Voice Response (IVR) |
The Session Initiation Protocol (SIP) is often used to initiate
connections to applications such as voicemail or interactive voice
recognition systems. This specification describes a convention for
forming SIP service URIs that request particular services based on
redirecting targets from such applications.
This specification adds two new values ("target" and "cause") to the IANA registration in
the "SIP/SIPS URI Parameters" registry as defined in
RFC 3969.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4463
04/2006
(86 p.)
[html]
[pdf(2)] |
S. Shanmugham
P. Monaco
B. Eberman |
- |
|
A Media Resource Control Protocol (MRCP)
Developed by Cisco, Nuance, and Speechworks |
The Session Initiation Protocol (SIP) is often used to initiate
This document describes a Media Resource Control Protocol (MRCP) that
was developed jointly by Cisco Systems, Inc., Nuance Communications,
and Speechworks, Inc. It is published as an RFC as input for further
IETF development in this area.
MRCP controls media service resources like speech synthesizers,
recognizers, signal generators, signal detectors, fax servers, etc.,
over a network. This protocol is designed to work with streaming
protocols like RTSP (Real Time Streaming Protocol) or SIP (Session
Initiation Protocol), which help establish control connections to
external media streaming devices, and media delivery mechanisms like
RTP (Real Time Protocol).
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4474
08/2006
(41 p.)
[html]
[pdf(2)] |
J. Peterson
C. Jennings |
SIP |
|
Enhancements for Authenticated Identity Management in SIP |
The existing security mechanisms in the Session Initiation Protocol
(SIP) are inadequate for cryptographically assuring the identity of
the end users that originate SIP requests, especially in an
interdomain context. This document defines a mechanism for securely
identifying originators of SIP messages. It does so by defining two
new SIP header fields,
"Identity",
for conveying a signature used for
validating the identity, and
"Identity-Info",
for conveying a reference to the certificate of the signer.
This RFC defines the following Response Codes: 428 Use Identity Header, 436 Bad Identity-Info, 437 Unsupported Certificate and 438 Invalid Identity Header.
This RFC also defines two new sub-registries
labeled "Identity-Info Parameters" and
"Identity-Info Algorithm Parameter Values" under http://www.iana.org/assignments/sip-parameters.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4475
05/2006
(53 p.)
[html]
[pdf(2)] |
R. Sparks
A. Hawrylyshen
A. Johnston
J. Rosenberg
H. Schulzrinne |
SIPPING |
| SIP Torture Test Messages |
|
This informational document gives examples of Session Initiation
Protocol (SIP) test messages designed to exercise and "torture" a SIP
implementation.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4479
07/2006
(35 p.)
[html]
[pdf(2)] |
J. Rosenberg |
SIMPLE |
| A Data Model for Presence |
|
This document defines the underlying presence data model used by
Session Initiation Protocol (SIP) for Instant Messaging and Presence
Leveraging Extensions (SIMPLE) presence agents. The data model
provides guidance on how to map various communications systems into
presence documents in a consistent fashion.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4480
07/2006
(37 p.)
[html]
[pdf(2)] |
H. Schulzrinne
V. Gurbani
P. Kyzivat
J. Rosenberg |
SIMPLE |
| RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF) |
The Presence Information Data Format (PIDF) defines a basic format
for representing presence information for a presentity. This format
defines a textual note, an indication of availability (open or
closed) and a Uniform Resource Identifier (URI) for communication.
The Rich Presence Information Data format (RPID) described here is an
extension that adds optional elements to the Presence Information
Data Format (PIDF). These extensions provide additional information
about the presentity and its contacts. The information is designed
so that much of it can be derived automatically, e.g., from calendar
files or user activity.
This extension includes information about what the person is doing, a
grouping identifier for a tuple, when a service or device was last
used, the type of place a person is in, what media communications
might remain private, the relationship of a service tuple to another
presentity, the person's mood, the time zone it is located in, the
type of service it offers, an icon reflecting the presentity's
status, and the overall role of the presentity.
These extensions include presence information for persons, services
(tuples), and devices.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4482
07/2006
(11 p.)
[html]
[pdf(2)] |
H. Schulzrinne |
SIMPLE |
| CIPID: Contact Information for the
Presence Information Data Format |
|
The Presence Information Data Format (PIDF) defines a basic XML
format for presenting presence information for a presentity. The
Contact Information for the Presence Information Data format (CIPID)
is an extension that adds elements to PIDF that provide additional
contact information about a presentity and its contacts, including
references to address book entries and icons.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4483
05/2006
(17 p.)
[html]
[pdf(2)] |
E. Burger |
SIP |
| A Mechanism for Content Indirection
in SIP Messages |
|
This document defines an extension to the URL MIME External-Body
Access-Type to satisfy the content indirection requirements for the
Session Initiation Protocol (SIP). These extensions are aimed at
allowing any MIME part in a SIP message to be referred to indirectly
via a URI.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4484
08/2006
(15 p.)
[html]
[pdf(2)] |
J. Peterson
J. Polk
D. Sicker
H. Tschofenig |
SIPPING |
|
Trait-Based Authorization Requirements for SIP |
|
This document lays out a set of requirements related to trait-based
authorization for the Session Initiation Protocol (SIP). While some
authentication mechanisms are described in the base SIP
specification, trait-based authorization provides information used to
make policy decisions based on the attributes of a participant in a
session. This approach provides a richer framework for
authorization, as well as allows greater privacy for users of an
identity system.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4485
05/2006
(23 p.)
[html]
[pdf(2)] |
J. Rosenberg
H. Schulzrinne |
SIP |
| Guidelines for Authors of Extensions to SIP |
|
The Session Initiation Protocol (SIP) is a flexible yet simple tool
for establishing interactive communications sessions across the
Internet. Part of this flexibility is the ease with which it can be
extended. In order to facilitate effective and interoperable
extensions to SIP, some guidelines need to be followed when
developing SIP extensions. This document outlines a set of such
guidelines for authors of SIP extensions.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4488
05/2006
(8 p.)
[html]
[pdf(2)] |
O. Levin |
SIP |
|
Suppression of SIP REFER Method Implicit Subscription |
|
The Session Initiation Protocol (SIP) REFER extension as defined in
RFC 3515
automatically establishes a typically short-lived event
subscription used to notify the party sending a REFER request about
the receiver's status in executing the transaction requested by the
REFER. These notifications are not needed in all cases. This
specification provides a way to prevent the automatic establishment
of an event subscription and subsequent notifications using a new SIP
extension
"Refer-Sub",
header field that may be included in a REFER request.
This document also registers a new SIP option tag:
'norefersub'.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4497
05/2006
(65 p.)
[html]
[pdf(2)] |
J. Elwell
F. Derks
P. Mourot
O. Rousseau |
SIPPING |
| Interworking between SIP and QSIG |
|
This document specifies interworking between the Session Initiation
Protocol (SIP) and QSIG within corporate telecommunication networks
(also known as enterprise networks). SIP is an Internet
application-layer control (signalling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include, in particular, telephone calls. QSIG is a
signalling protocol for creating, modifying, and terminating
circuit-switched calls (in particular, telephone calls) within
Private Integrated Services Networks (PISNs). QSIG is specified in a
number of Ecma Standards and published also as ISO/IEC standards.
|
|
|
| |
| Up |
Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4504
05/2006
(37 p.)
[html]
[pdf(2)] |
H. Sinnreich
S. Lass
C. Stredicke |
- |
| SIP Telephony Device
Requirements and Configuration |
This document describes the requirements for SIP telephony devices,
based on the deployment experience of large numbers of SIP phones and
PC clients using different implementations in various networks. The
objectives of the requirements are a well-defined set of
interoperability and multi-vendor-supported core features, so as to
enable similar ease of purchase, installation, and operation as found
for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the
more widely used values for some settings.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4508
05/2006
(6 p.)
[html]
[pdf(2)] |
O. Levin
A. Johnston |
SIP |
| Conveying Feature Tags with the
SIP REFER Method |
|
The SIP "Caller Preferences" extension defined in
RFC 3840 provides a
mechanism that allows a SIP request to convey information relating to
the originator's capabilities and preferences for handling of that
request. The SIP REFER method defined
in RFC 3515 provides a
mechanism that allows one party to induce another to initiate a SIP
request. This document extends the REFER method to use the mechanism
of RFC 3840.
By doing so, the originator of a REFER may inform the
recipient as to the characteristics of the target that the induced
request is expected to reach.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4538
06/2006
(17 p.)
[html]
[pdf(2)] |
J. Rosenberg |
SIP |
| Request Authorization through Dialog Identification in
SIP |
|
This specification defines the
"Target-Dialog"
header field for the
Session Initiation Protocol (SIP), and the corresponding
'tdialog' option tag.
This header field is used in requests that create SIP
dialogs. It indicates to the recipient that the sender is aware of
an existing dialog with the recipient, either because the sender is
on the other side of that dialog, or because it has access to the
dialog identifiers. The recipient can then authorize the request
based on this awareness.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4566
07/2006
(49 p.)
[html]
[pdf(2)] |
M. Handley
V. Jacobson
C. Perkins |
MMUSIC |
| SDP: Session Description Protocol |
|
This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation.
|
|
|
| |
| Up |
Status: | Proposed Standard -- obsoletes RFC2327, RFC3266 |
|
|
|
|
|
|
|
|
| | | |
RFC4567
07/2006
(30 p.)
[html]
[pdf(2)] |
J. Arkko
F. Lindholm
M. Naslund
K. Norrman
E. Carrara |
MMUSIC |
|
Key Management Extensions for SDP and RTSP |
This document defines general extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry
messages, as specified by a key management protocol, in order to
secure the media. These extensions are presented as a framework, to
be used by one or more key management protocols. As such, their use
is meaningful only when complemented by an appropriate key management
protocol.
General guidelines are also given on how the framework should be used
together with SIP and RTSP. The usage with the Multimedia Internet
KEYing (MIKEY) key management protocol is also defined.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4568
07/2006
(44 p.)
[html]
[pdf(2)] |
F. Andreasen
M. Baugher
D. Wing |
MMUSIC |
|
SDP Security Descriptions for Media Streams |
|
This document defines a Session Description Protocol (SDP)
cryptographic attribute for unicast media streams. The attribute
describes a cryptographic key and other parameters that serve to
configure security for a unicast media stream in either a single
message or a roundtrip exchange. The attribute can be used with a
variety of SDP media transports, and this document defines how to use
it for the Secure Real-time Transport Protocol (SRTP) unicast media
streams. The SDP crypto attribute requires the services of a data
security protocol to secure the SDP message.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4569
07/2006
(4 p.)
[html]
[pdf(2)] |
G. Camarillo |
SIPPING |
|
IANA Registration of the 'Message' Media Feature Tag |
This document registers with the IANA (Internet Assigned Numbers Authority) a new media feature tag
associated with the 'message' media type. This media feature tag
indicates that a particular device supports 'message' as a streaming
media type. Media feature tags can be used to route calls to devices
that support certain features.
This new Media feature tag:
sip.message (21) is
placed into the SIP Media Feature Tag Registration Tree,
which is defined in RFC 3840.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4570
07/2006
(14 p.)
[html]
[pdf(2)] |
B. Quinn
R. Finlayson |
MMUSIC |
|
SDP Source Filters |
|
This document describes how to adapt the Session Description Protocol
(SDP) to express one or more source addresses as a source filter for
one or more destination "connection" addresses. It defines the
syntax and semantics for an SDP "source-filter" attribute that may
reference either IPv4 or IPv6 address(es) as either an inclusive or
exclusive source list for either multicast or unicast destinations.
In particular, an inclusive source-filter can be used to specify a
Source-Specific Multicast (SSM) session.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
