[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-p2psip-disco

Network Working Group                                           A. Knauf
Internet-Draft                                                   G. Hege
Intended status: Standards Track                            T C. Schmidt
Expires: July 3, 2011                                        HAW Hamburg
                                                            M. Waehlisch
                                                    link-lab & FU Berlin
                                                       December 30, 2010


       A RELOAD Usage for Distributed Conference Control (DisCo)
                      draft-knauf-p2psip-disco-01

Abstract

   This document defines a RELOAD Usage for Distributed Conference
   Control (DisCo) with SIP.  DisCo preserves conference addressing
   through a single SIP URI by splitting its semantic of identifier and
   locator using a new Kind data structure.  Conference members are
   enabled to select conference controllers based on proximity awareness
   and to recover from failures of individual resource instances.  DisCo
   proposes call delegation to balance the load at focus peers.  The
   document also introduces methods to establish security and trust for
   a shared resource access, as well as for compatibility with
   conference unaware clients.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 3, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Knauf, et al.             Expires July 3, 2011                  [Page 1]


Internet-Draft                    DisCo                    December 2010


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview of DisCo  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Reference Scenario . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Initiating a Distributed Conference  . . . . . . . . . . .  8
     3.3.  Joining a Conference . . . . . . . . . . . . . . . . . . .  9
     3.4.  Conference State Synchronization . . . . . . . . . . . . . 10
     3.5.  Call delegation  . . . . . . . . . . . . . . . . . . . . . 11
     3.6.  Resilience . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.7.  Topology Awareness . . . . . . . . . . . . . . . . . . . . 11
   4.  RELOAD Usage for Distributed Conference Control  . . . . . . . 12
     4.1.  Kind Data Structure  . . . . . . . . . . . . . . . . . . . 12
     4.2.  Determining Coordinates  . . . . . . . . . . . . . . . . . 13
     4.3.  Conference Creation  . . . . . . . . . . . . . . . . . . . 14
     4.4.  Obtaining a Conference Certificate . . . . . . . . . . . . 15
       4.4.1.  Self-generated . . . . . . . . . . . . . . . . . . . . 16
       4.4.2.  Using Enrollment Server  . . . . . . . . . . . . . . . 16
     4.5.  Proximity-aware Conference Participation . . . . . . . . . 17
     4.6.  Advertising Focus Ability  . . . . . . . . . . . . . . . . 19
     4.7.  Configuration Document Extension . . . . . . . . . . . . . 19
   5.  Conference State Synchronization . . . . . . . . . . . . . . . 20
     5.1.  Event Package Overview . . . . . . . . . . . . . . . . . . 20
     5.2.  <distributed-conference> . . . . . . . . . . . . . . . . . 22
     5.3.  <version-vector>/<version> . . . . . . . . . . . . . . . . 22
     5.4.  <conference-description> . . . . . . . . . . . . . . . . . 23
     5.5.  <focus>  . . . . . . . . . . . . . . . . . . . . . . . . . 24
       5.5.1.  <focus-state>  . . . . . . . . . . . . . . . . . . . . 25
       5.5.2.  <users>/<user> . . . . . . . . . . . . . . . . . . . . 25
       5.5.3.  <relations>/<relation> . . . . . . . . . . . . . . . . 26
     5.6.  Distribution of Change Events  . . . . . . . . . . . . . . 26
     5.7.  Translation to Conference-Info Event Package . . . . . . . 27
       5.7.1.  <conference-info>  . . . . . . . . . . . . . . . . . . 28
       5.7.2.  <conference-description> . . . . . . . . . . . . . . . 28
       5.7.3.  <host-info>  . . . . . . . . . . . . . . . . . . . . . 28
       5.7.4.  <conference-state> . . . . . . . . . . . . . . . . . . 29
       5.7.5.  <users>/<user> . . . . . . . . . . . . . . . . . . . . 29



Knauf, et al.             Expires July 3, 2011                  [Page 2]


Internet-Draft                    DisCo                    December 2010


       5.7.6.  <sidebars-by-ref>/<sidebars-by-value>  . . . . . . . . 29
   6.  Distributed Conference Control with SIP  . . . . . . . . . . . 30
     6.1.  Call delegation  . . . . . . . . . . . . . . . . . . . . . 30
     6.2.  Conference Access  . . . . . . . . . . . . . . . . . . . . 31
     6.3.  Media Negotiation and Distribution . . . . . . . . . . . . 32
       6.3.1.  Offer/Answer . . . . . . . . . . . . . . . . . . . . . 32
     6.4.  Restructuring a Conference . . . . . . . . . . . . . . . . 33
       6.4.1.  On Graceful Leave  . . . . . . . . . . . . . . . . . . 33
       6.4.2.  On Unexpected Leave  . . . . . . . . . . . . . . . . . 34
   7.  DisCo Kind Definition  . . . . . . . . . . . . . . . . . . . . 35
   8.  Access Control Policy USER-CHAIN-MATCH . . . . . . . . . . . . 36
   9.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 37
   10. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . . . 41
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 42
     11.1. Trust Aspects  . . . . . . . . . . . . . . . . . . . . . . 42
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 44
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 45
     14.2. Informative References . . . . . . . . . . . . . . . . . . 45
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 47
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48





























Knauf, et al.             Expires July 3, 2011                  [Page 3]


Internet-Draft                    DisCo                    December 2010


1.  Introduction

   This document describes a RELOAD Usage for distributed conference
   control (DisCo) in a tightly coupled model with SIP [RFC3261].  The
   Usage provides self-organizing and scalable signaling that allows
   RELOAD peers, clients and plain SIP user agents to participate in a
   managed P2P conference.  DisCo defines the following functions:

   o  A protocol scheme for distributed conference control

   o  RELOAD Usage and definition of conferencing Kind

   o  RELOAD Usage and definition of a Kind for shared Resources in
      RELOAD

   o  Mechanisms for conference synchronization and call delegation

   o  Mechanism for proximity-aware routing within a conference

   o  An XML event package for distributed conferences

   o  Methods of establishing security and trust for shared resource
      access

   In this document, the term distributed conferencing refers to a
   multiparty conversation in a tightly coupled model in which the point
   of control (i.e., the focus) is identified by a unique URI, but the
   focus service is located at many independent entities.  Multiple SIP
   [RFC3261] user agents uniformly control and manage a multiparty
   session.  This document defines a new Usage for RELOAD, including an
   additional Kind code point with a corresponding data structure that
   complies the demands for distributed conferences.  The 'DisCo' data
   structure stores the mapping of a single conference to multiple
   conference controllers and thereby separates the conference URI from
   focus instantiations.

   Authorized controllers of a conference are permitted to register
   their mapping into the DisCo data structure independently.  Thus, the
   DisCo data structure represents a co-managed Resource in RELOAD.  To
   provide trusted and secure access to a co-managed Resource, this
   document defines a Usage to share a specific RELOAD Resource.  A
   RELOAD user explicitly authorizes RELOAD peers within a RELOAD Kind
   data structure called 'access list'.

   Delay and jitter are critical issues in multimedia communications.
   The proposed conferencing scheme supports mechanisms to build an
   optimized interconnecting graph between conference participants and
   their responsible conference controllers.  Conference members will be



Knauf, et al.             Expires July 3, 2011                  [Page 4]


Internet-Draft                    DisCo                    December 2010


   enabled to select the closest focus with respect to delay or jitter.

   DisCo extends conference control mechanisms to provide a consistent
   and reliable conferencing environment.  Controlling peers maintain a
   consistent view of the entire conference state.  The multiparty
   system can be re-structured based on call delegation operations.













































Knauf, et al.             Expires July 3, 2011                  [Page 5]


Internet-Draft                    DisCo                    December 2010


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].


   The terminology and definitions from der RELOAD base
   [I-D.ietf-p2psip-base], the peer-to-peer SIP concepts draft
   [I-D.ietf-p2psip-concepts] and the terminology formed by the
   framework for conferencing with SIP [RFC4353].  Additionally the
   following terms are used:

   Coordinate Value:  An opaque string that describes a host's relative
      position in the network topology.

   Focus peer:  A RELOAD peer that provides SIP conferencing functions
      and implements the Usage for distributed conferencing.  It is
      called 'active' if already involved in signaling relation to
      conference participants.  Otherwise, if only registered in a
      distributed conference data structure, it is referred to as a
      'potential' focus peer.





























Knauf, et al.             Expires July 3, 2011                  [Page 6]


Internet-Draft                    DisCo                    December 2010


3.  Overview of DisCo

