VoIP in the Real World


Your studios’ traditional phone service is going away. You’ll need to find an alternative.

Your legacy business phone service is going away, too. What are your plans to replace it?

Your business phone system is based on TDM technology; another company bought the original manufacturer; support is either expensive or non-existent.

Your listeners are calling from mobile phones, and VoIP phones. How well does your studio gear actually work with those?

It’s cumbersome, and perhaps impossible, to transfer calls between your business phone system and your studio phone system.

Your office phones and studio phones are completely separate services, and are even delivered in different formats. One or both of those is changing.

Management of your phone system is out of your control; you’re dependent upon legacy providers and technicians who no longer or never did understand the particular needs of broadcasters.


Yes, We Are Retiring

Just over two years ago, AT&T asked the US Federal Communications Commission to eventually order the shutdown of the Public Switched Telephone Network, or PSTN – the ubiquitous telephone system that provides POTS, T1, and ISDN switched voice service.

In a public response to the FCC’s request for comments regarding its forthcoming National Broadband Plan, AT&T acknowledged not the future obsolescence, but the current obsolescence of the PSTN telephone system, the one-time marvel of technology that defined its predecessor, the Bell System, in the 20th century.

AT&T wrote: “Due to technological advances, changes in consumer preference, and market forces, the question is when, not if, POTS service and the PSTN over which it is provided will become obsolete.”

As broadcast engineers, we’ve witnessed the demise of traditional Broadcast Remote Program Circuits and STL Program Leased Lines quite some years ago. More recently, telcos have been discontinuing new ISDN installations.

In some locales, traditional, switched phone services are not available at any price for new installations. Broadcasters and other businesses have experienced this in large, modern European cities – not in unwired, third world countries.

IF NOT THIS, THEN THAT

Maybe your last-mile, legacy POTS or ISDN service appears secure for now. Consider that more, if not most, of the infrastructure between the caller and your station is transported as Voice over IP.

Conversely, perhaps your business calls are already brought in as VoIP over SIP trunks. You could be converting these VoIP calls into ISDN or POTS connections locally via your in-house PBX. You’re converting these because your studio talkshow systems and other phone hybrids don’t connect directly to VoIP. They only connect to POTS or ISDN circuits.

Many stations in larger cities have suffered with a different annoyance for years – the so-called “choke circuit”. Designed in the 1960’s by incumbent phone companies, choke circuits were designed to protect phone company central switches while ostensibly leveling the playing field for radio contest callers. Choke circuits are often using the same equipment or technology as when they were installed decades ago. This lack of infrastructure upgrades to choke circuits usually leaves them as the worst-sounding telephone connections available, yet the only type that incumbent phone companies will supply as radio station call-in lines.

What to do?

 

VoIP Anticipation

Just a couple years ago Telos founder, Steve Church, stood before a similar gathering of engineers at NAB. He pointed out the following:

With VoIP PBXs becoming widespread, VoIP telco service on the horizon, and AoIP quickly taking hold for building studio infrastructure, IP-based on-air telephone systems can’t be far behind. VoIP phone systems and AoIP studio networks can be tightly interconnected, creating numerous benefits with regard to ease of installation and support of desirable features. Unnecessary analog-to-digital and 2-to-4 wire conversions are eliminated, allowing calls to pass cleanly over the studio network for better sounding callers. Much development is taking place in the VoIP world, and some of it has strong bearing on the technology’s application to broadcasting and other audio production facilities. As the technology matures, so should broadcasters’ awareness of it, such that its advantages can be put to proper use in radio and television production systems.

More of the calls inbound to broadcast facilities are VoIP, managed by SIP, or “Session Initiation Protocol”. More of these calls are VoIP over more of their transmission path, as both Incumbent and Competitive Local Exchange Carriers (I-LEC’s and C-LEC’s) are part of the phone call picture. Even if your studio lines are POTS from your I-LEC, many calls originate with and are transported by other carriers. By the time a call reaches your studio phone hybrid, it may have experienced several transcodings and several transitions between analog, framed voice path carriage, and packetized voice path carriage, or VoIP. Some of these transitions cause audio degradation, while others do not. None of this outside your facility is under your direct control.

