The IP Transition Part 2: Enterprise and Consumer ImpactThe IP Transition Part 2: Enterprise and Consumer Impact

Some of the devices now supported on the PSTN will have to be re-engineered for the IP connection, at considerable cost to the enterprise and consumer.

Communications providers, especially AT&T, have been pushing the PSTN toward IP evolution. They talk about aging infrastructure, the value of moving to an all-IP network, and the services they could provide. What I have not read about is the impact on the enterprise and consumer--notably what it will cost them. (I don't expect providers to absorb these costs. If they do, then they will indirectly charge us anyway.)

Nor have we heard about the difficulties of supporting a wide range of devices and services that are currently supported by the existing PSTN. Do the PSTN providers even know what is on their networks?

In my previous blog, "The IP Transition Part 1: Some Thoughts," I explored some thoughts that relate to SIP trunking and its limited support. I described how SIP trunking, an IP network connection, does not support many legacy device connections. I also looked at the probable elimination of legacy phones and the potential need for Session Border Controllers (SBCs) everywhere.

In this blog, I will be covering a number of issues, especially PSTN network legacy device support, which will probably force extra costs on the IP provider. Some of the devices now supported on the PSTN may have to be re-engineered for the IP connection, at considerable cost to the enterprise and consumer. The IP transition could disrupt the already limited IT resources, diverting them from valuable enterprise projects.

What's on the PSTN that may not work on IP (without changes)?
Many phone locations, device types, and telephone network services will have to be supported on the new IP public network. Many of these work over the legacy PSTN because that is the only or cheapest method of supporting them.

The following list is not exhaustive, but it demonstrates that the IP providers or the enterprise and consumer may have to make some possibly costly changes for endpoints. At minimum, the endpoints will have to be supported by gateways on the enterprise/consumer premises at a cost to them, not the service provider. As you go through the list, think about which other endpoints bypass the IP-PBX and connect to the legacy PSTN.

• Analog fax machines that operate the T.30 standard (This was discussed in the previous blog)
• Dial up modems mostly for PCs, not common today but still out there
• Point of sale devices and credit card readers
• Secret analog lines for special conditions such as a whistleblower connection
• Analog phones in otherwise unoccupied buildings. I found a university that had 200 buildings with analog phones, but only 100 buildings were continuously occupied. Would you install IP connections in the 100 unoccupied buildings?
• The janitor's closet--does it deserve an IP phone?
• Keeping analog phones in common areas that have little physical security
• That guard shack that is hundreds of feet from any building and can only be economically accessed on an old analog line
• The phone line outside a building that is used to call the guards for off-hours access should be an analog line to ensure security. Would you put an Ethernet port there?
• Emergency phones as a lifeline to the PSTN, which use analog connections
• Warehouse phones where it is expensive to install Ethernet lines just for a phone
• Supervisory control and data acquisition connections that are designed for analog lines
• Intercom endpoints
• Announcement and paging endpoints
• TTY and TDD--These are different names for telecommunication devices that make it easier for hearing-impaired people to talk over telephone lines. TTY stands for telephone typewriter, teletypewriter, or text phone. TDD stands for Telecommunications Device for the Deaf. Solutions exist, but who will pay for them--the provider, or the user?
• Telemetry systems--I know of a military base that has all of its telemetry on a PBX that was transitioned to an IP-PBX. It didn't work until all the endpoints and the telemetry processing system was redesigned to compensate for the latency, jitter, and packet loss. This site still needed a gateway to connect to the telemetry endpoints and system because upgrading them to IP was beyond their budget.
• Elevator phones for calling out to the PSTN in emergencies
• Alarm endpoints for fire, smoke, and CO² monitors
• Environmental measurement and control endpoints
• Door access and security controls

There are IP-based products on the market that can replace most of these endpoints; the issue is that the cost of changing these endpoints comes out of the enterprise/consumer budget. As an example of the endpoint issues, most cloud communications providers do not support most of the above mentioned endpoints. Supporting the endpoints on a cloud does not generate the revenue to pay for the support implementation and operation.

Emergency services: 911 and E911
The next generation of 911 services is called NG911. It will add more dimensions to answering emergency calls. A 911 call is routed to the nearest Public Safety Answering Point (PSAP). The caller must tell the PSAP personnel the location information and type of emergency assistance needed. But when establishing an Enhanced 911 (E911) call, your voice is not the only thing being transmitted in the network--the PSTN switch also sends out an Automatic Number Identification (ANI) signal to the network. The ANI is employed in relaying needed information to the local PSAP so it can dispatch first responders.

In the future, the local NG911 center will be able to receive a multimedia IP-based call and handle incoming texts, photos, videos, and video chat for impaired callers; the ability to handle different media allows emergency dispatchers to distribute the appropriate resources more rapidly compared to traditional 911 calls. Overflow calls can be automatically distributed to other 911 centers as needed, just like overflow calls are handled by multiple call centers in enterprises. Any vehicle with an Advanced Automatic Collision Notification (AACN) system can automatically send crash data to the 911 center, which dispatches the correct emergency services, even if the passengers are unable to respond.

This is all great, but the enterprise will have to implement its end of the call, add network location technology using IP networks. NG911 trials are being performed now, however, it is likely the PSAP budgets will be limited; therefore an enterprise may have old E911 service in one location and NG911 in another location, complicating support for E911. (See "Impacts of NG911".)

I have Verizon FiOS service with my business phone and fax lines. When I have a power failure at my office, my ability to call 911 is limited to the battery life in my FiOS interface unit (only 8 hours). I have a POTS line as well where I have no such limitation. This means that the IP version of my phone service is already hampered by my transition to the FiOS service. It begs the question, "What else have I lost for emergency services by moving to FiOS, that will also be lost after the IP transition?"

Producing the PSTN connection inventory
The list of devices and services already mentioned is not exhaustive. There are many devices unique to an industry--sometimes unique to an enterprise. It is imperative that the IT staff perform a thorough analysis of the existing PSTN connections. Some of the connected devices may be a decade or more old and therefore have been forgotten. In one of my VoIP/UC procurement projects, we kept finding devices over a period of 4 months that were not cataloged anywhere. It is not safe to assume you have cataloged all of them.

You probably have some T1 and PRI connections to the PSTN that will no longer be available. Also, look at your call center and help desk to determine if the IP transition will affect their operations, such as a change to the call recording, work force management, or internal billing systems.

After the inventory
Survey the locations of the legacy devices. Is there an Ethernet LAN connection nearby? If not, what is the cost of installing a LAN there? Create a draft budget to replace the endpoints with IP compatible devices, and the cost of implementing the LAN connections.

An alternative solution is to keep legacy devices and cabling. The legacy devices can connect to a gateway installed in a network closet. Then budget for the gateway and its installation. However, there may not be a gateway on the market that will support the legacy devices. In that case, you will be forced to pursue the IP-capable devices and LAN connections.

No matter what path you follow, it is essential that you inform the C-level management of the impending cost for transition to an all-IP public network.

Blog # 3
In the final part of this series on the IP transition, "The IP Transition Part 3; Getting There," the blog will explore some of the operational issues that will surface with the IP transition. Some of the issues covered include:

* What does the legacy PSTN not know is on the networks
* Traffic management
* Provider's reports on QoS/CoS and performance monitoring, and availability and reliability.

I will also look at how the enterprise/consumer should be notified of the transition, and what will most likely occur during the transition.