SIPPING WG
   Internet Draft                                           A. Johnston
   Document:                                                   WorldCom
    draft-johnston-sipping-cc-conferencing-00.txt              O. Levin
                                                              RADVISION
   Expires: April 2003                                     October 2002


                Session Initiation Protocol Call Control -
                       Conferencing for User Agents


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.





Abstract

   This document describes providing Conferencing call control
   capabilities in the Session Initiation Protocol (SIP).  This document
   builds on the Conferencing Requirements and Framework documents to
   show how a tightly coupled SIP conference will work.  The approach is
   explored from a user agent (UA) perspective.  Three types of UAs are
   described: a conferencing unaware UA, one capable of being a full
   member of a conference, and one also capable of hosting a conference.
   The use of URIs in conferencing, OPTIONS for capability discovery,
   and call control using REFER are covered in detail with example call
   flow diagrams.




Johnston & Levin         Expires - April 2003                 [Page 1]


               SIP Call Control - Conferencing for UAs   October 2002


Conventions used in this document

   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 RFC-2119 [2].

Table of Contents

   1. Introduction...................................................2
   2. SIP Conferencing Vocabulary....................................3
   3. Conferencing URIs..............................................3
      3.1 Use of a General URI in Conferencing.......................3
      3.2 Focus SIP URI..............................................4
      3.3 Conference SIP URI.........................................4
      3.4 Globally Routable Contact Requirements.....................4
   4. SIP User Agent Conferencing Capability Types...................5
      4.1 Type I - Conference Unaware UA.............................5
      4.2 Type II - Conference Member Capable UA.....................5
      4.3 Type III - Conference Member and/or Focus Capable UA.......6
   5. Discovery of Conferencing Capabilities using OPTIONS...........6
      5.1 Requirements Review........................................6
      5.2 Definitions................................................7
      5.3 Examples...................................................8
   6. SIP Conferencing Implementation................................9
      6.1 SIP Conferencing Building Blocks...........................9
      6.2 Creating a Conference......................................9
      6.3 Creating a Conference by a Type I UA......................11
      6.4 Dialing into a Conference by Conference URI...............12
      6.5 Dial out - Added by the Focus.............................13
      6.6 Requesting the Focus Add a New Resource to a Conference...15
      6.7 Adding a 3rd Party Using Conference ID....................16
      6.8 Adding a 3rd Party Using Call ID..........................18
      6.9 Bringing a Point-to-Point Dialog into a Conference........19
   Security Considerations..........................................20
   References.......................................................20
   Acknowledgments..................................................21
   Author's Addresses...............................................21


1.   Introduction

   This document uses the concepts and definitions in the Session
   Initiation Protocol(SIP) [3] conferencing framework document [4] and
   the requirements in [5].  The call control and dialog manipulation
   approach is based on that outlined in the Multiparty Framework
   document [6].  That document defines the basic approach of service
   design adopted for SIP which includes:

   - Definition of primitives, not services


Johnston & Levin         Expires - April 2003                 [Page 2]


               SIP Call Control - Conferencing for UAs   October 2002


   - Participant oriented
   - Signaling model independent
   - Invoker oriented
   - Primitives make full use of URIs
   - Include authentication, authorization, logging, etc. policies
   - Define graceful fallback to baseline SIP.

   The use of opaque URIs and the ability to communicate call control
   context information within a URI (as opposed to service-related
   header fields), as discussed in RFC 3087 [7], is fundamental to this
   document.

   All cases begin with an assumption that a URI is known to a user
   agent.  Some SIP mechanisms for URI discovery are described here,
   including the use of OPTIONS and extracting URIs from Contact header
   fields.  However, other methods can be used and may be developed.
   For example, current work in the ENUM working group described in RFC
   2916bis [8] to include service tags in addition to protocols to map
   to a URI.  For further study is the idea to use a DNS SRV-like
   process to discover URIs relating to conferencing services.  Another
   idea is to use Service Location Protocol RFC 2608 [9] for this
   purpose.

2.   SIP Conferencing Vocabulary

   For the terminology and assumptions used in this document, refer to
   the conferencing requirements [5] and framework [4] documents.

   This document presents the basic call control (dial-in and dial-out)
   conferencing building blocks from the UA perspective. For
   illustration of the possible applications we refer to the application
   vocabulary of ad-hoc, scheduled, server and end user.

3.   Conferencing URIs

   A user agent that hosts conferences can have three types of URIs that
   resolve to it: a general URI, a focus URI and conference URIs. All
   three types assist in supporting different conferencing scenarios.
   The latter two are dedicated to conferencing.

   The general URI and focus URI are likely to be well known URIs in
   that they would be published

3.1    Use of a General URI in Conferencing

   Using a general URI (typically referred as the userÆs address of
   record), a focus can support creation, control, and manipulation of a
   conference in a similar manner to that common in PSTN today.



Johnston & Levin         Expires - April 2003                 [Page 3]


               SIP Call Control - Conferencing for UAs   October 2002


   In this kind of scenario, inclusion of the general URI in the
   Request-URI would lead to a human user (in an end point) or to an IVR
   service (in a conferencing server) for INVITEs generated from a
   conferencing unware UA as will be shown in the following sections.

