The George Washington University

raggedsquadΔίκτυα και Επικοινωνίες

30 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

108 εμφανίσεις







The George Washington University


Department of Computer Science

Fall 2002
-

Computer Networking





VoIP and Packet Voice Protocols







Seyed Ali Ahmadi


















CONTENTS



Section I VoIP Technology


1
-

Summary

2
-

The Great Voice Myth

3
-

VoIP Standard Terminology

4
-

Centralized and Distributed Architectures

5
-

H.323

6
-

MGCP / H.245 / MEGACO

7
-

SIP

8
-

Interconnecting VoIP protocols

9
-

Conclusion


Section II H.323 in detail


1
-

What’s H.323

2
-

H.323 Versions

3
-

H.32x Family

4
-

Components of a H.323 Network

5
-

H.323 Zone

6
-

Protocols Specified by H.323

7
-

Gateway Characteristic

8
-

Gatekeeper Characteristic

9
-

Gatekeeper Functions

a.

Mandatory functions

b.

Optional functions

10
-

Internet working with other Multimedia Networks





















SUMMARY


Over the past decade, the telecommunicat
ions industry has witnessed rapid
changes in the way people and organizations communicate. Many of these changes spring
from the explosive growth of the Internet and from applications based on the Internet
Protocol (IP). The Internet has become a ubiquitou
s method of communication, and the
total amount of packet
-
based network traffic has quickly surpassed traditional voice
(circuit
-
switched
-
such as PSTN) network traffic (DataQuest, 1998).

In the wake of these technology advancements, it has become clear to
telecommunications carriers, companies, and vendors that voice traffic and services will
be one of the next major applications to take full advantage of IP technology. This
expectation is based on the impact of a new set of technologies of packet voice pro
tocols,
generally referred to as voice over IP (VoIP) or IP telephony.

VoIP supplies many unique capabilities to the carriers and customers who depend on IP
or other packet
-
based networks. The most important benefits include the following:


1
-

Cost Savings
: B
y moving voice traffic to IP networks, companies can reduce or
eliminate the toll charges associated with transporting calls over the public
switched telephone network (PSTN). Service providers and end users can also
conserve bandwidth by investing in addi
tional capacity only when it is needed.
This is made possible by the distributed nature of VoIP and by reduced operations
costs as companies combine voice and data traffic onto one network.


2
-

Open Standards and Multivendor Interoperability
: By adopting open

standards,
both businesses and service providers can purchase equipment from multiple
vendors and eliminate their dependency on proprietary solutions.



3
-

Integrated Voice and Data Networks
: By making voice "just another IP
application," companies can build

truly integrated networks for voice and data.
These integrated networks not only provide the quality and reliability of today's
PSTN, but they also enable companies to quickly and flexibly take advantage of
new opportunities within the changing world of c
ommunications.


In 1995, the first commercial VoIP products began to hit the market. These products were
targeted at companies looking to reduce telecommunications expenses by moving voice
traffic to packet networks. Early adopters of VoIP networks built t
oll
-
bypass solutions to
take advantage of favorable regulatory treatment of IP traffic. Without any established
standards, most early implementations were based on proprietary technology.

As these packet telephony networks grew and interconnection dependen
cies emerged, it
became clear that the industry needed standard VoIP protocols. Several groups took up
the challenge, resulting in independent standards, each with its own unique
characteristics. In particular, network equipment suppliers and their custome
rs were left
to sort out the similarities and differences between four different signaling and call
-
control protocols for VoIP:


1
-

H.323

2
-

Media Gateway Control Protocol (MGCP)

3
-

Session Initiation Protocol (SIP)

4
-

H.248/Media Gateway Control (MEGACO)


In the proc
ess of implementing workable VoIP solutions, network engineers had to
determine how each of these protocols worked and which ones were best for particular
networks and applications. This paper provides some overview and understanding of
these VoIP protocol
s.


What’s “The Great Voice Myth”?



Among Network engineers, the great voice myth defines that there is only one
way to build an ideal voice network:


There should be one and only one voice protocol for each function in a packet voice
network
”.

