I know, I know… a Polycom IP-9000 is not an ATA. It’s the best picture I had on hand of my own for the post. Deal with it! >:(
Here’s another knowledge drop for the Blog from my personal experience. The reason I’m making this post is because information on configuring a VoIP ATA made by Cisco / Linksys to work with a modem is rather difficult to find and piece together. I’m hoping this post will end up being a useful nugget of information for whoever happens to be here reading this.
The background on this
Some background on why I’m making this post. Over a decade ago, I was called upon by my now, former employer, to resolve an issue occurring at the office. The issue? POTS lines provided by Verizon Communications with a tendency to dial 911 (Emergency Services) on their own. The reason why the False 911 calls were occurring was due to the deplorable condition of the Copper Telephone network in my area. Many people aren’t using POTS anymore for Telephone service, and Verizon shifted their focus many years prior towards Fiber and Wireless, and this has resulted in a neglected Copper POTS network. This was in an area where Verizon never bothered to deploy Fiber to replace the copper. As a result, every single time the weather would change, especially during rain or snow storms, the copper wiring would short out in such a way that would cause the line to go off the hook, and for the switch to mistake the short circuit as a pulse dial in the sequence of “911”.
We wouldn’t even know about the 911 calls being made by the POTS lines until the first responders came crashing through the gate. Every single time this issue would occur, we’d end up with a broken parking lot entrance gate, and a rather embarrassing situation with either the Fire Department or the Police. The issue eventually escalated to result in fines being issued to the company every single time a false 911 was placed by the POTS lines. Now, sure. This sounds like a chronic issue. Why aren’t we getting the lines repairs? See, that’s the thing. Every time the problem would occur, we would contact Verizon to get the affected circuit repaired. A technician would come out, point out where the problem was (usually at the same spot), patch the problem, and then the fix would hold until the next rain storm or drastic weather change. The problem wouldn’t just occur on a single line, either. It would occur on many of the incoming POTS lines. Sometimes it was the fire panel. Sometimes it was the elevator’s emergency phone line (The telephone was pre-programmed and did not have a keypad). Sometimes it was a circuit that was never terminated inside of the building and existed only inside of the Verizon demarc for future use.
The only fix to the problem was to cancel the POTS lines. But, there are hard requirements on the POTS lines. The elevator needs to have an emergency phone in case someone becomes trapped inside. The Fire panels need a means to call out to the monitoring company for reporting purposes and for alarms, even if they had a cellular backup (and cellular wasn’t great in that area – the provider used by the panels relied on repeaters installed inside the facility). Another POTS line? Needed by the power company in order to meter for electricity to a massive, power hungry facility. If any of those lines don’t exist or function anymore, then that’s a problem. High estimated bills, and safety violations are guaranteed.
After coming up with a solution to the problem by configuring VoIP lines for this equipment, I had to spend a number of days with trial and error experimentation to tweak the settings to ensure each and every modem could communicate reliably with the provider. By reliably, I mean, no re-dials to try again, and no errors being reported by the provider on the data. A single call, all data transmitted reliably, in a single shot. This setup, once dialed in, has worked successfully for many years over a Cisco CUCM multi-geographical setup, as well as with RingCentral, just to name a few. It has also worked so well to the point where, despite being laid off from my former employer where this was put into place, I was called back to re-implement it again on a contract/consult basis long after being unemployed. Apparently, their vendors are so confused as to how their equipment has worked so reliably on VoIP Circuits, they have no idea how to configure it, and my for employer is the only customer they know of with such a setup. So I consider that to be a bit of an accomplishment.
Why VoIP is difficult with modems.
The reason why you’re looking at this blog post to begin with is because you’ve probably discovered that modems don’t work very well with VoIP. This is for a number of reasons:
- Internet VoIP doesn’t have quite the same level of quality of service as a TDM-based, circuit switched POTS circuit does. There is jitter, packet loss, and multi-path routing occurring between a VoIP ATA and the telephone provider. Much of this is the product of other Internet traffic riding over a best effort network.
- Analog modems expect a steady, paced, and uninterrupted connection through the telephone network to the Analog modem on the other end of the call. ATAs can attempt to emulate this through packet buffering which adds in a small delay, but this can also be problematic if the delay is too great, or the connection has too much variance.
- VoIP ATAs are physically located closer to the analog modem, with less attenuation compared to a POTS circuit to degrade line battery (voltage) through resistance. By not having hundreds to thousands of feet of copper to deal with, the modem is able to literally “scream” at the other modem. Some analog equipment cannot tolerate this, and the signal is effectively too strong.
- VoIP ATAs must process analog audio into a digital waveform and compress the audio with a codec. Not all codecs are made equally and not all ATAs are configured the same. Bandwidth-preserving G.729 cannot carry the same amount of audio information as the more bandwidth hungry G.711 codec. Analog modems were not designed with this concept in mind.
- VoIP ATAs often perform software processing on the audio to and from, allowing for clearer audio and noise reduction. Some of this is for user experience, and some of this is in an effort to save bandwidth by not encoding and transmitting audio which is not human speech. As a consequence, this software processing can also affect modems by deleting important highlights and details from the audio generated by an analog modem. There is no standard way to configure an ATA, as some of these settings boil down to personal or provider preference.
So in essence, POTS lines are generally built around Bellcore standards designed many decades ago, and are pretty universal in functionality regardless of your telephone company being Bell Canada, Verizon, AT&T, Telestra, or Frontier. When you had a POTS Line, some switch-side features like Call Waiting, Three-Way calling, and Call Holding might be implemented differently based on the Telephone provider and whether they used a Lucent 5ESS or a Nortel DMS-100, or fed you out of a Litespan 2000 or SLC-96. But what you got at the end of the day, was always a bare minimum product providing the equivalent of a 64kbps circuit switched connection. Even if the voltage on the circuit might be a little less out of a Litespan versus out of the CO’s 5ESS. The standard had built-in tolerances, and all telephone equipment was designed around the Bellcore standard.
One important aspect to note before I get into the next part of this post. The telephone service you get from a Cable company (Comcast, Spectrum, etc) delivered via a Cable modem is just Managed VoIP. The Cable modem itself is acting as a Cable ATA, is configured by your Cable company via TFTP, and the Phone service may have priority to the cable node’s bandwidth during times of congestion. But that’s about it. Generally speaking, the cable companies implement basic support for Faxing (via T.38 most likely) and build a circuit which delivers acceptable, even if not rich, audio quality. Also, many Fiber providers today including Verizon Fios are effectively selling VoIP over that Fiber unless you have explicitly asked for TDM-based phone service, so the same problems can occur with modems on those lines. But you’ll have a better chance with a Telephone company’s Fiber than a Cable provider at getting a modem to work. Can’t guarantee the same for a Mom & Pop Fiber provider selling Voice service however.
Prerequisites
For the sake of this post, here’s what you’ll need to get started.
- A Linksys SPA-2102, a Cisco ATA-191, Cisco ATA-192, or an equivalent piece of hardware that you can map my configuration settings to.
- A QUALITY Internet connection. As I talked about above, Internet Telephony doesn’t have the best pacing. I strongly recommend a Fiber Internet connection. If you have DOCSIS, that will do. Just try to ensure quality of service for your ATA no matter what kind of connection you have.
- An Analog modem. In my case, I engineered my settings to work with Honeywell Industrial equipment. One piece of equipment is an Electrical meter reading power usage for a substation. Another piece of equipment is a Honeywell Fire panel. Both devices operated at different baud rates over the line as configured by their vendors, but these settings worked successfully with both for many years, and still do to this day. Note that these settings have also worked successfully for me with Fax modems at the V.92 data rates where T.38 is not available.
- Administrator access to the ATA or to the fine-grained central configuration. I know, this should be common sense. You need to be able to change settings on the ATA which may not necessarily be controllable via your VoIP provider. I’ll explain more about this later in the post.
- The ATA should already be configured with a working extension or phone number. This is important because we want to make sure the ATA actually works first, especially since we will be applying “non-default” settings.
The configuration settings
Here’s the part you’re looking for. Again, these settings are based around the Linksys SPA-2102 / Cisco ATA-191 / Cisco ATA-192. Adopt to your configuration.
Note: I recommend reading the settings list first. If you are using a provider like RingCentral with automatic configuration deployments, or utilize FreePBX or CUCM with TFTP configuration of your ATA, you may be required to disable automatic provisioning in order to ensure these settings stick. Otherwise you will find yourself having to repeat work the next time the ATA reboots. I recommend first beginning with allowing your provider/PBX/Network to configure your ATA’s initial settings. Ensure your ATA Is registered with your provider and is able to receive/make calls. Once this is verified, you can disable provisioning.
Provisioning can usually be disabled by logging into your ATA’s Web Administration Interface as the Administrator user, clicking Advanced and then clicking the Provisioning tab. Set the “Provision Enable” drop-down box to “No” and click Save Settings at the bottom of the page. Note that your network configuration may override this setting as well via DHCP, so you may be required to make further tweaks to your network or setup!
The Provisioning tab also contains settings for Firmware Upgrades. You may keep the Firmware Upgrades enabled if your network or VoIP provider have specified values for this. It’s generally a good idea to keep firmware updates enabled!
Note #2: I am assuming that you are using the “Advanced” configuration tab and not the “Basic” configuration tab for your ATA, as this exposes all settings.
ATA Web Admin –> Advanced –> Line 1 (or 2).
| Setting | Value | Description (if necessary) |
| Network Settings –> SIP ToS / DiffServ Value | 0x68 | This is used for DSCP Packet marking. Don’t tweak this setting unless you know exactly what you are doing, and how your network is configured. Changing this value often has no effect if you are going out to the general Internet. This will make more of an effect where you operate the network end to end, and make use of DSCP for Traffic Policing and Shaping policies. If misconfigured, this value can just make things worse. |
| Network Settings –> RTP ToS/DiffServ Value | 0xb8 | This is used for DSCP Packet marking. Don’t tweak this setting unless you know exactly what you are doing, and how your network is configured. Changing this value often has no effect if you are going out to the general Internet. This will make more of an effect where you operate the network end to end, and make use of DSCP for Traffic Policing and Shaping policies. If mis-configured, this value can just make things worse. |
| Network Settings –> Network Jitter Level | Very High | This value controls how much buffering of the RTP Audio stream the ATA will do in order to compensate for jitter on the connection. This is in order to deliver a steady, consistent call by ensuring all RTP packets are re-assembled in the correct order. You may be tempted to adjust this setting lower because you are on Dedicated Fiber or, your call must traverse a LAN. In my experience, this is the most reliable value, even if your call is going to a Gateway 2ms away, or if you are hitting a gateway across the continent at 80ms. You may tweak this if you experience reliability problems, but most likely you will end up matching my value. |
| Network Settings –> Jitter Buffer Adjustment | Disabled | This setting must be disabled! What this setting does is adjust the size of the audio buffer based on active network conditions. This is done with some audio processing tricks which barely affect human speech audio quality, but which destroy modem communication. Modems expect a consistent buffer size, and cannot tolerate variance. |
| Network Settings –> SIP CoS Value | 3 | This is part of DSCP Packet marking for QoS purposes. Don’t tweak this setting unless you know exactly what you are doing, and how your network is configured. It is highly probable your ISP will ignore what is set here, but it is best practice not to change this from the default. |
| Network Settings –> RTP CoS Value | 6 | This is part of DSCP Packet marking for QoS purposes. Don’t tweak this setting unless you know exactly what you are doing, and how your network is configured. It is highly probable your ISP will ignore what is set here, but it is best practice not to change this from the default. |
| Audio Configuration –> Preferred Codec | G711u | G711u the “Gold Standard” codec for VoIP and Telecommunications. It provides a full, POTS-equivalent waveform over 64kbps of bandwidth. G711u is required for modems to operate. While it may be possible to use other codecs such as G722 for higher bandwidth, wideband audio, this may not be desirable as distortion can occur during the conversion from wideband to a more narrow band. |
| Audio Configuration –> Second Preferred Codec | Unspecified | Do not use any other codec besides G711u. |
| Audio Configuration –> Third Preferred Codec | Unspecified | Do not use any other codec besides G711u. |
| Audio Configuration –> Use Preferred Codec | Yes | We must use G711u. This setting prevents overrides by the remote SIP gateway by only announcing G711u support in this case. |
| Audio Configuration –> Silence Supp Enabled | No | This setting defaults to “Yes”. We need this to be disabled as this is an audio processing feature which extends “Silent” periods in a call. Analog modems rely on silence and the timing of said silence as part of their data transmission. Audio processing on this silence will corrupt the transmission. |
| Audio Configuration –> Silence Threshold | Medium | This setting has no effect if Silence Supp Enabled is set to No. However I recommend applying this anyways. |
| Audio Configuration –> G729a Enable | No | We must use G711u |
| Audio Configuration –> G723 Enable | No | We must use G711u |
| Audio Configuration –> G726-16 Enable | No | We must use G711u |
| Audio Configuration –> G726-24 Enable | No | We must use G711u |
| Audio Configuration –> G726-32 Enable | No | We must use G711u |
| Audio Configuration –> G726-40 Enable | No | We must use G711u |
| Audio Configuration –> DTMF Process INFO | Yes | Dial sequences can be processed via SIP INFO and sent to the Gateway. Recommend leaving this enabled. |
| Audio Configuration –> DTMF Process AVT | Yes | Dial sequences can be transmitted with AVT and sent to the Gateway. Recommend leaving this enabled. |
| Audio Configuration –> DTMF Tx Method | InBand | InBand DTMF is required by some industrial modems which rely on DTMF interaction with the dial-in gateway before transmitting data. Some may also utilize DTMF for the actual data tramission. Using InBand avoids timing and synchronization issues with these mixed mode configurations. |
| Audio Configuration –> DTMF Tx Strict Hold Off Time | 40 | This setting controls the delay between DTMF (Button-Tone) presses. 40 is the default. This value must not be set too short or the remote modem will not understand the DTMF transmission. |
| Audio Configuration –> Hook Flash Tx Method | None | I recommend disabling Hook Flash functionality. This is a POTS feature for “Flashing” from one call to another, but it is not necessary during a modem call. |
| Audio Configuration –> Release Unused Codec | Yes | This is a memory-saving measure, and also a means to prevent other codecs from being represented during a call when unused. We must use only our primary codec. |
| Audio Configuration –> Echo Canc Enable | No | This is Echo Cancellation, a feature which prevents the “Talkback” echo you sometimes hear on Telephones. This is normal behavior for a POTS Line and is typically worsened by longer circuits. Modems can rely on these echos during synchronization to determine circuit delay and quality. |
| Audio Configuration –> Echo Canc Adapt Enable | No | Has no effect unless Echo Canc Enable is set to “Yes.” This setting adapts the echo cancellation to the call for improved voice quality, and is once again an audio processing feature we do not want. |
| Audio Configuration –> Echo Supp Enable | No | This feature reduces the effect of the “Talkback” echo you sometimes hear on Telephones. It is normal for a POTS Line to have echo on it. This is an audio processing feature which produces inconsistent results, and we do not want it acting upon a modem call. |
| Audio Configuration –> FAX CED DETECT Enable | No | This is a detection feature for Fax machines, and allows the ATA to adapt the call to the specifics of a Fax and tweak the call. We want this line to be a “vanilla” circuit without assistance to ensure consistency. |
| Audio Configuration –> FAX CNG DETECT Enable | No | This is a detection feature for Fax machines, and allows the ATA to adapt the call to the specifics of a Fax and tweak the call. We want this line to be a “vanilla” circuit without assistance to ensure consistency. |
| Audio Configuration –> FAX Passthru Codec | G711u | Much like the above, we need to make sure we are using G711u. Although the ATA will have FAX Detection features disabled, we want to ensure the G711u codec will always be selected. |
| Audio Configuration –> FAX Codec Symmetric | Yes | This setting affects whether the same codec is used for transmission as is for reception. Although we are not using the FAX Detection features in the ATA, we want this to be Yes for consistency in using the G711u codec. |
| Audio Configuration –> DTMF Mode | Normal | This setting affects how DTMF tones are transmitted. We want this to not be manipulated by any means as some industrial applications using modems will rely on DTMF for their transmissions. |
| Audio Configuration –> FAX Process NSE | No | This feature allows the ATA to detect FAX signals and signal that the call must switch to G711u. This is not needed given the rest of our configuration, and we do not want it potentially interfering with our call. |
| Audio Configuration –> FAX Disable ECAN | No | This feature in the ATA allows for the disablement of Echo Cancellation and Suppression in the presence of FAX. As we have already disabled Echo Cancellation and Suppression previously, we will set this to No as it is unnecessary. We also do not want the ATA to be adjusting call settings during transmission. |
| Audio Configuration –> FAX Enable T.38 | No | For a Fax line, we might want this to be enabled if our provider supports T.38 for faxing. However, T.38 support on the ATA can also misinterpret other modem calls, and switch the call from G711u transmission to T.38, which will result in a dropped connection. Additionally, if your VoIP configuration is broken (Excessive firewalling?), the switch to T.38 can also fail and result in failure to transmit a fax. Keeping this disabled emulates a POTS circuit as closely as possible. |
| Audio Configuration –> FAX T38 V29 Only | No | This setting shouldn’t have any effect unless the ATA has moved the call over to T.38 instead of G711u. However, we are setting this to “No” as we want to emulate a POTS circuit as closely as possible. POTS Circuits do not directly manipulate a modem’s connection speed outside of variable line conditions which occur. |
ATA Web Admin –> Regional
Please note that this section is more or less optional, but may be necessary to adjust for your equipment to better reflect POTS Service in your area. Some may also need to be adjusted if your equipment is particularly sensitive to “hot” signal levels and attenuation is required.
| Setting | Value | Description (if necessary) |
| Ring and Call Waiting Ton Spec –> Ring Waveform | Sinusoidal | The default setting is “Trapezoid” This adjusts the AC Waveform of the incoming call ring, which is typically 82-88v AC Current. Older equipment may be sensitive to the default settings an ATA offers, since ATAs typically simulate ringing battery with a Trapezoid wave pattern. This is generally acceptable for digital phones, but analog ringers and older circuitry malfunction unless Sinusoidal is used. Sinusoidal most closely reflects what is sent out by a POTS provider. Note that REN values are generally going to be fixed on an ATA, and will be lower than Telco provided circuits, but this should not matter for ringing into a dial-up modem. |
| Ring and Call Waiting Ton Spec –> Ring Voltage | 85 | Generally only adjust this if your modem requires a different ringing voltage from the default. POTS Standard ringing AC voltage is typically up to 90v but can be lower in areas which are subtended out of remote terminals like the SLC-96, SLC-5, or Litespan 2000, or have more copper attenuation. |
| Miscellaneous –> FXS Port Impedance | 600 | Adjust this value if your modem specifies a minimum amount of impedance (resistance) that is required on the line in order to work properly. 600 is what I have used over structured wiring in a building, and even out into a power substation, with great success. |
| Miscellaneous –> FPS Port Output Gain | -4 | Tweak this value if you suspect your calls are too “loud” or too “quiet” for the modems. Please note this is in decibels, which is logarithmic in nature, so avoid DRASTIC value changes. For example, a quiet call should go from -4 to -3 or -2, not to 0. |
| Miscellaneous –> FPS Port Input Gain | -4 | Tweak this value if you suspect your calls are too “loud” or too “quiet” for the modems. Please note this is in decibels, which is logarithmic in nature, so avoid DRASTIC value changes. For example, a quiet call should go from -4 to -3 or -2, not to 0. |
| Miscellaneous –> DTMF Length | 0.1 | Adjust this only as necessary. Setting this value too short or too long can impact the reliability of modems utilizing a mix of DTMF during calls for communication. |
| Miscellaneous –> DTMF Playback Level | -16 | Tweak this value if DTMF is suspected to be too quiet or loud. Please note this is in decibels, which is logarithmic in nature, so avoid DRASTIC value changes. DTMF are normally quite loud, and can easily be distorted, causing errors in transmit. |
| Miscellaneous –> More Echo Suppression | No | Related to the Echo Suppression feature from the last chart. This is basically a “Bass Boost” equivalent feature to the Echo Suppression toggle. We want this to be off as we are not using Echo Suppression anyways. |
ATA Web Admin –> SIP
| Setting | Value | Description (If Necessary) |
| RTP Parameters –> RTP Packet Size | 0.020 | This adjusts the size of each RTP Packet. You generally want to avoid setting this to be too big, as this can result in larger chunks of audio being destroyed in the event of packet loss. Avoid setting this too small, which can make RTP Transmission less efficient, and place more load on network equipment such as firewalls. This value specified is what works for me. |
| RTP Parameters –> No UDP Checksum | No | UDP Checksumming is important for verifying packet integrity and can be useful for troubleshooting purposes. |
| SDP Payload Types –> RTP-Start-Loopback Codec | G711u | Corresponds with the fact that we will be using G711u for our calls. This is the codec we want to start with and use no matter what. |
| SDP Payload Types –> G711u Codec Name | PCMU | This is generally a pretty standard definition for G711u. Change only if needed by your phone system to ensure G711u is used on the backend. |
That’s it!
So that is pretty much the configuration I would run with to get a Linksys or Cisco ATA to closely emulate a POTS line. As mentioned above in the tables, some settings may require tweaking, such as Network Buffer Adjustments, DSCP Values, and FXS Port Gain/Resistance settings. At the end of the day, the process will be trial and error based on your network environment and your VoIP provider. But, hopefully this post will get you most of the way there if it doesn’t help perfectly. These settings have worked well for a very long time on my end.