3.1.  Reference Scenario

   The reference scenario for the Distributed Conference Control (DisCo)
   is shown in Figure 1.  Peers are connected via a RELOAD
   [I-D.ietf-p2psip-base] instance, in which peers A and B are managing
   a single multiparty conference.  The conference is identified by a
   unique conference URI, but located at peers A and B fulfilling the
   role of the focus.  The mapping of the conference URI to one or more
   responsible focus peers is stored in a new RELOAD Resource for
   distributed conferencing within a data structure denoted as DisCo-
   Registration.  The storing peer SP of the distributed conference
   resource holds this data.

   The focus peers A and B maintain SIP signaling relations to
   conference participants, which may have different conference protocol
   capabilities.  In this example, peer A is the multiparty manager for
   the RELOAD peer C and the plain SIP user agent E whereas focus peer B
   serves for RELOAD peer D and the RELOAD client F.

   RELOAD peers and clients obtain the contact information for the
   conference from the storing peer.  In contrast, the user agent E
   receives the conference URI not by RELOAD mechanisms, but resolves
   the ID and joins the conference by plain SIP negotiation.

   Focus peers establish a SIP signaling relation among each other used
   for notification messages that synchronize the conference focus
   peers' knowledge about the entire conference state.  Additionally,
   focus peers can transfer calls to each other by a call delegation
   mechanism.




















Knauf, et al.             Expires July 3, 2011                  [Page 7]


Internet-Draft                    DisCo                    December 2010


                                         +----------+
                                         |DisCo Data|
                                         +----------+
                                        /
                                  +-------+
                                  |Storing|
              # # # # # # # # # # | Peer  | # # # # # # # # # #
             #                    |  O    |                    #
            #                     +-------+                     #
           #                                                     #
          #                                                       #
         #                                                         #
      +----+                                                     +----+
      |Peer| \               RELOAD Instance                     |Peer|
      | C  |  \                                                  | D  |
      +----+   \                                                 +----+
         #     SIP                                                 #
          #      \                                                #
           #      \                                              #
            #     +-------+                       +-------+     #(
             #    | Focus |                       | Focus |    #  )
              # # | Peer  | # # # # # # # # # # # | Peer  | # #  (
                  |   A   | <===Conf.Events/====> |   B   |       )
                  +-------+    Call delegation    +-------+    Overlay
                 /                                        \     Comm.
                /                                          \     (
              SIP                                          SIP    )
              /                                              \   (
             /                                                \   )
        +----------+                                      +--------+
        |User Agent|                                      | Client |
        |    E     |                                      |   F    |
        +----------+                                      +--------+

   Figure 1: Reference Scenario: Focus peers A,B maintain a distributed
                                conference

3.2.  Initiating a Distributed Conference

   To create a conference the initiating user agent announces itself as
   a focus for the conference.  It stores its own contact information
   (Address-of-Record or Destination List) in the RELOAD overlay as a
   DisCo-Registration Kind (cf., Figure 2).  The hashed conference URI
   is used as the Resource-ID.  This data structure will later contain
   the contact IDs of all potential focus peers including optionally
   topological descriptors.





Knauf, et al.             Expires July 3, 2011                  [Page 8]


Internet-Draft                    DisCo                    December 2010


3.3.  Joining a Conference

   A RELOAD-aware node (cf., Bob in Figure 2) intending to join an
   existing conference retrieves the list of potential focus peers
   stored in the DisCo-Registration under the conference's Resource-ID.
   To join the conference it selects any of the focus peers (e.g.,
   Alice) and establishes a connection using AppAttach.  This transport
   is then used to send an INVITE to the conference applying the chosen
   focus as the contact.  The selection of the focus peer to contact can
   optionally be based on proximity information if available.

   A conference member proposes as a focus for subsequent participants
   by storing a mapping of the conference URI to his Address-of-Record
   or Destination List in the RELOAD overlay in the DisCo-Registration
   data structure.  This decision should incorporate bandwidth, power,
   and other constraints, but details are beyond the scope of this
   document.


































Knauf, et al.             Expires July 3, 2011                  [Page 9]


Internet-Draft                    DisCo                    December 2010


    Alice                          RELOAD                            Bob
    (initiating peer)                                     (joining peer)
    --------------------------------------------------------------------
      |                               |                               |
      |      Alice stores her mapping to register a conference        |
      | Store mapping(ConfURI, Alice) |                               |
      |------------------------------>|                               |
      |                               |        Lookup ConfURI         |
      |                               |<------------------------------|
      |                               |        Result ConfURI         |
      |                               |------------------------------>|
      |                               |                               |
      |       Bob establishes transport connection to Alice           |
      |                           AppAttach                           |
      |<--------------------------------------------------------------|
      |                           AppAttach                           |
      |-------------------------------------------------------------->|
      |                            INVITE                             |
      |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
      |                              OK                               |
      |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
      |                              ACK                              |
      |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
      |                             Media                             |
      |<=============================================================>|
      |                               |                               |
      |       Bob stores his mapping to become a focus peer too       |
      |                               |  Store mapping(ConfURI, Bob)  |
      |                               |<------------------------------|
      |                               |                               |

                  Figure 2: DisCo Usage generic Call Flow

3.4.  Conference State Synchronization

   Each focus of a conference maintains signaling connections to its
   related participants independently from other conference controllers.
   This distributed conference design effects that the entire SIP
   conference state is jointly held by all conference focus peers.  In
   DisCo, state synchronization is based on a SIP specific event
   notifications mechanism [RFC3265].

   Each focus peer can complete its view of the entire conference state
   among the focus peers by subscribing the other focus peers for an XML
   event package for distributed conferences.  It is defined in this
   document (see section Section 5) and is based on the event package
   for conference state [RFC4575].  Receivers of event notifications
   update their local conference state document to regain a valid view



Knauf, et al.             Expires July 3, 2011                 [Page 10]


Internet-Draft                    DisCo                    December 2010


   of current conference state.

   The event notification package for distributed conferences enables
   focus peers to synchronize the entire conference state.  The event
   package defines additional XML elements and complex types (see
   Section 9 for more details), which allow views of the
   responsibilities of any focus peer in the conference.  By providing
   these views each focus peer is enabled to perform additional load
   balancing operations and enhances the robustness against departures
   of focus peers.

3.5.  Call delegation

   The call delegation (see Section 4.2.) is a feature used to transfer
   an incoming participation request to another focus peer.  It can be
   applied to prevent an overloading of focus peers reaching its limit
   of serving new clients.  Call delegation is realized through SIP
   REFER requests, which carry signaling and session description
   information of the callee to be transferred.  A focus peer can decide
   to refer an incoming call to a less loaded remote focus.  This
   feature is achieved transparently to the transferred user agent by
   using a source routing mechanism at SIP dialog establishment.
   Descriptions of overload detection are beyond the scope of this
   document.

3.6.  Resilience

   A focus peer can decide to leave the conference or may ungracefully
   fail.  In a traditional conferencing scenario, a loss of the
   conference controller or the media distributor would cause a complete
   fail of the multiparty conversation.  Distributed conferencing uses
   the redundancy by multiple focus peers to reconfigure a running
   multiparty.  Participants that lost their entry point to the
   conference re-invite itself via the remaining focus peers or will be
   re-invited by the controllers.  This option is based on the
   conference state and call delegation functions.

3.7.  Topology Awareness

   DisCo supports landmarking approaches based on an extension for the
   RELOAD XML configuration document (see Section 4.7) to construct
   topology-aware connections between focus and peers.  Each peer
   intending to create or participate in a distributed conference MAY
   determine a topological descriptor that describes its relative
   position in the network.  Focus peers store these coordinate values
   as additional data field in the DisCo-Registration data structure.
   This enables peers joining the conference to select the closest focus
   with respect to its coordinate values.



Knauf, et al.             Expires July 3, 2011                 [Page 11]


Internet-Draft                    DisCo                    December 2010


4.  RELOAD Usage for Distributed Conference Control

4.1.  Kind Data Structure

   Each DisCo-Registration data structure stores mappings for one
   conference instance to many focus peers and for each focus peer the
   related coordinates value.  The data structure uses the RELOAD
   dictionary type whereas the DictionaryKey value is the Node-ID of the
   focus peer behind the dictionary entry.  This allows a focus peer to
   update it mapping.  The DisCo data structure of type
   DisCoRegistration is shown as follows:

     enum {
       sip_focus_uri (1),
       sip_focus_node_id (2), (255)
     } DisCoRegistrationtType;

     struct {
       opaque coordinate<0..2^16-1>

       select (DisCoRegistrationtType.type) {
         case sip_focus_uri:
           opaque uri<0..2^16-1>

         case sip_focus_node_id:
           Destination destination_list<0..2^16-1>

         /* This type can be extended */
       }

     } DisCoRegistrationData;

     struct {
       DisCoRegistrationtType type;
       uint16 length;
       DisCoRegistrationData data;
     } DisCoRegistration;

   The content of the DisCoRegistrationData structure are as follows:
                   type
                       type of the registration
                   length
                       the length of the registration PDU
                   data
                       the conference registration data






Knauf, et al.             Expires July 3, 2011                 [Page 12]


