Adtran
Help
The Adtran community holiday season is starting next week! The holiday period will span from December 21, 2024 to January 6, 2025. During this time, responses to feedback form submissions may be delayed. If you are encountering product issues, you can reach out to Adtran support at any time.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dryaquaman
New Contributor
‎06-09-2015 01:06 PM

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
Reply
1 Solution

Accepted Solutions
Anonymous
Not applicable
‎06-11-2015 12:20 PM

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
Reply
20 Replies
Anonymous
Not applicable
‎06-11-2015 12:20 PM

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

0 Kudos
Reply
dryaquaman
New Contributor
‎06-11-2015 12:34 PM

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
Accept as Solution Reply
Anonymous
Not applicable
‎06-11-2015 01:50 PM

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
Accept as Solution Reply
dryaquaman
New Contributor
‎06-11-2015 02:07 PM

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
Accept as Solution Reply
Anonymous
Not applicable
‎06-11-2015 02:29 PM

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
Accept as Solution Reply
dryaquaman
New Contributor
‎06-12-2015 07:29 AM

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
Accept as Solution Reply
dryaquaman
New Contributor
‎06-19-2015 12:54 PM

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
Accept as Solution Reply
Anonymous
Not applicable
‎06-19-2015 02:15 PM

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
Accept as Solution Reply
dryaquaman
New Contributor
‎06-19-2015 03:03 PM

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
Accept as Solution Reply
dryaquaman
New Contributor
‎07-09-2015 07:16 AM

Re: Looking for solution to end finger pointing.

Jump to solution

I have the 830 set up now to monitor the T1 channels.

It working as I had hoped it would.

I've now been able to capture an event where all channels were seized.

I do need a bit of clarification on the logs.

The Carrier side is on port 0:1

The PBX side is on port 0:2

In the log below both the carrier and PBX side of the logs show the exact same time down to the millisecond.

I need to be sure that the source of the seizure came from the PBX side.

Can you confirm?

2015-07-08 10:17:03    Local0.Info    10.96.218.210    [ADTRAN]:DP Outgoing Signallin|0|2|Ds0:1 RX-Change rxABCD:00 txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    [ADTRAN]:DP Outgoing Signallin|0|1|Ds0:1 TX-Set    rxABCD:0f txABCD:00 t:151309995 ms

0 Kudos
Accept as Solution Reply
Anonymous
Not applicable
‎07-09-2015 08:23 AM

Re: Looking for solution to end finger pointing.

Jump to solution

This log is a little strange because the T1s are connected through the DEDICATED MAP, so whatever is received on one interface should be transmitted on the other. Other than that one oddity, these two lines show that the PBX side (slot 0 port 2) disconnected the call because the ATLAS received the change (RX-Change rxABCD: 00). So this means the received signal bits changed to "00". The next line shows the ATLAS transmit the "00" toward the Carrier (TX-Set    rxABCD:0f txABCD:00), and at this time the ATLAS is still receiving "0f" indicating the Carrier hasn't released the channel.

I wouldn't expect the Carrier to release at exactly the same time as the PBX, so the question is if there is a "RX-Change" on |0|1|Ds0:1 in the next few seconds. If there is no "RX-Change" then the Carrier is never releasing that channel.

0 Kudos
Accept as Solution Reply
dryaquaman
New Contributor
‎07-09-2015 09:46 AM

Re: Looking for solution to end finger pointing.

Jump to solution

I'm glad to know I'm not the only one a little baffled. 

I'm not sure if it makes a difference or not but these are Automatic Ring Down Channels.  PLAR.

There have been no slips or frame losses seen on this T1.

For clarity, here are logs I believe to be a normal inbound and normal outbound calls.

Normal Outbound Call

2015-07-09 08:15:51    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:22 RX-Change rxABCD:0f txABCD:00 t:230438371 ms

2015-07-09 08:15:51    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:22 TX-Set    rxABCD:0f txABCD:0f t:230438371 ms

2015-07-09 08:33:51    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:18 RX-Change rxABCD:00 txABCD:00 t:231519148 ms

2015-07-09 08:33:51    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:18 TX-Set    rxABCD:0f txABCD:00 t:231519148 ms

Normal Inbound Call

2015-07-09 10:28:34    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:22 RX-Change rxABCD:00 txABCD:00 t:238401404 ms

2015-07-09 10:28:34    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:22 TX-Set    rxABCD:0f txABCD:00 t:238401404 ms

2015-07-09 10:28:36    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:22 RX-Change rxABCD:00 txABCD:00 t:238403693 ms

2015-07-09 10:28:36    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:22 TX-Set    rxABCD:00 txABCD:00 t:238403693 ms

These are the logs for the event I'm tracking.  

