tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6504

 
 
 

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Part 3 of 4, p. 31 to 60
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 31 
6.  Conference Users Scenarios and Examples

   Section 5 showed examples describing the several different ways a
   conference might be created using CCMP.  This section focuses on
   user-related scenarios, i.e., typical scenarios that may occur during

Top      Up      ToC       Page 32 
   the lifetime of a conference, like adding new users and handling
   their media.  The following scenarios are based on those documented
   in the XCON framework.  The examples assume that a conference has
   already been correctly established, with media, if applicable, per
   one of the examples in Section 5.

6.1.  Adding a Party

   In this example, Alice wants to add Bob to an established conference.
   In the following example we assume Bob is a new user of the system,
   which means Alice also needs to provide some details about him.  In
   fact, the case of Bob already present as a user in the conferencing
   system is much easier to address, and will be discussed later.

    Alice          Bob
    CMCC1          CMCC2       CMCCx       ConfS
     |               |           |           |
     |(1) userRequest(confUserID,|           |
     |    confObjID, create,     |           |
     |    userInfo)  |           |           |
     |-------------------------------------->|
     |               |           |           |
     |               |        (a) Create +---|
     |               |           | Bob   |   |
     |               |           | as a  |   |
     |               |           | user  +-->|
     |               |           |           |
     |(2) userResponse(confUserID, confObjID |
     |      create, 200, success, userInfo)  |
     |<--------------------------------------|
     |               |           |           |
     |               |           | (b) Focus |
     |               |           |   sets up |
     |               |           | signaling |
     |               |           |    to Bob |
     |               |<----------------------|
     |               |           |           |
     |               |           | (c) Notify|
     |               |           | ("Bob just|
     |               |           |  joined") |
     |               |           |<----------|
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

        Figure 11: Client Manipulation of Conference - Add a Party

Top      Up      ToC       Page 33 
   1.  Alice sends a userRequest message with an operation of "create"
       to add Bob to the specific conference as identified by the XCON-
       URI in the <confObjID>.  The "create" <operation> also makes sure
       that Bob is created as a user in the whole conferencing system.
       This is done by adding in the request a <userInfo> element
       describing Bob as a user.  This is needed in order to let the
       conferencing system be aware of Bob's characteristics.  In case
       Bob was already a registered user, Alice would just have
       referenced him through his XCON-USERID in the 'entity' attribute
       of the <userInfo> field, without providing additional data.  In
       fact, that data (including, for instance, Bob's SIP-URI to be
       used subsequently for dial-out) would be obtained by referencing
       the extant registration.  The conference server ensures that
       Alice has the appropriate authority based on the policies
       associated with that specific conference object to perform the
       operation.  As mentioned before, a new XCON-USERID is created for
       Bob, and the <userInfo> is used to update the conference object
       accordingly.  As already seen in Section 5.3, a placeholder
       wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP
       messages below) is used for the 'entity' attribute of the
       <userInfo> element, to be replaced by the actual XCON-USERID
       later;

   2.  Bob is successfully added to the conference object, and an XCON-
       USERID is allocated for him ("xcon-userid:Bob@example.com"); this
       identifier is reported in the response as the value of the
       'entity' attribute of the returned <userInfo>;

   3.  In the presented example, the call signaling to add Bob to the
       conference is instigated through the focus as well.  As noted
       previously, this is implementation specific.  In fact, a
       conferencing system may accomplish different actions after the
       user creation, just as it may do nothing at all.  Among the
       possible actions, for instance, Bob may be added as a <target>
       element to the <allowed-users-list> element, whose joining
       'method' may be either "dial-in" or "dial-out".  Besides, out-of-
       band notification mechanisms may be involved as well, e.g., to
       notify Bob via mail of the new conference, including details as
       the date, password, expected participants, and so on (see
       Section 4.3).

      Once Bob has been successfully added to the specified conference,
      per updates to the state, and depending upon the policies, other
      participants (including Bob himself) may be notified of the
      addition of Bob to the conference via the conference notification
      service in use.

Top      Up      ToC       Page 34 
1. userRequest/create message (Alice adds Bob)

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
        xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:userRequest>
          <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
              <info:display-text>Bob</info:display-text>
              <info:associated-aors>
                  <info:entry>
                    <info:uri>mailto:bob.depippis@example.com</info:uri>
                    <info:display-text>Bob's email</info:display-text>
                  </info:entry>
              </info:associated-aors>
              <info:endpoint entity="sip:bob83@example.com">
                  <info:display-text>Bob's laptop</info:display-text>
              </info:endpoint>
          </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. userResponse/create message (a new XCON-USERID is
   created for Bob and he is added to the conference)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
         xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
         xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <response-code>200</response-code>
        <response-string>success</response-string>
        <version>10</version>
        <ccmp:userResponse>
          <userInfo entity="xcon-userid:Bob@example.com">
              <info:display-text>Bob</info:display-text>
              <info:associated-aors>
                  <info:entry>

