datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

The Session Initiation Protocol (SIP) "Replaces" Header
RFC 3891

Document type: RFC - Proposed Standard (September 2004; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3891 (Proposed Standard)
Responsible AD: Allison Mankin
Send notices to: <dean.willis@softarmor.com>, <rohan@cisco.com>

Network Working Group                                            R. Mahy
Request for Comments: 3891                           Cisco Systems, Inc.
Category: Standards Track                                       B. Biggs
                                                                 R. Dean
                                                          September 2004

        The Session Initiation Protocol (SIP) "Replaces" Header

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document defines a new header for use with Session Initiation
   Protocol (SIP) multi-party applications and call control.  The
   Replaces header is used to logically replace an existing SIP dialog
   with a new SIP dialog.  This primitive can be used to enable a
   variety of features, for example: "Attended Transfer" and "Call
   Pickup".  Note that the definition of these example features is non-
   normative.

Mahy, et al.                Standards Track                     [Page 1]
RFC 3891               The SIP "Replaces" Header          September 2004

Table of Contents

   1.  Overview. . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  User Agent Server Behavior: Receiving a Replaces Header . . .   4
   4.  User Agent Client Behavior: Sending a Replaces Header . . . .   6
   5.  Proxy Behavior. . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  The Replaces Header . . . . . . . . . . . . . . . . . .   7
       6.2.  New Option Tag for Require and Supported Headers. . . .   8
   7.  Usage Examples. . . . . . . . . . . . . . . . . . . . . . . .   9
       7.1.  Replacing an Early Dialog at the Originator . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
       9.1.  Registration of "Replaces" SIP Header . . . . . . . . .  13
       9.2.  Registration of "replaces" SIP Option-tag . . . . . . .  13
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   11. References. . . . . . . . . . . . . . . . . . . . . . . . . .  13
       11.1. Normative References. . . . . . . . . . . . . . . . . .  13
       11.2. Informative References. . . . . . . . . . . . . . . . .  14
   12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  15
   13. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  16

1.  Overview

   This document describes a SIP [1] extension header field as part of
   the SIP multiparty applications architecture framework [10].  The
   Replaces header is used to logically replace an existing SIP dialog
   with a new SIP dialog.  This is especially useful in peer-to-peer
   call control environments.

   One use of the "Replaces" header is to replace one participant with
   another in a multimedia conversation.  While this functionality is
   already available using 3rd party call control [11] style call
   control, the 3pcc model requires a central point of control which may
   not be desirable in many environments.  As such, a method of
   performing these same call control primitives in a distributed,
   peer-to-peer fashion is very desirable.

   Use of a new INVITE with a new header for dialog matching was chosen
   over making implicit associations in an incoming INVITE based on
   call-id or other fields for the following reasons:

   o  An INVITE already has the correct semantics for a new call

   o  Using an explicit Replaces header in a new request makes the
      intent of the request obvious.

Mahy, et al.                Standards Track                     [Page 2]
RFC 3891               The SIP "Replaces" Header          September 2004

   o  A unique call-id may be given to the replacement call.  This
      avoids dialog matching problems in any of the related User Agents.

   o  There are no adverse effects if the header is unsupported.

   The Replaces header enables services such as attended call transfer,
   retrieve from park, and transition from locally mixed conferences to
   two party calls in a distributed peer-to-peer way.  This list of
   services is not exhaustive.  Although the Replaces header is

[include full document text]