Internet-Draft                    DisCo                    December 2010


   o  If the DisCoRegistration is set to "sip_focus_uri", then it
      contains an Address-of-Record (AoR) as an opaque string and opaque
      "coordinates" string, that describes the relative network
      position.  See more in section 4.4.

   o  If registration type is set to "sip_focus_node" then it contains
      the Destination list for the peer and an opaque string
      "coordinates" describing the focus' relative network position.

   The structure is designed for enabling a peer to contact a focus of
   the conference that is the nearest to itself.  A joining peer MAY
   select the focus peer, whose coordinate value matches at most to its
   own.  In this manner it reduces the problem of triangle inequality as
   without this feature a joining peer could choose an inadequate remote
   conference controller causing large signaling and may streaming
   delays.

4.2.  Determining Coordinates

   Each RELOAD peer within the context of a distributed conference MAY
   be aware of it's relative position in the network topology.  Those
   position information can support a topology-aware conference
   construction avoiding long signaling and media delays.  Providing
   this the Usage for distributed conference foresees the coordinates
   value within the DisCo-Registration data structure that allows focus
   peers to store a topological descriptor.  It is a generic field that
   describes a peer's relative position in the network.  Focus peers
   store this coordinate value together with their announcement as
   conference focus.  Joining peers likewise MAY determine their
   coordinates value and then select a focus peer whose relative
   position matches at most (see section Section 4.5).

   Many algorithms determine topology information by measuring Round-
   Trip Times (RTT) towards a set on hosts serving as so called
   landmarks.  To support such algorithms this document describes an
   extension to the RELOAD XML configuration document that allows to
   configure the set of Landmark hosts that peer must use for position
   estimation (see section Section 4.7).  Once a focus peer has
   registered its mapping in the DisCo data structure, it also stores
   the according coordinates in the same mapping.  These <Node-
   ID,coordinates> vectors are used by peers at conference join to
   select the focus peer that is relatively closest to itself.

   Because topology-awareness can be obtained by many different
   approaches a concrete algorithms is out of scope of this document.






Knauf, et al.             Expires July 3, 2011                 [Page 13]


Internet-Draft                    DisCo                    December 2010


4.3.  Conference Creation

   Before a peer registers to a new distributed conference, it is
   RECOMMENDED to ensure the initiating peer has a most up to date copy
   of the configuration document.  In this way, the conference creator
   assures that all joining peers will equally determine their
   coordinates value if such a algorithm is used.  The first peer that
   creates a distributed conference registers it in the RELOAD overlay
   following the steps as described in Figure 3:


           CA      Alice      Peer1     Overlay     PeerN   StoringPeer
        ------------------------------------------------------------
           |          |   StatReq Res:Conf-URI          |          |
           |          |---------->|--------->|--------->|--------->|
           |          |           StatAns    |          |          |
           |          |<----------|<---------|<---------|<---------|
           |<==Cert===|           |          |          |          |
           |          |           |          |          |          |
           |===Cert==>|   StoreReq Res:Conf-URI Kinds:DisCo[,SIP]  |
           |          |---------->|--------->|--------->|--------->|
           |          |           StoreAns   |          |          |
           |          |<----------|<---------|<---------|<---------|
           |          |           |          |          |          |


              Figure 3: Creation of a Distributed Conference

   1.  The peer MAY determine its own coordinate value (if used).

   2.  The peer SHOULD probe whether the desired conference URI is
       available.  It therefore generates the Resource-ID of the
       conference URI with the overlay hash function and sends a RELOAD
       StatReq towards this address.  By the corresponding StatAns
       response the peer knows whether the desired URI is occupied by
       another a DisCo Kind or even a SIP-Registration Kind
       [I-D.ietf-p2psip-sip].  If it is, the user MUST choose another
       URI and repeat the availability checks.  If no other DisCo or
       SIP-Registration Kind are stored at this Resource-ID it proceeds
       the registration.

   3.  Storing a conference registration is similar to registering a new
       virtual user that has the conference URI as its Address-of-
       Record.  Two options for obtaining a conference certificate are
       available as detailed in section Section 4.4.  The first does not
       require contacting the enrollment server, but only allows a set
       of conference URIs closely related to the registering peer's user
       name.  The second option allows any form of conference URI but



Knauf, et al.             Expires July 3, 2011                 [Page 14]


Internet-Draft                    DisCo                    December 2010


       needs to contact the enrollment server.  In both cases the
       resulting certificate contains the conference URI as a user name.

   4.  The peer finally registers the DisCo data structure signed with
       the private key corresponding to the above certificate by a Store
       request towards the storing peer (the owner of the address space
       for the Resource-ID of the conference URI).

   The additional certificate is needed for 2 major purposes:

   o  It separates the conference creator from the multiparty instance.

   o  It ensures the conference initiator's privacy.  Because the DisCo
      data structure will be accessed by many peers using the same
      conference private key.  If they were using the conference
      creators' key, they were permitted to write non-shared Resources
      of the creator.

   When the conference creator has obtained the conference certificate
   from the enrollment server, it MAY also register the conference URI
   as a SIP-Registration Kind as well.  In this case, it also MUST sign
   the Store request with the private key that matches the certificate
   obtained for the conference URI, since the SIP-Registration Kind uses
   the USER-NODE-MATCH policy.  In case of the conference creator's
   departure, the remaining focus peers are permitted to redirect the
   SIP mapping to another focus peer still serving the conference.  The
   SIP-Registration MAY be sent in the same StoreReq as the DisCo
   registration.

4.4.  Obtaining a Conference Certificate

   In RELOAD each node uses a certificate to identify itself when
   storing data at a specific location.  Since the DisCo-Registration
   needs to be written by multiple nodes, the private key of a group
   certificate is distributed among all authorized focus peers.  This
   demands the assignment of a certificate for each conference ID which
   is used for conferencing matters only.  This document describes two
   options for obtaining a conference certificate.  The method to be
   used depends on the desired pattern of the conference ID being
   registered.

   In both cases the certificate should have a sufficiently short
   lifetime to prevent a compromised certificate from being used
   continuously.  The chance of a conference key leaking and thus being
   compromised is much larger than for normal RELOAD certificates, since
   the key is shared among the focus peers of a conference.





Knauf, et al.             Expires July 3, 2011                 [Page 15]


Internet-Draft                    DisCo                    December 2010


4.4.1.  Self-generated

   A conference initiator can only register a conference ID that is
   derived from the user name defined in it's own certificate, without
   contacting an enrollment server.  The conference ID must be closely
   related to the user name of the creator to prevent malicious peers
   not associated with the conference from generating a certificate for
   the same name and registering themselves as a focus.

   The building scheme for constructing legitimate conference URIs MUST
   be specified in the overlay configuration document using a simple
   pattern matching scheme.

   Example:
   URI pattern: *-conf-$USER@$DOMAIN
   User Name: alice@example.com

   XYZ-conf-alice@example.com is allowed
   my-pretty-conf-alice@example.com is allowed
   alice-conference@example.com is NOT allowed

   The conference initiator generates a new public/private key pair and
   signs the public key with his own private key, thus generating a
   certificate for the conference.  The conference certificate contains
   the conference URI in the user name field, which MUST comply with the
   URI pattern specified for DisCo-conferences in the configuration
   document.  Any peer validating the certificate MUST traverse the
   certificate chain up to the enrollment server and only accept it if
   the certificates of the creator and of the enrollment server are
   valid.  Additionally the user name in the certificate of the creator
   MUST match the user name in the conference certificate using the
   specified pattern.

   This conference certificate is subsequently used to sign all entries
   of the DisCo-Registration kind stored in the overlay.  It MUST be
   accepted by the responsible peer.  This results in an extension of
   the common USER-MATCH access control policy to USER-CHAIN-MATCH,
   specified in Section 8.

4.4.2.  Using Enrollment Server

   An enrollment server MAY issue certificates for conferences with any
   URI that is not related to the user name of the conference initiator.

   Therefore a user agent intending to register a new conference
   contacts the enrollment server and requests a certificate using the
   standard mechanism defined in RELOAD [I-D.ietf-p2psip-base] Section
   10.3.



Knauf, et al.             Expires July 3, 2011                 [Page 16]


Internet-Draft                    DisCo                    December 2010


   Conferences with certificates obtained from an enrollment server use
   the USER-MATCH access control policy for the DisCo-Registration kind.

   The enrollment server MUST NOT reuse the Node-ID of the conference
   initiator for the conference certificate, since this certificate is
   intended for distribution among the focus peers of a conference.
   This would allow the focus peers to compromise any private resources
   stored by the initiator using the NODE-MATCH policy.