This conce
ptual idea of an ideal VoIP network has been discussed between academic
institutions and network designers, but it is certainly not the way the networks have been
built in reality. In fact multiple VoIP protocols and architectures have already been
deploye
d and they will exist for the foreseeable future, and many networks will continue
to be built using multiple VoIP protocols. Just as today's data networks were built over
time using multiple protocols and applications, the VoIP networks of today and tomorr
ow
will be constructed using the protocols and applications that best fit the associated
technology and business requirements.


VoIP Standard Terminology



VoIP comprises many standards and protocols. In order to completely understand
the differences betwe
en VoIP protocols, a network designer should first be familiar with
terminology. These are some of the terms and definitions, which are widely used in
industry (the protocols are listed in alphabetical order):


1
-

H.248
is an ITU Recommendation that defines "
Gateway Control Protocol."
H.248 is the result of a joint collaboration between the ITU and the IETF. It is
also referred to as IETF RFC 2885 (MEGACO), which defines a centralized
architecture for creating multimedia applications, including VoIP. In many w
ays,
H.248 builds on and extends MGCP.


2
-

H.323
is an ITU Recommendation that defines "packet
-
based multimedia
communications systems." In other words, H.323 defines a distributed
architecture for creating multimedia applications, including VoIP.



3
-

IETF
refe
rs to the Internet Engineering Task Force, a community of engineers
that seeks to determine how the Internet and Internet protocols work, as well as to
define the prominent standards.


4
-

ITU
is the International Telecommunication Union, an international orga
nization
within the United Nations System, where governments and the private sector
coordinate global telecom networks and services.


5
-

MEGACO
, also known as IETF RFC 2885 and ITU RecommendationH.248,
defines a centralized architecture for creating multimedi
a applications, including
VoIP.


6
-

MGCP
, also known as IETF RFC 2705, defines a centralized architecture for
creating multimedia applications, including VoIP.


7
-

Real
-
Time Transport Protocol (RTP)
, also known as IETF RFC 1889, defines a
transport protocol for
real
-
time applications. Specifically, RTP provides the
transport to carry the audio/media portion of VoIP communication. All the VoIP
signaling protocols uses RTP.


8
-

SIP
, also known as IETF RFC 2543, defines a distributed architecture for creating
multimedi
a applications, including VoIP.



Centralized and Distributed Architecture



In the past, all voice networks were built using a centralized architecture in which
dumb endpoints (telephones) were controlled by centralized switches. Although this
model worke
d well for basic telephony services, it mandated a trade
-
off between
simplified management and endpoint and service innovation.

One of the benefits of VoIP technology is that it allows networks to be built using either a
centralized or a distributed archit
ecture. This flexibility allows companies to build
networks characterized by both simplified management and endpoint innovation,
depending on the protocol used.

In general, centralized architectures are associated with MGCP and H.248/MEGACO
protocols. Thes
e protocols were designed for a centralized device

called a media
gateway controller or call agent

that handles switching logic and call control. The
centralized device talks to media gateways, which route and transmit the audio/media
portion of the calls
(the actual voice information).

In centralized architectures, the network intelligence is centralized and endpoints are
relatively dumb (with limited or no native features). Although most centralized VoIP
architectures use MGCP or H.248/MEGACO protocols, i
t is also possible to build SIP or
H.323 networks in a centralized fashion using back
-
to
-
back user agents (B2BUAs) or
gatekeeper routed call signaling (GKRCS), respectively.

Advocates of centralized VoIP architectures favor this model because it centralize
s
management, provisioning, and call control. It simplifies call flows for replicating legacy
voice features. And it is easy for legacy voice engineers to understand. Critics of
centralized architectures claim that it stifles innovation of endpoint feature
s and that it
will become a hindrance when building VoIP services that move beyond legacy voice
features.

Distributed architectures are associated with H.323 and SIP protocols. These protocols
allow network intelligence to be distributed between endpoints
and call
-
control devices.
Intelligence
in this instance refers to call state, calling features, call routing, provisioning,
and billing, or any other aspect of call handling. The endpoints can be VoIP gateways, IP
phones, media servers, or any device that
can initiate and terminate a VoIP call. The call
-
control devices are called gatekeepers in an H.323 network, and proxy or redirect servers
in a SIP network.

