Mahesh Shankar
February 2001.
This document provides guidelines and examples for initiating "forked"
media sessions using multiple media description headers in the session
description of a SIP message. The presence of multiple media and
address description headers in the SDP implies that multiple media
streams are opened for the session in question based on the media
description headers.
November 2000
This document defines a SIP extension to the REFER method of the SIP
Call Control Framework. This extension provides for the ability to
convey information about the progress of the Referred request when that
request is in a provisional state for a long period of time (many
seconds or minutes).
November 2000.
The Session Initiation Protocol (SIP) can support multi-party
conferencing in many different ways. In this draft, we define the
various multi-party conferencing models, and for each, discuss how they
are used and then analyze their relative benefits and drawbacks.
O. Levin
February 2001.
This document outlines requirements for a call control protocol for
real-time multimedia support over IP. As a part of its broader scope,
the document examines important aspects of interactive video
communications that need to be addressed by a call control protocol for
real-time multimedia support and discusses techniques currently used to
deal with them. This document examines the way SIP/SDP/RTP/RTCP can be
used today to support multimedia sessions and to deal with some of the
presented requirements. In a small number of cases, this document
mentions possible directions to enhance SIP in order to add new required
functionality or to provide the same functionality in a more efficient
way.
F. Haerens
February 2001.
This document describes how to perform third party call control in SIP
for both a basic single-media and multi-media call when SDP
preconditions are used. This draft considers the Quality of Service and
the resource management. There are no new SIP extensions needed to
accomplish this. The mechanism outlined is illustrated with examples in
order to help understand it.
November 2000
The 3rd party call control draft demonstrates a usage of SIP with some
of the enhancements of RFC2543bis. This usage requires that a 3pcc
controller remain in the signaling path and maintain state for the
duration of the call. While this is necessary in certain situations
(ex: protocol translation: H.323 to SIP, SIP to RTSP, HTTP to SIP), it
is sub-optimal in pure SIP environments. This draft demonstrates a
usage of the REFER method and SIP for presence to allow authorized peers
to participate in call control. Note that much of the functionality
described in PHONECTL can be duplicated using the proposed usage. Also
note that this is not an extension of SIP, merely a usage of SIP and
existing extensions.
March 2001
This document gives examples of SIP (Session Initiation Protocol)
telephony services. This covers most features offered in so-called
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 third
party call control (3pcc) extensions such as the REFER method. 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.
November 2000.
This document describes an extension to the Session Initiation
Protocol (SIP) that enables proxies to distribute call state to user
agents. The state information can be returned to the proxy when the
user agent requests a change in the characteristics of the active
call. By providing the ability to distribute state to the user
agents where it can be securely stored, proxy servers can remain
stateless for the duration of the call. This mechanism allows a
proxy server to provide services that depend on call state, while
still being stateless.
This document describes a proposed extension to SIP. This document
proposes a mechansim to encrypt/hide Record-Route and Route entries in
or to support confidentiality of SIP proxy routing information. The
functionality of the Record-Route and Route headers are preserved. The
introduction of this extension allows a set of trusted SIP proxies to
cooperatively hide the route that SIP PDUs transit from untrusted
proxies and user agents.
November 2000.
This document proposes an extension to the Session Initiation Protocol
(SIP). This extension provides the ability for the called SIP user
agent to identify from whom the call was diverted and why the call was
diverted. The extension defines a new general header, Diversion, which
conveys the diversion information from other SIP user agents and proxies
to the called user agent. This extension allows enhanced support for
various features, including Unified Messaging, Third-Party Voicemail,
and Automatic Call Distribution (ACD). SIP user agents and SIP proxies
which receive diversion information may use this as supplemental
information for feature invocation decisions.
August 2000.
Proxying hides the destinations tried by the proxy. Since this
information is sometimes useful to the requestor, this draft proposes a
new optional SIP request header called Contacts-Tried listing the
locations tried unsuccessfully during a search.
July 2000.
Explicit Multicast (xcast) is a multicast scheme that uses an explicit
list of destinations instead of one logical multicast address. Explicit
Multicast complements the existing multicast schemes in that it can
efficiently support very large numbers of distinct (small) multicast
groups and thus can play an important role in making multicast practical
for applications such as multiparty IP telephony, various conferencing &
collaborative applications, multiparty networked games, etc... This
document explains how multiparty IP telephony conferences making use of
xcast can be established by SIP carrying SDP. Some open issues will be
identified and discussed. Possible extensions to SIP and SDP to
streamline the use of xcast will be suggested as well.
July 2000.
This document outlines a set of services enabled by the Session
Initiation Protocol (SIP), that allow for access to voice services by
people who are hearing impaired. SIP has gained much attention as a
tool for voice communications on the Internet. Therefore,
considerations for universal access of its services are important. This
document does not propose any extensions or new capabilities to SIP, but
rather a set of services enabled by it.
June 2000.
March 2001.
In WG last call until December 24, 2000
The Session Initiation Protocol (SIP) is a flexible, yet simple tool for
establishing interactive connections 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.
March 2001.
This document proposes that SIP call control features be added in a
modular fashion, using an open-ended framework of extensions instead of
a single extension. These extensions should be advertised and requested
following previously defined negotiation techniques. The document
continues to describe preferred call control extension design
philosophy.
July 2000.
This document describes how to perform third party call control in SIP
when SDP preconditions are used. There are no new SIP extensions needed
to accomplish this. The mechanism outlined is illustrated with an
example in order to help understand it.
March 2001.
This document discusses the usage of the Session Initiation Protocol
(SIP) for third party call control. Third party call control refers
to the ability of one entity to create a call in which communications
is actually between other parties. We present a SIP mechanism for
accomplishing third party call control that does not require any
extensions or changes to SIP.
February 2001. In IESG review
The Session Initiation Protocol (SIP) provides a mechanism that allows a
client to request that a particular protocol extension be used to
process the request. The server declines the request if it does not
support the extension. However, there is currently no way for a server
to determine which extensions are supported by the client. Knowing
about client-supported extensions allows the server to tailor its
response accordingly. Furthermore, SIP does not define a way for a
client to query a server about the extensions it supports. This
document defines a SIP extension that allows clients to indicate, in a
request, the set of extensions supported. We also define a mechanism
that allows clients, through an OPTIONS request, to determine the
extensions supported by a server.
April 2001.
This memo provides information for the Internet community. It describes
a useful way to conceptualize the use of the standard SIP (Session
Initiation Protocol) Request-URI (Uniform Resource Identifier) that the
authors and many members of the SIP community think is suitable as a
convention. It does not define any new protocol with respect to RFC
2543. In a conventional telephony environment, extended service
applications often use call state information, such as calling party,
called party, reason for forward, etc, to infer application context. In
a SIP/2.0 call, much of this information may be either non-existent or
unreliable. This document proposes a mechanism to communicate context
information to an application. Under this proposal, a client or proxy
can communicate context through the use of a distinctive Request-URI.
This document continues with examples of how this mechanism could be
used in a voice mail application.
January 2004.
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.
March 2001.
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) [17] devices, which include User
Agent, Proxy server, Redirect server and Registrar.
Note: This draft partially replaces the
expired draft-ietf-mmusic-sip-cc
This document defines a SIP extension within the new Call Control
Framework to provide Call Transfer capabilities.
This document specifies an extension to the Session Initiation
Protocol (SIP) providing reliable provisional response messages. This
extension uses the option tag org.ietf.sip.100rel.
November 2000.
This document proposes an extension to the Session Initiation
Protocol (SIP). This extension allows for a periodic refresh of SIP
sessions through a re-INVITE. The refresh allows both user agents and
call stateful proxies to determine in the SIP session is still
active. The extension defines a new general header, Session-Expires,
which conveys the lifetime of the session.
Several newly developed languages and interfaces, such as the CPL and
SIP CGI, allow users or administrators to specify how a SIP proxy and
redirect server should process calls. This document defines how SIP
REGISTER requests and responses can be used to transport scripts between
user agents and SIP proxy and redirect servers.