4.5.  Proximity-aware Conference Participation

   A RELOAD peer intending to join a distributed conference follows the
   steps shown in Figure 4:

         Bob      Peer1     Overlay     PeerN     OwnerOfID     Alice
       --------------------------------------------------------------
          |   FetchReq Res:Conf-URI Kind:DisCo        |          |
          |--------->|--------->|--------->|--------->|          |
          |          |FetchAns  |          |          |          |
          |<---------|<---------|<---------|<---------|          |
          |          |          |          |          |          |
          |  Bob calculates Alice as closest Focus    |          |
          |          |          |          |          |          |
          |          |AppAttach--application:5060     |          |
          |--------->|--------->|--------->|--------->|--------->|
          |          |AppAttach--application:5060     |          |
          |<---------|<---------|<---------|<---------|<---------|
          |          |          |          |          |          |
          |<-------------------ICE Checks----------------------->|
          |          |          |          |          |          |
          |          |         INVITE sip:Alice       |          |
          |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
          |          |         200 OK      |          |          |
          |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
          |          |         ACK         |          |          |
          |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
          |          |          |          |          |          |
          |  Optinally, Alice passes writing permission          |
          |          |          |          |          |          |
          |         INFO content:Conf-Key{DisCo-Resource}        |
          |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
          |          |          |          |          |          |

            Figure 4: Participation of a Distributed Conference

   1.  The joining peer MAY determine its own coordinate value (if
       used).




Knauf, et al.             Expires July 3, 2011                 [Page 17]


Internet-Draft                    DisCo                    December 2010


   2.  The joining peer sends a FetchReq message for the DisCo Kind to
       the Resource-ID that corresponds to the hash over the conference
       URI using the overlays hash-function.  The FetchReq SHOULD NOT
       include any specific dictionary keys thus it will receive all
       potential -and active focus peers of the conference.

   3.  Once the joining peer received the Fetch results, it calculates
       which of the focus peers is the relatively closest to itself.

   4.  The focus with the smallest distance MAY be chosen for
       establishing a SIP signaling relation.

   Depending on which DisCo-Registration type the selected focus has
   stored its mapping, the joining Peer has the following 2
   possibilities:

   1.  If the DisCoRegistrationType is sip_focus_node_id, the joining
       peer uses RELOADs AppAttach request to establish a direct
       transport connection to the selected focus peer.  The application
       field of the request MUST be set to 5060 indicating for SIP.
       This transport connection SHOULD be used to a form an ordinary
       SIP dialog.  Further media session establishment is achieved by
       usual SIP mechanisms.

   2.  If the DisCoRegistrationType is sip_focus_uri, the joining peer
       MUST use the SIP-Registration [I-D.ietf-p2psip-sip] Usage to
       resolve the URI and form connectivity to the selected focus.

   Note that in the second case a focus peer can have multiple locations
   for its SIP-registration.  Therefore a focus MUST assure that its
   coordinate value corresponds to its current mapping AoR to location.
   If a focus peer has not determined its relative network position, the
   coordinates field MUST be left empty.

   Regardless of how the focus peer has registered its mapping in the
   overlay a joining peer MUST add it's coordinate value base64 encoded
   as URI-parameter in the contact-header field of the SIP INVITE
   request.  An example contact URI is
   "sip:alice@example.com;coord=YWxpY2VAZXhhbXBsZS5jb20=".  The
   additional parameter is used by the requested focus peer as it is not
   capable of serving additional conference participants.  It then it
   MUST delegate the call (see section Section 4.2) to the focus peer
   whose coordinate value matches next best to the coordinates of the
   joining peer.  The focus peer therefore uses the same calculation as
   described in the joining process.

   After the final SIP ACK request completes the signaling relation, a
   conference focus MAY passes the writing permission to the new



Knauf, et al.             Expires July 3, 2011                 [Page 18]


Internet-Draft                    DisCo                    December 2010


   participant.  It therefore sends a SIP INFO request carrying the
   conference private key for the DisCo Resource.  The decision whether
   to pass writing permission depends on the selected security model for
   the distributed conference as described in section Section 6.2.

4.6.  Advertising Focus Ability

   All participants of a distributed conference can become a focus peer
   for their conference.  The decision can depend on the capacities of
   the joining peer like sufficient processing power (CPU, Memory) for
   the desired media type and quality of the network connectivity.
   Additionally, a peer intending to become focus of a conference SHOULD
   NOT be located behind NAT or its IP SHOULD NOT belong to the private
   address range.  The information whether a participant is behind NAT
   can be obtained by ICE connectivity checks during the conference
   joining process.  Nevertheless, under special circumstances it might
   be reasonable to locate a focus peer behind a NAT.  For instance
   within a companies network infrastructure.

   If a participant is a candidate to become a focus of the conference
   it stores its mapping (Destination List or AoR) and coordinate value
   into the DisCo data structure.  Because the DisCo Kind uses either
   the USER-MATCH or the USER-CHAIN-MATCH access control policy, the
   shared 'private' key passed by the participant's focus peer is
   sufficient to permit this peer to write the DisCo Resource.  By
   storing the mapping into the data structure a participant becomes a
   potential focus.

4.7.  Configuration Document Extension

   This section defines an additional parameter for the <configuration>
   element that extends the RELOAD XML configuration document.  The
   proposed <landmarks> element allows RELOAD provider to publish a set
   of accessible and reliable hosts that SHOULD be used if RELOAD peers
   use landmarking algorithms to determine relative position in the
   network topology.

   The <landmarks> element serves as container of the <landmark-host>
   sub-elements each representing a single host that serves a landmark.
   The <landmark-host> uses the following attributes:

   address:  The IP address (IPv4 or IPv6) of the landmark host.

   port:  The port on which the landmark host responses for distance
      estimation.

   More than one landmark hosts SHOULD be present in the configuration
   document.



Knauf, et al.             Expires July 3, 2011                 [Page 19]


Internet-Draft                    DisCo                    December 2010


5.  Conference State Synchronization

   The global knowledge about signaling and media relations among the
   conference participants and focus peers defines the global state of a
   distributed conference.  It is composed of the union of every local
   state at the focus peers.  To enable focus peers to provide
   conference control operations that modify and/or require the global
   state of a conference, this document defines a mechanism for inter-
   focus state synchronization.  It is based on mutual subscriptions for
   an Event Package for Distributed Conferences and allows to preserve a
   coherent knowledge of the global conference state.  This XML based
   event package named 'distributed-conference' MUST be supported by
   each RELOAD peer that is registered within a DisCo-Registration.
   Participants of a distributed conference MAY support it.  To provide
   backward compatibility to conference members that do not support the
   distributed-conference event package, this document defines a
   translation to the Event Package for Conference State [RFC4575].

5.1.  Event Package Overview

   The 'distributed-conference' event package is designed to convey
   information about roles and relations of the conference participants.
   Conference controllers obtain the global state of the conference and
   use this information for load balancing or conference restructuring
   mechanisms in case of a focus failure.  Figure Figure 5 gives a
   general overview of the document hierarchy.

























Knauf, et al.             Expires July 3, 2011                 [Page 20]


Internet-Draft                    DisCo                    December 2010


   distributed-conference
     |
     |-- version-vector
     |    |-- version
     |    |-- version
     |
     |-- conference-description
     |
     |-- focus
     |    |-- focus-state
     |    |    |-- user-count
     |    |    |-- maximum-user-count
     |    |    |-- active
     |    |    |-- locked
     |    |    |-- conf-uris
     |    |    |-- available-media
     |    |
     |    |-- users
     |    |    |-- user
     |    |    |    |-- endpoint
     |    |    |    |    |-- media
     |    |    |    |    |-- call-info
     |    |
     |    |-- relations
     |    |    |-- relation
     |-- focus
     |    |-- ...

          Figure 5: Overview of the event package for distributed
                                conferences

   The local state for each focus peer is described within a
   corresponding 'focus' element.  Each provides general information
   about a focus peer, its signaling and media relations to participants
   and focus peers.  Conference participants are aggregated within
   'users' elements, respectively, 'user' sub elements.

   The document structure of 'distributed-conference' is designed to
   allow concurrent occurring change events at several focus peers.  For
   that reason, each focus peer has exclusive writing permission to the
   'focus' sub element that describes itself.  The Event Package for
   Distributed Conferences therefore imports the mechanisms for partial
   notification and uses the 'Element Keys' definitions described in
   [RFC4575] (see [RFC4575] sections 4.4-5.).  A focus peer is only
   allowed to update or change that <focus> sub element, whose 'entity'
   Element Key contains the same AoR as the AoR of RELOAD user that is
   acting focus peer.  This restriction also applies to the child
   elements of the 'version-vector' element.  Each 'version' number is a



Knauf, et al.             Expires July 3, 2011                 [Page 21]


Internet-Draft                    DisCo                    December 2010


   property of a specific focus peer which is exclusively responsible to
   increment the version number.

   General information about the conference itself, is provided within a
   'conference-description' element.  In contrast to the 'focus' and
   'version-vector' elements, the conference description is not meant
   for concurrent updating.  Instead, it provides static conference
   descriptions that rarely change during a multiparty session.

   More detailed descriptions about the event package and its elements
   are provided in the following sections.  The complete XML schema
   definition is given in section Section 9.