Advocates of distributed architectures favor this model because of its flexibility. It allows
VoIP
applications to be treated like any other distributed IP application, and it allows the
flexibility to add intelligence to either endpoints or call
-
control devices, depending on the
business and technology requirements of the network. Distributed architect
ures are
usually well understood by engineers who run IP data networks. Critics of distributed
architectures commonly point to the existing PSTN infrastructure as the only reference
model that should be used when trying to replicate legacy voice services.
They also note
that distributed networks tend to be more complex.



H.323


H.323 was originally designed as a transport protocol for multimedia applications
in Local Area Networks (LAN). Although H.323 is still used by numerous vendors for
videoconferencin
g applications, it has rapidly evolved to address the growing needs of
VoIP networks. Because of its early availability and these advancements, H.323 is
currently the most widely used VoIP signaling and call
-
control protocol, with
international and domesti
c carriers relying on it to handle billions of minutes of use each
year.

H.323 is considered an "umbrella protocol" because it defines all aspects of call
transmission, from call establishment to capabilities exchange to network resource
availability. H.32
3 defines Registration, Admission, and Status (RAS) protocol for call
routing; H.225 protocols for call set
-
up, and H.245 protocols for capabilities exchange.

H.323 is based on the Integrated Services Digital Network (ISDN) Q.931 protocol, which
allows it
to easily interoperate with legacy voice networks such as the PSTN or Signaling
System 7 (SS7). As a protocol used in a distributed architecture, H.323 allows companies
to build large
-
scale networks that are scalable, resilient, and redundant. It provides
mechanisms for interconnecting with other VoIP networks and supports network
intelligence on either the endpoints or the gatekeepers.





MGCP / H.245 / MEGACO



MGCP and H.248/MEGACO were designed to provide an architecture where call
control and service
s could be centrally added to a VoIP network. In that sense, an
architecture using these protocols closely resembles the existing PSTN architecture and
services.

MGCP and H.248/MEGACO define most aspects of signaling using a model called
packages. These pa
ckages define commonly used functionality, such as PSTN signaling,
line
-
side device connectivity, and features such as transfer and hold. In addition, session
definition protocol (SDP) is used to convey capabilities exchange.





SIP


SIP was designed as
a multimedia protocol that could take advantage of the
architecture and messages found in popular Internet applications. By using a distributed
architecture

with universal resource locators (URLs) for naming and text
-
based
messaging

SIP attempts to take ad
vantage of the Internet model for building VoIP
networks and applications. In addition to VoIP, SIP is used for videoconferencing and
instant messaging.

As a protocol, SIP only defines how sessions are to be set up and torn down. It utilizes
other IETF pro
tocols to define other aspects of VoIP and multimedia sessions, such as
SDP for capabilities exchange, URLs for addressing, Domain Name Systems (DNSs) for
service location, and Telephony Routing Over IP (TRIP) for call routing.






Although the IETF has
made great progress defining extensions that allow SIP to
work with legacy voice networks, the primary motivation behind the protocol is to create
an environment that supports next
-
generation communications models that utilize the
Internet and Internet app
lications.

As a protocol used in a distributed architecture, SIP allows companies to build large
-
scale
networks that are scalable, resilient, and redundant. It provides mechanisms for
interconnecting with other VoIP networks and for adding intelligence and

new features
on either the endpoints or the SIP proxy or redirect servers.




Interconnecting VoIP Protocols


VoIP networks continue to be deployed at a rapid pace, and VoIP vendors and
service providers continue to add new functionality. Because vendor s
upport for each
protocol differs and companies have varying business requirements, it is very likely that
VoIP networks will continue to be made up of multiple protocols.

Having various protocols gives customers the flexibility that they need to connect
se
rvices from multiple carriers. Using standards, even multiple standards, still simplifies
deployment of multi
-
vendor endpoints and increases options for network management
and provisioning.

As companies expand their networks, they are faced with choices ab
out how to
interconnect segments using differing VoIP protocols. These choices often fall into one
of three categories:


-

Translation through Time Division Multiplexing (TDM)
: In this model, a
company uses either TDM equipment or VoIP gateways to translate
from one
protocol domain to another. The benefits of this model are that it can be used
today. The downside is that it introduces latency into the VoIP network and
involves yet another protocol translation. This model is usually considered as a
short
-
term
solution until IP

based protocol translators are available.


-

