Goodbye to copper? [Telecom]

No it is not wired into the software. Do you think switch manufacturers only want to sell their gear in the U.S.? Of course they don't. They want to sell all over the world.

But here's the game that Lucent/Avaya plays. You pay for software features to be enabled on your swtich. It's there already, they just have to dial in and switch the feature on.

Yeah but # still gives the switch the ok to process the call as dialed. I know on my VoIP service from Vonage if I terminate all dialed numbers with # it puts the call right through instead of [after] a few seconds timeout [interval].

Why does direct dialing of international calls work?

My Meridian 9516 (10 years old, I believe) single-line set's repertory dialer will store up to 24 digits per entry. I haven't checked my latest cordless phones, but I suspect they are similar.

Years ago when full SATT was implemented there was a major media blitz to remind callers they must dial 1 before the area code and with some offices that were SATT Access they had to dial a 1 before a 7 digit number that was not within their local dialing. Those were the days [when] we could dial the last 5 or 4 digits to reach a local number.

What about the processing power of a DMS-100 installed in circa 1984? There are a whole lot of those.

Because Ma recognized early-on the value of exception handling/ special cases; you deal with them separately.

Once you dial "011"; it is a different ball game. You can afford to dedicate special facilities to coping with same.

I find this story lacking credibility for lots and lots of reasons. *

We got new area codes, and the new area codes didn't have a 0 or a 1 in the middle digits. This is what finally convinced GTE to get us off of a mechanical switch and onto something modern that actually works.

BUT, in the cases of PBXes, many of them depended on that 0 or 1 to identify an area code and the actual algorithm for splitting the number apart had to be changed.

This was unrelated to Y2K and occurred a bit before the Y2K changes, and it was a big set of headaches for everyone involved.

Yes, but this was more than just a code assignment change.

--scott

As will the international call go through without a "#" if you wait a few seconds, perhaps 5.

The example was discussing COBOL programs and transtioning to more modern techniques. The programming of an ESS is a different ballgame.

As to training ESS programmers, I still do not think it's necessary to go into great detail about No. 5 crossbar junctors, markers, senders, etc. An summary overview would be sufficient. We don't teach programmers today how to work a keypunch machine.

I believe the entire U.S. was ESS by the late 1980s. Are you saying GTE had an electro-mechanical central office in 1999?

Sounds like very sloppy PBX programming. If the machine was leased, it was up to the vendor. But if the machine was wholly owned, it was up to the customer to contract for an upgrade. Ownership has its downsides.

It is curious though, because in 1976 the Bell System published in print that area codes would no longer be 0/1 and that exchanges could be 0/1 in order to accomodate the growth in phone numbers. So, any PBX designed after that should've been able to accomodate.

In the old days a PBX merely transmitted whatever was dialed through to the trunk. Newer PBXs may have tracked numbers for routing purposes over the most cost-effective trunk. But if they did that, then obviously they had to be table driven, and then obviously needed some way to update the table to reflect new exchanges. Adding exchanges and area codes is certainly nothing new.

Indeed, one could ask why the heck didn't a PBX have a _good_ method for keeping its internal tables properly and timely updated?

By the time these non 1/0 area codes were in use GTE had either gotten away from mechanical switches or already had its toll centers electronic.

I would have also, had I not actually taught a similar sort of class.

--scott

Perhaps AT&T has some idea that they'd number the entire world's telephone networks, but one wonders about the length chosen.

Mexico was never in the NANP. There were special dialing procedures to reach northwestern Mexico where telephone systems were installed thanks to US investors, and a special dialing procedure to reach Mexico city using a dialing sequence that fit into NANP dialing. There was a long transition period in which these areas could be dialed either NANP style or using Mexico's country code. Eventually the practice ended when NANPA reclaimed the reserved dialing procedures for new area codes.

Mexico City was dual-numbered, but I'm not sure if dialing northwestern Mexico from the rest of Mexico required the use of a different dialing procedure for a domestic call or if it was treated as if the call was handed off to a switch across the border.

See

It's like the Y2K issue -- making the individual changes was generally _not_ a big task (although there were exceptions to that); *FINDING* all the places where things had to be changed was a whole nuther matter.

The 3+3+4 number format _is_, for practical purposes, "hard wired" into the control program software. It isn't that the switch "can't handle it (a longer, differently formatted number)" -- it *can*. *All* modern switches are required to accept dialed-digit strings of at least 16 (19??) characters. *BUT* they "don't know what to do with it" other than hand the entire thing off (what is called an 'opaque' object -- don't know, nor care, anything about the internal structure) to a 'foreign' switch based on the first (up to 4) digits after the international-dialing prefix. A local CO probably doesn't even look at _those_ digits, it sees the international ("011") prefix, and "passes the buck" to the toll tandem, which may do minimal parsing of the country-code (if nothing else to determine whether to route via East or West Coast, or towards Central/South America.

There's also more than 'just' the C.O. switch that has to be considered. Courtesy of 'local number portability', there is a database look-up ("dip") that has to be done for effectively every call, to find out 'where' that must be sent for delivery. That database, for performance reasons, requires a fixed-length 'key' (the phone number) field. Increasing the size of the key is a relatively minor task, but it requires a 'flag day' cut-over, *AND* assurance that the protocol for querying the database can handle the extra digit(s) properly.

Also, significant parts of the _hardware_ design are also predicated on certain economies based on the specific _scale_ of the elements in th 3+3+4 design. This constrains 'where and how' you can stick extra digits into the dial-string.

Especially considering that there's no way it could be done as a "big bang" so that the software would need to work in dual mode during the transition period.

-- Julian Thomas: snipped-for-privacy@jt-mj.net

Umm, no. Many PC based systems did not need modifications. However I discovered an obscure Y2K bug within Access in about late 1998. MS did fix the bug.

However most/all mainframe/mini based systems did need a *LOT* of work. And very thorough testing. I know this because all the code and systems I built in the 1980s were *not* Y2K compliant and would've needed every program to be examined. And I know that in the 1980s and even to the mid 1990s very little attention was paid to Y2K work.

Given a choice between building new systems, or making enhancements to systems vs Y2K remediation which has no visible impact (other than the survivability of your employer in a few years) which option do you think most IT managers took in the early to mid to even late 1990s? "Nah, let my successor worry about it. Oh, and when I take a new job I'll just blame my predecessor."

Tony

This sounds like Nortel (DMS-100) and AT&T/Lucent (5ESS) locked themselves out of the international market.