||: Partial Tutorial in response to selected VoIP Questions :||
Evan,
Apologies for my elementary-level approach yesterday
during one of my replies. I was not aware that you are a
programmer. ;-)
>>We had a discussion ...telecommunication
infrastructure.. one thing that must be taken into
consideration is that the existing equipment and [carrier]
companies are not seamlessly integrated... based on
Mergers and acquisitions...many companies are not
consistent in their structure and equipment, but rather
each a unique hybrid, of legacy and cutting edge
tech...until the [gateway] was Beta tested throughout
each configuration, they would not begin deployment.
The last thing they wanted was a work in the shop, fail
in the field product, and until assured it could handle it.
<<
---
Makes a lot of sense to me for a lot of reasons. Read on.
The factors you cite above account for a great deal of
test and evaluation time, and are often cause for
speculation as to why things "aren't ready" yet. Been
there. Sometimes it takes a thick skin to stick to your
guns. And then some...
Re: The M&A Mulligan Stew of systems: Each time I
hear about the 'synergies' that will result from carrier
mergers, I counter by regarding them as a "pooling of
disinterests." I don't know how Bernie Ebbers ever
pulled off the things he did without taking down the
entire country several years back. More power to him.
Then again, systems among the smaller carriers he
acquired were not as complicated then as the newer ones
in place in the larger carriers now, just a couple of years
later. Nevertheless, a monumental chore.
Even under ideal domestic conditions, the buggers are
there to get you, when you are rolling out new product.
Problems scale up geometrically in the international
sector where a greater number of specification variants
exist even among published and accepted 'standards.'
SS7 and older forms of the prior CCITT Signaling (#5
and #6) standards are notorious in this way.
To properly address your questions I'd have to first take
you through some stages of 'plant life' and c.o.
environments, and explain a few processes and
relationships. So, bear with me, and others be
forewarned... this could get to be a bit long. You may
want to do something else for the rest of the evening.
----
I'll assume that the Internet portion of this arrangement
is pretty much under control, and the IP side of the
equation on the VoIP server (gateway) is not the point of
concern, since the PSTN is the foreign territory in this
exercise. Although, there exist a number of variables in
the 'Net-side domain, both in the emerging standards (which
I suspect are not being implemented at this time), and in
the modality [they] may elect to create, i.e., the tie line
model, as I sense that this is straightforward and that this
is what they are electing to do at this time. Right? As
opposed to gatekeeper functions, LDAP lookups, or any
involvement with traditional PSTN SS7 Signaling, correct?
That's my assumption, in any event, going forward from here.
---
At the physical layer and its sub-layers (Layer 1 of the
OSI RM) where the cabling and electrical signaling
interfaces take place, things aren't all that bad, since
off-the-shelf board-level components are likely being
used, and most OEMs learned long ago that they either
meet the ANSI and ITU interfacing requirements, or
their products don't get sold.
Looking skyward in the stack from the physical interface,
however, things go from the mundane to sticky to worse,
when proving in new wares.
Calls must first be set up with signaling protocols using
'supervisory' signals which could either be direct current
interrupts, analog tones, or digital data of various formats.
While these are fairly stabilized state-side, they differ in
format and definition in many regions of the world, and
often within the same region when you get overseas.
These forms of data range from the very familiar to
some-not-so-familiar... on-hook, off-hook, idle, busy,
E&M, FX-O, dial-pulsing, revertive dc, T-1 a/b/c/d and
robbed-bit signaling, etc., and they present formidable
challenges to compliance among disparate hardware
elements in a multi-vendor, multi-carrier, multi-national
environment. Believe me on this one.
But this too is sometimes mitigated to a certain extent if
the chosen board-level components are standards-
compliant and tested, first. The problem becomes,
rather, one of specifying and coordinating your
intentions with the involved carriers. Ever hear of a
thing called an ISDN SPID? That should give you an
indication of what I am referring to, if you have. Next,
try resolving this and similar situations with someone
who speaks a different tongue.
---
Then there is the logical element to be concerned about,
once the call 'is' set up. Often these have to do with
specific "features." Increasingly, voice and data
systems' call processing functions are rules-based (older
ones, static; newer ones, dynamic), to govern "feature"
control, and features from Brand A don't work well or
at all with features found in Brand B. For example, the
programmed features found in a ROLM PBX, say, do
not conform to those of a Nortel or an Ericsson or a
Lucent. This impacts an enterprise considerably, as in
the case of a merger, when calling plans are established
and a group of locations need to be treated in a
customized fashion, due to such incompatibilities.
The preceding examples are those of premises-based
systems, which everyone can relate to, but the same
dynamics hold true in central offices between Class 5
switches (e.g., 5E ESSs, DMS 100s, EWSDs), and
adjacent dial-in remote access concentrators and
intelligent gateways, and so on. Next, compound this by
individual adaptations of the vendors options by each of
the carriers in the chain, and then extend the problem
overseas where there are often antiquated standards to
back into through various protocol conversion processes.
Interoperability and standards compliance, along with
rigorous debugs and shakeout exercises are paramount
before vendors can put their goods on the market for
sale in these instances.
The gateway that you are referring to needs to meet
these interfacing requirements both at the premises level
(PBXs and carrier hotels) and in the central office
(CLASS 5s). Plus, it must meet the carrier standards
requirements both domestically (ANSI/ITU) and
internationally (various/ITU). At the very least, a
considerable level of concern would be warranted, if one
were the least bit prudent, based on such a set of
circumstances, as your engineer friend has demonstrated.
It is not the same as though it were only for one or the
other (premesis or C.O). These gateways must be able to
function properly in both environments without geographic
limitations.
External interfacing is crucial, but equally as crucial on
the inside of the gateway is the need for correct
programming to effect the proper channel-seizure and
signaling actions that must take place on the interfaces.
And the sequence and timing of those external
transactions (signaling and message mode) must be
accurate to within the direction and limits specified in
the standards. Some of these vary from region to region,
and some are carrier specific. Sound familiar? ISDN is
another story that I wont even get into, except to state
that ISDN could very well prove over the next several
years to be a handy form of IP backbone supplement
when over-congestion and over-subscription conditions
arise. As a general rule, the simpler the implementation
(tie line like) the less headaches there are in meeting
compatibility requirements.
What the engineer should be equally or even more
concerned about, although he may or may not have
actually drilled down (or up) the stack this far yet,
resides in the partitioned layers of structured carrier
architectures, as would be illustrated in the emerging
Telecommunications Management Network (TMN)
Model, which are far more intricate and potentially
problematic than the actual nuts and bolts wiring and
signaling levels (lower layers) for the tie line model.
-----
Tedious, and often precarious, conditions result from
incompatibilities stemming from multi-vendor (and
M&A) activity, like you say, and these conditions don't
only exist when there is a merger. A lot of patch work is
also required in LEC COs which have undergone
routine upgrades to keep up with demand and turnover,
while they are simultaneously attempting to satisfy new
initiatives, spurred by regulatory pro-competitive
mandates. Consequently, it isn't always pretty inside
them COs, either.
In general, though, differences reside not only at the API
level, but at the upper layer code structures of the
operations support systems (OSSs) and other computing
platforms. As the name implies, an operations support
system is a set of programs and task-centric routines
(although recent ones are object oriented models
designed around inheritance and class structures) which
reside in complex operating environments that support
multiple carrier business functions, such as ...
...network management and surveillance; SS7/AIN
integration and 800 # call processing; follow-me
services; billing/accounting/exceptions; inter-carrier
data exchanges (electronic bonding); local number
portability (LNP); E- 911 functions; subscriber line data
bases; enhanced service creation and provisioning;
customer care/back office; maintenance administration
and trouble ticketing systems; engineering and circuit
ordering; other administrative functions; timing and
synchronization; corporate MIS links; etc. It's a longer
list, but you get the picture.
---
Is it likely that ITSPs will think in terms of getting
involved with all of these processes, and more, from a
VON perspective? The answer _could_ be 'yes,' but only
if there is a serious intent in becoming a world-class
telephone service provider, be it on the PSTN or over
VoIP or both. It is also possible to sidestep these
processes if an outfit wanted to remain a pure play inter-
national, or even a domestic, long distance tie line
company over an extended period. Either way, the
embedded basic telephone infrastructure that we have in
place today will be with us for at least another five to
ten years, before it begins to pick up the kind of
stigma associated with the black desktop rotary phone
of the past.
---
To date, gateways have basically "for the most part"
been used only to place analog voice and fax payloads
into IP containers for shipment over the Internet or an
equivalent TCP/IP-supportive network. They are used
to effectively create virtual tie lines or virtual inter-
machine trunks (vIMTs), without necessarily interacting
with any of the existing PSTN core signaling and data
base mechanisms, other than indirectly with those found
in end offices for reaching local called parties. These
virtual tie lines are actually replacements for the "nailed-
up" or dedicated PBX tie lines in private networks, and as
substitutes for the long distance carrier portion of the
PSTN on the public network.
In effect, by using the gateway, a new cloud (the
Internet or IP Net) is being used to bypass an older one
(the PSTN). All the while, continuing to use of the
LEC's end office switching 'machines' for ingress and
egress to the cloud.
BEGIN SIDEBAR: But is the Internet really the "new
cloud," and is the PSTN really the "old cloud?" I don't
think so. Not if we're talking about the age of the
protocols used. Most of the protocols and signaling
arrangements of the new PSTN are relatively new in the
wide area, compared to those protocols and constructs
inherent in the Internet which were born about thirty
years ago. ISDN, ATM, SONET, Frame Relay, and
WDM are all associated with the PSTN, ordinarily, and
they were all instituted within the past ten years, at
most. Some only this decade. TCP/IP, in contrast,
despite its ability to adapt continuously and adjust to
new demands through trial, error, correction, and
consensus, has been around about three times longer, at
least, than the ones mentioned for the PSTN family of
relatives. Think about that one in your spare time.
What's new about the Internet is not the Internet itself,
but the services that it now promises to support. And
support to the betterment of all, it is hoped. END SIDEBAR
In its original mode of operation, IP gateways are in
relatively little danger of getting entangled with higher
level OSS processes, because the gateway is insulated
from the OSSs by virtue of the elected interfacing
scheme. Conversely, however, these gateways cannot
easily, without the intervention from a separate form or
directory and routing mechanism, benefit from
advanced networking features, either (such as 800,
collect calling, ANI/CLID, and CLASS features such as
* 69 *71, and others). Both camps are rushing to perfect
their own flavors of these capabilities. Will they be
working at cross purposes for long? Or will the VoIP
Forum under the auspices of the ITU/ITMC see to it that
there is some form or harmonization soon?
---
But the moment that the gateway is used in the context
of a legitimate PSTN node (albeit with IP media
dependency, and I am not absolutely certain as to how
this will take place yet on a global scale) it then needs
to become concerned with compliance to a whole new set
of standards and industry practices, since standards
compatibility at this point becomes the defining means
to satisfactory performance, and more importantly,
survival.
When interaction with the carrier's OSSes or higher
level platforms [like SS7 and 800 number data bases]
come into play, ITSPs enter a brand new league, like
going from junior high school scrimmage league to the
NFL in January, and that's when proprietary solutions
are unequivocally useless and should be thrown out the
window altogether.
These are all the more reasons for concern for doing it
right the first time, and for taking one's time in getting
established properly in the beginning. If you put the
foundation in to merely satisfy the bare bone rudiments
of the initial service, you may have to tear it all out later,
in order to upgrade to the big leagues when it's time.
That may not seem like a big deal, but multiply this
process by several hundred geographic locations around
the globe, and you begin to see what I mean.
>>As new technologies are embraced, this would seem
to add even more elements into the picture. I guess I am
wondering if at some point, it will significantly delay
the deployment, by both the VPN and Telco markets, for
VoIP? ...once VoIP is in service, and the next 'Paradigm
Shifting" technology...comes along, will it delay them
incrementally more, due to the adding of infrastructure
diversity?<<
That's a series of loaded questions. <g>
"Significant" delay? No, at least not IMO. There are a
lot of brilliant people capable of fixing these issues who
are working on new standards, RFCs and internal
practices. The barriers that are keeping VoIP back right
now are an interrelated and codependent mixture of:
technical prematurity, FUD, regulatory, economic,
accounting practices, inertia related, and cultural. As
time goes by the order of significance of these factors
will vacillate IMO until a threshold is reached, and then
we will shift quickly into regarding the whole matter
like our grandparents regarded the automobile after the
horse and buggy era.
Re: Provisioning of the next gen of services or the next
step up in technology:
Historically, and to some degree this still exists,
provisioning tended to resemble bulky work, sometimes
requiring considerable logistics and physical handling of
boxes, cabling, "running cross-connects," and often
times arcane man-machine language (e.g., TL/1) for
diagnostics and for the configuring of network elements
'in person' on a circuit by circuit basis. The industry
went through several phases of a plug-in card form or
provisioning, until gradually, simpler processes were
implemented using automated console tools. These
resulted in far less manually intense fulfillment
processes. Today there is relatively little manual strain
or effort involved in upgrades, since, through the service
creating capabilities allowed by the OSSs, one could
swap out modules by selecting icons in order to
institute, remove or change the definition of a service
being delivered over a line.
Current provisioning practices are headed for total
software-controlled manipulation of already in-place
components to achieve a very wide range of capabilities.
In telecomm, as elsewhere, this is facilitated further by
the integration some AI, and largely due to DSP
technology which lends itself to flash invocations and
upgrades from one application to the next. For example,
H.323 to standard analog or pure ISDN BRI, or from
one algorithm to the next, say G.729A, to G.723.1,
without notice, on the fly, so to speak.
For migrating to newer generations of services, even
new technologies, intelligent service creation
capabilities may increasingly be used to enhance the
process considerably, without toil, relatively speaking,
provided the proper hooks (chips) are in place or could
be substituted, I suspect. Can't be certain about this one.
But in order to maximize the possibilities of success,
well-thought out architectures need to be put in place
that allow for the extensibilities that may be required.
Which brings us back to the question of your engineer friend,
and one of the reasons it is necessary to have in place a
solid architectural foundation.
Hope this helped, and Regards,
Frank Coluccio
|
