cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
New Contributor

Looking for solution to end finger pointing.

Jump to solution

I have an issue that I need to try and resolve.

It's not an Adtran problem but I'm hoping that someone can suggest a solution that will help.

I have a T1 with 24 private line voice channels that feeds into a Mitel system.  From there, the individual private channels are routed individually by the carrier to multiple other remote connections.

The problem is that these channels are seizing into our PBX at the same time and no one is there.

There are no errors on the T1s and the carrier is pointing at our equipment.

Even though the customer has multiple T1s, programmed exactly the same way, extended out to the same carrier only one T1 will exhibit  the problem.  If we move that T1 to a T1 port that does not have the problem, the issue will follow the T1.

This happens with several of our customers.

I'm trying to end the finger pointing and am willing to spend the money to find a solution.

What I'd like to see is if we can add some equipment between us and the carrier that will log seizures of the channels and the direction it was seized from.   If it's us we take the evidence to the manufacture.  If the seize points to the far end we demonstrate the evidence to the carrier.

I have a TSU 120 that I would hope would do it but I'd need software to log the channel access.

Perhaps there is something better.  

Does anyone have a suggestion?

Dry Aquaman

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Valued Contributor
Valued Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

Hello, and thank you for posting your question to the ADTRAN Support Forums.

I'm afraid the TSU 120 doesn't have any way to report line seizures.

About the only thing I can think of that you can use is an ATLAS (either an ATLAS 550 with 2 T1 ports, an ATLAS 830 which has 2 built-in T1 ports, or an ATLAS 890 with a T1 module). You'll need the ATLAS to be accessible from the LAN, and have a Syslog Server running on the LAN as well.


You can configure the ATLAS so monitor the signaling bits on the T1s (set DP OUTGOING SIGNALING to INFO) and the send that information to the Syslog Server. If you configure the T1s in the DIAL PLAN you may also want to set SWITCHBOARD to INFO, but if it is in the DEDICATED MAP then the DP OUTGOING will be the only information you can gather.

I believe configuring in the DIAL PLAN will be more beneficial because you can then verify if digits are being sent for each "line seizure" or not. With the ATLAS, you can also look under the MODULES menu at the DS0 STATUS and SIG STATUS to see the state of each channel on the T1, but this information isn't exported.

The DP OUTGOING messages will give the changes in signaling on each channel of the T1.

Hope this makes sense,
Patrick

View solution in original post

0 Kudos
20 Replies
Highlighted
Valued Contributor
Valued Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

Hello, and thank you for posting your question to the ADTRAN Support Forums.

I'm afraid the TSU 120 doesn't have any way to report line seizures.

About the only thing I can think of that you can use is an ATLAS (either an ATLAS 550 with 2 T1 ports, an ATLAS 830 which has 2 built-in T1 ports, or an ATLAS 890 with a T1 module). You'll need the ATLAS to be accessible from the LAN, and have a Syslog Server running on the LAN as well.


You can configure the ATLAS so monitor the signaling bits on the T1s (set DP OUTGOING SIGNALING to INFO) and the send that information to the Syslog Server. If you configure the T1s in the DIAL PLAN you may also want to set SWITCHBOARD to INFO, but if it is in the DEDICATED MAP then the DP OUTGOING will be the only information you can gather.

I believe configuring in the DIAL PLAN will be more beneficial because you can then verify if digits are being sent for each "line seizure" or not. With the ATLAS, you can also look under the MODULES menu at the DS0 STATUS and SIG STATUS to see the state of each channel on the T1, but this information isn't exported.

The DP OUTGOING messages will give the changes in signaling on each channel of the T1.

Hope this makes sense,
Patrick

View solution in original post

0 Kudos
Highlighted
New Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

That was exactly the answer I was looking for.

I won't need a dial plan since these are PLAR (ARD) circs they do not send digits.

I will recommend that we purchase one but I need to be sure that via the syslogs we will be able to show what channels were seized and from which end of the circ.

Do you have a recommendation for a syslog server that we can put on a laptop?

Dry Aquaman

0 Kudos
Highlighted
Valued Contributor
Valued Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

ADTRAN doesn't have a recommended Syslog Server. I personally use both Kiwi Syslog Server as well as TFTP Daemon (which has a syslog server capability), because they are both free.

The DP OUTGOING SIGNALING is one of the few logs that is captured from the DEDICATED MAP. The signaling changes are presented as hexadecimal representation of the binary values, so 0f is a value of "1111" and 05 is "0101"

