Analog Telephony (Part 3)

We’re back.

Alright, let’s wrap up with what happens when we’re in a call, incoming calls, hang ups,

and then a few troubleshooting techniques.

When we're in-call, we want to see two things.

We want to see a fairly stable voltage here and a stable current.

Sometimes when we don’t have great wiring or things are a little weird

and you're dropping calls or having other issues,

it really comes down to this line, the voltage current relationship.

Make sure to verify that there's not an intermittent short or some kind of other condition.

Often times when all the telephony wires come back, they come back to these punched down blocks,

so make sure to check the wiring in there when you're having problems

Toggle back to the control tab and let's look at hangup detection.

Loop drop is for real CO lines, if you will, that come from the telephone company.

Sometimes if all you have is the call progress, the problem is that the call progress is the reorder tone.

So you might hear that in the room before it auto hangs up.

And unfortunately there's not a lot you can do about this when that happens.

Here’s another hot tip for interfacing in-house PBX systems:

they don't always use standard call progress tones... unfortunately.

For example, the Siemens PBX might use German signaling rather than American signaling.

As a result, you may need to adjust the country in the Core properties

when you're using a private branch exchange.

Since we're internal, they don't need to follow the rules of the external country.

When it comes to incoming calls, it’s important to note line voltage is DC measurement.

As we discussed earlier, ring voltage is AC voltage, so it wont be reflected in this measurement.

It might be necessary to confirm incoming ring voltage with a voltmeter attached to the circuit.

When there is an incoming call, you simply see incoming call and caller ID in the progress string.

The ringing LED will strobe, and it strobes for the duration of the ring cadence.

Remember…if you don't enable a tone in the control tab,

then you won’t hear any indication that there’s an incoming call.

As we explained earlier, the interface does not play DTMF tones dialed by the user into the room.

Some users insist they want to hear them. QSC support can provide a user module that will accomplish this task,

but we’d like to avoid it whenever possible.

And if you're going to use it, make sure the tones are fed into the AEC reference of the microphones

to minimize the chances of ‘double-tap’.

When integrating Q-SYS call control to an external control system,

there are some potential problems you want to avoid.

Number one:

Many times a control systems programmer will only create a named control for the Dialer’s ‘dialstring’ field.

That works perfectly for the initial dial process,

but the keypad button controls MUST be used to dial any in-call digits so you need to create named controls

for all the keypad buttons as well as the other call control buttons to make use of all functionality.

Remember the keypad numbers and the other call controls are ‘trigger’ type controls.

If they’re treated as momentary or toggled controls in the control system,

you're going to have some pretty strange results, and I don't think it's going to work the way you envisioned.

So, don't do it!

Another common problem is the use of the ‘ringing’ or ‘off hook’ led signals

rather than using the dialer's control progress field as the only indicators of call status.

We really recommend you create named controls for the call progress fields and then parse that

out into the control system to have good data on the status of the telephone interface.

Earlier we mentioned the need for analog telephone adapters or ATAs.

For example, maybe you're using a hosted solution, that doesn't support Q-SYS softphone interface.

Very often they'll just send an ATA that's already set up and if you can't get proper signaling on the other side,

then it's very hard to know, if you have a VoIP problem or an analog telephony problem?

Based on which ATA you're using,

sometimes they can push the boundaries when it comes to electrical properties.

These are typically low power devices,

which makes it difficult to reproduce signals generated by the CO.

There are a few that we recommend in our documentation.

When troubleshooting, it’s often good to have a simple phone that you can connect to the analog side

to verify VoIP operation even before you get Q-SYS involved.

Also remember that it’s important to have the correct ATA…

The ATA needs the FXS port to interface properly with the Q-SYS POTS.

When troubleshooting these or other POTS related issues,

it’s useful to know the tolerance of the Q-SYS POTS interface.

For example, line voltage needs at least 18V DC on hook and 3 V DC off hook (with a nominal 6 VDC).

You got similar scenarios for Line current and ring voltage,

so I would take a good hard look at this slide and make note of these requirements.

Let’s say you’re having a problem with Q-SYS telephony

and you see what seems to be good levels and signaling in general.

For cases like this,

we’d recommend taking a few steps and gathering some information for the Q-SYS support team.

Number one:

Enable the POTS event logging, and then add recorders and record the POTS receive signal.

Then, make any successful or unsuccessful types of calls.

Then extract the Q-SYS log archive from the Core Manager and recorded audio files.

This data, and a good explanation of the problem,

can help your Q-SYS support team resolve the issue sas quickly as possible.

That’s it for Plain Old Telephone Systems from your Plain Old Training Guy. We'll see you next time.