I think it was clear from my last post that the Linksys/Cisco PAP2T was my favourite VoIP ATA. Unfortunately, as it is a dinosaur, it is no longer available. As I was interested in adding a few more lines to my internal Asterisk PBX for my own lab test purposes, I decided to grab Cisco’s latest offering – the SPA112. Will it live up to the Sipura heritage of being highly flexible, configurable and performant?
The SPA112 comes in a Cisco branded box, which is a basic cardboard box with the logo printed on it.
Important details as to the contents is printed on the label on the side. This seems to be a later model, hence there is a minimal firmware requirement of 1.3.5 or later. It has the Australian regulatory mark on it, meaning it is certified for use in Australia.
Opening the box, the first thing you are greeted with is a quick start guide leaflet and a small leaflet of how to find the full product documentation.
Underneath it is a molded cardboard tray containing the rest of the product.
In true Linksys/Cisco tradition, a very similar power adapter with right-angle plug arrangement is provided. Unfortunately, it also inherits the terrible design for Australian users which blocks the left side of the socket where the power switch normally is, making it rather inconvenient.
Of course, you get the adapter itself, which has a similar form factor to the PAP2T but with a case that has some curves. A large label with the product details is pasted on the bottom.
Some sides feature a glossy finish, while the others have venting to keep the internals cool.
This model is the more basic offering, with two lines, Ethernet, power and reset button on the rear.
Nicely included is a CAT5e Ethernet cable with all pairs wired through.
As with the PAP2T, deconstruction of the unit is straightforward as the screws are simply hidden underneath the rubber feet.
The board now features a mostly upgraded design and is instead based around the DSPGroup DVFD8187 and DAP1902 solution. This features a 220Mhz ARM 926 CPU, and 120Mhz R.E.A.L. DSP Co-Processor, with manufacturer support for G.711, G.722, G.723.1, G.729A/B, iLBC and G.722.2 codecs. RAM, Flash and line interface chips can also be seen on this side, with debug connectors as well. Unpopulated footprints appear to be for the SPA122 version integrating a router within the same form factor.
The underside features a Realtek RTL8201E 100Mbit/s Ethernet physical layer interface.
Those who are familiar with the PAP2T will expect to be greeted with an interface that looks like this:
However, the interface of the SPA112 is different.
Once logged-in, the fear that they have changed everything quickly disappears, as the same menu options can be found under the different tabs, including the dial-plans, regionalization and SIP settings, etc.
As the firmware was out of date, and a few vulnerabilities had been patched, I upgraded immediately to the latest firmware.
This was hassle free, although the interface remained similar.
The positive points of the administration interface is that it is much more elegant than the older PAP2T monolithic-page style. The interface now features proper settings back-up and restore, and a few additional features have been added surrounding discovery (e.g. Bonjour, LLDP-MED, CDP), provisioning (Linksys Key) and networking (VLAN). The annoying need to login as user, then admin and the need to switched to advanced view has been removed, although a second user of cisco is added by default.
Most of the tweakable items from the PAP2T remain, although with the RTP packetization, RTP Tx Packet Size Follows Remote SDP needs to be set to no to force the setting you have selected. The T.38 implementation seems to have been improved, and new settings for fax tone detection mode, and ECM enable are provided. Some settings such as “Modem Line” really aren’t well explained.
Logging and log-viewing can be done on the SPA112 itself, rather than needing to be forwarded to a remote Syslog server only.
Unfortunately, in saying this, the interface has also gotten much more frustrating to use as it is broken into sections which need to be saved as you go along. Each save can cause a reboot of the SPA112, which takes a variable amount of time depending on the settings. Some settings cause the SPA112 to be out of action for 3 seconds, whereas others require a full 40-second reboot.
The other thing that has changed is codec support. The PAP2T was capable of G.711a/u, G.726-16/24/32/40, G.729a and G.723, but the SPA112 is only capable of G.711a/u, G.726-32 and G.729a. This is unlikely to be an issue for most, as they would probably be using G.711a/u for best quality, or G.729a for bandwidth saving, but where people may have wanted to trade off voice quality further to work over dial-up connections, G.723 was a life-saver (even though it could only be used on one-line at a time in the PAP2T). Also, even though other codecs are supported by the manufacturer (e.g. iLBC, G.722/.2), they are not enabled in the device.
On most test calls, the SPA112 performed quite similarly to the PAP2T in terms of modem connect rate (in testing, as modems are more stringent than subjective voice testing) and gain settings once configured as I had expected it to. On the surface, it seems like it does the job and the echo return loss can be configured to quite good levels especially with the adjustable line impedance settings.
However, there was one gripe that seemed apparent – the device is underpowered. In fact, the firmware update PDF file warns you that network events can have impacts on call quality.
As a result, it is advisable to make sure you run the device behind a good firewall, and have the network relatively quiet and limited in broadcast or non-directed traffic.
Another big tip is not to read the call statistics within the administration area – in fact, don’t even administer the device at all while it is on a call. I find that as soon as you start loading any configuration pages, the audio on both ports stutters badly and this is bad enough to cause connected modems to drop the link. This behaviour does not happen with the PAP2T, and when it does, it is only a short click rather than a stutter.
Also, it seems that it has a habit of emitting ARP and Broadcast packets with incorrect frame check-sums, which seems to suggest they are trying to save computation somewhere. Notice how other devices have no such problem – and all frames are captured using the same hardware.
This is not something you expect to be seeing on a commercial piece of networking hardware.
The SPA112 is the logical successor to the PAP2T and it carries over most of the features with some added refinement and additional features. On the whole, it can do what it says on the tin, but the new management interface does have its own frustrations. The core of the system itself has changed, and along with it, some of the codec support and performance under network loading. It seems this newer unit is sensitive to network traffic and administration while on calls, which is an undesirable trait, and it puts out frames with incorrect FCS which is inexcusable.
Aside: Site Issues
It seems that GoDaddy’s storage and database servers are being slow. Luckily CloudFlare seems to be doing a good job caching visits, but writing/uploading/editing is becoming more of a chore than usual. As a result, some of the images I have uploaded are of a lower quality than previously offered. My perspective has been to offer the best quality available at the given time, so it is a little disappointing, but I have no real options at this stage. I suppose that’s all in good time, as I have a PhD thesis due to submit at the end of March, and I really shouldn’t be spending too much time here …