3am LineScope
Case studies

Some commonly encountered scenarios Migrating dial-up POS from PSTN to VoIP networks Migrating a new POS terminal on an existing network Reverse-engineering applications on legacy POS terminals Dealing with sporadic failures & call success rate problems Issues when developing & integrating soft-modems

3am LineScope ( datasheet | pricing | case studies | stay informed | new r9/10 info )

Migrating dial-up POS from PSTN to VoIP networks

With the proliferation of Voice over IP (VoIP) services, it's just a matter of time for dial-up POS terminals to be migrated to these networks. Unfortunately, VoIP is designed for voice, not data modems, and actual results depend a lot on the provider's readiness to cooperate by configuring their network appropriately. In fact, getting V.22 and V.22bis to work over VoIP (or MoIP, for Modem over IP, as it's now called) can be a challenge.

Modem-Relay V.150.1

If you are lucky, you might encounter an IP infrastructure that supports Modem-Relay, where the gateway uses de-modulation and re-modulation techniques to transport the voice band modem traffic over the packet network. Here, V.22/V.22bis will work easily. One problem you might run into is getting FastConnect handshakes to work.

Pass-through

With the more common pass-through IP infrastructure, all VoIP impairments are going to have a major effect on call success rate. First of all, you need to ensure that an appropriate lossless codec is being used, namely G.711. Modern speech codecs with lossy compression and silence detection will not work.

VoIP connections typically will have a longer round trip delay than PSTN, but as long as this delay is constant, it will not impair the connection. However, an excessive delay may interfere with handshake completion, particularly if the NAC is configured to auto-detect different handshakes or async/sync modes.

With regards to packet loss and jitter, these are critical, and the QOS needs to be high enough to ensure an acceptable call success rate. If packet loss is an issue, some workarounds are enabling retains and increasing the carrier loss detect threshold.

LineScope is able to provide you with the insight you need into just what is going wrong with a connection, with its powerful diagnostic instrumentation and data analysis features.

Migrating a new POS terminal on an existing network, or changing a NAC

Problems encountered here can be of two categories. If a different modem or transaction gateway (NAC) is being used, handshake and connection issues are likely, as NACs often use proprietary handshakes to shorten overall transaction times and to provide auto-detect capabilities.

Specifically, NACs speed up transaction times with features such as FastConnect, which reduces or eliminates steps such as alerting, audible ring, billing delay, answer tone, and call termination. They also support multiple transaction protocols such as VISA I/II and Synchronous Data Link Control (SDLC). SDLC speeds up calls and reduces traffic to a processing host even further.

Legacy terminals can contain modem implementations based on controllerless datapumps, such as the 73K221 and 73K224 from TDK. This means that modem operation, and in particular, the rather critical handshake phase, is competely under the host CPU's control or lack thereof. With controllerless datapumps, firmware implementation quirks are rife and a fully ITU-T compliant implementation is unlikely. Sometimes you just need to look into a working legacy terminal to help you understand why a newer terminal with a standard modem is behaving differently when it dials a tweaked NAC.

For newly developed applications, application protocol issues are likely. Specifications can contain obscure errors, and a peek into a functioning system will help you understand the problem. And sometimes, hosts have their own quirks, for example in their ISO-8583 implementation. In both categories, LineScope can assist you to identify the root of the problem.

Reverse-engineering applications on legacy POS terminals

Sometimes, it just happens that old terminals need replacing, but details about the application are unavailable due to incomplete or lost specifications. Even the most mundane information, such as exchanges on an X.25 PAD, can stop you from working. LineScope provides unobtrusive and trusty data analysis capabilities to help you solve these problems.

Dealing with sporadic failures and call success rate problems

Sporadic call failures can be difficult to deal with and solve. With LineScope, you just need to hook up the LineCoupler and record a whole day's worth of exchanges, if necessary. The recordings can be analyzed in real-time, synchronized with audio, or else analyzed off-line at rapid speeds, and then exported as text files. Problematic calls can then be easily isolated and analyzed in detail.

Issues when developing and integrating soft-modems

Despite the attractiveness of low unit cost, development and integration of soft-modems into a system is not trivial. The code itself is complex to develop, and it normally makes sense to just license a certified version from a third party. And integrating the soft-modem code into your target is fraught with pitfalls due to hard real-time constraints.

The target hardware environment can also cause its own problems; examples include excessive clock jitter, power rail noise and poor analog-front-end (AFE) performance. LineScope comes to the rescue with powerful diagnostic instrumentation, such as live constellation displays and plotting of key control loop variables, which can be used to detect internal impairments.