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

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

Highlighted
Valued Contributor
Valued Contributor

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.

Highlighted
New Contributor

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

Highlighted
Valued Contributor
Valued Contributor

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.

Highlighted
New Contributor

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

Highlighted
Valued Contributor
Valued Contributor

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.

Highlighted
New Contributor

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?

Valued Contributor
Valued Contributor

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.

Highlighted
New Contributor

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

Highlighted
Valued Contributor
Valued Contributor

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.