 |
| |
 |
| |
 |
| |
 |
| |
 |
Abstract:
This techno-centric article examines the technical elements involved in a VoIP implementation,
and relates them to the SA legislation legalising VoIP in Feb 2005. It estimates that although
specific figures vary, good equipment will be paid off at least twice with savings during the lifetime
of the equipment.
A suggested strategy in the run-up to February 2005:
In any VoIP environment, the tagging of voice packets, implementation of queueing supportive of
expeditious voice passage, implementation of fragmentation, compression, and selective packet
drop is part of QoS. It is suggested that customer sites implement QoS before VoIP is
implemented.
What happens next depends on the site, and the technology used.
If PBX's (Private Branch eXchange machines) have been used on sites, they become typically
interconnected via their IP interfaces in a VoIP transition. PBX's that don't have IP interfaces can
still be connected to a VoIP network via their FXO or Foreign eXchange Office interface, each one
capable of trunking one line to the PBX. PBX's with digital interfaces typically use DS0 (DS zero)
time slots to place calls across their digital interface using Time Division Multiplexing (instead of
using OSI packet headers, however some PBX's support layer 3 address assignment on the
digital interface itself). WIth TDM, digital information is distinguished based upon the time slot that
it is transmitted in. This requires synchronised timing, or clocking, between TDM peers, and this
is a simple matter of configuration of the peered TDM controller interfaces. There are 24 DS0
slots available, (or more, in the case of an E1 controller) each DS0 slot will accommodate a
phone call. When all the DS0 slots are used, no further calls can be placed off the digital interface.
This technology is suboptimal, as voice can be readily compressed without loss of significant
quality, and 64Kbps of voice is an unacceptably large stream size. As a result, after peering with
the TDM interface on the PBX, the peer device should compress the voice data as soon as
possible. This can be done through a device such as a DT-24+, which writes packet headers for
each DS0, and compresses voice content using a CODEC (compress-decompress algorithm).
Codecs used are prefixed with the letter G. Codecs include G729, G711, G723, and so on. The
codec is decompressed by the receiving IP phone, or, in the case of an analogue fax or phone, a
voice gateway, which decompresses and then translates digital (packet switched) to analogue
(circuit switched) format. If the receiving device does not understand the codec, the call will ring
out, but the voice will be garbled. One codec can be translated to another (such as G729 to G723)
via DSP (Digital Signal Processor Hardware), such as via the DSP blade for a Cisco Systems
Catalyst 6500 switch. This hardware is very costly, but is extremely versatile.
PBX to PBX connectivity is easy and possible via call forwarding logic that is configured on voice
gateways, DT-24+ devices, and other voice capable network appliances. These devices interpret
dialled numbers (DTMF signals) and typically map remote voice gateway IP addresses to the
patterns. PBX's can be connected in this way on large sites or branches, before February 2005,
so long as they are not separated by WAN links managed by Telkom. Voice gateways need to be
tuned to the signalling characteristics of the PBX's. Bit patterns that represent signals, such as
call ringout, call ringback ("echo" of the ringing phone in the caller's earpiece), busy tones, caller
ID, etc can vary. These patterns are read from the TDM line, and must be translated by the
gateway to a recognised packet switched alternative, such as H.225 format signalling. The voice
gateway redirects the H225 signal to a packet switched device such as a "Gatekeeper", a device
responsible for recording how much reserved/voice bandwidth is available and remaining in the
packet switched call path. The Gatekeeper will only approve the call if enough reservable
bandwidth remains, if insufficient bandwidth remains, the call is rejected, and the calling voice
gateway tries an alternative path, if one has been created for the digit pattern. If bandwidth is
available the Gateways can set up the call with each other using H225 signalling, and the call is
placed. The number of placeable calls depends upon the codec used, and the voice bandwidth
allocated in the queueing configuration of routers in the call path, something configured when the
QoS was set up. Should the maths be wrong, and the Gatekeeper be misconfigured, call quality
will suffer on ALL calls placed between the gateways once the sustainable limit is exceeded.
The next step normally involves substitution of PBX's with MCS servers. For Nortel, this means
Multimedia Communication Server. For Cisco, this means Media Convergence Server. However
for all intents and purposes, their function is to replace the PBX when IP telephones are used.
Nortel and Cisco IP phones are managed by the MCS software. It communicates with IP phones,
and sets up call signalling such as ringout, ringback, busy tone signal, and features like music on
hold, hunt grouping, and so on. The routing of digit patterns, that is, the association of phone
numbers with network IP appliances responsible for forwarding calls is referred to as the dial
plan, and this logic forms the crux of IP telephony. Dial plans can be configured on MCS devices,
or on routers. Cisco routers, for example, support native SRST, survivable remote site telephony,
which can be used to supply this call switching logic, and can also provide PSTN fallback in the
event of WAN failure. In this respect, the router becomes a miniature MCS, and Cisco Routers
from the 2600 series up support this technology. However, whether through a voice-capable
router, or through an MCS system, it must be remembered that an IP phone requires a
management system, whose primary responsibility, whether via SIP symbolic addressing, or
otherwise, is maintaining dial plan information , that the phone itself does not have complicated
device and dial pattern associations as voice-capable routers, voice gateways and MCS systems
have. The IP phone reports dialled digits to the management system, which sets up the call, and
then reports progress to the IP phone so that it plays out the correct signal tone- busy, ringing etc.
When the receiving phone goes off-hook, it's management system signals the calling phone's
management system, and the calling phone is instructed to connect to the destination IP
address. The management system then falls out of the picture until one of the phones signals a
hang-up to the management system, which frees Gatekeeper resources, and instructs the
remaining phone, via its' management system, to disconnect the session. Voice calls in fact use
TCP to signal, and UDP to carry the voice samples. It is generally accepted that the signals travel
with an IP precedence of 3, or the DSCP equivalent, and that the samples travel with IP
precedence 5, or the DSCP equivalent. Marking is done on the IP phone or the Gateway, and this
forms part of the QoS setup.
As can be seen here, there is plenty that can and should be done prior to February 1st. After
February 1st, ISP's will need to supply guarantees for delay and bandwidth for customers seeking
voice transmission. These guarantees can be checked. One function of e-secure is to ensure that
the technical guarantees in the legal document, the SLA, are upheld. We also implement
redundancy, in order to avoid claims for negligence that may be brought by a user unable to make
an emergency call when bandwidth is unavailable, and implement encryption, for the protection of
constitutional rights to privacy. These are just some of the legal areas that we attend to, and in
doing so, provide the complete measure of protection necessary for a properly configured
technical solution.
An important function prior to embarking on VoIP is the investigation of the cost-effectiveness of it
as a solution. We provide detailed cost analysis and predictive service to our clients, you will know
the required budget for IP telephony, and know when savings will have paid off equipment, and
become an asset to the organisation. Most organisations pay off equipment priced at the Cisco
Systems level within three years in terms of VoIP savings. Because this equipment has an
estimated life of around six years (in terms of parts availability, software, and so on), an
organisation which is not experiencing growth will go on to experience savings around the value
of the installed equipment during the remainder of the equipment lifespan. However BHCC usage
analysis is required in order to provide adequate levels of accuracy here.
know more?
example of Configuring DS0
groups and H323 settings
on Cisco equipment.
there was QoS
certainly not. The
equipment is expensive,
the technology dated. IP
and MPLS-based QoS
provide a better ROI, and
TCO. We write this as
accredited and recognised
experts in cell and packet
based networking. Speak
to us about your needs
here.
We have QoS labs
designed by Dirk Venter in
2003 to demonstrate
basics and alternatives.
Check them out.
Cisco kit required!
H323 protocol releases via
the ITU web site.
Click here to download the
official H323 and related
specification ITU
implementation guide.
How do you change
the protocol version
of H.323 used by a
Cisco IOS device?
H.323 used is dependent
upon the IOS release that
you are running- the later
the release, the later the
version. There is no
specific command to
modify the H.323 protocol
version!
Dated 29 October 2004
