idnits 2.17.1 draft-ietf-mmusic-sccp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 52 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 491: '... Usage of SCCP MUST be described in ...' RFC 2119 keyword, line 497: '...e sent. In this case it is RECOMMENDED...' RFC 2119 keyword, line 500: '...not the case the second sub-field MUST...' RFC 2119 keyword, line 503: '...irst port number MUST be followed by a...' RFC 2119 keyword, line 507: '...ion of the value MUST be set to "SCCP"...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 637 has weird spacing: '...AS_Flag flag;...' == Line 638 has weird spacing: '...P_Value val...' == Line 646 has weird spacing: '...CP_Name pres...' == Line 708 has weird spacing: '...P_Flags fla...' == Line 709 has weird spacing: '...P_Value val...' == (2 more instances...) -- 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 (February 13, 2001) is 8473 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-09) exists of draft-ietf-sip-rfc2543bis-02 ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '3') ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1889 (ref. '5') (Obsoleted by RFC 3550) -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bormann 3 Internet-Draft Kutscher 4 Expires: August 14, 2001 Ott 5 TZI, Universitaet Bremen 6 Trossen 7 Nokia Research Center 8 February 13, 2001 10 Simple Conference Control Protocol -- Service Specification 11 draft-ietf-mmusic-sccp-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 14, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document defines the services for a simple conference control 40 protocol (SCCP) to be used for tightly coupled conferences. It is 41 part of the Internet Multimedia Conferencing Architecture, proposed 42 in [1]. 44 The SCCP services provide functionality for management of the set of 45 members, management of the set of application/media sessions, and 46 for floor control to implement access control rules for distributed 47 application resources. 49 Note that this document does not specify how to implement the 50 proposed services. For that, different mappings are specified based 51 on different transport layer techniques. 53 This document is a product of the Multiparty Multimedia Session 54 Control (MMUSIC) working group of the Internet Engineering Task 55 Force. Comments are solicited and should be addressed to the 56 working group's mailing list at confctrl@isi.edu and/or the authors. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2 SCCP and Conference Setup . . . . . . . . . . . . . . . . . . 3 63 1.3 SCCP and Capability Negotiation . . . . . . . . . . . . . . . 4 64 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 65 3. Services of SCCP . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1 Conference Management . . . . . . . . . . . . . . . . . . . . 7 67 3.2 Application Session Management . . . . . . . . . . . . . . . . 7 68 3.3 Floor Control . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Requirements for Mappings onto underlying Transports . . . . . 10 70 5. A Model for Configuration and Capability Negotiation . . . . . 11 71 6. SDP considerations . . . . . . . . . . . . . . . . . . . . . . 14 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 75 A. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18 76 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24 78 1. Introduction 80 1.1 Overview 82 The Internet Multimedia Conferencing Architecture [1] currently 83 comprises conference control elements only for loosely coupled 84 conferences, i.e., "crowds that gather around an attraction". 85 However, many conferences have more formal policies with respect to 86 the underlying "social protocol" of the specific scenario. Also, it 87 may be desirable to change parameters of the conference, e.g., set 88 of media/applications and their parameters, in a coordinated way for 89 all participants. Conferences that have facilities for this purpose 90 shall be termed "tightly coupled conferences" in this document. 92 This document defines services for simple conference control of 93 tightly coupled conferences. The services provided by this protocol 94 were guided by the services offered by the ITU-T recommendations of 95 the H.323 series [7], namely: 97 o management of the set of members participating in the conference; 99 o management of the set of media/application sessions that 100 constitute the conference; and 102 o floor control, which especially enables "conducted" conferences 103 or implementation of arbitrary access control on distributed 104 resources. 106 Note that this document specifies only the services to be provided 107 but not the protocol mechanisms to be used for implementation. The 108 latter are to be specified by different "mapping drafts" for 109 specific transport layer techniques. 111 1.2 SCCP and Conference Setup 113 The Internet Multimedia Conferencing Architecture described in [1] 114 provides a categorization of conference management concepts and 115 corresponding technologies. The domain of conference management is 116 divided into conference setup (including conference discovery) and 117 conference course control. 119 While conference setup mechanisms, such as SIP [2], provide means to 120 distribute a proper initial state to the involved end systems, the 121 purpose of a conference course control protocol like SCCP is to 122 manage a state during the lifetime of a conference. 124 However, in cases where conferences are set up with SIP, the state 125 managed by SCCP would incorporate the initial conference state. This 126 initial state usually includes configuration of media sessions, that 127 might result from negotiation processes. One element of the initial 128 configuration of SCCP-enabled conference will be the configuration 129 of the SCCP channel and transport mapping-specific information. 131 While we clearly distinguish between the roles of conference setup 132 and conference course control there is a strong relation between 133 these two forms of conference control and it is therefore desirable 134 to define a way how to emerge an initial conference state (setup and 135 distributed with SIP, SAP, or by other means) into an SCCP-state. 137 1.3 SCCP and Capability Negotiation 139 The configuration information of application sessions in the setup 140 protocols SIP and SAP [3] is specified in a session description, in 141 the moment this is often an SDP [4] description. 143 Because SDP addresses the description of conferences only, a new 144 conference description framework is currently being defined ([6]). 145 This work does not only address the issue of describing sessions but 146 also the issue of capability negotiation. 148 In Section 3.2 capability (re-)negotiation is listed as one of the 149 functionalities provided by SCCP for application session management. 150 Section 5 presents a model for configuration and capability 151 negotiation that is currently pursued by [6]. The refinement of the 152 SCCP services in future versions of this document will consider this 153 model. 155 2. Definition of Terms 157 Participant: A human being that takes part in a conference. 159 Member: The system, including software and hardware, that takes part 160 in a computer conference, representing a single participant. 162 End system: A host or a set of locally interconnected hosts [1] that 163 is used as an interface to a teleconference by a single 164 participant. The end system runs all the required conferencing 165 software. Together with this software it constitutes a member. 167 SCCP entity: An instantiation of an SCCP implementation running on 168 an end system for a single member. An SCCP entity (or entity for 169 short) represents a specific participant in the conference using 170 the SCCP protocol. 172 Conference controller: An application that interacts closely with an 173 SCCP entity on one hand to implement the conference policy and 174 with the participant on the other hand to realize her wishes. 176 UCI: A universal communication identifier of a person. Used as the 177 E-mail address of an individual as well as the address that can 178 be used to invite that individual via SIP [2]. 180 Presence: A representation of the fact that an identified person is 181 using a particular end system for the purpose of (potentially or 182 actually) representing this person in one or more conferences. A 183 presence corresponds to that person "being logged in" at an end 184 system and (potentially or actually) being available for 185 conferencing. There is a one-to-many relationship between 186 presences and members: one presence may be member of many 187 conferences. There is a one-to-one relationship between members 188 and the cross-product of presences and the set of conferences 189 this presence appears in (which cross-product contains the set of 190 "appearances" of each presence). 192 Conference context: All session and membership information kept at 193 each member of a conference which can be accessed by each SCCP 194 entity through appropriate service requests. 196 Profile: An initial description of the conference, including 197 assignment of roles to particular members, time limits for 198 speakers, attributes of the conference (open/close, 199 conducted/anarchic, etc). 201 Application session (AS), Session: The set of media 202 agents/applications that act as peers to each other within a 203 conference. For real-time data, this generally will be an RTP 204 session; for other application protocols, other horizontal 205 protocols may define their own type of session concept. Possible 206 synonyms are "application group" or "media agent group". 208 Floor context: State information about floors which can be accessed 209 by each SCCP entity through appropriate service requests. 211 3. Services of SCCP 213 This section describes the services provided by SCCP and realized by 214 appropriate protocol mechanisms. Note that the latter is not within 215 the scope of this document. 217 3.1 Conference Management 219 SCCP is responsible for managing a conference context containing 220 membership information of all current conference participants. The 221 following operations are possible in the context of SCCP conference 222 management: 224 invite other users: SCCP users may invite other users to participate 225 in the current SCCP conference. 227 join the conference: SCCP provides to dynamically join a running 228 conference. The conference context is updated appropriately. 230 leave the conference: SCCP also provides to dynamically leave a 231 conference without disturbance. The conference context is updated 232 appropriately. 234 terminate the conference: in the case of a "conducted" conference, a 235 running conference may be terminated by the conductor resulting 236 in a destruction of the entire conference. 238 obtain conference context: maintain the information stored in the 239 conference context. 241 For sake of simplicity, SCCP does not provide more sophisticated 242 features like merging, appending, or splitting entire conferences. 244 3.2 Application Session Management 246 SCCP provides functionality to manage a set of media/application 247 sessions that constitute the conference, e.g., for real-time data 248 this will be an RTP session [5]. 250 Each media/application set is maintained in the conference context. 251 Hence, its parameters can be obtained using appropriate conference 252 context functions. However, it is also possible to create 253 application sessions without registering them in the conference 254 context due to scalability reasons. 256 Hence, SCCP offers the following application session management 257 functions: 259 negotiating and changing the configuration of application sessions: 261 allows to find an appropriate configuration of one or more 262 application sessions. Different policies for different types of 263 conferences and different requirements for different media types 264 have to be considered (symmetric vs. asymmetric configurations, 265 equal rights for participants or not etc.) The negotiation and 266 changing of the configuration can be applied on existing 267 application sessions (re-negotiation) or on newly created 268 application sessions. See Section 5 for the description of a 269 model for configuration and capability negotiation. 271 creating application sessions: defines a media/application set being 272 identified by a unique identifier within the conference. The 273 allowance to create application sessions depends on the 274 conference policy, e.g., in a conducted conference only the 275 conductor is allowed to create application sessions. The members 276 of the application session are stored in the appropriate 277 application session context entry. 279 terminating application sessions: an SCCP entity (as permitted in 280 the conference profile) deletes an application session. The 281 conference context is updated and the termination is signaled to 282 the appropriate local application(s). 284 joining application sessions: an SCCP entity starts the application 285 which then joins the SCCP application session. The conference 286 context is updated appropriately by adding the application as a 287 peer in the media/application set. 289 leaving application sessions: an SCCP entity terminates the local 290 application and leave the SCCP application session. The 291 conference context is updated appropriately. 293 inexact application sessions: For large conferences, it may make 294 sense to mark an application session as "inexact", i.e., no join 295 or leave messages are to be distributed. This may also be useful 296 in case that application protocols are able to maintain 297 membership information by themselves. 299 3.3 Floor Control 301 SCCP provides floor control facilities to support application state 302 synchronization. Additionally, conductorship of conferences is also 303 realized using the floor control functionality. 305 Hence, SCCP supports to map "social protocols", i.e., the rules to 306 access application objects like audiovisual streams, onto 307 distributed systems. However, the mapping of floors onto application 308 semantics is not within the scope of SCCP. 310 Each floor within SCCP is identified using a conference-unique name. 311 The naming pattern is not within the scope of SCCP. 313 Hence, SCCP provides the following floor control services: 315 grab floor: allocates a floor for exclusive use by the requesting 316 participant 318 inhibit floor: allocates a floor for non-exclusive use by several 319 participants 321 release floor: releases a previously allocated floor; the state of 322 the floor is changed accordingly 324 test floor: ask for the current state (F_FREE, F_GRABBED, 325 F_INHIBITTED) of the floor 327 ask floor: ask the current floor holder to grant an exclusive floor 328 to the requesting SCCP entity 330 give floor: grant an exclusive floor to another participant 332 holders of floor: ask for a list of current floor holders 334 It can be seen that the provided floor control service is very 335 similar to the T.122 services [8] of the H.323 standard. However, 336 requesting the current floor holder list is not supported by the 337 T.122 standard. 339 4. Requirements for Mappings onto underlying Transports 341 As previously mentioned in the introduction, this draft does not 342 specify the mappings onto different transport layer mechanisms. 343 However, some basic functionality is assumed by the underlying 344 transport to provide. 346 The requirements for transport mappings are: 348 Reliable message transport: Transport layer services are assumed 349 to provide reliable, consistent delivery of data units called 350 "messages". Reliability is bounded by the fact that member end 351 systems may find that they no longer can reliably interact 352 with the other members, e.g., due to a network partitioning. 353 When considering unicast transfer of messages, a "connection 354 failure indication" is mandatory to be delivered to the SCCP 355 layer. 357 Globally ordered message delivery: Messages are globally ordered. 358 Each message is assigned a message number by the appropriate 359 transport service, and messages are delivered to SCCP entities 360 in monotonic message number order. In the rest of this 361 document, the term "distribute" will be used to indicate that 362 a member end system sends a message using the transport 363 service. 365 5. A Model for Configuration and Capability Negotiation 367 This section provides a model for configuration and capability 368 negotiation adopted from [6]. 370 In this document, the features enabled and restricted by fixed 371 hardware and software resources of end systems are termed "system 372 capabilities". For example, the capability to process (or generate) 373 audio data of a given codec format is one of the system capabilities 374 of an audio conferencing system. 376 In multiparty multimedia conferences, participants employ different 377 "components" in conducting the conference. 379 Example: In lecture multicast conferences one component might be 380 the voice transmission for the lecturer, another the transmission 381 of video pictures showing the lecturer and the third the 382 transmission of presentation material. 384 Depending on system capabilities, user preferences and other 385 technical and political constraints, different configurations can be 386 chosen to accomplish the "deployment" of these components. 388 Each component can be characterized at least by (a) its intended use 389 (i.e., the function it shall provide) and (b) a one or more possible 390 ways to realize this function. Each way of realizing a particular 391 function is referred to as a "configuration". 393 Example: A conference component's intended use may be to make 394 transparencies of a presentation visible to the audience on the 395 Mbone. This can be achieved either by a video camera capturing 396 the image and transmitting a video stream via some video tool or 397 by loading a copy of the slides into a distributed electronic 398 whiteboard. For each of these cases, additional parameters may 399 exist, variations of which lead to additional configurations (see 400 below). 402 Two configurations are considered different regardless of whether 403 they employ entirely different mechanisms and protocols (as in the 404 previous example) or they choose the same and differ only in a 405 single parameter. 407 Example: In case of video transmission, a JPEG-based still image 408 protocol may be used, H.261 encoded CIF images could be sent as 409 could H.261 encoded QCIF images. All three cases constitute 410 different configurations. Of course there are many more detailed 411 protocol parameters. 413 In this system model, we distinguish two types of configurations: 415 o potential configurations 416 (a set of any number of configurations per component) indicating 417 a system's functional capabilities as constrained by the intended 418 use of the various components; 420 o actual configurations 421 (exactly one per instance of a component) reflecting the mode of 422 operation of this component's particular instantiation. 424 Example: The potential configuration of the aforementioned video 425 component may indicate support for JPEG, H.261/CIF, and 426 H.261/QCIF. A particular instantiation for a video conference 427 may use the actual configuration of H.261/CIF for exchanging 428 video streams. 430 In summary, the key terms of this model are: 432 o A multimedia session (streaming or conference) consists of one or 433 more conference components for multimedia "interaction". 435 o A component describes a particular type of interaction (e.g., 436 audio conversation, slide presentation) that can be realized by 437 means of different applications (possibly using different 438 protocols). 440 o A configuration is a set of parameters that are required to 441 implement a certain variation (realization) of a certain 442 component. There are actual and potential configurations. 444 * Potential configurations describe possible configurations that 445 are supported by an end system. 447 * An actual configuration is an "instantiation" of one of the 448 potential configurations, i.e. a decision how to realize a 449 certain component. 451 In less abstract words, potential configurations describe what a 452 system can do ("capabilities") and actual configurations describe 453 how a system is configured to operate at a certain point in time 454 (media stream spec). 456 To decide on a certain actual configuration, a negotiation process 457 needs to take place between the involved peers: 459 1. to determine which potential configuration(s) they have in 460 common, and 462 2. to select one of this shared set of common potential 463 configurations to be used for information exchange (e.g., based 464 upon preferences, external constraints, etc.). 466 In SAP [3]-based session announcements on the Mbone, for which SDP 467 was originally developed, the negotiation procedure is non-existent. 468 Instead, the announcement contains the media stream description sent 469 out (i.e., the actual configurations) which implicitly describe what 470 a receiver must understand to participate. 472 In point-to-point scenarios, the negotiation procedure is typically 473 carried out implicitly: each party informs the other about what it 474 can receive and the respective sender chooses from this set a 475 configuration that it can transmit. 477 Capability negotiation must not only work for 2-party conferences 478 but is also required for multi-party conferences. Especially for the 479 latter case it is required that the process of determining the 480 subset of allowable potential configurations is deterministic to 481 reduce the number of required round trips before a session can be 482 established. 484 6. SDP considerations 486 This section defines how to describe conferences that make use of 487 SCCP with SDP. Note the transport mappings for SCCP will require 488 additional parameters to be configured and thus provide extensions 489 to the SDP conventions presented here. 491 Usage of SCCP MUST be described in separate media description, where 492 the media type of an SCCP media description is "control", i.e. the 493 first sub-field of the m= line of the SCCP description has the value 494 "control". 496 As specified in [4] the second sub-field is the transport port to 497 which the media stream will be sent. In this case it is RECOMMENDED 498 that for transport mappings where the concept of a transport port 499 number is applicable the value of this field is interpreted as a 500 port number. Even if this is not the case the second sub-field MUST 501 contain a decimal number in the range 1024 to 65535 inclusive. If 502 the transport mapping requires a range of port numbers to be 503 specified the first port number MUST be followed by a "/" and the 504 number of ports as a decimal number (as specified in [4]). 506 The third sub-field specifies the transport protocol. The first 507 portion of the value MUST be set to "SCCP" followed by "/" and an 508 identifier for the SCCP transport mechanism (to be defined in 509 corresponding transport mapping specifications). 511 In SDP, the fourth sub-field is used to specify media formats as RTP 512 payload types. For SCCP, the value "0" MUST be used. 514 Additional attributes that might be defined in "a=" lines are yet to 515 be defined (or specified by transport mapping specifications.) 517 Example of an SCCP description in SDP: 519 m=control 30000 SCCP/XY 0 521 7. Security Considerations 523 The authentication and encryption model for SCCP will be defined in 524 a future version of this document. 526 References 528 [1] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The 529 Internet Multimedia Conferencing Architecture", Internet Draft 530 draft-ietf-mmusic-confarch-03.txt, July 2000. 532 [2] Handley, , Schulzrinne, H., Schooler, and Rosenberg, "SIP: 533 Session Initiation Protocol", Internet Draft 534 draft-ietf-sip-rfc2543bis-02.txt, November 2000. 536 [3] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 537 Protocol", RFC 2974, October 2000. 539 [4] Handley, M. and V. Jacobsen, "SDP: Session Description 540 Protocol", RFC 2327, April 1998. 542 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, 543 "RTP: A Transport Protocol for Real-Time Applications", RFC 544 1889, January 1996. 546 [6] Kutscher, , Ott, and Bormann, "Requirements for Session 547 Description and Capability Negotiation", Internet Draft 548 draft-kutscher-mmusic-sdpng-req-01.txt, November 2000. 550 [7] ITU-T, "Visual Telephone Systems and Equipment for Local Area 551 Networks with Non-Guaranteed Quality of Service", ITU-T 552 Recommendation H.323, 2000. 554 [8] ITU-T, "Multipoint communication service - Service definition", 555 ITU-T Recommendation T.122, February 1998. 557 Authors' Addresses 559 Carsten Bormann 560 TZI, Universitaet Bremen 561 Bibliothekstr. 1 562 Bremen 28359 563 Germany 565 Phone: +49.421.218-7024 566 Fax: +49.421.218-7000 567 EMail: cabo@tzi.org 568 Dirk Kutscher 569 TZI, Universitaet Bremen 570 Bibliothekstr. 1 571 Bremen 28359 572 Germany 574 Phone: +49.421.218-7595 575 Fax: +49.421.218-7000 576 EMail: dku@tzi.org 578 Joerg Ott 579 TZI, Universitaet Bremen 580 Bibliothekstr. 1 581 Bremen 28359 582 Germany 584 Phone: +49.421.201-7028 585 Fax: +49.421.218-7000 586 EMail: jo@tzi.org 588 Dirk Trossen 589 Nokia Research Center 590 5 Wayside Road 591 Burlington, MA 01803 592 USA 594 Phone: +1.781.993-3605 595 Fax: +1.781.993-1907 596 EMail: dirk.trossen@nokia.com 598 Appendix A. Message Formats 600 Note that this XDR-like specification does not imply any particular 601 type of encoding of the PDUs. The encoding may be defined 602 independently, or RFC 1832 encoding may be used. 604 /* basic type definitions */ 605 typedef string SCCP_Name<>; 606 typedef opaque SCCP_Value<>; 607 typedef SCCP_Name SCCP_Namelist<>; 608 typedef integer SCCP_Sync; 610 /* Status of a floor to be given back with most requests */ 611 enum SCCP_Status { 612 F_FREE, 613 F_GRABBED, 614 F_INHIBITED, 615 F_GIVING 616 }; 617 /* Flag of an application session (see also section 3.2) */ 618 enum SCCP_AS_Flag { 619 AS_EXACT, 620 AS_INEXACT 621 }; 622 /* Error for requests, currently only for floor control */ 623 enum SCCP_Error { 624 SCCP_E_GRABBED, /* floor grabbed */ 625 SCCP_E_INHIBITED, /* floor inhibited */ 626 SCCP_E_FREE /* floor free */ 627 }; 629 /* SCCP_AS is the application session in the conference context 630 * Name: identifies the application session 631 * flag: exact or inexact session description 632 * value: reflects upper layer semantic 633 * namelist: list of media/application sets 634 */ 635 struct SCCP_AS { 636 SCCP_Name name; 637 SCCP_AS_Flag flag; 638 SCCP_Value value; /* upper layer semantics */ 639 SCCP_NameList namelist; 640 }; 642 /* SCCP_Member is the member entry in the conference context 643 * presence: presence information of the member 644 */ 645 struct SCCP_Member { 646 SCCP_Name presence; 647 }; 649 /* SCCP_Floor is the core entry in the floor context 650 * Name: identifies the floor 651 * status: status of floor 652 * Holders: list of floor holders for inhibited floor 653 * mapping_data: implementation-dependent data to be stored for 654 administration purpose 655 */ 656 struct SCCP_Floor { 657 SCCP_Name name; 658 SCCP_Status status; 659 SCCP_NameList Holders; 660 SCCP_Value mapping_data; 661 }; 663 /* SCCP_Conference_Context contains list of 664 * - members 665 * - sessions 666 */ 667 struct SCCP_Conference_Context { 668 SCCP_Member members<>; 669 SCCP_AS sessions<>; 670 }; 672 /* SCCP_Floor_Context contains list of floors to be maintained 673 depending on the chosen mapping for realization 674 */ 675 struct SCCP_Floor_Context { 676 SCCP_Floor floors<>; 677 }; 679 enum SCCP_Type { 680 SCCP_T_JOIN, /* join conference */ 681 SCCP_T_LEAVE, /* leave conference */ 682 SCCP_T_ACCEPT, /* accept joining member */ 683 SCCP_T_CONTEXT, /* context */ 685 SCCP_T_ASCREATE, /* create application session */ 686 SCCP_T_ASDELETE, /* delete application session */ 687 SCCP_T_ASJOIN, /* join application session */ 688 SCCP_T_ASLEAVE, /* leave application session */ 690 SCCP_T_FLOOR_GRAB, /* grab floor */ 691 SCCP_T_FLOOR_INHIBIT, /* inhibit floor */ 692 SCCP_T_FLOOR_RELEASE, /* release floor */ 693 SCCP_T_FLOOR_TEST, /* test floor */ 694 SCCP_T_FLOOR_ASK, /* ask for floor */ 695 SCCP_T_FLOOR_GIVE, /* give floor to other user */ 696 SCCP_T_FLOOR_GIVEN, /* indication to originator */ 697 SCCP_T_FLOOR_HOLDER, /* ask for floor holder list */ 698 SCCP_T_FLOOR_HOLDER_ASK, /* collect floor holder list */ 699 SCCP_T_FLOOR_HOLDER_LIST, /* indicate floor holder list */ 700 SCCP_T_FLOOR_STATUS, /* indicate floor status */ 701 SCCP_T_FLOOR_ERROR, /* floor control error */ 703 SCCP_T_INVALID /* last sccp pdu type */ 704 }; 706 struct SCCP_Join { 707 SCCP_Name presence; /* joining member */ 708 SCCP_Flags flags; /* precept etc. */ 709 SCCP_Value value; /* user data */ 710 }; 712 struct SCCP_Accept { 713 SCCP_Name presence; /* joining member */ 714 }; 716 struct SCCP_Leave { 717 SCCP_Name presence; /* joining member */ 718 }; 720 struct SCCP_Context_Msg { 721 SCCP_Conference_Context context; 722 SCCP_Sync sync; 723 }; 725 struct SCCP_AS_Create { 726 SCCP_Name name; 727 SCCP_Value value; 728 SCCP_Namelist names; 729 }; 731 struct SCCP_AS_Delete { 732 SCCP_Name name; 733 }; 735 struct SCCP_AS_Join { 736 SCCP_Name name; 737 SCCP_Name entry; 738 }; 740 struct SCCP_AS_Leave { 741 SCCP_Name name; 742 SCCP_Name entry; 743 }; 744 struct SCCP_Floor_Grab { 745 SCCP_Name presence; 746 SCCP_Name floor; 747 }; 749 struct SCCP_Floor_Inhibit { 750 SCCP_Name presence; 751 SCCP_Name floor; 752 }; 754 struct SCCP_Floor_Release { 755 SCCP_Name presence; 756 SCCP_Name floor; 757 }; 759 struct SCCP_Floor_Test { 760 SCCP_Name presence; 761 SCCP_Name floor; 762 }; 764 struct SCCP_Floor_Ask { 765 SCCP_Name presence; 766 SCCP_Name floor; 767 }; 769 struct SCCP_Floor_Give { 770 SCCP_Name presence_given; 771 SCCP_Name presence_giving; 772 SCCP_Name floor; 773 }; 775 struct SCCP_Floor_Given { 776 SCCP_Name presence_given; 777 SCCP_Name presence_giving; 778 SCCP_Name floor; 779 }; 781 struct SCCP_Floor_Holder { 782 SCCP_Name presence; 783 SCCP_Name floor; 784 }; 786 struct SCCP_Floor_Holder_Ask { 787 SCCP_Name presence; 788 SCCP_Name floor; 789 SCCP_NameList floor_holders; 790 }; 792 struct SCCP_Floor_Holder_List { 793 SCCP_Name presence; 794 SCCP_Name floor; 795 SCCP_NameList floor_holders; 796 }; 798 struct SCCP_Floor_Status { 799 SCCP_Object floor; 800 }; 802 struct SCCP_Floor_Error { 803 SCCP_Name presence; 804 SCCP_Name floor; 805 SCCP_Error error; 806 }; 808 union SCCP_Union switch (SCCP_Type type) { 810 case SCCP_T_JOIN: 811 SCCP_Join JOIN; 812 case SCCP_T_ACCEPT: 813 SCCP_Accept ACCEPT; 814 case SCCP_T_LEAVE: 815 SCCP_Leave LEAVE; 816 case SCCP_T_CONTEXT: 817 SCCP_Context_Msg CONTEXT; 819 case SCCP_T_ASCREATE: 820 SCCP_AS_Create AS_CREATE; 821 case SCCP_T_ASDELETE: 822 SCCP_AS_Delete AS_DELETE; 823 case SCCP_T_ASJOIN: 824 SCCP_AS_Join AS_JOIN; /* member, session */ 825 case SCCP_T_ASLEAVE: 826 SCCP_AS_Leave AS_LEAVE; /* member, session */ 828 case SCCP_T_FLOOR_GRAB: 829 SCCP_Floor_Grab FLOOR_GRAB; 830 case SCCP_T_FLOOR_INHIBIT: 831 SCCP_Floor_Inhibit FLOOR_INHIBIT; 832 case SCCP_T_FLOOR_RELEASE: 833 SCCP_Floor_Release FLOOR_RELEASE; 834 case SCCP_T_FLOOR_TEST: 835 SCCP_Floor_Test FLOOR_TEST; 836 case SCCP_T_FLOOR_ASK: 837 SCCP_Floor_Ask FLOOR_ASK; 838 case SCCP_T_FLOOR_GIVE: 839 SCCP_Floor_Give FLOOR_GIVE; 840 case SCCP_T_FLOOR_GIVEN: 841 SCCP_Floor_Given FLOOR_GIVEN; 843 case SCCP_T_FLOOR_HOLDER: 844 SCCP_Floor_Holder FLOOR_HOLDER; 845 case SCCP_T_FLOOR_HOLDER_ASK: 846 SCCP_Floor_Holder_Ask FLOOR_HOLDER_ASK; 847 case SCCP_T_FLOOR_HOLDER_LIST: 848 SCCP_Floor_Holder_List FLOOR_HOLDER_LIST; 849 case SCCP_T_FLOOR_STATUS: 850 SCCP_Floor_Status FLOOR_STATUS; 851 case SCCP_T_FLOOR_ERROR: 852 SCCP_Floor_Error FLOOR_ERROR; 853 }; 855 struct SCCP_Message { 856 SCCP_Header hdr; 857 SCCP_Union sccp_un<>; 858 }; 860 Full Copyright Statement 862 Copyright (C) The Internet Society (2001). All Rights Reserved. 864 This document and translations of it may be copied and furnished to 865 others, and derivative works that comment on or otherwise explain it 866 or assist in its implmentation may be prepared, copied, published 867 and distributed, in whole or in part, without restriction of any 868 kind, provided that the above copyright notice and this paragraph 869 are included on all such copies and derivative works. However, this 870 document itself may not be modified in any way, such as by removing 871 the copyright notice or references to the Internet Society or other 872 Internet organizations, except as needed for the purpose of 873 developing Internet standards in which case the procedures for 874 copyrights defined in the Internet Standards process must be 875 followed, or as required to translate it into languages other than 876 English. 878 The limited permissions granted above are perpetual and will not be 879 revoked by the Internet Society or its successors or assigns. 881 This document and the information contained herein is provided on an 882 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 883 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 884 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 885 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 886 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 888 Acknowledgement 890 Funding for the RFC editor function is currently provided by the 891 Internet Society.