| RFC# |
Name |
Description
(abstract) |
| 2976 |
The SIP INFO Method |
This RFC proposes an extension to the Session Initiation Protocol (SIP). This extension adds the
INFO method to the SIP protocol. The intent of the INFO method is to
allow for the carrying of session related control information that is generated during a
session. One example of such session control information is ISUP and ISDN signaling messages used to control telephony call services.
|
| 3204
(updated by RFC 3459) |
MIME media types for ISUP and QSIG Objects |
This RFC describes
MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the
call involves interworking to the PSTN.
|
| 3261
(obsoletes RFC 2543/ updated by RFC 3853,RFC 4320) |
SIP: Session Initiation Protocol |
This RFC 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.
|
| 3262
(obsoletes RFC 2543) |
Reliability of Provisional Responses in SIP |
This RFC specifies an extension to the Session Initiation
Protocol (SIP) providing reliable provisional response messages.
This extension uses the option tag 100rel and defines the
Provisional Response ACKnowledgement
(PRACK) method.
|
| 3263
(obsoletes RFC 2543) |
SIP: Locating SIP Servers |
The Session Initiation Protocol (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
RFC describes those DNS procedures in detail.
|
| 3265
(obsoletes RFC 2543) |
SIP-Specific Event Notification |
This RFC describes an extension to the Session Initiation
Protocol (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.
|
| 3310 |
Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) |
This RFC 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.
|
| 3311 |
The Session Initiation Protocol UPDATE Method |
This RFC defines the new
UPDATE method for the Session
Initiation Protocol (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.
|
| 3312
(updated by RFC 4032) |
Integration of Resource Management and SIP |
This RFC 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 the Session Initiation Protocol (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.
|
| 3313 |
Private Session Initiation Protocol
(SIP)Extensions for Media Authorization |
This document describes the need for Quality of Service (QoS) and
media authorization and defines a Session Initiation Protocol (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.
|
| 3319 |
Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers |
This RFC 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 Session Initiation
Protocol (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.
|
| 3323 |
A Privacy Mechanism for the Session Initiation Protocol (SIP) |
This RFC defines new mechanisms for the Session Initiation
Protocol (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.
|
| 3325 |
Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks |
This document describes private extensions to the Session Initiation
Protocol (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.
|
| 3326 |
The Reason Header Field for the Session Initiation Protocol (SIP) |
For creating services, it is often useful to know
why a Session
Initiation Protocol (SIP) request was issued. This document defines
a header field, Reason, 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.
|
| 3327 |
Session Initiation Protocol Extension for Registering Non-Adjacent Contacts |
The REGISTER function is used in a Session Initiation Protocol (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.
|
| 3329 |
Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions |
This RFC defines new functionality for negotiating the
security
mechanisms used between a Session Initiation Protocol (SIP) user
agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities.
|
| 3361 |
DHCP Option for SIP Servers |
This RFC 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 Session Initiation
Protocol (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.
|
| 3420 |
Internet Media Type
message/sipfrag |
This RFC 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 Session
Initiation Protocol (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.
|
| 3428 |
Session Initiation Protocol 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 RFC proposes the MESSAGE method, an extension to the Session Initiation Protocol (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.
|
| 3486 |
Compressing
the Session Initiation Protocol |
This document describes a mechanism to signal
that compression is desired for one or more Session Initiation
Protocol (SIP) messages. It also states when it is appropriate to send
compressed SIP messages to a SIP entity.
|
| 3515 |
The Session Initiation Protocol (SIP) Refer Method |
This RFC defines the REFER method. This Session Initiation
Protocol (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 the refer
event package and the Refer-To request header.
|
| 3581 |
An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing |
The Session Initiation Protocol (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.
|
| 3608 |
Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration |
This document defines a Session Initiation Protocol (SIP) extension
header field 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.
|
| 3840 |
Indicating
User Agent Capabilities in the Session Initiation Protocol (SIP) |
This specification defines mechanisms by
which a Session Initiation Protocol (SIP) user agent can convey its
capabilities and characteristics to other user agents and to the
registrar for its domain. This information is conveyed as parameters of
the Contact header field.
|
| 3841 |
Caller
Preferences for the Session Initiation Protocol (SIP) |
This
document describes a set of extensions to the Session Initiation Protocol
(SIP) which allow a caller to express preferences
about request handling in servers. These preferences include the ability
to select which Uniform Resource Identifiers (URI) a request gets routed
to, and to specify certain request handling directives in proxies and
redirect servers. It does so by defining three new request header fields,
Accept-Contact, Reject-Contact, and Request- Disposition, which specify
the caller's preferences.
|
| 3853
(updates RFC 3261) |
S/MIME
Advanced Encryption Standard (AES) Requirement for the Session Initiation
Protocol (SIP)
|
RFC
3261 currently specifies 3DES as the mandatory-to-implement ciphersuite
for implementations of S/MIME in the
Session Initiation Protocol (SIP). This document updates the normative
guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for
S/MIME.
|
| 3891 |
The
Session Initiation Protocol (SIP) "Replaces" Header |
This
document defines a new header for use with Session Initiation Protocol
(SIP) multi-party applications and call control. The Replaces
header is used to logically replace an existing
SIP dialog with a new SIP dialog. This primitive can be used to
enable a variety of features, for example: "Attended Transfer"
and "Call Pickup". Note that the definition of these example
features is non- normative.
|
| 3892 |
The
Session Initiation Protocol (SIP) Referred-By Mechanism |
The
Session Initiation Protocol (SIP) REFER method provides a mechanism
where one party (the referrer) gives a second party (the referee) an
arbitrary URI to reference. If that URI is a SIP URI, the referee will
send a SIP request, often an INVITE, to that URI (the refer target). This
document extends the REFER method, allowing the referrer to provide
information about the REFER request to the refer target using the referee
as an intermediary. This information includes the identity of the referrer
and the URI to which the referrer referred. The mechanism utilizes S/MIME
to help protect this information from a malicious intermediary. This
protection is optional, but a recipient may refuse to accept a request
unless it is present.
|
| 3893 |
Session
Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format |
RFC
3261 introduces the concept of adding an S/MIME body to a Session
Initiation Protocol (SIP) request or response in order to provide
reference integrity over its headers. This
document provides a more specific mechanism to derive integrity and
authentication properties from an 'authenticated identity body', a
digitally-signed SIP message, or message fragment. A standard
format for such bodies (known as Authenticated Identity Bodies, or AIBs)
is given in this document. Some considerations for the processing of AIBs
by recipients of SIP messages with such bodies are also given.
|
| 3911 |
The
Session Initiation Protocol (SIP) "Join" Header |
This
document defines a new header for use with SIP
multi-party applications and call control. The Join
header is used to logically join an existing SIP dialog with a new SIP
dialog. This primitive can be used to enable a variety of features, for
example: "Barge-In", answering-machine-style "Message
Screening" and "Call Center Monitoring". Note that
definition of these example features is non- normative.
|
| 3903 |
Session
Initiation Protocol (SIP) Extension for Event State Publication |
This
document describes an extension to the Session Initiation Protocol (SIP)
for publishing event state used within
the SIP Events framework. The first application of this extension is for
the publication of presence information. The mechanism described in this
document can be extended to support publication of any event state for
which there exists an appropriate event package. It is not intended to be
a general-purpose mechanism for transport of arbitrary data, as there are
better-suited mechanisms for this purpose.
|
| 3968
(updates RFC 3427) |
The
Internet Assigned Number Authority (IANA) Header Field Parameter Registry
for the Session Initiation Protocol (SIP) |
This document creates an Internet Assigned
Number Authority (IANA) registry
for the Session Initiation Protocol (SIP)
header field parameters and parameter values. It also lists the
already existing parameters and parameter values to be used as the initial
entries for this registry.
|
| 3969
(updates RFC 3427) |
The
Internet Assigned Number Authority (IANA) Universal Resource Identifier
(URI) Parameter Registry for the Session Initiation Protocol (SIP) |
This document creates an Internet Assigned
Number Authority (IANA) registry
for the Session Initiation Protocol (SIP) and SIPS Uniform Resource
Identifier (URI) parameters, and their values. It also lists the
already existing parameters to be used as initial values for that
registry.
|
| 4028 |
Session
Timers in the Session Initiation Protocol (SIP) |
This document defines an extension to the
Session Initiation Protocol (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.
|
| 4032
(updates RFC 3312) |
Update
to the Session Initiation Protocol (SIP) Preconditions Framework |
This document updates RFC 3312, which
defines the framework for preconditions in SIP. We provide
guidelines for authors of new precondition types and describe how to use
SIP preconditions in situations that involve session mobility.
|
| 4092 |
Usage
of the Session Description Protocol (SDP) Alternative Network Address
Types (ANAT) Semantics in the Session Initiation Protocol (SIP) |
This document describes how to use the
Alternative Network Address Types (ANAT) semantics of the Session
Description Protocol (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.
|
| 4168 |
The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (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.
|
| 4244 |
An
Extension to the Session Initiation Protocol (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.
|
| 4320
(updates RFC 3261) |
Actions
Addressing Identified Issues with the Session Initiation Protocol's (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.
|
| 4321 |
Problems
Identified Associated with the Session Initiation Protocol's (SIP)
Non-INVITE Transaction |
This
document describes several problems that have been identified with the
Session Initiation Protocol's (SIP) non-INVITE transaction.
|
| 4412 |
Communications Resource Priority for
the Session Initiation Protocol (SIP) |
This document defines two new Session Initiation Protocol (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.
|
| 4474 |
Enhancements
for Authenticated Identity Management in the Session Initiation Protocol
(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.
|
| 4483 |
A Mechanism for
Content Indirection in Session Initiation Protocol (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.
|
| 4485 |
Guidelines for
Authors of Extensions to the Session Initiation Protocol (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.
|
| 4488 |
Suppression of Session Initiation Protocol (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 header field that may be included in a REFER request.
|
| 4508 |
Conveying
Feature Tags with Session Initiation Protocol (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.
|
| 4538 |
Request
Authorization through Dialog Identification in the Session Initiation
Protocol (SIP) |
This specification defines the Target-Dialog header field for
the Session Initiation Protocol (SIP), and the corresponding option tag,
tdialog. 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.
|
| 4780 |
Management
Information Base for the Session Initiation Protocol (SIP) |
This memo defines a portion of the Management Information
Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used to
manage Session Initiation Protocol (SIP) entities, which include User
Agents, and Proxy, Redirect and Registrar servers.
|
| 4916 |
Connected Identity in the
Session Initiation Protocol (SIP) - Updates RFC 3261 |
This document provides a means for a Session Initiation
Protocol (SIP) User Agent (UA) that receives a dialog-forming request to
supply its identity to the peer UA by means of a request in the reverse
direction, and for that identity to be signed by an
Authentication Service. Because of retargeting of a dialog-forming request
(changing the value of the Request-URI), the UA that receives it (the User
Agent Server, UAS) can have a different identity from that in the To header
field. The same mechanism can be used to indicate a change of identity
during a dialog, e.g., because of some action in the Public Switched
Telephone Network (PSTN) behind a gateway. This document normatively updates
RFC 3261 (SIP).
|
|
5079 |
Rejecting
Anonymous Requests in the Session Initiation Protocol (SIP) (RFC 5079) |
The Session Initiation Protocol (SIP) allows for users to
make anonymous calls. However, users receiving such calls have the right to
reject them because they are anonymous. SIP has no way to indicate to the
caller that the reason for call rejection was that the call was anonymous.
Such an indication is useful to allow the call to be retried without
anonymity. This specification defines a new SIP response code for this
purpose.
|
| RFC# |
Name |
Description
(abstract) |
| 3324 |
Short Term Requirements for Network Asserted Identity |
A Network Asserted Identity is an identity initially derived by a Session Initiation Protocol (SIP) network intermediary as a result of an authentication process. This
RFC 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.
|
| 3351 |
User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired individuals |
This RFC presents a set of Session Initiation Protocol
(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.
|
| 3372 |
Session Initiation Protocol (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).
|
| 3398 |
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping |
This RFC describes a way to perform the
mapping between two signaling protocols: the Session Initiation Protocol
(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).
|
| 3485 |
The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) |
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be
compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (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.
|
| 3578 |
Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) |
This RFC describes a way to map Integrated Services Digital Network User Part
(ISUP) overlap signalling to Session Initiation Protocol (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).
|
| 3665 |
Session Initiation Protocol Basic Call Flow Examples |
This informational
RFC 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.
|
| 3666 |
Session Initiation Protocol PSTN Call Flows |
This informational
RFC contains best current practice examples of Session
Initiation Protocol (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.
|
| 3680 |
A Session Initiation Protocol (SIP) Event Package for Registrations |
This RFC defines a Session Initiation Protocol (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.
|
| 3702 |
Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol |
As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for
authentication, authorization, and accounting of SIP sessions. This
RFC sets out the basic requirements for this work.
|
| 3725 |
Best Current Practices for Third Party Call Control in the Session Initiation Protocol |
Third party call control refers to the ability of one entity to
create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits
and drawbacks. This RFC discusses best current practices for the usage of SIP for third party call control.
|
| 3824 |
Using
E.164 numbers with the Session Initiation Protocol (SIP) |
There are a number of contexts in which
telephone numbers are employed by Session Initiation Protocol (SIP)
applications, many of which can be addressed by ENUM. Although SIP
was one of the primary applications for which ENUM was created, there is
nevertheless a need to define procedures for integrating
ENUM with SIP implementations. This document illustrates how
the two protocols might work in concert, and clarifies the authoring and
processing of ENUM records for SIP applications. It also provides
guidelines for instances in which ENUM, for whatever reason, cannot be
used to resolve a telephone number.
|
| 3842 |
A
Message Summary and Message Waiting Indication Event Package for the
Session Initiation Protocol (SIP) |
This document describes a Session
Initiation Protocol (SIP) event package to carry
message waiting status and message summaries from a messaging
system to an interested User Agent.
|
| 3959 |
The Early Session Disposition Type for the Session Initiation Protocol (SIP) |
This document defines a new disposition type (early-session) for the
Content-Disposition header field in the Session Initiation Protocol
(SIP). The treatment of "early-session" bodies is similar to the
treatment of "session" bodies. That is, they follow the offer/answer
model. Their only difference is that session descriptions whose
disposition type is "early-session" are used to establish early media
sessions within early dialogs, as opposed to regular sessions within
regular dialogs.
|
| 3960 |
Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) |
This document describes how to manage early media in the Session
Initiation Protocol (SIP) using two models: the gateway model and the
application server model. It also describes the inputs one needs to
consider in defining local policies for ringing tone generation.
|
| 4083 |
Input
3rd-Generation Partnership Project (3GPP) Release 5 requirements on the
Session Initiation Protocol (SIP) |
The 3rd-Generation Partnership Project
(3GPP) has selected Session Initiation Protocol (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.
|
| 4117 |
Transcoding
Services Invocation in the Session Initiation Protocol (SIP) Using Third
Party Call Control (3pcc) |
This document describes how to invoke
transcoding services using Session Initiation Protocol (SIP) and third
party call control. This way of invocation meets the requirements for SIP
regarding transcoding services invocation to support deaf, hard of hearing
and speech-impaired individuals.
|
| 4189 |
Requirements for End-to-Middle Security for the Session Initiation Protocol (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.
|
| 4235 |
An
INVITE-Initiated Dialog Event Package for the Session Initiation Protocol
(SIP) |
This document defines a 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.
|
| 4245 |
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.
|
| 4353 |
A Framework for Conferencing with the
Session Initiation Protocol (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.
|
| 4411 |
Extending the Session Initiation Protocol (SIP)
Reason Header for Preemption Events |
This document proposes an IANA Registration extension to the Session
Initiation Protocol (SIP) Reason Header 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.
|
| 4453 |
Requirements for Consent-Based Communications
in the Session Initiation Protocol (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.
|
| 4475 |
Session Initiation Protocol (SIP) Torture Test Messages |
This informational document gives examples of Session Initiation
Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation.
|
|