RFCs related to SIP (page 3 of 4)
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5002
08/2007
(7 p.)
[html]
[pdf(2)] |
G. Camarillo
G. Blanco |
SIPPING |
|
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.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5009
09/2007
(15 p.)
[html]
[pdf(2)] |
R. Ejzak |
SIPPING |
|
Private Header (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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC5022
09/2007
(81 p.)
[html]
[pdf(2)] |
J. Van Dyke
E. Burger
A. Spitzer |
- |
|
Media Server Control Markup Language (MSCML) and Protocol |
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment.
See RFC 3932 for more information.
Media Server Control Markup Language (MSCML) is a markup language
used in conjunction with SIP to provide advanced conferencing and
interactive voice response (IVR) functions. MSCML presents an
application-level control model, as opposed to device-level control
models. One use of this protocol is for communications between a
conference focus and mixer in the IETF SIP Conferencing Framework.
This document describes the MSCML and its usage.
It describes payloads that one can send to a
media server using standard SIP INVITE and INFO methods and the
capabilities these payloads implement.
It registers a new MIME type,
application/ mediaservercontrol+xml.
Prior to MSCML, there was not a standard way to deliver SIP-based
enhanced conferencing. Basic SIP constructs, such as those described
in RFC4240,
serve simple n-way conferencing well. The SIP URI
provides a natural mechanism for identifying a specific SIP
conference, while INVITE and BYE methods elegantly implement
conference join and leave semantics. However, enhanced conferencing
applications also require features such as sizing and resizing, in-
conference IVR operations (e.g., recording and playing participant
names to the full conference), and conference event reporting. MSCML
payloads within standard SIP methods realize these features.
The structure and approach of MSCML satisfy the requirements set out
in RFC4353.
In particular, MSCML serves as the interface
between the conference server or focus and a centralized conference
mixer. In this case, a media server has the role of the conference
mixer.
MSCML fills the need for IVR and conference control with requests and
responses over a SIP transport. VoiceXML
[W3C REC REC-voicexml20] fills the need for IVR
with requests and responses over a HTTP transport. This enables
developers to use whatever model fits their needs best.
The media server fulfills the role of the Media Resource Function
(MRF) in the IP Multimedia Subsystem (IMS)
[3GPP TS 23.228] as described by 3GPP.
MSCML and RFC4240,
upon which MSCML builds, are specifically
focused on the Media resource (Mr) interface which supports
interactions between application logic and the MRF.
|
|
|
| |
| Up |
Status: | Informational -- obsoletes RFC4722 |
|
|
|
|
|
|
|
|
| | | |
RFC5025
12/2007
(28 p.)
[html]
[pdf(2)] |
J. Rosenberg |
SIMPLE |
|
Presence Authorization Rules |
Authorization is a key function in presence systems. Authorization
policies, also known as authorization rules, specify what presence
information can be given to which watchers, and when. This
specification defines an Extensible Markup Language (XML) document
format for expressing presence authorization rules. Such a document
can be manipulated by clients using the XML Configuration Access
Protocol (XCAP), although other techniques are permitted.
This specification requests the following registrations at the IANA:
pres-rules AUID,
urn:ietf:params:xml:ns:pres-rules XML namespace,
urn:ietf:params:xml:schema:pres-rules XML schema.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC5027
10/2007
(16 p.)
[html]
[pdf(2)] |
F. Andreasen
D. Wing |
MMUSIC |
|
Security Preconditions for SDP Media Streams |
|
This document defines a new security precondition for the Session
Description Protocol (SDP) precondition framework described in
RFC3312 and
RFC4032
A security precondition can be used to delay session
establishment or modification until media stream security for a
secure media stream has been negotiated successfully.
|
|
|
| |
| Up |
Status: | Proposed Standard -- Updates: 3312 |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC5039
01/2008
(28 p.)
[html]
[pdf(2)] |
J. Rosenberg
C. Jennings |
SIPPING |
|
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.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5049
12/2007
(21 p.)
[html]
[pdf(2)] |
C. Bormann
Z. Liu
R. Price
G. Camarillo |
ROHC |
|
Applying Signaling Compression (SigComp) to SIP |
|
This document describes some specifics that apply when Signaling
Compression (SigComp) is applied to the Session Initiation Protocol
(SIP), such as default minimum values of SigComp parameters,
compartment and state management, and a few issues on SigComp over
TCP. Any implementation of SigComp for use with SIP must conform to
this document and SigComp, and in addition, support the SIP and
Session Description Protocol (SDP) static dictionary.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC5057
11/2007
(26 p.)
[html]
[pdf(2)] |
R. Mahy |
SIPPING |
|
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.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5067
11/2007
(7 p.)
[html]
[pdf(2)] |
S. Lind
P. Pfautz |
ENUM |
|
Infrastructure ENUM Requirements |
|
This document provides requirements for "infrastructure" or "carrier"
ENUM (E.164 Number Mapping), defined as the use of RFC 3761
technology to facilitate interconnection of networks for E.164 number
addressed services, in particular but not restricted to VoIP (Voice
over IP.)
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5069
01/2008
(12 p.)
[html]
[pdf(2)] |
T. Taylor
H. Tschofenig
H. Schulzrinne
M. Shanmugam |
ECRIT |
|
Security Threats and Requirements for Emergency Call Marking and Mapping |
This document reviews the security threats associated with the
marking of signalling messages to indicate that they are related to
an emergency, and with the process of mapping locations to Universal
Resource Identifiers (URIs) that point to Public Safety Answering
Points (PSAPs). This mapping occurs as part of the process of
routing emergency calls through the IP network.
Based on the identified threats, this document establishes a set of
security requirements for the mapping protocol and for the handling
of emergency-marked calls.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5079
12/2007
(8 p.)
[html]
[pdf(2)] |
J. Rosenberg |
SIP |
|
Rejecting Anonymous Requests in SIP |
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: '433 Anonymity Disallowed'.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5112
01/2008
(25 p.)
[html]
[pdf(2)] |
M. Garcia-Martin |
SIMPLE |
|
The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) |
|
The Session Initiation Protocol (SIP) is a text-based protocol for
initiating and managing communication sessions. The protocol is
extended by the SIP-events notification framework to provide
subscriptions and notifications of SIP events. One example of such
event notification mechanism is presence, which is expressed in XML
documents called presence documents. SIP can be compressed by using
Signaling Compression (SigComp), which is enhanced by using the SIP/
Session Description Protocol (SDP) dictionary to achieve better
compression rates. However, the SIP/SDP dictionary is not able to
increase the compression factor of (typically lengthy) presence
documents. This memo defines the presence-specific static dictionary
that SigComp can use in order to compress presence documents to
achieve higher efficiency. The dictionary is compression-algorithm
independent.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC5115
01/2008
(8 p.)
[html]
[pdf(2)] |
K. Carlberg
P. O'Hanlon |
- |
|
Telephony Routing over IP (TRIP) Attribute for Resource Priority |
|
This document defines a new attribute for the Telephony Routing over
IP (TRIP) protocol. The attribute associates protocols/services in
the PSTN offering authorized prioritization during call setup that
are reachable through a TRIP gateway. Current examples of
preferential service in the Public Switched Telephone Network (PSTN)
are Government Emergency Telecommunications Service (GETS) in the
U.S. and Government Telephone Preference Scheme (GTPS) in the U.K.
The proposed attribute for TRIP is based on the NameSpace.Value tuple
defined for the SIP Resource-Priority field.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5139
02/2008
(14 p.)
[html]
[pdf(2)] |
M. Thomson
J. Winterbottom |
GEOPRIV |
|
Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) |
|
This document defines an XML format for the representation of civic
location. This format is designed for use with Presence Information
Data Format Location Object (PIDF-LO) documents and replaces the
civic location format in RFC 4119. The format is based on the civic
address definition in PIDF-LO, but adds several new elements based on
the civic types defined for Dynamic Host Configuration Protocol
(DHCP), and adds a hierarchy to address complex road identity
schemes. The format also includes support for the xml:lang language
tag and restricts the types of elements where appropriate.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5167
03/2008
(9 p.)
[html]
[pdf(2)] |
M. Dolly
R. Even |
MEDIACTRL |
|
Media Server Control Protocol Requirements |
This document addresses the communication between an application
server and media server. The current work in IETF working groups
shows these logical entities, but it does not address the physical
decomposition and the protocol between the entities.
This document presents the requirements for a Media Server Control
Protocol (MCP) that enables an application server to use a media
server. It will address the aspects of announcements, Interactive
Voice Response, and conferencing media services.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