In my ATLAS, when I go onhook and offhook it sends the following to my Syslog Server:

Thu Jun 11 13:42:23 2015: <134>ATLAS 890[ADTRAN]:DP Outgoing Signallin|Sl 9|1|Ds0:1 TX-Set    rxABCD:00 txABCD:0f t:-1792972407 ms

Thu Jun 11 13:42:28 2015: <134>ATLAS 890[ADTRAN]:DP Outgoing Signallin|Sl 9|1|Ds0:1 TX-Set    rxABCD:00 txABCD:00 t:-1792968098 ms

So you can see both events are Slot 9, Port 1, on DS0:1 (Signallin|Sl 9|1|Ds0:1) and the transmitted signal changed to "0f" and then back to "00" when I went offhook and back onhook (txABCD:0f followed by txABCD:00). At the end is a simple timestamp for all the events so you can measure how many milliseconds pass between each event.

0 Kudos
Highlighted
New Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

It looks like I can work with that.

If I can interpret your example correctly

Thu Jun 11 13:42:23 2015: <134>ATLAS 890[ADTRAN]:DP Outgoing Signallin|Sl 9|1|Ds0:1 TX-Set    rxABCD:00 txABCD:0f t:-1792972407 ms

Thu Jun 11 13:42:28 2015: <134>ATLAS 890[ADTRAN]:DP Outgoing Signallin|Sl 9|1|Ds0:1 TX-Set    rxABCD:00 txABCD:00 t:-1792968098 ms

I see the off hook and the TX side signaled the seize:  (H0F or 1111)

When you went back on hook the TX side went all zeros (H00 or 0000)

I'm not sure which side of the TX/RX side of the circ this call is on but can I assume that if you went off hook the other direction the RX side would go H0F?

Dry Aquaman

0 Kudos
Highlighted
Valued Contributor
Valued Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

The Tx and Rx is with respect to the ATLAS. So the signal being transmitted out Slot 9 Port 1 was changing. I actually had an FXS module mapped to the T1 port, so when I went offhook on the phone, the Tx signal out the T1 changed to indicate the channel was being seized (offhook). If the received signal went to 0f (rxABCD:0f) then that would indicate the received signal on that interface changed.

0 Kudos
Highlighted
New Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

Thanks for you help Patrick.

We've ordered a referbed 830 and having it sent to my office so I can prep it and send on to NY.

Hopefully this will be the tool we can use to get the carrier off center to resolve this.

Hopefully I won't need much in the way of config help.

0 Kudos
Highlighted
New Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

I'm not sure what I've done wrong here. Perhaps you can help.

In my lab I set up my PBX with a T1 looped back to itself to simulate the carrier.

I have two phones, each with 5 channels terminated from different ends of the T1.

I can go off hook on either phone and it rings down to the other phone.

Now I've added the Atlas 830 in the center of the loopback T1.

The PBX shows all green with idle E&M channels on the DS0s.

I created a map on the 830 that maps Sys Ctl 1) T1/PRI to Sys Ctl 2) T1/PRI

maps.JPG

map2.JPG

map3.JPG

Now when I press the channel button on either phone, the phone on the other end will ring and then drop.  The calling phone will then go to a busy condition indicating the trunk is not Seizable.

Secondly,

I've set up the Kiwi Syslog server to capture channel detail.   If I unplug the T1 I get logs indicating alarms at the T1 level.  I've set Call Control Messages, Call Control IEs and DP Outgoing Signalling to "Info" but I don't get any logs - even though I can ring through to the far end of the T1, not not connect.

Dry Aquaman

0 Kudos
Highlighted
Valued Contributor
Valued Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

In your Dedicated Map, you need to set SIG to "RBS" since this connection is doing RBS signaling (this makes sure signaling bits are maintained from one interface to the other). This is needed because the signaling bits are the least significant bits in the 6th and 12th frame of the T1 signal, but each T1 has independent framing so data coming in on Frame 1 for one T1 may be going out on a different Frame Count on the other T1 interface. Setting SIG to "RBS" ensures the least significant bit in the 6th and 12th Frame match on both T1 interfaces.

The DP Outgoing Signaling should log any changes it receives in the signaling bits, but RBS has to be enabled for it to log.

0 Kudos
Highlighted
New Contributor

Re: Looking for solution to end finger pointing.

Jump to solution

That was it.   Thank you.

I'm now able to track the individual channel access via the syslog server.

Thank you

Dry Aquaman

0 Kudos