The set of standards that go together to make up the full range of ITU conferencing control facilities is very complex. A basic list of what has to be implemented is listed in table 7.3.
Document ; What it defines
H.221,222,223 ; multiplexing video and audio.
T.120 ; telematics (e.g. white-board) transmission protocols
H225 ; Media Stream Packetization and Synchronisation for Non-Guaranteed QoS LANs
H245 ; Control Protocol for Multimedia Communication
H.310 ; overall broadband systems for a/v terminals
H.320 ; N-ISDN terminals
H.321 ; B-ISDN version of H.320
H.322 ; H.320 for LANs with QoS (new IEEE 802 standards)
H.323 ; H.320 for LANs without QoS (i.e. Internet)
H323 defines the overall structure of ITU System for conferencing terminals including Terminals, Gateways (to non packet nets or to QoS guaranteeing packet nets:), Multipoint Controllers, Multipoint Processors and Multipoint Control Units. It rests on a family of other protocols which do the actual work - i.e. its a framework. Interoperability with H.324, H.322 (qos LAN), H.320 (ISDN) and H.321 (B-ISDN) is via the gateways.
Multipoint Controllers serve functions that are based on IGMP and other group management functions up to the H.232 application level, Multipoint processors serve functions of mixing, multiplexing and basically getting between unicast sources and multicast delivery. Multipoint Control Units may incorporate some or all these functions, as well as some conference control functions which are also present in all H.323 terminals too and gateways.
H.323 terminals would typically be TCP/IP hosts (PCs) with RTP/UDP stacks to carry H.261 (or H.263 or other coded video) and G.711 (or 722, 723, 728, 729) coded audio - in the ITU view, the T.120 stack is used for conferencing "data" applications. (see later). To carry out tasks of assigning control and data flows to the right port/address (TSAP in ISO/ITU parlance), the H.225 protocol is used.
On ISDN, H.221 (or similar) is used to multiplex audio and video (and data) onto a virtual circuit. In a packet LAN, we may want separate recovery mechanisms and different levels of reliability for data and video/audio stream (and conference control) so H.221, with its rigid, TDM-like bit level multiplexing is inappropriate. Instead, H.225 is provided. It makes use of underlying transport as much as possible - i.e. again, like H.323, of which it is part, its mainly a framework. It makes use of RTP/UDP (and IGMP/IP multicast) as well as TCP. An important part of H.225 is Registration, Admissions and Services (``RAS''). This serves some of the functions of DNS (as described in chapter one) and some of the functions of SAP/SDP/SIP (as described in chapter six). RAS messages are used to tell gatekeepers about H.323 terminals. RAS interacts, if needed, with Q931 signaling protocols to setup calls. Once a call is setup, a terminal will have a TCP connection to then proceed with H.245 messages to carry out next level up functions. For media, H.225 selects appropriate TSAP Ids (i..e UDP ports and multicast addresses) to use.
So H.225 uses Q.931 first - i.e. call establishment and clearing via Alerting, proceeding, connect, connect acknowledge, progress, setup, setup acknowledge, and Disconnect, Release, Release Complete messages. Q.932 can be used to get more IN like facilities - e.g. Hold, Hold Acknowledge, Hold Reject, Retrieve, Retrieve Acknowledge, Retrieve Reject. On a packet LAN, clearly Q.931 and so on, are not carried on a separate signaling channel (e.g. on N-ISDN or B-ISDN, there is a pre-agreed circuit for signaling messages- the D channel in narrow band ISDN gives a free 14 Kbps or so for this). On a packet LAN, messages must go on the LAN, and must be reliable, so TCP is used to a well known port. H.225 defines what the fields in the Q.931 messages (in the TCP data packets) carry - e.g. called and calling party addresses - obviously, again, on the LAN, if an H.323 terminal is being called (and not a H.321 ISDN terminal the other side of a gateway for example) then there is no called address in the sense of "p
User-to-user data in the Q.931 messages (in the TCP data messages on IP on the LAN) can carry lots of information - e.g. arbitrary "key pad" data (can use a phone style interface)
More importantly, the user-to-user field is used to carry complex messages encoded In ASN.1 [expand on ASN.1] to carry higher level (H.323, H.245) information. This Setup carries protocol id H.245 transport address source address and information active MC (which is an end point under control from an MC - see above and later) conference ID conference goal (create, join, invite, etc) call type (point-to-point, multicast, bandwidth!) Further messages that are conveyed according to the H.225 specification, include RAS messages, again, specified in ASN.1 (encoded in BER), and carried in user-to-user part of Q.931 messages over the TCP connection that was setup for this.
RAS message types include: gatekeeper request, confirm, reject registration request, confirm reject unregistration request confirm reject admission request, confirm, reject, bandwidth disengage location info and so on. As can be seen, then, these are mainly concerned with support for connecting with gateways that provide interworking, between packet LAN and conferencing systems the other side of the gateway. Once all this is done we can carry out some conferencing - this requires video and audio, and conference control. The latter in H.323 is the job of H.245
H.245 uses other protocols too (e.g. H.235 for security specifications) - it is used to select between multiplexing layers(H.220, 222, 223 and 225), and to provide transport procedures - it provides analogous (but for a/v, not data) services to T.120
So, because of the possible misunderstandings amongst an arbitrary set of peer s on a packet net, H.245 provides master/slave determination. It then provides capability exchange - i.e. what is each system able to send/receive (not just in qualitative terms, but also absolute and relative quantitative ones (e.g. "if i can receive 3 video of such and such a resolution, i can only mix 2 audio of such a coding).
In the IETF multicast tool-set, this could be done on the LAN with the conference bus, which is described in later in this chapter or it could be done with client SAP advertisements or capabilities in svrloc or even partly DHCP.
H.245 provides logical channel selection (i..e pick a port). Then it provides RTT estimation, channel maintenance (why do TCP and RM protocols not do that?), and then a set of commands and indications - these are really the core conference control facilities: (media control facilities and so on), as well as audio/video modes (activity on/off messages, silence suppression on/off commands and so on).
Thus finally, we descend to the end users requirements, which include h.243 password and other access control, Chair token control, terminal control messages, conference id info, facilities for exchanging certificates, ability to make a terminal the broadcaster, send this source, request all identifiers, Remote MC control and so forth.
Next: Multicast Internet Based MCS Up: ITU Model H.320/T.Gcc Previous: Services provided by the Jon CROWCROFT