datatracker.ietf.org
Sign in
Version 5.13.0, 2015-03-25
Report a bug

The Session Initiation Protocol (SIP) "Join" Header
RFC 3911

Document type: RFC - Proposed Standard (October 2004; No 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 3911 (Proposed Standard)
Responsible AD: Allison Mankin
Send notices to: rohan@cisco.com, dean.willis@softarmor.com

Network Working Group                                            R. Mahy
Request for Comments: 3911                                     Airespace
Category: Standards Track                                      D. Petrie
                                                                 Pingtel
                                                            October 2004

          The Session Initiation Protocol (SIP) "Join" 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 SIP multi-party
   applications and call control.  The Join header is used to logically
   join an existing SIP dialog with a new SIP dialog.  This primitive
   can be used to enable a variety of features, for example: "Barge-In",
   answering-machine-style "Message Screening" and "Call Center
   Monitoring".  Note that definition of these example features is non-
   normative.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Applicability of RFC 2804 ("Raven"). . . . . . . . . . . . .   3
   4.   User Agent Server Behavior: Receiving a Join Header  . . . .   4
   5.   User Agent Client Behavior: Sending a Join header  . . . . .   6
   6.   Proxy behavior . . . . . . . . . . . . . . . . . . . . . . .   7
   7.   Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
        7.1.  The Join Header  . . . . . . . . . . . . . . . . . . .   7
        7.2.  New option tag for Require and Supported headers . . .   8
   8.   Usage Examples . . . . . . . . . . . . . . . . . . . . . . .   8
        8.1.  Join accepted and transitioned to central conference .   9
        8.2.  Join rejected  . . . . . . . . . . . . . . . . . . . .  12
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  13
   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  14
        10.1. Registration of "Join" SIP header. . . . . . . . . . .  14

Mahy & Petrie               Standards Track                     [Page 1]
RFC 3911                        SIP Join                    October 2004

        10.2. Registration of "join" SIP Option-tag. . . . . . . . .  14
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  14
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  14
        12.1. Normative References . . . . . . . . . . . . . . . . .  14
        12.2. Informative References . . . . . . . . . . . . . . . .  15
   13.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  16
   14.  Full Copyright Statement . . . . . . . . . . . . . . . . . .  17

1. Introduction

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

   One use of the "Join" header is to insert a new participant into a
   multimedia conversation (which may be a two-party call or a SIP
   conference [15]).  While this functionality is already available
   using 3rd party call control [17], 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 an explicit Join header is needed in some cases instead of
   addressing an INVITE to a conference URI for the following reasons:

   o  A conference may not yet exist--the new invitation may be trying
      to join an ordinary two-party call.

   o  The party joining may not know if the dialog it wants to join is
      part of a conference.

   o  The party joining may not know the conference URI.

   The Join header enables services such as barge-in, real-time message
   screening, and call center monitoring in a distributed peer-to-peer
   way.  This list of services is not exhaustive.

   For example, the Boss has an established 2-party conversation with a
   Customer, and using some out-of-band mechanism (e.g., voice,
   gestures, or email) asks an Assistant to join the conversation.  The

[include full document text]