However, there are steps engineers can take to eliminate extra audio transcodings and call format transitions. VoIP connections can be provisioned from modern phone carriers all the way in to studio phone hybrids. Calls stay in the same digital VoIP format, at least from the chosen carrier all the way into the studio talkshow system. From that point, call quality will only get better as more callers and more infrastructure are using VoIP from end to end.

While the telecom industry is experiencing some fundamental transitions, broadcasters can now plot their course with confidence. Engineers can “begin with the end in mind” and upgrade parts or all of their studio and business phone systems to VoIP standards. Even if dedicated SIP trunks are not yet readily available, engineers gain additional operational capabilities with a SIP-based studio phone system, while simultaneously preparing for an eventual 100% SIP environment. In any use case, broadcasters benefit from added convenience, lower cost, better audio quality, and more efficient use of telephony resources.

 

In-Studio VoIP is Here

The Telos VX is a VoIP talkshow system for broadcasters. It’s the first on-air talkshow system designed to natively connect to SIP trunks. Because broadcasters depend on certain workflows for screening and airing callers, this new standards-based system is designed from the start to fit into all manner of broadcast workflow and program formats.

VoIP technology, and the SIP protocol that carries it, are new to most broadcast engineers. While we have all connected Analog Terminal Adapters (ATA’s) from Vonage or MajicJack, the specifics of SIP setup remain a mystery to many if not most of us. At this time, a multi-line, multi-studio SIP-based talkshow system is not a “take it out of the box and plug in the RJ-11’s” proposition.

Since 1984 Telos has led in the adoption of new technologies by broadcasters. Simplification and education are a key part of that leadership. This is the phase we’re wrapping up now with VX, the first SIP-based broadcast talkshow system. The case studies we present here will demonstrate the early challenges, and the solutions that have put these talkshow systems on-air in daily use.

In the two years since Steve Church shared his vision for a fully integrated SIP talkshow system, we’ve completed the beta phase of development and we’re now actively shipping and installing these SIP-based talkshow systems. During the beta period, we learned a lot about SIP implementations. Many of the issues found are due to differences among service providers, central office switch vendors, and network topologies. Each experience with installation and provisioning is documented and reviewed. Updates to VX software rising from actual field experience makes subsequent installations that much easier.

THE SETUP

The Telos VX system uses the Livewire Audio over IP (AoIP) protocol for broadcast audio I/O. Everything in and out of the system comes over Ethernet, both lines and audio. So any VX installation will have three interfacing considerations, network, audio and telephony. The remaining considerations relate mainly to user preferences and work flow.

AUDIO INTERFACING

The broadcast audio interfacing is the simplest part of an installation. If the broadcaster has Axia consoles, the VX’s Livewire streams are simply present on the AoIP network’s Ethernet, and can be selected and routed via their normal web based configuration. Mix-minuses are created for phone channels automatically and control functions are tightly integrated with the consoles. If analog audio or digital AES audio are desired, Telos Audio interfaces on the network convert the AoIP audio streams to and from analog or AES, allowing those signals can be connected to consoles or other audio routers.

MORE COMPLEXITY ON THE ‘TELEPHONY SIDE

The Livewire AoIP network is mature and predictable, with over 100,000 stereo Livewire streams coursing through broadcast facilities around the world today. Because of this, there are few, if any, surprises when implementing it. More challenging is the telephony side. SIP telephony still has many characteristics of the Wild, Wild West. With multiple service providers, different kinds of gateways, special configurations, and possibly unique customer implementation goals, planning for an installation requires different and perhaps more consideration than with POTS or ISDN.

SIMPLE VOIP INSTALLATIONS

