tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6504

 
 
 

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Part 4 of 4, p. 60 to 78
Prev RFC Part

 


prevText      Top      Up      ToC       Page 60 
7.3.  Private Messages

   The case of private messages can be handled as a sidebar with just
   two participants, similar to the example in Section 7.1.  Unlike the
   previous example, rather than using audio within the sidebar, Alice
   could just add an additional text-based media stream to the sidebar
   in order to convey her textual messages to Bob, while still viewing
   and listening to the main conference.

Top      Up      ToC       Page 61 
   In this scenario, Alice requests to the conference server the
   creation of a private chat room within the main conference context
   (presented in Figure 19) in which the involved participants are just
   Bob and herself.  This can be achieved through the following CCMP
   transaction (Figure 23).

   1.  Alice forwards a sidebarByValRequest/create message to the
       conference server with the main conference XCON-URI in the
       <confObjID> parameter and the desired sidebar conference object
       in the <sidebarByValInfo> field.  In this way, a sidebar creation
       using user-provided conference information is requested from the
       conference server.  Please note that, unlike the previous sidebar
       examples, in this case, a completely new conference object to
       describe the sidebar is provided: there is no cloning involved,
       while the <confObjID> still enforces the parent-child
       relationship between the main conference and the to-be-created
       sidebar.

   2.  The conference server, after checking Alice's rights and
       validating the conference object carried in the request, creates
       the required sidebar-by-val conference and a new XCON-URI for it.
       Instead of cloning the main conference object, as shown in
       Sections 7.1 and 7.2, the sidebar is created on the basis of the
       user-provided conference information.  However, the parent
       relationship between the main conference and the newly created
       sidebar is still maintained by the conference server (as a
       consequence of the chosen CCMP request message type -- the
       sidebarByVal one) and it is reflected by the <sidebar-parent>
       element in the <sidebarByValInfo> element returned in the
       sidebarByValResponse message.  Please notice that, according to
       the CCMP specification, the return of the created sidebar data in
       this kind of "success" response is not mandatory.

1. sidebarByValRequest/create message (Alice creates a private
   chat room between Bob and herself)

<?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:8977878@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByValRequest>
            <sidebarByValInfo entity="xcon:AUTO_GENERATE_1@example.com">

Top      Up      ToC       Page 62 
                <info:conference-description>
                  <info:display-text>
                        private textual sidebar alice - bob
                  </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>recvonly</info:status>
                        </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_2">
                            <info:display-text>
                                sidebar text
                            </info:display-text>
                            <info:type>text</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>

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

Top      Up      ToC       Page 63 
    <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>
                        private textual sidebar alice - bob
                    </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>recvonly</info:status>
                        </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="789">
                            <info:display-text>
                                sidebar text
                            </info:display-text>
                            <info:type>text</info:type>
                            <info:status>sendrecv</info:status>
                        </info:entry>
                    </info:available-media>
                    <xcon:sidebar-parent>
                         xcon:8977878@example.com
                    </xcon:sidebar-parent>
                </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>

Top      Up      ToC       Page 64 
                </info:users>
            </sidebarByValInfo>
        </ccmp:sidebarByValResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

             Figure 23: Sidebar for Private Messages Scenario

7.4.  Observing and Coaching

   "Observing and Coaching" is one of the most interesting sidebar-
   related scenarios.  In fact, it highlights two different interactions
   that have to be properly coordinated.

   An example of observing and coaching is shown in Figure 25.  In this
   example, call center agent Bob is involved in a conference with
   customer Carol.  Since Bob is a new agent and Alice sees that he has
   been on the call with Carol for longer than normal, she decides to
   observe the call and coach Bob as necessary.  Of course, the
   conferencing system must make sure that the customer Carol is not
   aware of the presence of the coach Alice.  This makes the use of a
   sidebar necessary for the success of the scenario.

   Consider the following as the conference document associated with the
   video conference involving Bob (the call agent) and Carol (the
   customer) (Figure 24):

<?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:8978383@example.com">
     <info:conference-description>
        <info:display-text>
                CUSTOMER SERVICE conference
        </info:display-text>
        <info:conf-uris>
            <info:entry>
               <info:uri>sip:8978383@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>service audio</info:display-text>
            <info:type>audio</info:type>
            <info:status>sendrecv</info:status>

Top      Up      ToC       Page 65 
          </info:entry>
          <info:entry label="456">
            <info:display-text>service 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:bob@example.com">
            <info:display-text>Bob - call agent</info:display-text>
            <info:endpoint entity="sip:bob@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 - customer</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 24: A Call-Center Conference Object Example

