idnits 2.17.1
draft-levin-xcon-cccp-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 18.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 2309.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2286.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2293.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2299.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 45 instances of too long lines in the document, the longest
one being 3 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (December 30, 2005) is 6692 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: 'TBD' on line 336
== Unused Reference: '3' is defined on line 2232, but no explicit reference
was found in the text
== Unused Reference: '4' is defined on line 2239, but no explicit reference
was found in the text
-- Possible downref: Normative reference to a draft: ref. '3'
-- Obsolete informational reference (is this intentional?): RFC 3265 (ref.
'4') (Obsoleted by RFC 6665)
== Outdated reference: A later version (-11) exists of
draft-ietf-xcon-framework-01
Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 XCON Working Group O. Levin
3 Internet-Draft Microsoft Corporation
4 Expires: July 3, 2006 R. Even
5 Polycom
6 P. Hagendorf
7 RADVISION
8 December 30, 2005
10 Centralized Conference Control Protocol
11 draft-levin-xcon-cccp-04
13 Status of this Memo
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
23 Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on July 3, 2006.
38 Copyright Notice
40 Copyright (C) The Internet Society (2005).
42 Abstract
44 This document defines a Centralized Conferencing Control Protocol
45 (CCCP) as a part of the XCON Working Group protocols suite. CCCP
46 uses a client-server model for creation, querying, and manipulation
47 of XCON entities, conference objects and sub-objects. An XCON
48 entity, which implements a CCCP server, provides a means for
49 authorized CCCP clients (e.g. conference participants) to affect the
50 behavior of a conference in the XCON system.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
56 3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 4
57 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 4.1. Transaction Model . . . . . . . . . . . . . . . . . . . . 4
59 4.2. Multiple Primitives in a Single Operation . . . . . . . . 6
60 4.3. Response Codes and Failures . . . . . . . . . . . . . . . 6
61 5. Using the Data Model . . . . . . . . . . . . . . . . . . . . . 6
62 6. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 7
63 6.1. Remote Procedure vs. Data Manipulation . . . . . . . . . . 7
64 6.2. CCCP Transactions vs. SOAP . . . . . . . . . . . . . . . . 8
65 7. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 9
66 7.1. System Primitives . . . . . . . . . . . . . . . . . . . . 9
67 7.1.1. Cancel . . . . . . . . . . . . . . . . . . . . . . . . 9
68 7.1.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 10
69 7.1.3. getTemplates . . . . . . . . . . . . . . . . . . . . . 11
70 7.1.4. getActiveConferences . . . . . . . . . . . . . . . . . 11
71 7.2. Conference Primitives . . . . . . . . . . . . . . . . . . 11
72 7.2.1. addConference . . . . . . . . . . . . . . . . . . . . 11
73 7.2.2. modifyConference . . . . . . . . . . . . . . . . . . . 13
74 7.2.3. deleteConference . . . . . . . . . . . . . . . . . . . 14
75 7.2.4. getConference . . . . . . . . . . . . . . . . . . . . 15
76 7.3. User Primitives . . . . . . . . . . . . . . . . . . . . . 16
77 7.3.1. addUser . . . . . . . . . . . . . . . . . . . . . . . 16
78 7.3.2. modifyUser . . . . . . . . . . . . . . . . . . . . . . 17
79 7.3.3. modifyUserRoles . . . . . . . . . . . . . . . . . . . 18
80 7.3.4. deleteUser . . . . . . . . . . . . . . . . . . . . . . 19
81 7.3.5. getUser . . . . . . . . . . . . . . . . . . . . . . . 20
82 7.4. Endpoint Primitives . . . . . . . . . . . . . . . . . . . 21
83 7.4.1. addEndpoint . . . . . . . . . . . . . . . . . . . . . 21
84 7.4.2. modifyEndpoint . . . . . . . . . . . . . . . . . . . . 22
85 7.4.3. deleteEndpoint . . . . . . . . . . . . . . . . . . . . 23
86 7.4.4. getEndpoint . . . . . . . . . . . . . . . . . . . . . 24
87 7.5. Endpoint Media Primitives . . . . . . . . . . . . . . . . 25
88 7.5.1. addEndpointMedia . . . . . . . . . . . . . . . . . . . 26
89 7.5.2. modifyEndpointMedia . . . . . . . . . . . . . . . . . 26
90 7.5.3. deleteEndpointMedia . . . . . . . . . . . . . . . . . 27
91 7.5.4. getEndpointMedia . . . . . . . . . . . . . . . . . . . 28
92 7.6. Sidebar Primitives . . . . . . . . . . . . . . . . . . . . 29
93 7.6.1. addSidebar . . . . . . . . . . . . . . . . . . . . . . 29
94 7.6.2. modifySidebar . . . . . . . . . . . . . . . . . . . . 30
95 7.6.3. deleteSidebar . . . . . . . . . . . . . . . . . . . . 30
96 7.6.4. addUserToSidebar . . . . . . . . . . . . . . . . . . . 30
97 7.6.5. deleteUserFromSidebar . . . . . . . . . . . . . . . . 30
98 7.6.6. moveUserBetweenSidebars . . . . . . . . . . . . . . . 30
99 7.7. Stimulus Primitives . . . . . . . . . . . . . . . . . . . 30
100 8. The XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 30
101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
102 9.1. URN Sub-Namespace Registration for
103 urn:ietf:params:xml:ns:cccp . . . . . . . . . . . . . . . 49
104 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 50
105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
108 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
109 12.2. Informative References . . . . . . . . . . . . . . . . . . 51
110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
111 Intellectual Property and Copyright Statements . . . . . . . . . . 53
113 1. Introduction
115 The SIPPING Conference Framework [6] describes a general centralized
116 conferencing architecture. The XCON Framework [7] defines how this
117 architecture can be realized by an XCON compliant system. This
118 document defines a Centralized Conferencing Control Protocol (CCCP)
119 as a conference control protocol in the XCON protocols suite
120 described in XCON Framework [7]
122 CCCP uses a client-server model for creation, querying, and
123 manipulation of XCON entities, conference objects and sub-objects.
124 By implementing a CCCP server, an XCON entity provides a means for
125 authorized CCCP clients (e.g. conference participants) to affect the
126 behavior of a conference in the XCON system. CCCP is a semantic-
127 oriented protocol, which uses the XML types defined in the SIPPING
128 Conference Package [2] for the representation of the conference
129 object and its sub-objects . In future, the CCCP can be extended to
130 include manipulations on additional conferencing objects being
131 represented by XML schemas such as policies and templates.
133 2. Terminology
135 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
136 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
137 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
138 described in BCP 14, RFC 2119 [1] and indicate requirement levels for
139 compliant implementations.
141 3. Transport
143 The protocol design assumes that CCCP runs on a reliable transport
144 protocol.
146 CCCP is agnostic to the details of the transport protocol being used
147 beneath and does not rely on any information being conveyed on the
148 transport level. This model allows for using different transport
149 protocols based on the system requirements and also for multiplexing
150 otherwise independent CCCP communications over a common transport
151 channel.
153 4. The Protocol
155 4.1. Transaction Model
157 CCCP is a client-server protocol. The protocol defines two
158 operations: request and response.
160 A client issues requests to a server. The server MUST reply with a
161 single final response. Two final responses are defined: "failure"
162 and "success".
164 Before issuing the final response, the server MAY reply with multiple
165 provisional responses. Currently a single provisional response
166 "pending" is defined.
168 Editor's Note: Timeouts TBD.
170 A CCCP request carries the following attributes:
172 +------------+------------------------------------------------------+
173 | Attribute | Description |
174 +------------+------------------------------------------------------+
175 | requestId | A unique string generated by the CCCP client across |
176 | | all its requests. |
177 | from | A transport URI which identifies the CCCP client. |
178 | to | A transport URI which identifies the CCCP server. |
179 | originator | A trusted ID of the originator of the request. |
180 +------------+------------------------------------------------------+
182 Table 1
184 The combination of the 'requestId', 'to', and 'from' attributes in
185 the request constitutes the CCCP transaction ID.
187 A CCCP response carries the following attributes:
189 +------------+------------------------------------------------------+
190 | Attribute | Description |
191 +------------+------------------------------------------------------+
192 | requestId | The original request ID generated by the client and |
193 | | echoed as is by the server. |
194 | from | A transport URI which identifies the CCCP server. |
195 | to | A transport URI which identifies the CCCP client. |
196 | code | The general response code: success, pending, or |
197 | | failure. |
198 | reason | The general CCCP failure reason. |
199 | timeout | The updated timeout used with pending responses |
200 | | (details TBD). |
201 | retryAfter | The suggested delay used with serverBusy responses. |
202 +------------+------------------------------------------------------+
204 Table 2
206 4.2. Multiple Primitives in a Single Operation
208 A CCCP operation (i.e. a request and a corresponding response) MAY
209 contain multiple primitives. The CCCP MUST process the received
210 primitives one-by-one in the order they appear in the request body.
211 If the request contains multiple primitives, the corresponding
212 response operation MUST contain the response primitive for each and
213 in the same order as in the request.
215 Multiple primitives within the same request MUST be executed as an
216 atomic operation. This means that if one primitive fails, the state
217 of the object MUST be rolled back to its state before processing the
218 request.
220 If a CCCP server is not willing to process a multi-primitive request,
221 it MUST fail the transaction with the response code "notSupported".
223 4.3. Response Codes and Failures
225 CCCP defines the following reasons for failure of a request operation
227 +------------------+------------------------------------------------+
228 | Failure | Description |
229 +------------------+------------------------------------------------+
230 | serverBusy | Optional retryAfter can be included in the |
231 | | response. |
232 | timeout | Operation took too long and was aborted by the |
233 | | server |
234 | unauthorized | Client is not authorized to perform the |
235 | | operation. |
236 | requestMalformed | The XML document in the request is either not |
237 | | well-formed or not compliant with the schema. |
238 | requestTooLarge | Result of the request operation length check. |
239 | requestCancelled | The pending request was canceled by CCCP. |
240 | notSupported | One of the primitives or their combination is |
241 | | not supported by the server. |
242 | otherFailure | Result of any other server fault condition. |
243 +------------------+------------------------------------------------+
245 Table 3
247 Most CCCP primitives define their own optional response codes. This
248 allows communicating the detailed primitive result in addition to the
249 CCCP general response code.
251 5. Using the Data Model
252 The CCCP operations are applied to the data objects expressed in
253 terms of SIPPING Conference Package [2] XML types whenever possible.
254 The considerations listed below MUST be taken into account when using
255 the schema with CCCP.
257 The information included in the request expresses the desired data
258 object state to be achieved after the operation is successfully
259 completed. By definition, the CCCP primitives allow for inclusion of
260 any information that can be expressed in terms of the conference-type
261 and its sub-types.
263 Attributes 'state' and 'version' of the conference-type and its sub-
264 types are never used with CCCP. The information in the response is
265 provided as a feedback to the request only and typically does not
266 carry the full state of the object.
268 For each primitive request, the CCCP explicitly defines (see Section
269 6) what information (i.e. attributes and elements) MUST be provided
270 by the client and what information (when provided by the client) MUST
271 NOT be ignored by the server. The rest of the information included
272 by the client MAY be treated as optional by the server.
274 For each primitive response, the CCCP explicitly defines (see Section
275 6) what information (i.e. attributes and elements) if included by the
276 server MUST NOT be ignored by the client. The rest of the
277 information included by the client MAY be treated as optional by the
278 server. If neither mandatory information nor new data is generated,
279 the server MAY return minimum schema compliant construct, such as an
280 element with empty body and the attributes identifying the
281 corresponding request only. On the other hand, the CCCP server MAY
282 include any rich dynamically generated information to the client (for
283 example, to be displayed to a user or be logged in by the system) in
284 the response. The client MAY ignore any information received in the
285 response, unless stated otherwise in Section 6.
287 6. Design Rationale
289 6.1. Remote Procedure vs. Data Manipulation
291 The first step in the decision process was to compare between a data
292 manipulation approach and a remote procedure call approach.
294 The advantages of the data manipulation approach are:
295 o Mostly appropriate for simple lightweight clients using built on a
296 stimulus-response model
298 o The data model is the protocol -- any existing generic data
299 manipulation protocol will work
300 o Adding functionality does not require changes to the protocol,
301 only to the data model. The server implementation needs to track
302 these changes of course and implement the corresponding new
303 functionality.
305 The advantages for the remote procedure call approach are:
306 o Mostly appropriate for conferencing-aware client applications that
307 are built to automate the experience and/or hide conferencing
308 complexity from the end user
309 o Makes compound operations and conference specific operations
310 explicit and thus much easier and faster for conferencing server
311 implementation
312 o Allows for inclusion of data manipulation primitives when desired,
313 e.g. for manipulating templates. In other words, a hybrid
314 approach is easily built where it makes sense.
316 We came to a conclusion that there is a place for both approaches to
317 co-exist in the industry. The decision of which to use in each case
318 will be based on the client side requirements.
320 We also came to a conclusion that it is not necessary to define a new
321 conference-specific protocol in order to meet the lightweight client
322 requirements for a stimulus-response approach. Instead one of the
323 existing standard data manipulation protocols can be used for this
324 purpose. This approach will require standardizing the user interface
325 in terms of a standard conferencing XML schema(s).
327 On the other hand, smart conference-aware conferencing clients cannot
328 operate using abstract stimulus-response approach only. In order to
329 achieve both efficient and flexible conference control, a truly
330 application-specific, i.e. a conferencing control protocol, is
331 needed. The CCCP is defined with this need in mind.
333 6.2. CCCP Transactions vs. SOAP
335 It is not difficult to map the CCCP primitives and functionality into
336 a SOAP compliant protocol as shown in [TBD]. Apart from the pure
337 syntax differences, the two protocols differ in the way they report
338 the final result of a requested operation.
340 According to the SOAP specification, each transaction is comprised of
341 a request and a single corresponding response (which are transported
342 over the underlying HTTP transaction). This definition means that an
343 application that uses SOAP needs to define its own conventions for
344 handling requests that can not be completed immediately. Typically
345 this is being achieved by introducing an additional notification
346 channel in the direction opposite to the request. It is important to
347 note that this channel must not be mistaken with the conference state
348 notification channel defined in [conf package].
350 The conference control notification channel should be provided to the
351 client originating the request only and would not necessarily reflect
352 any changes in the conference state. For example, in case a request
353 transaction is completed with the "in progress" response and later a
354 server fails to execute the request, the notification sent to the
355 client will not convey any change in the conference state, but rather
356 needs to convey the request ID and the failure reason.
358 CCCP is different at that sense from the SOAP architecture. CCCP
359 does not use any dedicated notification channel. Instead CCCP has
360 the notion of possible multiple pending responses always followed by
361 the final (either success or failure) response. This approach
362 simplifies the conferencing application and also makes CCCP truly
363 independent from the underlying transport protocol.
365 It is important to note that a CCCP client is expected to support the
366 Conference State event package as the means for maintaining the most
367 current synchronized conference state. The client should not use the
368 CCCP responses for updating the local copy of the conference state
369 document.
371 7. Primitives
373 This section describes the defined CCCP primitives and includes valid
374 XML document examples for each. The corresponding CCCP XML schema is
375 provided in Section 7.
377 7.1. System Primitives
379 7.1.1. Cancel
381 Cancel a pending request.
383 This primitive can be issued by a client to cancel a pending
384 transaction. The primitive is an independent transaction on its own.
385 The body of the primitive MUST carry the requestId of one of the
386 pending requests.
388
397
398 5
399
400
402 Note that a valid response can contain an empty body.
404
414
415
417 7.1.2. Ping
419 Ping a CCCP Server.
421
430
431
433 A successful response is shown below.
435
445
446
448 7.1.3. getTemplates
450 Get the list of templates supported by the system. XML TBD.
452 7.1.4. getActiveConferences
454 Get the list of conference identifiers for active conference objects
455 in the system.
457 XML TBD.
459 7.2. Conference Primitives
461 7.2.1. addConference
463 Create a conference.
465 The 'conferenceEntity' value in the request is a client's suggestion
466 only. The CCCP server MAY replace the suggested value with a
467 different 'conferenceEntity' value in the corresponding response.
469
478
479
482
483 Design Review
484
485
486 tel:+1-8666119036
487 FFD bridge
488
489
490
491
492 https://company.com/ConfServer
493
494
495
496
497 audio
498
499
500
501
502
503
505 The CCCP server MAY replace the suggested 'conferenceEntity' with a
506 different value in the corresponding response. In the case of a
507 successful response, the CCCP client MUST use the new value and
508 SHOULD use all the new parameters allocated by the server to the
509 conference.
511
521
522
525
526 Design Review
527
528
529 tel:+1-8666119036
530 FFD bridge
531
532
533
534
535 https://company.com/ConfServer
536
537
538
539
540 audio
541
542
543
544
545
546
548 7.2.2. modifyConference
550 Modify conference parameters.
552
561
562
565
566 Spec Review
567
568
569
570
572
582
583
585 7.2.3. deleteConference
587 Remove conference from the system.
589
598
599
601
602
604
614
615
617 7.2.4. getConference
619 Retrieve the conference information.
621
630
631
633
634
635
645
646
649
650 Design Review
651
652
653 tel:+1-8666119036
654 FFD bridge
655
656
657
658
659 https://company.com/ConfServer
660
661
662
663
664 audio
665
666
667
668
669
670
672 7.3. User Primitives
674 7.3.1. addUser
676 The client MUST provide the 'userEntity' value in the request.
678
687
688
690
692 Bob Hoskins
693
694 presenter
695
696
697
698
700
710
711
713 7.3.2. modifyUser
715 Modify the user information.
717
726
727
729
731 Bob Hoskins III
732
733
734 tel:2562566
735 the description
736 optional tbd values
737
738
739
740 presenter
741
742
743
744
746
756
757
759 7.3.3. modifyUserRoles
761 This is a dedicated primitive to change user's roles. The same
762 effect can be achieved by using the modifyUser primitive. Note that
763 a CCCP server can choose to implement both approaches simultaneously
764 to be invoked by different clients.
766 Editor's Note: The dedicated primitive is defined to demonstrate that
767 both approaches are possible with CCCP.
769
778
779
782
784 presenter
785
786
787
789
799
800
802 7.3.4. deleteUser
804 Remove the user from the conference roster.
806
815
816
819
820
822
832
833
835 7.3.5. getUser
837 Retrieve the information about a conference participant.
839
848
849
852
854
856
866
867
868
870 Bob Hoskins III
871
872
873 tel:2562566
874 the description
875 optional tbd values
876
877
878
879 presenter
880
881
882
883
885 7.4. Endpoint Primitives
887 7.4.1. addEndpoint
889 Bring the specified user into a conference by establishing a call
890 (signaling and media) with him/her/it.
892 The endpoint 'entity' value MAY be replaced or augmented by the CCCP
893 server. The 'media-id' value MAY be replaced or augmented by the
894 CCCP server. If the server returns this information in the response,
895 the client MUST use the values provided by the server.
897
906
907
910
912 Bob's Laptop
913 dialed-out
914
915 main audio
916 audio
917
918
919
920
922
932
933
935 7.4.2. modifyEndpoint
937 Modify the call description or/and its behaivior.
939
948
949
952
954 Bob's Laptop
955
956
957
959
969
970
972 7.4.3. deleteEndpoint
974 Disconnect the call.
976
985
986
990
991
993
1003
1004
1006 7.4.4. getEndpoint
1008 Retrieve the information about the call.
1010
1019
1020
1024
1025
1027
1037
1038
1041
1043 Bob's Laptop
1044 dialed-out
1045
1046 main audio
1047 audio
1048
1049
1050
1051
1053 7.5. Endpoint Media Primitives
1054 7.5.1. addEndpointMedia
1056 Add the specified media stream to the call.
1058 The 'media-id' value MAY be replaced or augmented by the CCCP server.
1059 The CCCP client MUST use the new value if returned by the server in
1060 the response.
1062
1071
1072
1076
1078 main audio
1079 audio
1080
1081
1082
1084
1094
1095
1097 7.5.2. modifyEndpointMedia
1099 Modify the media behavior. This primitive can be used to mute and
1100 un-mute the call.
1102
1111
1112
1116
1118 audio
1119 recvonly
1120
1121
1122
1124
1134
1135
1137 7.5.3. deleteEndpointMedia
1139 Remove the specified media stream from the call.
1141
1150
1151
1156
1157
1159
1169
1170
1172 7.5.4. getEndpointMedia
1174 Retrieve the information about the specified stream in the call.
1176
1185
1186
1191
1192
1194
1204
1205
1209
1211 audio
1212 recvonly
1213
1214
1215
1217 7.6. Sidebar Primitives
1219 7.6.1. addSidebar
1221 Create a sidebar in the conference.
1223 XML TBD.
1225 7.6.2. modifySidebar
1227 Modify the sidebar parameters in the conference.
1229 XML TBD.
1231 7.6.3. deleteSidebar
1233 Remove the sidebar from the conference.
1235 XML TBD.
1237 7.6.4. addUserToSidebar
1239 Add the specified conference participant to the sidebar.
1241 XML TBD.
1243 7.6.5. deleteUserFromSidebar
1245 Remove the specified conference participant from the sidebar.
1247 XML TBD.
1249 7.6.6. moveUserBetweenSidebars
1251 Move the the specified conference participant from sidebar A to
1252 sidebar B.
1254 XML TBD.
1256 7.7. Stimulus Primitives
1258 This operation is used to convey opaque to the CCCP logic requests
1259 from a CCCP client to a CCCP server to be processed by applications
1260 above CCCP.
1262 XML TBD.
1264 8. The XML Schema
1266
1267
1277
1281
1285
1289
1293
1296
1298
1301
1303
1306
1307
1308
1309
1311
1313
1315
1317
1319
1321
1323
1325
1327
1329
1331
1333
1335
1337
1339
1341
1343
1345
1347
1350
1351
1352
1354
1357
1358
1361
1363
1367
1369
1370
1372
1375
1376
1377
1378
1380
1382
1384
1386
1388
1390
1392
1394
1396
1398
1400
1402
1404
1406
1408
1410
1412
1414
1416
1419
1420
1421
1423
1426
1428
1431
1433
1436
1438
1440
1442
1444
1446
1448
1449
1450
1453
1454
1455
1456
1457
1458
1459
1461
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1477
1480
1481
1482
1484
1486
1489
1490
1491
1492
1494
1496
1499
1500
1501
1502
1503
1505
1507
1511
1512
1513
1514
1515
1516
1518
1520
1523
1524
1525
1526
1528
1529
1531
1533
1536
1537
1538
1540
1542
1543
1545
1546
1548
1551
1552
1553
1554
1555
1556
1558
1561
1562
1563
1565
1566
1567
1569
1573
1574
1575
1577
1579
1580
1581
1583
1586
1587
1588
1589
1591
1592
1593
1595
1598
1599
1600
1601
1602
1603
1605
1606
1607
1609
1610
1612
1615
1616
1617
1618
1619
1620
1622
1625
1626
1627
1629
1631
1632
1633
1635
1638
1639
1640
1641
1642
1643
1645
1646
1647
1649
1650
1652
1656
1657
1658
1659
1660
1661
1663
1666
1667
1668
1670
1672
1673
1674
1676
1679
1680
1681
1682
1683
1684
1686
1687
1688
1691
1692
1694
1697
1698
1699
1700
1701
1702
1703
1706
1707
1708
1710
1711
1713
1714
1715
1717
1720
1721
1722
1724
1725
1727
1728
1730
1731
1733
1736
1737
1738
1739
1740
1741
1742
1744
1747
1748
1749
1752
1753
1755
1756
1757
1759
1762
1763
1764
1766
1767
1768
1769
1771
1772
1773
1775
1776
1778
1781
1782
1783
1785
1787
1788
1789
1791
1794
1795
1796
1798
1799
1800
1801
1803
1804
1805
1807
1809
1811
1814
1815
1816
1817
1818
1819
1820
1822
1825
1826
1827
1829
1831
1832
1833
1835
1838
1839
1840
1842
1843
1844
1845
1847
1849
1850
1852
1853
1855
1858
1859
1860
1861
1862
1863
1864
1866
1869
1870
1871
1873
1874
1875
1876
1878
1879
1880
1881
1883
1886
1887
1888
1890
1891
1892
1893
1895
1896
1897
1899
1900
1901
1904
1905
1906
1908
1910
1911
1912
1914
1917
1918
1919
1920
1921
1922
1923
1924
1926
1929
1930
1931
1933
1934
1935
1936
1938
1939
1940
1942
1943
1944
1947
1948
1949
1951
1953
1954
1955
1957
1960
1961
1962
1963
1964
1965
1966
1967
1969
1972
1973
1974
1976
1977
1978
1979
1981
1982
1983
1986
1987
1989
1993
1994
1995
1997
1998
2000
2001
2002
2004
2007
2008
2009
2011
2012
2013
2014
2016
2017
2018
2021
2022
2024
2027
2028
2029
2030
2031
2032
2033
2034
2035
2037
2040
2041
2042
2044
2047
2048
2049
2051
2054
2055
2056
2057
2058
2059
2060
2061
2062
2064
2067
2068
2069
2071
2072
2073
2074
2076
2077
2078
2080
2081
2083
2086
2087
2088
2090
2092
2093
2094
2096
2099
2100
2101
2103
2104
2105
2106
2108
2109
2110
2112
2113
2115
2118
2119
2120
2123
2125
2126
2127
2129
2130
2132
2135
2136
2137
2139
2140
2141
2143
2144
2145
2146
2148
2151
2152
2153
2154
2155
2156
2157
2158
2159
2161 Figure 39
2163 9. IANA Considerations
2165 This document registers a new XML namespace and a new XML schema.
2167 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cccp
2169 This section registers a new XML namespace, as per the guidelines in
2170 RFC 3688 [5].
2172 URI: The URI for this namespace is urn:ietf:params:xml:ns:cccp
2173 Registrant Contact: IETF XCON Working Group , as
2174 designated by the IESG
2175 XML:
2177 BEGIN
2178
2179
2181
2182
2183
2185 Centralized Conference Information Namespace
2187
2189 Namespace for Centralized Conference Control Protocol
2190 urn:ietf:params:xml:ns:cccp
2191 See RFCXXXX.
2192
2193