The simplest installations have a single connection to the outside world, most often through a VoIP PBX. In these installations, the VX broadcast phone interface or ‘engine’ is connected only to the PBX. All lines and trunks from all providers are also connected to the PBX and routed appropriately by the PBX. The VX is provisioned with ‘extensions’ from the PBX and inbound Direct Inward Dial (DID) numbers are ‘pointed’ to these extensions.

Kuic Radio, Vacaville, California

voip-real-world

The first VX system beta test was done at KUIC radio in Vacaville, California. The station had just moved into new facilities with a SIP PBX, the open source Asterisk system. It is connected to the Public Switched Telephone Network (PSTN) via an ISDN Primary Rate Interface (PRI) provided by TelePacific, a regional Competitive Local Exchange Carrier (CLEC). The station has no POTS service. That system runs all office and studio phones. The system is in daily use and further expansion is planned.

The VX system is connected ONLY to the PBX. All calls, incoming and outgoing, go through the PBX via SIP, thus there is no further interfacing to the PRI or any POTS lines. This is as simple as it gets. We used an Axia Power Station to break out the audio and control with this VX installation as it had all of the necessary components “built in”, notably a Power over Ethernet POE switch, Analog and Digital audio IO, and GPIO for warning lights and delay dump controls.

corus-com-voip

Asterisk PBX services:

  • Network Time Protocol (NTP)

  • syslog logging server, logs all devices

  • Call detail recording

  • Voicemail

  • sIP registration

  • VPN access to all networks for maintenance

Corus in Winnipeg consists of a three-station cluster: CJOB, a full service 50 KW news/talk station that also originates a fair amount of national network programming; Power 97, an Active Rock station with a high profile morning show; and, Groove FM, which is music intensive, though with a live morning show.

The stations’ requirements and the availability of SIP trunking from Shaw Communications, a Corus partner company, made the facility an attractive choice to test some new connectivity options with the VX.

John Wall at Corus, Winnipeg, wanted to use multiple telephone providers, SIP trunking from Shaw, POTS and a PRI from the utility, MTS, and analog gateways to allow the use of existing Mitel PBX extensions and a few other POTS lines.

PHONE LINE AUDIO-INTEGRITY

It’s always best to keep lines “4-wire” that is, with separate transmit and receive audio with digital delivery as much as possible, so the station decided to use call forwarding from the analog lines to the new Shaw DID numbers, this way the lines never “went analog”, degrading audio performance. This also eliminated the need for additional Analog Terminal Adapters (ATA’s) often called ‘Gateways’, used to take 2 wire POTS lines and convert them to 4 wire SIP. We would only have to use the gateway boxes to convert Mitel PBX extensions from the office phone system for use with the VX.

Upon further investigation, it was learned that the Mitel PBX could support SIP stations directly, though with an expensive software upgrade and substantial additional licensing expense. It was decided that this could wait a while as the new studio construction was running on an aggressive time line.

Once the Livewire AoIP audio network was set up, initial tests were made with the newly installed Shaw SIP circuit. Unexpectedly, even though it was a dedicated circuit, the Shaw trunk required registration, which at that time the VX did not support (it has since been added and is now fully supported). Registration is the process where the client system logs into the providers network with an ‘Auth ID’ and password, sometimes called a “secret”. Once any one line is registered, all of the trunk’s Direct Inward Dial (DID) numbers become available for use. Registration reoccurs regularly as negotiated by the systems. We also learned that registration status is a good troubleshooting aid. A successfully registered line or trunk will generally have no connectivity problems and its status is easily checked from the VX’s web GUI.

ASTERISK: THE TELEPHONY SWISS ARMY KNIFE

With the immediate need for registration support and very limited time to get the whole system working, it was decided to build and Asterisk PBX from available hardware and configure it to perform the trunk registration function and connect via SIP PBX extensions to the VX. Once complete, the trunks successfully came up and calls were routed to the pre-programmed extensions on the VX. The audio and signaling were perfect and the caller ID information intact.

