?
Abstract: This document defines basic terminology for describing different
types of NAT behavior when handling Unicast UDP and also defines a set of
requirements that would allow many applications, such as multimedia
communications or on-line gaming, to work consistently. Developing NATs that
meet this set of requirements will greatly increase the likelihood that these
applications will function properly.
?
Abstract: This document outlines the motivation and requirements for a
Peer-to-Peer (P2P) based approach for SIP registration and resource discovery
using distributed hash tables, and presents the architectural design for such a
system. This design removes the need for central servers from SIP, while
offering full backward compatibility with SIP, allowing reuse of existing
clients, and allowing P2P enabled nodes to communicate with conventional SIP
entities. A basic introduction to the concepts of P2P is presented, backward
compatibility issues addressed, and the security considerations are considered.
This is very early work to explore the characteristics that a P2P system might
have. It is less secure in many ways than the traditional approach to SIP but
has certain other interesting characteristics that may make it desirable in some
situations. This work is being discussed on the sipping@ietf.org mailing
list.
?
Abstract: This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the context of
a session. Message sessions are treated like any other media stream when setup
via a rendezvous or session setup protocol such as the Session Initiation
Protocol.
?
Abstract: The SIMPLE Working Group uses two separate models for conveying
instant messages. Pager-mode messages stand alone and are not part of a SIP
(Session Initiation Protocol) session, whereas Session-mode messages are set up
as part of a session using the SIP protocol. MSRP (Message Sessions Relay
Protocol) is a protocol for near-real-time, peer-to-peer exchanges of binary
content without intermediaries, which is designed to be signaled using a
separate rendezvous protocol such as SIP. This document introduces the notion of
message relay intermediaries to MSRP and describes the extensions necessary to
use them.
?
Abstract: This draft describes some extensions for verifying SIP response
identity and enhancing SIP response authentication. Some mechanisms are
demonstrated for providing and verifying the identity of SIP responses. In order
to prevent several kinds of security attacks through SIP response, SIP response
authentication should be provided through a chain of trust of the SIP responses.
Some extensions are proposed to enhance the per-hop authentication for handling
SIP response. This draft is an early work in progress and suggests some
approaches but there is still significant discussion needed. Some of the attacks
discussed in this draft can be mitigated by using the sips URL.
? "Managing Client Initiated Connections
in the Session Initiation Protocol (SIP)", C. Jennings, R. Mahy, July 2005,
draft-ietf-sip-outbound-00
?
Abstract: 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 NATs, prevent servers from connecting to User Agents in this
way. Even when a proxy server can open a TCP connection to a User Agent, most
User Agents lack a certificate suitable to act as a TLS server. 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 for high availability
systems.
? "Certificate Management Service for The
Session Initiation Protocol (SIP)", C. Jennings, J. Peterson, July 2005, draft-ietf-sipping-certs-02
?
Abstract: This draft defines a Credential Service that allows SIP User Agents
to use a SIP 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. The
Credential Service also allows users to store and retrieve their own
certificates and private keys.
?
Abstract: IETF has several groups that are considering the impact of NATs on
various protocols. Having a classification of the types of NATs that are being
developed and deployed is useful in gauging the impact of various solutions.
This draft records the results of classifying NATs. This draft is not complete
and has only a few test results but it is worth discussing all the testing we
wish to do before all the test results are collected. The test results here are
very old and work is being done to update them with more current information.
This work is being discussed on the ietf-behave@list.sipfoundry.org mailing
list
?
Abstract: This document describes an extension to vCard to support Instant
Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming
increasingly common ways of communicating, and users want to save this contact
information in their address books. This draft allows a URI that is associated
with IM or PP to be specified inside of a vCard.
?
Abstract: This draft specifies how to use Datagram Transport Layer Security
(DTLS) as a transport for SIP. DTLS is a new protocol for providing TLS security
over a datagram protocol. This draft is being discussed on the sip@ietf.org
mailing list.
?
Abstract: One of the techniques used in SPAM prevention and various solutions
for denial of service attacks is to force the SIP client requesting a service to
perform a calculation that limits the rate and increases the cost of the
request. This draft defines a way to allow a UAS to ask the UAC to compute a
computationally expensive hash based function and present the result to the UAS.
Although the computation is expensive for the UAC to compute, it is cheap for
the UAS to verify. The solution also allows for proxies to compute and check the
puzzle on behalf of the UAC or UAS.
?
Abstract: This document shows call flows demonstrating the use of SIPS, TLS,
and S/MIME in SIP. This draft provides information that helps implementers build
interoperable SIP software. It is purely informational. To help facilitate
interoperability testing, it includes certificates used in the example call
flows and a CA certificate to create certificates for testing. This work is
being discussed on the sip@ietf.org mailing list.
?
Abstract: The SIP protocol is often used to initiate connections to voicemail
or unified messaging systems. This specification describes a convention for
forming SIP Service URIs that request particular services from unified messaging
systems.
?
Abstract: There are circumstances in SIP-based communications systems in which
it is useful to have a long-term, stable identifier for a particular user agent.
This specification outlines requirements and discusses existing standards that
can be used to satisfy this need.
?
Abstract: SIP needs a mechanism for general backwards compatibility for moving
from SDP to SDPng or moving from non end-to-end encrypted SDP to end-to-end
encrypted SDP. This document specifies how a SIP offer uses
multipart/alternative, and how an answer indicates which part was
selected.
?
Abstract: Communication systems require that a person receiving a call be able
able to charge the caller when they are from different administrative domains.
This is necessary for making fair exchanges of service between two different
communicating parties and is a major strategy for reducing the viability of
SPAM. This draft proposes an approach for doing this in SIP. The approach relies
on a third party to act as a payment service provider and is optimized for very
simple, low value transactions. It does not provide the full range of services
that are desirable in typical online trading systems. This draft is being
discussed on the sipping@ietf.org mailing list. There is currently work to
substantially change this draft to use SAML.
?
Abstract: Conference State Control Protocol (CSCP) is a means to modify the
state in a conference service. It extends the Binary Floor Control Protocol and
adds commands to get, set, add, and delete fields in the conference
state.
?
Abstract: Conference servers have many controls that change how the media is
combined for the various conference participants. It is necessary to describe
these controls to the clients connected to a centralized conference, so that the
clients can render a user interface and allow the user to manipulate them. This
work is being discussed on the xcon@ietf.org mailing list. This draft has not
changed since the 02 version.