5.2.  <distributed-conference>

   The <distributed-conference> element is the root of a distributed
   conference XML document.  It uses the following attributes:

   entity:  This attribute contains the conference URI that identifies
      the distributed conference described by the XML document.  A
      SUBSCRIBE request addressed to this URI results in an ordinary
      subscribe/notify relation between participants and their related
      focus peer.

   state:  In accordance to [RFC4575], this attribute indicates whether
      the content of a distributed conference document is a 'full',
      'partial' or 'deleted' information.

   The <distributed-conference> child elements are <vector-version>,
   <conference-description> and the <focus> elements.  An event
   notification of state 'full' MUST include all these elements.  An
   event notification of state 'partial' MUST contain at least <version-
   vector> and its sub elements.

5.3.  <version-vector>/<version>

   The Event Package for Distributed Conferences uses the <version-
   vector>, respectively, <version> elements to enable a coherent
   versioning scheme based on vector clocks as defined in
   [timestamps-acsc88].  Each <version> element contains a unsigned
   integer that describes the local version of a specific focus peer and
   contains the following attribute:

   entity  This attribute contains the AoR of the focus peer.  This AoR
      corresponds to the 'user name' field, that is declared in the
      certificate that the RELOAD user acting as focus peer obtained
      while enrollment.




Knauf, et al.             Expires July 3, 2011                 [Page 22]


Internet-Draft                    DisCo                    December 2010


   If a focus peer originates a notification for a change event, the
   focus peer MUST increment its associated <version> element by one.
   Additionally, a change event notification MUST contain a complete
   <version-vector> that carries each <version> element known by the
   focus peer.

   The recipient of a change event needs to update the <version> element
   of the originator of the event notification in its local XML
   document.  All other <version> elements remain constant, although the
   received <version-vector> might be different.  Instead, a comparison
   of both version vectors can indicate a different knowledge about the
   global conference state.

   As long as each <version> number in the recipients XML document is at
   least lower than one to the received <version-vector> numbers, there
   is no need for a subscription refresh.  In this case, one or more
   change event notifications might not reached all subscribers yet.

   Otherwise, if any <version> number of the recipient is retarded more
   than one, the recipient SHOULD refresh the subscription in order to
   trigger a 'full' state notification.  The recipient uses the full
   state notification to recursively update every <focus> element, whose
   corresponding <version> element is retarded more than one.

5.4.  <conference-description>

   The <conference-description> element provides general information and
   links to auxiliary services for the conference.  The following sub
   elements provide human-readable text descriptions about the
   conference:

   <display-text>:  Contains a short text description about the
      conference

   <subject>:  Contains the subject of the conference

   <free-text>:  Contains a longer textual description about the
      conference

   <keywords>:  Contains a list of keywords that match the conference
      topic.  The XML schema definition and semantic is imported from
      the 'conference-info' event package [RFC4575].

   In accordance with [RFC4575] a <service-uris> sub element enables
   focus peers to advertise auxiliary services for the conference.  The
   XML schema definition and semantic is imported from the 'conference-
   info' event package [RFC4575].




Knauf, et al.             Expires July 3, 2011                 [Page 23]


Internet-Draft                    DisCo                    December 2010


   The <conference-description> element uses the 'state' Element Key to
   enable the partial notification mechanism.

5.5.  <focus>

   The <focus> element describes an active focus peer as whole.  It
   provides general information about a focus peer (e.g., display-text,
   languages, etc.).  Contains conference specific information about the
   state of a focus peer (user-count, available media types, etc.).
   Announces the signaling and media information about participants
   maintained by this focus peer and describes Signaling or media
   connections to other focus peers.

   The <focus> element uses the following attributes:

   entity:  This attribute contains the AoR of the RELOAD user acting as
      focus peer to the conference.  This AoR corresponds to the 'user
      name' field, that is declared in the certificate the user obtained
      while RELOAD enrollment [I-D.ietf-p2psip-base].  The AoR in the
      'entity' attribute uniquely identifies the focus peer, that is
      allowed to update or change the sub elements of <focus>.  All
      other focus peers SHOULD NOT update or change sub elements of this
      <focus> element.  A SUBSCRIBE request addressed to this AoR MUST
      be interpreted as the request for conference state synchronization
      with another focus peer.

   state:  In accordance to RFC4575, this attribute indicates whether
      the content of the <focus> element is a 'full', 'partial' or
      'deleted' information.  Since the event package for distributed
      conferences uniquely restricts modifications on <focus> sub
      elements to a specific focus peer, a 'partial' notification
      contains a single <focus> element at maximum.

   The following sub elements of <focus> provide general information
   about a focus peer.  The XML schema definition and semantic for
   <associated-aors>, <roles> and <languages> are imported from the
   'conference-info' event package [RFC4575].

   <display-text>:  Contains a short text description about the user
      acting as focus peer.

   <associated-aors>:  In accordance with [RFC4575], this element
      contains additional URIS that are associated with this user.

   roles:  In accordance with [RFC4575], this element MAY contain human-
      readable text descriptions about the roles of the user in the
      conference.




Knauf, et al.             Expires July 3, 2011                 [Page 24]


Internet-Draft                    DisCo                    December 2010


   <languages>:  In accordance with [RFC4575], this element contains a
      list of tokens, each describing a language understood by the user.

   The following sections describe the remaining sub elements of <focus>
   more detailed.

5.5.1.  <focus-state>

   The <focus-state> element aggregates a set of conference specific
   information about the RELOAD user acting as focus peer.  The
   following attribute is defined for the <focus-state> element:

   status:  This attribute indicates whether the content of the <focus-
      state> element is a 'full', 'partial' or 'deleted' information.

   The <focus-state> element has the following sub elements:

   <user-count>:  This element contains the number of participants that
      are connected to the conference via this focus peer at a certain
      moment.

   <maximum-user-count>:  This number indicates a threshold of
      participants a focus peer is able to serve.  This value MAY
      changes during a conference, depending on the focus peers current
      load.

   <conf-uris>:  In accordance with the 'conference-info' event package
      [RFC4575], this element MAY contains other conference URIs in
      order to access the conference via different signaling means.  The
      XML schema definition and semantic is imported from [RFC4575].

   <available-media>:  This element is imports the <conference-media-
      type> type XML scheme definitions from [RFC4575].  It allows a
      focus peer to list its available media streams.

   <active>:  This boolean element indicates whether a focus peer is
      currently active.  Conference participation requests or a call
      delegation request SHOULD succeed.

   <locked>:  In contrast to <active>, this element indicates that a
      focus peer is not willing to accept any participation or call
      delegation request.

5.5.2.  <users>/<user>

   The <users>, respectively, each <user> element describes a single
   participant that is connected to the conference via the focus peer
   which is described by the parent <focus> element.  The <users>



Knauf, et al.             Expires July 3, 2011                 [Page 25]


Internet-Draft                    DisCo                    December 2010


   element XML schema definition and its semantic is imported from the
   'conference-info' event package [RFC4575].

5.5.3.  <relations>/<relation>

   The <relations> element serves as container for <relation> elements,
   each describing a specific connection between to another focus peer.
   The parent element <relations> uses the 'state' attribute to enable
   the partial notification mechanism.  For the <relation> element the
   following attribute is defined:

   entity:  This attribute contains the AoR of the remote focus.

   The content of each <relation> is a comma separated string that
   describes the tuple <CONNECTION-TYPE,IDENTIFIER>.  The CONNECTION-
   TYPE describes the type of connection (e.g. media, signaling, etc.)
   and the IDENTIFIER contains a token that uniquely identifies the
   connection in the conference.  It is meant as a generic method to
   announce any kind of connection to a remote focus.  This
   specification defines following tuples:

   media,label:  This tuple identifies a single media stream originated
      in the focus peer described in the parent <focus> element.  The
      'media' part indicates that this connections belongs to any kind
      of media connection.  The 'label' part uniquely identifies to the
      stream within the conference and corresponds to the SDP "label"
      media attribute defined in [RFC4574].

   sync,call-id:  This tuple indicates a subscription for the event
      package for distributed conferences.  The remote focus peer
      described in the 'entity' attribute is a subscriber for
      distributed-conference event package for the purpose of conference
      state synchronization.  The 'call-id' part thereby corresponds to
      the call-id of the SIP subscription dialog.

5.6.  Distribution of Change Events

   Maintaining a coherent conference state at each controller of a
   distributed conference, requires a common protocol scheme to
   communicate each conference change event to each focus peer.  Using
   SIP specific event notifications [RFC3265], this requirement would
   result in an N to M relation (with N=M), between N notifiers and M
   subscribers to synchronize the conference state.  To avoid a 'full
   meshed' subscription topology, where each focus peer has N
   subscriptions to all other focus peers, this section describes a
   'mutual' subscription scheme that constructs a spanning tree topology
   among the focus peers.