With the Asterisk PBX on the network, it was simple to add additional useful services such as centralized logging via Syslog, a Network Time Protocol (NTP) server and Voice Mail with interactive Voice Response (IVR) functionality. The long term and very detailed log data has been especially useful for troubleshooting and allows secure remote network access to the Telos support team as needed. The Call Detail Recording (CDR) also has been helpful to the station for research, showing the source of all calls and the number and length of those calls, including call attempts to busy numbers.

At the time of this writing, the system has been operating for well over a year and now processes about 120,000 calls per month. It has never crashed or required a reboot.

Finally, the analog gateway was configured, and connected to the Mitel PBX. It was set to forward incoming calls to the Asterisk PBX, which would send them to a specific extension button on the VX. Outgoing calls could now be placed on the Mitel as well. The gateway device was configured to send its own logging data to the Syslog server on Asterisk providing a complete picture of everything happening on the network.

The syslog server, running as a service on the Asterisk PBX, monitors the Asterisk PBX itself, all Axia hardware, the VX engine, the analog phone gateways, and even the Internet router. All devices are time synced via NTP to ensure that logged events are all time correlated. The large hard drive in the Asterisk PBX allows storage of very detailed debugging logs for long periods of time. The PBX’s own Call Detail Recorder (CDR) has also proven very helpful for troubleshooting as every detail of every call the system has received is stored and searchable. It’s been extremely helpful in debugging and the use of Syslog is suggested for most large or complex installations.

“CHOKE LINES”

Everything was working well - with one exception. We’d tried to “port” the high volume “choke” numbers over to Shaw. On the day of the porting, we got a call from telco saying that porting the choke numbers couldn’t be done. This has been our experience with all attempts to port choke numbers in North America, with rare exceptions.

The fallback plan was to call-forward the choke lines to the Shaw DID numbers in an attempt to keep the calls “four wire all the way”. A tech was sent to the old studio location to forward the phones. When he dialed the feature code used to activate call forwarding, instead of the expected dial tone that would prompt you to enter the destination number, a confirmation tone was immediately heard. This essentially meant that you couldn’t forward the line to the destination of your choice. After working with the local phone utility, MTS, we found that the lines were provisioned long ago, with an unusual variation of the call forwarding feature, that required the destination number to be set in the central office switch by telco technicians. These numbers had been in service for many years and were provisioned in an unusual way. Eventually, MTS simply changed the type of call forwarding feature on the lines, and all was good.

For the first few days, only one call at a time was forwarded through to the Shaw DID’s from the choke network. This was clearly not the desired behavior! Our discussions with the utility, MTS, led them to understand and correct the problem. There is a setting in the Central Office switch that limits the number of simultaneous calls or ‘paths’.

There are many provisioning options in a central office switch, and much history and related lore. To telco guys, the choke network is generally not understood and is usually feared. They are convinced that your massive call volume will bring down their entire network, and they also don’t want to cause problems that a popular morning radio show host will talk about on the air, so they tend to be overly cautious. They also tend to have no idea what your actual traffic volume looks like.

The PSTN is now much more robust and powerful than the network of say, 1980. There are no mechanical central offices and few (if any) analog trunks. Interestingly, the first choke networks were implemented in the 1960’s. The prolems that the “choke” solution prevented simply don’t exist anymore. The system was created when trunks were the scarce item, to be shared and rationed. Calls to busy numbers (radio stations giving away cars, more scarce these days than trunks!) would use a trunk just to play the busy tone to callers. When a call is made today, and it’s busy, most often the busy tone comes from your own central office or even the instrument itself, as is the case with a SIP phone. Each call is simply a data transaction. The routing is based on a database lookup, not unlike DNS on the Internet.