3.2    Focus SIP URI

   Another type of URI is what we will call the focus URI.  An INVITE
   sent to the focus URI is a request to setup an ad-hoc conference, as
   will be shown in the following sections.

3.3    Conference SIP URI

   As specified in the conferencing framework document [4], the
   conference ID is a SIP URI. A URI which represents a particular
   conference instance is referred to as a conference URI.   A request
   sent to this URI will result in a member being added (or removed,
   depending on the method) to (or from) a particular conference.

   As will be shown later, it can be discovered from Contact header
   field in an INVITE or 200 OK in the dialog establishment with a
   focus.  It can then be used in a Request-URI or Refer-To header field
   to add members to the conference.

3.4    Globally Routable Contact Requirements

   As was specified before, the Conference URI MUST be globally
   routable. Since, according to this document, the Contact header field
   is used to convey this URI, this requires that Contact URIs from a
   focus be globally routable URIs.

   This requirement is identical to that in Section 8.1.1.8 in RFC 3261
   [3].  However, the specified use in conferencing of the Contact URI
   outside of a dialog makes satisfying this requirement critical.

   If the focus requires that all requests be routed through a proxy
   server, then special care MUST be taken with the creation of this
   Contact URI.  To satisfy this requirement, the Contact URI MUST
   either route to the proxy server or resolve to the proxy server, with
   an additional SIP registration step being required to further resolve
   this URI to the specific device.

   For example, consider a focus with a hostname server51.chicago.com
   which creates a conference URI.  A normal Contact could be of the
   form:

      Contact: <sip:389390542457@serv51.chicago.com>;isFocus




Johnston & Levin         Expires - April 2003                 [Page 4]


               SIP Call Control - Conferencing for UAs   October 2002


   (The "isFocus" parameter is described in Section 5.2 below.)
   However, if this focus requires that all requests come through a
   proxy server at p1.chicago.com then this Contact will not work as the
   proxy will be bypassed.  One approach is to include an escaped loose
   Route header field in the Contact URI:

    Contact: <sip:389390542457@serv51.chicago.com
                             ?Route=sip:p1.chicago.com;lr>;isFocus

   This would result in a request being sent to
   sip:389390542457@serv51.chicago.com with a loose Route header forcing
   routing to sip:p1.chicago.com first.

     EditorÆs Note: Open Issue: This syntax, while allowed in a
     redirection, is not permitted in an INVITE or 200 OK response per
     Table 1 in RFC 3261.

   Another approach would involve a Contact of the form:

      Contact: <sip:389390542457@chicago.com>;isFocus

   in which this sip:389390542457@chicago.com URI would be registered by
   the focus against a Contact:

      Contact: <sip:389390542457@serv51.chicago.com>

   which resolves directly to the focus.  Other approaches may also be
   used to generate this globally routable Contact URI.

4.   SIP User Agent Conferencing Capability Types

   We can identify three different SIP user agent (UA) applications
   regarding their conferencing capabilities.

4.1    Type I - Conference Unaware UA

   The simplest user agent can participate in a conference ignoring all
   SIP conferencing-related information. The simplest user agent is able
   to dial into a conference and to be invited to a conference. All
   conferencing information (if any) is conveyed to it using non-SIP
   means. Such s user agent would not usually host a conference (at
   least, not using SIP explicitly).  A Type I UA need only support RFC
   3261 [3].  Call flows for Type I UAs are not shown in general in this
   document as they would be identical to those in the SIP Call Flows
   document [10].

4.2    Type II - Conference Member Capable UA




Johnston & Levin         Expires - April 2003                 [Page 5]


               SIP Call Control - Conferencing for UAs   October 2002


   A Type II user agent can support SIP conferencing conventions and
   extensions merely as a conference member. Such user agents do not
   have focus capabilities.

   From a SIP requirements perspective, a Type II UA would support REFER
   [11], SIP Events [12], the conferencing package [13], and the
   conventions of conferencing call control defined in this document, in
   addition to support of RFC 3261.

4.3    Type III - Conference Member and/or Focus Capable UA

   The next level of user agents is capable of both being a conference
   member and a conference focus. This is a special capability and can
   be discovered using the techniques described in Section 5.

   A user agent of this type could be implemented in end user equipment
   and would be used for ad-hoc creation of small to middle size
   conferences.

   Alternatively, a type III UA could be a dedicated conferencing server
   whose primary task is to host conferences of any type and size. Note
   that a certain conference instance can bridge members having
   different capabilities who have joined the conference by different
   means (i.e. dial-in, dial-out, scheduled and ad-hoc).

   A conference server typically will not be a single device but a
   function decomposed into media servers, IVR systems, etc as described
   in the Application Components document [14].  In this document,
   however, it will be discussed as if it were a UA with certain focus
   capabilities.

   A conference server will likely have all three types of URIs (as
   specified above) that resolve to it: a general URI, a focus URI, and
   conference URIs.