Knauf, et al.             Expires July 3, 2011                 [Page 26]


Internet-Draft                    DisCo                    December 2010


   A member in a distributed conference that accepted an authorized
   participation request and becomes a new focus peer, SHOULD join the
   state synchronization process of a conference.  Therefore, it sends a
   SIP SUBSCRIBE to request the Event Package for Distributed
   Conferences to its own focus peer.  The subscription request SHOULD
   be addressed to AoR of the active focus peer, thus it interprets this
   subscription as a request for conference state synchronization.  The
   corresponding NOTIFY message contains a 'full' distributed-conference
   state XML document (see section Section Section 5.1).

   Following, the subscribed focus peer has to subscribe the new
   upcoming focus peer for the distributed conference event package.
   The corresponding notification by the new focus carries a 'partial'
   conference state XML document.  It contains the received <version-
   vector> including a new <version> element for itself and contains a
   new <focus> element that describes its local state (see section
   Section 5.5).

   Resulting by this subscription scheme, each focus peer has at least
   one subscription to obtain updates for the conference state and is a
   notifier for change events originated itself.  In a incrementally
   increasing conference, the 1st and 2nd focus peer have a mutual
   subscription for conference change events.  A 3rd focus could have a
   mutual subscription with the 1st focus, a 4th focus to the 2nd focus
   and so forth.  The result is a spanning tree topology among the focus
   peers in which each focus peer is a possible root for distribution
   tree for conference change events.

   However, the fact that event notifications need to traverse one or
   more intermediate focus peers until conference-wide delivery, demands
   a forwarding mechanism for change events.  On receiving a change
   event, a notified focus firstly validates based on the <version-
   vector> whether the incoming state event is not a duplicate to
   previews notifications.  If its not a duplicate, the received change
   event, secondly, triggers a new event notification process at the
   receiver of the change event.  It notifies all its subscribers with
   excepting the sender of the event notification (which is not
   necessarily the event originator).  Thus, the change event will be
   'flooded' among the focus peer of a conference.

5.7.  Translation to Conference-Info Event Package

   The Event Package for Distributed Conferences imports several XML
   element definitions of the Event Package for Conference State
   [RFC4575].  This is caused by two reasons.  Firstly, the semantic of
   these elements are fitting the demands to describe the global state
   of a distributed conference and, secondly, it facilitates a re-
   translation to [RFC4575] to enable a backward compatibility to DisCo-



Knauf, et al.             Expires July 3, 2011                 [Page 27]


Internet-Draft                    DisCo                    December 2010


   unaware clients.  Therefore, each focus peer MAY provide a separate
   [RFC4575] conform event notification service to its connected
   participants.

   The following sections describe the translation to the Event Package
   for Conference State [RFC4575] by defining translation rules for the
   root element and its direct sub elements.  For a better
   understanding, the following sections use a notation ci.<ELEMENT> to
   refer to a sub element of the conference-info element, and
   disco.<ELEMENT> to refer to an element of the distributed-conference
   event package.

5.7.1.  <conference-info>

   The root element of Event Package for Conference State uses the
   attributes 'entity', 'state' and 'version' and is the counterpart of
   the <distributed-conference> root element in the DisCo Event Package.
   The former two attributes 'entity' and 'state' are equal in both root
   elements and can be seamlessly translated.

   According to [RFC4575], the version attribute SHOULD be incremented
   by one at any time a new notification being sent to a subscriber.
   New notifications SHOULD be triggered by change events that are
   originated within a focus peer and SHOULD be triggered by reception
   of a 'distributed-conference' event state of another focus peer.

5.7.2.  <conference-description>

   The <conference-description> element exists in both event packages,
   conference-info and distributed-conference.  Thus, the following
   elements are seamlessly translatable: <keywords>, <display-text>,
   <subject>, <free-text> and <service-uris>.

   The sub elements <conf-uris>, <maximum-user-count> and <available-
   media> in conference-info have there counterparts below the
   \focus\focus-state element of the distributed-conference event
   package.  Each describes a local state of a focus peer in the
   conference.  Hence, the intersection of every disco.<conf-uris>,
   disco.<available-media> and the sum over each disco.<maximum-user-
   count> element of each disco.<focus> element in distributed-
   conference, specifies the content of the corresponding conference-
   info elements.

5.7.3.  <host-info>

   According to [RFC4575] the ci.<host-info> element contains
   information about the entity hosting the conference.  For
   participants in a distributed conference, the hosting entity is the



Knauf, et al.             Expires July 3, 2011                 [Page 28]


Internet-Draft                    DisCo                    December 2010


   focus peer through which they are connected to the conference.  Thus,
   the ci.<host-info> element contains information about a focus peer
   that is serving its participants.

5.7.4.  <conference-state>

   The ci.<conference-state> element allows subscribers obtain
   information about overall state of a conference.  Its sub elements
   ci.<user-count>, ci.<active> and ci.<locked> are reused as sub
   elements of \focus\focus-state to describe the local state of a focus
   peer in a distributed conference.  The translation rules from the
   distributed-conference to the conference-info event package are the
   following:

   <user-count>:  The sum over each value of the disco.<user-count>
      element defines the corresponding ci.<user-count>.

   <active>:  The boolean ci.<active> element is defined by the logical
      concatenation over all disco.<active> elements by an OR-operator.

   <locked>  The boolean ci.<locked> element is defined by the logical
      concatenation over all disco.<locked> elements by an AND-operator.

5.7.5.  <users>/<user>

   The distributed-conference event package imports the definitions of
   the ci.<users> and ci.<user> elements under a parent disco.<focus>
   element for each focus peer in a conference.  Thus, the aggregation
   over all disco.<users> elements specifies the content of the
   corresponding ci.<users> element.

5.7.6.  <sidebars-by-ref>/<sidebars-by-value>

   In accordance to [RFC4575], if a participant is connected to a
   sidebar, its responsible focus peer creates a new <user> by
   referencing to the corresponding sidebar conference.















Knauf, et al.             Expires July 3, 2011                 [Page 29]


Internet-Draft                    DisCo                    December 2010


6.  Distributed Conference Control with SIP

6.1.  Call delegation

   Distributed conference control provides the possibility to delegate
   the control for a conference participant from one focus to another
   remote focus for some reason.  In contrast to common call transfers
   that are using the SIP REFER method as described in [RFC3515], call
   delegations are achieved transparently to the transferred party.

   However, a focus peer starts a call delegation by sending SIP REFER
   request containing the URI of the participant in the Refer-To header
   field.  Additionally, the focus peer appends the following parameter
   to the URI of the participant:

   call-id:  Contains the call-ID of the original SIP dialog
      establishment between the referred participant and the referring
      focus peer.

   sess-id:  Contains the 'session identifier' value of the original SDP
      'o=' field of the original offer/answer process between referred
      participant and referring focus peer.

   If the recipient accepts the REFER request, it generates a re-INVITE
   towards the referred party and sets the SIP call-id header and the
   SDP 'session-identifier' field in the SDP offer, according to the URI
   parameter values of the initial REFER request.  The From header field
   and contact header are set to the conference URI with setting the
   'isfocus' tag to contact header.  This identifies the peer as a focus
   to the conference and identifies this re-INVITE as a request of the
   SIP dialog between the party and the conference.  To ensure that
   further signaling messages will be routed correctly, the new focus
   adds a Record-Route header field that contains the contact
   information (URI, IP-address,..) of this peer.

   An example call flow for call delegation is shown in Figure 6.















Knauf, et al.             Expires July 3, 2011                 [Page 30]


Internet-Draft                    DisCo                    December 2010


   Participant    Referring Focus                         Remote Focus
   --------------------------------------------------------------------
        |    Dialog    |                                     |
        |<============>|                                     |
        |              |                                     |
        |  Delegating a participant to remote focus          |
        |              |                                     |
        |              |(1) REFER refer-to:<uri>?call-id=123&sess-id=456
        |              |------------------------------------>|
        |              |(2) 200 OK                           |
        |              |<------------------------------------|
        |              |(3) Notify: pending                  |
        |              |<------------------------------------|
        |              |(4) 200 OK                           |
        |              |------------------------------------>|
        |              |                                     |
        |  Remote focus adds RR-header that carries its URI  |
        |              |                                     |
        |  (5) INVITE sip:<uri> record-route:<rem.focus>     |
        |<---------------------------------------------------|
        |  (6) 200 OK  |                                     |
        |--------------------------------------------------->|
        |  (7) ACK     |                                     |
        |<---------------------------------------------------|
        |              |(8) Notify: active                   |
        |              |<------------------------------------|
        |              |(9) 200 OK                           |
        |              |------------------------------------>|

             Figure 6: Delegating a participant with SIP REFER

   Note, subscriptions for the event packages 'distributed-conference'
   and 'conference-info' are in scope of a specific focus peer and its
   connected participants.  Hence, after a successful call delegation,
   the referring focus peer SHOULD terminate any subscription to the
   referred participant.  The notifier SHOULD include a reason parameter
   "deactivated" to indicate a migration of the subscription as defined
   in [RFC3265].  The new SUBSCRIBE request by the party MUST be sent
   via the SIP dialog to the conference.