The telco engineers who came up with the early high volume solutions are retired or worse, and thus not available for consultation about network design challenges or explanations of the system that they designed long ago. So choke lives on, frozen in time and purpose.

The truth is that most stations really don’t need choke numbers anymore. Unless your station is giving away cars or houses every hour, it’s unlikely that the Telco would even notice your traffic. Still, If you do frequent contesting, you may wish to consider asking your SIP provider or Telco to limit the number of calls that it allows through to an individual DID number. This would be done mainly to avoid overloading your PBX or VX that is handling all of the extra call setup messages, that simply tell the phone company to return a busy signal to callers. There’s no good reason to keep your systems busy handling call setup messages for calls that will never actually get to you.

 

In The Newsroom

The CJOB newsroom has small consoles at each workstation with a mic and routable inputs. Phone interviews are recorded at these workstations from calls that come in from the main switchboard. We needed to find a way to get those calls into the VX, and get the hybrid audio of interest into the consoles.

The VX has a feature that allows for a dedicated console fader per line, and dedicated lines also have an available auto-answer function. We simply created a few lines in Asterisk and set them up to auto-answer in the VX. When a call comes in from the switchboard, that caller is answered on the Mitel office phone by the reporter. If the reporter decides to record the caller, he simply transfers the caller to an extension by pressing two buttons. The call is then auto-answered by the VX and the conversation continue through the console and microphone, and may thus be recorded.

peak-broadcasting

The Telos VX is as much a paradigm shift in the broadcast industry as VoIP is to the telephone industry. In the early days of VX development, it was important to Telos to get as many systems “out there and in daily use” as possible. We knew that the “real world” had much to teach us. With the beta program in full swing, we’d simply ran out of prototype hardware to deploy, mainly the VSet phone instruments. The first prototype VSets were very expensive and only a few were built. On the other hand, VX engines were easily available as they shared the same hardware platform as other Axia gear.

Joe Mauk at Peak Broadcasting in Fresno, California, understood the system’s potential and recognized that it would be a particularly good fit for his six-station cluster. Two of those are talk stations. Telos wanted more beta sites and the only problem with setting him up was getting him enough VSets.

At that same time, Broadcast Bionics, a Telos partner company, had just modified its popular PhoneBOX software to run with VX and wanted to test it. PhoneBOX is a touch-screen controlled, database-driven call screening and control solution. Peak Broadcasting had also expressed an interest in a PC or touch screen type user interface for the VX. Telos and Broadcast Bionics offered Peak the opportunity to beta test both PhoneBOX and the VX, and they accepted the offer enthusiastically.

The first step was to figure out how to get lines into the system. The stations were using a large 1A2 key system and a mix of Telco POTS and PBX extensions. Our goal, as always, is to get the lines delivered in some 4-wire fashion. The DID PBX extensions would be no problem as they were 4 wire from the phone company, delivered by ISDN PRI. They were only 2-wire at the PBX extension line card, which we wouldn’t be using.

We considered the use of a PRI gateway device or an Asterisk PBX to accept traffic from their Eon Millennium PBX to then convert it to SIP to keep the traffic four wire all the way. Asterisk was chosen because Joe also wanted to use the G.722 7khz wideband codec that the VX supports for remote broadcasts and news reports, and the routing flexibility that Asterisk provides would give him many other options.

The remaining problem was that there were still some old copper-loop POTS numbers currently being used on the 1A2 key system. Joe decided that the numbers could be ported over to one of the CLEC PRI’s that feeds his office PBX, the Millennium as DID’s. The on air calls would then come into the station on the four-wire bearer channels of the PRI and could be routed to the Asterisk PBX for use with the VX and simultaneously to analog PBX stations to run the old 1A2 gear. This would give us complete call routing flexibility, caller ID support and a simple fallback solution in case of initial trouble.

Porting the phone numbers went flawlessly. We configured the Millennium PBX, the Asterisk PBX and the VX and made a few test calls. Then we brought Broadcast Bionics onboard to set up the PhoneBOX part of the installation. They configured the system remotely and it’s been up and working flawlessly for about six months now.