Top      Up      ToC       Page 35 
                    <info:uri>mailto:bob.depippis@example.com</info:uri>
                    <info:display-text>Bob's email</info:display-text>
                  </info:entry>
              </info:associated-aors>
              <info:endpoint entity="sip:bob83@example.com">
                  <info:display-text>Bob's laptop</info:display-text>
              </info:endpoint>
          </userInfo>
        </ccmp:userResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

                   Figure 12: Add Party Message Details

6.2.  Muting a Party

   This section provides an example of the muting of a party in an
   active conference.  We assume that the user to mute has already been
   added to the conference.  The document only addresses muting and not
   unmuting, since the latter would involve an almost identical CCMP
   message flow anyway.  However, if any external floor control is
   involved, whether a particular conferencing client can actually mute/
   unmute itself must be considered by the conferencing system.

      Please notice that interaction between CCMP and floor control
      should be carefully considered.  In fact, handling CCMP- and BFCP-
      based media control has to be considered as multiple layers: that
      is, a participant may have the BFCP floor granted, but be muted by
      means of CCMP.  If so, he would still be muted in the conference,
      and would only be unmuted if both the protocols allowed for this.

   Figure 13 provides an example of one client, Alice, impacting the
   media state of another client, Bob.  This example assumes an
   established conference.  In this example, Alice, who is the moderator
   of the conference, wants to mute Bob on a medium-sized multi-party
   conference, as his device is not muted (and he's obviously not
   listening to the call) and background noise in his office environment
   is disruptive to the conference.  BFCP floor control is assumed not
   to be involved.

   Muting can be accomplished using the <mute> control element
   associated with the target user's audio, in which case the conference
   server must update the settings associated with the user's media
   streams.  Muting/unmuting can also be accomplished by directly
   modifying the settings related to the target user's media streams,
   which is the approach shown in this example.  Specifically, Bob's
   <userInfo> is updated by modifying the <endpoint> element in the