Single Protocol Architecture
: In this model, a company moves all its VoIP
devices and services to a single protocol, simplifying the network as a whole. The
downside to this approach is that it might not be possible to migrate existing
equipment to suppo
rt the new protocol, a situation that can limit the company's
ability to take advantage of some existing services. In addition, it limits the
potential connectivity to other networks that are using other VoIP signaling
protocols.



-

Protocol Translation
: In

this model, a company uses IP

based protocol translators
to interconnect two or more VoIP protocol domains. IP translators allow a
company to retain the flexibility of using multiple VoIP protocols, do not
introduce the delay problems that additional TDM
interconnections do, and do not
require a wholesale replacement or swap of existing equipment.


The downside to this approach is that there is no standard for protocol translation, so
not all VoIP protocol translators are exactly the same. Although the IET
F has attempted
to define a model for translating H.323 to SIP, it involves more than just building a
protocol
-
translation box. As shown in the following table, although protocols are
somewhat similar, they do have some differences. Vendors of protocol tra
nslators need
in
-
depth knowledge of all the protocols being used in the VoIP network, and they must be
aware of how various VoIP components utilize different aspects of the protocol.

For example, H.323 and SIP can send dual
-
tone multi
-
frequency (DTMF) digi
ts in either
the signaling path or the media path (via RTP). But H.323 mandates only that the H.245
signaling path be used, and SIP does not specify how DTMF should be carried. This
means that SIP devices could be sending DTMF in the media path (RFC 2833),

and
H.323 devices could be sending DTMF in the signaling path (H.245). If the VoIP
protocol translator cannot properly recognize both the signaling path and the media path,
then it might not function properly.









Conclusion: Packet Voice and VoIP Is

About Services, Not Protocols


Just as companies choose various protocols for their data networks, they will
choose various protocols for their VoIP requirements, depending on the business and
technical requirements at hand. Although the variety in VoIP

protocols has caused some
confusion in the marketplace, it is precisely this protocol flexibility that makes VoIP
-
based voice systems so much more useful than legacy voice systems. Companies should
choose vendors based on three very important requirements
:


Customers need vendors that are committed to supporting open standards within their
products and are actively developing voice strategies that consider interoperability with
all VoIP protocols. Without this commitment, VoIP systems are in danger of beco
ming as
proprietary as legacy voice systems.

Customers need products that support multiple protocols. This way, if a company finds
that it needs to migrate its systems or add products that support a different protocol, it
will not be required to perform up
grades to the network.

Customers need voice solutions with end
-
to
-
end support for all VoIP protocols, meaning
vendors must provide solutions that work in both single
-
protocol and multi
-
protocol
environments.

























Section II


H.323 in de
tail


What’s H.323?




H.323 is a technology for transmission of audio, video and

data communications
over a packet switched networks. It provides components, protocols, and procedures for
multimedia communications based on a packet switched network. Pack
et based networks
include IP
-
based (like Internet), Internet packet exchange (IPX) based LAN and wide are
networks. H.323 can be used in variety of applications:

-

Audio only (IP telephony)

-

Audio and Video (Videoconferencing)

-

Audio and data

-

Audio, video and
data



Terminals on a Packet Network



H.323 Versions



H.323 has been specified by ITU


T study group 16. The first version of H.323


visual telephone systems and equipment of LANs that provide a nonguaranteed quality of
services (Qo
S)


was accepted in October 1996.

Right at the beginning, it was heavily weighted towards multimedia communications in
LAN environments. The emergence of VoIP and IP telephony applications has paved the
way for a revision of H.323 specification. The abse
nce of a standard for VoIP resulted in
products that were incompatible and it was almost impossible to build a network that
would communicate with another VoIP network. VoIP technology introduced new
requirements such as communication between a PC
-
based ph
one and a traditional PSTN
phone. These new requirements forced the need for a standard in VoIP technology.
Version two of H.323 (packet
-
Based multimedia communication systems) was accepted
in January 1998. There is also a recent third version with new fea
tures such as fax
-
over
-
IP and gatekeeper
-
gatekeeper communications and fast connection mechanism.


H.32x Family



H.323 standard is part of H.32x family specified by ITU. Other protocols in this
family specify multimedia communication services over differ
ent networks:




H.324 over SCN