Peak has a wireless Internet provider on the building roof. We added some off-site VoIP extensions and a couple of trunks using the wireless provider with great success. Peak effectively now has a backup provider for local service in case the PRI’s or their PBX goes down and also use the G.722 codec for remote broadcasts and from reporters in the field using iPhones.

Cox Broadcasting, Tampa, Florida

cox-florida

The Cox broadcasting cluster in Tampa/St. Petersburg, Florida, asked us to create a system that used every line delivery option available, all at the same time. We like a challenge and knew that this installation would provide us with valuable real world experience. It did.

Lines were delivered via SIP trunks from Cox’s preferred carrier PAETEC. Some PBX extensions from their older Nortel Option 11 PBX would also need to be available in studios. Some POTS lines would also need to get into the system. The engineering department led by Director of Engineering, Roz Clark, and Chief Engineer, Dylan Scott, was also intrigued by the possible use of mobile apps and the G.722 wideband codec, supported by the VX directly. This would require a firewalled connection to the Public Internet.

Since the facility has an existing Harris console/router infrastructure, AES and Analog I/O Nodes would break out the VX audio for console connection. GPIO would be made available for control of delays, to light warning lamps, and allow the Harris gear to control the VX line functions.

The first roadblock encountered was a useful learning experience for the Telos team. The provider, PAETEC, installed a dedicated T1 to carry the SIP trunks. They terminated the T1 with a cisco router that was set to be the default gateway for the VX’s WAN interface, normally used for providers, gateways and administration. The router is maintained and configured by PAETEC and the customer does not have administrative access to it.

At the time of this installation, Telos VX’s had a single, system-wide field for the global assignment of a “NAT external address”. The addition of multiple gateway devices and other routers (to the Internet) potentially required a different entry for each device. This meant that we could have PAETEC or our other gateway devices, not both. It was necessary for Telos to make changes in the VX software to accommodate this unforeseen situation. This feature was quickly added and allows far greater flexibility in multi-network, multi-gateway installations.

This was our first experience using PAETEC as the service provider, and it went very smoothly. We’ve had the best experiences with CLECs as opposed to the Incumbent carriers, as a general rule. SIP trunking and VoIP in general are still new to the old-line phone companies, and while many of them offer it, it’s not yet what they do well or understand fully. We expect the Incumbent phone companies to get better at this as time goes on and they gain more experience with SIP trunking.

The analog gateway for the PBX extensions and POTS lines was set up easily, leaving the Public Internet/G.722 piece to complete. There were several different ways to approach this. While it’s possible to have an app connect directly with the VX, the benefits of one of the features that SIP registration provides became clear: because wireless and WIFI networks present a constantly changing IP address and network environment to the app, the remote device or app couldn’t be called if the IP address was unknown. We decided to implement an Asterisk server to provide registration functionality and a simple and consistent dial plan. Each station would have a unique private phone number, for example “Hot 101.5” would be dialable by calling 41015. Each app user would have his own number as well. It would be easy to see at a glance if there was connectivity or not, and overall troubleshooting would be far easier. The presence of that Asterisk machine on the network also gives us VPN remote access, Syslog server, NTP, and audio recording features.

Nextmedia, San Jose, California

NextMedia in San Jose, California, is fortunate to have a CLEC central office in the basement of their building, and very solid and inexpensive wireless Internet as well. This means that line delivery does not need to involve the local phone company, AT&T, in any way. A few pairs of wires to the basement delivers whatever they need, which reduces their costs even further than just getting service from a CLEC.

Service is delivered to NextMedia via PRI’s and also from a wireless provider, WiLine networks. WiLine offers unlimited long distance, originally delivering their service via SIP through analog terminal adapters.

