|
|
|
|
|
|
|
|
|
|
| Last Update: Jun 12, 2010
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3324
11/2002
(11 p.)
pdf(2p)
|
M. Watson |
| 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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC3351
08/2002
(17 p.)
pdf(2p)
|
N. Charlton
M. Gasson
G. Gybels
M. Spanner
A. van Wijk |
| 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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC3372
09/2002
(23 p.)
pdf(2p)
|
A. Vemuri
J. Peterson |
| 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).
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 63) |
|
|
|
|
|
|
|
|
| | |
RFC3398
12/2002
(68 p.)
pdf(2p)
|
G. Camarillo
A. B. Roach
J. Peterson
L. Ong |
| 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).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC3485
02/2003
(30 p.)
pdf(2p)
|
M. Garcia-Martin
C. Bormann
J. Ott
R. Price
A. B. Roach |
| 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.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3578
08/2003
(13 p.)
pdf(2p)
|
G. Camarillo
A. B. Roach
J. Peterson
L. Ong |
| 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).
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3665
12/2003
(94 p.)
pdf(2p)
|
A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers |
| 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.
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 75) |
|
|
|
|
|
|
|
|
| | |
RFC3666
12/2003
(118 p.)
pdf(2p)
|
A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers |
| 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.
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 76) |
|
|
|
|
|
|
|
|
| | |
RFC3680
03/2004
(26 p.)
pdf(2p)
|
J. Rosenberg |
| 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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC3725
04/2004
(31 p.)
pdf(2p)
|
J. Rosenberg
J. Peterson
H. Schulzrinne
G. Camarillo |
| Best Current Practices for Third Party Call Control (3pcc)
in SIP |
|
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 SIP. However,
there are several possible approaches, each with different benefits
and drawbacks. This document discusses best current practices for
the usage of SIP for third party call control.
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 85) |
|
|
|
|
|
|
|
|
| | |
RFC3824
06/2004
(16 p.)
pdf(2p)
|
J. Peterson
H. Liu
J. Yu
B. Campbell |
| Using E.164 numbers with SIP |
|
There are a number of contexts in which telephone numbers are
employed by 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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC3959
12/2004
(11 p.)
pdf(2p)
|
G. Camarillo |
| The Early Session Disposition Type for
SIP |
This document defines a new disposition type (early-session) for the
Content-Disposition header field in 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.
This document defines the
'early-session' SIP option tag.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC3960
12/2004
(13 p.)
pdf(2p)
|
G. Camarillo
H. Schulzrinne |
| Early Media and Ringing Tone Generation
in SIP |
|
This document describes how to manage early media in 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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4083
05/2005
(36 p.)
pdf(2p)
|
M. Garcia-Martin |
|
Input 3GPP Release 5 Requirements on SIP |
|
The 3rd-Generation Partnership Project (3GPP) has selected SIP
as the session establishment protocol for
the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of
Release 5 of the 3GPP specifications. Although SIP is a protocol
that fulfills most of the requirements for establishing a session in
an IP network, SIP has never been evaluated against the specific 3GPP
requirements for operation in a cellular network. In this document,
we express the requirements identified by 3GPP to support SIP for
Release 5 of the 3GPP IMS in cellular networks.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4117
06/2005
(19 p.)
pdf(2p)
|
G. Camarillo
E. Burger
H. Schulzrinne
A. van Wijk |
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4189
10/2005
(12 p.)
pdf(2p)
|
K. Ono
S. Tachimoto |
| Requirements for End-to-Middle Security for SIP |
|
A Session Initiation Protocol (SIP) User Agent (UA) does not always
trust all intermediaries in its request path to inspect its message
bodies and/or headers contained in its message. The UA might want to
protect the message bodies and/or headers from intermediaries, except
those that provide services based on its content. This situation
requires a mechanism called "end-to-middle security" to secure the
information passed between the UA and intermediaries, which does not
interfere with end-to-end security. This document defines a set of
requirements for a mechanism to achieve end-to-middle security.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4235
11/2005
(39 p.)
pdf(2p)
|
J. Rosenberg
H. Schulzrinne
R. Mahy |
|
An INVITE-Initiated Dialog Event Package for SIP |
This document defines the 'dialog'
event package for the SIP Events architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another
user and to receive notification of the changes in state of INVITE-initiated
dialog usages in which the subscribed-to user is involved.
This RFC registers a new MIME type, application/ dialog-info+xml.
It also registers two new Media feature tags,
sip.byeless (19) and
sip.rendering (20),
placed into the SIP Media Feature Tag Registration Tree,
which is defined in RFC 3840.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4240
12/2005
(24 p.)
pdf(2p)
|
E. Burger
J. Van Dyke
A. Spitzer |
| Basic Network Media Services with SIP |
In SIP-based networks, there is a need to provide basic network media
services. Such services include network announcements, user
interaction, and conferencing services. These services are basic
building blocks, from which one can construct interesting
applications. In order to have interoperability between servers
offering these building blocks (also known as Media Servers) and
application developers, one needs to be able to locate and invoke
such services in a well defined manner.
This document describes a mechanism for providing an interoperable
interface between Application Servers, which provide application
services to SIP-based networks, and Media Servers, which provide the
basic media processing building blocks.
This specification adds new values to the IANA registration in
the "SIP/SIPS URI Parameters" registry as defined in
RFC 3969:
"play", "content-type", "delay", "duration", "repeat", "locale",
"param[n]",
and "voicexml".
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4245
11/2005
(12 p.)
pdf(2p)
|
O. Levin
R. Even |
| 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.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4353
02/2006
(29 p.)
pdf(2p)
|
J. Rosenberg |
| A Framework for Conferencing with SIP |
|
The Session Initiation Protocol (SIP) supports the initiation,
modification, and termination of media sessions between user agents.
These sessions are managed by SIP dialogs, which represent a SIP
relationship between a pair of user agents. Because dialogs are
between pairs of user agents, SIP's usage for two-party
communications (such as a phone call), is obvious. Communications
sessions with multiple participants, generally known as conferencing,
are more complicated. This document defines a framework for how such
conferencing can occur. This framework describes the overall
architecture, terminology, and protocol components needed for multi-party
conferencing.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4354
01/2006
(21 p.)
pdf(2p)
|
M. Garcia-Martin |
| A SIP Event Package and Data Format
for Various Settings in Support
for the Push-to-Talk over Cellular (PoC) Service |
The Open Mobile Alliance (OMA) is defining the Push-to-talk over
Cellular (PoC) service where SIP is the protocol used to establish
half-duplex media sessions across different participants, to send
instant messages, etc. This document defines the
'poc-settings'
SIP event package to
support publication, subscription, and notification of additional
capabilities required by the PoC service. This SIP event package is
applicable to the PoC service and may not be applicable to the
general Internet.
This document registers a new MIME type, application/ poc-settings+xml.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4411
02/2006
(22 p.)
pdf(2p)
|
J. Polk |
|
Extending SIP Reason Header for Preemption Events |
This document proposes an IANA Registration extension to the SIP
Reason Header
(RFC 3326)
to be included in a BYE
Method Request as a result of a session preemption event, either at a
user agent (UA), or somewhere in the network involving a
reservation-based protocol such as the Resource ReSerVation Protocol
(RSVP) or Next Steps in Signaling (NSIS). This document does not
attempt to address routers failing in the packet path; instead, it
addresses a deliberate tear down of a flow between UAs, and informs
the terminated UA(s) with an indication of what occurred.
This RFC defines a new protocol value: Preemption to the "Reason
Protocols" sub-registry.
It also defines the
http://www.iana.org/assignments/preemption-namespace registry,
with 4 defined cause codes.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4453
04/2006
(8 p.)
pdf(2p)
|
J. Rosenberg
G. Camarillo
D. Willis |
| Requirements for Consent-Based Communications in SIP |
|
The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant
messaging, and presence. In its current form, it allows session
invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the
recipient. Without such consent, it is possible for SIP to be used
for malicious purposes, including spam and denial-of-service attacks.
This document identifies a set of requirements for extensions to SIP
that add consent-based communications.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4457
04/2006
(8 p.)
pdf(2p)
|
G. Camarillo
G. Blanco |
|
The SIP P-User-Database Private-Header (P-Header) |
|
This document specifies the SIP
"P-User-Database"
Private-Header (P-header). This header field is used
in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia
Subsystem) to provide SIP registrars and SIP proxy servers with the
address of the database that contains the user profile of the user
that generated a particular request.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4475
05/2006
(53 p.)
pdf(2p)
|
R. Sparks
A. Hawrylyshen
A. Johnston
J. Rosenberg
H. Schulzrinne |
| SIP Torture Test Messages |
|
This informational document gives examples of Session Initiation
Protocol (SIP) test messages designed to exercise and "torture" a SIP
implementation.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4484
08/2006
(15 p.)
pdf(2p)
|
J. Peterson
J. Polk
D. Sicker
H. Tschofenig |
|
Trait-Based Authorization Requirements for SIP |
|
This document lays out a set of requirements related to trait-based
authorization for the Session Initiation Protocol (SIP). While some
authentication mechanisms are described in the base SIP
specification, trait-based authorization provides information used to
make policy decisions based on the attributes of a participant in a
session. This approach provides a richer framework for
authorization, as well as allows greater privacy for users of an
identity system.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4497
05/2006
(65 p.)
pdf(2p)
|
J. Elwell
F. Derks
P. Mourot
O. Rousseau |
| Interworking between SIP and QSIG |
|
This document specifies interworking between the Session Initiation
Protocol (SIP) and QSIG within corporate telecommunication networks
(also known as enterprise networks). SIP is an Internet
application-layer control (signalling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include, in particular, telephone calls. QSIG is a
signalling protocol for creating, modifying, and terminating
circuit-switched calls (in particular, telephone calls) within
Private Integrated Services Networks (PISNs). QSIG is specified in a
number of Ecma Standards and published also as ISO/IEC standards.
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 117) |
|
|
|
|
|
|
|
|
| | |
RFC4569
07/2006
(4 p.)
pdf(2p)
|
G. Camarillo |
|
IANA Registration of the 'Message' Media Feature Tag |
This document registers with the IANA (Internet Assigned Numbers Authority) a new media feature tag
associated with the 'message' media type. This media feature tag
indicates that a particular device supports 'message' as a streaming
media type. Media feature tags can be used to route calls to devices
that support certain features.
This new Media feature tag:
sip.message (21) is
placed into the SIP Media Feature Tag Registration Tree,
which is defined in RFC 3840.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4575
08/2006
(40 p.)
pdf(2p)
|
J. Rosenberg
H. Schulzrinne
O. Levin |
|
A SIP Event Package for Conference State |
This document defines a 'conference'
event package for tightly coupled
conferences using the Session Initiation Protocol (SIP) events
framework, along with a data format used in notifications for this
package. The conference package allows users to subscribe to a
conference Uniform Resource Identifier (URI). Notifications are sent
about changes in the membership of this conference and optionally
about changes in the state of additional conference components.
This document registers a new MIME type, application/ conference-info+xml.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4579
08/2006
(43 p.)
pdf(2p)
|
A. Johnston
O. Levin |
|
SIP Call Control - Conferencing for User Agents |
|
This specification defines conferencing call control features for the
Session Initiation Protocol (SIP). This document builds on the
Conferencing Requirements and Framework documents to define how a
tightly coupled SIP conference works. The approach is explored from
the perspective of different user agent (UA) types: conference-unaware,
conference-aware, and focus UAs. The use of Uniform
Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities
discovery, and call control using REFER are covered in detail with
example call flow diagrams. The usage of the isfocus feature tag is
defined.
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 119) |
|
|
|
|
|
|
|
|
| | |
RFC4596
07/2006
(40 p.)
pdf(2p)
|
J. Rosenberg
P. Kyzivat |
|
Guidelines for Usage of the SIP Caller Preferences Extension |
|
This document contains guidelines for usage of the Caller Preferences
Extension to the Session Initiation Protocol (SIP). It demonstrates
the benefits of caller preferences with specific example
applications, provides use cases to show proper operation, provides
guidance on the applicability of the registered feature tags, and
describes a straightforward implementation of the preference and
capability matching algorithm specified in Section 7.2 of
RFC 3841.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4730
11/2006
(56 p.)
pdf(2p)
|
E. Burger
M. Dolly |
|
A SIP Event Package for Key Press Stimulus (KPML) |
This document describes a SIP event package
'kpml'
that enables
monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses
Extensible Markup Language (XML) documents referred to as Key Press
Markup Language (KPML). The kpml Event Package may be used to
support applications consistent with the principles defined in the
document titled "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE
messages and allows for XML documents that define and describe filter
specifications for capturing key presses (DTMF Tones) entered at a
presentation-free User Interface SIP User Agent (UA). The event
package uses NOTIFY messages and allows for XML documents to report
the captured key presses (DTMF tones), consistent with the filter
specifications, to an Application Server. The scope of this package
is for collecting supplemental key presses or mid-call key presses
(triggers).
This document registers two new MIME types:
application/ kpml-request+xml and
application/ kpml-response+xml.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5002
08/2007
(7 p.)
pdf(2p)
|
G. Camarillo
G. Blanco |
|
The SIP P-Profile-Key Private Header (P-Header) |
|
This document specifies the SIP "P-Profile-Key" P-header. This header
field is used in the 3rd-Generation Partnership Project (3GPP) IMS
(IP Multimedia Subsystem) to provide SIP registrars and SIP proxy
servers with the key of the profile corresponding to the destination
SIP URI of a particular SIP request.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5009
09/2007
(15 p.)
pdf(2p)
|
R. Ejzak |
|
P-Header Extension to
SIP for Authorization of Early Media |
|
This document describes the
"P-Early-Media" private header field
(P-Header) to be used by the European Telecommunications
Standards Institute (ETSI) Telecommunications and Internet-converged
Services and Protocols for Advanced Networks (TISPAN) for the purpose
of authorizing early media flows in Third Generation Partnership
Project (3GPP) IP Multimedia Subsystems (IMS). This header field is
useful in any SIP network that is interconnected with other SIP
networks and needs to control the flow of media in the early dialog
state.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5039
01/2008
(28 p.)
pdf(2p)
|
J. Rosenberg
C. Jennings |
|
SIP and Spam |
|
Spam, defined as the transmission of bulk unsolicited messages, has
plagued Internet email. Unfortunately, spam is not limited to email.
It can affect any system that enables user-to-user communications.
The Session Initiation Protocol (SIP) defines a system for user-to-user
multimedia communications. Therefore, it is susceptible to
spam, just as email is. In this document, we analyze the problem of
spam in SIP. We first identify the ways in which the problem is the
same and the ways in which it is different from email. We then
examine the various possible solutions that have been discussed for
email and consider their applicability to SIP.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5057
11/2007
(26 p.)
pdf(2p)
|
R. Mahy |
|
Multiple Dialog Usages in SIP |
Several methods in the Session Initiation Protocol (SIP) can create
an association between endpoints known as a dialog. Some of these
methods can also create a different, but related, association within
an existing dialog. These multiple associations, or dialog usages,
require carefully coordinated processing as they have independent
life-cycles, but share common dialog state. Processing multiple
dialog usages correctly is not completely understood. What is
understood is difficult to implement.
This memo argues that multiple dialog usages should be avoided. It
discusses alternatives to their use and clarifies essential behavior
for elements that cannot currently avoid them.
This is an informative document and makes no normative statements of
any kind.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5118
02/2008
(18 p.)
pdf(2p)
|
V. Gurbani
C. Boulton
R. Sparks |
|
SIP Torture Test Messages for IPv6 |
|
This document provides examples of Session Initiation Protocol (SIP)
test messages designed to exercise and "torture" the code of an
IPv6-enabled SIP implementation.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5194
06/2008
(31 p.)
pdf(2p)
|
A. van Wijk
G. Gybels |
|
Framework for Real-Time Text over IP using SIP |
|
This document lists the essential requirements for real-time Text-
over-IP (ToIP) and defines a framework for implementation of all
required functions based on the Session Initiation Protocol (SIP) and
the Real-Time Transport Protocol (RTP). This includes interworking
between Text-over-IP and existing text telephony on the Public
Switched Telephone Network (PSTN) and other networks.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5279
07/2008
(7 p.)
pdf(2p)
|
A. Monrad
S. Loreto |
|
A Uniform Resource Name (URN) Namespace for the 3GPP |
|
This document describes the Namespace Identifier (NID) for Uniform
Resource Namespace (URN) resources published by the 3rd Generation
Partnership Project (3GPP). 3GPP defines and manages resources that
utilize this URN name model. Management activities for these and
other resource types are provided by the 3GPP Support Team.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5318
12/2008
(12 p.)
pdf(2p)
|
J. Hautakorpi
G. Camarillo |
|
SIP P-Refused-URI-List Private-Header |
|
This document specifies the Session Initiation Protocol (SIP)
"P-Refused-URI-List" Private-Header (P-Header). This P-Header is used
in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC)
system. It enables URI-list servers to refuse the handling of
incoming URI lists that have embedded URI lists. This P-Header also
makes it possible for the URI-list server to inform the client about
the embedded URI list that caused the rejection and the individual
URIs that form such a URI list.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5359
10/2008
(170 p.)
pdf(2p)
|
A. Johnston
R. Sparks
C. Cunningham
S. Donovan
K. Summers |
|
SIP Service Examples |
|
This document gives examples of Session Initiation Protocol (SIP)
services. This covers most features offered in so-called IP Centrex
offerings from local exchange carriers and PBX (Private Branch
Exchange) features. Most of the services shown in this document are
implemented in the SIP user agents, although some require the
assistance of a SIP proxy. Some require some extensions to SIP
including the REFER,
SUBSCRIBE, and
NOTIFY methods and the
Replaces
and Join header fields.
These features are not intended to be an
exhaustive set, but rather show implementations of common features
likely to be implemented on SIP IP telephones in a business
environment. This document specifies an Internet Best Current Practices
for the Internet Community, and requests discussion and suggestions for
improvements.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5361
10/2008
(14 p.)
pdf(2p)
|
G. Camarillo |
|
A Document Format for Requesting Consent |
This document defines an Extensible Markup Language (XML) format for
a permission document used to request consent. A permission document
written in this format is used by a relay to request a specific
recipient permission to perform a particular routing translation.
This specification requests the following registrations at the IANA:
urn:ietf:params:xml:ns:consent-rules XML namespace,
urn:ietf:params:xml:schema:consent-rules XML schema.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5364
10/2008
(17 p.)
pdf(2p)
|
M. Garcia-Martin
G. Camarillo |
|
XML Format Extension for Representing Copy Control Attributes in Resource Lists |
|
In certain types of multimedia communications, a Session Initiation
Protocol (SIP) request is distributed to a group of SIP User Agents
(UAs). The sender sends a single SIP request to a server which
further distributes the request to the group. This SIP request
contains a list of Uniform Resource Identifiers (URIs), which
identify the recipients of the SIP request. This URI list is
expressed as a resource list XML document. This specification
defines an XML extension to the XML resource list format that allows
the sender of the request to qualify a recipient with a copy control
level similar to the copy control level of existing email systems.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5369
10/2008
(10 p.)
pdf(2p)
|
G. Camarillo |
|
Framework for Transcoding with SIP |
|
This document defines a framework for transcoding with SIP. This
framework includes how to discover the need for transcoding services
in a session and how to invoke those transcoding services. Two
models for transcoding services invocation are discussed: the
conference bridge model and the third-party call control model. Both
models meet the requirements for SIP regarding transcoding services
invocation to support deaf, hard of hearing, and speech-impaired
individuals.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5370
10/2008
(11 p.)
pdf(2p)
|
G. Camarillo |
|
The SIP Conference Bridge Transcoding Model |
|
This document describes how to invoke transcoding services using the
conference bridge model. This way of invocation meets the
requirements for SIP regarding transcoding services invocation to
support deaf, hard of hearing, and speech-impaired individuals.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5390
12/2008
(14 p.)
pdf(2p)
|
J. Rosenberg |
|
Requirements for Management of Overload in SIP |
|
Overload occurs in Session Initiation Protocol (SIP) networks when
proxies and user agents have insufficient resources to complete the
processing of a request. SIP provides limited support for overload
handling through its 503 response code, which tells an upstream
element that it is overloaded. However, numerous problems have been
identified with this mechanism. This document summarizes the
problems with the existing 503 mechanism, and provides some
requirements for a solution.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5407
12/2008
(60 p.)
pdf(2p)
|
M. Hasebe
J. Koshiko
Y. Suzuki
T. Yoshikawa
P. Kyzivat |
|
Example Call Flows of Race Conditions in SIP |
|
This document gives example call flows of race conditions in the
Session Initiation Protocol (SIP). Race conditions are inherently
confusing and difficult to thwart; this document shows the best
practices to handle them. The elements in these call flows include
SIP User Agents and SIP Proxy Servers. Call flow diagrams and
message details are given.
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 147) |
|
|
|
|
|
|
|
|
| | |
RFC5502
04/2009
(14 p.)
pdf(2p)
|
J. van Elburg |
|
The SIP P-Served-User Private-Header for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem |
|
This document specifies the SIP P-Served-User P-header. This header
field addresses an issue that was found in the 3rd Generation
Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an
S-CSCF (Serving Call Session Control Function) and an AS (Application
Server) on the ISC (IMS Service Control) interface. This header
field conveys the identity of the served user and the session case
that applies to this particular communication session and application
invocation.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5503
03/2009
(34 p.)
pdf(2p)
|
F. Andreasen
B. McKibben
B. Marshall |
|
Private SIP Proxy-to-Proxy Extensions for supporting PacketCable DCS Architecture |
In order to deploy a residential telephone service at a 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, RFC 3261, 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.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5589
06/2009
(58 p.)
pdf(2p)
|
R. Sparks
A. Johnston
D. Petrie |
|
SIP Call Control - Transfer |
|
This document describes providing Call Transfer capabilities in the
Session Initiation Protocol (SIP). SIP extensions such as REFER and
Replaces are used to provide a number of transfer services including
blind transfer, consultative transfer, and attended transfer. This
work is part of the SIP multiparty call control framework.
|
|
|
| |
| List |
Status: | Best Current Practice (BCP: 149) |
|
|
|
|
|
|
|
|
| | |
RFC5628
10/2009
(14 p.)
pdf(2p)
|
P. Kyzivat |
|
Registration Event Package Extension for SIP Globally Routable User Agent URIs (GRUUs) |
RFC 3680 defines a Session Initiation Protocol (SIP) event package
for registration state. This package allows a watcher to learn about
information stored by a SIP registrar, including its registered
contact.
However, the registered contact is frequently unreachable and thus
not useful for watchers. The Globally Routable User Agent URI
(GRUU), defined in RFC 5627, is a URI that is capable of reaching a
particular contact. However this URI is not included in the document
format defined in RFC 3680. This specification defines an extension
to the registration event package to include GRUUs assigned by the
registrar.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5629
10/2009
(38 p.)
pdf(2p)
|
J. Rosenberg |
|
A Framework for Application Interaction in SIP |
|
This document describes a framework for the interaction between users
and Session Initiation Protocol (SIP) based applications. By
interacting with applications, users can guide the way in which they
operate. The focus of this framework is stimulus signaling, which
allows a user agent (UA) to interact with an application without
knowledge of the semantics of that application. Stimulus signaling
can occur to a user interface running locally with the client, or to
a remote user interface, through media streams. Stimulus signaling
encompasses a wide range of mechanisms, ranging from clicking on
hyperlinks, to pressing buttons, to traditional Dual-Tone Multi-Frequency
(DTMF) input. In all cases, stimulus signaling is
supported through the use of markup languages, which play a key role
in this framework.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5631
10/2009
(35 p.)
pdf(2p)
|
R. Shacham
H. Schulzrinne
S. Thakolsri
W. Kellerer |
|
SIP Session Mobility |
|
Session mobility is the transfer of media of an ongoing communication
session from one device to another. This document describes the
basic approaches and shows the signaling and media flow examples for
providing this service using the Session Initiation Protocol (SIP).
Service discovery is essential to locate targets for session transfer
and is discussed using the Service Location Protocol (SLP) as an
example.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5850
05/2010
(44 p.)
pdf(2p)
|
R. Mahy
R. Sparks
J. Rosenberg
D. Petrie
A. Johnston |
|
A Call Control and Multi-Party Usage Framework for SIP |
|
This document defines a framework and the requirements for call
control and multi-party usage of the Session Initiation Protocol
(SIP). To enable discussion of multi-party features and
applications, we define an abstract call model for describing the
media relationships required by many of these. The model and actions
described here are specifically chosen to be independent of the SIP
signaling and/or mixing approach chosen to actually set up the media
relationships. In addition to its dialog manipulation aspect, this
framework includes requirements for communicating related information
and events such as conference and session state and session history.
This framework also describes other goals that embody the spirit of
SIP applications as used on the Internet such as the definition of
primitives (not services), invoker and participant oriented
primitives, signaling and mixing model independence, and others.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5853
04/2010
(26 p.)
pdf(2p)
|
J. Hautakorpi
G. Camarillo
R. Penfield
A. Hawrylyshen
M. Bhatia |
|
Requirements from SIP Session Border Control (SBC) Deployments |
|
This document describes functions implemented in Session Initiation
Protocol (SIP) intermediaries known as Session Border Controllers
(SBCs). The goal of this document is to describe the commonly
provided functions of SBCs. A special focus is given to those
practices that are viewed to be in conflict with SIP architectural
principles. This document also explores the underlying requirements
of network operators that have led to the use of these functions and
practices in order to identify protocol requirements and determine
whether those requirements are satisfied by existing specifications
or if additional standards work is required.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5876
04/2010
(11 p.)
pdf(2p)
|
J. Elwell |
|
Updates to Asserted Identity in SIP |
|
The Session Initiation Protocol (SIP) has a mechanism for conveying
the identity of the originator of a request by means of the
P-Asserted-Identity and P-Preferred-Identity header fields. These
header fields are specified for use in requests using a number of SIP
methods, in particular the INVITE method. However, RFC 3325 does not
specify the insertion of the P-Asserted-Identity header field by a
trusted User Agent Client (UAC), does not specify the use of
P-Asserted-Identity and P-Preferred-Identity header fields with
certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH,
and does not specify how to handle an unexpected number of URIs or
unexpected URI schemes in these header fields. This document extends
RFC 3325 to cover these situations.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5897
06/2010
(23 p.)
pdf(2p)
|
J. Rosenberg |
|
Identification of Communications Services in SIP |
|
This document considers the problem of service identification in the
Session Initiation Protocol (SIP). Service identification is the
process of determining the user-level use case that is driving the
signaling being utilized by the user agent (UA). This document
discusses the uses of service identification, and outlines several
architectural principles behind the process. It identifies perils
when service identification is not done properly -- including fraud,
interoperability failures, and stifling of innovation. It then
outlines a set of recommended practices for service identification.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