H.320 over integrated services digital networks (ISDN)



H.321 and H.310 over broadband integrated services digital networks (B

ISDN)



H.322 over LANs that provide guaranteed QoS

One of the primary goals in the development of
the H.323 standard was interoperability
with other multimedia
-
services networks. This interoperability is achieved through the
use of a gateway. A gateway performs any network or signaling translation required for
interoperability.

Interworking with Other
Multimedia Networks


The H.323 standard specifies four kinds of components, which, when networked
together, provide the point
-
to
-
point and point
-
to
-
multipoint multimedia
-
communication
services:



Terminals



Gateways



Gatekeepers



Multipoint control units (M
CUs)

Terminals

Used for real
-
time bi
-
directional multimedia communications, an H.323 terminal
can either be a personal computer (PC) or a stand
-
alone device, running an H.323 and the
multimedia applications. It supports audio communications and can optiona
lly support
video or data communications. Because the basic service provided by an H.323 terminal
is audio communications, an H.323 terminal plays a key role in IP

telephony services.
An H.323 terminal can either be a PC or a stand
-
alone device, running an

H.323 stack
and multimedia applications. The primary goal of H.323 is to interwork with other
multimedia terminals. H.323 terminals are compatible with H.324 terminals on SCN and
wireless networks, H.310 terminals on B

ISDN, H.320 terminals on ISDN, H.321

terminals on B

ISDN, and H.322 terminals on guaranteed QoS LANs. H.323 terminals
may be used in multipoint conferences.

Gateways

A gateway connects two dissimilar networks. An H.323 gateway provides
connectivity between an H.323 network and a non

H.323 n
etwork. For example, a
gateway can connect and provide communication between an H.323 terminal and SCN
networks (SCN networks include all switched telephony networks, e.g., public switched
telephone network [PSTN]). This connectivity of dissimilar networks

is achieved by
translating protocols for call setup and release; converting media formats between
different networks, and transferring information between the networks connected by the
gateway. A gateway is not required, however, for communication between

two terminals
on an H.323 network.

Gatekeepers

A gatekeeper can be considered the brain of the H.323 network. It is the focal
point for all calls within the H.323 network. Although they are not required, gatekeepers
provide important services such as add
ressing, authorization and authentication of
terminals and gateways; bandwidth management; accounting; billing; and charging.
Gatekeepers may also provide call
-
routing services.

Multipoint Control Units

MCUs provide support for conferences of three or mor
e H.323 terminals. All
terminals participating in the conference establish a connection with the MCU. The MCU
manages conference resources, negotiates between terminals for the purpose of
determining the audio or video coder/decoder (CODEC) to use, and may

handle the
media stream. The gatekeepers, gateways, and MCUs are logically separate components
of the H.323 standard but can be implemented as a single physical device.

H.323
Components

An H.323 zone is a collection of all terminals, gateways, and MCUs ma
naged by
a single gatekeeper (see
Figure 2
). A zone includes at least one terminal and may include
gateways or MCUs. A zone has only one gatekeeper. A zone may be independent of
network topology and may be comprised of multiple network segments that are
co
nnected using routers or other devices.


H.323 Zone



The protocols specified by H.323 are listed below. H.323 is independent of the
packet network and th
e transport protocols over which it runs and does not specify them.



Audio CODECs



Video CODECs



H.225 registration, admission, and status (RAS)



H.225 call signaling



H.245 control signaling



Real
-
time transfer protocol (RTP)



Real
-
time control protocol (R
TCP)



Audio CODEC

An audio CODEC encodes the audio signal from the microphone for transmission
on the transmitting H.323 terminal and decodes the receive
d audio code that is sent to the
speaker on the receiving H.323 terminal. Because audio is the minimum service provided
by the H.323 standard, all H.323 terminals must have at least one audio CODEC support,
as specified in the ITU

T G.711 recommendation (a
udio coding at 64 kbps). Additional
audio CODEC recommendations such as G.722 (64, 56, and 48 kbps), G.723.1 (5.3 and
6.3 kbps), G.728 (16 kbps), and G.729 (8 kbps) may also be supported.

Video CODEC