Mike Stockwell, Director of Engineering at the San Jose Cluster had specific goals in mind. He wanted to get rid of the ‘fat wire’ 1A2 key system and the tired and now fully depreciated phones from 1986. He wanted to improve on-air telephone audio quality in all of his studios with four-wire, 100% digital delivery of calls. He also wanted to be able to use both IP and ISDN codecs for his regular remote broadcasts.

Mike had been using the Internet and an Asterisk PBX for his remotes using G.722 and for a few off-site phones. He obtained the SIP login credentials from WiLine for his existing SIP Analog Terminal Adapters (ATA’s) and connected his Asterisk PBX directly to their network, bypassing the two wire ATA’s. Then he connected his Asterisk to his office PBX via a PRI and programmed the dial plans of each system to transparently pass calls to each other. At this point, he could now direct DID numbers from his CLEC PRI to either the office PBX or his Asterisk IP PBX. The goal here was to be able to use lines from WiLine or the CLEC, or G.722 capable phones or apps directly from the Internet for remotes.

Mike’s ISDN codecs are fed directly from his PBX as ISDN BRI’s with the European “S/T” type four-wire interface. This is because the system uses that interface for its office phones. ISDN traffic is routed over the CLEC’s PRI, which can handle clear channel 64 kbps circuit switched data, where the WiLine SIP service cannot. All of this is transparent to users who simply dial the number normally.

 

Summing Up

The installations described here illustrate that it’s possible to dramatically improve audio quality and operational flexibility, while reducing costs and the number of components in the studio on-air phone system.

The installations described considered these important goals when system implementation choices were made:

  • 1. How can we keep as many phone lines as possible in the four-wire domain?

  • 2. How can we make the system as reliable as possible while still consolidating delivery facilities?

  • 3. How can we best position ourselves for the future of telephony, which will be 100% IP?

  • 4. How can we identify the best service provider choices in our area and for our situation?

  • 5. How can we make these dramatic changes without adding complexity or adversely changing our users experience?

  • 6. What are our risks and what is our fall back plan? How much backup do we need?

Over the past two years, we also learned that you should consider more than “is this PBX SIP capable” when shopping. The overall “openness” of the system and manufacturer, the licensing and maintenance costs should be considered when choosing a PBX. In several locations, we’ve found that it would be relatively simple to connect the VX directly to the PBX, but when we found out that the arbitrary licensing costs to the PBX vendor would be several thousand dollars, other arrangements were made.

We found that SIP providers will often assume that you want the G.729 compressed codec, not understanding that audio quality is a primary concern that you’re willing to pay for. Never lose sight of why you are making changes in the first place!

Consider how your lines are delivered and how many you actually need. You will get fewer channels (17) on a T1 IP connection than a TDM T1 connection (23). If capacity is an important issue, your best choice is to have SIP trunks delivered in some other (non T1) fashion if possible, or simply use a SIP gateway, bringing in TDM on a PRI from the carrier, then converting to SIP. That scenario is all digital and four-wire.

We learned that the ILEC phone companies aren’t the best choices for SIP service at this time. They’re just not familiar with the technology yet and really assume that they’ll be connecting to you through a PBX.

We’ve also found that moving to VoIP is more of a network-engineering job than it is an audio or telephony job. You must consider what to expose to the Internet and how. Further, you must consider maintenance, remote vendor troubleshooting, and error logging.

With some good choices and a little pre-planning, you’ll have the best on-air phones that have ever been possible. Gone are the days of running jumper wire and replacing 10-volt lamps in old phones with broken buttons. Also gone are fat bundles of color-coded wires, the notion of “tip and ring”, battery voltage, and loading coils.

As we look forward, we’ll find that converting to VoIP and SIP trunks will become easier and, eventually, ubiquitous. We’ll also see wideband codecs becoming standard in mobile phones and tablet computers, so your VoIP broadcast talkshow system will be communicating with them, too, and with audio quality as you’ve never experienced over a “telephone”.



Return To