5.   Discovery of Conferencing Capabilities using OPTIONS

   The general means of capability discovery in SIP is the OPTIONS
   method as detailed in Section 11 of RFC 3261 [3].  This same method
   can be used by a user agent to discover conferencing capabilities.

5.1    Requirements Review

   Currently the only requirement is to distinguish between Type I/II
   vs. Type III user agents. Should additional conferencing extensions
   defined in future, means to distinguish between Type I vs. Type II
   user agents may be required.




Johnston & Levin         Expires - April 2003                 [Page 6]


               SIP Call Control - Conferencing for UAs   October 2002


5.2    Definitions

   A UA MAY send an OPTIONS request to discover the conferencing
   capabilities of another UA. If the UA responding to the query has
   conferencing-related capabilities and wants to share this
   information, it can do so in the reply to the OPTIONS request.

   If the UA identified by the general URI in the OPTIONS request has an
   ability to act as a focus, the OPTIONS response SHOULD indicate this
   by the inclusion of the focus URI with "isFocus" caller prefs
   parameter [15] in a Contact header field.

      EditorÆs Note: This Contact header field "isFocus" parameter is
      currently not defined in the base caller prefs [Error! Bookmark
      not defined.] document, but needs be added as an extension.

   This OPTIONS request can be sent outside a dialog (pre-call) or
   within an established dialog (mid-call). In both cases, inclusion of
   the "isFocus" parameter in a Contact header in the reply to the
   OPTIONS request expresses the ability of the UA to host a conference
   (i.e. having focus capabilities) as opposite to having a focus active
   for this call.

   A UA receiving an OPTIONS request SHOULD generate a well-formed
   response containing Allow, Accept, Allow-Events, and Supported, and
   Contact header fields.

   An OPTIONS query sent to either a general or focus URIs would likely
   return Contact URIs listing both the general URI and the focus URI.

   An OPTIONS query to the general or focus URI would not return a list
   of active conference URIs hosted by the server. This information can
   be retrieved using a method TBD.

      OPEN ISSUE: In general, nothing in this specification prohibits
      conference URIs discovery using the OPTIONS method. That being
      said, currently, there is no way to distinguish between focus URI
      and conference URI: an OPTIONS sent to a particular conference URI
      would return a response containing that conference URI in a
      Contact containing the "isFocus" parameter, same as for a focus
      URI.

      OPEN ISSUE: Should an OPTIONS request sent to a conference URI not
      return the focus URI? Or the general URI?

   Note that the Allow, Accept, Allow-Events, and Supported header
   fields should be present in an INVITE from a focus or a 200 OK answer
   from the focus to an INVITE as a part of a normal dialog
   establishment process. Inclusion of the Contact header with "isFocus"


Johnston & Levin         Expires - April 2003                 [Page 7]


               SIP Call Control - Conferencing for UAs   October 2002


   parameter by the focus signals to a UA that the dialog is a part of a
   conference identified by the URI in the Contact header.

5.3    Examples

   This section contains an example response to an OPTIONS request sent
   by Alice to Carol (sent to Carol's address of record, i.e. general
   URI).  Based on the response, Alice's UA learns that Carol's UA has
   conferencing and focus capabilities (Type III UA), and learns the
   focus URI which could be used later to invoke conferencing services.

   The response details are as follows:

         SIP/2.0 200 OK
         Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
          ;received=192.0.2.4
         To: <sip:carol@chicago.com>;tag=93810874
         From: Alice <sip:alice@atlanta.com>;tag=1928301774
         Call-ID: a84b4c76e66710
         CSeq: 63104 OPTIONS
         Contact: <sip:carol@chicago.com>
         Contact: <sip:carolsfocus@chicago.com>;isFocus
         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
          SUBSCRIBE, NOTIFY
         Allow-Events: refer, conference
         Accept: application/sdp, application/conference-info+xml,
          message/sipfrag
         Accept-Language: en
         Supported: pref, replaces
         Content-Type: application/sdp
         Content-Length: 274

         (SDP not shown)

   Useful information from each of these headers is detailed in the next
   sections.

   Allow.  The support of methods such as REFER, SUBSCRIBE, and NOTIFY
   indicate that the user agent supports call control and SIP Events.

   Accept.  The support of bodies such as message/sipfrag,
   application/conference-info+xml also indicates support of call
   control and conferencing.

   Allow-Events. The support of event packages such as refer,
   conference.

   Supported.  The support of extensions such as caller prefs [Error!
   Bookmark not defined.] and replaces [16].


Johnston & Levin         Expires - April 2003                 [Page 8]


               SIP Call Control - Conferencing for UAs   October 2002



      Editor's Note:  If an extension tag for some TBD conferencing
      related extensions is defined, it would be present here.

   Contact.  This OPTIONS response contains two Contact header fields.
   The first one is just Carol's address of record (i.e. the general
   URI) for session establishment, etc.  The second Contact URI is the
   URI of Carol's focus.  This can be determined by the presence of the
   "isFocus" caller preferences [Error! Bookmark not defined.]
   parameter.  The presence of a Contact with this parameter confirms
   that Carol's UA is a Type III UA.