Does it appear that the PBX seized all the channels the same time?

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:1 RX-Change rxABCD:00 txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:1 TX-Set    rxABCD:0f txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:2 RX-Change rxABCD:00 txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:2 TX-Set    rxABCD:0f txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:3 RX-Change rxABCD:00 txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:3 TX-Set    rxABCD:0f txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:4 RX-Change rxABCD:00 txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:4 TX-Set    rxABCD:0f txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:5 RX-Change rxABCD:00 txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:5 TX-Set    rxABCD:0f txABCD:00 t:151309995 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:6 RX-Change rxABCD:00 txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:6 TX-Set    rxABCD:0f txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:7 RX-Change rxABCD:00 txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:7 TX-Set    rxABCD:0f txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:8 RX-Change rxABCD:00 txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:8 TX-Set    rxABCD:0f txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:9 RX-Change rxABCD:00 txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:9 TX-Set    rxABCD:0f txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:10 RX-Change rxABCD:00 txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:10 TX-Set    rxABCD:0f txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:11 RX-Change rxABCD:00 txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:11 TX-Set    rxABCD:0f txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:12 RX-Change rxABCD:00 txABCD:00 t:151309996 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:12 TX-Set    rxABCD:0f txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:13 RX-Change rxABCD:00 txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:13 TX-Set    rxABCD:0f txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:14 RX-Change rxABCD:00 txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:14 TX-Set    rxABCD:0f txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:15 RX-Change rxABCD:00 txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:15 TX-Set    rxABCD:0f txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 RX-Change rxABCD:00 txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 TX-Set    rxABCD:0f txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:17 RX-Change rxABCD:00 txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:17 TX-Set    rxABCD:0f txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:18 RX-Change rxABCD:00 txABCD:00 t:151309998 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:18 TX-Set    rxABCD:0f txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:19 RX-Change rxABCD:00 txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:19 TX-Set    rxABCD:0f txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:20 RX-Change rxABCD:00 txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:20 TX-Set    rxABCD:0f txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:21 RX-Change rxABCD:00 txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:21 TX-Set    rxABCD:0f txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:22 RX-Change rxABCD:00 txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:22 TX-Set    rxABCD:0f txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:23 RX-Change rxABCD:00 txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:23 TX-Set    rxABCD:0f txABCD:00 t:151310000 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:24 RX-Change rxABCD:00 txABCD:00 t:151310001 ms

2015-07-08 10:17:03    Local0.Info    10.96.218.210    WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:24 TX-Set    rxABCD:0f txABCD:00 t:151310001 ms

0 Kudos
Accept as Solution Reply
Anonymous
Not applicable
‎07-09-2015 11:27 AM

Re: Looking for solution to end finger pointing.

Jump to solution

I'm still not sure if the ATLAS is displaying this correctly, because what is received on one interface should be transmitted on the other, and this doesn't seem to be.

That said, for a PLAR circuit, then Tx: 11 (or 0f) and Rx: 11 (0f) is idle, and when one side seizes the channel it transmits "00". So it does look like the PBX (connected to 0:2) seizes all 24 channels at once.

0 Kudos
Accept as Solution Reply
dryaquaman
New Contributor
‎07-14-2015 09:23 AM

Re: Looking for solution to end finger pointing.

Jump to solution

Sorry to bug you again on this but we did some additional testing and found that in both the in bound and out bound calls the syslogs always shows the PBX record 1st.

I'm looking to identify the source of the call but it always shows the PBX side.

Is there anything I can do to help identify this?

Note that on both in and out calls it always shows the Mitel seizing first.

PBX:     0|2

Carrier: 0|1

Inbound

7/14/2015 10:09:20 AM [999] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 RX-Change rxABCD:0f txABCD:00 t:669248116 ms

7/14/2015 10:09:20 AM [1000] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 TX-Set    rxABCD:00 txABCD:0f t:669248116 ms

7/14/2015 10:09:20 AM [1001] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 RX-Change rxABCD:0f txABCD:00 t:669248686 ms

7/14/2015 10:09:20 AM [1002] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 TX-Set    rxABCD:0f txABCD:0f t:669248686 ms

7/14/2015 10:09:27 AM [1003] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 RX-Change rxABCD:00 txABCD:00 t:669255414 ms

7/14/2015 10:09:27 AM [1004] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 TX-Set    rxABCD:0f txABCD:00 t:669255414 ms

7/14/2015 10:09:29 AM [1006] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 TX-Set    rxABCD:0f txABCD:0f t:669257743 ms

7/14/2015 10:09:29 AM [1005] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 RX-Change rxABCD:0f txABCD:00 t:669257743 ms

Outbound

7/14/2015 10:11:43 AM [1007] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 RX-Change rxABCD:00 txABCD:00 t:669391479 ms

7/14/2015 10:11:43 AM [1008] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 TX-Set    rxABCD:0f txABCD:00 t:669391479 ms

7/14/2015 10:11:44 AM [1009] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 RX-Change rxABCD:00 txABCD:00 t:669392519 ms

7/14/2015 10:11:44 AM [1010] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 TX-Set    rxABCD:00 txABCD:00 t:669392519 ms

7/14/2015 10:11:54 AM [1014] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 TX-Set    rxABCD:0f txABCD:0f t:669402735 ms

7/14/2015 10:11:54 AM [1011] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|2|Ds0:16 RX-Change rxABCD:0f txABCD:00 t:669402165 ms

7/14/2015 10:11:54 AM [1012] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 TX-Set    rxABCD:00 txABCD:0f t:669402165 ms

