ail Record (CDR) or other billing record can be written and stored by the gatekeeper. Next, a Q.931 Release Complete message is sent in the call signaling connection, which can then be closed. Finally, the other terminal sends a DRQ to the gatekeeper over UDP and receives a DCF response. The call flows in Figures 8.2 and 8.3 show direct end-point signaling, where the calling terminal opens TCP connections to the called terminal and Calling Called H.323 Gatekeeper H.323 Terminal Terminal Media Session EndSessionCommand EndSessionCommand Figure 8.3 H.323 call tear-down sequence. Comparison to H.323 exchanges H.225.0 and H.245 messages. In the ACF response to the calling ter- minal, the gatekeeper can require gatekeeper routed signaling, where the call sig- naling and control signaling channels are opened with the gatekeeper, who then opens the channels with the called terminal. In this way, the gatekeeper stays in the signaling path and proxies all signaling messages. This allows the gatekeeper to know the exact call state and be able to invoke features. 8.3 Versions There are four versions of H.323, which reflect the evolution of this protocol with a fifth underway in 2003. H.323 is fully backward compatible, SO gate- keepers and terminals must support flows and mechanisms defined in all previ- ous versions. Version 1 was approved in 1996 and was titled "Visual Telephone Systems over Networks with Non-Guaranteed Quality of Service." The example call flow in Figure 8.2 shows the version 1 call setup. Not unexpectedly given the number of messages and TCP connections, this process was very slow, some- times taking as many as seven round trips to establish a call. While this may have been acceptable for a protocol designed for video conferencing over a single LAN segment, it is not acceptable for an IP telephony network designed to pro- vide a similar level of service to the PSTN. Version 2 included alternative call setup schemes to speed up the call setup. Two schemes were added to H.323, called FastStart and H.245 t