6.   SIP Conferencing Implementation

   Note that most the scenarios described below apply equally for ad-hoc
   or reserved conference, with the exception of Sections 6.2 and 6.3 on
   creating a conference which does not apply to a reserved conference.

6.1    SIP Conferencing Building Blocks

   The scenarios presented below are the call control building blocks
   for various SIP tight conferencing applications as described in the
   conferencing requirements [5] and framework documents [4]. In the
   sections below we present typical SIP conferencing call control flows
   and discuss the applicability of each for different conferencing
   situations. The major design goal is that the same SIP conferencing
   building blocks would be used by user agents having different
   conferencing capabilities and comprising different applications.

6.2    Creating a Conference

   This section addresses creating an ad-hoc conference by interaction
   with a focus URI with the focus being responsible for the conference
   ID generation.

   This approach requires awareness of conferencing information from the
   members. Only a Type II UA will know to retrieve the conference
   information (from the Contact header) and use it for adding new
   members.

   The benefit of this approach is that the details and conventions of
   the deployed conferencing infrastructure are transparent to the
   members (and the participating users), since they treat the
   Conference ID merely as an opaque URI. That allows for building
   automated end user applications in a play-and-plug manner.

   To create a conference, a UA SHOULD send an INVITE (with the Request-
   URI set to the focus URI) to the focus that will host the conference.



Johnston & Levin         Expires - April 2003                 [Page 9]


               SIP Call Control - Conferencing for UAs   October 2002


   The SIP URI of the focus can be provisioned in the UA or can be
   discovered using any of the means described earlier in this document.

   The focus can distinguish this INVITE request as a request to create
   a new ad-hoc conference from a request to join an existing conference
   by the Request-URI.  In this flow, the focus is a Type III UA, so it
   maintains different types of URIs as discussed in the previous
   sections.

   Assuming that all security and policy requirements have been met, the
   focus SHOULD create the conference with the Contact URI returned in
   the 200 OK being the conference URI.  The Contact header field SHOULD
   contain the "isFocus" parameter to indicate that this URI is for a
   conference.

   The UA creating the conference SHOULD send a SUBSCRIBE to the
   conference URI with the conference event package.

   An example call flow is shown in Figure 1. Note that Focus is
   shorthand for the focus URI and Conf-ID Is short for the conference
   URI.  In this flow, Alice creates a conference by sending an INVITE
   to the focus URI.  Once the media session is established, Alice
   subscribes to the conference URI obtained through the Contact in the
   200 OK response from the focus.


     Alice                Focus                 Bob                Carol
       |                    |                    |                    |
       | Alice creates the conference.           |                    |
       |                    |                    |                    |
       | INVITE sip:Focus F1|                    |                    |
       |------------------->|                    |                    |
       |   180 Ringing F2   |                    |                    |
       |<-------------------|                    |                    |
       |   200 OK Contact:Conf-ID;isFocus F3     |                    |
       |<-------------------|                    |                    |
       |        ACK F4      |                    |                    |
       |------------------->|                    |                    |
       |        RTP         |                    |                    |
       |<==================>|                    |                    |
       |                    |                    |                    |
       | Alice subscribes to the conference URI. |                    |
       |                    |                    |                    |
       | SUBSCRIBE sip:Conf-ID F5                |                    |
       |------------------->|                    |                    |
       |     200 OK F6      |                    |                    |
       |<-------------------|                    |                    |
       |     NOTIFY F7      |                    |                    |
       |<-------------------|                    |                    |


Johnston & Levin         Expires - April 2003                [Page 10]


               SIP Call Control - Conferencing for UAs   October 2002


       |     200 OK F8      |                    |                    |
       |------------------->|                    |                    |

   Figure 1. Creation of a Conference.


6.3    Creating a Conference by a Type I UA

   It is a requirement that a Type I UA be able to create and add
   participants to a conference without understanding any of the
   conferencing conventions or extensions (such as in Section 6.2
   above).  The only way to accomplish this is for the participant
   (human) to choose the conference URI in the domain of the focus URI.
   The disadvantages of this approach are discussed later in the
   section.

   A user (human) would choose a conference URI according to system
   rules and insert it into the Request-URI of the INVITE. This same URI
   is echoed by a focus adhering to certain conventions (discussed
   below) in the Contact header by the focus.  Additional members could
   be added by non-SIP means (publication of the chosen conference URI
   using web pages, email, IM, etc.).  Alternatively, the Type I UA
   could then add other participants to the conference using SIP call
   control by establishing a session with them, then transferring them
   to the conference URI [17].  Note that only the participant (human)
   is aware of the conferencing application, and the Type I UA only need
   support RFC 3261 and optionally call transfer.

   Making this work does impose certain requirements on a focus. As a
   service/implementation choice, a focus could allow the creator of the
   conference to choose the user portion of the conference URI. However,
   this requires URI and behavior conventions to be used by both members
   and the focus.

   For example, a service might reserve the domain conf.example.com for
   all conference URIs.  The focus URI could be
   sip:focus@conf.example.com.  The focus could be configured to
   interpret an unknown Request-URI in the conf.example.com domain as a
   request for a conference to be created with the conference URI as the
   Request-URI.  For example, an INVITE sent with a Request-URI of
   sip:k32934208ds72@conf.example.com could be routed to the focus who
   would then create a conference.  This conference URI should be
   registered by the focus to become routable as a conference URI within
   the conf.example.com domain.  The returned Contact would look as
   follows: <sip:k32934208ds72@conf.example.com>;isFocus.  Note,
   however, that this approach relies on conventions adopted between the
   participant (human) and the focus.