7/14/2015 10:11:54 AM [1013] From: (10.96.218.210) Fac:16 Sev:6 Msg >>> WCS[ADTRAN]:DP Outgoing Signallin|0|1|Ds0:16 RX-Change rxABCD:0f txABCD:00 t:669402735 ms

0 Kudos
Accept as Solution Reply
Anonymous
Not applicable
‎07-14-2015 09:36 AM

Re: Looking for solution to end finger pointing.

Jump to solution

If you know what type of RBS signaling is being used (Loop Start, Ground Start, E&M Immediate, E&M Wink, or Feature Group D) then you can can move it from the DEDICATED MAP to the DIAL PLAN. In the DIAL PLAN configure the T1 from the carrier as NETWORK TERM and the T1 to the PBX as the USER TERM. Under the IFCE CONFIG you set the number of DS0s, and you can set the DS0 SELECTION as ALIGNED in order to maintain the channel selection from one interface to the other. You can use "$" as the IN#ACCEPT and OUT#ACCEPT, but you do have to configure the RBS Signaling Method and if there are any DID Digits being received, etc.

0 Kudos
Accept as Solution Reply
dryaquaman
New Contributor
‎07-16-2015 04:00 PM

Re: Looking for solution to end finger pointing.

Jump to solution

The dial plan isn't working for me and I'm not sure where the issue is.

This is the terminal side config:

Terminal Side.JPG

This is the User Side config

user side.JPG

This is the status of the channels when they all should be idle.

status.JPG

It looks like all channels on the carrier side are seized.

When I seize the PBX side the channel status changes to a '.'.

Since these are plars we don't send any digits in any direction.

Am I missing something?

0 Kudos
Accept as Solution Reply
Anonymous
Not applicable
‎07-17-2015 10:27 AM

Re: Looking for solution to end finger pointing.

Jump to solution

I'm afraid the ATLAS does not support PLAR in the DIAL PLAN, but the signaling the ATLAS is receiving doesn't really match PLAR.

I suggest you look at the SIG STATUS for the module, which will show you the Tx and Rx RBS signaling bits. With PLAR, both sides should transmit "1 1" , which means when all the channels are idle, both interfaces should be both transmitting and receiving "1 1" (which the Syslog shows as 0f because it is looking at the ABCD bits and not just the A & B bits - the SIG STATUS only displays the A & B bits).

The fact that port 2 shows "O" makes sense since when configured for E&M signaling, the "1 1" is seen as an "offhook" condition, but the "." just indicates an idle channel, which indicates it is receiving "0 0" rather than "1 1".

So it's possible the SYSLOG from having the ports MAPPED is correct and I have no idea how this is even working. As I mentioned, in an idle state, both the carrier and the PBX should be transmitting "1 1" if they are doing PLAR. If that's the case, then you may be able to look at the SIG STATUS when it locks up and see what is being received on each port and from that decide if that is normal for it's initial "idle" state or not.

0 Kudos
Accept as Solution Reply
dryaquaman
New Contributor
‎07-20-2015 07:45 AM

Re: Looking for solution to end finger pointing.

Jump to solution

The reason I was switching to dial plan was because when using direct mapping the syslogs always showed the PBX circ seizing the circ 1st.

Is it possible at all to use the dial plan if neither side is sending digits?  or do I need to figure something else out?

Ralph

0 Kudos
Accept as Solution Reply
Anonymous
Not applicable
‎07-20-2015 08:17 AM

Re: Looking for solution to end finger pointing.

Jump to solution

If the RBS signaling is supported you CAN use the dial plan even if no digits are dialed. In the NETWORK TERM, you can assign a TRUNK NUMBER which will be the number used when an inbound call is detected. The USER TERM will have this TRUNK NUMBER as its IN#ACCEPT. Under the USER TERM you can configure DIAL ON OFFHOOK.

The problem is that the ATLAS does not support PLAR signaling on an RBS T1. It supports E&M Immediate, E&M Wink, Loop Start, Ground Start, and Feature Group D. Each of these have their own set of signaling bits to indicate idle, offhook, etc. PLAR also has its own set of signaling bits which are different than the others.

The signaling bits are the least significant bits in the 6th and 12th frame of each channel on the T1.

With E&M, if a channel is idle, it should be both transmitting "0 0" and receiving "0 0". To place a call, the device will transmit "1 1" to seize the channel, while still receiving "0 0" from the far end of the T1. When it is both transmitting and receiving a "1 1" then the call is connected.

With PLAR, if a channel is idle, it will be both transmitting "1 1" and receiving "1 1". To place a call, the device will transmit "0 0" while still receiving "1 1" from the far end of the T1. When it is both transmitting and receiving "0 0" the call is connected.

So, what I suggest is to look under the MODULES at the SIG STATUS and verify what each port is receiving. I don't see a reason for the DED MAP not to work, but the logs you sent in are not making sense. Look at the SIG STATUS and make sure what one T1 is receiving is what the other T1 is transmitting.

If you are truly using PLAR signaling then the ATLAS DIAL PLAN does not support this signaling type.

0 Kudos
Accept as Solution Reply