A video CODEC encodes video from the camera for transmi
ssion on the
transmitting H.323 terminal and decodes the received video code that is sent to the video
display on the receiving H.323 terminal. Because H.323 specifies support of video as
optional, the support of video CODECs is optional as well. However,
any H.323 terminal
providing video communications must support video encoding and decoding as specified
in the ITU

T H.261 recommendation.

H.225 Registration, Admission, and Status

Registration, admission, and status protocol (RAS) is the protocol between

endpoints (terminals and gateways) and gatekeepers. The RAS is used to perform
registration, admission control, bandwidth changes, status, and disengage procedures
between endpoints and gatekeepers. An RAS channel is used to exchange RAS messages.
This si
gnaling channel is opened between an endpoint and a gatekeeper prior to the
establishment of any other channels.

H.225 Call Signaling

The H.225 call signaling is used to establish a connection between two H.323
endpoints. This is achieved by exchanging H.
225 protocol messages on the call
-
signaling
channel. The call
-
signaling channel is opened between two H.323 endpoints or between
an endpoint and the gatekeeper.

H.245 Control Signaling

H.245 control signaling is used to exchange end
-
to
-
end control message
s governing
the operation of the H.323 endpoint. These control messages carry information related to
the following:



Capabilities exchange



Opening and closing of logical channels used to carry media streams



Flow
-
control messages



General commands and ind
ications

Real
-
Time Transport Protocol

Real
-
time transport protocol (RTP) provides end
-
to
-
end delivery services of real
-
time
audio and video. Whereas H.323 is used to transport data over IP

based networks, RTP is
typically used to transport data via the us
er datagram protocol (UDP). RTP, together with
UDP, provides transport
-
protocol functionality. RTP provides payload
-
type
identification, sequence numbering, timestamping, and delivery monitoring. UDP
provides multiplexing and checksum services. RTP can als
o be used with other transport
protocols.

Real
-
Time Transport Control Protocol

Real
-
time transport control protocol (RTCP) is the counterpart of RTP that provides
control services. The primary function of RTCP is to provide feedback on the quality of
the
data distribution. Other RTCP functions include carrying a transport
-
level identifier
for an RTP source, called a canonical name, which is used by receivers to synchronize
audio and video.

Protocols Specified by H.323


H.323 terminals must support the foll
owing:



H.245 for exchanging terminal capabilities and creation of media channels



H.225 for call signaling and call setup



RAS for registration and other admission control with a gatekeeper



RTP/RTCP for sequencing audio and video packets

H.323 terminals
must also support the G.711 audio CODEC. Optional components in an
H.323 terminal are video CODECs, T.120 data
-
conferencing protocols, and MCU
capabilities.

Gateway Characteristics

A gateway provides translation of protocols for call setup and release, co
nversion
of media formats between different networks, and the transfer of information between
H.323 and non

H.323 networks. An application of the H.323 gateway is in IP telephony,
where the H.323 gateway connects an IP network and SCN network (e.g., ISDN
n
etwork).

Gateway Protocol Stack



On the H.323 side, a gateway runs H.245 control signaling for exchanging capabilities,
H.225 call signaling for call s
etup and release, and H.225 registration, admissions, and
status (RAS) for registration with the gatekeeper. On the SCN side, a gateway runs SCN

specific protocols (e.g., ISDN and SS7 protocols). Terminals communicate with gateways
using the H.245 control
-
signaling protocol and H.225 call
-
signaling protocol. The
gateway translates these protocols in a transparent fashion to the respective counterparts
on the non

H.323 network and vice versa. The gateway also performs call setup and
clearing on both the H.32
3

network side and the non

H.323

network side. Translation
between audio, video, and data formats may also be performed by the gateway. Audio
and video translation may not be required if both terminal types find a common
communications mode. For example, i
n the case of a gateway to H.320 terminals on the
ISDN, both terminal types require G.711 audio and H.261 video, so a common mode
always exists. The gateway has the characteristics of both an H.323 terminal on the
H.323 network and the other terminal on th
e non

H.323 network it connects.

Gatekeepers are aware of which endpoints are gateways because this is indicated when
the terminals and gateways register with the gatekeeper. A gateway may be able to
support several simultaneous calls between the H.323 an
d non

H.323 networks. In
addition, a gateway may connect an H.323 network to a non

H.323 network. A gateway
is a logical component of H.323 and can be implemented as part of a gatekeeper or an
MCU.

