back to article Unified comms means a unified technical approach

The very nature of unified communications (UC) with its many component parts – voice, video conferencing, audio conferencing, presence and so on - means that when it comes to scoping implementations from a technical perspective, requirements will necessarily cut across different disciplines. Precisely for this reason, it …

COMMENTS

This topic is closed for new posts.
Flame

Is it all so new?

I used to be a fairly competent and technical person working in the telecom sector a couple of years ago - after the latest round of wholesale butt fcukng I now consider myself unemployable. I worked in telecoms since 1988 on a number of technologies and since about 2000 I started seeing very specific skills requirements that looked like thinly veiled age discrimination policies.

Anyone who formerly worked on fixed network infrastructures was deemed useless as far as mobile communications was concerned. Anyone who worked on ISDN and C7 signalling could not possibly comprehend the new infinitely more complex domains of VOIP, GSM/GPRS. This mentality continued down the years, having started at the bottom rung in 2001 in mobile handset development, I found that much of the old technologies were redeployed from existing specs almost unchanged into mobile comms.

Now I am on the scrap heap because I have only worked on GSM and GPRS and not on HSPA, 3G and LTE technologies.

MY POINT HERE IS: why is it necessary for the tech industry to PURGE itself of those it deems to have an antiquated knowledge base? Aren't those that have spent time learning previous technologies capable of reapplying past experiences and knowledge to the new stuff?

How can new UNIFIED COMMS architectures be developed when those that have seen the challenges of past applications are written off? Also how much of a system can you simply buy in ready made from somewhere else and integrate into your new architectures as a bunch of black boxes before you need to import the designers, testers and integrators as well?

0
0
Bronze badge

Simple.

It's because unless you were *really* incompetent you'd realise that the new technology is vastly inferior to the old tech, and forsake putting new equipment in.

Working in an SME I was responsible for the telephone switches as well as the IT stuff. The telephone switches design was at least 15 years old, it was never replaced simply because it worked. There was 30 seconds of downtime in ~5 years, caused by a programming error by myself.

Later, working for a large publicly owned healthcare organisation I encountered VOIP being used on a reasonable scale. They had ~15 sites running VOIP systems, requiring two very overworked techs to deal with the workload. Downtime effecting users was a daily occurrence on these systems.

They also had a large number of legacy telephone systems (~315) being managed by two staff, who were also dealing with mobile phones. They weren't exactly rushed off their feet and were completely stable, apart from power cuts etc.

Why would anybody want to move to a new system reinventing the wheel, with less functionality and stability than a 15 year old clunker?

0
0
Flame

Is it all so new?

I used to be a fairly competent and technical person working in the telecom sector a couple of years ago - after the latest round of wholesale butt fcukng I now consider myself unemployable. I worked in telecoms since 1988 on a number of technologies and since about 2000 I started seeing very specific skills requirements that looked like thinly veiled age discrimination policies.

Anyone who formerly worked on fixed network infrastructures was deemed useless as far as mobile communications was concerned. Anyone who worked on ISDN and C7 signalling could not possibly comprehend the new infinitely more complex domains of VOIP, GSM/GPRS. This mentality continued down the years, having started at the bottom rung in 2001 in mobile handset development, I found that much of the old technologies were redeployed from existing specs almost unchanged into mobile comms.

Now I am on the scrap heap because I have only worked on GSM and GPRS and not on HSPA, 3G and LTE technologies.

MY POINT HERE IS: why is it necessary for the tech industry to PURGE itself of those it deems to have an antiquated knowledge base? Aren't those that have spent time learning previous technologies capable of reapplying past experiences and knowledge to the new stuff?

How can new UNIFIED COMMS architectures be developed when those that have seen the challenges of past applications are written off? Also how much of a system can you simply buy in ready made from somewhere else and integrate into your new architectures as a bunch of black boxes before you need to import the designers, testers and integrators as well?

0
0
Silver badge

Nothing new.

Back in the early-late 1980s, I was part of the team that deployed IBM's internal network (vastly larger than the Internet of the day). It was primarily designed to move data around, but from my lab in Redwood City, CA I could get local dial-tone in every major city that IBM had presence in, world-wide. Likewise, I could setup video conferencing between any two or more IBM locations that had sufficient bandwidth. Anyone with adequate permissions & passwords at IBM could do the same thing. Bandwidth was dynamically allocated out of the data stream, according to "importance" of the voice/data calls over the network.

It started as a test network, to eyeball the feasibility of such a system, but quickly grew to be ubiquitous throughout IBM world-wide (I have four or five passports-worth of stamps to prove it ...). It routed TCP/IP, X.25, TokenRing, ArcNet, AppleTalk and various other protocols transparently. We tunneled Ethernet, transparently, world-wide, despite the so-called distance limitations. I could move Sun source code from Sun's Palo Alto Fabian Avenue HQ to my Seaport Bvd. office in Redwood City faster over the IBM network than over the Internet, by a couple orders of magnitude and with no bit-errors. It had a learning curve[1], but it worked perfectly.

Ultimately, while we learned a lot from the exercise, it was written off. Data pipes are data pipes, and can be used for occasional video, but telephony is better handled by dedicated telco circuitry and YABHPBXAOTD[2] ... End users just aren't geared to understand HowItWorks(tm), and setting up and taking down voice calls is much better handled by a dedicated "black box".

[1] My group was the only group of people I ever worked with who all understood hardware to component level, could program in multiple languages, and across multiple architectures, grokked Core issues of multiple OSes, had real-world networking experience (most of us did spanning tree in our heads[3]), understood both voice and data, could spec both power and HVAC, and most of us were proficient in cost/benefit analysis. If we had had any sense, we would have split off and formed our own company ... oh, to be in my 20s again!

[2] YetAnotherBloodyHugePrivateBranchExchangeAcronymO'T'Day

[3] Was handy, in the days of static routing tables ... [4]

[4] Granted, the Internet was a lot smaller back then ;-)

0
0
This topic is closed for new posts.

Forums