Johnston & Levin         Expires - April 2003                [Page 11]


               SIP Call Control - Conferencing for UAs   October 2002


   As a result, the method of the conference URI as an opaque URI being
   generated by the focus (as per Section 6.2) is preferred.

   To join an existing specific conference a UA SHOULD send an INVITE to
   the conference URI chosen by the first participant. The rest of this
   scenario is shown in Section 6.4.

   An example call flow is shown in Figure 2.  The participant Alice
   creates the conference URI (using some convention agreed to with the
   focus domain) and sends an INVITE to that URI which reaches the
   focus.  The focus creates the conference and returns the same
   conference URI in the 200 OK answer to the INVITE (which is ignored
   by the Type I UA).

     Alice                Focus                 Bob                Carol
       |                    |                    |                    |
       | Alice creates the conference and chooses the conference URI. |
       |                    |                    |                    |
       | INVITE sip:Conf-ID F1                   |                    |
       |------------------->|                    |                    |
       |   180 Ringing F2   |                    |                    |
       |<-------------------|                    |                    |
       |   200 OK Contact:Conf-ID;isFocus F3     |                    |
       |<-------------------|                    |                    |
       |        ACK F4      |                    |                    |
       |------------------->|                    |                    |
       |        RTP         |                    |                    |
       |<==================>|                    |                    |

   Figure 2. A Conferencing Unaware (Type I) UA Creates a Conference


6.4    Dialing into a Conference by Conference URI

   In this section a UA knows the conference URI and "dials in" to join
   this conference.  The conference URI can be reserved using non-SIP
   mechanisms, or generated using the methods of Sections 6.2 or 6.3.

   If the UA is the first member of the conference to dial in, it is
   likely that this INVITE will "create" the conference.  However, the
   conference URI must have been created prior to its use.

   When the conference is up and running already, the dialing-in member
   is joined to the conference by a focus.

   To join an existing specific conference a UA SHOULD send an INVITE to
   the conference URI.




Johnston & Levin         Expires - April 2003                [Page 12]


               SIP Call Control - Conferencing for UAs   October 2002


   Assuming that all security and policy requirements have been met, the
   focus SHOULD establish the session with the UA and "mix" the media
   appropriately with existing conference members.

   The UA SHOULD subscribe to the conference URI with the conference
   event package.

   The focus SHOULD notify other members that a new member has been
   added.

   An example call flow is shown in Figure 3.  It is assumed that Alice
   is already in the conference (has a session established with the
   focus).


     Alice                Focus                 Bob                Carol
       |                    |                                         |
       |<==================>|                                         |
       |                    |    Carol "dials in" to the conference   |
       |                    |                                         |
       |                    |              INVITE sip:Conf-ID F1      |
       |                    |<----------------------------------------|
       |                    |               180 Ringing F2            |
       |                    |---------------------------------------->|
       |                    |     200 OK Contact:Conf-ID;isFocus F3   |
       |                    |---------------------------------------->|
       |                    |                   ACK F4                |
       |                    |<----------------------------------------|
       |                    |                    RTP                  |
       |                    |<=======================================>|
       |                    |           SUBSCRIBE sip:Conf-ID F5      |
       |                    |<----------------------------------------|
       |                    |                  200 OK F6              |
       |                    |---------------------------------------->|
       |                    |                NOTIFY F7                |
       |                    |---------------------------------------->|
       |                    |                  200 OK F8              |
       |                    |<----------------------------------------|
       |     NOTIFY F9      |                                         |
       |<-------------------|                                         |
       |     200 OK F10     |                                         |
       |------------------->|                                         |

   Figure 3. A member "dials in" to an existing conference.


6.5    Dial out - Added by the Focus




Johnston & Levin         Expires - April 2003                [Page 13]


               SIP Call Control - Conferencing for UAs   October 2002


   This section is equally applicable for both ad-hoc and reserved
   conferences.

   To directly add a member to a conference, a focus SHOULD send an
   INVITE to the member containing a Contact header field with the
   conference URI and the ôisFocusö header parameter.  The resulting
   media session SHOULD be appropriately mixed with the media from the
   other members.

   The new member SHOULD subscribe to the conference ID from the Contact
   from the INVITE.

   The simplest UA (as in Type I) would simply ignore the conferencing
   information and treat the session (from a SIP perspective) as a point
   to point session.

   The focus SHOULD notify other participants that a new member has been
   added.

   An example call flow is shown in Figure 4.  It is assumed that Alice
   is already a member of the conference.  The focus invites Carol to
   the conference by sending an INVITE.  After the session is
   established, Carol subscribes to the conference URI.

     Alice                Focus                 Bob                Carol
       |                    |                    |                    |
       |<==================>|                    |                    |
       |                    |                                         |
       |           Focus "dials out" to add Carol to the conference   |
       |                    |                                         |
       |                    |     INVITE Contact:Conf-ID;isFocus F1   |
       |                    |---------------------------------------->|
       |                    |               180 Ringing F2            |
       |                    |<----------------------------------------|
       |                    |                  200 OK F3              |
       |                    |<----------------------------------------|
       |                    |                   ACK F4                |
       |                    |---------------------------------------->|
       |                    |                    RTP                  |
       |                    |<=======================================>|
       |                    |           SUBSCRIBE sip:Conf-ID F5      |
       |                    |<----------------------------------------|
       |                    |                  200 OK F6              |
       |                    |---------------------------------------->|
       |                    |                NOTIFY F7                |
       |                    |---------------------------------------->|
       |                    |                  200 OK F8              |
       |                    |<----------------------------------------|
       |     NOTIFY F9      |                                         |