Gatekeeper Characteristics

Gatekeepers provide call
-
contr
ol services for H.323 endpoints, such as address
translation and bandwidth management as defined within RAS. Gatekeepers in H.323
networks are optional. If they are present in a network, however, terminals and gateways
must use their services. The H.323 st
andards both define mandatory services that the
gatekeeper must provide and specify other optional functionality that it can provide. An
optional feature of a gatekeeper is call
-
signaling routing. Endpoints send call
-
signaling
messages to the gatekeeper, w
hich the gatekeeper routes to the destination endpoints.
Alternately, endpoints can send call
-
signaling messages directly to the peer endpoints.
This feature of the gatekeeper is valuable, as monitoring of the calls by the gatekeeper
provides better contro
l of the calls in the network. Routing calls through gatekeepers
provides better performance in the network; as the gatekeeper can make routing decisions
based on a variety of factors, for example, load balancing among gateways. A gatekeeper
is optional in

an H.323 system. The services offered by a gatekeeper are defined by RAS
and include address translation, admissions control, bandwidth control, and zone
management. H.323 networks that do not have gatekeepers may not have these
capabilities, but H.323 ne
tworks that contain IP

telephony gateways should also contain
a gatekeeper to translate incoming E.164 telephone addresses into transport addresses. A
gatekeeper is a logical component of H.323 but can be implemented as part of a gateway
or MCU.









Gatekeeper Components

Mandatory Gatekeeper Functions

Address Translation


Calls originating within an H.323 network may use an alias to address the
destina
tion terminal. Calls originating outside the H.323 network and received by a
gateway may use an E.164 telephone number (e.g., 310
-
442
-
9222) to address the
destination terminal. The gatekeeper translates this E.164 telephone number or the alias
into the net
work address (e.g., 204.252.32:456 for an IP

based network) for the
destination terminal. The destination endpoint can be reached using the network address
on the H.323 network.

Admission Control


The gatekeeper can control the admission of the endpoints
into the H.323
network. It uses RAS messages, admission request (ARQ), confirm (ACF), and reject
(ARJ) to achieve this. Admissions control may be a null function that admits all
endpoints to the H.323 network.

Bandwidth Control


The gatekeeper provides su
pport for bandwidth control by using the RAS
messages, bandwidth request (BRQ), confirm (BCF), and reject (BRJ). For instance, if a
network manager has specified a threshold for the number of simultaneous connections
on the H.323 network, the gatekeeper ca
n refuse to make any more connections once the
threshold is reached. The result is to limit the total allocated bandwidth to some fraction
of the total available, leaving the remaining bandwidth for data applications. Bandwidth
control may also be a null f
unction that accepts all requests for bandwidth changes.

Zone Management


The gatekeeper provides the above functions

address translation, admissions
control, and bandwidth control

for terminals, gateways, and MCUs located within its
zone of control.

Opti
onal Gatekeeper Functions

Call
-
Control Signaling


The gatekeeper can route call
-
signaling messages between H.323 endpoints. In a
point
-
to
-
point conference, the gatekeeper may process H.225 call
-
signaling messages.
Alternatively, the gatekeeper may allow th
e endpoints to send H.225 call
-
signaling
messages directly to each other.

Call Authorization


When an endpoint sends call
-
signaling messages to the gatekeeper, the gatekeeper
may accept or reject the call, according to the H.225 specification. The reasons

for
rejection may include access
-
based or time
-
based restrictions, to and from particular
terminals or gateways.

Call Management


The gatekeeper may maintain information about all active H.323 calls so that it
can control its zone by providing the mainta
ined information to the bandwidth
-
management function or by rerouting the calls to different endpoints to achieve load
balancing.

Internet Working with other Multimedia Networks


The H.323 Protocol has been designed so that it interoperates with other
Mult
imedia networks. The most popular H.323 Interworking is IP telephony when the
underlying network of H.323 is an IP network and the interoperating network is SCN.
SCN includes PSTN and ISDN networks.


IP telephony. H.323 Interworking with SCN




H.323 is compatible with various other H.32x networks. Following figure shows an
H.323 zone interworking with all H.32x networks. The ITU

T recommendation H.246
spec
ifies interworking among various H.32x networks.