The TSU 600 can be used to DAX POTS lines to a T1. You would need FXO modules rather than FXS, though.
The FXO module receives loop current, ring voltage, etc.; and the FXS module provides loop current, ring voltage, etc.
The FXO ports can be mapped to the Network T1 of the TSU 600, so if that is connecting to the PBX, you will probably need a T1 crossover cable (https://supportforums.adtran.com/docs/DOC-4103) between the TSU and the PBX (since the Network port is not a DSX-1 port).
Hope this helps,
Thanks for the reply. I took a TSU 600 home tonight for 'homework' and to test out programming; again, currently I only have FXS ports (but we have FXO modules at the office)...so that said, I was looking at the DSO Map A, and saw the usual entries- DSO 1 mapped to 1.1 (current) FXS module; if this were the FXO module (and/or just the FXS module itself), is there 'directionality' implied, i.e., if DSO 1 is mapped to (let's call it) 1.1 FXO module, so a call received on DSO 1 would ring to FXO 1.1...is the opposite then true, that a call received on 'FXO' module 1.1 would ring on DSO 1 (in my scenario, 'toward' the VoIP PBX)?
Thanks for helping me 'think out loud' on this one!
I've now been through all the settings on our TSU 600's FXO cards (LS, LSMW, GS and DPT) and none of them cause an associated channel on the NI to pass the ring along. Is there a certain setting that should be used on the FXO cards in this scenario?
The FXO module should be configured for either Loop Start or Ground Start. The PBX will need to be configured for the same signaling type. My understanding is that the phone lines are standard POTS lines that you can plug a telephone into and are then able to draw dial tone, dial out, or have the phone ring on an inbound call. If this is the case, then when the FXO receives the ring voltage, it will then translate that into the appropriate signaling bits on the T1 channel. The PBX should then interpret that change in the signaling bits as an inbound "ringing" state.
In the TSU you can go under STATUS, and then PORT STATUS, select the desired FXO port and you can then view the "2W STATUS" (two wire status), which will indicate if the line is busy (off hook), ringing, or if there is a message-waiting (MW) indication on the line. These are indicated by an asterisk (*) over an active condition.
You can also get some very good information under the PORT STATUS by going into "VIEW SIG BITS" in order to see the signaling bits being transmitted by the TSU and received by the TSU. These are all with respect to the T1 line, so the RXA and RXB are the signaling bits received by the TSU sent from the PBX. The TXA and TXB are the signaling bits transmitted from the TSU to the PBX.
With LOOP START signaling, an idle state should have the RXA RXB TXA TXB equal 01 01. When the FXO port receives ring voltage from an inbound call on the POTS line, then it should change to 01 00 (the TXA and TXB both go to 0 to indicate the FXO port has received ring voltage and to signal the PBX of the inbound call). If the PBX goes off hook, then the received bits should change so the display should be 11 01.
Again, an FXO port receives loop current and ring voltage from the POTS line plugged into it. An FXS port provides loop current and ring voltage to the line plugged into it. If you can plug a standard telephone onto these lines and have an inbound call ring the phone, and are able to go off hook, hear dial tone and dial out, then you need an FXO module in the TSU to MUX those lines to a T1 circuit. If a standard phone works, then it is also doing LOOP START signaling.
If the TSU is not receiving 01 as the RXA and RXB then the PBX is not doing loop start signaling and you will need to find out what signaling it is doing.
Thank you! Some excellent information here.
I think the difficulty is that the T1 of the TSU has Loop Start as its
protocol (either default protocol, or due to the fact that our FXO
modules are configured as Loop Start, and therefore the T1 just
transports the same signalling??) and the PBX (Digium Switchvox) does
NOT have Loop Start as a choice for T1; it has E&M, E&M WinkStart,
Feature Group D (3 flavors of...) but not Loop Start signalling.
We have instead attempted to use an Atlas 550, with FXO ports, trying
to MUX up to its Network T1 card, or User T1 card, but as of yet had the
same results- the inbound calls to the FXO port on the Atlas show
'Ringing' but the T1 channels do not (configured as E&M w/ or w/o
WinkStart). The closest we got was configuring the T1 of the Atlas as
Loop Start (at least we saw the channel Ringing with the inbound call)
but the Switchvox never saw the call (presumably again, because it's not
configurable for Loop Start signalling on T1).
So we switched over to allow the Atlas to do protocol conversion, and
the inbound is still FXO and the Network cards are now configured as
PRI...as well as the Switchvox's digital card configured as PRI. We
tried connecting the Network side PRI card in the Atlas to the
Switchvox; and tried connecting the User side PRI card in the Atlas to
the Switchvox. In all cases, however, the Switchvox PRI circuit never
sees the call.
I spent all day on it yesterday in frustration, so went home; I'll
work with it a bit more today.
Can you mostly speak to the question of whether the TSU T1 'only' uses
Loop Start protocol, or whether it simply 'transports' whatever protocol
is MUX'd up to it?
Thanks for your help.
Message was edited by: Patrick to remove personal information
The FXO modules support either Loop Start or Ground Start, and the RBS signaling will match whichever they are configured for. The default for the FXO module is Loop Start. The FXO module cannot do E&M signaling on the T1. (On a side-note, the FXS module can be configured as "Tandem E&M" in order to do E&M signaling on the T1 and either Loop Start or Ground Start off the FXS interface.)
The ATLAS has the same restrictions with its FXO modules when configuring in the DEDICATED MAP, but you can use the DIAL PLAN to get around this. The FXO ports will be configured as NET TERM entries, and you should configure each port as a separate NET TERM entry. Under the INTERFACE CONFIGURATION assign a TRUNK NUMBER being the extension or phone number you want this line to be (because on a POTS line no digits are transferred, so you have to tell the ATLAS what the phone number is when that line rings).
Under the USER TERM, configure the T1 with RBS Signaling. You will have a separate entry for each channel of the T1, and each entry will have the IN#ACCEPT matching the TRUNK NUMBER you assigned in the FXO configuration. In the IFCE CONFIG you will specify the DS0 and the SIGNALING (Either E&M Immediate, or Wink). You can even enable DIRECT INWARD DIALING, if you want DTMF digits transmitted to the PBX.
Great thanks....I thought I knew a lot about both products, but this is
a level deeper than I've ever had to go!
I appreciate your help.
Message was edited by: Patrick to remove personal information
Update- This setting seems to work:
Using FXO modules, FXO_LS, each mapped individually to DS0 1, 2, 3, etc for FXO 1.1, 1.2, 1.3, 1.4, 2.1, etc
Digium Switchvox AA305 (SMB ver 5.5.7)
Using Single Span T1/PRI card, channel group configured as FXO with Kewlstart Signalling
[This seems to be the only supported setting that emulates 'Loop Start' on the T1, according to the Switchvox Admin Guide]
Default inbound extension set to 800 (Main IVR) to answer with Auto Attendant options
The only caveat is that we have no 'real' analog lines in the building, so we're testing behind an Atlas 800 with FXS ports, serving as our 'Telco' and therefore we have no Disconnect Supervision, but inbound and outbound calls can complete successfully.
Thanks for your help.
I'm glad to hear you found a way to get it to work!
As far as the disconnect supervision - In the ATLAS DIAL PLAN you can go into the IFCE CONFIG for the FXS ports and change the "Forward Disconnect" from "Disabled" to either 600ms, 1000ms, or 2000ms. When that is set and the "other end" hang up the call, the FXS port will cut loop current for the specified time.
Well, no, I mis-spoke...out of our Atlas 800 we have a T1 going to a TSU 600, serving our FXS ports for faxes and modems (which I'm borrowing for this test), along with 6 other PRI's we use for lab testing various phone systems!; I don't have the FXS boards directly in the Atlas 800, but I've seen those Forward Disconnect settings in other Atlas 550's we use for customers, to break out their Faxes, Credit Card Machines, etc. so I'm familiar with that setting.