Johnston & Levin         Expires - April 2003                [Page 14]


               SIP Call Control - Conferencing for UAs   October 2002


       |<-------------------|                                         |
       |     200 OK F10     |                                         |
       |------------------->|                                         |

   Figure 4. Focus "dials out" to add Carol to the conference.


6.6    Requesting the Focus Add a New Resource to a Conference.

   A SIP conference URI can be used to inject different kinds of
   information into the conference. Examples include new members, new
   real-time media sources, new IM messages, and pointers to passive
   information references (such as HTTP URIs).

   To request the focus add a new information resource to the specified
   conference, any SIP UA can send a REFER to the conference URI with a
   Refer-To containing the URI of the new resource.  Since this REFER is
   sent to the conference URI and not the focus URI, the semantics to
   the focus are to bring the resource into the conference and make it
   visible to the conference members. The resultant focus procedures are
   dependant both on the nature of the new resource (as expressed by its
   URI) and the own focus abilities regarding IM, central real time
   media processing, etc.

   The flow for adding a new UA member is important to consider because
   it works even if the new member does not support REFER and transfer
   call control - only the requesting member and the focus need to
   support the call control.

   Upon receipt of the REFER containing a Refer-To header with a SIP
   URI, the focus SHOULD send an INVITE to the new member identified by
   the Refer-To SIP URI containing a Contact header field with the
   conference URI and the "isFocus" header parameter.  The resulting
   media session SHOULD be appropriately mixed with the media from the
   other members.

   The new member SHOULD subscribe to the conference ID from the Contact
   from the INVITE.

   The simplest UA (as in Type I) would simply ignore the conferencing
   information and treat the session (from a SIP perspective) as a point
   to point session.

   The focus SHOULD notify other participants that a new member has been
   added.

   An example call flow is shown in Figure 5.  It is assumed that Alice
   is already a member of the conference.  Alice sends a REFER to the
   conference URI.  The focus invites Carol to the conference by sending


Johnston & Levin         Expires - April 2003                [Page 15]


               SIP Call Control - Conferencing for UAs   October 2002


   an INVITE.  After the session is established, Carol subscribes to the
   conference URI.

     Alice                Focus                 Bob                Carol
       |                    |                    |                    |
       |<==================>|                    |                    |
       | REFER sip:Conf-ID Refer-To:Carol F1     |                    |
       |------------------->|                                         |
       |  202 Accepted F2   |                                         |
       |<-------------------|                                         |
       |                    |                                         |
       |           Focus "dials out" to add Carol to the conference   |
       |                    |                                         |
       |                    |     INVITE Contact:Conf-ID;isFocus F3   |
       |                    |---------------------------------------->|
       |                    |               180 Ringing F4            |
       |                    |<----------------------------------------|
       |                    |                  200 OK F5              |
       |                    |<----------------------------------------|
       |                    |                   ACK F6                |
       |                    |---------------------------------------->|
       |                    |                    RTP                  |
       |                    |<=======================================>|
       |     NOTIFY F7      |                                         |
       |<-------------------|                                         |
       |     200 OK F8      |                                         |
       |------------------->|                                         |
       |                    |           SUBSCRIBE sip:Conf-ID F9      |
       |                    |<----------------------------------------|
       |                    |                  200 OK F10             |
       |                    |---------------------------------------->|
       |                    |                NOTIFY F11               |
       |                    |---------------------------------------->|
       |                    |                  200 OK F12             |
       |                    |<----------------------------------------|
       |     NOTIFY F13     |                                         |
       |<-------------------|                                         |
       |     200 OK F14     |                                         |
       |------------------->|                                         |

   Figure 5. Member Requests Focus add member to the conference.


6.7    Adding a 3rd Party Using Conference ID

   This section is equally applicable for both ad-hoc and reserved
   conferences.