6.2.  Conference Access

   It is an important issue to define who is allowed to participate a
   multimedia conference.  In many cases, a group conversation can be an
   open discussion free to participate, while in other occasions a
   closed privacy of a multiparty session is demanded.  Additionally, it
   is an issue which of the conference participant is allowed to become
   a controller of the multiparty session.



Knauf, et al.             Expires July 3, 2011                 [Page 31]


Internet-Draft                    DisCo                    December 2010


   To provide those constraints for distributed conferences in RELOAD,
   this document defines a basic set of conference access that decide
   whether:

   o  A peer is allowed to participate a conference

   o  A peer is allowed to become a focus of the conference

   Both cases can be regulated with plain SIP authorization mechanisms
   achieved by the focus peers asking for a participants credentials.
   Those credentials and the allowed users can be setup at creation of
   the conference.  It is up by the conference to define different
   access role deciding if a user is allowed to become a focus peer or
   not.

6.3.  Media Negotiation and Distribution

   This section describes a basic scheme for media negotiation and
   distribution, which is done in an ad-hoc fashion.  Each focus peer
   forwards all media streams it receives from the conference to all
   connected peers it is responsible for and similarly all streams from
   its peers to its responsible focus.  This results in the media stream
   naturally following the SIP signalling paths.  Implementations MAY
   choose to use a more sophisticated scheme, e.g. employing cross
   connections between different sub-trees of the conference, but MUST
   take measures to prevent loops in media routing.

   When a new peer has been attached to a focus, new media steams may be
   available to the focus, which need to be forwarded to the conference.
   To accomplish this, the new media streams need to be signalled to the
   other participants.  This is usually done by sending a SIP re-INVITE
   and modifying the media sessions, adding the new streams to the SDP.
   This renegotiation can be costly since it needs to be propagated
   through the whole conference.  Also, distributing all media streams
   separately to all participants can be quite bandwidth intensive.
   Both problems can partially be mitigated by focus peers performing
   mixing of media streams, thus trading bandwidth and signalling
   overheads for computational load on focus peers.

6.3.1.  Offer/Answer

   A peer joining a conference negotiates media types and media
   parameters with its designated focus using the standard SDP offer/
   answer protocol [RFC3264].  The focus SHOULD offer all media streams
   used in the conference.

   A new participant does not necessarily know about all media streams
   present in a conference beforehand, and thus some of the media



Knauf, et al.             Expires July 3, 2011                 [Page 32]


Internet-Draft                    DisCo                    December 2010


   streams might not be included in the initial SDP offer sent by the
   joining peer.  An SDP answer sent by the corresponding focus MUST NOT
   contain any media streams not matching an offer (cf. [RFC3264]
   Section 6).  A joining peer which is aware of the distributed nature
   of the conference, SHOULD NOT send an SDP offer in the initial INVITE
   message, but instead send an empty INVITE to which the focus replies
   with an OK, containing the offer.  This prevents the need for a
   second offer/answer-dialog to modify the session.  But for
   compatibility the normal behavior with the INVITE containing the
   offer MUST be supported.

   The focus SHOULD only offer media types and codecs which are already
   used in the conference and which will probably be accepted when
   forwarded to neighboring peers, unless the focus is prepared to do
   transcoding and/or mixing of the received streams.

   A focus has two options when distributing media streams from a new
   participant to the conference.  The focus can either mix the new
   streams into his own, thus averting the need to modify the already
   established media sessions with neighboring peers or in case the
   focus is not willing or able to do mixing of the media streams, he
   SHOULD modify the media sessions with all attached peers by sending a
   re-INVITE, adding the new media streams coming from the newly joined
   participant to the SDP.  This SHOULD subsequently be done by all
   other focus peers upon receiving the new stream, resulting in the
   stream being distributed across the conference.

6.4.  Restructuring a Conference

   Distributed conference control provides the possibility to delegate
   calls to remote focus peers.  This feature is used to restructure a
   conference in case of departure of a focus peer.  Following, this
   section presents restructuring schemes for graceful and unexpected
   leaves of conference focus peers.

6.4.1.  On Graceful Leave

   In a graceful case, the leaving focus peer (LP) accomplishes the
   following procedure:

   o  LP deletes its mapping in the DisCo-Registration by storing the
      "non-existing" value as described in the RELOAD base document
      [I-D.ietf-p2psip-base].  Afterwards, it fetches the lasted version
      of the DisCo-Registration to obtain all potential focus peers.

   o  LP calculates for all its participants the closest focus among all
      active and potential focus peer using the algorithm described in
      Section 4.2.  LP then delegates all participants to those focus



Knauf, et al.             Expires July 3, 2011                 [Page 33]


Internet-Draft                    DisCo                    December 2010


      peers.

   o  LP then announces its leave by sending a NOTIFY to all its
      subscribers for the extended conference event package, setting its
      <focus> state to 'deleted'.  Thereafter, it ends its own SIP
      conference dialog by sending by to its related focus peer.

   Since the state synchronization topology in a distributed conference
   is commonly arranged in a spanning tree, a leave of a focus peer
   effects a gab in the tree structure.  Those focus peers which had the
   leaving focus peer as their parent focus, are supposed to reconnect
   to the synchronization graph, by subscribing the leaving peer's
   parent node.

6.4.2.  On Unexpected Leave

   If an unexpected leave is detected by a participant (e.g. missing
   signaling and/or media packets) it MUST repeat the joining procedure
   as described in Section 4.5.
































Knauf, et al.             Expires July 3, 2011                 [Page 34]


Internet-Draft                    DisCo                    December 2010


7.  DisCo Kind Definition

   This section formally defines the DisCo kind.
    Name
        DISCO-REGISTRATION

    Kind IDs
        The Resource name DISCO-REGISTRATION Kind-ID is the AoR of the
        conference. The data stored is the DisCoRegistrationData, that
        contains a coordinates value describing a peers relative network
        position acting as focus for the conference. Additionally it
        contains either the peers URI or a Destination list.

    Data Model
        The data model for the DISCO-REGISTRATION Kind-ID is dictionary.
        The dictionary key is
        the Node-ID of the peer action as focus.

    Access Control
        USER-MATCH
         or
        USER-CHAIN-MATCH

    The data stored for the Kind-ID DISCO-REGISTRATION is of type
    DisCoRegistration. It contains a "coordinates" value, that
    describes the peers relative network position and
    XOR one of the two following data:

        sip_focus_uri
            the URI of the peer action as focus
        sip_focus_node_id
            the Destination list of the peer acting as focus



















Knauf, et al.             Expires July 3, 2011                 [Page 35]


Internet-Draft                    DisCo                    December 2010


8.  Access Control Policy USER-CHAIN-MATCH

   The base RELOAD document [I-D.ietf-p2psip-base] mandates that every
   kind definition specifies an Access Control Model to use.  The base
   document defines four access control policies, of which none is
   fitting for the purpose of shared write access to a resource.  This
   document defines a new access control model called USER-CHAIN-MATCH.

   In the USER-CHAIN-MATCH policy, a given value MUST be written (or
   overwritten) if and only if the request is singed with a key
   associated with a certificate whose user name hashes (using the hash
   function for the overlay) to the Resource-ID for the resource.  Also
   the user name of the certificate MUST match the user name of an
   intermediary certificate in the chain to the root certificate, using
   the matching pattern specified in the configuration document for the
   corresponding kind.



































Knauf, et al.             Expires July 3, 2011                 [Page 36]


Internet-Draft                    DisCo                    December 2010


9.  XML Schema

   The XML schema for the event package for distributed conferences is:

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:ci="urn:ietf:params:xml:ns:conference-info"
        xmlns="urn:ietf:params:xml:ns:distributed-conference"
        targetNamespace="urn:ietf:params:xml:ns:distributed-conference"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">
   <!--
       This imports the definitions in conference-info
   -->
   <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
           schemaLocation="http://www.iana.org/assignments/xml-registry/
                        schema/conference-info.xsd"/>
   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
        schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
     <!--
      A DISTRIBUTED CONFERENCE ELEMENT
   -->
   <xs:element name="distributed-conference"
               type="distributed-conference-type"/>
     <!--
       DISTRIBUTED CONFERENCE TYPE
   -->
     <xs:complexType name="distributed-conference-type">
       <xs:sequence>
         <xs:element name="version-vector"
               type="version-vector-type" minOccurs="1"/>
         <xs:element name="conference-description"
         type="conference-description-type"
         minOccurs="0" maxOccurs="1"/>
         <xs:element name="focus"
         type="focus-type"
         minOccurs="0"
         maxOccurs="unbounded"/>
          <xs:any namespace="##other" processContents="lax"/>
        </xs:sequence>
        <xs:attribute name="state" type="ci:state-type"/>
        <xs:attribute name="entity" type="xs:anyURI"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>
   <!--
       VERSION VECTOR TYPE
   -->
     <xs:complexType name="version-vector-type">



