Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
RFC 5366

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                       G. Camarillo
Request for Comments: 5366                                      Ericsson
Category: Standards Track                                    A. Johnston
                                                                   Avaya
                                                            October 2008

        Conference Establishment Using Request-Contained Lists
                in the Session Initiation Protocol (SIP)

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.

Abstract

   This document describes how to create a conference using SIP URI-list
   services.  In particular, it describes a mechanism that allows a User
   Agent Client to provide a conference server with the initial list of
   participants using an INVITE-contained URI list.

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. User Agent Client Procedures ....................................2
      3.1. Response Handling ..........................................2
      3.2. Re-INVITE Request Generation ...............................3
   4. URI-List Document Format ........................................3
   5. Conference Server Procedures ....................................5
      5.1. Re-INVITE Request Handling .................................6
   6. Example .........................................................6
   7. Security Considerations ........................................10
   8. IANA Considerations ............................................10
   9. Acknowledgments ................................................11
   10. References ....................................................11
      10.1. Normative References .....................................11
      10.2. Informative References ...................................12

Camarillo & Johnston        Standards Track                     [Page 1]
RFC 5366                 INVITE-Contained Lists             October 2008

1.  Introduction

   Section 5.4 of [RFC4579] describes how to create a conference using
   ad hoc SIP [RFC3261] methods.  The client sends an INVITE request to
   a conference factory URI and receives the actual conference URI,
   which contains the "isfocus" feature tag, in the Contact header field
   of a response -- typically a 200 (OK) response.

   Once the UAC (User Agent Client) obtains the conference URI, it can
   add participants to the newly created conference in several ways,
   which are described in [RFC4579].

   Some environments have tough requirements regarding conference
   establishment time.  They require the UAC to be able to request the
   creation of an ad hoc conference and to provide the conference server
   with the initial set of participants in a single operation.  This
   document describes how to meet this requirement using the mechanism
   to transport URI lists in SIP messages described in [RFC5363].

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  User Agent Client Procedures

   A UAC that wants to include the set of initial participants in its
   initial INVITE request to create an ad hoc conference adds a body
   whose disposition type is 'recipient-list', as defined in [RFC5363],
   with a URI list that contains the participants that the UAC wants the
   conference server to invite.  Additionally, the UAC MUST include the
   'recipient-list-invite' option-tag (which is registered with the IANA
   in Section 8) in a Require header field.  The UAC sends this INVITE
   request to the conference factory URI.

   The INVITE transaction is also part of an offer/answer exchange that
   will establish a session between the UAC and the conference server,
   as specified in [RFC4579].  Therefore, the INVITE request may need to
   carry a multipart body: a session description and a URI list.

3.1.  Response Handling

   The status code in the response to the INVITE request does not
   provide any information about whether or not the conference server
   was able to bring the users in the URI list into the conference.
   That is, a 200 (OK) response means that the conference was created
   successfully, that the UAC that generated the INVITE request is in

Camarillo & Johnston        Standards Track                     [Page 2]
RFC 5366                 INVITE-Contained Lists             October 2008

   the conference, and that the server understood the URI list.  If the