Johnston & Levin         Expires - April 2003                [Page 16]


               SIP Call Control - Conferencing for UAs   October 2002


   A member wishing to add a new member simply requests another
   participant to send an INVITE to the conference URI.  This can be
   done using a non-SIP means (such as passing or publishing the
   conference URI in an email, IM, or web page).  If a non-SIP means is
   used, then the flow and requirements are identical to Section 6.4.

   The SIP mechanism to do this utilizes the REFER method.

   A UA wishing to add a new member SHOULD send a REFER request to the
   member with a Refer-To header containing the conference URI.

   The requirements are then identical to the "dial in" case of Section
   6.4.  The UA MAY receive notification through the REFER action that
   the new member has been added in addition to the notification
   received through the conference package.

   An example is shown in Figure 6.  In this call flow, it is assumed
   that Alice is already a member of the conference.  Alice sends Bob an
   "out of band" REFER - that is, a REFER outside of an established
   dialog.  Should Bob reject the REFER, Alice might try sending an
   INVITE to Bob to establish a session first, then send a REFER within
   the dialog, effectively transferring Bob into the conference [17].


     Alice                Focus                 Bob                Carol
       |                    |                    |                    |
       |<==================>|                    |                    |
       |                    |                    |                    |
       |  Alice adds Bob into conference         |                    |
       |                    |                    |                    |
       | REFER Refer-To:Conf-ID F1               |                    |
       |---------------------------------------->|                    |
       |  202 Accepted F2   |                    |                    |
       |<----------------------------------------|                    |
       |     NOTIFY F3      |                    |                    |
       |<----------------------------------------|                    |
       |     200 OK F4      |                    |                    |
       |---------------------------------------->|                    |
       |                    | INVITE sip:Conf-ID F5                   |
       |                    |<-------------------|                    |
       |                    |   180 Ringing F6   |                    |
       |                    |------------------->|                    |
       |                    | 200 OK Contact:Conf-ID;isFocus F7       |
       |                    |------------------->|                    |
       |                    |       ACK F8       |                    |
       |                    |<-------------------|                    |
       |                    |        RTP         |                    |
       |                    |<==================>|                    |
       |                    |      NOTIFY F9     |                    |


Johnston & Levin         Expires - April 2003                [Page 17]


               SIP Call Control - Conferencing for UAs   October 2002


       |<----------------------------------------|                    |
       |                    |      200 OK F10    |                    |
       |---------------------------------------->|                    |
       |      NOTIFY F11    |                    |                    |
       |<-------------------|                    |                    |
       |      200 OK F12    |                    |                    |
       |------------------->|                    |                    |
       |                    | SUBSCRIBE sip:Conf-ID F13               |
       |                    |<-------------------|                    |
       |                    |     200 OK F14     |                    |
       |                    |------------------->|                    |
       |                    |     NOTIFY F15     |                    |
       |                    |------------------->|                    |
       |                    |     200 OK F16     |                    |
       |                    |<-------------------|                    |

   Figure 6. Adding a member to an existing conference.


6.8    Adding a 3rd Party Using Call ID

   Under some circumstances, a member wanting to join a conference may
   only know a dialog ID of one of the legs of the conference and the
   focus URI, instead of the conference URI.  The information may have
   been learned using the dialog package [18] or some non-SIP means.  If

   A UA can request to be added to a conference by sending a request to
   the focus containing a Join [19] header field containing a dialog ID
   of one leg of the conference (a dialog between a member and the
   focus).

   There are other scenarios in which a Type III or even Type II UA
   which is capable of creating a conference can use the Join header for
   certain conferencing call control scenarios.

   The Join header field is also useful in the transition of a two party
   call to a conference call, as described in [20].

   To request a conference member to be added to the conference without
   knowing the conference URI, a UA SHOULD send an INVITE request to the
   focus URI containing a Join header field.  The Join header field MUST
   contain the dialog identifier of a valid dialog between the focus and
   the member.

   An example is shown in Figure 7.  It is assumed that Alice is a
   member of the conference.  The dialog identifier between Alice and
   the focus is abbreviated as A-F and is known by Bob.  Bob requests to
   be added to the conference by sending an INVITE message F1 to the
   focus containing a Join header which contains the dialog identifier


Johnston & Levin         Expires - April 2003                [Page 18]


               SIP Call Control - Conferencing for UAs   October 2002


   A-F.  Note that this dialog identifier could be learned through some
   non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY and the dialog event
   package [21].  Bob is added into the conference by the focus.

     Alice                Focus                 Bob                Carol
       |                    |                    |                    |
       |<==================>|                    |                    |
       |                    |                    |                    |
       |  Bob requests to be added to the conference.                 |
       |                    |                    |                    |
       |                    | INVITE sip:Focus Join:A-F  F1           |
       |                    |<-------------------|                    |
       |                    |   180 Ringing F2   |                    |
       |                    |------------------->|                    |
       |                    | 200 OK Contact:Conf-ID;isFocus F3       |
       |                    |------------------->|                    |
       |                    |       ACK F4       |                    |
       |                    |<-------------------|                    |
       |                    |        RTP         |                    |
       |                    |<==================>|                    |
       |                    | SUBSCRIBE sip:Conf-ID F5               |
       |                    |<-------------------|                    |
       |                    |     200 OK F6      |                    |
       |                    |------------------->|                    |
       |                    |     NOTIFY F7      |                    |
       |                    |------------------->|                    |
       |                    |     200 OK F8      |                    |
       |                    |<-------------------|                    |

   Figure 7. Adding a member to an existing conference using Join.