Top      Up      ToC       Page 66 
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) Update +---|
  |                      |    sidebar-by-val |   |
  |                      |     (media, users |   |
  |                      |     policy, etc.) +-->|
  |                      |                       | Sidebar is modified:
  |                      |                       | unilateral sidebar
  |                      |                       | audio, Carol excluded
  |                      |                       | from the sidebar
  |(4) sidebarByRefResponse(confUserID,          |
  |                 confObjID*, update,          |
  |               200, success, version)         |
  |<---------------------------------------------|
  |                      |                       |
  |                      |         Notify (Bob   |
  |                      |    he's been added to |
  |                      |        sidebar users) |
  |                      |<----------------------|
  |                      |                       |
  '                      '                       '
  '                      '                       '
  '                      '                       '

      Figure 25: Supervisor Creating a Sidebar for Observing/Coaching

Top      Up      ToC       Page 67 
   1.  Upon receipt of the sidbarByRefRequest/create message from Alice
       to create a new sidebar conference from the <confObjID> received
       in the request, the conference server uses the received active
       conference to clone a conference reservation for the sidebar.
       The conference server also allocates a new XCON-URI to be used
       for any subsequent protocol requests directed to the new sidebar.
       The conference server maintains the mapping between this sidebar
       conference ID and the one associated with the main conference
       instance.  The conference server sends a sidebarByRefResponse
       message with the new XCON-URI in the <confObjID> field and other
       relevant information in the <sidebarByRefInfo>.

   2.  Upon receipt of the sidebarByRefResponse message, Alice
       manipulates the data received in the <sidebarByRefInfo> in the
       response.  Alice wants only Bob to be involved in the sidebar;
       thus, she updates the <allowed-users-list> to include only Bob
       and herself.  Alice also wants the audio to be received by
       herself and Bob from the original conference, but wants any
       outgoing audio from herself to be restricted to the participants
       in the sidebar, whereas Bob's outgoing audio should go to the
       main conference, so that both Alice and the customer Carol hear
       the same audio from Bob.  Alice sends a sidebarByRefRequest
       message with an "update" <operation> including the updated
       sidebar information in the <sidebarByRefInfo> element.

   3.  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.  In order to request
       the insertion of a further media stream in the sidebar (i.e., in
       this example an audio stream from Alice to Bob), the requester
       has to provide a new <entry> element in the <available-media>
       field of the <sidebarByRefInfo>.  The mandatory 'label' attribute
       of that new <entry> is filled with a dummy value
       "AUTO_GENERATE_1", but it will contain the real server-generated
       media stream identifier when the media stream is effectively
       allocated on the server side.  Similarly, the mandatory 'id'
       attribute in the <media> element referring to the new sidebar
       audio stream under both Alice's and Bob's <endpoint> contains a
       wildcard value, respectively, "AUTO_GENERATE_2" and
       "AUTO_GENERATE_3": those values will be replaced with the
       appropriated server-generated identifiers upon the creation of
       the referred media stream.  We are assuming the conference server
       is able to recognize those dummy values as placeholders.

   4.  After validating the data, the conference server sends a
       sidebarByRefResponse message.  Based upon the contact information
       provided for Bob by Alice, the call signaling to add Bob to the

Top      Up      ToC       Page 68 
       sidebar with the appropriate media characteristics is instigated
       through the focus.  Bob is notified of his addition to the
       sidebar via the conference notification service; thus, he is
       aware that Alice, the supervisor, is available for coaching him
       through this call.

