This page lists the RFCs related to SIP. For each RFC, the following information is provided:
| |
| | - | RFCxxxx
: the RFC number is a link to the IETF's tool HTML version, which includes a link to the errata, if any | | | - | Date (month/year) | | | - | Number of pages | | | - | pdf(v)
: possibly a pdf version for viewing (unaltered content and unprintable) | | | - | pdf(p)
: a two-page printable version | | | - | Author List | | | - | Originating WG | | | - | Title
: with a link to itself, for a display at the top of the screen | | | - | RFC's Abstract, possibly modified for pointing out new METHODs
, Header Fields
, Option Tags
, Event Packages
| | | - | Status | | | - | See also (possibly) |
| | For a reminder of capitalized key words used in RFCs, click [here
]. | |
|
|
|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
3261-32xx
|
| | # RFC 3261
| SIP
| # RFC 3262
| Reliability of Provisional Responses in SIP (PRACK)
| # RFC 3263
| Locating SIP Servers
| # RFC 3264
| Offer/Answer Model with SDP
| # RFC 3265
| SIP-Specific Event Notification (SUBSCRIBE and NOTIFY)
| |
|
|
|
|
|
| | | | RFC3261
06/2002
(269 p.)
pdf(v)
pdf(p)
| J. Rosenberg
H. Schulzrinne
G. Camarillo
A. Johnston
J. Peterson
R. Sparks
M. Handley
E. Schooler | SIP
| SIP: Session Initiation Protocol
| This document describes Session Initiation Protocol
(SIP), an application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include Internet telephone calls, multimedia
distribution, and multimedia conferences.
SIP invitations used
to create sessions carry session descriptions that allow participants
to agree on a set of compatible media types. SIP makes use of elements
called proxy servers to help route requests to the user's current
location, authenticate and authorize users for services, implement
provider call-routing policies, and provide features to users. SIP also
provides a registration function that allows users to upload their
current locations for use by proxy servers. SIP runs on top of several
different transport protocols.
This RFC instructs the IANA to create four new sub-registries under
http://www.iana.org/assignments/sip-parameters
: Option Tags
, Warning Codes (warn-codes)
, Methods and Response Codes
, added to the sub-registry of Header Fields
that is already present there.
It registers the "message/sip
" MIME media type. It also registers four new Content-Disposition
header "disposition-types": alert
, icon
, session
and render
. |
|
|
| | Up
| Status: | Proposed Standard
-- updated by: RFC 3265
, RFC 3853
, RFC 4320
, RFC 4916
, RFC 5393
| |
|
|
|
|
|
|
| | | | RFC3262
06/2002
(14 p.)
pdf(v)
pdf(p)
| J. Rosenberg
H. Schulzrinne | SIP
| Reliability of Provisional Responses in SIP
| This document specifies an extension to SIP providing reliable provisional response messages. This extension uses the '100rel
' SIP option tag and defines the Provisional Response ACKnowledgement ("PRACK
") method. Each provisional response is given a sequence number, carried in the "RSeq
" header field. The PRACK messages contain an "RAck
" header field, which indicates the sequence number of the provisional response that is being acknowledged. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3263
06/2002
(17 p.)
pdf(v)
pdf(p)
| J. Rosenberg
H. Schulzrinne | SIP
| Locating SIP Servers
| SIP uses DNS procedures to allow a client to resolve
a SIP Uniform Resource Identifier (URI) into the IP address, port, and
transport protocol of the next hop to contact. It also uses DNS to
allow a server to send a response to a backup client if the primary
client has failed. This document describes those DNS procedures in
detail.
This RFC defines the " Registry for the SIP SRV Resource Record Services Field
" and places the following NAPTR service field values: SIP+D2T
, SIPS+D2T
, SIP+D2U
, SIP+D2S
. |
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 2782
, RFC 3401
, RFC 3402
, RFC 3403
, RFC 3404
| |
|
|
|
|
| | | | RFC3264
06/2002
(25 p.)
pdf(v)
pdf(p)
| J. Rosenberg
H. Schulzrinne | MMUSIC
| An Offer/Answer Model with SDP
| This document defines a mechanism by which two
entities can make use of SDP to arrive at a common view of a multimedia
session between them. In the model, one participant offers the other a
description of the desired session from their perspective, and the
other participant answers with the desired session from their
perspective. This offer/answer model is most useful in unicast sessions
where information from both participants is needed for the complete
view of the session. The offer/answer model is used by protocols like
SIP. |
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 4317
| |
|
|
|
|
| | | | RFC3265
06/2002
(38 p.)
pdf(v)
pdf(p)
| A. B. Roach | SIP
| SIP - Specific Event Notification
| This document describes an extension to SIP. The
purpose of this extension is to provide an extensible framework by
which SIP nodes can request notification from remote nodes indicating
that certain events have occurred. The "SUBSCRIBE
" and "NOTIFY
"
methods described in this document provide a framework by which
notification of these events can be ordered. This document does not
describe an extension which may be used directly; it must be extended
by other documents, referred to as "event packages".
This document defines the "Event
", "Allow-Events
", and "Subscription-State
" header fields. |
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 3515
('refer
'
package)
RFC 3680
('reg
'
package)
RFC 3842
('message-summary
'
package)
RFC 3856
('presence
'
package)
RFC 3857
('winfo
'
template-package)
RFC 3910
('spirits-INDPs
'
and 'spirits-user-prof
'
packages)
RFC 4235
('dialog
'
package)
RFC 4354
('poc-settings
'
package)
RFC 4575
('conference
'
package)
RFC 4730
('kpml
'
package)
RFC 5362
('consent-pending-additions
'
package)
RFC 3903
('PUBLISH
'
method) | |
|
|
|
|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
33xx
|
| | # RFC 3303
| MIDCOM Architecture and Framework
| # RFC 3310
| HTTP Digest Authentication Using AKA
| # RFC 3311
| SIP UPDATE Method
| # RFC 3312
| Integration of Resource Management and SIP
| # RFC 3313
| Private SIP Extensions for Media Authorization
| # RFC 3314
| Recommendations for IPv6 in 3GPP Standards
| # RFC 3319
| DHCPv6 Options for SIP Servers
| # RFC 3320
| Signaling Compression (SigComp)
| # RFC 3321
| SigComp - Extended Operations
| # RFC 3322
| SigComp Requirements & Assumptions
| # RFC 3323
| Privacy Mechanism for SIP
| # RFC 3324
| Requirements for Network Asserted Identity
| # RFC 3325
| SIP Asserted Identity
| # RFC 3326
| Reason Header Field for SIP
| # RFC 3327
| Path Extension Header Field for SIP
| # RFC 3329
| SIP Security Agreement
| # RFC 3351
| SIP for Deaf, Hard of Hearing and Speech Impaired
| # RFC 3361
| DHCPv4 Option for SIP Servers
| # RFC 3372
| SIP-T
| # RFC 3388
| Grouping of Media Lines in SDP
| # RFC 3398
| ISUP to SIP Mapping
| |
|
|
|
|
|
| | | | RFC3303
08/2002
(34 p.)
pdf(p)
| P. Srisuresh
J. Kuthan
J. Rosenberg
A. Molitor
A. Rayhan | MIDCOM | Middlebox communication architecture and framework
| A principal objective of this document is to describe
the underlying framework of middlebox communications (MIDCOM) to enable
complex applications through the middleboxes, seamlessly using a
trusted third party.
There are a variety of intermediate devices in
the Internet today that require application intelligence for their
operation. Datagrams pertaining to real-time streaming applications,
such as SIP and H.323, and peer-to-peer applications, such as Napster
and NetMeeting, cannot be identified by merely examining packet
headers. Middleboxes implementing Firewall and Network Address
Translator services typically embed application intelligence within the
device for their operation. The document specifies an architecture and
framework in which trusted third parties can be delegated to assist the
middleboxes to perform their operation, without resorting to embedding
application intelligence. Doing this will allow a middlebox to continue
to provide the services, while keeping the middlebox application
agnostic. |
|
|
|
|
|
|
| | | | RFC3310
09/2002
(18 p.)
pdf(v)
pdf(p)
| A. Niemi
J. Arkko
V. Torvinen | SIP
| HTTP Digest Authentication using AKA
| This memo specifies an Authentication and Key
Agreement (AKA) based one-time password generation mechanism for
Hypertext Transfer Protocol (HTTP) Digest access authentication. The
HTTP Authentication Framework includes two authentication schemes:
Basic and Digest. Both schemes employ a shared secret based mechanism
for access authentication. The AKA mechanism performs user
authentication and session key distribution in Universal Mobile
Telecommunications System (UMTS) networks. AKA is a challenge-response
based mechanism that uses symmetric cryptography.
This RFC defines the " AKA-Version Namespace
" IANA Registry and places the AKAv1
value. |
|
|
| | Up
| Status: | Informational | | See also: | RFC 2617
, RFC 4169
| |
|
|
|
|
| | | | RFC3311
09/2002
(13 p.)
pdf(v)
pdf(p)
| J. Rosenberg | SIP
| SIP UPDATE Method
| This specification defines the new "UPDATE
"
method for SIP. UPDATE allows a client to update parameters of a
session (such as the set of media streams and their codecs) but has no
impact on the state of a dialog. In that sense, it is like a re-INVITE,
but unlike re-INVITE, it can be sent before the initial INVITE has been
completed. This makes it very useful for updating session parameters
within early dialogs. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3312
10/2002
(30 p.)
pdf(p)
| G. Camarillo
W. Marshall
J. Rosenberg | SIP
| Integration of Resource Management and SIP
| This document defines a generic framework for
preconditions, which are extensible through IANA registration. This
document also discusses how network quality of service can be made a
precondition for establishment of sessions initiated by SIP. These
preconditions require that the participant reserve network resources
before continuing with the session. We do not define new quality of
service reservation mechanisms; these preconditions simply require a
participant to use existing resource reservation mechanisms before
beginning the session.
This document defines the 'precondition
' SIP option tag. |
|
|
| | Up
| Status: | Proposed Standard -- updated by: RFC 4032
, RFC 5027
| |
|
|
|
|
| | | | RFC3313
01/2003
(16 p.)
pdf(p)
| W. Marshall | SIP
| Private SIP Extensions for Media Authorization
| This document describes the need for Quality of
Service (QoS) and media authorization and defines a SIP extension that
can be used to integrate QoS admission control with call signaling and
help guard against denial of service attacks. The use of this extension
is only applicable in administrative domains, or among federations of
administrative domains with previously agreed-upon policies, where both
the SIP proxy authorizing the QoS, and the policy control of the
underlying network providing the QoS, belong to that administrative
domain or federation of domains.
This document defines the "P-Media-Authorization
" header field. |
|
|
|
|
|
|
| | | | RFC3314
09/2002
(23 p.)
pdf(p)
| M. Wasserman | IPV6 | Recommendations for IPv6 in 3GPP Standards
| This document contains recommendations from the
Internet Engineering Task Force (IETF) IPv6 Working Group to the Third
Generation Partnership Project (3GPP) community regarding the use of
IPv6 in the 3GPP standards. Specifically, this document recommends that
the 3GPP specify that multiple prefixes may be assigned to each primary
PDP context, require that a given prefix must not be assigned to more
than one primary PDP context, and allow 3GPP nodes to use multiple
identifiers within those prefixes, including randomly generated
identifiers.
The IPv6 Working Group supports the use of IPv6
within 3GPP and offers these recommendations in a spirit of open
cooperation between the IPv6 Working Group and the 3GPP community.
Since the original publication of this document as an Internet-Draft,
the 3GPP has adopted the primary recommendations of this document. |
|
|
|
|
|
|
| | | | RFC3319
07/2003
(7 p.)
pdf(p)
| H. Schulzrinne
B. Volz | SIP
| Dynamic Host Configuration Protocol (DHCPv6) Options for SIP Servers
| This document defines a Dynamic Host Configuration
Protocol version 6 (DHCPv6) option that contains a list of domain names
or IPv6 addresses that can be mapped to one or more SIP outbound proxy
servers. This is one of the many methods that a SIP client can use to
obtain the addresses of such a local SIP server. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3320
01/2003
(62 p.)
pdf(p)
| R. Price
C. Bormann
J. Christoffersson
H. Hannu
Z. Liu
J. Rosenberg | ROHC | Signaling Compression (SigComp)
| This document defines Signaling Compression
(SigComp), a solution for compressing messages generated by application
protocols such as SIP and the Real Time Streaming Protocol (RTSP). The
architecture and prerequisites of SigComp are outlined, along with the
format of the SigComp message.
Decompression functionality for
SigComp is provided by a Universal Decompressor Virtual Machine (UDVM)
optimized for the task of running decompression algorithms. The UDVM
can be configured to understand the output of many well-known
compressors such as DEFLATE (RFC 1951
). |
|
|
| | Up
| Status: | Proposed Standard -- updated by: RFC 4896
| |
|
|
|
|
| | | | RFC3321
01/2003
(19 p.)
pdf(p)
| H. Hannu
J. Christoffersson
S. Forsgren
K.-C. Leung
Z. Liu
R. Price | ROHC | Signaling Compression (SigComp) - Extended Operations
| This document describes how to implement certain mechanisms in Signaling Compression (SigComp), RFC 3320
, which can significantly improve the compression efficiency compared to using simple per-message compression.
SigComp
uses a Universal Decompressor Virtual Machine (UDVM) for decompression,
and the mechanisms described in this document are possible to implement
using the UDVM instructions defined in RFC 3320
. |
|
|
| | Up
| Status: | Informational -- updated by: RFC 4896
| |
|
|
|
|
| | | | RFC3322
01/2003
(13 p.)
pdf(p)
| H. Hannu | ROHC | Signaling Compression (SigComp) Requirements & Assumptions
| The purpose of this document is to outline
requirements and motivations for the development of a scheme for
compression and decompression of messages from signaling protocols. In
wireless environments and especially in cellular systems, e.g., GSM
(Global System for Mobile communications) and UMTS (Universal Mobile
Telecommunications System), there is a need to maximize the transport
efficiency for data over the radio interface. With the introduction of
SIP/SDP to cellular devices, compression of the signaling messages
should be considered in order to improve both service availability and
quality, mainly by reducing the user idle time, e.g., at call setup. |
|
|
|
|
|
|
| | | | RFC3323
11/2002
(22 p.)
pdf(v)
pdf(p)
| J. Peterson | SIP
| A Privacy Mechanism for SIP
| This document defines new mechanisms for SIP in
support of privacy. Specifically, guidelines are provided for the
creation of messages that do not divulge personal identity information.
A new "privacy service" logical role for intermediaries is defined to
answer some privacy requirements that user agents cannot satisfy
themselves. Finally, means are presented by which a user can request
particular functions from a privacy service.
This document defines the "Privacy
" header field. It also defines the 'privacy
' SIP option tag. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3324
11/2002
(11 p.)
pdf(p)
| M. Watson | SIPPING
| Short Term Requirements for Network Asserted Identity
| A Network Asserted Identity is an identity initially
derived by a SIP network intermediary as a result of an authentication
process. This document describes short term requirements for the
exchange of Network Asserted Identities within networks of securely
interconnected trusted nodes and to User Agents securely connected to
such networks. There is no requirement for identities asserted by a UA
in a SIP message to be anything other than the user's desired alias. |
|
|
|
|
|
|
| | | | RFC3325
11/2002
(18 p.)
pdf(v)
pdf(p)
| C. Jennings
J. Peterson
M. Watson | SIP
| Private Extensions to SIP for Asserted Identity within Trusted Networks
| This document describes private extensions to SIP
that enable a network of trusted SIP servers to assert the identity of
authenticated users, and the application of existing privacy mechanisms
to the identity problem. The use of these extensions is only applicable
inside an administrative domain with previously agreed-upon policies
for generation, transport and usage of such information. This document
does NOT offer a general privacy or identity model suitable for use
between different trust domains, or use in the Internet at large.
This document defines the "P-Asserted-Identity
" and "P-Preferred-Identity
" header fields. |
|
|
|
|
|
|
| | | | RFC3326
12/2002
(8 p.)
pdf(p)
| H. Schulzrinne
D. Oran
G. Camarillo | SIP
| The Reason Header Field for SIP
| For creating services, it is often useful to know why a SIP request was issued. This document defines the "Reason
"
header field that provides this information. The Reason header field is
also intended to be used to encapsulate a final status code in a
provisional response. This functionality is needed to resolve the
"Heterogeneous Error Response Forking Problem", or HERFP.
This RFC defines a new sub-registry
under http://www.iana.org/ assignments/sip-parameters
, labeled "Reason Protocols
", for registering the "SIP
" and "Q.850
" protocol values (and their associated protocol cause) to be used with the Reason header field. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3327
12/2002
(17 p.)
pdf(v)
pdf(p)
| D. Willis
B. Hoeneisen | SIP
| SIP Extension Header Field for Registering Non-Adjacent Contacts
| The REGISTER function is used in a SIP system primarily to associate a temporary contact address with an address-of-record.
This
contact is generally in the form of a Uniform Resource Identifier
(URI), such as Contact: <sip:alice@pc33.atlanta.com> and is
generally dynamic and associated with the IP address or hostname of the
SIP User Agent (UA). The problem is that network topology may have one
or more SIP proxies between the UA and the registrar, such that any
request traveling from the user's home network to the registered UA
must traverse these proxies. The REGISTER method does not give us a
mechanism to discover and record this sequence of proxies in the
registrar for future use.
This document defines an extension header field, "Path
" which provides such a mechanism. The associated SIP option tag is 'path
'. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3329
01/2003
(24 p.)
pdf(v)
pdf(p)
| J. Arkko
V. Torvinen
G. Camarillo
A. Niemi
T. Haukka | SIP
| Security Mechanism Agreement for SIP
| This document defines new functionality for
negotiating the security mechanisms used between a SIP user agent and
its next-hop SIP entity. This new functionality supplements the
existing methods of choosing security mechanisms between SIP entities.
This document defines the "Security-Client
", "Security-Server
", and "Security-Verify
" header fields. It also defines the 'sec-agree
' SIP option tag. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3351
08/2002
(17 p.)
pdf(p)
| N. Charlton
M. Gasson
G. Gybels
M. Spanner
A. van Wijk | SIPPING
| User Requirements for SIP in Support of Deaf, Hard of Hearing and Speech-impaired Individuals
| This document presents a set of SIP user requirements
that support communications for deaf, hard of hearing and
speech-impaired individuals. These user requirements address the
current difficulties of deaf, hard of hearing and speech-impaired
individuals in using communications facilities, while acknowledging the
multi-functional potential of SIP-based communications. A number of
issues related to these user requirements are further raised in this
document. Also included are some real world scenarios and some
technical requirements to show the robustness of these requirements on
a concept-level. |
|
|
|
|
|
|
| | | | RFC3361
08/2002
(7 p.)
pdf(p)
| H. Schulzrinne | SIP
| Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for SIP Servers
| This document defines a Dynamic Host Configuration
Protocol (DHCP-for-IPv4) option that contains a list of domain names or
IPv4 addresses that can be mapped to one or more SIP outbound proxy
servers. This is one of the many methods that a SIP client can use to
obtain the addresses of such a local SIP server. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3372
09/2002
(23 p.)
pdf(p)
| A. Vemuri
J. Peterson | SIPPING
| SIP for Telephones (SIP-T): Context and Architectures
| The popularity of gateways that interwork between the
PSTN (Public Switched Telephone Network) and SIP networks has motivated
the publication of a set of common practices that can assure consistent
behavior across implementations. This document taxonomizes the uses of
PSTN-SIP gateways, provides uses cases, and identifies mechanisms
necessary for interworking. The mechanisms detail how SIP provides for
both 'encapsulation' (bridging the PSTN signaling across a SIP network)
and 'translation' (gatewaying). |
|
|
| | Up
| Status: | Best Current Practice (BCP: 63) | |
|
|
|
|
| | | | RFC3388
12/2002
(21 p.)
pdf(p)
| G. Camarillo
G. Eriksson
J. Holler
H. Schulzrinne | MMUSIC
| Grouping of Media Lines in SDP
| This document defines two SDP attributes: "group" and
"mid". They allow to group together several "m" lines for two different
purposes: for lip synchronization and for receiving media from a single
flow (several media streams) that are encoded in different formats
during a particular session, on different ports and host interfaces. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3398
12/2002
(68 p.)
pdf(v)
pdf(p)
| G. Camarillo
A. B. Roach
J. Peterson
L. Ong | SIPPING
| ISUP to SIP Mapping
| This document describes a way to perform the mapping
between two signaling protocols: SIP and the Integrated Services
Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7
(SS7). This mechanism might be implemented when using SIP in an
environment where part of the call involves interworking with the
Public Switched Telephone Network (PSTN). |
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 3578
| |
|
|
|
|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
34xx
|
| | # RFC 3401
| DDDS - The Comprehensive DDDS
| # RFC 3402
| DDDS - The Algorithm
| # RFC 3403
| DDDS - DNS Database
| # RFC 3404
| DDDS - URI Resolution Application
| # RFC 3420
| Internet Media Type message/sipfrag
| # RFC 3427
| Change Process for SIP
| # RFC 3428
| SIP Extension for Instant Messaging (MESSAGE)
| # RFC 3455
| 3GPP SIP P-Header Extensions
| # RFC 3485
| SIP and SDP Static Dictionary for SigComp
| # RFC 3486
| Compressing SIP
| # RFC 3487
| IEPREP SIP Requirements
| |
|
|
|
|
|
| | | | RFC3401
10/2002
(6 p.)
pdf(v)
pdf(p)
| M. Mealling | - | Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS
| This document specifies the exact documents that make
up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an
abstract algorithm for applying dynamically retrieved string
transformation rules to an application-unique string.
This document along with RFC 3402
, RFC 3403
and RFC 3404
obsolete RFC 2168
and RFC 2915
, as well as updates RFC 2276
. |
|
|
|
|
|
|
| | | | RFC3402
10/2002
(17 p.)
pdf(v)
pdf(p)
| M. Mealling | - | Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm
| This document describes the Dynamic Delegation
Discovery System (DDDS) algorithm for applying dynamically retrieved
string transformation rules to an application-unique string.
Well-formed transformation rules will reflect the delegation of
management of information associated with the string. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3403
10/2002
(14 p.)
pdf(v)
pdf(p)
| M. Mealling | - | Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database
| This document describes a Dynamic Delegation
Discovery System (DDDS) Database using the Domain Name System (DNS) as
a distributed database of Rules. The Keys are domain-names and the
Rules are encoded using the Naming Authority Pointer (NAPTR) Resource
Record (RR). Since this document obsoletes RFC 2915
, it is the official specification for the NAPTR DNS Resource Record. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3404
10/2002
(18 p.)
pdf(v)
pdf(p)
| M. Mealling | - | Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI) Resolution Application
| This document describes a specification for taking
Uniform Resource Identifiers (URI) and locating an authoritative server
for information about that URI. The method used to locate that
authoritative server is the Dynamic Delegation Discovery System. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3420
11/2002
(8 p.)
pdf(p)
| R. Sparks | SIP
| Internet Media Type message/sipfrag
| This document registers the message/sipfrag
Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip
,
but allows certain subsets of well formed SIP messages to be
represented instead of requiring a complete SIP message. In addition to
end-to-end security uses, message/sipfrag
is used with the REFER
method to convey information about the status of a referenced request. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3427
12/2002
(12 p.)
pdf(p)
| A. Mankin
S. Bradner
R. Mahy
D. Willis
J. Ott
B. Rosen | TSV area | Change Process for SIP
| This memo documents a process intended to apply
architectural discipline to the future development of SIP. There have
been concerns with regards to new SIP proposals. Specifically, that the
addition of new SIP features can be damaging towards security and/or
greatly increase the complexity of the protocol. The Transport Area
directors, along with the SIP and Session Initiation Proposal
Investigation (SIPPING) working group chairs, have provided suggestions
for SIP modifications and extensions. |
|
|
| | Up
| Status: | Best Current Practice (BCP: 67) -- updated by: RFC 3968
, RFC 3969
| |
|
|
|
|
| | | | RFC3428
12/2002
(18 p.)
pdf(v)
pdf(p)
| B. Campbell
J. Rosenberg
H. Schulzrinne
C. Huitema
D. Gurle | SIP
| SIP Extension for Instant Messaging
| Instant Messaging (IM) refers to the transfer of
messages between users in near real-time. These messages are usually,
but not required to be, short. IMs are often used in a conversational
mode, that is, the transfer of messages back and forth is fast enough
for participants to maintain an interactive conversation.
This document proposes the "MESSAGE
"
method, an extension to SIP that allows the transfer of Instant
Messages. Since the MESSAGE request is an extension to SIP, it inherits
all the request routing and security features of that protocol. MESSAGE
requests carry the content in the form of MIME body parts. MESSAGE
requests do not themselves initiate a SIP dialog; under normal usage
each Instant Message stands alone, much like pager messages. MESSAGE
requests may be sent in the context of a dialog initiated by some other
SIP request. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3455
01/2003
(34 p.)
pdf(v)
pdf(p)
| M. Garcia-Martin
E. Henrikson
D. Mills | SIPPING
| Private Header (P-Header) Extensions to SIP for the 3GPP
| This document describes a set of private 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.
This document defines the "P-Associated-URI
", "P-Called-Party-ID
", "P-Visited-Network-ID
", "P-Access-Network-Info
", "P-Charging-Function- Addresses
", and "P-Charging-Vector
" header fields. |
|
|
|
|
|
|
| | | | RFC3485
02/2003
(30 p.)
pdf(p)
| M. Garcia-Martin
C. Bormann
J. Ott
R. Price
A. B. Roach | SIPPING
| SIP and SDP Static Dictionary for Signaling Compression (SigComp)
| SIP is a text-based protocol for initiating and
managing communication sessions. The protocol can be compressed by
using Signaling Compression (SigComp). Similarly, SDP is a text-based
protocol intended for describing multimedia sessions for the purposes
of session announcement, session invitation, and other forms of
multimedia session initiation. This memo defines the SIP/SDP-specific
static dictionary that SigComp may use in order to achieve higher
efficiency. The dictionary is compression algorithm independent. |
|
|
| | Up
| Status: | Proposed Standard -- updated by: RFC 4896
| |
|
|
|
|
| | | | RFC3486
02/2003
(12 p.)
pdf(p)
| G. Camarillo | SIP
| Compressing SIP
| This document describes a mechanism to signal that
compression is desired for one or more SIP messages. It also states
when it is appropriate to send compressed SIP messages to a SIP entity.
|
|
|
| | Up
| Status: | Proposed Standard -- updated by: RFC 5049
| |
|
|
|
|
| | | | RFC3487
02/2003
(17 p.)
pdf(p)
| H. Schulzrinne | IEPREP | Requirements for Resource Priority Mechanisms for SIP
| This document summarizes requirements for
prioritizing access to circuit-switched network, end system and proxy
resources for emergency preparedness communications using SIP. |
|
|
|
|
|
|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
35xx
|
| | # RFC 3515
| SIP REFER Method
| # RFC 3524
| Mapping Media Streams to Resource Reservation Flows
| # RFC 3574
| Transition Scenarios for 3GPP Networks
| # RFC 3578
| ISUP Overlap Signalling to SIP
| # RFC 3581
| Symmetric Response Routing
| |
|
|
|
|
|
| | | | RFC3515
04/2003
(23 p.)
pdf(v)
pdf(p)
| R. Sparks | SIP
| The SIP Refer Method
| This document defines the "REFER
"
method. This SIP extension requests that the recipient REFER to a
resource provided in the request. It provides a mechanism allowing the
party sending the REFER to be notified of the outcome of the referenced
request. This can be used to enable many applications, including call
transfer. In addition to the REFER method, this document defines the 'refer
' event package and the "Refer-To
" request header. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3524
04/2003
(6 p.)
pdf(p)
| G. Camarillo
A. Monrad | MMUSIC
| Mapping of Media Streams to Resource Reservation Flows
| This document defines an extension to SDP grouping
framework. It allows requesting a group of media streams to be mapped
into a single resource reservation flow. The SDP syntax needed is
defined, as well as a new "semantics" attribute called Single
Reservation Flow (SRF). |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3574
08/2003
(12 p.)
pdf(p)
| J. Soininen | V6OPS | Transition Scenarios for 3GPP Networks
| This document describes different scenarios in Third
Generation Partnership Project (3GPP) defined packet network, i.e.,
General Packet Radio Service (GPRS) that would need IP version 6 and IP
version 4 transition. The focus of this document is on the scenarios
where the User Equipment (UE) connects to nodes in other networks,
e.g., in the Internet. GPRS network internal transition scenarios,
i.e., between different GPRS elements in the network, are out of scope.
The purpose of the document is to list the scenarios for further
discussion and study. |
|
|
|
|
|
|
| | | | RFC3578
08/2003
(13 p.)
pdf(v)
pdf(p)
| G. Camarillo
A. B. Roach
J. Peterson
L. Ong | SIPPING
| Mapping of ISUP Overlap Signalling to SIP
| This document describes a way to map Integrated
Services Digital Network User Part (ISUP) overlap signalling to SIP.
This mechanism might be implemented when using SIP in an environment
where part of the call involves interworking with the Public Switched
Telephone Network (PSTN). |
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 3398
| |
|
|
|
|
| | | | RFC3581
08/2003
(13 p.)
pdf(p)
| J. Rosenberg
H. Schulzrinne | SIP
| An Extension to SIP for Symmetric Response Routing
| SIP operates over UDP and TCP, among others. When
used with UDP, responses to requests are returned to the source address
the request came from, and to the port written into the topmost Via
header field value of the request. This behavior is not desirable in
many cases, most notably, when the client is behind a Network Address
Translator (NAT). This extension defines a new parameter for the Via
header field, called "rport", that allows a client to request that the
server send the response back to the source IP address and port from
which the request originated. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
36xx
|
| | # RFC 3605
| RTCP attribute in SDP
| # RFC 3608
| SIP Extension for Service Route Discovery
| # RFC 3665
| SIP Basic Call Flow Examples
| # RFC 3666
| SIP PSTN Call Flows
| # RFC 3680
| SIP Registrations Event
| # RFC 3693
| Geopriv Requirements
| # RFC 3694
| Threat Analysis of the Geopriv Protocol
| |
|
|
|
|
|
| | | | RFC3605
10/2003
(8 p.)
pdf(p)
| C. Huitema | MMUSIC
| Real Time Control Protocol (RTCP) attribute in SDP
| SDP is used to describe the parameters of media
streams used in multimedia sessions. When a session requires multiple
ports, SDP assumes that these ports have consecutive numbers. However,
when the session crosses a network address translation device that also
uses port mapping, the ordering of ports can be destroyed by the
translation. To handle this, we propose an extension attribute to SDP. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3608
10/2003
(17 p.)
pdf(v)
pdf(p)
| D. Willis
B. Hoeneisen | SIP
| SIP Extension Header Field for Service Route Discovery During Registration
| This document defines a SIP extension header field ("Service-Route
")
used in conjunction with responses to REGISTER requests to provide a
mechanism by which a registrar may inform a registering user agent (UA)
of a service route that the UA may use to request outbound services
from the registrar's domain. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3665
12/2003
(94 p.)
pdf(p)
| A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers | SIPPING
| SIP Basic Call Flow Examples
| This document gives examples of Session
Initiation Protocol (SIP) call flows. Elements in these call flows
include SIP User Agents and Clients, SIP Proxy and Redirect Servers.
Scenarios include SIP Registration and SIP session establishment. Call
flow diagrams and message details are shown. |
|
|
| | Up
| Status: | Best Current Practice (BCP: 75) | | See also: | Illustrated Basic Call Flows
| |
|
|
|
|
| | | | RFC3666
12/2003
(118 p.)
pdf(p)
| A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers | SIPPING
| SIP Public Switched Telephone Network (PSTN) Call Flows
| This document contains best current practice examples
of SIP call flows showing interworking with the Public Switched
Telephone Network (PSTN). Elements in these call flows include SIP User
Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to
PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols
are illustrated using ISDN (Integrated Services Digital Network), ISUP
(ISDN User Part), and FGB (Feature Group B) circuit associated
signaling. PSTN calls are illustrated using global telephone numbers
from the PSTN and private extensions served on by a PBX (Private Branch
Exchange). Call flow diagrams and message details are shown. |
|
|
| | Up
| Status: | Best Current Practice (BCP: 76) | | See also: | Illustrated SIP PSTN Call Flows
| |
|
|
|
|
| | | | RFC3680
03/2004
(26 p.)
pdf(v)
pdf(p)
| J. Rosenberg | SIPPING
| A SIP Event Package for Registrations
| This document defines the 'reg
'
SIP event package for registrations. Through its REGISTER method, SIP
allows a user agent to create, modify, and delete registrations.
Registrations can also be altered by administrators in order to enforce
policy. As a result, these registrations represent a piece of state in
the network that can change dynamically. There are many cases where a
user agent would like to be notified of changes in this state. This
event package defines a mechanism by which those user agents can
request and obtain such notifications.
This document registers a new MIME type, application/reginfo+xml
. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3693
02/2004
(30 p.)
pdf(p)
| J. Cuellar
J. Morris
D. Mulligan
J. Peterson
J. Polk | GEOPRIV
| Geopriv Requirements
| Location-based services, navigation applications,
emergency services, management of equipment in the field, and other
location-dependent services need geographic location information about
a Target (such as a user, resource or other entity). There is a need to
securely gather and transfer location information for location
services, while at the same time protect the privacy of the individuals
involved.
This document focuses on the authorization, security and
privacy requirements for such location-dependent services.
Specifically, it describes the requirements for the Geopriv Location
Object (LO) and for the protocols that use this Location Object. This
LO is envisioned to be the primary data structure used in all Geopriv
protocol exchanges to securely transfer location data. |
|
|
|
|
|
|
| | | | RFC3694
02/2004
(18 p.)
pdf(p)
| M. Danley
D. Mulligan
J. Morris
J. Peterson | GEOPRIV
| Threat Analysis of the Geopriv Protocol
| This document provides some analysis of threats
against the Geopriv protocol architecture. It focuses on protocol
threats, threats that result from the storage of data by entities in
the architecture, and threats posed by the abuse of information yielded
by Geopriv. Some security properties that meet these threats are
enumerated as a reference for Geopriv requirements. |
|
|
|
