|
|
|
|
|
|
RFCs related to SIP
|
|
|
|
|
|
|
|
|
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 text version
|
|
| - |
Date (month/year)
|
|
| - |
Number of pages
|
|
| - |
[html]: link to IETF's tool HTML version, which includes a link to the errata, if any
|
|
| - |
[pdf(2)]: a link to the PDF version, 2 pages per sheet -- for optimal printing -- with "fit in window" initial viewing option
|
|
| - |
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
|
|
|
|
For a reminder of capitalized key words used in RFCs, click
[here].
|
|
|
|
SIP is based on an HTTP-like request/response transaction model
and,
although SIP is NOT an extension of HTTP, RFC 3261 refers to
sections of HTTP/1.1 specification (RFC 2616) for the syntax
and semantic of many SIP message fields.
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3261
06/2002
(269 p.)
[html]
[pdf(2)] |
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.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3262
06/2002
(14 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
| | | |
RFC3264
06/2002
(25 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
| | | |
RFC3265
06/2002
(38 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3303
08/2002
(34 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
A. Niemi
J. Arkko
V. Torvinen |
SIP |
| HTTP Digest Authentication
using Authentication and Key Agreement (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.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3311
09/2002
(13 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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
RFC4032 |
|
|
|
|
|
|
|
|
| | | |
RFC3313
01/2003
(16 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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 (RFC1951).
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC3321
01/2003
(19 p.)
[html]
[pdf(2)] |
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), RFC3320, 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 RFC3320.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3322
01/2003
(13 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC3372
09/2002
(23 p.)
[html]
[pdf(2)] |
A. Vemuri
J. Peterson |
SIPPING |
| Session Initiation Protocol 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 |
|
|
|
|
|
|
|
|
| | | |
RFC3388
12/2002
(21 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3420
11/2002
(8 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3428
12/2002
(18 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3485
02/2003
(30 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
| | | |
RFC3486
02/2003
(12 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3489
03/2003
(47 p.)
[html]
[pdf(2)] |
J. Rosenberg
J. Weinberger
C. Huitema
R. Mahy |
MIDCOM |
| STUN - Simple Traversal of User Datagram Protocol (UDP)
through Network Address Translators (NATs) |
|
STUN is a lightweight protocol that
allows applications to discover the presence and types of NATs and
firewalls between them and the public Internet. It also provides the
ability for applications to determine the public
IP addresses allocated to them by the NAT. STUN works with many
existing NATs, and does not require any special behavior from them.
As a result, it allows a wide variety of applications to work through
existing NAT infrastructure.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3515
04/2003
(23 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
| | | |
RFC3581
08/2003
(13 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3603
10/2003
(28 p.)
[html]
[pdf(2)] |
W. Marshall
F. Andreasen |
SIPPING |
| Private SIP
Proxy-to-Proxy Extensions
for Supporting the PacketCable Distributed Call Signaling Architecture |
In order to deploy a residential telephone service at very large
scale across different domains, it is necessary for trusted elements
owned by different service providers to exchange trusted information
that conveys customer-specific information and expectations about the
parties involved in the call. This document describes private
extensions to the Session Initiation Protocol for
supporting the exchange of customer information and billing
information between trusted entities in the PacketCable Distributed
Call Signaling Architecture. These extensions provide mechanisms for
access network coordination to prevent theft of service, customer
originated trace of harassing calls, support for operator services
and emergency services, and support for various other regulatory
issues. The use of the extensions is only applicable within closed
administrative domains, or among federations of administrative
domains with previously agreed-upon policies where coordination of
charging and other functions is required.
This document defines the
"P-DCS-Trace-Party-ID",
"P-DCS-OSPS",
"P-DCS-Billing-Info",
"P-DCS-LAES",
and
"P-DCS-Redirect"
header fields.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3605
10/2003
(8 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC3665
12/2003
(94 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
| | | |
RFC3666
12/2003
(118 p.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
| | | |
RFC3680
03/2004
(26 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
