idnits 2.17.1 draft-cordell-success-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 260: '... SET OF UserAddress OPTIONAL,...' RFC 2119 keyword, line 261: '... SET OF UserAddress OPTIONAL,...' RFC 2119 keyword, line 262: '...Ack SET OF UserAddress OPTIONAL,...' RFC 2119 keyword, line 263: '... respondTo NetAddress OPTIONAL,...' RFC 2119 keyword, line 264: '... INTEGER ( 1 .. 65535 ) OPTIONAL,...' (89 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 90 has weird spacing: '...ication indep...' == Line 350 has weird spacing: '... use is to de...' == Line 1005 has weird spacing: '...y' list does ...' == Line 1128 has weird spacing: '...message to al...' == Line 1168 has weird spacing: '...message to al...' == (1 more instance...) -- 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 (Nov 22, 1996) is 10015 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) No issues found here. Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Cordell 2 draft-cordell-success-00.txt BT 3 Nov 22, 1996 4 Expires: 22 May 1997 6 Simple Universal Call/Conference 7 Establishment Sequence - 8 (SUCCESS) 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 30 Currently in the Internet there are a number of call control 31 protocols, each of them tailored to their own special applications. 32 This includes SDP for session announcement, SIP and SCIP for 33 session invitation and Q.931 used in H.323. None of these is 34 likely to be turned into a generic call control protocol. Q.931 35 is limited to point-to-point calls. SDP and SIP do not include 36 close down phases which are important if calls are being charged 37 for on a timed basis or gateways are involved. Nor do they support 38 supplementary services such as transfer. This proposal addresses 39 these issues by defining a protocol based on a new conference control 40 paradigm (referred to as the hello-hello paradigm) that can be used 41 to create and control conferences from simple point-to-point calls, to 42 large `broadcasts' and all call models in between. Both real-time 43 peer-to-peer conversational models and client-server streaming models 44 are catered for in the protocol so that all forms of real-time stream 45 can feature in a conference. 47 Cordell [Page 1] 48 Table of Contents 49 Abstract................................................1 50 Table of Contents.......................................2 51 1. Introduction.........................................2 52 2. Overview.............................................4 53 3. Detailed Description.................................5 54 3.1. Messages..........................................5 55 3.2. Message Sub Types................................11 56 3.3. Event processing.................................19 57 3.4. Main Information.................................28 58 3.5. Timers...........................................30 59 4. Capabilities........................................30 60 5. Use of the Feature Message..........................32 61 6. Connecting to Stream Servers........................33 62 7. Message Encoding....................................34 63 8. Address of Author...................................40 64 References.............................................40 66 1. Introduction 67 This document describes a call setup procedure for use in 68 an Internet environment. It allows flexible call setup, 69 ranging from initiating a point-to-point call in a 70 tightly coupled fashion, to a multicast conference 71 announcement in a very loosely coupled fashion, and a 72 number of conference models in between. It has also been 73 designed with the intention of allowing gatewaying to 74 other communications networks to be easily facilitated. 75 The protocol operates over an unreliable datagram service 76 such as the Internet's UDP service. Reliability of the 77 protocol, when desired, is achieved by retransmission of 78 messages adopting an algorithm similar to that of RTCP to 79 select the retransmission interval. 81 The protocol is intended to amalgamate a number of the 82 features of the IETF SDP, SIP and SCIP protocols and the 83 ITU Q.931 protocol into a single unified Internet call 84 setup protocol. 86 During the design of this protocol the main goals have 87 been: 89 To develop an open standard for seamless end-to-end 90 multimedia communication independent of underlying 91 network boundaries and transport technology. i.e. the 92 protocol used in the Internet should translate cleanly 93 and easily into call setup protocols used for ISDN and 94 ATM. 96 Users should have a consistent set of network services 97 independent of the network providing the connection. 98 i.e. facilities like transfer and hold should be 99 supported (even if they are not implemented in a 100 specific product). 102 Cordell [Page 2] 103 The call setup protocol should enable the maximum 104 potential and flexibility of the Internet 105 infrastructure to be realised. Seamless migration 106 between the various call models should also be 107 supported directly at the protocol level. i.e. tightly 108 coupled and loosely coupled conferences should not be 109 explicitly differentiated at the protocol level, and 110 migration between these modes should be possible as the 111 conference evolves. 113 The inclusion of all media streams within a conference 114 should be at the control of the call control protocol 115 whether they be real-time conversational data, real- 116 time live feeds, or pre-stored server fed streams. 117 i.e. clients should invite and handle media streams 118 within a conference in the same way they handle all 119 other real-time feeds. 121 Support for capability negotiation should be supported, 122 even in large multicast conferences where possible, so 123 that systems will automatically select the best media 124 transport system available, thus allowing effective 125 exploitation of new and evolving coding technologies. 127 The protocol should be extensible for the purposes of 128 adding new features to the standard protocol, and 129 adding extensions for the purpose of evaluating new 130 features. This should be done where possible without 131 relying on a defined set of version numbers. 133 It has also been important to design a protocol that is 134 rich and descriptive, thus enabling terminal designs that 135 can enhance the user experience, but will at the same 136 time collapse down to a very simple sub-set by ignoring 137 certain fields that will allow basic terminals to be 138 developed as initial product offerings. 140 Note that throughout this document the terms call and 141 conference are used interchangeably. For the purposes of 142 this document, it is NOT necessarily implied from the 143 term call that the communication is point-to-point, and 144 it is NOT necessarily implied from the term conference 145 that the communication is multipoint. 147 Cordell [Page 3] 148 2. Overview 149 To be suitable for use when setting up both point-to- 150 point calls and multicast conferences the protocol 151 effectively announces that its associated endpoint is in 152 a call in the same way that a person uses `Hello' when 153 greeting another person. This approach differs to the 154 Request and Acknowledge call setup style used in some 155 protocols (which is equivalent to the `may I speak to 156 you/yes you may' paradigm), and the billboard style 157 advertisement used in other protocols (which is 158 equivalent to the `big show on Friday' paradigm). 160 To provide tighter control where required (such as in the 161 point-to-point case, or even for a small sub-set of a 162 large multicast) the messages have one or more fields 163 called Reply fields that allow them to specify who should 164 acknowledge the message. In a multicast `broadcast' from 165 a single point the Hello message might not contain a 166 Reply field. In a multicast conference that contains a 167 few core people, and then anybody else that wishes to 168 listen in, the message would contain a number of Reply 169 fields for each of the endpoints that had to be in the 170 conference before the conference was worth proceeding 171 with. 173 The protocol uses only five main message types. These 174 are introduced here with a brief description. They are 175 described further later on. 177 Hello Used both to initiate a call and answer a call. 178 Effectively it announces that an endpoint has 179 entered into a point-to-point call or a 180 multiparty conference. 182 Progress This message indicates the progress of a call 183 being setup. This is intended primarily to give 184 feedback to a user about the progress of call 185 setup and does not result in any state changes. 186 A number of progress message types exist, such as 187 ringing, performing address lookup, transferring 188 to POTS network etc. This message can be 189 generated by intermediate points if they are 190 involved in the call setup process. Feed back 191 from the Progress message allows the user and 192 application to know that the call/conference is 193 progressing, thus preventing a user waiting for 194 an answer from a terminal that is not switched 195 on. 197 Bye This message gives an endpoint the option to 198 signal that an it has left, or is leaving a 199 call/conference. 201 Cordell [Page 4] 202 Byebye Is sent to acknowledge a Bye from an endpoint. 203 The use of this is described further below. 205 Feature Used for additional signalling such as 206 transferring calls and putting people on hold. 207 The minimum support required for this message is 208 to identify when a message has been sent to you, 209 and respond with the notSupported element of the 210 message. Much of this processing is identical to 211 the other messages, and so this does not 212 represent a significant burden. The use of this 213 message is intended to be the place where extra 214 functionality is added into the protocol. The 215 idea is to have optional bolt-on 216 services/protocols into this message. One such 217 bolt-on that has already been specified is for 218 control of real-time streams supplied by servers. 220 The main elements of these messages as far as the 221 protocol is concerned are the 'from', 'to', 'reply', and 222 'replyAck' fields. The purpose of the first two should 223 be quite obvious. The third field indicates which 224 terminals should send a reply in response to the message 225 sent. A reply is indicated by putting the name of the 226 terminal that is being replied to in the replyAck field. 228 The main rules of the protocol are that if you receive a 229 Hello message with your endpoint mentioned in the Reply 230 field, you should send either a Progress message or a 231 Hello message with the name of the terminal you are 232 responding to indicated in the replyAck field and the 233 From field set. When a hello message is received with 234 your endpoint mentioned in the replyAck field, you should 235 send a Hello message that does not include the sender in 236 either the reply or replyAck fields. If you receive a 237 Bye message with your endpoint mentioned in the Reply 238 field, you should send a Byebye message with the From and 239 To fields set. Further description is included below to 240 show how these messages and rules can be used to setup 241 and cleardown conferences. 243 3. Detailed Description 244 The above outlines the principles of operation. This 245 section adds more detail. 247 3.1. Messages 248 This section indicates the sorts of fields that the 249 various messages contain. See the section on message 250 encoding to see how the messages are encoded on the line. 252 Cordell [Page 5] 253 Note that the most important fields are `cID`, `from`, 254 `to', `reply` and `replyAck`. 256 Hello ::= SEQUENCE 257 { 258 cID GUID, 259 from UserAddress, 260 to SET OF UserAddress OPTIONAL, 261 reply SET OF UserAddress OPTIONAL, 262 replyAck SET OF UserAddress OPTIONAL, 263 respondTo NetAddress OPTIONAL, 264 refreshX3 INTEGER ( 1 .. 65535 ) OPTIONAL, 265 description Text OPTIONAL, 266 display Text OPTIONAL, 267 time SET OF Time OPTIONAL, 268 userInfo SET OF UserAddress OPTIONAL, 269 capno INTEGER (0..65535 ) OPTIONAL, 270 caps SET OF Capability OPTIONAL, 271 sendno INTEGER (0..65535 ) OPTIONAL, 272 sending SET OF Property OPTIONAL, 273 ... 274 } 276 cID A unique number specifying the conference. 278 from A unique name specifying who the message is 279 from. This specifies the participant at the 280 protocol level. This information should remain 281 consistent throughout the conference. 283 to The primary intended recipient of the message. 284 Allows messages to be addressed to a sub-set of 285 the conference and for handling by proxy or 286 location service. 288 reply Who should reply to this message. If an 289 endpoint finds an alias for itself in this 290 list, it must respond with the specified alias 291 as opposed to another of its aliases. 293 replyAck Indicates the terminals to which a reply is 294 being sent in response to an earlier reply 295 message. 297 respondTo The address (possible multicast address) to 298 which all responses should be sent. This 299 allows a terminal to send an invitation to a 300 remote terminal using point-to-point 301 addressing, but have the remote terminal 302 respond to the messages to the conference 303 multicast address. 305 Cordell [Page 6] 306 refreshX3 Indicates the time in seconds by which a 307 minimum of three subsequent hello messages 308 should have been received. If one or more 309 hello messages (only one is required) have not 310 been received in this period, the receiver can 311 assume the session has ended. This allows a 312 receiver to know that a session has ended 313 without explicit notification. An interval of 314 three refreshes is specified to allow for lost 315 packets. 317 description Short description of the session. 319 display Information that might be presented to a remote 320 user about the state of this endpoint. 322 time When the session should take place. If this 323 field is not present, then the conference is 324 considered to be now. 326 userInfo Additional information about the person sending 327 the message. 329 capno Specifies the instance of caps set specified in 330 the caps part of the message. If the sender 331 modifies the data contained in the caps 332 section, then it should increment the value 333 contained in this field by 1. This is to 334 remove the need for the receiver to continually 335 parse the caps section looking for changes. 337 caps The set of capabilities that this terminal can 338 receive. 340 sendno Specifies the instance of sending parameter 341 specified in the sending part of the message. 342 If the sender modifies the data contained in 343 the sending section, then it should increment 344 the value contained in this field by 1. This 345 is to remove the need for the receiver to 346 continually parse the sending section looking 347 for changes. 349 sending Describes information about a stream. Its main 350 use is to describe the actual streams which 351 are being sent by a sender. 353 Cordell [Page 7] 354 Progress ::= SEQUENCE 355 { 356 cID GUID, 357 from UserAddress, 358 to SET OF UserAddress OPTIONAL, 359 phase ProgressPhase, 360 fromEndpoint BOOLEAN, 361 capno INTEGER (0..65535 ) OPTIONAL, 362 caps SET OF Capability OPTIONAL, 363 display Text OPTIONAL, 364 ... 365 } 367 cID A unique number specifying the conference. 369 from A unique name specifying who the message is 370 from. 372 to The primary intended recipient of the message. 374 phase Progress status code indicating things like 375 looking up address, ringing etc. 377 fromEndpoint Set to TRUE if message generated by t 379 capno Specifies the instance of caps set specified in 380 the caps part of the message. If the sender 381 modifies the data contained in the caps 382 section, then it should increment the value 383 contained in this field by 1. This is to 384 remove the need for the receiver to continually 385 parse the caps section looking for changes. 387 caps The set of capabilities that this terminal can 388 receive. By putting caps in the Progress 389 message it is possible to do decisions on the 390 conference caps used prior to the conference 391 starting. 393 display Information that might be presented to a remote 394 user about the state of this endpoint. 396 Bye ::= SEQUENCE 397 { 398 cID GUID, 399 from UserAddress, 400 to SET OF UserAddress OPTIONAL; 401 reply SET OF UserAddress OPTIONAL, 402 reason ByeReason OPTIONAL, 403 display Text OPTIONAL, 404 ... 405 } 407 Cordell [Page 8] 408 cID A unique number specifying the conference. 410 from A unique name specifying who the message is 411 from. 413 reply Who should reply to this message. 415 reason Why the connection was closed. These might 416 consist of: Normal, Busy, Unknown address, 417 Ambiguous address, Redirect, Alternative 418 service (see SIP), Join conference, No 419 resources, Unspecified, etc. 421 display Information that might be presented to a remote 422 user about the state of this endpoint. 424 Byebye ::= SEQUENCE 425 { 426 cID GUID, 427 from UserAddress, 428 to SET OF UserAddress, 429 display Text OPTIONAL, 430 ... 431 } 433 cID A unique number specifying the conference. 435 from A unique name specifying who the message is 436 from. 438 to The primary intended recipient of the message. 439 Indicates who the Byebye message is in response 440 to. 442 display Information that might be presented to a remote 443 user about the state of this endpoint. 445 Cordell [Page 9] 446 Feature ::= SEQUENCE 447 { 448 cID GUID, 449 from UserAddress, 450 to UserAddress OPTIONAL, 451 fID FeatureSeqNo, 452 mode CHOICE 453 { 454 reqAck ServiceType, 455 reqNoack ServiceType, 456 ack NULL, 457 querySupported ServiceList, 458 isSupported NULL, 459 notSupported NULL, 460 ... 461 }, 462 ... 463 } 465 cID A unique number specifying the conference. 467 from A unique name specifying who the message is 468 from. 470 to The primary intended recipient of the message. 472 reqAck Request a service that should be acknowledged 474 reqNoack Request a service that should not be 475 acknowledged 477 ack Acknowledges a feature. The FeatureSeqNo shall 478 correspond to the FeatureSeqNo set in the 479 request message. 481 querySupported Asks the remote end if a feature is s 482 message. 484 isSupported Sent in response to a querySupported 485 the request message. 487 notSupported Signals that a requested feature is n 488 correspond to the FeatureSeqNo set in the 489 request message. 491 3.2. Message Sub Types 493 -- The root message element 495 SUCCESSV1 ::= CHOICE 496 { 497 hello Hello, 498 progress Progress, 499 bye Bye, 500 byebye ByeBye, 501 feature Feature, 502 ... 503 } 505 GUID ::= OCTET STRING ( SIZE(16) ) 506 Text ::= BMPString( SIZE(0..511) ) 508 UserAddress ::= CHOICE 509 { 510 email Text, 511 locator Text, -- Name meaningful to 512 -- location service 513 system Text, 514 url Text, -- For identifying files on 515 -- servers 516 ipdotted Text, -- IP dotted notation 517 e164 SEQUENCE OF SEQUENCE 518 -- Allow multiple E.164 numbers per 519 -- single destination 520 { 521 extension Text, 522 remoteAddr Text OPTIONAL, 523 remoteSubAddr Text OPTIONAL 524 ... 525 }, 526 fax Text, 527 title Text, --e.g. `Director of BT Labs' 528 tag GUID, --machine assigned address 529 commonName Text, 530 role Role, 531 network NetAddress, 532 ... 533 } 535 Role ::= CHOICE 536 { 537 chairperson NULL, 538 secretary NULL, 539 speaker INTEGER(0..65535), 540 panel INTEGER(0..65535), 541 controller NULL, 542 ... 543 } 545 NetAddress ::= CHOICE 546 { 547 ip4 SEQUENCE 548 { 549 ip OCTET STRING ( SIZE(4) ), 550 port INTEGER( 0..65535 ) OPTIONAL, 551 ttl INTEGER( 0..255 ) OPTIONAL, 552 service CHOICE { UDP NULL, TCP NULL, ...} OPTIONAL, 553 route SEQUENCE OF OCTET STRING SIZE(4) OPTIONAL 554 -- for source routing 555 }, 556 ip6 SEQUENCE 557 { 558 ip OCTET STRING ( SIZE(16) ), 559 port INTEGER( 0..65535 ) OPTIONAL, 560 ttl INTEGER( 0..255 ) OPTIONAL, 561 service CHOICE { UDP NULL, TCP NULL, ...} OPTIONAL, 562 route SEQUENCE OF OCTET STRING SIZE(16) OPTIONAL 563 -- for source routing 564 }, 565 ... 566 } 568 ProgressPhase ::= CHOICE 569 { 570 locating NULL, --proxy of some description 571 --is locating user 572 placed NULL, --Users terminal has 573 --received call indication 574 ringing NULL, --User terminal is ringing 575 gatewaying NULL, --Transferring to POTS or 576 --ISDN 577 willattend NULL, --Signals that the user 578 --will attend a conference taking 579 --place in the future that they 580 --have been invited to attend 581 ... 582 } 584 ByeReason ::= CHOICE 585 { 586 normal NULL, 587 unauthorized NULL, 588 deferred NULL, -- Do not disturb 589 callback NULL, -- User will callback 590 -- when free 591 busy NULL, 592 feature NULL, -- Bye due to 593 -- signalled feature 594 unknown NULL, -- Person or file not known 595 ambiguous NULL, -- Address is incomplete 596 deflection SEQUENCE 597 { 598 cID GUID OPTIONAL, 599 user UserAddress, 600 conference BOOLEAN OPTIONAL, 601 display Text OPTIONAL, 602 ... 603 }, --must do re-routing end-less 604 --loop detection 605 noCaps NULL,-- No common capabilities 606 noLocation NULL, 607 noNetResources NULL, 608 noSysResources NULL, 609 ... 610 } 612 Time ::= SEQUENCE 613 { 614 first INTEGER(0..4294967295), --NTP seconds 615 --time of first showing 616 duration INTEGER(0..4294967295), 617 repeat SEQUENCE OF 618 { 619 delay INTEGER(0..429496795), --seconds 620 times INTEGER(0..255), --how many 621 --repeats 622 ... 623 } OPTIONAL, 624 ... 625 } 627 Capability ::= CHOICE 628 { 629 --Video modes 630 h261 H261, 631 h262 H262, 632 h263 H263, 634 --Audio modes 635 gsm AudioParameters, 636 g711Alaw AudioParameters, 637 g711Ulaw AudioParameters, 638 g722-64k AudioParameters, 639 g722-56k AudioParameters, 640 g722-48k AudioParameters, 641 g723 SEQUENCE 642 { 643 maxAI-sduAudioFrames INTEGER( 1..256 ), 644 silenceSuppression BOOLEAN, 645 address NetAddress, 646 setNum SET OF INTEGER(0..255), 647 payloadtype INTEGER( 0..127) OPTIONAL, 648 description Text OPTIONAL 649 }, 650 g728 AudioParameters, 651 g-dsvd AudioParameters, 653 --Data modes 654 t120 ControlParameters, 655 sccp ControlParameters, 657 --Control modes 658 h323 H323Parameters, 659 ... 660 } 662 AudioParameters ::= SEQUENCE 663 { 664 maxFPP INTEGER(1..2048), 665 --Max frames per packet 666 address NetAddress, 667 setNum SET OF INTEGER(0..255), 668 payloadtype INTEGER( 0..127) OPTIONAL, 669 ssrc INTEGER( 0..2^32-1 ) OPTIONAL, 670 -- Only used in sending field 671 description Text OPTIONAL, 672 ... 673 } 675 ControlParameters ::= SEQUENCE 676 { 677 address NetAddress, 678 setNum SET OF INTEGER(0..255) OPTIONAL, 679 ... 680 } 682 H323Parameters ::= SEQUENCE 683 { 684 crv INTEGER( 1..65535 ), 685 type EndpointType, -- See H.225 for definition 686 activeMC BOOLEAN, 687 conferenceGoal CHOICE 688 { 689 create NULL, 690 join NULL, 691 invite NULL, 692 ... 693 } OPTIONAL, 694 h245 NetAddress OPTIONAL, 695 ... 696 } 698 -- The encoding for the H.261, H.262 and H.263 modes are based on H.245 699 H261 ::= SEQUENCE 700 { 701 qcifMPI INTEGER( 1..4 ) OPTIONAL, 702 cifMPI INTEGER( 1..4 ) OPTIONAL, 703 maxBitRate INTEGER( 1..19200 ), 704 stillImage BOOLEAN, --H.261 Annex D 706 address NetAddress, 707 setNum SET OF INTEGER(0..255) OPTIONAL, 708 payloadtype INTEGER( 0..127) OPTIONAL, 709 ssrc INTEGER( 0..2^32-1 ) OPTIONAL, 710 -- Only used in sending field 711 description Text OPTIONAL, 712 ... 713 } 715 H262 ::= SEQUENCE --MPEG1 716 { 717 profileAndLevel-SPatML BOOLEAN, 718 profileAndLevel-MPatLL BOOLEAN, 719 profileAndLevel-MPatML BOOLEAN, 720 profileAndLevel-MPatH-14 BOOLEAN, 721 profileAndLevel-MPatHL BOOLEAN, 722 profileAndLevel-SNRatLL BOOLEAN, 723 profileAndLevel-SNRatML BOOLEAN, 724 profileAndLevel-SpatialatH-14 BOOLEAN, 725 profileAndLevel-HPatML BOOLEAN, 726 profileAndLevel-HPatH-14 BOOLEAN, 727 profileAndLevel-HPatHL BOOLEAN, 728 videoBitRate INTEGER (0.. 1073741823) 729 OPTIONAL, -- units 400 bits/sec 730 vbvBufferSize INTEGER (0.. 262143) 731 OPTIONAL, -- units 16384 bits 732 samplesPerLine INTEGER (0..16383) 733 OPTIONAL, -- units samples/line 734 linesPerFrame INTEGER (0..16383) 735 OPTIONAL, -- units lines/frame 736 framesPerSecond INTEGER (0..15) 737 OPTIONAL, -- frame_rate_code 738 luminanceSampleRate INTEGER (0..4294967295) 739 OPTIONAL, -- units samples/sec 741 address NetAddress, 742 setNum SET OF INTEGER(0..255) OPTIONAL, 743 payloadtype INTEGER( 0..127) OPTIONAL, 744 ssrc INTEGER( 0..2^32-1 ) OPTIONAL, 745 description Text OPTIONAL, 746 ... 747 } 749 H263 ::= SEQUENCE 750 { 751 sqcifMPI INTEGER (1..32) OPTIONAL, 752 -- units 1/29.97 Hz 753 qcifMPI INTEGER (1..32) OPTIONAL, 754 -- units 1/29.97 Hz 755 cifMPI INTEGER (1..32) OPTIONAL, 756 -- units 1/29.97 Hz 757 cif4MPI INTEGER (1..32) OPTIONAL, 758 -- units 1/29.97 Hz 759 cif16MPI INTEGER (1..32) OPTIONAL, 760 -- units 1/29.97 Hz 761 maxBitRate INTEGER (1..19200), 762 -- units 100 bits/s 763 unrestrictedVector BOOLEAN, 764 arithmeticCoding BOOLEAN, 765 advancedPrediction BOOLEAN, 766 pbFrames BOOLEAN, 767 hrd-B INTEGER (0..524287) OPTIONAL, 768 -- units 128 bits 769 bPPmaxKb INTEGER (0..65535) OPTIONAL, 770 -- units 1024 bits 772 address NetAddress, 773 setNum SET OF INTEGER(0..255) OPTIONAL, 774 payloadtype INTEGER( 0..127) OPTIONAL, 775 ssrc INTEGER( 0..2^32-1 ) OPTIONAL, 776 description Text OPTIONAL, 777 ... 778 } 780 FeatureSeqNo ::= INTEGER( 0..255 ) 782 ServiceList ::= CHOICE 783 { 784 call NULL, 785 authen NULL, 786 message NULL, 787 assignRole NULL, 788 rtsp NULL, 789 apps NULL, 790 ... 791 } 793 ServiceType ::= CHOICE 794 { 795 call CallControl, 796 authen Authentication, 797 message SEQUENCE OF Text, 798 assignRole Role, 799 rtsp NetAddress, 800 apps Appshare, 801 ... 802 } 804 CallControl ::= CHOICE 805 { 806 hold NULL, 807 holdack NULL, 808 holdrej NULL, 809 resume NULL, 810 resumeack NULL, 811 resumerej NULL, 812 transfer SEQUENCE 813 { 814 cID GUID OPTIONAL, 815 user UserAddress, 816 conference BOOLEAN OPTIONAL, 817 display Text OPTIONAL, 818 ... 819 }, 820 transferack NULL, 821 transferrej NULL, 822 ... 823 } 825 Authentication ::= CHOICE 826 { 827 challenge OCTET STRING SIZE( 0..64 ), 828 cresponse OCTET STRING SIZE ( 0..64 ), 829 ... 830 } 832 Appshare ::= CHOICE 833 { 834 reqList NULL, 835 list SET OF Application, 836 reqAddr Application, 837 addrAck NetAddress, 838 addrRej NULL, 839 ... 840 } 842 Application ::= CHOICE 843 { 844 t126 NULL, -- Example 845 word6.microsoft.com NULL, -- Example 846 notes.lotus.com NULL, -- Example 847 ... 848 } 850 Property ::= SEQUENCE 851 { 852 stream SET OF Capability, 853 title Text OPTIONAL, 854 director SET OF Text OPTIONAL, 855 producer SET OF Text OPTIONAL, 856 actor SET OF Text OPTIONAL, 857 actress SET OF Text OPTIONAL, 858 created Time OPTIONAL, 859 duration INTEGER( 0..2^32 ) OPTIONAL, 860 -- in milliseconds 861 fastfrwd INTEGER( 1..255 ) OPTIONAL, 862 -- Max fast frwd factor 863 rewind INTEGER( 1..255 ) OPTIONAL, 864 -- Max rewind factor, 865 pause BOOLEAN OPTIONAL, 866 nudgeFrwd BOOLEAN OPTIONAL, -- single frame advance 867 nudgeBack BOOLEAN OPTIONAL, -- single frame back 868 live BOOLEAN OPTIONAL, 869 indexable BOOLEAN OPTIONAL, 870 ... 871 } 873 3.3. Event processing 874 This section gives an example of the sequences that take 875 place for each of the main events. As mentioned above, 876 it is intended mainly for illustrative purposes. 878 For clarity, each event is presented in the form of C 879 style pseudo-code. Due to the detailed nature of this 880 description, its accuracy can not be guaranteed, and 881 it might change in future versions. 883 The principle of the pseudo-code is that in a conference 884 there a set of terminals that you want in the conference 885 and a set of terminals that want you in the conference. 886 As the conference evolves, this information is stored in 887 two lists, 'my-reply' and 'reply-to' respectively. As 888 much of this information is multicast, information can 889 also be obtained on other terminals in the conference 890 that you are not directly interested in. When Hello 891 messages are sent, you copy the contents of the my-reply 892 list to the message reply field, and the reply-to list to 893 the replyAck field. The message is then sent to the 894 super-set of the my-reply list and the reply-to list. 895 For these two lists, as you receive replys from the 896 specified endpoints, you remove them from the list 897 appropriately (see Hello pseudo code below). If you 898 receive a Hello message with your name in the reply then 899 you add the name of the sender to the reply-to list. 900 When the conference is stable, both lists should be 901 empty. The frequency with which Hello messages are sent 902 is controlled by two timers, Tfast and Tslow. Tfast is 903 used as the time base to generate hello messages when the 904 conference is undergoing a state change from the terminal 905 perspective, i.e. when either the 'my-reply' contains 906 entries marked as not progressing or the 'reply-to' lists 907 is not empty. Tslow is used as the generator of hello 908 messages when the conference is stable from the point of 909 view of the endpoint, or the use of the Tfast timer 910 doesn't seem to be progressing the conference state. 912 The result of this is that a three way handshake of Hello 913 messages is set up, that can be interrupted a Progress 914 message. Three stages are required (as opposed to two) 915 because on receiving a progress message (from the remote 916 user rather than an intermediary such as a proxy) the 917 invitor will switch to using a slower timer for 918 generating Hello messages. This does not allow for 919 suitable response when the remote user answers the call 920 as the Hello message generated in this instance may get 921 lost. If this were to happen, the invitor would not send 922 another Hello message inviting a response for many 923 seconds, hence the invitor would not know that the remote 924 user had entered the call. Therefore, rather than 925 waiting for another Hello message, the remote user takes 926 responsibility for ensuring that the invitor is aware 927 they are in the conference by repeatedly sending Hello 928 messages with the invitor indicated in the replyAck field 929 until the invitor responds by sending a Hello message 930 with the remote user absent from its reply list. Note 931 that it is important to switch to using the slower timer 932 when a Progress message is received as it may take a 933 remote user many minutes to answer a call, during which 934 time it is unacceptable to send multiple Hello messages 935 at a high repetition rate. 937 A third list ('interested-in') stores the total of the 938 'my-reply' list and 'reply-to' list. This is used to 939 copy to the 'my-reply' list when the conference is being 940 closed down, thus informing all those that invited you 941 and all those that you invited, that you are leaving the 942 conference. (N.B. in practice these lists would probably 943 be implemented as one list with a set of flags, but it's 944 easier to describe in this way). A final detail on top 945 of all this is whether the user is in or out of the 946 conference, whether they are listen-only, or whether they 947 have expressed an explicit desire to not be in the 948 conference (e.g. they were in, but have since left). 949 This generally affects how the reception of the hello and 950 bye messages are handled. 952 In addition to the two timer mentioned above, there are 953 two other timers, Trefresh and Tleaving. Tleaving 954 generates Bye messages when the conference is being 955 closed down. Its characteristics will probably be much 956 the same as Tfast (but will expire after N time-outs 957 rather than switching to Tslow). Trefresh is aimed at 958 picking up terminals that have silently left the 959 conference or failed. A field in the hello message 960 indicates the period over which the sender intends to 961 send 3 more hello messages. Trefresh is started, and all 962 endpoints in the 'active-endpoint' list are marked as 963 'not refreshed'. As each hello message comes in, the 964 endpoint that it is from is marked as refreshed. Also, a 965 variable collects the maximum value presented in any of 966 the hello messages refresh field during the refresh 967 period. When Trefresh expires, it goes through the 968 'interested-in' list and knocks out all the endpoints 969 that haven't refreshed thus assuming they have left the 970 conference. Trefresh is then restarted with the value 971 that has been calculated as the maximum refresh time. 973 Receive Hello: 974 ______________ 976 if( refresh time > auto refresh time ) 977 Update auto refresh time; 978 Update `active-endpoints' list and set endpoint 979 refreshed flag; 981 if( message directed to me or to all ) 982 { 983 if( User-mode is active or listening ) 984 { 985 // IF sender asking me to reply 986 if( I'm in `message-reply' list && sender not in 987 `reply-to' list ) 988 { 989 Add sender to `reply-to' list; // Hello will be 990 // sent later 991 Set User-mode to active; 992 } 994 // IF sender acknowledges my reply 995 if( sender in `reply-to' list && I'm not in 996 `message-reply' list ) 997 Remove sender from `reply-to' list; 999 // IF sender responds to my reply request 1000 if( sender in `my-reply' list ) 1001 Remove sender from `my-reply' list; 1003 if( User-mode is active ) 1004 { 1005 if( `my-reply' list does not contain any 1006 entries marked as not progressing && 1007 `reply-to' list is empty && 1008 I'm not in 'message-replyAck' list ) 1009 Ensure Tslow is running and Tfast is not; 1010 else 1011 Ensure Tfast is running and Tslow is not; 1012 } 1013 } 1015 else if( user not yet in conference ) 1016 { 1017 Inform user of conference; 1018 if( I'm in `message-reply' list ) 1019 { 1020 Add sender to `reply-to' list; 1021 Add sender to `interested-in' list; 1022 Progress message; 1023 } 1024 } 1026 else if( user indicated not interested in 1027 conference ) 1028 if( I'm in `message-reply' list ) 1029 Send Bye message with appropriate reason; 1030 } 1032 Receive Progress: 1033 _________________ 1035 Record state against terminal; 1036 Inform user conference state changed; 1037 if( message is from sender [as opposed to an 1038 intermediary] ) 1039 Mark sender as progressing in 'my-reply' list; 1041 Receive Bye: 1042 ____________ 1044 Remove endpoint from active-endpoints list; 1046 if( sender in `interested-in' list ) 1047 { 1048 Remove from `interested-in' list; 1049 if( sender in `my-reply' list ) 1050 { 1051 Remove sender from `my-reply' list; 1052 if( User-mode is active ) 1053 { 1054 if( reason specifies alternative address ) 1055 { 1056 Put new address in `interested-in' list; 1057 Put new address in `my-reply' list; 1058 if( Tslow is running ) 1059 Cancel Tslow timer; 1060 if( Tfast is not running ) 1061 Start Tfast and reset retransmission count; 1062 } 1063 } 1065 // ELSE allow for both endpoints to say bye at same time 1066 else if( User-mode is leaving ) 1067 { 1068 if( `my-reply' list empty ) 1069 { 1070 Inform user; 1071 Stop Tleaving; 1072 } 1073 } 1074 } 1075 } 1077 if( I'm in `message-reply' list ) 1078 Send ByeBye message; 1080 Receive ByeBye: 1081 _______________ 1083 if( message directed to me ) 1084 { 1085 Remove remote sender from `my-reply' list; 1086 if( `my-reply' list is empty ) 1087 { 1088 Inform user; 1089 Stop Tleaving; 1090 } 1091 } 1093 User initiates call: 1094 ____________________ 1096 Select conference ID; 1097 Put desired endpoints in `my-reply' list and mark as 1098 not progressing; 1099 Put desired endpoints in `interested-in' list; 1100 Send Hello message to all endpoints in 'interested-in' 1101 list copying 'my-reply' list to message 1102 'reply' field, and copying 'reply-to' 1103 list to message 'replyAck' field; 1104 Start Tfast and reset retransmission count; 1105 Set User-mode to active; 1107 User invites new endpoints: 1108 ___________________________ 1110 Put desired endpoints in `my-reply' list and mark as 1111 not progressing; 1112 Put desired endpoints in `interested-in' list; 1113 Send Hello message to all endpoints in 'interested-in' list 1114 copying 'my-reply' list to message 'reply' 1115 field, and copying 'reply-to' list to message 1116 'replyAck' field; 1117 if( Tslow is running ) 1118 Cancel Tslow timer; 1119 if( Tfast is not running ) 1120 Start Tfast and reset retransmission count; 1121 Set User-mode to active; 1123 User answers call: 1124 __________________ 1126 if( `reply-to' list is not empty ) 1127 { 1128 Send Hello message to all endpoints in 1129 'interested-in' list copying 'my-reply' 1130 list to message 'reply' field, and copying 1131 'reply-to' list to message 'replyAck' field; 1132 if( Tslow is running ) 1133 Cancel Tslow timer; 1134 if( Tfast is not running ) 1135 Start Tfast and reset retransmission count; 1136 Start auto refresh timer (Trefresh) and set next period 1137 time to zero; 1138 Set User-mode to active; 1139 } 1140 else 1141 Set User-mode to listening; 1143 User leaves call: 1144 _________________ 1146 Stop Tfast and Tslow; 1147 Copy `interested-in' list to `my-reply' list; 1148 if( `my-reply' list not empty ) 1149 { 1150 Send Bye message with Reply fields set and 1151 appropriate disconnect reason; 1152 Initiate Bye closing retransmission timer logic (Tleaving); 1153 Reset Bye closing retransmission count (Nleaving); 1154 } 1155 else 1156 { 1157 if( it is desired to signal this endpoint leaving conference ) 1158 Send Bye with Reply list empty and appropriate 1159 disconnect reason; 1160 } 1162 Timer Tfast times out: 1163 ______________________ 1165 Decrement fast retransmission count (Nfast); 1166 if( retransmission count is not zero ) 1167 { 1168 Send Hello message to all endpoints in 'interested-in' 1169 list copying 'my-reply' list to message 1170 'reply' field, and copying 'reply-to' 1171 list to message 'replyAck' field; 1172 if( `my-reply' list does not contain any entries 1173 marked as not progressing && `reply-to' 1174 list is empty && 1175 I'm not in 'message-replyAck' list ) 1176 Ensure Tslow is running and Tfast is not; 1177 else 1178 Ensure Tfast is running and Tslow is not; 1179 } 1180 else 1181 { // Call is failing to progress 1182 if( `active-endpoints' list is not empty ) 1183 Start TSlow; 1184 else 1185 { 1186 Inform user; 1187 Send Bye message with empty Reply list; 1188 } 1189 } 1191 Timer Tslow times out: 1192 ______________________ 1194 Send Hello message to all endpoints in 'interested-in' 1195 list copying 'my-reply' list to message 1196 'reply' field, and copying 'reply-to' list 1197 to message 'replyAck' field; 1198 Re-evaluate and restart Tslow; 1200 Timer Tleaving times out: 1201 _________________________ 1203 if( `my-reply' list is not empty ) 1204 { 1205 Send Bye message with Reply list; 1206 Decrement re-transmission count: 1207 if( retransmission count is not zero ) 1208 Re-evaluate and restart Tleaving; 1209 else 1210 inform user; 1211 } 1212 else 1213 Inform user; 1215 Timer Trefresh times out: 1216 _________________________ 1218 Remove items from `interested-in' list, `my-reply' 1219 list and `reply-to' list that have 1220 not been marked as refreshed; 1221 if( next period refresh time is not zero ) 1222 { 1223 Re-start Trefresh; 1224 Clear next period refresh count to zero; 1225 } 1227 3.4. Main Information 1229 3.4.1. Per conference information: 1231 User-mode Whether the user is not in conference, only 1232 listening to the conference, actively involved 1233 in the conference, or not interested in the 1234 conference. 1235 interested-in Stores the list of endpoints that that this endpoint 1236 list has either replied to or asked for replys from during 1237 the conference. 1238 my-reply list Implemented as part of interested-in list. Stores the 1239 list of endpoints this endpoint wants to receive a 1240 reply from. 1241 reply-to list Implemented as part of interested-in list. Stores the 1242 list of endpoints this endpoint should reply to. 1243 endpoint-list List of all the terminals in the conference, or as many 1244 as the application is prepared to store. 1245 Mcast-Address The call control session multicast address. This may not 1246 be used in some circumstances. 1248 3.4.2. Information stored per endpoint in the interested- 1249 in list: 1251 Quantity Type Description 1252 -------- ---- ----------- 1253 name String and The name of the endpoint. 1254 type 1255 my-reply Flag Indicates whether this endpoint 1256 wants a reply from the remote 1257 endpoint 1258 reply-to Flag Indicates whether this endpoint 1259 should send a reply to the remote 1260 endpoint 1261 progressing Flag Set to FALSE when an 1262 endpoint is initially invited to a 1263 call. When a Progress or Hello 1264 message is received from the 1265 endpoint, the flag is set to TRUE. 1266 refreshed Flag Indicates whether the remote 1267 endpoint has sent a new Hello 1268 message within the refresh period 1269 address IP Addr/Port The address and port to send 1270 messages to the remote endpoint. 1271 Maybe a unicast or multicast address 1272 depending on the conference phase 1273 and type 1274 go-mcast Flag If True, indicates that if a 1275 terminal was invited to a conference 1276 using unicast, it should be 1277 signalled to use the conference 1278 multicast address. When a reply 1279 from the endpoint has been received 1280 on the conference multicast address, 1281 the address field above will be 1282 changed to the conference multicast 1283 address. 1284 last-cap-no Integer The number of the last 1285 capability set sent by the terminal. 1286 last-send-no Integer The number of the last send 1287 no set by the sender. 1289 3.5. Timers 1290 The protocol defines a numbers of timers. These are 1291 described here. 1293 Timer value Repeats Description 1294 ----------- ------- ----------- 1295 Tfast Nfast Used as the time base to generate Hello 1296 messages when the endpoint is changing 1297 its membership lists 1298 Tslow Infinite Used as the time base to generate Hello 1299 messages when the endpoint has a stable 1300 membership list 1301 Tleaving Nleaving Used as a timebase to generate Bye messages 1302 when an endpoint is leaving a conference 1303 Trefresh Infinite Used to detect endpoints that have silently 1304 left a conference 1306 4. Capabilities 1307 The capabilities in the hello message allows the sender 1308 of the message to specify media that the receiving 1309 endpoints can transmit. In addition to standard audio, 1310 video, and data capabilities, control capabilities are 1311 defined. This allows a protocol to be used on top of 1312 this protocol for setting up media streams such as H.323, 1313 SCCP and T.120. 1315 Capabilities do not need to be present in every Hello 1316 message sent. If they are not present the previously 1317 specified capabilities are taken to be still valid. If 1318 one or more capabilities are changed, then a complete set 1319 of capabilities needs to be specified, thus overwriting 1320 the previous set. When the capability set is changed the 1321 sender should increment the capno parameter sent in the 1322 hello message to let the receiver know that a change has 1323 been made without the receiver having to parse the whole 1324 message. 1326 When defining the set of capabilities that can be 1327 received, each declared capability is assigned to one or 1328 more 'sets'. These sets are numbered zero to 255. A 1329 maximum of one mode can be active from a given set at any 1330 one time. Thus, if GSM and G.723 are assigned to the 1331 same set, only one of them can be active at a time. If 1332 G.723 is defined in two sets, then two G.723 streams can 1333 be used simultaneously perhaps with different languages. 1334 This is thought to be the simplest mechanism possible 1335 that allows multiple options to be specified for multiple 1336 streams of the same media type. To specify more 1337 complicated capability sets, higher layer protocols such 1338 as SCCP, H.245, or T.120 should be used. 1340 The method of defining proprietry extensions defined under 1341 the Use of the Feature Message can also be used to define 1342 proprietry codecs in the capability sets. 1344 Note that when inviting a new terminal into a conference 1345 (i.e. when the hello message specifies a reply), the 1346 capabilities expressed should be that of the inviting 1347 terminals view of the conferences aggregated common 1348 capabilities and not solely those of the inviting 1349 terminal. 1351 It is recommended that a mandatory set of base 1352 capabilities be defined that must be supported by all 1353 terminals. This will ensure that there will always be 1354 some degree of compatibility. An example is G.723, and 1355 if video is present, QCIF H.261. This base set would 1356 allow effective use over dial-up modem links. 1358 This scheme works well for point-to-point cases and for 1359 large multicasts where negotiation is not allowed or not 1360 possible. However, it is desirable to extend the scheme 1361 such that effective mode negotiation can take place for 1362 at least a dozen terminals. This requires further work. 1363 Currently negotiation is looked upon as a two stage 1364 process; finding the common capabilities and then 1365 deciding which capabilities to use within that set. Over 1366 time it should be possible to establish the common 1367 capabilities of the terminals in the conference using a 1368 logical ANDing process of all the capabilities received. 1369 Deciding which mode to use of the resulting set seems 1370 more problematic as a consistent notion of which mode is 1371 the best of the ones available needs to be established 1372 between all of the members in the conference. For video 1373 algorithms this may be a relatively straight forward 1374 process, but for audio this may vary depending on the 1375 application environment and personal preference. One 1376 possibility might be to employ the observation that in 1377 general, only one person will be talking at the same 1378 time. Also each RTP packet is tagged with the coding 1379 mode. By loading all the common decoders in use in the 1380 conference into system memory a terminal may be able to 1381 select the appropriate decoder as each audio packet 1382 arrives. This will require a larger memory foot print, 1383 but should not require extra processing power. To 1384 simplify this situation, new speakers may be able to 1385 implement heuristics such as using the coding algorithm 1386 of the previous speaker. 1388 5. Use of the Feature Message 1389 The Feature message is used for additional signalling 1390 such as transferring calls and putting people on hold. 1391 The minimum support required for this message is to 1392 identify when a message has been sent to you, and to 1393 respond with the notSupported form of the message. Much 1394 of this processing is identical to the other messages, 1395 and so this does not represent a significant burden. 1397 This message is intended to be the mechanism by which the 1398 protocol is extended. The concept is to have optional 1399 services/protocols that bolt-on to the message. Bolt-on 1400 services have already been specified for call transfer 1401 and control of real-time streams supplied by servers. 1403 It is expected that software modules providing services 1404 to the call control protocol will register with the 1405 feature handling components in the core layer. When a 1406 service wants to send a message, it will tell the feature 1407 handler to do so. The feature handler will keep 1408 retransmitting the feature message until it gets an ack 1409 back from the remote feature handler, or a not supported 1410 indication. The feature handler will then tell the 1411 service that the message has been sent. At the receive 1412 side, the feature handler will extract the service for 1413 who the message is intended. If a service of that type 1414 has been registered, then the message will be sent to 1415 that service and an acknowledgement will be sent. If no 1416 service of the specified name is registered, then a 1417 notSupported message will be returned. The 1418 querySupported form of the message is supported in a 1419 similar way. 1421 Proprietary extensions to the protocol should also be 1422 made using the feature message. To ensure that 1423 proprietary extensions do not overlap with those from 1424 different vendors or future standardised messages, they 1425 should use the naming convention of: 1427 . 1429 For example: 1431 myService.products.mycompany.com 1433 The entire string should not exceed 255 characters in 1434 length. 1436 6. Connecting to Stream Servers 1437 Accessing different kinds of media within a conference in 1438 a consistent way is an important issue for call control 1439 as it simplifies the client code, but also makes the user 1440 experience more consistent. This should also apply to 1441 material introduced into a conference which is pre-stored 1442 on servers. This is especially the case if a remote user 1443 is invited to a conference who is away from their machine 1444 and has left a pre-recorded message. 1446 Equally important is, if a server is introduced into a 1447 conference, a mechanism for making full use of the server 1448 features should be available. Extending the protocol to 1449 include a full set of media control options is not 1450 desirable, but a number of possibilities are available 1451 within the framework of SUCCESS for achieving this. The 1452 method chosen here is to make use of the feature message. 1453 Assuming that the server supports RTSP or a similar 1454 protocol, the resulting sequence of events would occur. 1456 The user invites the server to the conference using the 1457 standard Hello message handshakes. When the server is in 1458 the conference, it sends a feature message to the user's 1459 client indicating that it supports RTSP, and what the 1460 appropriate address is. 1462 If the user client does not have an RTSP feature 1463 registered, then the client will send back a feature 1464 notSupported message. This tells the server that RTSP 1465 control is not available. In this instance the server 1466 should proceed to play it's pre-stored material, and then 1467 exit the conference using the Bye sequence. 1469 If the user client has registered an RTSP feature 1470 controller with the SUCCESS layer, then the client will 1471 acknowledge the feature message and pass the contents of 1472 the incoming RTSP feature message to the RTSP control 1473 mechanism. This event could be used to launch the 1474 display of a set of VCR style control buttons on the user 1475 display. The client would connect to the server 1476 specified address and issue appropriate server control 1477 messages such as HELLO and PLAY_RANGE. When the client 1478 had finished with the server it would send the GOODBYE 1479 message. At this point the server should send the 1480 SUCCESS Bye message indicating that it is leaving the 1481 conference. 1483 Using this strategy facilitates a consistent user 1484 experience, but also allows the maximum flexibility of 1485 the invited streams to be exploited. 1487 7. Message Encoding 1488 SD is described using a limited set of tokens which are 1489 intended not to be extensible. Hence, its impossible to 1490 describe SUCCESS as a set of extensions to SD as is 1491 perhaps desirable. 1493 Although the protocol described above is orthogonal to 1494 the underlying message transportation mechanism, some 1495 thoughts on message encoding are perhaps justified. An 1496 important consideration is that the message set should be 1497 extensible over time, with older terminals simply 1498 ignoring fields they do not understand. As new message 1499 elements are introduced they will likely contain multiple 1500 associated pieces of information. An efficient way of 1501 grouping these is important so that an entire message 1502 element can be ignored if required. Hence some concept 1503 of structure in messages is required.. 1505 ASN.1 is now the method of choice for encoding messages 1506 in ITU standards. The benefits of ASN.1 is that it 1507 describes messages in a powerful expressive high level 1508 way. It is similar to writing code in Pascal or C as 1509 opposed to Assembler. The downside is that it typically 1510 requires the use of a compiler to compile the messages 1511 into a rather esoteric line format. 1513 The IETF community have a preference for encoding 1514 messages in ASCII (or equivalent). This is partly 1515 because it easily solves the problem of data 1516 representation when moving from machine to machine (ASN.1 1517 also does this), and because it allows the data to be 1518 generated and read by humans. 1520 Observing that it is unlikely that the ITU will want to 1521 depart from using ASN.1 and the IETF would still like to 1522 maintain a line format which is ASCII based, and there is 1523 mutual benefit from the two bodies defining standards 1524 that (if not the same) are interworkable, this section 1525 describes a mechanism for compiling ASN.1 messages into 1526 ASCII text. 1528 The benefits of this would be that a common method of 1529 expressing high level messages could be adopted, and 1530 interworking between the standards would be trivial. 1532 The first requirement to providing a simplified ASCII 1533 encoding is to select a sub-set of the total ASN.1 1534 capabilities. To this end, the following keywords have 1535 been selected. All other keywords are ignored. 1537 INTEGER OCTET IA5String BMPString 1538 STRING SIZE SEQUENCE OF SET OF 1539 SEQUENCE CHOICE BOOLEAN NULL 1540 OPTIONAL 1542 Subset of ASN.1 keywords 1543 ________________________ 1545 To demonstrate the scheme an example is given. 1547 A typical definition for an (complicated) ASN.1 message 1548 may look as follows: 1550 startup ::= SEQUENCE 1551 { 1552 sequence_no INTEGER( 1..65536 ), 1553 name IA5String( SIZE( 0..128 ) ), 1554 gUID OCTET STRING ( SIZE( 16 ) ), 1555 activated BOOLEAN 1556 modes SEQUENCE 1557 { 1558 highmodeBOOLEAN, 1559 lowmode BOOLEAN, 1560 ... 1561 }, 1562 response CHOICE 1563 { 1564 acknowledge NULL, -- NULL indicates no further data 1565 silent NULL, 1566 informGroup INTEGER( 0..65536 ), -- Address to send 1567 --group response to 1568 ... 1569 }, 1570 id INTEGER( 1..256 ) OPTIONAL, 1571 node_alerts SEQUENCE OF INTEGER( 0..65535 ), 1572 complex SEQUENCE OF SEQUENCE 1573 { 1574 admin_node INTEGER( 0..256 ), 1575 user_id INTEGER( 0..256 ), 1576 mode SEQUENCE 1577 { 1578 video BOOLEAN, 1579 audio BOOLEAN, 1580 data BOOLEAN, 1581 ... 1582 } OPTIONAL, 1583 ... 1584 } 1585 ... 1586 } 1587 From this it can be seen that there are some basic types 1588 including: INTEGER, IA5String, OCTET STRING and BOOLEAN. 1590 There are also two `complex' structures, these being 1591 SEQUENCE and CHOICE. A SEQUENCE is similar to a 1592 structure (struct) in C and a CHOICE is similar to a 1593 union (however, the chosen option in the CHOICE is also 1594 recorded, which is not the case for a C union). 1596 A final consideration is that you can have a SEQUENCE OF 1597 or SET OF the above types, and elements can be OPTIONAL. 1599 In a SEQUENCE OF or SET OF construct there can be more 1600 than one of the specified component. The number of items 1601 may be constrained or unconstrained. 1603 Elements that are marked OPTIONAL can be absent in a 1604 correctly formed message. All other elements must be 1605 present for the message to be valid. 1607 Now lets consider how these can be represented in 1608 Unicode. 1610 The basic mechanism is to encode all items as: 1612 = 1615 By doing this consistently, parsers can skip fields they 1616 don't understand. 1618 Therefore the INTEGER can simply be represented as a 1619 printable string of the number, (the range of the number 1620 is not so important to the line format when represented 1621 in this way. However, the number range is probably 1622 important to the application.) e.g. 1624 sequence_no = 125 1626 An IA5String can be represented as a string in quotes, 1627 e.g. 1629 name = "Pete" 1631 ... the usual back slash escapes can also be included. 1633 OCTET STRINGs are represented using the following 1634 representation: 1636 gUID = x0f1b6c0d 1638 ...here, each OCTET is coded as two hexadecimal digits. 1639 The leading x indicates that this is in OCTET 1640 representation. 1642 Booleans can be coded simply as TRUE and FALSE, as in: 1644 activated = TRUE 1646 The SEQUENCE can be coded by including the elements of 1647 the sequence in brackets (), for example: 1649 modes = ( highmode = TRUE lowmode = FALSE ) 1651 ...doing this allows the complete sequence to be skipped 1652 if the parameter is not understood, or it is of no 1653 interest. This is important for backwards compatibility. 1654 (N.B. the ellipsis are important for coding messages 1655 using the ITU method, but they have no significance for 1656 this coding method. However, to ensure compatibility, 1657 they should be included in the message definition where 1658 appropriate.) Also note that the complete message is 1659 itself a SEQUENCE. This explains the example of the 1660 complete message shown below. 1662 A CHOICE can be encoded using a similar scheme to the 1663 SEQUENCE, as in: 1665 response = ( acknowledge = NULL ) 1667 ... or: 1669 response = ( informGroup = 137 ) 1671 ... many choice options map to NULL, (an example of which 1672 is shown above) which is inefficient in terms of 1673 characters sent and tedious to write by hand. 1674 Conversely, this presents little problem to a program 1675 scanning and generating the text as it consistently 1676 maintains the X=Y format. However, on the whole a 1677 shorthand notation for the above of: 1679 response = ( acknowledge ) 1681 ... seems preferable. Note that the brackets are still 1682 important as this highlights that acknowledge comes from 1683 a CHOICE statement. An implementation should recognise 1684 both formats. 1686 The OPTIONAL items is either present or not present. 1687 Unfortunately an example makes no sense. 1689 When multiple items of the same type are included in a 1690 message using the SEQUENCE OF or SET OF encoding, this 1691 can be done simply by including the item multiple times, 1692 as in: 1694 node_alerts = 0 node_alerts = 5000 node_alerts = 12 1696 ... this is quite wasteful in terms of characters, and so 1697 the following compacted encoding could be used: 1699 node_alerts = 0 = 5000 = 12 1701 ... the rule that allows this is that if you get the = 1702 token when you expected to receive an item name, you 1703 should use the most recently collected item name, subject 1704 to the level of parenthesis. 1706 As a final, complicated example, the `complex' component 1707 shown above can be encoded as: 1709 complex = ( admin_node = 20 1710 user_id = 6 1711 mode = ( video = TRUE audio = TRUE data = FALSE ) 1712 ) 1714 = ( admin_node = 5 1715 user_id = 5 1716 ) 1718 To sum up, a complete example of the message would be: 1720 startup = ( 1721 sequence_no = 125 1722 name = "Pete" 1723 gUID = x0f1b6c0d 1724 activated = TRUE 1725 modes = ( highmode = TRUE lowmode = FALSE ) 1726 response = ( informGroup = 137 ) 1727 id = 12 1728 node_alerts = 0 = 5000 = 12 1729 complex = ( 1730 admin_node = 20 1731 user_id = 6 1732 mode = ( video = TRUE audio = TRUE data = FALSE ) 1733 ) 1734 = ( 1735 admin_node = 5 1736 user_id = 5 1737 ) 1738 ) 1740 Note that because each element is tagged, there order is 1741 not important. Therefore, the above message could 1742 equally be represented as: 1744 startup = ( 1745 name = "Pete" 1746 activated = TRUE 1747 node_alerts = 0 1748 sequence_no = 125 1749 modes = ( highmode = TRUE lowmode = FALSE ) 1750 id = 12 1751 node_alerts = 5000 = 12 1752 complex = ( 1753 admin_node = 20 1754 user_id = 6 1755 mode = ( video = TRUE audio = TRUE data = FALSE ) 1756 ) 1757 response = ( informGroup = 137 ) 1758 complex = ( 1759 admin_node = 5 1760 user_id = 5 1761 ) 1762 gUID = x0f1b6c0d // We can have comments too 1763 ) 1765 A final comment is that message definitions rarely map 1766 directly to the base (INTEGER, OCTET) types. I.e. the 1767 definition above might be encoded as: 1769 startup ::= SEQUENCE 1770 { 1771 sequence_no Seq_no, 1772 name IA5String(SIZE(0..128)), 1773 gUID conference_ID, 1774 activated BOOLEAN, 1775 modes Modes, 1776 . 1777 . 1778 . 1780 elsewhere the following definitions would appear: 1782 Seq_no INTEGER(1..65536), 1783 conference_ID ::= OCTET STRING (SIZE(16)), 1784 Modes ::= SEQUENCE 1785 { 1786 highmode BOOLEAN, 1787 lowmode BOOLEAN, 1788 ... 1789 } 1791 This is a better way to do the message definition, for 1792 all the reasons that you would do the same in any piece 1793 of software. The coding method is not affected by this 1794 as it is a process of macro expansion to get to the 1795 message definition we started with. 1797 8. Address of Author 1799 Peter Cordell 1800 BT Labs 1801 MLB 4/40 1802 Martlesham Heath 1803 Ipswich IP5 7RE 1804 e-mail: pete.cordell@bt-sys.bt.co.uk 1806 References 1808 This document has drawn heavily on the following sources: 1810 SDP M. Handley, V. Jacobson "SDP: Session Description Protocol" 1811 Internet Draft, draft-ietf-mmusic-sdp-02.txt, Work in Progress, 1812 Feb 1996. 1814 SIP M. Handley, E. Schooler "SIP: Session Invitation Protocol" 1815 Internet draft, draft-ietf-mmusic-sip-01.txt, June 1996 1817 SCIP H. Schulzrinne, "Simple Conference Invitation Protocol", 1818 Internet draft, draft-ietf-mmusic-scip-00.txt, Feb 1996 1820 H.245 ITU-T, "Control Protocol for Multimedia Communication" Nov 1995 1822 H.225 ITU-T, "Media Stream Packetisation and Synchronisation on Non- 1823 Guarenteed Quality of Service LANs", May 1996 1825 X.680 ITU-T, "Abstract Syntax Notation One (ASN.1): Specification of 1826 Basic Notation", July 1994 1828 To Do 1829 Add scenarios. 1830 Check centralised control such as used in call centres. 1831 Write text on how the e164 address field should be used. 1832 Re-visit how properties of streams are transmitted. 1833 Re-visit gateway connectivity now that new pseudo-code 1834 has been put in.