|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
## SIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 7, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
## SIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
## SIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the SIP working group -- updated on August 22, 2006 --
is reported below.
|
|
|
|
The Session Initiation Protocol (SIP) working group is chartered to
maintain and continue the development of SIP, currently specified as
proposed standard RFC 3261, and its family of extensions.
SIP is a text-based protocol, similar to HTTP and SMTP, for
initiating interactive communication sessions between users. Such
sessions include voice, video, chat, interactive games, and virtual
reality. The main tasks of the group involve bringing SIP from
proposed to draft standard and specifying and developing proposed
extensions that arise out of strong requirements. The SIP working
group will concentrate on the specification of SIP and its
extensions, and will not explore the use of SIP for specific
environments or applications. It will, however respond to general-
purpose requirements for changes to SIP provided by other working
groups, including the SIPPING working group, when those requirements
are within the scope and charter of SIP. The process and
requirements for such extensions are documented in
RFC 3427, "Change
Process for the Session Initiation Protocol".
Throughout its work, the group will strive to maintain the basic
model and architecture defined by SIP. In particular:
|
|
| 1. |
Services and features are provided end-to-end whenever possible.
|
| 2. |
Standards-track extensions and new features must be generally
applicable, and not applicable only to a specific set of session types.
|
| 3. |
Simplicity is key.
|
| 4. |
Reuse of existing Internet protocols and architectures and integrating
with other Internet applications is crucial.
|
|
The primary source of change requirements to be considered by the SIP
Working Group is the SIPPING working group, which analyzes the
requirements for application of SIP to several different tasks,
including the tasks of standards-development organizations that are
developing systems based on SIP and that may require changes or
extensions thereto. Additional requirements are produced by the
other IETF working groups that are using SIP, including the SIMPLE WG
(which is using SIP for messaging and presence) and the XCON working
group (which is using SIP for centralized conferencing).
In addition to extending SIP as required to address these externally-derived
requirements, the deliverables of the group include assuring
capable security and privacy mechanisms within SIP and increasing the
stability of the SIP specification.
Specific deliverables toward
these goals include:
|
|
| 1. |
Mechanisms for secure expression of identity in requests and
responses.
|
| 2. |
Mechanism to securely request services delivery by non-terminal
elements ("end-to-middle").
|
| 3. |
Guidelines for use of existing security mechanisms such as TLS,
IPsec, and certificates.
|
| 4. |
Guidelines for the use of descriptive techniques such as SAML
(Security Association Markup Language) with SIP.
|
| 5. |
Draft standard versions of SIP and critical supporting
specifications.
|
|
|
Other deliverables may be agreed upon as extensions are understood to
be necessary. Prospective deliverables will be discussed with the
Area Director before inclusion on agendas, and new proposed work must
be approved via a charter update.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
## SIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
sip-consent-
framework-04
RFC Ed Queue (02/08)
Jan 31, 2008
(31 p.)
[pdf(2)]
[html]
|
J. Rosenberg
G. Camarillo
D. Willis |
|
A Framework for Consent-based Communications in SIP |
The Session Initiation Protocol (SIP) supports communications for
several services, 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 amplification, and DoS (Denial of
Service) attacks. This document identifies a framework for consent-
based communications in SIP.
This document defines the
"Trigger-Consent" and
"Permission-Missing"
header fields, as well as a new SIP response code:
'470 Consent Needed'.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-gruu-15
RFC Ed Queue (10/07)
Oct 11, 2007
(41 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in SIP |
Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI that can be used
by anyone on the Internet to route a call to that specific UA
instance. A URI that routes to a specific UA instance is called a
Globally Routable UA URI (GRUU). This document describes an
extension to SIP for obtaining a GRUU from a registrar and for
communicating a GRUU to a peer within a dialog.
This specification defines two new Contact header field parameter called
"pub-gruu" and
"temp-gruu",
the 'gruu' SIP option tag,
and one new SIP URI parameter:
"gr".
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
## SIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
sip-answermode-06
IESG Evaluation::
Revised ID Needed
Sep 5, 2007
(26 p.)
[pdf(2)]
[html]
|
D. Willis
A. Allen |
|
Requesting Answering Modes for SIP |
This document defines extends SIP with two header fields and
associated option tags that can be used in INVITE requests to convey
the requester's preference for user-interface handling related to
answering of that request. The first header,
"Answer-Mode",
expresses a preference as to whether the target node's user interface
waits for user input before accepting the request or instead accepts
the request without waiting on user input. The second header,
"Priv-Answer-Mode"
is similar to the first, except that it requests
administrative-level access and has consequent additional
authentication and authorization requirements. These behaviors have
applicability to applications such as Push-to-Talk and to diagnostics
like loop-back. Usage of each header field in a response to indicate
how the request was handled is also defined.
This specification defines the 'answermode' SIP option tag.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-certs-06
Publication Requested
Apr 5, 2008
(30 p.)
[pdf(2)]
[html]
|
C. Jennings
J. Fischl |
| Certificate Management Service for SIP |
This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP event
package to discover the certificates of other users. This mechanism
allows user agents that want to contact a given Address-of-Record
(AOR) to retrieve that AOR's certificate by subscribing to the
Credential Service, which returns an authenticated response
containing that certificate. The Credential Service also allows
users to store and retrieve their own certificates and private keys.
This document defines the 'certificate' and
'credential' SIP event packages. It also defines the
'application/pkcs8' MIME media type.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-e2m-sec-06
AD is watching
(Dead)
Jul 7, 2007
(30 p.)
[pdf(2)]
[html]
|
K. Ono
S. Tachimoto |
|
End-to-middle Security in SIP |
Some services provided by intermediaries depend on their ability to
inspect a message body in the Session Initiation Protocol (SIP).
When sensitive information is included in the message body, a SIP
User Agent (UA) needs to protect it from other intermediaries than
those that the UA agreed to disclose it to. This document proposes a
mechanism for securing information passed between an end user and
intermediaries using S/MIME. It also proposes mechanisms for a UA to
discover intermediaries which need to inspect an S/MIME-secured
message body, or to receive the message body with data integrity.
This document defines the
"Proxy-Required-Body"
header field, two new SIP response codes:
'495 Signature Required',
'496 Proxy Undecipherable', and a new warn-code:
'380 Required to View Content-Type'.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-fork-loop-fix-06
AD is watching
Mar 7, 2007
(13 p.)
[pdf(2)]
[html]
|
R. Sparks
S. Lawrence
A. Hawrylyshen
B. Campen |
|
Addressing an Amplification Vulnerability in SIP
Forking Proxies |
This document normatively updates RFC 3261, the Session Initiation
Protocol (SIP), to address a security vulnerability identified in SIP
proxy behavior. This vulnerability enables an attack against SIP
networks where a small number of legitimate, even authorized, SIP
requests can stimulate massive amounts of proxy-to-proxy traffic.
This document strengthens loop-detection requirements on SIP proxies
when they fork requests (that is, forward a request to more than one
destination). It also corrects and clarifies the description of the
loop-detection algorithm such proxies are required to implement.
Additionally, this document defines a Max-Breadth mechanism for
limiting the number of concurrent branches pursued for any given
request.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-location-
conveyance-10
AD is watching
Feb 24, 2008
(44 p.)
[pdf(2)]
[html]
|
J. Polk
B. Rosen |
|
Location Conveyance for SIP |
This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The extension covers end to end
conveyance as well as location-based routing, where proxy servers
make routing decisions based on the location of the SIP user agents.
This document defines the
"Geolocation"
header field,
the 'geolocation' SIP option tag,
and a new SIP response code:
'424 Bad Location Information'.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-sips-08
Publication Requested
Feb 23, 2008
(57 p.)
[pdf(2)]
[html]
|
F. Audet |
|
The use of the SIPS URI Scheme in SIP |
This document provides clarifications and guidelines concerning the
use of the SIPS URI scheme in the Session Initiation Protocol (SIP).
It also makes normative changes to SIP. This document also provides
a discussion of possible future steps in specification.
This specification registers two new response codes, namely 418 (SIPS
Not Allowed) and 419 (SIPS Required).
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-uri-list-
message-03
Waiting for Writeup::
External Party
Dec 21, 2007
(19 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
G. Camarillo |
|
Multiple-Recipient MESSAGE Requests in SIP |
This document specifies a mechanism that allows a SIP User Agent
Client (UAC) to send a SIP MESSAGE request to a set of destinations,
by using a SIP URI-list (Uniform Resource Identifier list) service.
The UAC sends a SIP MESSAGE request that includes the payload along
with the URI list to the MESSAGE URI-list service, which sends a
MESSAGE request including the payload to each of the URIs included in
the list.
This document defines the 'recipient-list-message'
SIP option tag.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
sip-uri-list-
subscribe-02
Waiting for Writeup::
External Party
Nov 13, 2007
(11 p.)
[pdf(2)]
[html]
|
G. Camarillo
A. Roach
O. Levin |
| Subscriptions to Request-Contained
Resource Lists in SIP |
This document specifies a way to create subscription to a list of
resources in SIP. This is achieved by including the list of
resources in the body of a SUBSCRIBE request. Instead of having a
subscriber send a SUBSCRIBE request for each resource individually,
the subscriber defines the resource list, subscribes to it, and gets
notifications about changes in the resources' state using a single
SUBSCRIBE dialog.
This document defines the 'recipient-list-subscribe'
SIP option tag,
and a new Call-Info header field parameter called
"list-management".
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
rosenberg-sip-
app-media-tag-02
Waiting for Writeup::
AD Follow up
Nov 12, 2007
(9 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
A SIP Media Feature Tag for MIME Application Sub-Types |
The caller preferences specification for the Session Initiation
Protocol (SIP) allows a caller to express preferences that the call
be routed to a User Agent (UA) with particular capabilities.
Similarly, a specification exists to allow a UA to indicate its
capabilities in a registration. Amongst those capabilities are the
type of media streams the agent supports, described as top-level MIME
types. The 'application' MIME type is used to describe a broad range
of stream types, and provides insufficient granularity as a
capability. This specification allows a UA to indicate which
application sub-types the agent supports.
This specification adds a new media feature tag ('sip.app-subtype') to the SIP Media
Feature Tag Registration Tree defined in RFC 3840.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
## SIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
sip-connect-
reuse-09
ID Exists
Feb 8, 2008
(20 p.)
[pdf(2)]
[html]
|
R. Mahy
V. Gurbani
B. Tate |
| Connection Reuse in SIP |
This document enables a pair of communicating proxies to reuse a
congestion-controlled connection between themselves for sending
requests in the forward and backwards direction. Because the
connection is essentially aliased for requests going in the backwards
direction, reuse should be predicated upon both the communicating
endpoints authenticating themselves using X.509 certificates through
TLS. For this reason, we only consider connection reuse for TLS over
TCP and TLS over SCTP. A single connection cannot be reused for the
TCP or SCTP transport between two peers, and this document provides
insight into why this is the case. As a remedy, it suggests using
two TCP connections (or two SCTP associations), each opened pro-
actively towards the recipient by the sender. Finally, this document
also provides guidelines on connection reuse and virtual SIP servers
and the interaction of connection reuse and DNS SRV lookups in SIP.
This specification defines a new Via header field parameter called
"alias".
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
sip-domain-certs-00
ID Exists
Nov 8, 2007
(15 p.)
[pdf(2)]
[html]
|
V. Gurbani
S. Lawrence
A. Jeffrey |
|
Domain Certificates in SIP |
|
This document describes how to interpret certain information in a
X.509 PKIX-compliant certificate used in a Transport Layer Security
(TLS) connection. More specifically, it describes how to find the
right identity for authentication in such certificates and how to use
it for mutual authentication.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
sip-dtls-srtp-
framework-01
ID Exists
Feb 23, 2008
(29 p.)
[pdf(2)]
[html]
|
J. Fischl
H. Tschofenig
E. Rescorla |
|
Framework for Establishing an SRTP Security Context using DTLS |
|
This document specifies how to use the Session Initiation Protocol
(SIP) to establish an Secure Real-time Transport Protocol (SRTP)
security context using the Datagram Transport Layer Security (DTLS)
protocol. It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake. It relies
on the SIP identity mechanism to ensure the integrity of the
fingerprint attribute. The key exchange travels along the media path
as opposed to the signaling path.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
sip-hitchhikers-
guide-05
ID Exists
Feb 24, 2008
(42 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
A Hitchhiker's Guide to SIP |
|
The Session Initiation Protocol (SIP) is the subject of numerous
specifications that have been produced by the IETF. It can be
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP. This specification serves
as a guide to the SIP RFC series. It lists the specifications under
the SIP umbrella, briefly summarizes each, and groups them into
categories.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
| | |
sip-outbound-13
ID Exists
Mar 21, 2008
(52 p.)
[pdf(2)]
[html]
|
C. Jennings
R. Mahy |
|
Managing Client Initiated Connections in SIP |
The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections and send asynchronous UDP datagrams to User
Agents in order to deliver requests. However, many practical
considerations, such as the existence of firewalls and Network
Address Translators (NATs), prevent servers from connecting to User
Agents in this way. This specification defines behaviors for User
Agents, registrars and proxy servers that allow requests to be
delivered on existing connections established by the User Agent. It
also defines keep alive behaviors needed to keep NAT bindings open
and specifies the usage of multiple connections from the User Agent
to its Registrar.
This specification defines
the 'outbound' SIP option tag,
and a new Contact header field parameter called
"reg-id".
It also defines a new media feature tag: sip.instance, a new response code: 430 Flow Failed, as well as new SIP/SIPS URI parameters: keep-crlf, keep-stun, timed-keepalive, and ob.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
| | |
sip-record-route-
fix-02
ID Exists
Feb 22, 2008
(26 p.)
[pdf(2)]
[html]
|
T. Froment
C. Lebel
|
|
Addressing Record-Route issues in SIP |
|
A typical function of a Session Initiation Protocol (SIP) Proxy is to
set a Record-Route header on initial requests in order to make
subsequent requests pass through it. This header contains a SIP
Uniform Resource Identifier (URI) indicating where and how the
subsequent requests should be sent to reach the proxy. Like any SIP
URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and
URI parameters that could influence the routing like different
transport parameters (UDP, TCP, SCTP...), or a compression indication
like "comp=sigcomp". When a proxy has to change some of those
parameters between its incoming and outgoing interfaces (multi-homed
proxies, transport protocol switching, sip to sips or IPV4 to IPV6
scenarios...), the question arises on what should be put in Record-
Route header(s). It is just not possible to make one header having
the characteristics of both sides at the same time. This document
aims to clarify these scenarios and fix bugs already identified on
this topic; it formally recommends the use of the double Record-Route
technique as an alternative to the current RFC3261 text, which
describes only a Record-Route rewriting solution.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
sip-saml-03
ID Exists
Nov 18, 2007
(43 p.)
[pdf(2)]
[html]
|
H. Tschofenig
J. Hodges
J. Peterson
J. Polk
D. Sicker |
|
SIP SAML Profile and Binding |
This document specifies a Session Initiation Protocol (SIP) profile
of Security Assertion Markup Language (SAML) as well as a SAML SIP
binding. The defined SIP SAML Profile composes with the mechanisms
defined in the SIP Identity specification and satisfy requirements
presented in "Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)".
This specification defines a
new SIP response code: '425 Bad SAML Assertion'
and a new Reason protocol value: 'SAML'.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
sip-session-policy-
framework-03
ID Exists
Apr 27, 2008
(35 p.)
[pdf(2)]
[html]
|
V. Hilt
G. Camarillo
J. Rosenberg |
|
A Framework for SIP Session Policies |
Proxy servers play a central role as an intermediary in the Session
Initiation Protocol (SIP) as they define and impact policies on call
routing, rendezvous, and other call features. This document
specifies a framework for SIP session policies that provides a
standard mechanism by which a proxy can define or influence policies
on sessions, such as the codecs or media types to be used. It
defines a model, an overall architecture and new protocol mechanisms
for session policies.
This document defines the
"Policy-Id" and
"Policy-Contact"
header fields, as well as
the 'policy'
SIP option tag.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
sip-subnot-etags-02
ID Exists
Feb 25, 2008
(24 p.)
[pdf(2)]
[html]
|
A. Niemi |
|
An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification |
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures have a serious
deficiency in that they provide no tools to avoid replaying event
notifications that have already been received by a user agent. This
memo defines an extension to SIP events that allows the subscriber to
condition the subscription request to whether the state has changed
since the previous notification was received. When such a condition
is true, either the body of a resulting event notification or the
entire notification message is suppressed.
This document defines the
"Suppress-Body-If-Match" and
"Suppress-Notify-If-Match"
header fields, as well as
the 'subnot-etags'
SIP option tag, and the '204 No Notification' response code.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