Top      Up      ToC       Page 36 
   <media> part related to audio information, identified by the 'id'
   attribute.  The modification consists in setting the audio <status>
   to "recvonly", in case of muting.

    Alice          Bob
    CMCC1          CMCC2       CMCCx        ConfS                MS
     |               |           |            |                  |
     |(1) userRequest(subject,   |            |                  |
     |    confUserID,confObjID,  |            |                  |
     |    update,userInfo)       |            |                  |
     |               |           |            |                  |
     |--------------------------------------->|                  |
     |               |           |            | Mute Bob         |
     |               |           |            |----------------->|
     |               |           |            |           200 OK |
     |               |           |            |<-----------------|
     |               |           |            |                  |
     |               |<====== XXX Bob excluded from mix XXX ====>|
     |               |           |            |                  |
     |               |         (a) Update +---|                  |
     |               |             Bob in |   |                  |
     |               |         data model |   |                  |
     |               |            (muted) +-->|                  |
     |               |           |            |                  |
     | (2)userResponse(confUserID,confObjID,  |                  |
     |           update,200,success,version)  |                  |
     |<---------------------------------------|                  |
     |               |           |            |                  |
     |               |           | (b) Notify |                  |
     |               |           |   ("Bob is |                  |
     |               |           |    muted") |                  |
     |               |           |<-----------|                  |
     |               |           |            |                  |
     '               '           '            '                  '
     '               '           '            '                  '
     '               '           '            '                  '

        Figure 13: Client Manipulation of Conference - Mute a Party

   1.  Alice sends a userRequest message with an "update" <operation>
       and the <userInfo> with the <status> field in the <media> element
       for Bob's <endpoint> set to "revconly".  In order to authenticate
       herself, Alice provides in the <subject> request parameter her
       registration credentials (i.e., username and password).  The
       <subject> parameter is an optional one: its use can be systematic
       whenever the conference server envisages to authenticate each

Top      Up      ToC       Page 37 
       requester.  In such cases, if the client does not provide the
       required authentication information, the conferencing server
       answers with a CCMP "authenticationRequired" <response-code>,
       indicating that the request cannot be processed without including
       the proper <subject> parameter.  The conference server ensures
       that Alice has the appropriate authority based on the policies
       associated with that specific conference object to perform the
       operation.  It recognizes that Alice is allowed to request the
       specified modification, since she is moderator of the target
       conference, and updates the <userInfo> in the conference object
       reflecting that Bob's media is not to be mixed with the
       conference media.  If the conference server relies on a remote
       media server for its multimedia functionality, it subsequently
       changes Bob's media profile accordingly by means of the related
       protocol interaction with the MS.  An example describing a
       possible way of dealing with such a situation using the media
       server control architecture [RFC5567] is described in Figure 31,
       "Simple Bridging: Framework Transactions (2)", in [CALL-FLOWS].

   2.  A userResponse message with a "200" <response-code> ("success")
       is then sent to Alice.  Depending upon the policies, the
       conference server may notify other participants (including Bob)
       of this update via any conference notification service that may
       be in use.

 1. userRequest/update message (Alice mutes Bob)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
        xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:type="ccmp:ccmp-user-request-message-type">
       <subject>
          <username>Alice83</username>
          <conference-password>13011983</conference-password>
        </subject>
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>update</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Bob@example.com">
                <info:endpoint entity="sip:bob83@example.com">
                    <info:media id="1">
                        <info:label>123</info:label>
                        <info:status>recvonly</info:status>
                    </info:media>
                </info:endpoint>

Top      Up      ToC       Page 38 
            </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. userResponse/update message (Bob has been muted)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
               xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
               xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>update</operation>
        <response-code>200</response-code>
        <response-string>success</response-string>
            <version>7</version>
        <ccmp:userResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

                      Figure 14: Mute Message Details

6.3.  Conference Announcements and Recordings

   This section deals with features that are typically required in a
   conferencing system, such as public announcements (e.g., to notify
   vocally that a new user joined a conference) and name recording.
   While this is not strictly CCMP-related (the CCMP signaling is
   actually the same as the one seen in Section 6.1), it is an
   interesting scenario to address to see how several components of an
   XCON-compliant architecture interact with each other to make it
   happen.

   In this example, as shown in Figure 15, Alice is joining Bob's
   conference that requires that she first enter a passcode.  After
   successfully entering the passcode, an announcement prompts Alice to
   speak her name so it can be recorded.  When Alice is added to the
   active conference, the recording is played back to all the existing
   participants.  A very similar example is presented in Figure 33 of
   [CALL-FLOWS].

Top      Up      ToC       Page 39 
   CMCC  Alice                    ConfS                         MS
        |                            |                            |
        |(1)userRequest(confObjID,   |                            |
        |         create,userInfo)   |                            |
        |--------------------------->|                            |
        |                            |--+ Alice is                |
        |                            |  | new in the              |
        |                            |<-+ system (create          |
        |                            |    confUserID)             |
        |           ConfS handles +--|                            |
        |           SIP signaling |  |                            |
        |    (Alice<->ConfS<->MS) +->|                            |
        |                            |                            |
        |                            |--+ A password is           |
        |                            |  | required for            |
        |                            |<-+ that conference         |
        |                            |                            |
        |                            | Request IVR menu (PIN)     |
        |                            |--------------------------->|
        |                            |                            |
        |<========= MS gets PIN from Alice through DTMF =========>|
        |                            |                            |
        |                            |        Provided PIN is...  |
        |                            |<---------------------------|
        |                   Check +--|                            |
        |                     PIN |  |                            |
        |                         +->|                            |
        |                            |--+ Alice must              |
        |                            |  | record her              |
        |                            |<-+ name                    |
        |                            |                            |
        |                            | Request name recording     |
        |                            |--------------------------->|
        |                            |                            |
        |<========= MS records Alice's audio RTP (name) =========>|
        |                            |                            |
        |                            |            Audio recording |
        |                            |<---------------------------|
        |                Complete +--|                            |
        |                creation |  |                            |
        |                of Alice +->|                            |

Top      Up      ToC       Page 40 
        |                            |                            |
        |                            |                            |
        | (2)userResponse(confUserID,|                            |
        |       confObjID,create,200,|                            |
        |           success,version) |                            |
        |<---------------------------|                            |
        |                            |                            |
        '                            '                            '

                  Figure 15: Recording and Announcements

   1.  Upon receipt of the userRequest message from Alice to be added to
       Bob's conference, the conference server determines that a
       password is required for this specific conference.  Thus, an
       announcement asking Alice to enter the password is sent back.
       This may be achieved by means of typical IVR functionality.  Once
       Alice enters the password, it is validated against the policies
       associated with Bob's active conference.  The conference server
       then connects to a server that prompts and records Alice's name.
       The conference server must also determine whether Alice is
       already a user of this conferencing system or whether she is a
       new user.  In this case, Alice is a new user for this
       conferencing system, so a new XCON-USERID is created for Alice.
       Based upon the contact information provided by Alice, the call
       signaling to add Alice to the conference is instigated through
       the focus.

   2.  The conference server sends Alice a userResponse message that
       includes in the <confUserID> the XCON-USERID assigned by the
       conferencing system to her.  This would allow Alice to later
       perform operations on the conference (if she were to have the
       appropriate policies), including registering for event
       notifications associated with the conference.  Once the call
       signaling indicates that Alice has been successfully added to the
       specific conference, per updates to the state, and depending upon
       the policies, other participants (e.g., Bob) are notified of the
       addition of Alice to the conference via the conference
       notification service and an announcement is provided to all the
       participants indicating that Alice has joined the conference.

  1. userRequest/create message  (a new conferencing system client,
     Alice, enters Bob's conference)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
       xmlns:info="urn:ietf:params:xml:ns:conference-info"
             xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
             xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">

Top      Up      ToC       Page 41 
      <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:type="ccmp:ccmp-user-request-message-type">
          <confObjID>xcon:bobConf@example.com</confObjID>
          <operation>create</operation>
          <ccmp:userRequest>
            <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
                  <info:associated-aors>
                      <info:entry>
                          <info:uri>
                             mailto:Alice83@example.com
                          </info:uri>
                          <info:display-text>email</info:display-text>
                      </info:entry>
                  </info:associated-aors>
                  <info:endpoint entity="sip:alice_789@example.com"/>
              </userInfo>
          </ccmp:userRequest>
      </ccmpRequest>
  </ccmp:ccmpRequest>

  2. userResponse/create message (Alice provided with a new XCON-USERID
     and added to the conference)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xsi:type="ccmp:ccmp-user-response-message-type">
          <confUserID>xcon-userid:Alice@example.com</confUserID>
          <confObjID>xcon:bobConf@example.com</confObjID>
          <operation>create</operation>
          <response-code>200</response-code>
          <response-string>success</response-string>
          <version>5</version>
          <ccmp:userResponse/>
      </ccmpResponse>
  </ccmp:ccmpResponse>

                 Figure 16: Announcement Messaging Details

6.4.  Monitoring for DTMF

   Conferencing systems also often need the capability to monitor for
   dual-tone multi-frequency (DTMF) from each individual participant.
   This would typically be used to enter the identifier and/or access
   code for joining a specific conference.  This feature is also often

Top      Up      ToC       Page 42 
   exploited to achieve interaction between participants and the
   conferencing system for non-XCON-aware user agents (e.g., using DTMF
   tones to get muted/unmuted).

   An example of DTMF monitoring, within the context of the framework
   elements, is shown in Figure 15.  The media control architecture and
   protocols [RFC5567] can be used by the conference server for all the
   DTMF interactions.  Examples for DTMF interception in conference
   instances are presented in [CALL-FLOWS].

6.5.  Entering a Password-Protected Conference

   Some conferences may require a password to be provided by a user who
   wants to manipulate the conference objects (e.g., join, update,
   delete) via CCMP.  In this case, a password would be included in the
   <conference-password> element in the appropriate <conference-uris>
   entry of the conference data model.  Such password must be then
   included in the <conference-password> field in the CCMP request
   addressed to that conference.

   In the following example, Alice, a conferencing system client,
   attempts to join a password-protected conference.

   1.  Alice sends a userRequest message with a "create" <operation> to
       add herself in the conference with XCON-URI
       "xcon:8977777@example.com" (written in the <confObjID>
       parameter).  Alice provides her XCON-USERID via the <confUserID>
       field of the userRequest message and leaves out the <userInfo>
       one (first-party join).  In this first attempt, she doesn't
       insert any password parameter.

   2.  Upon receipt the userRequest/create message, the conference
       server detects that the indicated conference is not joinable
       without providing the appropriate passcode.  A userResponse
       message with a "423" <response-code> ("conference password
       required") is returned to Alice to indicate that her join has
       been refused and that she has to resend her request including the
       appropriate conference password in order to participate.

   3.  After getting the passcode through out-of-band mechanisms, Alice
       provides it in the proper <conference-password> request field of
       a new userRequest/create message and sends the updated request
       back to the server.

   4.  The conference server checks the provided password and then adds
       Alice to the protected conference.  After that, a userResponse
       message with a "200" <response-code> ("success") is sent to
       Alice.

Top      Up      ToC       Page 43 
 1. userRequest/create message (Alice tries to enter the conference
    without providing the password)

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ccmp:ccmpRequest
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
            xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
            xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
     <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:type="ccmp:ccmp-user-request-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>create</operation>
         <ccmp:userRequest/>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. userResponse/create message ("423", "conference password required")

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ccmp:ccmpResponse
     xmlns:info="urn:ietf:params:xml:ns:conference-info"
     xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
     xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-user-response-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>create</operation>
         <response-code>423</response-code>
         <response-string>conference password required</response-string>
         <ccmp:userResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

 3. userRequest/create message (Alice provides the password)

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ccmp:ccmpRequest
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
            xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
            xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
     <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:type="ccmp:ccmp-user-request-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>create</operation>
         <conference-password>8601</conference-password>

Top      Up      ToC       Page 44 
         <ccmp:userRequest/>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 4. userResponse/create message
    (Alice has been added to the conference)

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ccmp:ccmpResponse
     xmlns:info="urn:ietf:params:xml:ns:conference-info"
     xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
     xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-user-response-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>create</operation>
         <response-code>200</response-code>
         <response-string>success</response-string>
         <version>10</version>
         <ccmp:userResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

      Figure 17: Password-Protected Conference Join Messages Details

7.  Sidebars Scenarios and Examples

   While creating conferences and manipulating users and their media are
   sufficient for many scenarios, there may be cases when more complex
   management is needed.

   In fact, a feature typically required in conferencing systems is the
   ability to create sidebars.  A sidebar is basically a child
   conference that usually includes a subset of the participants of the
   parent conference and a subset of its media as well.  Sidebars are
   typically required whenever some of the participants in a conference
   want a private discussion, without interfering with the main
   conference.

   This section deals with some typical scenarios using a sidebar, like
   whispering, private messaging, and coaching scenarios.  The first
   subsections present some examples of how a generic sidebar can be
   created, configured, and managed.

Top      Up      ToC       Page 45 
7.1.  Internal Sidebar

   Figure 18 provides an example of one client, Alice, involved in an
   active conference with Bob and Carol.  Alice wants to create a
   sidebar to have a side discussion with Bob while still viewing the
   video associated with the main conference.  Alternatively, the audio
   from the main conference could be maintained at a reduced volume.
   Alice initiates the sidebar by sending a request to the ConfS to
   create a conference reservation based upon the active conference
   object.  Alice and Bob would remain on the roster of the main
   conference, such that other participants could be aware of their
   participation in the main conference, while an internal-sidebar
   conference is occurring.  Besides, Bob decides that he is not
   interested in still receiving the conference audio in background (not
   even at a lower volume as Alice configured) and so modifies the
   sidebar in order to make that stream inactive for him.

  Alice                   Bob                    ConfS
    |                      |                       |
    |(1) sidebarByValRequest(confUserID,           |
    |                  confObjID,create)           |
    |--------------------------------------------->|
    |                      |                       |
    |                      |        (a) Create +---|
    |                      |    sidebar-by-val |   |
    |                      |     (new conf obj |   |
    |                      |       cloned from +-->|
    |                      |        confObjID)     | Sidebar now has
    |                      |                       | id confObjID*
    |(2) sidebarByValResponse(confUserID,          | (parent mapping
    |     (confObjID*,create,200,success,          | conf<->sidebar)
    |         version,sidebarByValInfo)            |
    |<---------------------------------------------|
    |                      |                       |
    |(3) sidebarByValRequest                       |
    |       (confUserID, confObjID*,               |
    |       update,sidebarByValInfo)               |
    |--------------------------------------------->|
    |                      |                       |

Top      Up      ToC       Page 46 
    |                      |        (b) Update +---|
    |                      |    sidebar-by-val |   |
    |                      |     (media, users |   |
    |                      |       etc.)       +-->|
    |                      |                       | Sidebar is
    |                      |                       | modified
    |(4) sidebarByValResponse(confUserID,          |
    |                 confObjID*, update,          |
    |              200, success, version)          |
    |<---------------------------------------------|
    |                      |                       |
    |                      |(5) userRequest        |
    |                      |      (confUserID',    |
    |                      |       confObjID*,     |
    |                      |       update,userInfo)|
    |                      |---------------------->|
    |                      |                       |
    |                      |        (c) Update +---|
    |                      |     user settings |   |
    |                      |     (Bob's media) |   |
    |                      |                   +-->|
    |                      |                       | Sidebar is modified
    |                      |                       | (original audio
    |                      |                       | inactive for Bob)
    |                      |(6) userResponse       |
    |                      |     (confUserID',     |
    |                      |      confObjID*,      |
    |                      |      update, 200,     |
    |                      |      success,version) |
    |                      |<----------------------|
    |                      |                       |
    '                      '                       '
    '                      '                       '
    '                      '                       '

            Figure 18: Client Creation of a Sidebar Conference

   1.  Upon receipt of CCMP sidebarByValRequest message to create a new
       sidebar based upon the conference whose XCON-URI is in the
       <confObjID> received in the request, the conference server uses
       such XCON-URI to clone a conference reservation for the sidebar.
       The sidebar reservation is NOT independent of the active main
       conference (i.e., parent).  The conference server also allocates
       a new XCON-URI ("confObjID*" in Figure 18) for that sidebar to be
       used for any subsequent protocol requests from any of the members
       of the conference.  The new XCON-URI is returned in the response
       message <confObjID> parameter.

Top      Up      ToC       Page 47 
   2.  The relationship information is provided in the
       sidebarByValResponse message, specifically in the <sidebar-
       parent> element.  A dump of the complete representation of the
       main/parent conference is provided below as well to show how the
       cloning process for the creation of the sidebar could take place.

   3.  Upon receipt of the sidebarByValResponse message to reserve the
       conference, Alice can now create an active conference using that
       reservation or create additional reservations based upon the
       existing reservations.  In this example, Alice wants only Bob to
       be involved in the sidebar; thus, she manipulates the membership
       so that only the two of them appear in the <allowed-users-list>
       section.  Alice also wants both audio and video from the original
       conference to be available in the sidebar.  For what concerns the
       media belonging to the sidebar itself, Alice wants the audio to
       be restricted to the participants in the sidebar (that is, Bob
       and herself).  Additionally, Alice manipulates the media values
       to receive the audio from the main conference at a reduced
       volume, so that the communication between her and Bob isn't
       affected.  Alice sends a sidebarByValRequest message with an
       operation of "update" along with the <sidebarByValInfo>
       containing the aforementioned sidebar modifications.

   4.  Upon receipt of the sidebarByValRequest message to update the
       sidebar reservation, the conference server ensures that Alice has
       the appropriate authority based on the policies associated with
       that specific conference object to perform the operation.  The
       conference server must also validate the updated information in
       the reservation, ensuring that a member like Bob is already a
       user of this conference server.  Once the data for the conference
       identified by the <confObjID> is updated, the conference server
       sends a sidebarByValResponse message to Alice.  Depending upon
       the policies, the initiator of the request (i.e., Alice) and the
       participants in the sidebar (i.e., Bob) may be notified of his
       addition to the sidebar via the conference notification service.

   5.  At this point, Bob sends a userRequest message to the conference
       server with an operation of "update" to completely disable the
       background audio from the parent conference, since it prevents
       him from understanding what Alice says in the sidebar.

   6.  Notice that Bob's request only changes the media perspective for
       Bob.  Alice keeps on receiving both the audio from Bob and the
       background from the parent conference.  This request may be
       relayed by the conference server to the media server handling the
       mixing, if present.  Upon completion of the change, the

Top      Up      ToC       Page 48 
       conference server sends a userResponse message to Bob.  Depending
       upon the policies, the initiator of the request (i.e., Bob) and
       the participants in the sidebar (i.e., Alice) may be notified of
       this change via the conference notification service.

   The following conference object represents the conference in which
   the sidebar is to be created.  It will be used by the conference
   server to create the new conference object associated with the
   sidebar.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <info:conference-info
                xmlns:info="urn:ietf:params:xml:ns:conference-info"
                xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
                xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
                entity="xcon:8977878@example.com">
     <info:conference-description>
        <info:display-text>MAIN CONFERENCE</info:display-text>
        <info:conf-uris>
            <info:entry>
               <info:uri>sip:8977878@example.com</info:uri>
               <info:display-text>conference sip uri</info:display-text>
            </info:entry>
        </info:conf-uris>
        <info:available-media>
          <info:entry label="123">
            <info:display-text>main conference audio</info:display-text>
            <info:type>audio</info:type>
            <info:status>sendrecv</info:status>
          </info:entry>
          <info:entry label="456">
            <info:display-text>main conference video</info:display-text>
            <info:type>video</info:type>
            <info:status>sendrecv</info:status>
            <xcon:controls>
                    <xcon:video-layout>single-view</xcon:video-layout>
           </xcon:controls>
          </info:entry>
        </info:available-media>
    </info:conference-description>
    <info:conference-state>
        <info:active>true</info:active>
    </info:conference-state>
    <info:users>
        <info:user entity="xcon-userid:Alice@example.com">
            <info:display-text>Alice</info:display-text>
            <info:endpoint entity="sip:Alice@example.com">
                <info:media id="1">

Top      Up      ToC       Page 49 
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:Bob@example.com">
            <info:display-text>Bob</info:display-text>
            <info:endpoint entity="sip:bob83@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
        <info:user entity="xcon-userid:Carol@example.com">
            <info:display-text>Carol</info:display-text>
            <info:endpoint entity="sip:carol@example.com">
                <info:media id="1">
                    <info:label>123</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
                <info:media id="2">
                    <info:label>456</info:label>
                    <info:status>sendrecv</info:status>
                </info:media>
            </info:endpoint>
        </info:user>
    </info:users>
  </info:conference-info>

             Figure 19: Conference with Alice, Bob, and Carol

   The sidebar creation happens through a cloning of the parent
   conference.  Once the sidebar is created, an update request makes
   sure that the sidebar is customized as needed.  The following
   protocol dump makes the process clearer.

Top      Up      ToC       Page 50 
1. sidebarByValRequest/create message (Alice creates an
   internal sidebar)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
               xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
               xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByValRequest/>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. sidebarByValResponse/create message (sidebar returned)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse
              xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
              xmlns:info="urn:ietf:params:xml:ns:conference-info"
              xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>create</operation>
        <response-code>200</response-code>
        <response-string>success</response-string>
            <version>1</version>
        <ccmp:sidebarByValResponse>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                    <info:display-text>
                         SIDEBAR CONFERENCE registered by Alice
                    </info:display-text>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                  main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                  main conference video

Top      Up      ToC       Page 51 
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Carol@example.com"/>
                    </xcon:allowed-users-list>
                    <xcon:sidebar-parent>
                         xcon:8977878@example.com
                    </xcon:sidebar-parent>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

3. sidebarByValRequest/update message (Alice updates the
   created sidebar)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
            xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
            xmlns:info="urn:ietf:params:xml:ns:conference-info"
            xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByVal-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByValRequest>
            <sidebarByValInfo entity="xcon:8974545@example.com">
                <info:conference-description>
                  <info:display-text>
                        private sidebar Alice - Bob
                  </info:display-text>
                  <info:available-media>
                        <info:entry label="123">

Top      Up      ToC       Page 52 
                            <info:display-text>
                                main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>recvonly</info:status>
                            <xcon:controls>
                                <xcon:gain>-60</xcon:gain>
                            </xcon:controls>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>recvonly</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_1">
                            <info:display-text>
                                sidebar audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_2">
                            <info:display-text>
                                sidebar video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

Top      Up      ToC       Page 53 
4. sidebarByValResponse/update message (sidebar's
   updates accepted)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse
                xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
                xmlns:info="urn:ietf:params:xml:ns:conference-info"
                xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="ccmp:ccmp-sidebarByVal-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <response-code>200</response-code>
        <response-string>success</response-string>
            <version>2</version>
        <ccmp:sidebarByValResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

5. userRequest/update message (Bob updates his media)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
           xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
           xmlns:info="urn:ietf:params:xml:ns:conference-info"
           xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
      <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:Bob@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:Bob@example.com">
                <info:endpoint entity="sip:bob83@example.com">
                    <info:media id="1">
                        <info:display-text>
                            main conference audio
                        </info:display-text>
                        <info:label>123</info:label>
                        <info:status>inactive</info:status>
                    </info:media>
                </info:endpoint>
            </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

Top      Up      ToC       Page 54 
6. userResponse/update message (Bob's preferences are set)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
               xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
               xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:Bob@example.com</confUserID>
        <confObjID>xcon:8974545@example.com</confObjID>
        <operation>update</operation>
        <response-code>200</response-code>
        <response-string>success</response-string>
        <version>3</version>
        <ccmp:userResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

               Figure 20: Internal Sidebar Messaging Details

7.2.  External Sidebar

   Figure 21 provides an example of a different approach towards
   sidebars.  In this scenario, one client, Alice, is involved in an
   active conference with Bob, Carol, David, and Ethel.  Alice gets an
   important text message via a whisper from Bob that a critical
   customer needs to talk to Alice, Bob, and Ethel.  Alice creates a
   sidebar to have a side discussion with the customer Fred including
   the participants in the current conference with the exception of
   Carol and David, who remain in the active conference.  The difference
   from the previous scenario is that Fred is not part of the parent
   conference: this means that different policies might be involved,
   considering that Fred may access information coming from the parent
   conference, in case the sidebar was configured accordingly.  For this
   reason, in this scenario, we assume that Alice disables all the media
   from the original (parent) conference within the sidebar.  This means
   that, while in the previous example Alice and Bob still heard the
   audio from the main conference in background, this time no background
   is made available.  Alice initiates the sidebar by sending a request
   to the conference server to create a conference reservation based
   upon the active conference object.  Alice, Bob and Ethel would remain
   on the roster of the main conference in a hold state.  Whether or not
   the hold state of these participants is visible to other participants
   depends upon the individual and local policy.  However, providing the
   hold state allows the participants in the main conference to see that
   others in the conference are busy.  Note, that a separate conference
   could have been created by Alice to allow Bob and Ethel to talk to
   Fred.  However, creating a sidebar has somewhat of an advantage by

Top      Up      ToC       Page 55 
   allowing the conference to be created using some of the same settings
   (e.g., role, floor control, etc.) that Bob and Ethel had in the main
   conference and it would allow for updates such that the media could
   be updated, for example, to provide audio from the main conference.

 Alice                   Bob                   ConfS
   |                      |                       |
   |(1) sidebarByRefRequest(confUserID,           |
   |                 confObjID, create)           |
   |--------------------------------------------->|
   |                      |                       |
   |                      |        (a) Create +---|
   |                      |    sidebar-by-ref |   |
   |                      |     (new conf obj |   |
   |                      |       cloned from +-->|
   |                      |        confObjID)     | Sidebar now has
   |                      |                       | id confObjID*
   |(2) sidebarByRefResponse(confUserID,          | (parent mapping
   |      confObjID*,create,200,success,          | conf<->sidebar)
   |           version,sidebarByRefInfo)          |
   |<---------------------------------------------|
   |                      |                       |
   |(3) sidebarByRefRequest(confUserID,           |
   |      confObjID*,update,sidebarByRefInfo)     |
   |--------------------------------------------->|
   |                      |                       |
   |                      |        (b) Create +---|
   |                      |      new user for |   |
   |                      |            Fred   |   |
   |                      |                   +-->|
   |                      |                       |
   |                      |        (c) Update +---|
   |                      |    sidebar-by-ref |   |
   |                      |     (media, users |   |
   |                      |     policy, etc.) +-->|
   |                      |                       | Sidebar is modified:
   |                      |                       | media from the
   |                      |                       | parent conference is
   |                      |                       | not available to
   |(4) sidebarByRefResponse(confUserID,          | anyone
   |                 confObjID*, update,          |
   |             200, success, version)           |
   |<---------------------------------------------|
   |                      |                       |

Top      Up      ToC       Page 56 
   |                      |        Notify (Fred   |
   |                      |              added to |
   |                      |        sidebar users) |
   |                      |<----------------------|
   |                      |                       |
   '                      '                       '
   '                      '                       '
   '                      '                       '

             Figure 21: Client Creation of an External Sidebar

   1.  Upon receipt of the sidebarByRefRequest message to create a new
       sidebar conference, based upon the active conference specified by
       <confObjID> in the request, the conference server uses that
       active conference to clone a conference reservation for the
       sidebar.  The sidebar reservation is NOT independent of the
       active conference (i.e., parent).  The conference server, as
       before, allocates a new XCON-URI ("confObjID*" in Figure 21) to
       be used for any subsequent protocol requests toward the sidebar
       reservation.  The mapping between the sidebar XCON-URI and the
       one associated with the main conference is maintained by the
       conference server and it is gathered from the <sidebar-parent>
       element in the sidebar conference object.

   2.  Upon receipt of the sidebarByRefResponse message, which
       acknowledges the successful creation of the sidebar object, Alice
       decides that only Bob and Ethel, along with the new participant
       Fred are to be involved in the sidebar.  Thus, she manipulates
       the membership accordingly.  Alice also sets the media in the
       <conference-info> such that the participants in the sidebar don't
       receive any media from the main conference.  All these settings
       are provided to the conferencing server by means of a new
       sidebarByRefRequest message, with an "update" <operation>.

   3.  Alice sends the aforementioned sidebarByRefRequest message to
       update the information in the reservation and to create an active
       conference.  Upon receipt of the sidebarByRefRequest/update
       message, the conference server ensures that Alice has the
       appropriate authority based on the policies associated with that
       specific conference object to perform the operation.  The
       conference server also validates the updated information in the
       reservation.  Since Fred is a new user for this conferencing
       system, a conference user identifier (XCON-USERID) is created for
       Fred.  Specifically, Fred is added to the conference by only
       providing his SIP URI.  Based upon the contact information
       provided for Fred by Alice, the call signaling to add Fred to the
       conference may be instigated through the focus (e.g., if Fred had

Top      Up      ToC       Page 57 
       a "dial-out" value for the 'method' attribute in his <target>
       field under <allowed-users-list>) at the actual activation of the
       sidebar.

   4.  The conference server sends a sidebarByRefResponse message and,
       depending upon the policies, the initiator of the request (i.e.,
       Alice) and the participants in the sidebar (i.e., Bob and Ethel)
       may be notified of his addition to the sidebar via the conference
       notification service.

1. sidebarByRefRequest/create message (Alice creates an
   external sidebar)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
               xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
               xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByRefRequest/>
    </ccmpRequest>
  </ccmp:ccmpRequest>

2. sidebarByRefResponse/create message (created
   sidebar returned)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse
                xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
                xmlns:info="urn:ietf:params:xml:ns:conference-info"
                xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
            <operation>create</operation>
        <response-code>200</response-code>
        <response-string>success</response-string>
        <version>1</version>
        <ccmp:sidebarByRefResponse>
            <sidebarByRefInfo entity="xcon:8971212@example.com">
                <info:conference-description>
                    <info:display-text>
                        SIDEBAR CONFERENCE registered by Alice
                    </info:display-text>

Top      Up      ToC       Page 58 
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Carol@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:David@example.com"/>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:Ethel@example.com"/>
                    </xcon:allowed-users-list>
                    <xcon:sidebar-parent>
                        xcon:8977878@example.com
                    </xcon:sidebar-parent>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

3. sidebarByRefRequest/update message (Alice updates the sidebar)

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
                xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
                xmlns:info="urn:ietf:params:xml:ns:conference-info"

Top      Up      ToC       Page 59 
                xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByRefRequest>
            <sidebarByRefInfo entity="xcon:8971212@example.com">
                <info:conference-description>
                    <info:display-text>
                        sidebar with Alice, Bob, Ethel and Fred
                    </info:display-text>
                    <info:available-media>
                        <info:entry label="123">
                            <info:display-text>
                                 main conference audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>inactive</info:status>
                        </info:entry>
                        <info:entry label="456">
                            <info:display-text>
                                 main conference video
                        </info:display-text>
                            <info:type>video</info:type>
                            <info:status>inactive</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_1">
                            <info:display-text>
                                 sidebar audio
                            </info:display-text>
                            <info:type>audio</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                        <info:entry label="AUTO_GENERATE_2">
                            <info:display-text>
                                 sidebar video
                            </info:display-text>
                            <info:type>video</info:type>
                            <info:status>sendrecv</info:status>
                            <xcon:controls>
                                 <xcon:video-layout>
                                       single-view
                                 </xcon:video-layout>
                            </xcon:controls>
                        </info:entry>
                    </info:available-media>
                </info:conference-description>

Top      Up      ToC       Page 60 
                <info:conference-state>
                    <info:active>false</info:active>
                </info:conference-state>
                <info:users>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:Bob@example.com"/>
                        <xcon:target method="dial-out"
                              uri="sip:fred@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

4. sidebarByRefResponse/update message (sidebar updated)

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <ccmp:ccmpResponse
                xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
                xmlns:info="urn:ietf:params:xml:ns:conference-info"
                xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="ccmp:ccmp-sidebarByRef-response-message-type">
        <confUserID>xcon-userid:Alice@example.com</confUserID>
        <confObjID>xcon:8971212@example.com</confObjID>
        <operation>update</operation>
        <response-code>200</response-code>
        <response-string>success</response-string>
        <version>2</version>
        <ccmp:sidebarByRefResponse/>
    </ccmpResponse>
  </ccmp:ccmpResponse>

               Figure 22: External Sidebar Messaging Details



(page 60 continued on part 4)

Next RFC Part