1. sidebarByRefRequest/create message (Alice as coach creates a 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:8978383@example.com</confObjID>
        <operation>create</operation>
        <ccmp:sidebarByRefRequest/>
    </ccmpRequest>
</ccmp:ccmpRequest>

2. sidebarByRefResponse/create message (sidebar created)

<?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:8971313@example.com</confObjID>
        <operation>create</operation>
        <response-code>200</response-code>
        <response-string>Success</response-string>
        <version>1</version>
        <ccmp:sidebarByRefResponse>
            <sidebarByRefInfo entity="xcon:8971313@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>

Top      Up      ToC       Page 69 
                            <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>
                    <xcon:sidebar-parent>
                        xcon:8971313@example.com
                    </xcon:sidebar-parent>
                </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>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

  3. sidebarByRefRequest/update message (Alice introduces unilateral
     sidebar audio and excludes Carol from the sidebar)

  <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-sidebarByRef-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8971313@example.com</confObjID>
        <operation>update</operation>
        <ccmp:sidebarByRefRequest>
            <sidebarByRefInfo entity="xcon:8971313@example.com">

Top      Up      ToC       Page 70 
                <info:conference-description>
                    <info:display-text>
                        Coaching sidebar Alice and Bob
                    </info:display-text>
                    <info:available-media>
                        <info:entry label="AUTO_GENERATE_1">
                            <info:display-text>
                                 Alice-to-Bob audio
                            </info:display-text>
                            <info:type>audio</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>
                    <info:user entity="xcon-userid:alice@example.com">
                      <info:endpoint entity="sip:alice@example.com">
                        <info:media id="AUTO_GENERATE_2">
                         <info:label>AUTO_GENERATE_1</info:label>
                         <info:status>sendonly</info:status>
                        </info:media>
                      </info:endpoint>
                    </info:user>
                    <info:user entity="xcon-userid:bob@example.com">
                      <info:endpoint entity="sip:bob@example.com">
                        <info:media id="AUTO_GENERATE_3">
                         <info:label>AUTO_GENERATE_1</info:label>
                         <info:status>recvonly</info:status>
                        </info:media>
                      </info:endpoint>
                    </info:user>
                    <xcon:allowed-users-list>
                        <xcon:target method="dial-in"
                              uri="xcon-userid:alice@example.com"/>
                        <xcon:target method="dial-out"
                              uri="xcon-userid:bob@example.com"/>
                    </xcon:allowed-users-list>
                </info:users>
            </sidebarByRefInfo>
        </ccmp:sidebarByRefRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

Top      Up      ToC       Page 71 
4. sidebarByRefRequest/update message (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-sidebarByRef-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8971313@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 26: Coaching and Observing Messaging Details

8.  Removing Participants and Deleting Conferences

   The following scenarios detail the basic operations associated with
   removing participants from conferences and entirely deleting
   conferences.  The examples assume that a conference has already been
   correctly established, with media, if applicable, per one of the
   examples in Section 5.

8.1.  Removing a Party

   Figure 27 provides an example of a client, Alice, removing another
   participant, Bob, from a conference.  This example assumes an
   established conference with Alice, Bob, Claire, and Duck.  In this
   example, Alice wants to remove Bob from the conference so that the
   group can continue in the same conference without Bob's
   participation.

Top      Up      ToC       Page 72 
   Alice            Bob       Claire       ConfS
     |               |           |           |
     |(1) userRequest(confUserID,|           |
     |         confObjID, delete,|           |
     |         userInfo)         |           |
     |-------------------------------------->|
     |               |           |           |
     |               |           | (a) Focus |
     |               |           | tears down|
     |               |           | signaling |
     |               |           |  to Bob   |
     |               |<----------------------|
     |               |                       |
     |               |         (b)Deletes+---|
     |               |           | Bob   |   |
     |               |           | as a  |   |
     |               |           | user  +-->|
     |               |           | in        |
     |               |           | confObj   |
     |               |           |           |
     |(2) userResponse(confUserID,confObjID, |
     |           delete,200,success,version) |
     |<--------------------------------------|
     |               |           |           |
     |               |           |           |
     |               |           | (c) Notify|
     |               |           | ("Bob just|
     |               |           |  left")   |
     |               |           |<----------|
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

       Figure 27: Client Manipulation of Conference - Remove a Party

   1.  Alice sends a userRequest message with a "delete" <operation>.
       The conference server ensures that Alice has the appropriate
       authority based on the policies associated with that specific
       conference object to perform the operation.

   2.  Based upon the contact and media information in the conference
       object for Bob in the <userInfo> element, the conferencing system
       starts the process to remove Bob (e.g., the call signaling to
       remove Bob from the conference is instigated through the focus).
       The conference server updates the data in the conference object,
       thus, removing Bob from the <users> list.  After updating the
       data, the conference server sends a userResponse message to

Top      Up      ToC       Page 73 
       Alice.  Depending upon the policies, other participants (e.g.,
       Claire) may be notified of the removal of Bob from the conference
       via the conference notification service.

 1. userRequest/delete message (Alice deletes 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:8977794@example.com</confObjID>
         <operation>delete</operation>
         <ccmp:userRequest>
             <userInfo entity="xcon-userid:Bob@example.com"/>
         </ccmp:userRequest>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. userResponse/delete message (Bob has been deleted)

 <?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>delete</operation>
         <response-code>200</response-code>
         <response-string>success</response-string>
         <version>17</version>
         <ccmp:userResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

            Figure 28: Removing a Participant Messaging Details

Top      Up      ToC       Page 74 
8.2.  Deleting a Conference

   In this section, an example of a successful conference deletion is
   provided (Figure 29).

   Alice                          ConfS
    |                               |
    |(1)confRequest(confUserID,     |
    |       confObjID, delete)      |
    |------------------------------>|
    |                 (a)Delete +---|
    |                    Conf   |   |
    |                    Object |   |
    |                           +-->|
    |                               |--+ (b) MS
    |                               |  | removes related
    |                               |  | mixer instances and
    |                               |<-+ their participants
    |                               |    (SIP signaling as well)
    |                               |
    |(2)confResponse(confUserID,    |
    |      confObjID,delete,200,    |
    |      success)                 |
    |                               |
    |<------------------------------|
    |                               |
    '                               '

                     Figure 29: Deleting a Conference

   1.  The conferencing system client Alice sends a confRequest message
       with a "delete" operation to be performed on the conference
       identified by the XCON-URI carried in the <confObjID> parameter.
       The conference server, on the basis of the <confUserID> included
       in the receipt request, ensures that Alice has the appropriate
       authority to fulfill the operation.

   2.  After validating Alice's rights, the conference server instigates
       the process to delete the conference object, disconnecting
       participants and removing associated resources such as mixer
       instances.  Then, the conference server returns a confResponse
       message to Alice with "200" as <response-code> and the deleted
       conference XCON-URI in the <confObjID> field.

Top      Up      ToC       Page 75 
 1. confRequest/delete message (Alice deletes a 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">
     <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:type="ccmp:ccmp-conf-request-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
         <ccmp:confRequest/>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. confResponse/delete message ("200", "success")

 <?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-conf-response-message-type">
         <confUserID>xcon-userid:Alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>delete</operation>
         <response-code>200</response-code>
         <response-string>success</response-string>
         <ccmp:confResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

            Figure 30: Deleting a Conference Messaging Details

9.  Security Considerations

   The security considerations applicable to the implementation of these
   call flows are documented in the XCON framework, with additional
   security considerations documented in the CCMP document.  Statements
   with regard to the necessary security are discussed in particular
   flows; however, this is for informational purposes only.  The
   implementer is encouraged to carefully consider the security
   requirements in the normative documents.

Top      Up      ToC       Page 76 
10.  Acknowledgements

   The detailed content for this document is derived from the prototype
   work of Lorenzo Miniero, Simon Pietro Romano, Tobia Castaldi, and
   their colleagues at the University of Napoli.

11.  References

11.1.  Normative References

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", RFC 5239, June 2008.

   [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
              "Conference Information Data Model for Centralized
              Conferencing (XCON)", RFC 6501, March 2012.

   [RFC6502]  Camarillo, G., Srinivasan, S., Even, R., and J.
              Urpalainen, "Conference Event Package Data Format
              Extension for Centralized Conferencing (XCON)", RFC 6502,
              March 2012.

   [RFC6503]  Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
              "Centralized Conferencing Manipulation Protocol",
              RFC 6503, March 2012.

   [W3C.REC-xml-20081126]
              Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20081126, November 2008,
              <http://www.w3.org/TR/2008/REC-xml-20081126>.

11.2.  Informative References

   [CALL-FLOWS]
              Amirante, A., Castaldi, T., Miniero, L., and S. Romano,
              "Media Control Channel Framework (CFW) Call Flow
              Examples", Work in Progress, July 2011.

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

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

Top      Up      ToC       Page 77 
   [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
              (SIP) Call Control - Conferencing for User Agents",
              BCP 119, RFC 4579, August 2006.

   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", RFC 4582, November 2006.

   [RFC4597]  Even, R. and N. Ismail, "Conferencing Scenarios",
              RFC 4597, August 2006.

   [RFC5567]  Melanchuk, T., "An Architectural Framework for Media
              Server Control", RFC 5567, June 2009.

   [RFC6505]  McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
              Control Package for the Media Control Channel Framework",
              RFC 6505, March 2012.

Top      Up      ToC       Page 78 
Authors' Addresses

   Mary Barnes
   Polycom
   TX
   USA

   EMail: mary.ietf.barnes@gmail.com


   Lorenzo Miniero
   Meetecho
   Via Carlo Poerio 89/a
   Napoli  80121
   Italy

   EMail: lorenzo@meetecho.com


   Roberta Presta
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   EMail: roberta.presta@unina.it


   Simon Pietro Romano
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   EMail: spromano@unina.it