6.9    Bringing a Point-to-Point Dialog into a Conference

   A focus is capable of bringing an existing point-to-point dialog with
   another UA to a conference that the focus hosts. The focus would do
   it by sending re-INVITE changing the Contact URI to the conference
   URI with the ôisFocusö parameter. By doing this, the focus signals to
   the UA that it becomes a member of the conference, specified in the
   Contact header.

   Currently, there is no way for a UA, being in an active point-to-
   point call with a focus, to express by SIP call control means a
   request to bridge its dialog with a specific conference or to create
   a new conference and include the dialog in this conference.  Instead,
   a new dialog will need to be created.  Even if the UA discovers that
   the other side has focus capabilities, the UA needs to close the old
   session and to establish a new session/dialog with the focus.



Johnston & Levin         Expires - April 2003                [Page 19]


               SIP Call Control - Conferencing for UAs   October 2002


        Editor's Note: Is this an issue?


Security Considerations

   TBD


References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3 J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
      Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
      Initiation Protocol", RFC 3261, June 2002.

   4 J. Rosenberg, "A Framework for Conferencing with the Session
      Initiation Protocol," October 2002, Work in Progress.

   5 O. Levin, R. Even, P. Koskelainen, S. Sen, "Requirements for
      Tightly Coupled SIP Conferencing," Internet Engineering Task
      Force, November 2002, Work in progress.

  6 R. Mahy, B. Campbell, A. Johnston, D. Petrie, J. Rosenberg, and R.
      Sparks, "A Multi-party Application Framework for SIP," Internet
      Engineering Task Force, February 2002, Work in progress.

   7 B. Campbell and R. Sparks, "Control of Service Context using SIP
      Request-URI," RFC 3087, April 2001.

   8 P. Faltstrom and M. Mealing, "The E.164 to URI DDDS Application,"
      Internet Engineering Task Force, June 2002, Work in progress.

   9 E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location
      Protocol, Version 2," RFC 2608, June 1999.

   10 A. Johnston, S. Donovan, R. Sparks, C. Cunningham, "SIP Basic Call
      Flow Examples", Internet Draft, Internet Engineering Task Force,
      October 2002, Work in Progress.

   11 R. Sparks, "The Refer Method", Internet Draft, Internet
      Engineering Task Force, July 2002, Work in Progress.




Johnston & Levin         Expires - April 2003                [Page 20]


               SIP Call Control - Conferencing for UAs   October 2002



   12 A. Roach, "SIP-Specific Event Notification," RFC 3265, June 2002.

   13 J. Rosenberg and H. Schulzrinne, "A Session Initiation Protocol
      (SIP) Event Package for Conference State," Internet Engineering
      Task Force, June 2002, Work in progress.

   14 J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
      server component architecture for SIP," Internet Draft, Internet
      Engineering Task Force, Mar. 2001.  Work in progress.

   15 H. Schulzrinne and J. Rosenberg, "SIP Caller Preferences and
      Callee Capabilities," Internet Engineering Task Force, June 2001,
      Work in Progress.

   16 R. Mahy , B. Biggs, and R. Dean, "The SIP Replaces header,"
      Internet Draft, Internet Engineering Task Force, April 2002, Work
      in Progress.

   17 R. Sparks and A. Johnston, "SIP Call Control û Transfer," Internet
      Engineering Task Force, October 2002, Work in progress.

   18 J. Rosenberg and H. Schulzrinne, "A Session Initiation Protocol
      (SIP) Event Package for Dialog State," Internet Engineering Task
      Force, June 2002, Work in progress.

   19 R. Mahy and D. Petrie, "The Session Initiation Protocol (SIP)
      'Join' Header," Internet Engineering Task Force, June 2002, Work
      in progress.

   20 A. Johnston, S. Donovan, R. Sparks, C. Cunningham, "SIP Service
      Examples", Internet Draft, Internet Engineering Task Force,
      October 2002, Work in Progress.

   21 J. Rosenberg and H. Schulzrinne, "A Session Initiation Protocol
      (SIP) Event Package for Dialog State," Internet Engineering Task
      Force, June 2002, Work in progress.



Acknowledgments

   The authors would like to thank all the members of the SIPPING
   Conferencing design team for their input and discussions.


Author's Addresses




Johnston & Levin         Expires - April 2003                [Page 21]


               SIP Call Control - Conferencing for UAs   October 2002


   Alan Johnston
   WorldCom
   100 South 4th Street
   St. Louis, MO 63102
   USA

   EMail:  alan.johnston@wcom.com

   Orit Levin
   RADVISION
   266 Harristown Road
   Glen Rock, NJ USA

   Email:  orit@radvision.com
   Phone:  +1-201-689-6330


   Copyright Notice

   "Copyright (C) The Internet Society 2002. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


   Acknowledgement

   Funding for the RFC Editor function is currently provided by the


Johnston/Levin           Expires - April 2003                [Page 22]


               SIP Call Control - Conferencing for UAs   October 2002


   Internet Society.


















































Johnston/Levin           Expires - April 2003                [Page 23]