Knauf, et al.             Expires July 3, 2011                 [Page 37]


Internet-Draft                    DisCo                    December 2010


       <xs:sequence>
         <xs:element name="version"
                     type="version-type"
                     minOccurs="1"
                     maxOccurs="unbounded"/>
         <xs:any namespace="##other" processContents="lax"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>
   <!--
       CONFERENCE DESCRIPTION TYPE
   -->
     <xs:complexType name="conference-description-type">
       <xs:sequence>
         <xs:element name="display-text"
                     type="xs:string" minOccurs="0"/>
         <xs:element name="subject" type="xs:string" minOccurs="0"/>
         <xs:element name="free" type="xs:string" minOccurs="0"/>
         <xs:element name="keywords"
                     type="ci:keywords-type" minOccurs="0"/>
         <xs:element name="service-uris"
                     type="ci:uris-type" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax"/>
       </xs:sequence>
       <xs:attribute name="state" type="ci:state-type"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>
   <!--
       FOCUS TYPE
   -->
     <xs:complexType name="focus-type">
       <xs:sequence>
         <xs:element name="display-text"
                     type="xs:string" minOccurs="0"/>
         <xs:element name="associated-aors"
                     type="ci:uris-type" minOccurs="0"/>
         <xs:element name="roles"
                     type="ci:user-roles-type" minOccurs="0"/>
         <xs:element name="languages"
                     type="ci:user-languages-type" minOccurs="0"/>
         <xs:element name="focus-state"
                     type="focus-state-type" minOccurs="0"/>
         <xs:element name="users"
                     type="ci:users-type" minOccurs="0"/>
         <xs:element name="relations"
                     type="relations-type" minOccurs="0"/>
         <xs:any namespace="#other" processContents="lax"/>
       </xs:sequence>



Knauf, et al.             Expires July 3, 2011                 [Page 38]


Internet-Draft                    DisCo                    December 2010


       <xs:attribute name="entity" type="xs:anyURI"/>
       <xs:attribute name="state" type="ci:state-type"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>
   <!--
       VERSION TYPE
   -->
     <xs:complexType name="version-type">
       <xs:simpleContent>
         <xs:extension base="xs:unsignedInt">
           <xs:attribute name="entity" type="xs:anyURI"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
     <!--
       FOCUS STATE TYPE
   -->
     <xs:complexType name="focus-state-type">
       <xs:sequence>
         <xs:element name="user-count"
                     type="xs:unsignedInt" minOccurs="0"/>
         <xs:element name="maximal-user-count"
                     type="xs:unsignedInt" minOccurs="0"/>
         <xs:element name="conf-uris"
                     type="ci:uris-type" minOccurs="0"/>
         <xs:element name="available-media"
                     type="ci:conference-media-type" minOccurs="0"/>
         <xs:element name="active" type="xs:boolean" minOccurs="0"/>
         <xs:element name="locked" type="xs:boolean" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax"/>
       </xs:sequence>
       <xs:attribute name="state" type="ci:state-type"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>
     <!--
       RELATIONS TYPE
   -->
     <xs:complexType name="relations-type">
       <xs:sequence>
         <xs:element name="relation"
                     type="relation-type"
                     minOccurs="0" maxOccurs="unbounded"/>
         <xs:any namespace="##other" processContents="lax"/>
       </xs:sequence>
       <xs:attribute name="state" type="ci:state-type"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>



Knauf, et al.             Expires July 3, 2011                 [Page 39]


Internet-Draft                    DisCo                    December 2010


     <!--
       RELATION TYPE
   -->
     <xs:complexType name="relation-type">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="entity" type="xs:anyURI"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
   </xs:schema>







































Knauf, et al.             Expires July 3, 2011                 [Page 40]


Internet-Draft                    DisCo                    December 2010


10.  Relax NG Grammar

   The grammar for the Landmark configuration document extension is:

   <!--
       LANDMARKS ELEMENT
   -->
   parameter &amp;= element landmarks {
       attribute version { xsd:int }
       <!--
           LANDMARK-HOST ELEMENT
       -->
       element landmark-host {
           attribute address { xsd:string },
           attribute port { xsd:int }
       }*
   }?


































Knauf, et al.             Expires July 3, 2011                 [Page 41]


Internet-Draft                    DisCo                    December 2010


11.  Security Considerations

11.1.  Trust Aspects

   TODO: Describing the privacy level for a conference instance; define
   whether a joining user is allowed to become a member or even focus of
   a conference.












































Knauf, et al.             Expires July 3, 2011                 [Page 42]


Internet-Draft                    DisCo                    December 2010


12.  IANA Considerations

   TODO: register Kind-ID code point at the IANA
















































Knauf, et al.             Expires July 3, 2011                 [Page 43]


Internet-Draft                    DisCo                    December 2010


13.  Acknowledgments

   This work was stimulated by fruitful discussions in the P2PSIP
   working group and SAM research group.  We would like to thank all
   active members for constructive thoughts and feedback.  In
   particular, the authors would like to thank (in alphabetical order)
   David Bryan, Toerless Eckert, Lothar Grimm, Cullen Jennings, Peter
   Musgrave, Joerg Ott, Peter Pogrzeba, Brian Rosen, and Jan Seedorf.











































Knauf, et al.             Expires July 3, 2011                 [Page 44]


Internet-Draft                    DisCo                    December 2010


14.  References

14.1.  Normative References

   [I-D.ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-12 (work in
              progress), November 2010.

   [I-D.ietf-p2psip-sip]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "A SIP Usage for RELOAD",
              draft-ietf-p2psip-sip-05 (work in progress), July 2010.

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

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

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
              Initiation Protocol (SIP) Event Package for Conference
              State", RFC 4575, August 2006.

14.2.  Informative References

   [I-D.ietf-p2psip-concepts]
              Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
              Dawkins, "Concepts and Terminology for Peer to Peer SIP",
              draft-ietf-p2psip-concepts-03 (work in progress),
              October 2010.




Knauf, et al.             Expires July 3, 2011                 [Page 45]


Internet-Draft                    DisCo                    December 2010


   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol (SIP)", RFC 4353,
              February 2006.

   [timestamps-acsc88]
              Fidge, C., "Timestamps in Message-Passing Systems that
              Preserve the Partial Ordering", Proceedings of 11th
              Australian Computer Science Conference, pp. 56-66,
              February 1988.










































Knauf, et al.             Expires July 3, 2011                 [Page 46]


Internet-Draft                    DisCo                    December 2010


Appendix A.  Change Log

   The following changes have been made from version
   draft-knauf-p2psip-disco-00.

   1.  Updated references.

   2.  Corrected typos.

   3.  New Section: Conference State Synchronization

   4.  XML Event Package for Distributed Conferences

   5.  New mechanism for generating chained conference certificates

   6.  Allow shared writing of resources using Access Control Policy
       USER-CHAIN-MATCH

   7.  Media Negotiation mechanism in a distributed conference

   8.  New Section: Distributed Conference Control with SIP






























Knauf, et al.             Expires July 3, 2011                 [Page 47]


Internet-Draft                    DisCo                    December 2010


Authors' Addresses

   Alexander Knauf
   HAW Hamburg
   Berliner Tor 7
   Hamburg  D-20099
   Germany

   Phone: +4940428758067
   Email: alexander.knauf@haw-hamburg.de
   URI:   http://inet.cpt.haw-hamburg.de/members/knauf


   Gabriel Hege
   HAW Hamburg
   Berliner Tor 7
   Hamburg  D-20099
   Germany

   Phone: +4940428758067
   Email: hege@fhtw-berlin.de
   URI:   http://inet.cpt.haw-hamburg.de/members/hege


   Thomas C. Schmidt
   HAW Hamburg
   Berliner Tor 7
   Hamburg  D-20099
   Germany

   Email: schmidt@informatik.haw-hamburg.de
   URI:   http://inet.cpt.haw-hamburg.de/members/schmidt


   Matthias Waehlisch
   link-lab & FU Berlin
   Hoenower Str. 35
   Berlin  D-10318
   Germany

   Email: mw@link-lab.net
   URI:   http://www.inf.fu-berlin.de/~waehl









Knauf, et al.             Expires July 3, 2011                 [Page 48]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/