SIP Drafts: Extensions to Base Specification

The following drafts describe extensions that add features to SIP that are applicable to a range of applications, including reliable 1xx responses, early media cut-through, session timers. Other drafts provide detailed examples of call flows.

SIP Forked Media

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.

A SIP Extension: Informational Responses to the REFER method
R. Mahy
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).

Models for Multi Party Conferencing in SIP
J. Rosenberg, H. Schulzrinne
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.

SIP Requirements for support of Multimedia and Video

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.

Third Party Call Control for Resource Managemen

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.

Using SIP for Peer-to-Peer Third-Party Call Control
R. Mahy
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.

SIP Telephony Service Examples
Alan Johnston, Robert Sparks, Chris Cunningham, Steve Donovan, Kevin Summers
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.

SIP Extensions for supporting Distributed Call State
W. Marshall et al.
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.

SIP Record-Route/Route Hiding
B. Byerly, D. Daiker, S. Bhatnagar.br> October 2000.
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.

Diversion Indication in SIP
S. Levy, B. Byerly, J. Yang.
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.

SIP extension for tracking locations attempted
D. Oran, H. Schulzrinne.
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.

SIP for the establishment of xcast-based multiparty conferences
B. Van Doorselaer, D. Ooms.
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.

SIP Enabled Services to Support the Hearing Impaired
J. Rosenberg, H. Schulzrinne, H. Sinnreich.
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.

SCTP as a Transport for SIP
J. Rosenberg, H. Schulzrinne.
June 2000.

Guidelines for Authors of SIP Extensions
J. Rosenberg, H. Schulzrinne.
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.

Framework for SIP Call Control Extensions
Ben Campbell.
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.

Third party call control with SDP preconditions
G. Camarillo.
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.

Third Party Call Control in SIP
J. Rosenberg, H. Schulzrinne, J. Peterson, G. Camarillo
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.

Mandating SIP Extension Support by Servers
J. Rosenberg, H. Schulzrinne.
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.

Control of Service Context using SIP Request-URI
Ben Campbell and Robert Sparks.
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.

Session Initiation Protocol (SIP) Basic Call Flow Examples
A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers
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.

Management Information Base for Session Invitation Protocol
K. Lingle, J. Maeng, J. Mule, D. Walker.
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.

SIP Call Control: Transfer
Robert Sparks. February 2001.
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.

SIP 183 Session Progress Message
S. Donovan, H. Schulzrinne, J. Rosenberg, M. Cannon, A. Roach. October 1999.

Distributed Multipoint Conferences using SIP
J. Mark and K. Kelley. March 2000.

Reliability of Provisional Responses in SIP
Jonathan Rosenberg, Henning Schulzrinne.
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.

Providing for Multiple-Proxy Authentication of a SIP Request
R. Sparks. October 1999.

SIP Session Timer
S. Donovan, J. Rosenberg.
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.

The SIP PROPOSE Method
C. Ong, S. He

Transporting User Control Information in SIP REGISTER Payloads
Jonathan Lennox, Henning Schulzrinne; November 2000.
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.

Protocol Complications with the IP Network Address Translator (NAT) (includes sections on SIP and H.323)
M. Holdrege, P. Srisuresh

Requirements for SIP Servers and User Agents
Henning Schulzrinne

Last updated by Henning Schulzrinne