28 May, 1996SOURCE : SG15 Plenary May 28, 1966TITLE :Draft Recommendation : VISUAL TELEPHONE SYSTEMS ANDEQUIPMENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEEDQUALITY OF SERVICEThis document reflects changes to COM15-245 () approved by the May 28 Plenary ofSG15. It is the final master for the decided . It has no change marks. The file name . This document results from the application of the changes in the to the white document COM15-245 to produce the change marked . When the changes are accepted the result is 23:271
INTERNATIONAL TELECOMMUNICATION 28, 1996STANDARDIZATION SECTOR D e c i d ed May 28, 1996OF ITULINE TRANSMISSION OF NON-TELEPHONESIGNALSVISUAL TELEPHONE SYSTEMS AND EQUIPMENT FORLOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICEDRAFT ITU-T Recommendation
Page iDecided , 28 May 1996FOREWORDThe ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the International Tele-communication Union. The ITU-T is responsible for studying technical, operatingf aqnude staiornifs andissuing Recommendations on them with a view to standardizing telecommunications on a worldwide World Telecommunication Standardization Conference (WTSC), which meets every four years,established the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendationson these -T Recommendation was prepared by the ITU-T Study Group 15 (199x-199x) and was approvedby the WTSC (Place, Month xx-xx, 199x).___________________ ITU 199xAll rights reserved. No part of this publication may be reproduced or utilized in any form or by any means,electronic or mechanical, including photocopying and microfilm, without permission in writing from the 23:27i
Page iiDecided , 28 May 1996SUMMARYRecommendation describes terminals, equipment, and services for multimedia communication overLocal Area Networks (LAN) which do not provide a guaranteed Quality of Service. terminals andequipment may carry real-time voice, data, and video, or any combination, including LAN over which terminals communicate, may be a single segment or ring, or it may be multiplesegments with complex topologies. It should be noted that operation of terminals over the multipleLAN segments (including the Internet) may result in poor performance. The possible means by which qualityof service might be assured on such types of LANs/internetworks is beyond the scope of terminals may be integrated into personal computers or implemented in stand-alone devices such asvideotelephones. Support for voice is mandatory, while data and video are optional, but if supported, theability to use a specified common mode of operation is required, so that all terminals supporting that mediatype can interwork. allows more than one channel of each type to be in use. OtherRecommendations in the series include packet and synchronization, control, video codecs, , , , , and audio codecs, and the series ofmultimedia communications makes use of the logical channel signalling procedures of Recommendation , in which thecontent of each logical channel is described when the channel is opened. Procedures are provided forexpression of receiver and transmitter capabilities, so transmissions are limited to what receivers candecode, and so that receivers may request a particular desired mode from transmitters. Since theprocedures of are also used by Recommendation for ATM networks, Recommendation GSTN, and , interworking with these systems should not require to translation as wouldbe the case for terminals may be used in multipoint configurations, and may interwork with terminals on B-ISDN, terminals on N-ISDN, terminals on B-ISDN, terminals on Guaranteed Quality ofService LANs, terminals on GSTN and wireless networks, and terminals on 23:27ii
Page iiiDecided , 28 May 1996Table of ContentsSUMMARY...........................................................................................................................ii1 SCOPE..............................................................................................................................12 NORMATIVE REFERENCES............................................................................................23 DEFINITIONS....................................................................................................................44 SYMBOLS AND ABBREVIATIONS..................................................................................85 CONVENTIONS................................................................................................................96 SYSTEM DESCRIPTION................................................................................................. Information Streams........................................................................................................................................ Terminal Characteristics................................................................................................................................ Terminal elements outside the .. .o..f. .H....3..2..3.........................................................................1..1... Terminal elements within the scope.. .o..f. .H....3..2..3..........................................................................1..2.... LAN Interfa..........................................................................................................................................1.. Video ..c.......................................................................................................................................... Terminal Based Continuous P....s....c..e...................................................................................1..3.. Audio ..c.......................................................................................................................................... Audio ..g.................................................................................................................................1.. Maximum Audio-Video .. .S....w................................................................................1..4.... Receive Path ....y.............................................................................................................................1.. Data Chan..n.........................................................................................................................................1.. Data Chan..n..e.................................................................................................................1..5... Control Func....n..................................................................................................................1..6.... Capabilities ..n..g..e..............................................................................................................1..7... Logical channel ....g.........................................................................................................1.. Mode ..c..e..s.....................................................................................................................1..9... Master Slave ..a....n.....................................................................................................1.. Timer and counter .....e..s........................................................................................................2..0.. RAS Signalling ..io..n..................................................................................................................2..0... Call Signalling ..n................................................................................................................2..1... ..e..r....................................................................................................................................2.. Logical channel num...b..e..........................................................................................................2.. Logical Channel Bitrate .L..................................................................................................... Gateway Characteristics................................................................................................................................. Gatekeeper Characteristics............................................................................................................................. Multipoint Controller Characteristics............................................................................................................259/21/98 23:27iii
Page ivDecided , 28 May Multipoint Processor Characteristics............................................................................................................. Multipoint Control Unit Characteristics........................................................................................................ Multipoint Capability...................................................................................................................................... Centralized Multipoint ..b...................................................................................................... Decentralized Multipoint Cap..a..................................................................................................2.. Hybrid Multipoint - Centralized. .A..u..d............................................................................................... Hybrid Multipoint - Centralized.. .V....o.............................................................................................. Establishment of Common.. .M..o..d..e....................................................................................................2.. Multipoint rate ....g................................................................................................................2..9... Multipoint Lip Synchroniz....io..n........................................................................................................2.. Multipoint ..n.....................................................................................................................3..0.... Cascading Multipoint . .U..n..................................................................................................3..07 CALL SIGNALLING........................................................................................................ Addresses......................................................................................................................................................... LAN ..s.........................................................................................................................................3.. TSAP ..r...................................................................................................................................... Alias Addre..........................................................................................................................................3.. Registration, Admissions, and Status (RAS) Channel.................................................................................... Gatekeeper Disco..v....y.....................................................................................................................3..1... Endpoint Registra....n......................................................................................................................3..2... Endpoint ..n...............................................................................................................................3.. Admissions, Bandwidth Change, Status, .D....e....a..g..e.................................................................3..4.. Call Signalling Channel................................................................................................................................... Call Signalling Channel Ro..u....g.....................................................................................................3.. Control Channel ....g................................................................................................................3..6... Call Reference Value....................................................................................................................................... Conference ID and Conference Goal..............................................................................................................378. CALL SIGNALLING PROCEDURES............................................................................ Phase A - Call set-up...................................................................................................................................... Basic Call Setup - Neither Endpoint Re..g........d........................................................................3..8... Both Endpoints Registered to the Same G.....e....e..p..e..r...............................................................3..8.. Only Calling Endpoint has Gate..k..e....e..r........................................................................................... Only Called Endpoint has ....e..p..e..r............................................................................................ Both Endpoints Registered to Different ....e..e..p..e..................................................................4.. Call Set-up via .....s................................................................................................................4..6... Gateway Inbound Call .S..e....p.................................................................................................... Gateway Outbound Call .S..e....p.................................................................................................4.. Call Setup with an .M..C..U...................................................................................................................4..7... Call ..g..................................................................................................................................... Broadcast Call ....p.........................................................................................................................4..7.. Phase B - Initial communication and capability exchange.............................................................................489/21/98 23:27iv
Page vDecided , 28 May Phase C - Establishment of audiovisual communication................................................................................. Mode ..e..s......................................................................................................................................4.. Exchange of video by mutual ag....e..m...e..n..t.....................................................................................4.. Media Stream Address Distribution............................................................................................................ Phase D: Call Services..................................................................................................................................... Bandwidth ..e..s...........................................................................................................................4.. ..s..................................................................................................................................................5..1... Ad Hoc Conference ..s....n........................................................................................................5.. Direct Endpoint Call Signalling - Conferen.... .C..r....t..e.......................................................... Direct Endpoint Call Signalling - Conferen..c..e.. ...v..it..e...........................................................5.. Endpoint Call Signalling - ..n.... ................................................................... Gatekeeper Routed Call Signalling - Confere..n..c..e. .C.....a....................................................... Gatekeeper Routed Call Signaling - ..n.... ...v.......................................................... Gatekeeper Routed Call Model - ..n.... ...................................................................5.. Supplementary ..ic..e..s................................................................................................................5..9.... Phase E: Call termination............................................................................................................................... Call Clearing without a ..e..e..p..e..r...............................................................................................6.. Call Clearing with a Gatek..e..e..p..e..r....................................................................................................6.. Call Clearing by ..e..p..e..r..........................................................................................................6..1.. Protocol Failure Handling...............................................................................................................................619 INTEROPERATION WITH OTHER TERMINAL TYPES................................................. Speech only terminals...................................................................................................................................... Visual telephone terminals over the ISDN ()......................................................................................... Visual telephone terminals over GSTN ()............................................................................................. Visual telephone terminals over Mobile Radio ( Visual telephone terminals over ATM ()............................................................................................... Visual telephone terminals over Guaranteed Quality of Service LANs ()............................................ Simultaneous Voice and Data Terminals over GSTN ().......................................................................... Terminals on the LAN...........................................................................................................................6410 OPTIONAL ENHANCEMENTS..................................................................................... Encryption.....................................................................................................................................................6411 MAINTENANCE............................................................................................................ Loopbacks for maintenance purposes........................................................................................................... Monitoring Methods.....................................................................................................................................669/21/98 23:27v
Page 1Decided , 28 May 19961 ScopeThis Recommendation, , covers the technical requirements for narrow-band visual telephone servicesdefined in Recommendations, in those situations where the transmission path includesone or more Local Area Networks (LAN), which may not provide a guaranteed Quality of Service (QoS)equivalent to that of N-ISDN. Examples of this type of LAN are:-Ethernet (IEEE )-Fast Ethernet (IEEE )-FDDI (non-guaranteed quality of service mode)-Token Ring (IEEE )Recommendation covers the case of visual telephone services in those situations where thetransmission path includes one or more Local Area Networks (LAN), which are configured and managed toprovide a guaranteed Quality of Service (QoS) equivalent to that of N-ISDN such that no additionalprotection or recovery mechanisms beyond those mandated by Rec. need be provided in theterminals. Pertinent parameters are the data error and loss properties and variation of transit delay. Anexample of a suitable LAN is: Integrated Services (IS) LAN: IEEE Isochronous services with CarrierSense Multiple Access with Collision Detection (CSMA/CD) Media access control (MAC) terminals may be used in multipoint configurations, and may interwork with terminals on B-ISDN, terminals on N-ISDN, terminals on B-ISDN, terminals on Guaranteed Quality ofService LANs, terminals on GSTN and wireless networks, and terminals on GSTN. See Figure1/ scope of does not include the LAN itself, or the transport layer which may be used to connectvarious LANs. Only elements needed for interaction with the Switched Circuit Network (SCN) are within thescope of . The combination of the Gateway, the terminal, and the out-of-scope LANappears on the SCN as an , , , or Recommendation describes the components of an system. This includes Terminals, Gateways,Gatekeepers, Multipoint Controllers, Multipoint Processors, and Multipoint Control Units. Control messagesand procedures within this Recommendation define how these components communicate. Detaileddescriptions of these components are contained in Section components described in this Recommendation consist of endpoints and entities. Theendpoints can call and are callable according to the call setup procedures of Section 8. The entities are notcallable, however, they can be addressed in order to perform their specific functions. For example, aterminal cannot place a call to a Gatekeeper, however, the Gatekeeper is addressed as part of the callestablishment 23:271
Page 2Decided , 28 May 1996Scope -Guaranteed QoS LAN(Note) terminaloperating : A gateway may support one or more of the GSTN, N-ISDN and/or B-ISDN connections. Figure 1/ Interoperability of Terminals2 Normative referencesThe following ITU-T Recommendations and other references contain provisions which, through reference inthis text, constitute provisions of this Recommendation. At the time of publication, the editions indicatedwere valid. All Recommendations and other references are subject to revision; all users of thisRecommendation are therefore encouraged to investigate the possibility of applying the most recent editionof the Recommendations and other references listed below. A list of the currently valid ITU-TRecommendations is regularly published.[1]ITU-T Recommendation (199X) : M"edia Stream Packetization andSynchronization for Visual Telephone Systems on Non-Guaranteed Quality ofService LANs ".9/21/98 23:272
Page 3Decided , 28 May 1996[2]ITU-T Recommendation (1995): "Control of communications between Visual TelephoneSystems and Terminal Equipment".[3]ITU-T Recommendation (1988): "Pulse Code Modulation (PCM) of Voiucen Fcrieqs".[4]ITU-T Recommendation (1988): "7 kHz Audio-coding within 64 kbit/s".[5]ITU-T Recommendation (1995): "Dual Rate Speech codec for multimediatelecommunications transmitting at and kbit/s".[6]ITU-T Recommendation (1992): "Speech Coding at 16 kbit/s".[7]ITU-T Recommendation (1995): "Speech codec for multimedia telecommunicationstransmitting at 8/13 kbit/s".[8]ITU-T Recommendation (1993): "Video CODEC for audiovisual services atp X 64 kbit/s"[9]ITU-T Recommendation (1995): "Video CODEC for narrowtelecommunications channels at < 64 kbit/s"[10]ITU-T Recommendation (1994): "Transmission protocols for multimediadata"[11]ITU-T Recommendation (1995): "Narrow-band ISDN visual telephonesystems and terminal equipment".[12]ITU-T Recommendation (1995): "Adaptation of Visual TelephoneTerminals to B-ISDN Environments".[13]ITU-T Recommendation (1995): "Visual Telephone Systems and TerminalEquipment for Local Area Networks which Provide a Guaranteed Quality ofService".[14]ITU-T Recommendation (1995): Terminal for Low Bitrate MultimediaCommunications".[15]ITU-T Recommendation (1996): "Broadband audio-visual communicationssystems and terminal equipment".[16]ITU-T Recommendation (1993): "Digital Subscriber Signalling System No. 1(DSS 1) - ISDN User-Network Interface Layer 3 Specification for Basic CallControl".[17]ITU-T Recommendation (1993): "Digital Subscriber SigSnyaslltienmg No. 1(DSS 1) - Generic Procedures for the Control of ISDN Supplementary Services".[18]ITU-T Recommendation (1993): "Digital Subscriber Signalling System No. 1(DSS 1) - Supplementary Services Protocols, Structure, and General Principles".9/21/98 23:273
Page 4Decided , 28 May 1996[19]ISO/IEC 10646-1 (1993): "Information Technology - Universal Multiple-OctetCoded Character Set (USC) -- Part I: Architecture and Basic Multilingual Plane".[20] ITU-T Recommendation (1991) “Numbering Plan for the ISDN Era”.3 DefinitionsFor the purposes of this Recommendation the definitions given in Clause 3 of both [1] and [2]apply along with those in this section. These definitions apply to the LAN side only. Other terms may beappropriate when refering to the Switched Circuit Network (SCN) MC: An MC that has won the master slave determination procedure and is currently providing themultipoint control function for the Hoc Multipoint Conference: An Ad Hoc Multipoint conference was a point-to-point conference that hadbeen expanded into a multipoint conference at some time during the call. This can be done if a one or moreof the terminals in the initial point-to-point conference contains an MC, if the call is made using aGatekeeper that includes MC functionality, or if the initial call is made through an MCU as a multipoint callbetween only two : An entity on the LAN having a Transport Address. Not the same as being callable. Aterminal or MCU is addressable and callable. A gatekeeper is addressable but not callable. An MC or MP isneither callable nor addressable but is contained within an endpoint or Gatekeeper that mute: Suppressing of the audio signal of a single or all source(s). Send muting means that theoriginator of an audio stream mutes its microphone and/or does not transmit any audio signal at all. Receivemute means that the receiving terminal ignores a particular incoming audio stream or mutes its Conference: A Broadcast conference is one in which there is one transmitter of media streamsand many receivers. There is no bi-directional transmission of control or media streams. Such conferencesshould be implemented using LAN transport multicast facilities, if available. This conference type is forfurther Panel Conference: A Broadcast Panel conference is a combination of a Multipoint conferenceand a Broadcast conference. In this conference, several terminals are engaged in a multipoint conferencewhile many other terminals are only receiving the media streams. There is bi-directional transmissionbetween the terminals in the multipoint portion of the conference and no bi-directional transmission betweenthem and the listening terminals. This conference type is for further : Point-to-point multimedia communication between two endpoints. The call begins with the callsetup procedure and ends with the call termination procedure. The call consists of the collection of reliableand unreliable channels between the endpoints. In case of interworking with some SCN endpoints via agateway, all the channels terminate at the Gateway where they are converted to the appropriaterepresentation for the SCN end Signalling Channel: Reliable channel used to convey the call setup and teardown messages () between two : Capable of being called as described in Section 8. Terminals, MCUs, and Gateways are callable,but Gatekeepers and MCs are Multipoint Conference: A Centralized Multipoint conference is one in which all participatingterminals communicate in a point-to-point fashion with an MCU. The terminals transmit their control, audio,video, and/or data streams to the MCU. The MC within the MCU centrally manages the conference. TheMP within the MCU processes the audio, video, and/or data streams, and returns the processed streams toeach 23:274
Page 5Decided , 28 May 1996Control and Indication (C&I): End-to-end signalling between terminals, consisting of Control, which causesa state change in the receiver, and Indication which provides for information as to the state or functioning ofthe system (see also [2] for additional information and abbreviations).Data: Information stream other than audio, video, and control, carried in the logical data channel ( [1]).Decentralized Multipoint Conference: A Decentralized Multipoint conference is one in which theparticipating terminals multicast their audio and video to all other participating terminals without using anMCU. The terminals are responsible for (a) summing the received audio streams and (b) selecting one ormore of the received video streams for display. No audio or video MP is required in this case. Theterminals communicate on their Control Channels with an MC which manages the conference. Thedata stream is still centrally processed by the MCS MCU which may be within an : An terminal, Gateway, or MCU. An endpoint can call and be called. It generates and/orterminates information : The Gatekeeper (GK) is an entity on the LAN that provides address translation andcontrols access to the local area network for terminals, Gateways, and MCUs. The Gatekeeper mayalso provide other services to the terminals, Gateways, and MCUs such as bandwidth management andlocating : An Gateway (GW) is an endpoint on the local area network which provides for real-time,two-way communications between Terminals on the LAN and other ITU Terminals on a wide areanetwork, or to another Gateway. Other ITU Terminals include those complying withRecommendations ( on B-ISDN), (ISDN), (ATM), (GQOS-LAN), (GSTN), (Mobile), and (DSVD). Entity: Any component, including terminals, Gateways, Gatekeepers, MCs, MPs, and Control Channel: Reliable Channel used to carry the control information messages () between two Logical Channel: Channel used to carry the information streams between two channels are established following the OpenLogicalChannel procedures. An unreliable channelis used for audio, audio control, video, and video control information streams. A reliable channel is used fordata and control information streams. There is no relationship between a logical channel and aphysical Session: the part of the call that begins with the establishment of an Control Channel, andends with the receipt of the essionCommand or termination due to failure. Not to be confusedwith a call, which is delineated by the Setup and Release Complete Multipoint Conference - Centralized Audio: A Hybrid Multipoint - Centralized Audio conference isone in which terminals multicast their video to other participating terminals, and unicast their audio to the MPfor mixing. The MP returns a mixed audio stream to each Multipoint Conference - Centralized Video: A Hybrid Multipoint - Centralized Video conference isone in which terminals multicast their audio to other participating terminals, and unicast their video to the MPfor switching or mixing. The MP returns a video stream to each Stream: A flow of information of a specific media type (e. g. audio) from a single source toone or more address: The network layer address of an entity as defined by the (inter)network layer protocolin use (e. g. an IP address). This address is mapped onto the layer one address of the respective systemby some means defined in the (inter)networking 23:275
Page 6Decided , 28 May 1996Lip Synchronization: Operation to provide the feeling that speaking motion of the displayed person issynchronized with his Area Network (LAN): A shared or switched medium, peer-to-peer communications network thatbroadcasts information for all stations to receive within a moderate-sized geographic area, such as a singleoffice building or a campus. The network is generally owned, used, and operated by a single the context of LANs also include internetworks composed of several LANs that are interconnectedby bridges or Multipoint Conference: A Mixed Multipoint conference (Figure 2/) has some terminals (D,E,and F) participating in a centralized mode while other terminals (A, B, and C) are participating in adecentralized mode. A terminal is not aware of the mixed nature of the conference, only of the type ofconference it is participating in. The MCU provides the bridge between the two types of Audio and VideoUnicast Audio and VideoDecentralized SideCentralized SideFigure 2/ Mixed Multipoint ConferenceMulticast: A process of transmitting PDUs from one source to many destinations. The actual mechanism (ieIP multicast, multi-unicast, etc) for this process may be different for different LAN Conference: A Multipoint conference is a conference between three or more terminals. Theterminals may be on the LAN or on the SCN. The multipoint conference shall always be controlled by anMC. Various multipoint conference types are defined in this section but they all require a single MC perconference. They may also involve one or more MCUs on the SCN. A terminal on the LAN may alsoparticipate in an SCN multipoint conference by connecting via a Gateway to an SCN MCU. This does notrequire the use of an Control Unit: The Multipoint Control Unit (MCU) is an endpoint on the local area network whichprovides the capability for three or more terminals and Gateways to participate in a multipoint also connect two terminals in a point-to-point conference which may later develop into a multipointconference. The MCU generally operates in the fashion of an MCU, however, an audio processor isnot mandatory. The MCU consists of two parts: a mandatory Multipoint Controller and optional MultipointProcessors. In the simplest case, an MCU may consist only of an MC with no Controller: The Multipoint Controller (MC) is an entity on the local area network whichprovides for the control of three or more terminals participating in a multipoint cMoanyfe arleson n ecttwo terminals in a point-to-point conference which may later develop into a multipoint Tcohnef eMreCn cper. o vides forcapability negotiation with all terminals to achieve common levels of communications. It also may control9/21/98 23:276
Page 7Decided , 28 May 1996conference resources such as who is multicasting video. The MC does not perform mixing or switching ofaudio, video and Processor: The Multipoint Processor (MP) is an entity on the local area network whichprovides for the centralized processing of audio, video, and/or data streams in a multipoint conference. TheMP provides for the mixing, switching, or other processing of media streams under the control of the MP may process a single media stream or multiple media streams depending on the type of -Unicast: A process of transfering PDUs where an endpoint sends more than one copy of a mediastream, but to different endpoints. This may be necessary in networks which do not support -to-Point Conference: A Point-to-Point conference is a conference between two terminals. May beeither directly between two terminals or between an terminal and an SCN terminal via agateway. A call between two terminals (See Call).RAS Channel: Unreliable channel used to convey the registration, admissions, bandwidth change, andstatus messages (following ) between two Channel: A transport connection used for reliable transmission of an information stream from itssource to one or more Transmission: Transmission of messages from a sender to a receiver using connection-modedata transmission. The transmission service guarantees sequenced, error-free, flow-controlled transmissionof messages to the receiver for the duration of the transport Session: For each participant, the session is defined by a particular pair of destination TransportAddresses (one LAN address plus a TSAP identifier pair for RTP and RTCP). The destination TransportAddress pair may be common for all participants, as in the case of IP multicast, or may be different for each,as in the case of individual unicast network addresses. In a multimedia session, the media audio and videoare carried in separate RTP sessions with their own RTCP packets. The multiple RTP sessions aredistinguished by different transport Circuit Network (SCN): A public or private switched telecommunications network such as theGSTN, N-ISDN, or : An Terminal is an endpoint on the local area network which provides for real-time, two-waycommunications with another terminal, Gateway, or Multipoint Control Unit. This communicationconsists of control, indications, audio, moving color video pictures, and/or data between the two terminals. Aterminal may provide speech only, speech and data, speech and video, or speech, data, and Address: The transport layer address of an addressable entity as defined by the(inter)network protocol suite in use. The Transport Address of an entity is composed of the LANaddress plus the TSAP identifier of the addressable Connection: An association established by a transport layer between two entities for thetransfer of data. In the context of , a transport connection provides reliable transmission Identifier: The piece of information used to multiplex several transport connections of the same typeon a single entity with all transport connections sharing the same LAN address, (e. g. the portnumber in a TCP/UDP/IP environment). TSAP identifiers may be (pre)assigned statically by someinternational authority or may be allocated dynamically during setup of a call. Dynamically assigned TSAPidentifiers are of transient nature, i. e. their values are only valid for the duration of a single : A process of transmitting messages from one source to one Channel: A logical communication path used for unreliable transmission of an informationstream from its source to one or more 23:277
Page 8Decided , 28 May 1996Unreliable Transmission: Transmission of messages from a sender to one or more receivers by means ofconnectionless-mode data transmission. The transmission sebrvesict-ee fifso rt delivery of the PDU,meaning that messages transmitted by the sender may be lost, duplicated, or received out of order by (anyof) the receiver(s).Well-known TSAP Identifier: A TSAP identifier that has been allocated by an (international) authority thatis in charge for the assignment of TSAP identifiers for a particular (inter)networking protocol and the relatedtransport protocols -- (e. g. the IANA for TCP and UDP port numbers). This identifier is guaranteed to beunique in the context of the respective : A Zone (Figure 3/) is the collection of all terminals (Tx), Gateways (GW), and Multipoint ControlUnits (MCU) managed by a single Gatekeeper (GK). A Zone includes at least one terminal, and may or maynot include Gateways or MCUs. A Zone has one and only one Gatekeeper. A Zone may be independent ofLAN topology and may be comprised of multiple LAN segments which are connected using routers (R) orother 3/ Zone4 Symbols and abbreviationsFor the purposes of this Recommendation, the following symbols and abbreviations times CIF16CIF16 times CIFACFAdmission ConfirmationARJAdmission RejectARQAdmission RequestBASBitrate Allocation SignalBCFBandwidth Change ConfirmationBCHBose, Chaudhuri, and HocquenghamB-ISDNBroadband - Integrated Services Digital NetworkBRJBandwidth Change RejectBRQBandwidth Change RequestC&IControl and IndicationCIDConference IdentifierCIFCommon Intermediate FormatDCFDisengage ConfirmantioDIDDirect Inward DialingDRQDisengage RequestECSEncryption Control SignalEIVEncryption Initialization Vector9/21/98 23:278
Page 9Decided , 28 May 1996FASFrame Alignment SignalFIRFull Intra RequestGCFGatekeeper ConfirmationGKGatekeeperGQOSGuaranteed Quality of ServiceGRJGatekeeper RejectGRQGatekeeper RequestGSTNGeneral Switched Telephone NetworkGWGatewayIANAInternet Assigned Number AuthorityIPInternet ProtocolIPXInternetwork Protocol ExchangeIRQInformation RequestIRRInformation Request ResponseISDNIntegrated Sevrices Digital NetworkITU-TInternational Telecommunications Union- Telecommunications StandardizationSectorLANLocal Area NetworkLCFLocation ConfirmationLCNLogical Channel NumberLRJLocation RejectLRQLocation RequestMCMultipoint ControllerMCSMultipoint Communications SystemMCUMultipoint Control UnitMPMultipoint ProcessorMSNMultiple Subscriber NumberN-ISDNNarrow Band-Integrated Services Digital NetworkNACKNegative AcknowledgeQCIFQuarter CIFRCFRegistration ConfirmationRRJRegistration RejectRRQRegistration RequestRTPReal Time ProtocolRTCPReal Time Control ProtocolSBESingle Byte ExtensionSCMSelected Communications ModeSCNSwitched Circuit NetworkSPXSequential Protocol ExchangeSQCIFSub QCIFTCPTransport Control ProtocolTSAPTransport Layer Service Access PointUCFUnregister ConfirmationUDPUser Datagram ProtocolURJUnregister RejectURQUnregister Request5 ConventionsIn this document the following conventions are used:"Shall" indicates a mandatory 23:279
Page 10Decided , 28 May 1996"Should" indicates a suggested but optional course of action."May" indicates an optional course of action rather than a recommendation that something to Sections, Paragraphs, Annexes, and Appendices refer to those items within thisRecommendation unless another document is explicitly listed. For example, Section refers to of this Recommendation; Section refers to section in items exist on both the LAN and on the SCN, references to the SCN item will be explicit. Forexample, an MCU is an MCU on the LAN, an SCN MCU is an MCU on the Recommendation describes the use of three different message types: , RAS, and . Todistinguish between the different message types the following convension is followed. message andparameter names consist of multiple concatinated words highlighted in bold typeface(maximumDelayJitter). RAS message names are represented by three letter abbreviations (ARQ). names consist of one or two words with the first letters capitalized (Call Proceeding).6 System descriptionThis Recommendation describes the elements of the components. These are Terminals, Gateways,Gatekeepers, MCs, and MCUs. These components communicate through the transmission of InformationStreams. The characteristics of these components are described in this Information StreamsVisual telephone components communicate through the transmission of Information Streams. TheseInformation Streams are classified into video, audio, data, communications control, and call control asfollows:Audio signals contain digitized and coded speech. In order to reduce the average bitrate of audio signals, voiceactivation may be provided. The audio signal is accompanied by an audio control signals contain digitized and coded motion video. Video is transmitted at a rate no greater than that selectedas a result of the capability exchange. The video signal is accompanied by a video control signals include still pictures, facsimile, documents, computer files, and other data control signals pass control data between remote like functional elements and are used forcapability exchange, opening and closing logical channels, mode control and other functions that are part ofcommunications control signals are used for call establishment, disconnect, and other call control information streams described above are formatted and sent to the network interface as described Terminal CharacteristicsAn example of an terminal is shown in Figure 4/. The diagram shows the user equipmentinterfaces, video codec, audio codec, telematic equipment, layer, system control functions, and the9/21/98 23:2710
Page 11Decided , 28 May 1996interface to the LAN. All terminals shall have a System Control Unit, layer, NetworkInterface, and an Audio Codec Unit. The Video Codec Unit and User Data Applications are of Recommendation CodecVideo I/O , CodecAudio I/O , ,, , Data , ControlSystem ControlCall ControlUser 4/ Terminal Terminal elements outside the scope of following elements are not within the scope of , and are therefore not defined within thisRecommendation:•Attached audio devices providing, voice activation sensing, microphone and loudspeaker, telephoneinstrument or equivalent, multiple microphones mixers, and acoustic echo cancellation.•Attached video equipment providing cameras and monitors, and their control and selection, video processingto improve compression or provide split screen functions.•Data applications and associated user interfaces which use or other data services over the data channel.•Attached Network Interface, which provides the interface to the LAN, supporting appropriate signalling, andvoltage levels, in accordance with national and international standards.•Human user system control, user interface and 23:2711
Page 12Decided , 28 May Terminal elements within the scope of following elements are within the scope of , and are therefore subject to standardization and aredefined within this Recommendation:•The Video Codec (, etc.) encodes the video from the video source (. camera) for transmission anddecodes the received video code which is output to a video display.•The Audio Codec (, etc.) encodes the audio signal from the microphone for transmission, and decodesthe received audio code which is output to the loudspeaker.•The Data Channel supports telematic applications such as electronic whiteboards, still image transfer, fileexchange, database access, audiographics conferencing, etc. The standardized data application for real-timeaudiographics conferencing is . Other applications and protocols may also be used via as specified in Section .•The System Control Unit (, ) provides signalling for proper operation of the terminal. Itprovides for call control, capability exchange, signalling of commands and indications, and messages to openand fully describe the content of logical channels.• Layer () formats the transmitted video, audio, data and control streams into messages foroutput to the network interface, and retrieves the received video, audio, data, and control streams frommessages which have been input from the network interface. In addition, it performs logical framing, sequencenumbering, error detection, and error correction as appropriate to each media LAN InterfaceThe LAN interface is implementation specific and is outside the scope of this recommendation. However,the LAN interface shall provide the services described in Recommendation . This includes thefollowing: Reliable (. TCP, SPX) end-to-end service is mandatory for the Control Channel, theData Channels, and the Call Signalling Channel. Unreliable (. UDP, IPX) end-to end service ismandatory for the Audio Channels, the Video Channels, and the RAS Channel. These services may beduplex or simplex, unicast or multicast depending on the application, the capabilities of the terminals, andthe configuration of the Video CodecThe video codec is optional. All terminals providing video communications shall be capable ofencoding and decoding video according to QCIF. Optionally, a terminal may also be capable ofencoding and decoding video according CIF or SQCIF, QCIF, CIF, 4CIF, and 16CIF. If aterminal supports with CIF or higher resolution, it shall also support CIF. All terminals whichsupport shall support QCIF. The and codecs, on the LAN, shall be used withoutBCH error correction and without error correction video codecs, and other picture formats, may also be used via negotiation. More than onevideo channel may be transmitted and/or received, as negotiated via the Control Channel. The may optionally send more than one video channel at the same time, for example, to convey thespeaker and a second video source. The terminal may optionally receive more than one videochannel at the same time, for example, to display multiple participants in a distributed multipoint and QCIF are defined in . SQCIF, 4CIF and 16CIF are defined in . For the algorithm,SQCIF is any active picture size less than QCIF, filled out by a black border, and coded in the QCIF 23:2712
Page 13Decided , 28 May 1996For all these formats, the pixel aspect ratio is the same as that of the CIF format. NOTE - The resultingpicture aspect ratio for SQCIF is different from the other video bitrate, picture format and algorithm options that can be accepted by the decoder are definedduring the capability exchange using . The encoder is free to transmit anything that is within thedecoder capability set. The decoder should have the possibility to generate requests via for a certainmode, but the encoder is allowed to simply ignore these requests if they are not mandatory which indicate capability for a particular algorithm option shall also be capable of accepting videobitstreams which do not make use of that terminals shall be capable of operating in asymmetric video bitrates, frame rates, and, if more thanone picture resolution is supported, picture resolutions. For example, this will allow a CIF capable terminalto transmit QCIF while receiving CIF each video logical channel is opened, the maximum operating mode to be used on that channel issignaled to the receiver in the nLogicalChannel message. The maximum mode signaledincludes maximum picture format, algorithm options, maximum codec bit rate, etc. The header within thevideo logical channel indicates which mode is actually used for each picture, within the stated example, a video logical channel opened for CIF format may transmit CIF, QCIF, or SQCIF pictures, butnot 4CIF or 16CIF. A video logical channel opened with onlyu ntrhees trictedVector andarithmeticCoding options may use neither, either, or both options, but shall not use options which were video stream is formatted as described in Terminal Based Continuous terminals may receive more than one video channel, particularly for multipoint conferencing. In thesecases, the terminal may need to perform a video mixing or switching function in order to present thevideo signal to the user. This function may include presenting the video from more than one terminal to theuser. The terminal shall use simultaneous capabilities to indicate how many simultaneousvideo streams it is capable of decoding. The simultaneous capability of one terminal should not limit thenumber of video streams which are multicast in a conference (this choice is made by the MC). Audio CodecAll terminals shall have an audio codec. All terminals shall be capable of encoding anddecoding speech according to Recommendation . All terminals shall be capable of transmitting andreceiving A-law anµd- law. A terminal may optionally be capable of encoding and decoding speech usingRecommendations , , , MPEG1 audio, and . The audio algorithm used by theencoder shall be derived during the capability exchange using . The terminal should be capableof asymmetric operation for all audio capabilities it has declared within the same capability set, . it shouldbe able to send and receive if it is capable of audio stream is formatted as described in terminal may optionally send more than one audio channel at the same time, for example, toallow two languages to be packets should be delivered to the transport layer periodically at an interval determined by the audiocodec Recommendation in use (audio frame interval). The delivery of each audio packet shall occur no laterthan 5 milliseconds after a whole multiple of the audio frame interval, measured from delivery of the firstaudio frame (audio delay jitter). Audio coders capable of further limiting their audio delay jitter may so signalusing the aximumDelayJitter parameter of thhe2 250Capability structure contained within a9/21/98 23:2713
Page 14Decided , 28 May 1996terminal capability set message, so that receivers may optionally reduce their jitter delay buffers. This is notthe same as the RTCP interarrival jitter : The testing point for the maximum delay jitter is at the input to network transport layer. Network stack,network, driver, and interface card jitter is not Audio terminals may receive more than one audio channel, particularly for multipoint conferencing. In thesecases, the terminal may need to perform an audio mixing function in order to present a compositeaudio signal to the user. The terminal shall use simultaneous capabilities to indicate how manysimultaneous audio streams it is capable of decoding. The simultaneous capability of one terminal shouldnot limit the number of audio streams which are multicast in a Maximum Audio-Video Transmit SkewTo allow terminals to appropriately set their receive buffer size, terminals shall transmit theh2250MaximumSkewIndication message to indicate the maximum skew between the audio and videosignals as delivered to the network transhp2o2r5t0. MaximumSkewIndication shall be sent for each pair ofassociated audio and video logical channels. This is not required for audio only or hybrid conferences. Lipsynchronization, if desired, shall be achieved via use of Receive Path DelayReceive path delay includes delay added to a media stream in order to maintain synchronization and toaccount for network packet arrival jitter. Media streams may optionally be delayed in the receiverprocessing path to maintain synchronization with other media streams. Further, a media stream mayoptionally be delayed to allow for network delays which cause packet arrival jitter. An terminal shallnot add delay for this purpose in its transmitting media processing points such as MCUs or Gateways may alter the video and audio time taginformation, and shall transmit appropriately modified audio and video time tags and sequence numbers,reflecting their transmitted signals. Receiving endpoints may add appropriate delay in the audio path toachieve lip Data ChannelOne or more data channels are optional. The data channel may be uni-directional or bi-directionaldepending on the requirements of the data is the default basis of data interoperability between an terminal and other , , ,or terminals. Where any optional data application is implemented using one or more of the ITU-TRecommendations which can be negotiated via , the equivalent application, if any, shall be oneof those provided. A terminal that provides far-end camera control using and is not required toalso support a far end camera control that non-standard data applicatiodnast aA(pplicationCapability = non-standard application,dataProtocolCapability = non-standard) and Transparent User Datad at(aApplicationCapability =userData applicationd, ataProtocolCapability = transparent) may be used whether the equivalent is provided or capability shall be signaled usindga taApplicationCapability = t120 application,dataProtocolCapability =s 23:2714
Page 15Decided , 28 May 1996The Data channel is formatted as described in Data ChannelsThere are two ways of establishing a connection within the context of an call. The first is theestablishment of the connection during an call as an inherent part of the call, using theprocedures of for opening logical channels. The second is the establishment of the connectionprior to placing the the case where the call is established first, the normal call setup procedures of Section arefollowed. The capability exchange takes place, and a bi-directional logical channel shall be opened for connection according to the normal procedures indicating that a new connection shall becreated as described opening of a bi-directional logical channel for may be initiated by either entity sendingopenLogicalChannel, and then following the bi-directional logical channel procedures of actually open the logical channel, the initiating entity shall soepnedn Laong icalChannel messageindicating that a data channel is to be openedf oinrw tahred LogicalChannelParameters as well asin ther everseLogicalChannelParameters. The initiator may decide whether or not to include a transportaddress in theo penLogicalChannel message. If the peer (the responder)accepts this logical channel itshall confirm the opening of the logical channel uospinegn LogicalChannelAck. In theopenLogicalChannelAck, the responder shall include a transport address to be used for setup of the if it did not receive a transport address from the initiator. Otherwise, the transport address shallbe absent. In both cases, the transport address for the connection shall be carried in theseparateStack parameter .The entity transmitting the transport address shall be prepared to accept a connection on this transportaddress. The entity receiving the transport address shall initiate a connection setup using thepreviously received transport both theo penLogicalChannel and theo penLogicalChannelAck messages, thea ssociateConferenceparameter shall be setf atols shall follow the procedures of for the protocol stack indicatDedat ainP rtohteo colCapabilityexcept that the transport addresses as described above shall be employed for connection setup. The winnerof the master/slave determination process shall have the option of being the upper node in the :The operation after completion of the connection setuopn dis tbhey scope of this the case where the connection is established first, the call is placed following the normal callsetup procedures of Section . The capability exchange takes place, and it is desired to associate connection with the call. The procedures of are used to open a bi-directional logicalchannel for data as described opening of a bi-directional logical channel for may be initiated by either entity by sendingopenLogicalChannel, and then following the bi-directional logical channel procedures of . Theinitiator of the setup should include identification information for the already existing connection in theopenLogicalChannel message to indicate to the peer which connection (if there are several) is to 23:2715
Page 16Decided , 28 May 1996To actually open the logical channel, the initiating entity shall ospeenndL aongi calChannel message for abi-directional logical channel indicating that a data channel is to be opened in theforwardLogicalChannelParameters as well as in there verseLogicalChannelParameters. If the peeraccepts this logical channel it shall returonp eanL ogicalChannelAck message to the initiator in which itmay include its local identification for the transport connectionIn both mesassasgoecsia ttheCe onferenceparameter shall be sett rtuoe .As identification information the local (dynamically instanstiated) transport address of the initial transportconnection of the connection should be provided sienp athraet eStack parameter. In addition, theexternalReference parameter may be used to provide further information on which connection is tobe any of this identification information is not available to the initiator, it may omit the respective value(s).Note:If the transport address is not specified and the two endpoints share more than one it may be ambiguous for the recipient which connection is referred of this ambiguity and steps to avoid it are for further Control FunctionThe Control Function uses the Control Channel to carry end-to-end control messagesgoverning operation of the entity, including capabilities exchange, opening and closing of logicalchannels, mode preference requests, flow control messages, and general commands and signalling is established between two endpoints, an endpoint and an MC, or an endpoint and aGatekeeper. The endpoint shall establish exactly one Control Channel, for each call that the endpointis participating in. This channel shall use the messages and procedures of Recommendation . Notethat a terminal, MCU, Gateway, or Gatekeeper may support many calls, and thus many ControlChannels. The Control Channel shall be carried on logical channel 0. Logical channel 0 shall beconsidered to be permanently open from the establishment of the Control Channel until thetermination of this channel. The normal procedures for opening and closing logical channels shall not applyto the Control specifies a number of independent protocol entities which support endpoint to endpoint signalling. Aprotocol entity is specified by its syntax (messages), semantics, and a set of procedures which specify theexchange of messages and the interaction with the user. endpoints shall support the syntax,semantics, and procedures of the following protocol entities:•Master/slave determination•Capability Exchange•Logical Channel Signalling•Bi-directional Logical Channel Signalling•Close Logical Channel Signalling•Mode Request•Round Trip Delay Determination•Maintenance Loop SignallingGeneral commands and indications shall be chosen from the message set contained in . In addition,other command and indication signals may be sent which have been specifically defined to be transferred in-band within video, audio or data streams (see the appropriate Recommendation to determine if such signalshave been defined).9/21/98 23:2716
Page 17Decided , 28 May messages fall into four categories: Request, Response, Command, and Indication. Request andResponse messages are used by the protocol entities. Request messages require a specific action by thereceiver, including an immediate response. Response messages respond to a corresponding messages require a specific action, but do not require a response. Indication messages areinformative only, and do not require any action or response. terminals shall respond to all and requests as specified in Annex A, and shall transmit indications reflecting the state of terminals shall be capable of parsing all ediaSystemControlMessage messages, andshall send and receive all messages needed to implement required functions and those optional functionswhich are supported by the terminal. Annex A contains a table showing which messages aremandatory, optional, or forbidden for terminals. terminals shall send thefunctionNotSupported message in response to any unrecognized request, response, or commandmessages that it indicationu,s erInputIndication, is available for transport of user input alphanumeric charactersfrom a keypad or keyboard, equivalent to the DTMF signals used in analog telephony, or SBE numbermessages in . This may be used to manually operate remote equipment such as voice mail or videomail systems, menu-driven information services, etc. terminals shall support the transmission of userinput characters 0-9, ‘*’, and ‘#’. Transmission of other characters is - If the encryption procedures of this Recommendation are in use, the Control Channel will notbe encrypted. Users are therefore cautioned regarding the carriage of user data in the ControlChannel, the use of non-standard messages, and the confidentiality risk from traffic analysis of the request messages conflict with RTCP control packets. Thev stUpdatePicture,videoFastUpdateGOB, and videoFastUpdateMB requests should be used instead of the RTCP controlpackets Full Intra Request (FIR) and Negative Acknowledgement (NACK). The ability to accept FIR andNACK is signalled during the capability exchangeCapabilities exchange shall follow the procedures of , which provides for separate receive and transmitcapabilities, as well as a method by which the terminal may describe its ability to operate in variouscombinations of modes capabilities describe the terminal’s ability to receive and process incoming information shall limit the content of their transmitted information to that which the receiver has indicated itis capable of receiving. The absence of a receive capability indicates that the terminal cannot receive (is atransmitter only).Transmit capabilities describe the terminal’s ability to transmit information streams. Transmit capabilitiesserve to offer receivers a choice of possible modes of operation, so that the receiver may request the modewhich it prefers to receive. The absence of a transmit capability indicates that the terminal is not offering achoice of preferred modes to the receiver (but it may still transmit anything within the capability of thereceiver).The transmitting terminal assigns each individual mode the terminal is capable of operating in a number in acapabilityTable. For example, audio, audio, and CIF video would each be assignedseparate capability numbers are grouped inatlote rnativeCapabilitySet structures. EachalternativeCapabilitySet indicates that the terminal is capable of operating in exactly one mode listed in the9/21/98 23:2717
Page 18Decided , 28 May 1996set. For example, aanl ternativeCapabilitySet listing {, , } means that the terminal canoperate in any one of those audio modes, but not more than alternativeCapabilitySet structures are grouped instiom ultaneousCapabilities structures. EachsimultaneousCapabilities structure indicates a set of modes the terminal is capable of usingsimultaneously. For example, asi multaneousCapabilities structure containing the twoalternativeCapabilitySet structures {, } and {, , } means that the terminal canoperate either of the video codecs simultaneously with any one of the audio codecs. ThesimultaneousCapabilities set { {}, {, }, {, , } } means the terminal canoperate two video channels and one audio channel simultaneously: One video channel per , anothervideo channel per either or , and one audio channel per either , , or - The actual capabilities stored inc tahpea bilityTable are often more complex than presented example, each capability indicates details including ability to support various picture formats atgiven minimum picture intervals, and ability to use optional coding modes. For a complete description, seeRecommendation terminal’s total capabilities are described by ac saepta boifl ityDescriptor structures, each of which is asingles imultaneousCapabilities structure and caa pabilityDescriptorNumber. By sending more than onecapabilityDescriptor, the terminal may signal dependencies between operating modes by describingdifferent sets of modes which it can simultaneously use. For example, a terminal issuing twocapabilityDescriptor structures, one { {, }, {, , } } as in the previous example,and the other { {}, {} }, means the terminal can also operate the video codec, but only withthe low-complexity audio may dynamically add capabilities during a communication session by issuing additionalcapabilityDescriptor structures, or remove capabilities by sending recvaipsaebdi lityDescriptor terminals shall transmit at leasct aopnaeb ilityDescriptor -standard capabilities and control messages may be issued usnionngS tthaen dardParameter structuredefined in . Note that while the meaning of non-standard messages is defined by individualorganizations, equipment built by any manufacturer may signal any non-standard message, if the meaning may reissue capability sets at any time, according to the procedures of channel signallingEach logical channel carries information from a transmitter to one or more receivers, and is identified by alogical channel number which is unique for each direction of channels are opened and closed using otpheen LogicalChannel and closeLogicalChannelmessages and procedures of . When a logical channel is openoepde,n tLhoeg icalChannel messagefully describes the content of the logical channel, including media type, algorithm in use, any options, and allother information needed for the receiver to interpret the content of the logical channel. Logical channelsmay be closed when no longer needed. Open logical channels may be inactive, if the information sourcehas nothing to logical channels in are unidirectional, so asymmetrical operation, in which the number and typeof information streams is different in each direction of transmission, is allowed. However, if a receiver iscapable only of certain symmetrical modes of operation, it may send a receive capability set that reflects itslimitations, except where noted elsewhere in . Terminals may also be capable of using a particularmode in only one direction of transmission. Certain media types, including data protocols such as ,inherently require a bi-directional channel for their operation. In such cases a pair of unidirectional logical9/21/98 23:2718
Page 19Decided , 28 May 1996channels, one in each direction, may be opened and associated together to form a bi-directional channelusing the bi-directional channel opening procedures of . Such pairs of associated channels need notshare the same logical channel number, since logical channel numbers are independent in each direction channels shall be opened using the following procedure:The initiating terminal shall sendO apne nLogicalChannel message as described in . If the logicalchannel is to carry a media type using RTP (audio or videoO),p etnhLeo gicalChannel message shallinclude them ediaControlChannel parameter containing the transport address for the reverse responding terminal shall respond witOhp aen LogicalChannelAck message as described in the logical channel is to carry a media type using RTOP,p ethneL ogicalChannelAck message shallinclude both the me dtiraansportChannel parameter containing the RTP transport address for the mediachannel and them ediaControlChannel parameter containing the transport address for the forward types (such as data) which do not use RTP/RTCP shall ommite dthiaeC a corresponding reverse channel is opened for a given existing RTP session (identified by the RTPsessionID), the mediaControlChannel transport addresses exchanged by Othpee nLogicalChannelprocess shall be identical to those used for the forward channel. Should a collision occur where both endsattempt to establish conflicting RTP sessions at the same time, the master endpoint shall reject theconflicting attempt as described in . The reOjepcetendLo gicalChannel attempt may then be retriedat a later preferencesReceivers may request transmitters to send a particular mode using threq de message,which describes the desired mode. Transmitters should comply if endpoint receiving tmheu ltipointModeCommand from the MC shall then comply witrhe qaull estModecommands, if they are within its capability set. Note that in a decentralized conference, as in a centralizedconference, all terminraeql uestMode commands are directed to the MC. The MC may grant the request ornot; the basis for this decision is left to the Master Slave DeterminationThe Master Slave Determination procedures are used to resolve conflicts between two endpointswhich can both be the MC for a conference, or between two endpoints which are attempting to open a bi-directional channel. In this procedure, two endpoints exchange random numbers in the message, to determine the master and slave endpoints. endpoints shallbe capable of operating in both master and slave modes. The endpointst esrhmailnl aselTty pe to the valuespecified in Table 1/ below ands staettu sDeterminationNumber to a random number in the range 0to 224-1. Only one random number shall be chosen by the endpoint for each call, except in the case ofidentical random numbers, as described in Value EntityFeature SetTerminalGatewayGatekeeperMCU9/21/98 23:2719
Page 20Decided , 28 May 1996Entity with No MC5060NANAEntity contains an MC but no MP7080120160Entity contains MC with Data MPNA90130170Entity contains MC with Data and audio MPNA100140180Entity contains MC with Data, Audio, and vidNeAo110150190MPTable 1/: terminal types for master-slave determinationThe Active MC in a conference shall use a value of 240. Cascaded MCs are for further a single entity can take part in multiple calls, then the valuet eursmeidn afloTry pe in the master-slave determination process shall be based on the features that the entity has assigned or will assignto the call in which it is being MC that is already acting as an MC shall always remain the active MC. Therefore, once an MC has beenselected as the active MC in a conference, it shall use the Active MC value for all subsequent connections tothe no MC is active and the entities are of the same type, then the entity with the highest feature set (asshown in Table 1/) shall win the master-slave determination. If no MC is active and the entities are ofdifferent types, then an MC that is located in an MCU shall have priority over an MC that is located in aGatekeeper, which shall have priority over an MC that is located in a Gateway, which in turn shall havepriority over an MC located in a an entity can be associated with two or more of the classifications shown in Table 1/, then itshould use the highest value for which it and counter valuesAll timers defined in should have periods of at least as long as the maximum data delivery timeallowed by the data link layer carrying the Control Channel, including any retry counter N100 should be at least relating to protocol error handling are covered in Section RAS Signalling FunctionThe RAS signalling function uses messages to perform registration, admissions, bandwidthchanges, status, and disengage procedures between endpoints and Gatekeepers. The RAS SignallingChannel is independent from the Call Signalling Channel and the Control Channel. openlogical channel procedures are not used to establish the RAS Signalling Channel. In LAN environments thatdo not have a Gatekeeper, the RAS Signalling Channel is not used. In LAN environments which contain aGatekeeper (a Zone), the RAS Signalling Channel is opened between the endpoint and the RAS Signalling Channel is opened prior to the establishment of any other channels between . This channel is described in detail in Section 7 of this 23:2720
Page 21Decided , 28 May Call Signalling FunctionThe call signalling function uses call signalling to establish a connection between two . The Call Signalling Channel is independent from the RAS Channel and the ControlChannel. open logical channel procedures are not used to establish the Call Signalling Channel. TheCall Signalling Channel is opened prior to the establishment of the Channel and any other logicalchannels between endpoints. In systems that do not have a Gatekeeper, the Call Signalling Channelis opened between the two endpoints involved in the call. In systems which contain a Gatekeeper, the CallSignalling Channel is opened between the end point and the Gatekeeper, or between the endpointsthemselves as chosen by the Gatekeeper. This channel is described in detail in Section 7 of this LayerLogical channels of video, audio, data or control information are established according to the procedures ofRecommendation . Logical channels are unidirectional, and are independent in each direction oftransmission. Some logical channels, such as for data, may be bi-directional, and are associated throughthe bi-directional open logical channel procedure of . Any number of logical channels of each mediatype may be transmitted, except for the Control Channel of which there shall be one per call. Inaddition to the logical channels, endpoints use two signalling channels for call control, and Gatekeeperrelated functions. The formatting used for these channels shall conform to Recommendation channel numbersEach logical channel is identified by a logical channel number (LCN), in the range 0 to 65535, which servesonly to associate logical channels with the transport connection. Logical channel numbers are selectedarbitrarily by the transmitter, except that logical channel 0 shall be permanently assigned to the Channel. The actual Transport Address that the transmitter shall transmit to, shall be returned by thereceiver in thoep enLogicalChannelAck Channel Bitrate LimitsA logical channel’s bandwidth shall have an upper limit specified by the minimum of the endpoint’s transmitcapability (if present) and the receiving endpoint’s receive capability. Based on this limit, an endpoint shallopen a logical channel at a bitrate at or below this upper limit. A transmitter shall transmit an informationstream within the logical channel at any bitrate at or below the open logical channel bitrate. The limit appliesto the information streams which are the content of the logical channel(s), not including RTP headers, RTPpayload headers and LAN headers and other endpoints shall obey to ftlhoew ControlCommand message of , which commands a limit to thebitrate of a logical channel or the aggregate bitrate of all logical channels. endpoints that want to limitthe bitrate of a logical channel, or the aggregate bitrate of all logical channels should send theflowControlCommand message to the transmitting the terminal has no information to send in a given channel, the terminal shall send no information. Filldata shall not be sent on the LAN in order to maintain a specific data Gateway CharacteristicsThe Gateway shall provide the appropriate translation between transmission formats (for example ) and between communications procedures (for example to/from ). The Gatewayshall also perform call setup and clearing on both the LAN side and the SCN side. Translation betweenvideo, audio, and data formats may also be performed in the Gateway. In general, the purpose of the9/21/98 23:2721
Page 22Decided , 28 May 1996Gateway (when not operating as an MCU) is to reflect the characteristics of a LAN endpoint to an SCNendpoint, and the reverse, in a transparent endpoint may communicate with another endpoint on the same LAN directly and withoutinvolving a Gateway. The Gateway may be omitted if communications with SCN terminals (terminals not onthe LAN) is not required. It may also be possible for a terminal on one segment of the LAN to call outthrough one Gateway and back onto the LAN through another Gateway in order to bypass a router or a lowbandwidth Gateway has the characteristics of an Terminal or MCU on the LAN, and of the SCN terminal orMCU on the SCN. The choice of terminal or MCU is left to the manufacturer. The Gateway provides thenecessary conversion between the different terminal types. Note that the Gateway may initially operate as aterminal, but later using signalling begin to operate as an MCU for the same call that was initiallypoint-to-point. Gatekeepers are aware of which terminals are Gateways since this is indicated when theterminal/Gateway registers with the Gateway which passes data between the SCN and the LAN may contain a MCS Providerwhich connects the MCS Providers on the LAN to the MCS Providers on the examples of an Gateway are shown in Figure 5/. The diagrams show the terminalor MCU function, the SCN terminal or MCU function, and the conversion function. The terminalfunction has the characteristics described in Section . The MCU function has the characteristicsdescribed in Section . The Gateway appears to the other terminals on the LAN as one or terminals, or an MCU. It communicates with the other terminals using the procedures inthis SCN terminal or MCU function has the characteristics described in the appropriate Recommendation(, , , , , , GSTN or ISDN speech only terminals). The Gateway appears tothe terminals on the SCN as one or more of the same terminal types or MCUs. It communicates to anotherterminal on the SCN using the procedures described in the appropriate Recommendation for that signalling procedures are beyond the scope of , including such topics as whether the appears as a terminal or a network to the SCN. Note that a Gateway may convert directly or without going to supporting interworking with speech only terminals on GSTN or ISDN should generate and detectDTMF signals corresponding to rInputIndications for 0-9, *, and #.9/21/98 23:2722
Page 23Decided , 28 May DFigure 5/ Gateway ConfigurationsThe conversion function provides the necessary conversion of transmission format, control, audio, video,and/or data streams between the different terminal recommendations. At a minimum, the Gateway shallprovide a conversion function for the transmission format, call setup signals and procedures, andcommunications control signals and procedures. When required, the Gateway shall provide for conversion. The Gateway performs the appropriate conversion between the Call Signallingand the SCN signalling system (, , etc.). The conversion between messages on the LANand messages on the SCN is described in Appendix signalling received by the Gateway from an ISDN endpoint and not applicable to the Gatewayshould be passed through to the LAN endpoint, and vice versa. This signalling includes and messages. This will allow endpoints to implement the Supplementary Services defined in thoseRecommendations. The handling of other SCN call signalling systems is for further recommendation describes the connection of one terminal on the LAN to one external terminalon the SCN through the Gateway. The actual number of terminals that can communicate through theGateway is not subject to standardization. Similarly, the number of SCN connections, number ofsimultaneous independent conferences, audio/video/data conversion functions, and inclusion of multipointfunctions is left to the manufacturer. If the Gateway includes an MCU function on the LAN side, that function9/21/98 23:2723
Page 24Decided , 28 May 1996shall be an MCU on the LAN side. If the Gateway includes an MCU function on the SCN side, it mayappear as an MCU, or as an MCU for or systems (these MCUs are indicated asfor further study in the respective Recommendations) on the SCN Gateway may be connected via the SCN to other Gateways to provide communication between which are not on the same which provides transparent interconnection between LANs without using (such as routersand remote dial in units) are not Gateways as defined within the scope of this Gatekeeper CharacteristicsThe Gatekeeper, which is optional in an system, provides call control services to the than one Gatekeeper may be present and communicate with each other in an unspecified Gatekeeper is logically separate from the endpoints, however, its physical implementation may coexistwith a terminal, MCU, Gateway, MC, or other LAN it is present in a system, the Gatekeeper shall provide the following services:•Address Translation - The Gatekeeper shall perform alias address to Transport Address translation. Thisshould be done using a translation table which is updated using the Registration messages described inSection 7. Other methods of updating the translation table are also allowed.•Admissions Control - The Gatekeeper shall authorize LAN access using ARQ/ACF/ARJ may be based on call authorization, bandwidth, or some other criteria which is left to the manufacturer. Itmay also be a null function which admits all requests.•Bandwidth Control - The Gatekeeper shall support BRQ/BRJ/BCF messages. This may be based onbandwidth management. It may also be a null function which accepts all requests for bandwidth changes.•Zone Management - The Gatekeeper shall provide the above functions for terminals, MCUs, and Gatewayswhich have registered with it as described in Section Gatekeeper may also perform other optional function such as:•Call Control Signalling - The Gatekeeper may choose to complete the call signalling with the endpoints andmay process the call signalling itself. Alternatively, the Gatekeeper may direct the endpoints to connect the CallSignalling Channel directly to each other. In this manner, the Gatekeeper can avoid handling the callcontrol signals. The Gatekeeper may have to act as the network as defined in in order to supportsupplementary services. This operation is for further study.•Call Authorization - Through the use of the signalling, the Gatekeeper may reject calls from a terminaldue to authorization failure. The reasons for rejection may include, but are not limited to, restricted accessto/from particular terminals or Gateways, and restricted access during certain periods of time. The criteria fordetermining if authorization passes or fails is outside the scope of this Recommendation.•Bandwidth Management - Control of the number of terminals permitted simultaneousaccess to the LAN. Through the use of the signalling, the Gatekeeper may reject callsfrom a terminal due to bandwidth limitations. This may occur if the Gatekeeper determines thatthere is not sufficient bandwidth available on the network to support the call. The criteria fordetermining if bandwidth is available is outside the scope of this Recommendation. Note thatthis may be a null function, . all terminals are granted access. This function also operatesduring an active call when a terminal requests additional 23:2724
Page 25Decided , 28 May 1996•Call Management - For example, the Gatekeeper may maintain a list of ongoing information may be necessary to indicate that a called terminal is busy, and to provideinformation for the Bandwidth Management function.•Gatekeeper management information data structure. For further study.•Bandwidth reservation for terminals not capable of this function. For further study.•Directory services. For further order to support Ad Hoc Multipoint Conferences, the Gatekeeper may choose to receive the ControlChannels from the two terminals in a point-to-point conference. When the conference switches to amultipoint conference, the Gatekeeper can redirect the Control Channel to an MC. The Gatekeeperneed not process the signalling, it only needs to pass it between the terminals or the terminals and which contain Gateways should also contain a Gatekeeper in order to translate incoming into Transport entities that contain a Gatekeeper shall have a mechanism to disable the internal Gatekeeper so thatwhen there are multiple entities that contain a Gatekeeper on a LAN, the entities can beconfigured into the same Multipoint Controller CharacteristicsThe MC provides control functions to support conferences between three or more endpoints in a multipointconference. The MC carries out the capabilities exchange with each endpoint in a multipoint MC sends a capability set to the endpoints in the conference indicating the operating modes in whichthey may transmit. The MC may revise the capability set that it sends to the terminals as a result ofterminals joining or leaving the conference, or for other this manner, the MC determines the Selected Communication Mode (SCM) for the conference. The SCMmay be common for all endpoints in the conference. Alternatively, some endpoints may have a differentSCM than other endpoints in the conference. The manner in which the MC determines a SCM is not withinthe scope of this part of multipoint conference setup, an endpoint will become connected to an MC on its ControlChannel. This connection may occur:- via an explicit connection with an MCU.- via an implicit connection to the MC within a Gatekeeper.- via an implicit connection to the MC within another terminal or Gateway in the multipointconference.- via an implicit connection through a Gatekeeper to an choice of conference mode (. decentralized or centralized) occurs after connection with the MCusing signalling. The choice of conference mode may be limited by the capability of the endpoints orthe MC may be located within a Gatekeeper, Gateway, terminal, or MCU. See Figure 6/ 23:2725
Page 26Decided , 28 May 1996Terminal 1Terminal 2Gatekeeper 1 Gatekeeper 2Gatekeeper 3MCMCMCMPLANMCMCMPMCMPMCGateway 1 Gateway 2 Gateway 3 MCU 1MCU 2Note: Gateway, Gatekeeper, and MCU can be a single deviceFigure 6/ Possible locations of MC and MP in systemAn MC within a terminal is not callable. It can be included in the call in order to process the signallingto support Ad Hoc multipoint conferences. In this case, there may be no distinction between the MC and Control Function (Section ) of the terminal. Communications between them is outside the scopeof this MC located with the Gatekeeper is not callable, however, an MCU located with a Gatekeeper is MCU located with a Gatekeeper functions as an independent MCU. An MC located with a Gatekeepermay be used to support Ad Hoc multipoint conferences when the Gatekeeper receives the ControlChannels from the endpoints. In this manner, the Gatekeeper can route the Control Channels to theMC at the start of the call or when the conference switches to Gateway can function as a terminal or an MCU. When functioning as a terminal, the Gateway maycontain an MC. This has the same characteristics as described above for an MC within a MCU always contains an MC. The MCU is callable and the MC processes the Control channelfrom all of the two or more endpoints are in a conference, the endpoints shall use the master slave resolutionprocedure of to determine the MC that will control the the capability exchange and master/slave determination, the MC may first assign a terminal number toa new endpoint using ttheer minalNumberAssign. The MC shall then notify the other endpoints of the newendpoint in the conference ustienrgm inalJoinedConference. The new endpoint may request a list of otherendpoints in the conference usingt ethrme Multipoint Processor CharacteristicsThe MP receives audio, video, and/or data streams from the endpoints involved in a centralized or hybridmultipoint conference. The MP processes these media streams, and returns them to the between the MC and the MP are not subject to MP may process one or more media stream types. When the MP processes video, it shall process thevideo algorithms and formats as described in . When the MP processes audio, it shall process the9/21/98 23:2726
Page 27Decided , 28 May 1996audio algorithms as described in . When the MP processes data, it shall process data streams asdescribed in MP which processes video shall provide either video switching or video mixing. Video switching is theprocess of selecting the video that the MP outputs to the terminals from one source to another. The criteriaused to make the switch may be determined through detection of a change in speaker (sensed by theassociated audio level) or through control. Video mixing is the process of formatting more than onevideo source into the video stream that the MP outputs to the terminals. An example of video mixing iscombining four source pictures into a two by two array in the video output picture. The criteria for whichsources and how many are mixed is determined by the MC until other controls are defined. The use of for these control functions is for further MP which processes audio shall prepare N audio outputs from M audio inputs by switching, mixing, or acombination of these. Audio mixing requires decoding the input audio to linear signals (PCM or analog),performing a linear combination of the signals, and recoding the result to the appropriate audio format. TheMP may eliminate or attenuate some of the input signals in order to reduce noise and other unwantedsignals. Each audio output may have a different mix of input signals providing for private terminals shall assume that their audio is not present in the audio stream returned to them. Terminalremoval of its own audio from the MP audio output is for further MP which processes data shall be capable of acting as a non-leaf MCS provider and should becapable of acting as the Top MCS Provider. An MP may also process non-standard data, transparent userdata, and/or other types of MP may provide algorithm and format conversion, allowing terminals to participate in a conference atdifferent MP is not callable, the MCU which it is a part of is callable. The MP terminates and sources the Multipoint Control Unit CharacteristicsThe MCU is an endpoint which provides support for multipoint conferences. The MCU shall consist of anMC and zero or more MPs. The MCU uses messages and procedures to implement features similarto those found in typical MCU that supports centralized multipoint conferences consists of an MC and an audio, video, anddata MP. A typical MCU that supports decentralized multipoint conferences consists of an MC and a dataMP supporting . It relies on decentralized audio and video LAN side of a Gateway may be an MCU. A Gatekeeper may also include an MCU. In either case theyare independent functions that happen to be MCU shall be callable by other endpoints using the procedures of Section Multipoint Centralized Multipoint CapabilityAll terminals shall have centralized multipoint capability. A Gateway which appears as a terminal on theLAN shall also have centralized multipoint capability. In this mode of operation they communicate with theMC of the MCU in a point-to-point manner on the control channel and with the MP on the audio, video, anddata channels. In this mode, the MC performs multipoint control functions, while the MP performsvideo switching or mixing, audio mixing, and multipoint data distribution. The MP transmits the9/21/98 23:2727
Page 28Decided , 28 May 1996resulting video, audio, and data streams back to the terminals. The MP may have the capability to convertbetween different audio, video, and data formats and bitrates, allowing the terminals to participate in theconference using different communications MCU may use multicast to distribute the processed video if the terminals in the conference can receivemulticast transmissions. Multicast distribution of processed audio is for further mode is signalled by the following capabiclietinetsr:a lizedControl, centralizedAudio,centralizedVideo, andc Decentralized Multipoint CapabilityIf the terminals have decentralized multipoint capability, they communicate with the MC of an MCU,Gateway, Gatekeeper, or terminal in a point-to-point mode on the Control Channel and optionally withan MP on data channels. The terminals shall have the capability to multicast their audio and video channelsto all other endpoints in the conference. The MC may control which terminal or terminals are activelymulticasting audio and/or video (for example by usifnlogw tChoen trolCommand on either channel).The terminals receive multicast video channels and select one or more of the available channels for displayto the user. The terminals receive the multicast audio channels and perform an audio mixing function inorder to present a composite audio signal to the MC may provide conference control functions such as chair control, video broadcast and videoselection. This shall be done by receiving from a terminal and then sending the appropriate control toother terminals to enable or disable their video multicast. commands may optionally provide the mode is signalled by the following capabiclietnietsra: lizedControl, decentralizedAudio,decentralizedVideo, andc Hybrid Multipoint - Centralized AudioIf the terminals and MCU have hybrid multipoint-centralized audio capability, they may use distributedmultipoint for video and centralized multipoint for audio. In this mode, the terminals communicate with theMC in a point-to-point mode on the Control Channel and optionally with an MP on data terminals shall have the capability to multicast their video channels to all other endpoints in theconference. The MC may control which terminal or terminals are actively multicasting video. The terminalsreceive multicast video channels and select one or more of the available channels for display to the of the terminals in the conference transmit their audio channels to the MP. The MP performs the audiomixing function and outputs the resulting audio streams to the terminals. The MP may produce an exclusiveaudio sum for each terminal in the conference. Multicast distribution of processed audio is for further mode is signalled by the following capabiclietinetsr:a lizedControl, centralizedAudio,decentralizedVideo, andc Hybrid Multipoint - Centralized VideoIf the terminals and MCU have hybrid multipoint-centralized video capability, they may use distributedmultipoint for audio and centralized multipoint for video. In this mode, the terminals communicate with theMC in a point-to-point mode on the Control Channel and optionally with an MP on data 23:2728
Page 29Decided , 28 May 1996The terminals shall have the capability to multicast their audio channels to all other endpoints in theconference. The MC may control which terminal or terminals are actively multicasting audio. The terminalsreceive multicast audio channels and perform a mixing function in order to present a composite audio signalto the of the terminals in the conference transmit their video channels to the MP. The MP performs the videoswitching, mixing, or format conversion functions and outputs the resulting video streams to the MP may produce an exclusive video stream for each terminal in the conference, or it may multicast avideo stream to all participating terminals, in order to minimize the bandwidth used on the mode is signalled by the following capabiclietnietsra: lizedControl, decentralizedAudio,centralizedVideo, andc Establishment of Common ModeThe MC shall coordinate a common communications mode between the terminals in the multipointconference. The MC may force terminals into a particular common mode of transmission (as allowed bytheir capability sets) by sending to the terminal a receive capability set listing only the desired mode oftransmission, or the MC may rely mounl tipointModeCommand and mode preference commands toenforce mode symmetry. The later approach should be used since it allows the terminals to know the fullrange of conference capabilities available that can be the MCU has the capability to convert audio and/or video formats, it may not be necessary to force allterminals into the same communications Multipoint rate matchingSince the terminals on each link in a multipoint configuration may attempt to operate at different bit rates,the MC shall send wControlCommand messages to limit the transmitted bit rates to those whichcan be sent to Multipoint Lip SynchronizationAn MP which is providing audio mixing in either the Centralized or Hybrid multipoint conferences shallmodify the time tags of the audio and video streams, taking into account its own time base, in order tomaintain audio and video synchronization. Further, when the MP processes the audio and/or video togenerate a new stream sourced from the MP, the MP shall generate its own sequence numbers in the audioand video mixing audio, the MP should synchronize each of the incoming audio streams to its own timing, mixthe audio streams, and then shall generate a new audio stream based on its own timing with its ownsequence numbers. If the MP is also switching video, the switched stream shall have its original time stampreplaced with the MP time base to synchronize it with the mixed audio stream and shall have a newsequence number representing the stream from the the case of distributed multipoint conferences, the receiving terminal may be able to maintain lipsynchronization by aligning the selected video stream and its associated audio by using the RTP time of the other audio streams may not be necessary. If multiple video streams are displayed, theassociated audio streams should be may not be possible to guarantee lip synchronization in hybrid multipoint 23:2729
Page 30Decided , 28 May Multipoint EncryptionIn a centralized multipoint configuration the MP is considered to be a trusted entity. Each port of the MPdecrypts the information streams from each of the terminals and encrypts the information streams toeach terminal in accordance with Section . Operation of an untrusted MCU is for further in decentralized and hybrid multipoint conferences is for further Cascading Multipoint Control UnitsThe multipoint control function may be distributed between several MCU entities. Such operations are forfurther Call SignallingCall signalling is the messages and procedures used to establish a call, request changes in bandwidth of thecall, get status of the endpoints in the call , and disconnect the call. Call signalling uses messages definedin and the procedures described in Section 8. This section describes some call signalling LAN AddressEach entity shall have at least one LAN Address. This address uniquely identifies the entity onthe LAN. Some entities may share a LAN Address (ie. a terminal and a co-located MC). This address isspecific to the LAN environment in which the endpoint is located. Different LAN environments may havedifferent LAN Address endpoint may use different LAN addresses for different channels within the same TSAP IdentifierFor each LAN Address, each entity may have several TSAP Identifiers. These TSAP Identifiers allowmultiplexing of several channels sharing the same LAN have one well known TSAP Identifier defined: the Call Signalling Channel TSAP have one well known TSAP Identifier defined: the RAS Channel TSAP Identifier and one wellknown multicast address defined: Discovery Multicast Address. These are defined in Appendix and entities should use dynamic TSAP Identifiers for the Control Channel, AudioChannels, Video Channels, and Data Channels. The Gatekeeper should use a dynamic TSAP Identifier forCall Signalling Channels. The RAS Channels and Signalling Channels may be redirected to dynamic TSAPIdentifiers during the registration Alias AddressAn endpoint may also have one or more alias addresses associated with it. The alias addresses provide analternate method of addressing the endpoint. These address include addresses (network accessnumber, telephone number, etc.), IDs (name, e-mail like address, etc.), and any others defined . Alias addresses shall be unique within a Zone. Gatekeepers, MCs, and MPs shall not have there is no Gatekeeper in the system, the calling endpoint shall address the called endpoint directlyusing the Call Signalling Channel Transport Address of the called endpoint. When there is a Gatekeeper in9/21/98 23:2730
Page 31Decided , 28 May 1996the system, the calling endpoint may address the called endpoint by its Call Signalling Channel TransportAddress, or alias address. The latter shall be translated into a Call Signalling Channel Transport Address bythe called endpoint’s address may consist of an optional access code followed by the access code consists of n digits from the set of 0 to 9, *, and #. The number of digits and their meaningis left to the discretion of the manufacturer. One purpose of such an access code might be to requestaccess to a Gateway. The Gatekeeper may alter this address prior to sending it to the ID consists of a string of ISO/IEC 10646-1 characters as defined in . It may be a username, email name, or other endpoint may have more than one alias address (including more than one of the same type) which istranslated to the same Transport Address. The endpoint’s alias addresses shall be unique within a Registration, Admissions, and Status (RAS) ChannelThe RAS Channel shall be used to carry messages used in the Gatekeeper discovery and endpointregistration processes which associate an endpoint’s alias address with its Call Signalling Channel TransportAddress. The RAS Channel shall be an unreliable Gatekeeper DiscoveryGatekeeper discovery is the process an endpoint uses to determine which Gatekeeper to register with. Thismay be done manually or automatically. Manual discovery relies on methods outside the scope of thisRecommendation to determine which Gatekeeper an endpoint is associated with. The endpoint isconfigured with the Transport Address of the associated Gatekeeper. For example, it may be entered atendpoint configuration, or it may be entered into a initialization file. In this way, the endpoint knows a-prioriwhich Gatekeeper it is associated with. The endpoint can now register with that Automatic method allows the endpoint - Gatekeeper association to change over time. The endpointmay not know who its Gatekeeper is, or may need to identify another Gatekeeper due to a failure. This maybe done through auto discovery. Auto discovery allows for lower administrative overhead in configuringindividual endpoints and additionally allows replacement of an existing Gatekeeper without manuallyreconfiguring all of the affected endpoint may multicast (or use other methods as described in Appendix D) a GatekeeperRequest (GRQ) message, asking “Who is my Gatekeeper?”. This is sent to the Gatekeeper’s well knownDiscovery Multicast Address. One or more Gatekeepers may respond with the Gatekeeper Confirmation(GCF) message indicating “I can be your Gatekeeper.”, and returns the Transport Address of theGatekeeper’s RAS Channel. If a Gatekeeper does not want the endpoint to register to it, it shall returnGatekeeper Reject (GRJ). See Figure 7/. If more than one Gatekeeper responds, the endpoint maychoose the Gatekeeper it wants to use. At this point, the endpoint knows which Gatekeeper to register endpoint can now register with that 23:2731
Page 32Decided , 28 May 1996EndpointGatekeeperGRQGCF/GRJFigure 7/ Auto DiscoveryIf no Gatekeeper responds within a timeout, the endpoint may retry the GRQ. An endpoint shall not send aGRQ within 5 seconds after sending a previous one. If no response is received, the endpoint may use themanual discovery at any time an endpoint determines it has an invalid registration with its Gatekeeper, it must re-discover itsGatekeeper. The invalid registration may be detected by either receiving an RRJ message from aGatekeeper in response to an RRQ from the endpoint, or not receiving any response to an RRQ from theendpoint within a GRQ may be repeated periodically (., at endpoint power up), so the Gatekeeper shall be able tohandle multiple requests from the same Endpoint RegistrationRegistration is the process by which an endpoint joins a Zone, and informs the Gatekeeper of its TransportAddress and alias addresses. As part of their configuration process, all endpoints shall register with theGatekeeper identified through the discovery process. Registration shall occur before any calls areattempted, and may occur periodically as necessary (for example, at endpoint power up).An endpoint shall send a Registration Request (RRQ) to a Gatekeeper. This is sent to the Gatekeeper’sRAS Channel Transport Address. The endpoint has the LAN Address of the Gatekeeper from theGatekeeper discovery process and uses the well known RAS Channel TSAP Identifier. The Gatekeepershall respond with either a Registration Confirmation (RCF) or a Registration Reject (RRJ). See Figure8/. An endpoint shall only register with a single RRQ may be repeated periodically (ie, at terminal power up), so the Gatekeeper shall be able to handlemultiple requests from the same endpoint. If a Gatekeeper receives an RRQ having the same alias addressand the same Transport address as a previous RRQ, it shall respond with RCF. If a Gatekeeper receives anRRQ having the same alias address as a previous RRQ and a different Transport address, it should rejectthe registration indicating a duplicate registration. If the Gatekeeper receives an RRQ having the sameTransport Address as a previous RRQ and a different alias address, it should replace the translation tableentries. The Gatekeeper may have a method to authenticate these changes which is for further Gatekeeper shall ensure that each alias address translates uniquely to a single Transport registrations shall be rejected by the Gatekeeper. The Gatekeeper may reject the registration forother reasons, such as changes in discovery or security the endpoint does not include an alias address in the RRQ message, the Gatekeeper may assign Gatekeeper shall return the assigned alias address to the terminal in the RCF 23:2732
Page 33Decided , 28 May 1996EndpointGatekeeperRRQRCF or RRJURQEndpoint initiatedUnregister RequestUCF/URJURQGatekeeper initiatedUCFUnregister RequestFigure 8/ RegistrationAn endpoint may cancel its registration by sending an Unregister Request message (URQ) to theGatekeeper. The Gatekeeper shall respond with an Unregister Confirmation message (UCF). This allowsendpoints to change the alias address associated with its Transport Address, or vice versa. If the endpointwas not registered with the Gatekeeper, it shall return an Unregister Reject message (URJ) to the Gatekeeper may cancel the registration of an endpoint by sending an Unregister Request message (URQ)to the endpoint. The endpoint shall respond with an Unregister Confirmation message (UCF). The endpointshall re-register with a Gatekeeper prior to initiating any calls. This may require the endpoint to register witha new endpoint which is not registered with a Gatekeeper is called an unregistered endpoint. This type ofendpoint does not request admission permission from a Gatekeeper and so cannot participate in admissionscontrol, bandwidth control, address translation, and other functions performed by the Endpoint LocationAn endpoint or Gatekeeper which has an alias address for an endpoint and would like determine itsTransport Address may issue a Location Request (LRQ) message. This message may be sent to a specificGatekeeper, or may be multicast like the GRQ message. This is sent to the Gatekeeper’s well known RASChannel TSAP Identifier, or if multicast, is sent to the Gatekeeper’s well known Discovery Multicast Gatekeeper with which the requested endpoint is registered, shall respond with the LocationConfirmation (LCF) message containing the Transport Address of the endpoint’s Call Signalling Channel orthe endpoint’s Gatekeeper’s Call Signalling Channel. All Gatekeepers with which the requested endpoint isnot registered, shall return Location Reject (LRJ) if they received the LRQ on the RAS Channel. Any9/21/98 23:2733
Page 34Decided , 28 May 1996Gatekeeper with which the requested endpoint is not registered, shall not respond to the LRQ, if it receivedthe LRQ on the Discovery Multicast Admissions, Bandwidth Change, Status, DisengageThe RAS Channel is also used for the transmission of Admissions, Bandwidth Change, Status, andDisengage messages. These messages take place between an endpoint and a Gatekeeper and are used toprovide admissions control and bandwidth management functions. The detailed use of these messages isdescribed in Section Admissions Request (ARQ) message specifies the requested Call Bandwidth. This is an upper limit onthe aggregate bitrate for all transmitted and received, audio and video channels excluding any RTP headers,RTP payload headers, LAN headers, and other overhead. Data and control channels are not included in thislimit. The Gatekeeper may reduce the requested Call Bandwidth in the Admissions Confirm (ACF)message. An endpoint shall assure that the aggregate bitrate, averaged over one second, for all transmittedand received, audio and video channels is at or below the Call Bandwidth. An endpoint or the Gatekeepermay attempt to modify the Call Bandwidth during a call using the Bandwidth Change Request (BRQ) Call Signalling ChannelThe Call Signalling Channel shall be used to carry call control messages. The Call Signallingchannel shall be a reliable networks that do not contain a Gatekeeper, call signalling messages are passed directly between thecalling and called endpoints using the Call Signalling Transport Addresses. In these networks, it is assumedthat the calling endpoint knows the Call Signalling Transport Address of the called endpoint and thus cancommunicate networks that do contain a Gatekeeper, the initial admission message exchange takes place between thecalling endpoint and the Gatekeeper using the Gatekeeper's RAS Channel Transport Address. Within theinitial admissions message exchange, the Gatekeeper indicates in the ACF message whether to send thecall signalling directly to the other endpoint or to route it through the Gatekeeper. The call signallingmessages are sent to either the endpoint’s Call Signalling Transport Address or the Gatekeeper’s CallSignalling Transport specifies the mandatory messages that are used for call signalling in . Section 8specifies the procedures for using Call Signalling Channel RoutingCall signalling messages may be passed in two ways. The first method is Gatekeeper Routed Call Signalling(Figure 9/). In this method, call signalling messages are routed through the Gatekeeper between theendpoints. The second method is Direct Endpoint Call Signalling (Figure 10/). In this method, the callsignalling messages are passed directly between the endpoints. The choice of which methods is used ismade by the methods use the same kinds of connections for the same purposes, and the same messages are exchanges on RAS channels with the Gatekeeper, followed by an exchange ofcall signalling messages on a Call Signalling channel. This is then followed by the establishment of Control Channel. The actions of the Gatekeeper in response to the admission messages determinewhich call model is used, this is not under the control of the endpoint, although the endpoint can specify 23:2734
Page 35Decided , 28 May 1996For the Gatekeeper Routed method, the Gatekeeper may choose to close the Call Signalling Channel afterthe call setup is completed, or it may choose to keep it open for the duration of the call to supportsupplementary services. Only the Gatekeeper shall close the Call Signalling Channel and it should not beclosed when a Gateway is involved in the symmetrical signalling method of Annex D shall be used for all mandatory call signallingprocedures. This does not address the role that a Gateway might play on the SCN side using or othercall signalling Gatekeeper Clouds in Figure 9/ thru Figure 12/ contain one or more Gatekeepers which mayor may not communicate with each other. The endpoints may be connected to the same Gatekeeper or todifferent Signalling Channel MessagesRAS Channel Messages1 - ARQ2 - ACF/ARJ3 - SetupGatekeeper Cloud4 - Setup5 - ARQ6 - ACF/ARJ7 - Connect123845678 - ConnectEndpoint 1Endpoint 2Figure 9/ Gatekeeper Routed Call SignallingCall Signalling Channel MessagesRAS Channel Messages1 - ARQ2 - ACF/ARJ3 - SetupGatekeeper Cloud4 - ARQ5 - ACF/ARJ6 - Connect12453Endpoint 1Endpoint 269/21/98 23:2735
Page 36Decided , 28 May 1996Figure 10/ Direct Endpoint Call Control Channel RoutingWhen Gatekeeper Routed call signalling is used, there are two methods to route the Control the first method, the Control Channel is established directly between the endpoints. See Figure11/. This method is for further study. In the second method, the Control Channel is routedbetween the endpoints through the Gatekeeper. See Figure 12/. This method allows the Gatekeeperto redirect the Control Channel to an MC when an Ad Hoc multipoint conference switches from apoint-to-point conference to a multipoint conference. This choice is made by the Gatekeeper. When DirectEndpoint call signalling is used, the Control Channel can only be connected directly between Control Channel MessagesCall Signalling Channel MessagesRAS Channel Messages1 - ARQ2 - ACF/ARJ3 - SetupGatekeeper Cloud4 - Setup5 - ARQ6 - ACF/ARJ7 - Connect123845678 - Connect9 - ChannelEndpoint 19Endpoint 2Figure 11/: Direct Control Channel Connection Between Control Channel MessagesCall Signalling Channel MessagesRAS Channel Messages1 - ARQ2 - ACF/ARJ3 - SetupGatekeeper Cloud4 - Setup5 - ARQ6 - ACF/ARJ7 - Connect123894567108 - Connect9 - Channel10 - ChannelEndpoint 1Endpoint 29/21/98 23:2736
Page 37Decided , 28 May 1996Figure 12/ Gatekeeper Routed Call Reference ValueAll call signalling and RAS messages contain a Call Reference Value (CRV). Refer to . This is usedto associate all messages related to the same call. The same CRV shall be used in all admissions, callsetup, supplementary service, bandwidth change, and call termination messages relating to the same call. Anew CRV shall be used for new calls. A second call from an endpoint to invite another endpoint into thesame conference shall use a new CRV. The CRV is not the same as the Conference ID (CID). The CRVrelates messages within the same call, the CID relates calls within the same Conference ID and Conference GoalThe Conference ID (CID) is a unique non-zero value created by the originating endpoint and passed invarious messages, encoded with CID octet zero first. The CID identifies the conference with whichthe message is associated. The CID shall be formed from 16 octets as follows:CID octet1514131211109876543210valueN5N4N3N2N1N0C1C0H1AVM1M0L3L2L1L0where an index of 0 (. N0) refers to the lowest order octet of the respective value (. N5:N0):N5:0 is 48 bits of physical LAN address, if :0 is 16 bits of counter incremented per conference if the clock cannot be guaranteed to , A,M1:0,L3:0 is low order 60 bits of 100 nanosecond clock since Oct 15, 1582 local assigment of bits is as follows:H1AM1M0L3L2L1L059 5251 484732310V is 4 bits of version number = 0001 placed in the lower order 4 bits of CID octet conferenceGoal indicates the intention of the call. Choices are: Create - to create a new conference,Join - to join an existing conference, and Invite - to invite a new endpoint into an existing . Call Signalling ProceduresThe provision of the communication is made in the following steps:-phase A: Call set-up (subclause );-phase B: Initial communication and capability exchange (subcl)a;use -phase C: Establishment of audio visual communication (subclause );-phase D: Call Services (subclause );-phase E: Call termination (subclause )9/21/98 23:2737
Page 38Decided , 28 May Phase A - Call set-upCall Set-up takes place using the call control messages defined in according to the call controlprocedures defined below. Requests for bandwidth reservation should take place at the earliest both the alias address and the transport address are specified, preference shall be given to the Basic Call Setup - Neither Endpoint RegisteredIn the scenario shown in Figure 13/ neither endpoint is registered to a Gatekeeper. The two endpointscommunicate directly. Endpoint 1 (calling endpoint) sends the Setup (1) message to the well known CallSignalling Channel TSAP Identifier of endpoint 2. Endpoint 2 responds with the Connect (4) message whichcontains an Control Channel Transport Address for use in 1Endpoint 2Setup(1)Call proceeding(2)Alerting(3)Connect(4)Call Signalling MessagesFigure 13/ Basic Call Setup, no Both Endpoints Registered to the Same GatekeeperIn the scenario shown in Figure 14/, both endpoints are registered to the same Gatekeeper, and theGatekeeper has chosen Direct Call Signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2)exchange with that Gatekeeper. The Gatekeeper shall return the Call Signalling Channel Transport Addressof endpoint 2 (called endpoint) in the ACF. Endpoint 1 then sends the Setup (3) message to endpoint 2using that Transport Address. If endpoint 2 wishes to accept the call, it initiates an ARQ (5)/ACF (6)exchange with the Gatekeeper. It is possible that an ARJ (6) is received by endpoint 2, in which case itsends Release Complete to endpoint 1. Endpoint 2 responds with the Connect (4) message which containsan Control Channel Transport Address for use in 23:2738
Page 39Decided , 28 May 1996Endpoint 1Gatekeeper 1Endpoint 2ARQ(1)ACF/ARJ(2)Setup(3)Call proceeding(4)ARQ(5)ACF/ARJ(6)Alerting(7)Connect(8)RAS MessagesCall Signalling MessagesFigure 14/ Both Endpoints Registered, Same Gatekeeper - Direct Call SignallingIn the scenario shown in Figure 15/, both endpoints are registered to the same Gatekeeper, and theGatekeeper has chosen to route the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF(2) exchange with that Gatekeeper. The Gatekeeper shall return a Call Signalling Channel TransportAddress of itself in the ACF. Endpoint 1 then sends the Setup (3) message using that Transport Gatekeeper then sends the Setup (4) message to endpoint 2. If endpoint 2 wishes to accept the call, itinitiates an ARQ (6)/ACF (7) exchange with the Gatekeeper. It is possible that an ARJ (7) is received byendpoint 2, in which case it sends Release Complete to the Gatekeeper. Endpoint 2 responds with theConnect (9) message which contains an Control Channel Transport Address for use in . The Gatekeeper sends the Connect (10) message to endpoint 1 which may contain the endpoint2 Control Channel Transport Address, or a Gatekeeper (MC) Control Channel TransportAddress, based on whether the Gatekeeper chooses to route the Control Channel or 1Gatekeeper 1Endpoint 2ARQ(1)ACF(2)Setup(3)Setup(4)Call Proceeding(5)Call Proceeding(5)ARQ(6)ACF/ARJ(7)Alerting(8)Alerting(8)Connect(9)Connect(10)RAS MessagesCall Signalling Messages9/21/98 23:2739
Page 40Decided , 28 May 1996Figure 15/ Both Endpoints Registered, Same Gatekeeper - Gatekeeper Routed Call Only Calling Endpoint has GatekeeperIn the scenario shown in Figure 16/, endpoint 1 (calling endpoint) is registered with a Gatekeeper,endpoint 2 (called endpoint) is not registered with a Gatekeeper, and the Gatekeeper has chosen Direct CallSignalling. Endpoint 1 initiates the ARQ (1)/ACF (2) exchange with the Gatekeeper. Endpoint 1 then sendsthe Setup (3) message to endpoint 2 using the well known Call Signalling Channel Transport Address. Ifendpoint 2 wishes to accept the call, it responds with the Connect (4) message which contains an Channel Transport Address for use in 1Gatekeeper 1Endpoint 2ARQ(1)ACF/ARJ(2)Setup(3)Call proceeding(4)Alerting(5)Connect(6)RAS MessagesCall Signalling MessagesFigure 16/ Only Calling Endpoint Registered - Direct Call SignallingIn the scenario shown in Figure 17/, endpoint 1 (calling endpoint) is registered with a Gatekeeper,endpoint 2 (called endpoint) is not registered with a Gatekeeper, and the Gatekeeper has chosen to route thecall signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2) exchange with that Gatekeeper shall return a Call Signalling Channel Transport Address of itself in the ACF(2). Endpoint 1then sends the Setup (3) message using that Transport Address. The Gatekeeper then sends the Setup (4)message to the well known Call Signalling Channel Transport Address of endpoint 2. If endpoint 2 wishes toaccept the call, it responds with the Connect (7) message which contains an Control ChannelTransport Address for use in signalling. The Gatekeeper sends the Connect (9) message to endpoint1 which may contain the endpoint 2 Control Channel Transport Address, or a Gatekeeper (MC) Channel Transport Address, based on whether the Gatekeeper chooses to route the ControlChannel or 23:2740
Page 41Decided , 28 May 1996Endpoint 1Gatekeeper 1Endpoint 2ARQ(1)ACF(2)Setup(3)Setup(4)Call Proceeding(5)Call Proceeding(5)Alerting(6)Alerting(6)Connect(7)Connect(8)RAS MessagesCall Signalling MessagesFigure 17/ Only Calling Endpoint Registered - Gatekeeper Routed Call Only Called Endpoint has GatekeeperIn the scenario shown in Figure 18/, endpoint 1 (calling endpoint) is not registered with a Gatekeeper,endpoint 2 (called endpoint) is registered with a Gatekeeper, and the Gatekeeper has chosen Direct CallSignalling. Endpoint 1 sends the Setup (1) message to endpoint 2 using the well known Call SignallingChannel Transport Address. If endpoint 2 wishes to accept the call, it initiates an ARQ (3)/ACF (4)exchange with the Gatekeeper. It is possible that an ARJ (4) is received by endpoint 2, in which case itsends Release Complete to endpoint 1. Endpoint 2 responds with the Connect (6) message which containsan Control Channel Transport Address for use in 1Gatekeeper 2Endpoint 2Setup(1)Call proceeding(2)ARQ(3)ACF/ARJ(4)Alerting(5)Connect(6)RAS MessagesCall Signalling MessagesFigure 18/ Only Called Endpoint Registered - Direct Call SignallingIn the scenario shown in Figure 19/, endpoint 1 (calling endpoint) is not registered with a Gatekeeper,endpoint 2 (called endpoint) is registered with a Gatekeeper, and the Gatekeeper has chosen to route the9/21/98 23:2741
Page 42Decided , 28 May 1996call signalling. Endpoint 1 (calling endpoint) sends a Setup (1) message to the well known Call SignallingChannel Transport address of endpoint 2. If endpoint 2 wishes to accept the call, it initiates the ARQ(3)/ACF (4) exchange with that Gatekeeper. If acceptable, the Gatekeeper shall return a Call SignallingChannel Transport Address of itself in the ARJ(4) with a cause croduete oCfa llToGatekeeper. Endpoint 2replies to endpoint 1 with a Facility (5) message containing the Call Signalling Transport Address of itsGatekeeper. Endpoint 1 then sends the Release Complete (6) message to endpoint 2. Endpoint 1 sends aSetup (7) message to the Gatekeeper’s Call Signalling Channel Transport Address. The Gatekeeper sendsthe Setup (8) message to endpoint 2. Endpoint 2 initiates the ARQ (9)/ACF (10) exchange with thatGatekeeper. Endpoint 2 then responds with the Connect (12) message which contains its ControlChannel Transport Address for use in signalling. The Gatekeeper sends the Connect (13) message toendpoint 1 which may contain the endpoint 2 Control Channel Transport Address, or a Gatekeeper(MC) Control Channel Transport Address, based on whether the Gatekeeper chooses to route Control Channel or 1Gatekeeper 2Endpoint 2Setup(1)Call Proceeding (2)ARQ(3)ARJ(4)Facility (5)Release Complete (6)Setup(7)Setup(8)Call Proceeding(2)Call Proceeding(2)ARQ(9)ACF/ARJ(10)Alerting(11)Alerting(11)Connect(12)Connect(13)RAS MessagesCall Signalling MessagesFigure 19/ Only Called Endpoint Registered - Gatekeeper Routed Call Both Endpoints Registered to Different GatekeepersIn the scenario shown in Figure 20/, both endpoints are registered to different Gatekeepers, and bothGatekeepers choose Direct Call Signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2)exchange with Gatekeeper 1. Gatekeeper 1 may return the Call Signalling Channel Transport Address ofendpoint 2 (called endpoint) in the ACF if Gatekeeper 1 has a method of communicating with Gatekeeper 1 then sends the Setup (3) message to either the Transport Address returned by the Gatekeeper (ifavailable) or to the well known Call Signalling Channel Transport Address of endpoint 2. If endpoint 2wishes to accept the call, it initiates an ARQ (5)/ACF (6) exchange with Gatekeeper 2. It is possible that anARJ (6) is received by endpoint 2, in which case it sends Release Complete to endpoint 1. Endpoint 2responds with the Connect (8) message which contains an Control Channel Transport Address for usein 23:2742
Page 43Decided , 28 May 1996Endpoint 1Gatekeeper 1Gatekeeper 2Endpoint 2ARQ(1)ACF/ARJ(2)Setup(3)Call proceeding(4)ARQ(5)ACF/ARJ(6)Alerting(7)Connect(8)RAS MessagesCall Signalling MessagesFigure 20/ Both Endpoints Registered - Both Gatekeepers Direct Call SignallingIn the scenario shown in Figure 21/, both endpoints are registered to different Gatekeepers, the callingendpoint’s Gatekeeper chooses Direct Call Signalling, and the called endpoint’s Gatekeeper chooses toroute the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2) exchange withGatekeeper 1. Gatekeeper 1 may return the Call Signalling Channel Transport Address of endpoint 2 (calledendpoint) in the ACF (2) if Gatekeeper 1 has a method of communicating with Gatekeeper 2. Endpoint 1then sends the Setup (3) message to either the Transport Address returned by the Gatekeeper (if available)or to the well known Call Signalling Channel Transport Address of endpoint 2. If endpoint 2 wishes to acceptthe call, it initiates the ARQ (5)/ACF (6) exchange with Gatekeeper 2. If acceptable, Gatekeeper 2 shallreturn a Call Signalling Channel Transport Address of itself in the ARJ(6) with a cause code ofrouteCallToGatekeeper. Endpoint 2 replies to endpoint 1 with a Facility (7) message containing the CallSignalling Transport Address of Gatekeeper 2. Endpoint 1 then sends the Release Complete (8) message toendpoint 2. Endpoint 1 shall send a DRQ (9) to Gatekeeper 1 which responds with DCF (10). Endpoint 1 theninitiates a new ARQ(11)/ACF(12) exchange with Gatekeeper 1. Endpoint 1 sends a Setup (13) message tothe Gatekeeper’s Call Signalling Channel Transport Address. Gatekeeper 2 sends the Setup (14) messageto endpoint 2. Endpoint 2 initiates the ARQ (15)/ACF (16) exchange with Gatekeeper 2. Endpoint 2 thenresponds with the Connect (18) message which contains its Control Channel Transport Address foruse in signalling. Gatekeeper 2 sends the Connect (19) message to endpoint 1 which may contain theendpoint 2 Control Channel Transport Address, or a Gatekeeper 2 (MC) Control ChannelTransport Address, based on whether the Gatekeeper chooses to route the Control Channel or 23:2743
Page 44Decided , 28 May 1996Endpoint 1Gatekeeper 1Gatekeeper 2Endpoint 2ARQ(1)ACF(2)Setup(3)Call Proceeding(4)ARQ(5)ARJ(6)Facility (7)Release Complete(8)DRQ(9)DCF(10)ARQ(11)ACF(12)Setup(13)Setup(14)Call Proceeding(4)Call Proceeding(4)ARQ(15)ACF/ARJ(16)Alerting(17)Alerting(17)Connect(18)Connect(19)RAS MessagesCall Signalling MessagesFigure 21/ Both Endpoint Registered - Direct / Routed Call SignallingIn the scenario shown in Figure 22/, both endpoints are registered to different Gatekeepers, the callingendpoint’s Gatekeeper chooses to route the call signalling, and the called endpoint’s Gatekeeper choosesDirect Call Signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2) exchange with Gatekeeper1. Gatekeeper 1 shall return a Call Signalling Channel Transport Address of itself in the ACF(2). Endpoint 1then sends the Setup (3) message using that Transport Address. Gatekeeper 1 then sends the Setup (4)message containing its Call Signalling Channel Transport Address to the well known Call Signalling ChannelTransport Address of endpoint 2. If endpoint 2 wishes to accept the call, it initiates the ARQ (6)/ACF (7)exchange with Gatekeeper 2. It is possible that an ARJ (7) is received by endpoint 2, in which case it sendsRelease Complete to endpoint 1. Endpoint 2 responds to Gatekeeper 1 with the Connect (9) message whichcontains its Control Channel Transport Address for use in signalling. Gatekeeper 1 sends theConnect (10) message to endpoint 1 which may contain the endpoint 2 Control Channel TransportAddress, or a Gatekeeper 1 (MC) Control Channel Transport Address, based on whether theGatekeeper chooses to route the Control Channel or 23:2744
Page 45Decided , 28 May 1996Endpoint 1Gatekeeper 1Gatekeeper 2Endpoint 2ARQ(1)ACF(2)Setup(3)Setup(4)Call Proceeding(5)Call Proceeding(5)ARQ(6)ACF/ARJ(7)Alerting(8)Alerting(8)Connect(9)Connect(10)RAS MessagesCall Signalling MessagesFigure 22/ Both Endpoint Registered - Routed / Direct Call SignallingIn the scenario shown in Figure 23/, both endpoints are registered to different Gatekeepers, and bothGatekeepers choose to route the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2)exchange with Gatekeeper 1. Gatekeeper 1 shall return a Call Signalling Channel Transport Address ofitself in the ACF(2). Endpoint 1 then sends the Setup (3) message using that Transport 1 then sends the Setup (4) message to the well known Call Signalling Channel TransportAddress of endpoint 2. If endpoint 2 wishes to accept the call, it initiates the ARQ (6)/ACF (7) exchange withGatekeeper 2. If acceptable, Gatekeeper 2 shall return a Call Signalling Channel Transport Address of itselfin the ARJ(7) with a cause code rofu teCallToGatekeeper. Endpoint 2 replies to Gatekeeper 1 with aFacility (8) message containing the Call Signalling Transport Address of Gatekeeper 2. Gatekeeper 1 thensends the Release Complete (9) message to endpoint 2. Gatekeeper 1 sends a Setup (10) message toGatekeeper 2’s Call Signalling Channel Transport Address. Gatekeeper 2 sends the Setup (11) message toendpoint 2. Endpoint 2 initiates the ARQ (12)/ACF (13) exchange with Gatekeeper 2. Endpoint 2 thenresponds to Gatekeeper 2 with the Connect (15) message which contains its Control ChannelTransport Address for use in signalling. Gatekeeper 2 sends the Connect (16) message toGatekeeper 1 which may contain the endpoint 2 Control Channel Transport Address, or a Gatekeeper2 (MC) Control Channel Transport Address, based on whether the Gatekeeper 2 chooses to route Control Channel or not. Gatekeeper 1 sends the Connect (17) message to endpoint 1 which maycontain the Control Channel Transport Address sent by Gatekeeper 2, or a Gatekeeper 1 (MC) Channel Transport Address, based on whether the Gatekeeper 1 chooses to route the ControlChannel or 23:2745
Page 46Decided , 28 May 1996Endpoint 1Gatekeeper 1Gatekeeper 2Endpoint 2ARQ(1)ACF(2)Setup(3)Setup(4)Call Proceeding(5)Call Proceeding(5)ARQ(6)ARJ(7)Facility(8)Release Complete(9)Setup(10)Setup(11)Call Proceeding(5)Call Proceeding(5)ARQ(12)ACF/ARJ(13)Alerting(14)Alerting(14)Alerting(14)Connect(15)Connect(16)Connect(17)RAS MessagesCall Signalling MessagesFigure 23/ Both Endpoint Registered - Both Gatekeepers Routing Call Call Set-up via Gateway Inbound Call Set-upWhen an external terminal calls a LAN endpoint via the Gateway, call set-up between the Gateway and theLAN endpoint proceeds the same as the endpoint to endpoint call setup. The Gateway may need to issueCall Proceeding messages to the external terminal while establishing the call on the Gateway which cannot directly route an incoming SCN call to an endpoint shall be able to accepttwo stage dialing. For Gateways to networks (also , , and in mode), theGateway shall accept SBE numbers from the terminal. For Gateways to native mode networks, the Gateway shall accept putIndication messages from the these two cases, support of DTMF is optional. For Gateways to speech only terminals, the Gateway shallaccept DTMF numbers from the speech only terminal. These numbers will indicate a second stage dialingnumber to access the individual endpoint on the Gateway Outbound Call Set-upWhen a LAN endpoint calls an external terminal via the Gateway, call set-up between the LAN endpoint andthe Gateway proceeds the same as the endpoint to endpoint call setup. The Gateway will receive thedestination address in the Setup message. It will then use this address to place the outbound Gateway may issue Call Proceeding messages to the LAN endpoint while establishing the outgoing 23:2746
Page 47Decided , 28 May 1996The Progress Indicator information element is used to indicate that inter-networking is occuring. TheGateway shall issue a Progress indicator information element within the Alerting, Call Proceeding, orConnect messages. This information may also be sent in a Progress LAN endpoint shall send all addresses that it is calling in the Setup message. For example, a sixB channel call on the ISDN will require six addresses in the Setup message. The Gateway shallrespond to the Setup message with a Connect or Release Complete message as well as Alerting, CallProceeding, or Progress messages. Failure of the SCN call shall be reported to the LAN endpoint in theRelease Complete message. The use of multiple CRV values and multiple Setup messages is for furtherstudy. Addition of channels on the SCN during a call is for further LAN endpoint which is registered with a Gatekeeper should request sufficient call bandwidth in the ARQmessage for the aggregate of all SCN calls. If sufficient call bandwidth was not requested in the ARQmessage, the procedures of section , Bandwidth Changes, shall be followed in order to obtain additionalcall Gateway may advance to Phase B after placing the first call on the SCN. Additional calls for theadditional SCN numbers may be placed after the capability exchange with the Gateway andestablishment of audio communications with the SCN Call Setup with an MCUFor Centralized Multipoint Conferences, all endpoints exchange call signalling with the MCU. Call set-upbetween an endpoint and the MCU proceeds the same as the endpoint to endpoint call setup scenarios ofSections thru . The MCU may be the called endpoint or the calling a Centralized Multipoint Conference, the Control Channel is opened between the endpoints and theMC within the MCU. The audio, video, and data channels are opened between the endpoints and the MPwithin the MCU. In a Decentralized Multipoint Conference, the Control Channel is open between theendpoint and the MC (there may be many such Control Channels, one for each call). The Audio andVideo Channels should be multicast to all endpoints in the conference. The Data Channel shall be openedwith the Data an Ad Hoc Multipoint Conference where there is no MC within the endpoints, the Control Channelshall be routed through the Gatekeeper. Initially the Control Channel will be routed between theendpoints through the Gatekeeper. When the conference switches to multipoint, the Gatekeeper mayconnect the endpoints to an MC associated with the an Ad Hoc Multipoint Conference where one or both of the endpoints contains an MC, the normal callsetup procedures defined in Sections thru are used. The master slave determination procedure isused to determine which MC will be the active MC for the Call ForwardingAn endpoint wishing to forward a call to another endpoint may issue a Facility message indicating theaddress of the new endpoint. The endpoint receiving this Facility indication should send a Release Completeand then restart the Phase A procedures with the new Broadcast Call SetupThis section is for further 23:2747
Page 48Decided , 28 May Phase B - Initial communication and capability exchangeOnce both sides have exchanged call setup messages from Phase A,the endpoints shall establish the Channel. The procedures of are used over the Control Channel for the capabilityexchange and to open the media channels. Note: Optionally, the Control Channel may be set up bythe called endpoint on receipt of Setup, and by the calling endpoint on receipt of Alerting or Call the event that Connect does not arrive, or an endpoint sends Release Complete, the ControlChannel shall be system capabilities are exchanged by transmission of thte apabilitySet capability message shall be the first message master/slave determination procedure of shall take place as described in Section . Incases where both endpoints in a call have MC capability, the master slave determination is used fordetermining which MC will be the active MC for the conference. The active MC may then send themcLocationIndication procedure also provides master slave determination for opening bi-directional channels for the initial capability exchange or master/slave determination procedures fail, these should be retried atleast two additional times before the terminal abandons the connection attempt and proceeds to phase this exchange of capabilities, the endpoints shall proceed directly to the desired operating . Phase Phase C - Establishment of audiovisual communicationFollowing the exchange of capabilities and master slave determination, the procedures of shall thenbe used to open logical channels for the various information streams. The audio and video streams, whichare transmitted in the logical channels setup in , are transported over dynamic TSAP Identifiers usingan unreliable protocol (see ). Data communications which is transmitted in the logical channels setupin , are transported using a reliable protocol (see ).The openLogicalChannelAck returns the Transport Address that the receiving endpoint has assigned tothat logical channel. The transmitting channel shall then send the information stream associated with thelogical channel to that Transport the opening of logical channels for audio and videoh,2 2o5n0eM aximumSkewIndicationmessage shall be sent by the transmitter for each associated audio and video Mode changesDuring a session the procedures for changing channel structure, capability, receive mode etc. shall becarried out as defined in Recommendation Exchange of video by mutual agreementThe indicationv, ideoIndicateReadyToActivate, is defined in . Its use is optional, but when used theprocedure shall be as 1 has been set so that video is not transmitted unless, and until, endpoint 2 has also indicatedreadiness to transmit video. Endpoint 1 shall send the indviicdaetoioInnd icateReadyToActivate when theinitial capability exchange has been completed, but shall not transmit a video signal until it has receivedeitherv ideoIndicateReadyToActivate or incoming video from endpoint 23:2748
Page 49Decided , 28 May 1996An endpoint which has not been set in this optional way is not obliged to wait until receipt ofvideoIndicateReadyToActivate or video before initiating its video Media Stream Address DistributionIn unicast, the endpoint shall open logical channels to the MCU or other endpoint. Addresses are passed inthe openLogicalChannel and multicast, the multicast addresses are assigned by the MC and distributed to the endpoints in thecommunicationsModeCommand. It is the responsibility of the MC to allocate and assign unique multicastaddresses. The endpoint shall signal an open logical channel to the MC with a multicast address in theopenLogicalChannel. The MC shall forward thoep enLogicalChannel to each receiving multi-unicast, the endpoint must open logical channels to each of the other endpoints. TheopenLogicalChannel is sent to the MC and shall contain the terminal number of the endpoint for which thechannel is intended. The endpoint can match opae nLogicalChannelAck by Phase D: Call Bandwidth ChangesCall bandwidth is initially established and approved by the Gatekeeper during the admissions exchange. Anendpoint shall assure that the aggregate for all transmitted and received audio and video channels,excluding any RTP headers, RTP payload headers, LAN headers, and other overhead, is within thisbandwidth. Data and control channels are not included in this any time during a conference, the endpoints or Gatekeeper may request an increase or decrease in thecall bandwidth. An endpoint may change the bitrate of a logical channel without requesting a bandwidthchange from the Gatekeeper if the aggregate bitrate of all transmitted and received channels does notexceed the current call bandwidth. If the change will result in a aggregate bitrate that exceeds the currentcall bandwidth, the endpoint shall request a change in the call bandwidth from its Gatekeeper and awaitconfirmation prior to actually increasing any bitrate. A bandwidth change request is recommended when anendpoint will use a reduced bandwidth for an extended period of time, thus freeing up bandwidth for endpoint wishing to change its call bandwidth sends a Bandwidth Change Request (BRQ) message (1)tothe Gatekeeper. The Gatekeeper determines if the request is acceptable. The criteria for this determinationis outside the scope of this Recommendation. If the Gatekeeper determines that the request is notacceptable, it returns a Bandwidth Change Reject (BRJ) message (2) to endpoint. If the Gatekeeperdetermines that the request is acceptable, it returns a Bandwidth Change Confirm (BCF) message (2).If endpoint 1 wishes to increase its transmitted bitrate on a logical channel, it first determines if the callbandwidth will be exceeded. See Figure 24/. If it will, endpoint 1 shall request a bandwidth change (1and 2) from Gatekeeper 1. When the call bandwidth is sufficient to support the change, endpoint 1 sends acloseLogicalChannel (3) message to close the logical channel. It then re-opens the logical channel usingthe openLogicalChannel (4) specifying the new bitrate. If the receiving endpoint wishes to accept thechannel with the new bitrate, it must first assure that its call bandwidth is not exceeded by the change. If itis, the endpoint shall request a call bandwidth change (5 and 6) with its Gatekeeper. When the callbandwidth is sufficient to support the channel, the endpoint replieso pweinthL oagnic alChannelAck (7),otherwise, it responds witho apne nLogicalChannelReject indicating unacceptable 23:2749
Page 50Decided , 28 May 1996Gatekeeper 1Endpoint 1Endpoint 2Gatekeeper 2BRQ(1)BCF/BRJ(2)CloseLogicalChannel(3)OpenLogicalChannel(4)BRQ(5)BCF/BRJ(6)OpenLogicalChAck(7)Note: Gatekeeper 1 andGatekeeper 2 may bethe same 24/ Bandwidth Change Request - Transmitter ChangeIf the endpoint 1 wishes to increase its transmitted bitrate on a logical channel from endpoint 2 which itpreviously flow controlled to a lower bitrate, endpoint 1 first determines if the call bandwidth will beexceeded. See Figure 25/. If it will, endpoint 1 shall request a bandwidth change from Gatekeeper the call bandwidth is sufficient to support the change, endpoint 1fl oswenCdosn tar olCommand (3)to indicate the new upper limit on bitrate for the channel. If endpoint 2 decides to increase the bitrate on thechannel, it must first assure that its call bandwidth is not exceeded by the change. If it is, endpoint 2 shallrequest a call bandwidth change (4 and 5) with its Gatekeeper. When the call bandwidth is sufficient tosupport the channel, endpoint 2 will sendc ltohsee LogicalChannel (6) message to close the logicalchannel. It then re-opens the logical channel usinogp etnhLeo gicalChannel (7) specifying the new 1 should then accept the channel with the new bitrate, and it replies with anopenLogicalChannelAck (6).Gatekeeper 1Endpoint 1Endpoint 2Gatekeeper 2BRQ(1)BCF/BRJ(2)FlowControlCommand(3)BRQ(4)BCF/BRJ(5)CloseLogicalChannel(6)OpenLogicalChannel(7)OpenLogicalChAck(8)Note: Gatekeeper 1 andGatekeeper 2 may bethe same 25/ Bandwidth Change Request - Receiver ChangeA Gatekeeper wishing to change the transmitted bitrate of endpoint 1 sends a BRQ message to endpoint the request is for a decrease in bitrate, endpoint 1 shall always comply by reducing its aggregate bitrateand returning a BCF. Endpoint 1 may initiate the appropriate signalling to inform endpoint 2 that9/21/98 23:2750
Page 51Decided , 28 May 1996bitrates have changed. This will allow endpoint 2 to inform its Gatekeeper of the change. If the request isfor an increase, the endpoint may increase its bitrate when StatusIn order for the Gatekeeper to determine if an endpoint is turned off, or has otherwise enter a failure mode,the Gatekeeper may use the Information Request (IRQ) / Information Request Response (IRR) messagesequence (see ) to poll the endpoints at an interval decided by the manufacturer. The pollinginterval shall be greater than 10 seconds. This message may also be used by a diagnostic device asdescribed in Section Gatekeeper may want an endpoint to periodically send an unrequested IRR message. The Gatekeepermay indicate this to the endpoint by specifying the rate that this IRR is sent within the irrFrequency field ofthe Admission Confirm (ACF) message. An endpoint receiving this irrFrequency rate shall send an IRRmessage at that rate for the duration of the call. While this rate is in effect, the Gatekeeper may still sendIRQ messages to the endpoint which shall respond as described the duration of a call, an endpoint or Gatekeeper may periodically request call status from anotherendpoint. The requesting endpoint or Gatekeeper issues a Status Enquiry message. The Endpoint receivingthe Status Enquiry message shall respond with a Status message indicating the current call state. Thisprocedure may be used by the Gatekeeper in order to periodically check if a call is still active. Note that thisis a message sent on the Call Signalling Channel, and should not be confused with IRR which is aRAS message sent on the RAS Ad Hoc Conference ExpansionThe following procedures are optional for terminals and Gateways and mandatory for Ad Hoc Multipoint conference is one that can be expanded from a point-to-point conference involving anMC to a multipoint conference. First, a point-to-point conference is created between two endpoints (endpoint1 and endpoint 2). At least one endpoint, or the Gatekeeper must contain an MC. Once the point-to-pointconference has been created, the conference may be expanded to multipoint conference in two differentways. The first way is when any endpoint in the conference invites another endpoint (endpoint 3) into theconference by calling that endpoint through the MC. The second way is for an endpoint (endpoint 3) to joinan existing conference by calling an endpoint in the Hoc Conference expansion can take place when using either the Direct Call Signalling model or theGatekeeper Routed Call Signalling model. The Control Channel topology for the Direct Call Signallingmodel appears as:MCEndpoint 1Endpoint 2Endpoint 3The Control Channel topology for the Gatekeeper Routed Call Signaling model appears as:9/21/98 23:2751
Page 52Decided , 28 May 1996MCEndpoint 1GatekeeperEndpoint 3Endpoint 2In either case an MC must be present in the conference at the time of expansion to any number greater than2 procedures required to create a point-to-point conference and then expand the conference throughinvite and join, for each call model, is covered in the following should be noted that the call is ended by a failure of the entity that is providing the Direct Endpoint Call Signalling - Conference CreateEndpoint 1 creates a conference with endpoint 2 as follows:A1) Endpoint 1 sends a Setup message to endpoint 2 containing a globally unique CID = N andconferenceGoal = create according to the procedure in Section ) Endpoint 2 has the following options:A2a) If it wants to join the conference, it sends a Connect message with CID = N to endpoint 1. Inthis case it is either 1) not participating in another conference or 2) it is participating in anotherconference, it is capable of participating in multiple conferences at the same time, and the receivedCID = N does not match the CID of any of the conferences in which it is currently ) If it is in another conference with CID = M and can participate in only one conference at a timeit either 1) rejects the call by sending Release Complete indicating in-conference or 2) it can requestendpoint 1 to join the conference with CID = M by sending a Facility message indicatingrouteCallToMC with the Call Signalling Channel Transport Address of the endpoint containing theMC and CID = M of the ) If it does not wish to join this conference it rejects the call by sending Release Completeindicating ) If endpoint 2 enters the conference, endpoint 1 uses the transport address of the ControlChannel provided in the Connect message to open the Control Channel with endpoint ) The messages are then exchanged as described below:A4a) TerminalCapabilitySet messages are exchanged between the endpoints to determine theversion number of the used in order to parse the remaining received messages ) Using master/slave determination procedure, it is determined that Endpoint 2 is themaster. In the Gatekeeper-Routed model the master could be in the Gatekeeper’s MC. If the masterhas an MC, it becomes the Active MC. It may then senMdC tLhoec ationIndication to the otherendpoint(s). The MC may be active in the conference now, or when the user initiates the multipointconference function, at the choice of the 23:2752
Page 53Decided , 28 May 1996A4c) The master may send ttheerm inalNumberAssign message to the endpoints. The endpointsshall use the 8 bit terminal number, and not use the 8 bit MCU number, from the 16 bit numberassigned as the low 8 bits of the SSRC field in the RTP header. These low 8 bits in SSRC thenidentify the streams from a particular ) Since the capabilities of the receiver are known frToemrm thinea lCapabilitySet message, thetransmitter opens the logical channels. It shall senhd2 2o5n0eM aximumSkewIndication for eachpair of audio and video Direct Endpoint Call Signalling - Conference InviteThere are two cases of the conference invite. First, the endpoint which contains the active MC wishes toinvite another endpoint into the conference. Second, an endpoint which does not contain the active MCwishes to invite another endpoint into the a point-to-point conference has been established using procedures A1 to A4, an endpoint (endpoint 2)containing the active MC wishing to add another endpoint to the conference, shall use the followingprocedure:B1) Endpoint 2 sends a Setup message to endpoint 3 with CID = N and conferenceGoal = inviteaccording to the procedures in Section . See Figure 26/) Endpoint 3 has the following options:B2a) If it wishes to accept the invitation to join the conference, it sends a Connect message with CID= N to endpoint ) If it wishes to reject the invitation to join the conference, it sends a Release Complete messageindicating destinationBusy to endpoint ) If it is in another conference with CID = M, it can request endpoint 2 to join the conference withCID = M by sending a Facility message indicating routeCallToMC with the Call Signalling ChannelTransport Address of the endpoint containing the MC and CID = M of the ) If the received CID matches the CID of a conference that endpoint 3 is currently participatingin, it shall reject the call by sending Release Complete indicating that it is already in the ) If endpoint 3 accepts the invitation, endpoint 2 uses the transport address of the Control Channelprovided in the Connect message to open the Control Channel with endpoint ) The messages are then exchanged as described below:C1) TerminalCapabilitySet messages are exchanged between the MC and endpoint ) Using master/slave determination procedure, it is determined that endpoint 2 is alreadythe active MC. The MC may then sendM thCeL ocationIndication to the endpoint )The MC shall sendm ultipointModeCommand at this time to all the three ) The MC may send thtee rminalNumberAssign message to endpoint 3. If received, theendpoints shall use the 8 bit terminal number, and not use the 8 bit MCU number, from the 16 bitnumber assigned as the low 8 bits of the SSRC field in the RTP header. These low 8 bits in SSRCthen identify the streams from a particular 23:2753
Page 54Decided , 28 May 1996C5) An endpoint can get the list of the other endpoints in the conference by sending theterminalListRequest message to the MC. The MC responds witht etrhme ) Whenever a new endpoint joins the conference, the MC sentdesrm tihnea lNumberAssignmessage to endpoint 4 atnedrm inalJoinedConference message to endpoints 1, 2, and ) Whenever an endpoint leaves the conference, the MC tseermndinsa lLeftConference to theremaining ) The MC shall send thceo mmunicationModeCommand to all the endpoints in the ) Endpoint 1 and endpoint 2 will close their logical channels that were created during the point-to-point conference if they are inconsistent with the information contained in ) The logical channels can now be opened between the MC and the 2 (E2)Endpoint 3 (E3)Setup (E3, CID=N, invite)Alerting / Call ProcedingConnect (E3 TA)Figure 26/ MC Invite SignallingAfter a point-to-point conference has been established using procedures A1 to A4, an endpoint (endpoint 1)that does not contain the active MC wishing to add another endpoint to the conference, shall use thefollowing procedure:B1)Endpoint 1 sends a Setup message to the MC (endpoint 2) with a new CRV indicating a call toendpoint 3 by providing the transport address of endpoint 3, CID = N, and conferenceGoal = Figure 27/) Endpoint 2 sends a Setup message to endpoint 3 with CID = N and conferenceGoal = inviteaccording to the procedures in Section ) During call signalling with endpoint 3, endpoint 2 shall pass Call Signalling messages receivedfrom endpoint 3, including Connect, to endpoint 1 (the original inviter).B4) Endpoint 3 has the same options, described previously, of either accepting or rejecting 23:2754
Page 55Decided , 28 May 1996B5) At some time after the completion of the call setup procedure between endpoint 2 and endpoint3, endpoint 2 shall send a Release Complete message to endpoint ) If endpoint 3 accepts the invitation, endpoint 2 uses the transport address of the Control Channelprovided in the Connect message to open the Control Channel with endpoint ) The messages are then exchanged as previously described in procedures C1 to 1 (E1)Endpoint 2 (E2)Endpoint 3 (E3)Setup (E3, CID=N, invite)Setup (E3, CID=N, invite)Alerting / Call ProcedingAlerting / Call ProcedingConnect (E3 TA)Connect (E3 TA)Release Complete (cause)Figure 27/ Non-MC Invite Endpoint Call Signalling - Conference JoinThere are two cases of the conference join. First, an endpoint calls the endpoint which contains the activeMC. Second, an endpoint calls an endpoint which is not the active a point-to-point conference has been established using procedures A1 to A4, an endpoint (endpoint 3)wishing to join a conference may attempt to connect with the endpoint containing the active MC in theconference. In this case, the following procedure shall be ) Endpoint 3 sends a Setup message to endpoint 2 with CID = N, and conferenceGoal = joinaccording to the procedure in Section . See Figure 28/) If the CID matched the CID of an active conference in the MC, endpoint 2 (MC) has thefollowing options:B2a) If it decides that endpoint 3 should be allowed to join the conference, it sends the Connectmessage with CID = ) If it decides that endpoint 3 should not be allowed to join the conference, it sends the ReleaseComplete message with ) If the CID does not match the CID of an active conference in the MC, endpoint 2 shall sendRelease Complete indicating a bad 23:2755
Page 56Decided , 28 May 1996B4) If endpoint 2 allows the join, endpoint 2 opens the Control Channel with endpoint ) The messages are then exchanged as previously described in procedures C1 to 2 (E2)Endpoint 3 (E3)Setup (E3, CID=N, join)Alerting /Call ProcedingConnect (E2 TA)Figure 28/ MC Join SignallingAfter a point-to-point conference has been established using procedures A1 to A4, an endpoint (endpoint 3)wishing to join a conference may attempt to connect with an endpoint that does not contain the active MC inthe conference. In this case, the following procedure shall be ) Endpoint 3 sends a Setup message to endpoint 1 with CID = N, and conferenceGoal = joinaccording to the procedure in Section . See Figure 29/) Endpoint 1 returns a Facility message indicating routeCallToMC with the Call Signalling ChannelTransport Address of endpoint 2 (containing the active MC) and the CID = N of the ) Endpoint 3 then sends a Setup message to endpoint 2 (MC) with CID = N and conferenceGoal =join as described in the previous conference join 23:2756
Page 57Decided , 28 May 1996Endpoint 1 (E1)Endpoint 3 (E3)Endpoint 2 (E2)Setup (E1, CID=N, join)Facility (cause,E2)Release Complete (cause)Setup (E2, CID=N, join)Alerting / Call ProcedingConnect (E2 TA)Figure 29/ Non-MC Join Gatekeeper Routed Call Signalling - Conference CreateIn cases where the Gatekeeper routes the Call Signalling Channel and the Control Channel, theGatekeeper should contain (or have access to) an MC or MCU. Procedures A1 to A4 are used to establishthe point-to-point call. During Master/Slave determination (A4b), if the GattekrmeeinpaelrT’sy pe is greaterthan the terminalType received from an endpoint in tmhaes terSlaveDetermination message, theGatekeeper may replace the endpotinertm’s inalType value with its own before forwarding the message tothe destination endpoint. If the Gatekeetpeermrsi nalType is not greater than thter minalType of theendpoint, the Gatekeeper shall not modiftye rtmhein alType value. In effect, the Gatekeeper is performingthe master slave determination procedure with each endpoint. If the Gatekeeper wins the master slavedetermination with both endpoints, the MC associated with the Gatekeeper shall be the active MC,otherwise, one of the endpoints shall be the active Gatekeeper Routed Call Signaling - Conference InviteAfter a point-to-point conference has been established using procedures A1 to A4 as modified above, anendpoint (endpoint 1 or 2) that does not contain the active MC wishing to add another endpoint to theconference, shall use the following procedure:B1)Endpoint 1 sends a Setup message through the Gatekeeper directed to endpoint 3 with a newCRV, CID = N, and conferenceGoal = invite. See Figure 30/) The Gatekeeper (MC) sends a Setup message to endpoint 3 with CID = N and conferenceGoal= invite according to the procedures in Section ) During call signalling with endpoint 3, the Gatekeeper shall pass Call Signalling messagesreceived from endpoint 3, including Connect, to endpoint 1 (the original inviter).B4) Endpoint 3 has the same options, described previously, of either accepting or rejecting 23:2757
Page 58Decided , 28 May 1996B5) At some time after the completion of the call setup procedure between the Gatekeeper andendpoint 3, the Gatekeeper shall send a Release Complete message to ) If endpoint 3 accepts the invitation, the Gatekeeper uses the transport address of the ControlChannel provided in the Connect message to open the Control Channel with endpoint ) The messages are then exchanged as previously described in procedures C1 to C10 withthe Gatekeeper taking part in all master slave determination procedures as the active MC (C2). Atthis time, the Control Channels from the endpoints should be connected to the MC, and the MCshould be in control of the 1 (E1)GatekeeperEndpoint 3 (E3)Setup (E3, CID=N, invite)Setup (E3, CID=N, invite)Call Proceeding/AlertingCall Proceeding/AlertingConnect (E3 TA)Connect (GK TA)Release Complete (cause)Figure 30/ Gatekeeper Routed invite Gatekeeper Routed Call Model - Conference JoinAfter a point-to-point conference has been established using procedures A1 to A4 as modified above, anendpoint (endpoint 3), wishing to join a conference may attempt to connect with an endpoint that does notcontain the active MC in the conference. In this case, the following procedure shall be ) Endpoint 3 sends a Setup message through the Gatekeeper directed to endpoint 1 with CID = N,and conferenceGoal = join according to the procedure in Section . See Figure 31/) If the CID matched the CID of an active conference in the MC, the Gatekeeper (MC) has thefollowing options:B2a) If it decides that endpoint 3 should be allowed to join the conference, it sends the Connectmessage with CID = N to endpoint ) If it decides that endpoint 3 should not be allowed to join the conference, it sends the ReleaseComplete message with ) The Gatekeeper may forward the Setup message to endpoint 1. Endpoint 1 may respond with aFacility message indicatirnogu teCallToMC or it it may respond with a release 23:2758
Page 59Decided , 28 May 1996B3) If the CID does not match the CID of an active conference in the MC, the Gatekeeper shall sendRelease Complete indicating a bad ) If the Gatekeeper allows the join, the Gatekeeper uses the transport address of the ControlChannel provided in the Setup message to open the Control Channel with endpoint ) The messages are then exchanged as previously described in procedures C1 to C10 withthe Gatekeeper taking part in all master slave determination procedures as the active MC (C2). Atthis time, the Control Channels from the endpoints should be connected to the MC, and the MCshould be in control of the 3 (E3)GatekeeperEndpoint 1 (E1)Setup (E1, CID=N, join)Call Proceeding/AlertingConnect (GK TA)Figure 31/ Gatekeeper Routed Join Supplementary ServicesProvisions have been made within this Recommendation to allow endpoints to the use the SupplementaryServices as defined in , , and the series of Recommendations. These services shall usethe Call Signalling Channel and messages. These services may provide features such as hold,transfer, forward, and methods of providing supplementary services are for further Phase E: Call terminationEither endpoint may terminate a call by the following procedure:1)It should discontinue transmission of video at the end of a complete picture, and then close alllogical channels for 23:2759
Page 60Decided , 28 May 19962)It should discontinue transmission of data and then close all logical channels for )It should discontinue transmission of audio and then close all logical cha anundeilos. for4)It shall transmit the SessionCommand message in the Control Channel, indicatingto the far end that it wishes to disconnect the call and then discontinue message )It shall then wait to receive ethndeS essionCommand message from the other endpoint and thenshall close the Control )If the Call Signalling Channel is open, a Release Complete message shall be sent and the )It shall clear the call by using the procedures d endpoint receivinegn dSessionCommand without first having transmitted it, shall carry out steps 1) to 7)above, except that in step 5, it shall not wait feonrd tShees sionCommand from the first a call may not terminate a conference; a conference may be explicitly terminated using messaged (ropConference). In this case, the endpoints shall wait for the MC to terminate the calls asdescribed Call Clearing without a GatekeeperIn networks that do not contain a Gatekeeper, after steps 1 to 6 above, the call is terminated. No furtheraction is Call Clearing with a GatekeeperIn networks that contain a Gatekeeper, the Gatekeeper needs to know about the release of bandwidth. Afterperforming steps 1 to 6 above, each endpoint shall transmit an Disengage Request (DRQ) message(3) to its Gatekeeper. The Gatekeeper shall respond with a Disengage Confirm (DCF) message (4). Aftersending the DRQ message, the endpoints shall not send further unsolicited IRR messages to theGatekeeper. See Figure 32/. At this point the call is terminated. This figure shows the direct callmodel, a similar procedure is followed for the Gatekeeper routed DRQ and DCF messages shall be sent on the RAS 23:2760
Page 61Decided , 28 May 1996Gatekeeper 1Endpoint 1Endpoint 2Gatekeeper 2EndSessionCommand(1)EndSessionCommand(1)Release Complete (2)DRQ(3)DRQ(3)DCF(4)DCF(4)RAS messagesNote: Gatekeeper 1 andCall Signalling messagesGatekeeper 2 may messagesthe same 32/ Endpoint Initiated Call Call Clearing by GatekeeperThe Gatekeeper may terminate a call by sending a DRQ to an endpoint. See Figure 33/. Theendpoint shall immediately follow steps 1 through 6 from above and then reply to the Gatekeeper with other endpoint, upon receiveindgS essionCommand shall follow the procedure described above. Thisfigure shows the direct call model, a similar procedure is followed for the Gatekeeper routed the conference is a multipoint conference, the Gatekeeper should send a DRQ to each endpoint in theconference, in order to close the entire 1Endpoint 1Endpoint 2Gatekeeper 2DRQ(3)EndSessionCommand(1)EndSessionCommand(1)Release Complete (2)DCF(4)DRQ(3)DCF(4)RAS messagesNote: Gatekeeper 1 andCall Signalling messagesGatekeeper 2 may messagesthe same 33/ Gatekeeper Initiated Call Protocol Failure HandlingThe underlying reliable protocol of the Control Channel uses appropriate effort to deliver or receivedata on the channel before reporting a protocol failure. Therefore, if a protocol failure is reported on the9/21/98 23:2761
Page 62Decided , 28 May 1996channel, the Control Channel, and all associated logical channels shall be closed. This shall be donefollowing the procedures of Phase E, as if the other endpoint had issued theen includes transmission of the DRQ message to the Gatekeeper and termination of the Call SignallingChannel. In the case where the failure is detected by the MC in a multipoint conference, the MC shall sendterminalLeftConference messages to the remaining terminals. It is up to the implementation whether ornot to try to re-establish the call without user intervention. In any case, this would appear to the otherendpoint (and the Gatekeeper) as a new Call Signalling Channel also uses an underlying reliable protocol. Depending on the routing of the CallSignalling Channel, either the Gatekeeper or an endpoint may detect the protocol failure. If the Gatekeeperdetects the failure, it shall attempt to re-establish the Call Control Channel. This implies that the endpointshall always have the ability to establish a channel on its Call Signalling Channel Transport Address. Failureof the Call Signalling channel shall not change the call state. After re-establishment of the CallSignalling Channel, the Gatekeeper may send a Status message to request the call state of the endpoint toassure that they are in the endpoint detects the failure, the endpoint may choose to terminate the call as described in Phase E, orit may attempt to re-establish the Call Signalling Channel as described during a call, an endpoint wants to determine if the other endpoint is still functioning and connected, is maysend the undTripDelayRequest. Since Control Channel is carried on a reliable channel, thiswill result in a response from the other endpoint or an error from the transport interface. In the latter case,the procedures described above shall be used. An endpoint in a multipoint conference may use the samemechanism; however it will learn only whether it still has a connection to the MC. Note that it is possible foran endpoint to have an error-free connection with the MC but still be receiving no audio or video from therest of the terminals in the Interoperation with other terminal typesInteroperation with other terminals shall be accomplished through the Gateway. .Section Speech only terminalsInteroperation with speech only terminals (telephony) over the ISDN or GSTN can be provided by:1) using a -ISDN speech ) using a -GSTN speech Gateway should consider the following issues:- Audio code : If desired, since ISDN uses : from analog to - Bitstream : to/from unframedGSTN: genearte - Control conversion. (Generate )- Call Control Signalling conversion.- DTMF tone conversion to/from InputIndication Visual telephone terminals over the ISDN ()Interoperation with visual telephone terminals over the ISDN () can be provided by:9/21/98 23:2762
Page 63Decided , 28 May 19961) using a Gateway should consider the following issues:- Video format conversion. (if desired, is mandatory for both terminal types.)- Audio code conversion. (if desired, is mandatory for both terminal types.)- Data protocol conversion.- Bitstream conversion. ( to/from )- Control conversion. ( to/from )- Call Control Signalling conversion.- SBE Number conversion to/from InputIndication Visual telephone terminals over GSTN ()Interoperation with visual telephone terminals over the GSTN () can be provided by two methods:1) using a ) using a Gateway assuming that there exists an ISDN/GSTN Interworking Unit in Gateway should consider the following issues:- Video format conversion. (if desired, is mandatory for both terminal types.)- Audio code conversion. ( is mandatory for terminal, is mandatory for .)- Data protocol conversion.- Bitstream conversion. ( to/from )- Call Control Signalling Visual telephone terminals over Mobile Radio ( further Visual telephone terminals over ATM ()Interoperation with visual telephone terminals over ATM networks () can be provided by two methods:1) using a ) using a Gateway assuming that there exists an ISDN/ATM Interworking Unit inthe Gateway should consider the following issues:- Video format conversion. (if desired, is mandatory for both terminal types.)- Audio code conversion. (if desired. is mandatory for both terminal types.)- Data protocol conversion.- Bitstream conversion. ( to/from )- Control conversion. ( to/from )- Call Control Signalling 23:2763
Page 64Decided , 28 May Visual telephone terminals over Guaranteed Quality of Service LANs ()Interoperation with visual telephone terminals over Guaranteed Quality of Service LANs () can beprovided by:1) using a Gateway assuming that there exists a GQOS LAN-ISDN Gateway in Gateway should consider the following issues:- Video format conversion. (if desired, is mandatory for both terminal types.)- Audio code conversion. (if desired, is mandatory for both terminal types)- Data protocol conversion.- Bitstream conversion. ( to/from )- Control conversion. ( to/from )- Call Control Signalling Simultaneous Voice and Data Terminals over GSTN ()Interoperation wiSthim ultaneous Voice and Data Terminals over GSTN ( )b e provided by:1) using a Gateway should consider the following issues:- Audio code conversion. ( to/from Annex A)- Data protocol conversion.- Bitstream conversion. ( to/from Control conversion. (both terminals use )- Call Control Signalling Terminals on the LANAn terminal that has capability should be capable of being configured as a Only terminalwhich listens and transmits on the standard well known TSAP Identifier. This will allow the terminal to participate in only only terminal on the LAN shall be able to participate in the portion of multipoint . See Section further for maintenance purposesSome loopback functions are defined in to allow verification of some functional aspects of theterminal, to ensure correct operation of the system and satisfactory quality of the service to the remote 23:2764
Page 65Decided , 28 May 1996The systemLoop request andlo gicalChannelLoop request shall not be used. Tmhed iaLoop request isoptional. An endpoint that receives mthaein tenanceLoopOffCommand shall turn off all loopbackscurrently in the purpose of loopbacks, two modes are defined:a)Normal operation mode: no loopback. Indicated in (a) of Figure 34/. This shall be the defaultmode, and the mode entered whenm tahien tenanceLoopOffCommand is )Media loop mode: loopback of media stream at the analogr If/aOc ein. tUepon receiving thmee diaLooprequest as defined in , loopback of the content of the selected logical channel shall be activated asclose as possible to the analog interface of the video/audio codec towards the video/audio codec, so thatdecoded and re-coded media content is looped, as indicated in (b) Figure . 3 4T/ 2lo3opback isoptional. It should be used only when a single logical channel containing the same media type is openedin each direction. Operation when multiple channels are opened in the return direction is ) NormalNetworkCodecInterfaceb) Media loopNetworkCodecInterfaceFIGURE 34/ - Loop backA Gateway to which receives an mLoop request, gicalChannelLooprequest, or a Gateway to , which receives an Dig-Loop command from an SCN endpoint mayperform the appropriate loopback function within the Gateway. The Gateway shall not pass these requeststo the LAN endpoint. A Gateway to receivingm oop from an SCN endpoint shallpass the request to the LAN endpoint. A Gateway to , receiving Vid-loop or Au-loop commandfrom an SCN endpoint shall convert it to the appropriatem op request and send it to the Gateway to , which receives an aLoop request from a LAN endpoint shall convert it tothe appropriate Vid-loop or Au-loop command and send it to the SCN Gateway to may send an mLoop request or gicalChannelLooprequest to the SCN endpoint. A Gateway to , may send an Dig-Loop command to the SCNendpoint. If a LAN endpoint is in a call to the SCN endpoint, the audio and video sent to the LAN endpointmay be the looped back audio or video, pre-recorded audio or video message indicating the loopbackcondition, or no audio or 23:2765
Page 66Decided , 28 May Monitoring MethodsAll terminals shall support the Information Request/Information Request Response (IRQ/IRR) message . The Information Request Response message contains the TSAP Identifier of all channels currentlyactive on the call, including and control, as well as audio and video. This information can beused by third party maintenance devices to monitor conferences to verify system 23:2766
Page 67Decided , 28 May 1996ANNEX MESSAGES USED BY ENDPOINTSThe following rules apply to the use of messages by endpoints:An endpoint shall not malfunction or otherwise be adversely affected by receiving messages that itdoes not recognize. An endpoint receiving an unrecognized request, response, or command shall return“function not supported”. (This is not required for indications)The following abbreviations are used in the table: M = Mandatory, O = Optional, F = Forbidden to message marked as mandatory for the receiving endpoint indicates that the endpoint shall accept themessage and take the appropriate action. A message marked as mandatory for the transmitting endpointindicates that the endpoint shall generate the message under the appropriate . Master Slave Determination MessagesMessageReceivingTransmittingEndpointEndpointStatusStatusDeterminationMMDetermination AcknowledgeMMDetermination RejectMMDetermination ReleaseMMB. Terminal Capability MessagesMessageReceivingTransmittingEndpointEndpointStatusStatusCapability SetMMCapability Set AcknowledgeMMCapability Set RejectMMCapability Set ReleaseMMC. Logical Channel Signalling Messages9/21/98 23:2767
Page 68Decided , 28 May 1996MessageReceivingTransmittingEndpointEndpointStatusStatusOpen Logical ChannelMMOpen Logical Channel AcknowledgeMMOpen Logical Channel RejectMMOpen Logical Channel ConfirmMMClose Logical ChannelMMClose Logical Channel AcknowledgeMMRequest Channel CloseMORequest Channel Close AcknowledgeOORequest Channel Close RejectOMRequest Channel Close ReleaseOMD. Multiplex Table Signalling MessagesMessageStatusMultiplex Entry SendFMultiplex Entry Send AcknowledgeFMultiplex Entry Send RejectFMultiplex Entry Send ReleaseFE. Request Multiplex Table Signalling MessagesMessageStatusRequest Multiplex EntryFRequest Multiplex Entry AcknowledgeFRequest Multiplex Entry RejectF9/21/98 23:2768
Page 69Decided , 28 May 1996Request Multiplex Entry ReleaseFF. Request Mode MessagesMessageReceivingTransmittingEndpointEndpointStatusStatusRequest ModeMORequest Mode AcknowledgeMORequest Mode RejectOMRequest Mode ReleaseOMG. Round Trip Delay messagesMessageReceivingTransmittingEndpointEndpointStatusStatusRound Trip Delay RequestMORound Trip Delay ResponseOMH. Maintenance Loop MessagesMessageReceivingTransmittingEndpointEndpointStatusStatusMaintenance Loop RequestSystem LoopFFMedia LoopO(Note 1)O(Note 1)Logical Channel LoopFF9/21/98 23:2769
Page 70Decided , 28 May 1996Maintenance Loop AcknowledgeOOMaintenance Loop RejectOMMaintenance Loop Command OffMONote 1: Mandatory in . CommandsMessageReceivingTransmittingEndpointEndpointStatusStatusSend Terminal Capability SetMMEncryptionOOFlow ControlMOEnd SessionMMMiscellaneous CommandsEqualize DelayOOZero DelayOOMultipoint Mode CommandMOCancel Multipoint Mode CommandMOVideo Freeze PictureMOVideo Fast Update PictureMOVideo Fast Update GOBMOVideo Fast Update MBMOVideo Temporal Spatial Trade OffOOVideo Send Sync Every GOBOOVideo Send Sync Every GOB CancelOOMCLocationIndicationMOTerminal ID RequestOO9/21/98 23:2770
Page 71Decided , 28 May 1996Terminal List RequestOObroadcast meOOcancel Broadcast MeOOMake Terminal BroadcasterOOSend This SourceOOCancel Send This SourceOODrop TerminalOOMake Me ChairOOCancel Make Me ChairOODrop ConferenceOOEnter PasswordOOEnter Terminal IdOOEnter Conference IDOORequest Terminal IDOOTerminal ID ResponseOOTerminal List ResponseOOVideo Command RejectOOMake Me Chair ResponseOOJ. Conference Mode CommandsMessageReceivingTransmittingEndpointEndpointStatusStatusCommunication Mode CommandMOCommunication Mode RequestOOCommunication Mode ResponseOO9/21/98 23:2771
Page 72Decided , 28 May 1996K. IndicationsMessageReceivingTransmittingEndpointEndpointStatusStatusFunction Not SupportedMMMiscellaneous IndicationLogical Channel ActiveOOLogical Channel InactiveOOMultipoint ConferenceMOCancel Multipoint ConferenceMOMultipoint Zero CommOOCancel Multipoint Zero CommOOMultipoint Secondary StatusOOCancel Multipoint Secondary StatusOOVideo Indicate Ready to ActivateOOVideo Temporal Spatial Trade OffOOSBE NumberOOTerminal Number AssignMOTerminal Joined ConferenceOOTerminal Left ConferenceOOSeen By At Least One OtherOOCancel Seen By At Least One OtherOOSeen By AllOOCancel Seen By AllOOTerminal You Are SeeingOO9/21/98 23:2772
Page 73Decided , 28 May 1996Request For FloorOOJitter Skew IndicationFFH2250MaximumSkewIndicationOMNew ATM Virtual Channel IndicationFFUser InputM (for 0-9, *M (for 0-9, *and #)and #)non-standard commands, requests, etc are 23:2773
Page 74Decided , 28 May 1996APPENDIX AINFORMATIVEPROCESSING OF MESSAGES IN GATEWAYSThe Gateway shall terminate the Call Signalling Channel between an endpoint and theGateway on one hand and the call signaling channel (if any) between the Gateway and the SCN endpoint onthe other. The following applies only if the SCN side supports a call signalling protocol such as Gateway shall conform to the call signalling procedures recommended for the SCN side independentfrom the LAN side. The Gateway shall conform to the call signalling procedures of this Recommendation forthe LAN side independent from the SCN addition, call signalling messages received from one side (LAN/SCN) may require forwarding to the otherside (SCN/LAN). Some forwarded messages may contain information elements or parts of informationelements which are unmodified or uninterpreted by the Gateway. Other forwarded messages may containinforation elements or parts of information elements may be added or removed by the Gateway, as the following, an overview of the actions to be taken by the gateway in response to messages andthe information elements, is provided. Messages and information elements that are forbidden in arenot messages originating on the side:•A SETUP message side shall lead to initiation of call setup procedure for the SCN side.•A RELEASE COMPLETE shall lead to initiation of the call disconnect as defined for the SCNside.•A CALL PROCEEDING message shall be forwarded to the SCN side. This shall not be done if aCALL PROCEEDING has been sent before to the SCN in compliance to the respective SCNspecification ( in the ISDN case).•A CONNECT message shall be forwarded to the SCN side upon receipt from an endpoint.•A CONNECT ACKNOWLEDGE message shall be forwarded to the SCN side upon receipt. Thisshall not be done if CONNECT ACKNOWLEDGE has been sent before to the SCN incompliance to the respective SCN specification. If the gateway has sent a CONNECT to endpoint and has not received the corresponding CONNECT ACKNOWLEDGE from endpoint within the time frame required for successful completion of the call, it shallgenerate the CONNECT ACKNOWLEDGE to the SCN side as appropriate to comply to the SCNcall setup procedures.•Messages for supplementary services (FACILITY, HOLD, HOLD ACKNOWELDGE, HOLDREJECT, RETRIEVE, RETRIEVE ACKNOWLEDGE, RETRIEVE REJECT and theINFORMATION messages) that are not processed by the Gateway, shall be forwarded to theSCN side.•All messages forbidden to be originated from an endpoint shall be generated by theGateway autonomously as required by the SCN information elements of the respective messages are to be converted as follows:9/21/98 23:2774
Page 75Decided , 28 May 1996•The contents of connection specific information elements (such as Call Reference Value) shallbe adapted as required by the SCN protocol.•Information elements that are not in use on the side shall be generated by the Gateway asrequired by the SCN protocol.•Translation of other information elements shall be done as required by the SCN protocols andprocedures. Where interoperability is not an issue, conversion is left to the discretion of themanufacturer.•Only the user-data part of the user-user information element shall be forwarded to the SCN shall be re-encoded following Figure 4-36/ and Table 4-26/ messages originating on the SCN side are forwarded to the endpoint without modificationexcept for the following:•Messages forbidden by shall not be passed to the side.•The call reference value is mapped to the appropriate value for the side.•The user data field is copied into the corresponding user-user information elementstructure.•The user-user information element structure shall be generated according to the specification 23:2775
