Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6504

Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Pages: 78
Informational
Part 4 of 4 – Pages 60 to 78
First   Prev   None

Top   ToC   RFC6504 - Page 60   prevText

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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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   ToC   RFC6504 - 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