In the simple case described above, Mark called John directly on his current IP address 10.2.3.4. This situation is very convenient to show the basics of H.323, but very unlikely to happen in reality. If nothing else, a plain IP address is very hard to remember. In many cases it will even change—most ISPs allocate a dynamic IP address to their subscribers.
Our next example is more realistic: Mark now wants to call his grandmother, who only owns a regular phone and doesn’t have the slightest idea of what an IP address is. This example will show the need for a new H.323 entity, called thegatekeeper.
The gatekeeper is the most complex component of the H.323 framework. It was first introduced in H.323v1, but at that time most people didn’t really understand how useful it would be. At best, the gatekeeper was considered to be a sort of directory mapping friendly names to IP addresses. Some companies found alternative ways of doing this: some now- obsolete ‘H.323-compliant’ software and hardware used proprietary mechanisms ranging from IRC servers to LDAP servers to find the transport address of another VoIP phone or gateway.
H.323v2 has clarified the role of the gatekeeper, and now it is widely acknowledged that the gatekeeper is responsible for most network-based services (i.e., services which need to be performed independently of the terminal or when the terminal is turned off).
These services include registration (the ability to know that someone has logged on and can be reached at a particular terminal, sometimes called ‘presence’), admission (checking the right to access resources), and status (monitoring the availability of telephone-related network resources, such as gateways and terminals). Finding the transport address to use to reach a particular alias is naturally also part of the gatekeeper’s role, since this transport address might depend on the status of the called party (e.g., if the person is not logged on, the call should be redirected to an answering machine or a regular phone through a gateway), the identity of the caller (not everybody might be allowed to call Mark, such as in the case of a do-not-disturb service), or the status of a particular resource (if all ports on a gateway are busy, then it might be necessary to use another gateway). Therefore,
the gatekeeper is also in charge of routing all VoIP calls in the H.323 network, and the implementation of services like call forward on no answer.
The set of all H.323 endpoints, conference servers (MCUs) or gateways managed by a single gatekeeper is called a zone. In our example John’s terminal and the gateway belong to the same zone.
In this Section 2.2.2 we consider that the caller has access to a gatekeeper, and show some of the gatekeeper features in action. The terminal and the gatekeeper use a specific protocol for registration, admission, and status purposes, which has logically been named RAS. This protocol is also defined in H.225.0.
2.2.2.1 Locating the gatekeeper
In simple configurations, the gatekeeper’s IP address might simply be configured man- ually or automatically in the VoIP terminal. This is the most frequent case in real-life H.323 networks. This IP address is usually acquired when the VoIP endpoint boots: it first acquires an IP address and basic configuration parameters through the Dynamic Host Configuration Protocol (DHCP), one of the configuration parameters is the name of a TFTP server and a configuration file. The endpoint then downloads a configuration file using the TFTP protocol, which specifies, among other parameters, the address of a gate- keeper (and most of the time, a back-up gatekeeper). If such a configuration mechanism cannot be used or is not suitable, H.323 has developed a mechanism to dynamically find a gatekeeper on the network. This has a number of advantages (e.g., when someone has got a laptop and roams between several office locations). This mechanism also provides a way to introduce redundancy and load balancing between several gatekeepers in the network.
In order to find a gatekeeper, a H.323 terminal should send a multicast Gatekeeper Request (GRQ)to the group address 224.0.1.41 on UDP port 1718 (for more information on multicast, see companion book, Beyond VoIP Protocols). Within the GRQ message, it can specify whether it is willing to contact a particular gatekeeper. The terminal also mentions its aliases, allowing a gatekeeper to reply only to specific groups of terminals.
Eventually, a GRQ can also be sent in unicast to port 1718, or preferably 1719, this is the default for unicast RAS messages, but obviously in this case the endpoint should know the possible gatekeeper IP addresses in advance.
The GRQ message should be sent with a very low TTL (time to live) initially in order to reach the gatekeepers on the local network first, and then use expanding ring search (Figure 2.10). This GRQ message tells the GK on what address and port the terminal expects to receive the answer, which type of terminal it is and what the terminal alias(es) is (are).
Each gatekeeper should be a member of group 224.0.1.41 and listen on port 1718.
Therefore, one or more of these gatekeepers will reply on the address specified by the terminal with aGatekeeper Confirm (GCF) message which indicates the name of the gatekeeper, and the unicast address and port that this gatekeeper uses for RAS messages.
It can also include the names and transport information of other back-up gatekeepers.
The use of multicast for gatekeeper discovery has raised much controversy. In fact, not many IP networks support multicast today. Multicast routing is not activated by default on
GRQ will cross this router only if its TTL > 1
External GK Local GK
GRQ sent using multicast
Figure 2.10 Locating the gatekeeper using multicast GRQ messages.
routers, and many network administrators feel comfortable with static routes and are not really willing to experiment with a dynamic multicast routing protocol, such as DVMRP or PIM. Multicast discovery of the Gatekeeper is hardly ever used in practice, except perhaps in some private installations, e.g., videoconferencing inside a company.
2.2.2.2 Registration
If it received more than one answer from a gatekeeper in the discovery process, the ter- minal chooses one and registers this with the selected gatekeeper by sending a unicast Registration Request (RRQ) message (usually on UDP port 1719). This message car- ries an important piece of information: the transport address which is to be used for call signaling. The registration can be ‘soft state’ if the terminal so desires, in which case it also specifies atime to live for the registration and will refresh its registration periodi- cally by sending more RRQs, also calledlightweight RRQsorkeep-alive RRQs. These RRQs have a special parameter ‘keepAlive’ set and do not include the full registration information.
The gatekeeper replies with aRegistration Confirm (RCF)message in which the gate- keeper assigns a unique identifier to this terminal which must be copied in all subsequent RAS messages. The GK can also assign an alias to the requesting endpoint in this RCF.
Whether or not the terminal chose to use the ‘keepAlive’ registration, the gatekeeper can also request keepAlive RRQs by specifying a maximum time to live in its response.
Since the advent of H.323v4 it is also possible to use additive registrations, in order to register many aliases which would not fit in a single RRQ message (this can be used by IP-PBXs when registering many extensions to a core network). Such RRQs have a specific ‘additiveRegistration’ flag. They are also acknowledged by an RCF.
2.2.2.3 Requesting permission to make a new call
Now that John’s terminal has found a gatekeeper and is registered, John still needs to request a permission from the gatekeeper for each call he wants to make. In this case he wants to reach his grandma at+33 123456789.
His terminal will first send anAdmission Request (ARQ)message to its gatekeeper.
The ARQ message includes:
• A sequential number.
• The GK-assigned terminal identifier.
• The type of call (point to point).
• The call model that the terminal is willing to use (direct or gatekeeper-routed—see Section 2.2.2.2).
• The destination information (in this case the E.164 address+33 123456789 of grandma, but it could also have been Mark’s email alias). Note that we used ‘+’ to denote the country code, but this character is not transported in the ARQ message. In real- ity John would probably use the local dialing convention, and not a full number in international format.
• A Call Reference Value (CRV), which should be copied in the SETUP message.
• A globally unique CallID.
• An estimation of the bidirectional bandwidth that will be used for this call for media streams. This includes audio and video that will be sent from the called party and is measured excluding network overhead. This is avery rough estimation in most cases, since the codecs will be negotiated later. For instance, an audio-only terminal might indicate 128 kbit/s as a worst case if the two terminals negotiate a G.711 codec (64 kbit/s) for the incoming and outgoing audio logical channels. The endpoint may use Bandwidth Request (BRQ)messages later to ask for additional bandwidth (e.g., if it needs to open video channels).
The two possible call models refer to the way the call-signaling channel (carrying Q.931 messages) and the H.245 channel are set up between the endpoints. The calling endpoint can establish these channels directly with the called endpoint (thedirect mode), or it can establish these channels with the gatekeeper which will relay the call-signaling and call
control information to the called endpoint (there might be several gatekeepers routing the Q.931 and H.245 channels between the two endpoints). The later mode is the gatekeeper routed mode.
In this example we will use the direct model; we will discuss the GK-routed mode later. As we will see, the GK-routed mode is much more powerful and is the only model that works in carrier-class deployments.
If it decides to accept the call, the gatekeeper replies with anAdmissionConfirm (ACF) message which specifies:
• The call model to use (regardless of what was previously indicated by the calling endpoint).
• The transport address and port to use for Q.931 call signaling. This address can be the IP address of the called terminal directly (or the IP address of a gateway when calling a regular phone number) in the direct model, or it might be the gatekeeper itself if it decides to route the call. In our example the gatekeeper replies with the IP address of a gateway.
• The allowed bandwidth for the call.
• The GK can also request the terminal to send IRR (Information Request) messages from time to time to check whether the endpoint is still alive.
Note that this admission phase is really redundant if the gatekeeper wishes to use the routed mode, because the gatekeeper keeps full control of the call in routed mode. In H.323v2, the admission phase using ARQ/ACF messages can be skipped if the gatekeeper grants the preGrantedARQright to the endpoint during the registration phase (see Section 2.3.6).
2.2.2.4 Call signaling
The Admission Confirm message has provided John’s terminal with the information it needed to complete the call (Figure 2.11). Now the terminal can establish a call-signaling connection to the call-signaling address and port specified by the gatekeeper, in our case a gateway to the phone network, and send a Q.931 SETUP message. Before proceeding, the gateway may itself be required to ask the gatekeeper if it is authorized to place the call using an ARQ/ACF sequence. The ARQ will mention both the calling endpoint alias/call- signaling address and the called endpoint alias/call-signaling address, and a field indicating that this is an ARQ related to the termination of a call. In this receive side ARQ, the CRV (Call Reference Value) will be locally generated and, therefore, will differ from the CRV of the calling side ARQ. But the CallID should be copied from the SETUP message.
The gateway knows from the called party number information element of the H.323 SETUP message which phone number it must call. If it is connected to an ISDN phone line, it will simply send an ISDN Q.931 SETUP message on the D channel to initiate the connection on the ISDN. If it is connected to an analog line, it will go off-hook and dial the number using DTMF. If it is sending the call to an SS7 ISUP network, it will convert the SETUP message to an ISUPInitial Address Message (IAM). Note that the
GK GW 10.1.2.3 ARQ (number =
+33 12345678, ...) ACF (Call. Sig. = 10.1.2.3:1720, ...)
ALERTING CONNECT
SETUP (number =012345678) ARQ
ACF SETUP (number = +33 12345678)
Figure 2.11 Direct mode call authorized by the gatekeeper.
format of the phone number may need to be changed (e.g., the country code may need to be removed). In the direct mode, this needs to be done by the gateway, whereas in the routed mode this would typically be done by the gatekeeper, centralizing the numbering plan and routing management.
The gateway will send an H.225 ALERTING message to the caller as soon as it has received an indication from the phone network that Grandma’s phone is ringing, and send the CONNECT message as soon as she has picked up the handset. If the gateway was connected through an ISDN line, these events will be signaled by the phone network using similar Q.931 ALERTING and CONNECT messages. If it is an analog line, the gateway needs to detect the appropriate ring/busy/connect conditions.
The ALERTING or CONNECT message contains a transport address to allow John’s terminal to establish an H.245 control channel on which it can negotiate codecs and open media channels. This procedure is identical to the procedure used above when John was calling Mark. The media channels are then opened between the gateway and John’s terminal as in the previous example.
2.2.2.5 Termination phase
Whoever hangs up (e.g., the gateway in Figure 2.12) first needs to close its logical channels using the H.245 CloseLogicalChannel message. The gateway then sends an
GK GW 10.1.2.3
DRQ
EndSessionCommand
HANG-UP
DCF EndSessionCommand
Release Complete
DRQ
DCF
Figure 2.12 Call released at H.245 and H.225 level (Q.931 and RAS).
H.245endSessionCommandmessage to John’s terminal and waits to receive the same message from John’s terminal. The gateway then closes the H.245 channel. If the Q.931 channel is still open, each terminal must send a Q.931 ReleaseComplete message before closing it, then the terminal and the gateway must send a Disengage Request (DRQ) message to the gatekeeper, enabling the gatekeeper to know that the call and associated network resources have been released. The gatekeeper replies to each with aDisengage Confirm (DCF). At this stage, if the terminal or the gateway had been sending IRR messages to the gatekeeper, they must stop.
If there is more than one gatekeeper and the gateway and the terminal are registered to different gatekeepers, each one sends a DRQ to its own gatekeeper.
The terminal or the gateway have no reason to unregister (done by sending an Unre- gistrationRequestorURQto the gatekeeper), unless, for instance, John decides to close his IP telephony software. A terminal should remain registered as long as it can make or receive calls.
If during the communication the gatekeeper wants to clear the call it can also send a DRQ to one or both endpoints. On receiving the DRQ the endpoint must send an H.245 endSessionCommand to the other endpoint, wait to receive an endSession command, close the Q.931 channel with a release complete, and send a DCF to the gatekeeper. Of course, this is dependent on the endpoint implementation and cannot be used reliably for
applications like prepaid calls if at least one side of the call is not a trusted device. For such applications, if the endpoints are not fully trusted, the routed call model must be used.
In order to prevent a terminal from pretending it is closing a connection with a gate- way without sending an endSessionCommand/release complete to the gateway, when a gatekeeper receives a DRQ from the terminal, it will wait until it has received a DRQ from the gateway before replying with a DCF. If the gatekeeper receives a DRQ from the gateway (as in our example), it will wait until it has received a DRQ from the terminal before sending a DCF to the gateway. In case the gatekeeper doesn’t receive a DRQ from the terminal within a few seconds, it will ask the terminal to disconnect by sending a DRQ. The terminal is supposed to disconnect and send back a DCF, but if it doesn’t within a few seconds (the PC might have crashed), the gatekeeper will send a DCF to the gateway anyhow. This procedure minimizes fraud and unwanted operation due to unstable or non-conformant terminals, but the routed mode is still more reliable.
In the direct mode, Call Detail Records must be generated by the gateways, the RAS information available at the gatekeeper level is not accurate enough for most purposes.
For instance, it does not have access to the call release causes (a Q850 release code is provided by the network for each released call, specifying the reason for dropping the call: normal clearing, network congestion, user busy, switch failure, etc.). Also, the timing information is loosely coupled with the timing of the actual call release, and the start and stop information are available at different machines in the case of a network with multiple gatekeepers. This makes gatekeeper-level accounting records approximate at best.
In real-life deployments with multi-gatekeeper networks, where unfortunately gateways or routers sometimes crash or show unexpected behaviour, the direct mode also makes it quite difficult to detect so-called ‘zombie calls’, calls that for some reason remain active in the network, out of control, for days or months.
All these issues are resolved by using the gatekeeper-routed mode.