Outbound Calls (RANDOM) person on the other END can hear 1

[lhiraman]

I am not sure where to start. This problem has been happening since last week, Siemens support said that the need to send out a tech to pull and pop back in the PRI card, tech showed up did that last Friday night, same issues starting Monday, the tech opened a ticket with our PRI provider, tech from telephone company said they can't find any issues..siemens tech saying it is PRI provider, IT IS A BIG CIRCLE!

Can anyone help? Or let me know how to see if any trunks are acting up.

 

[birdseye51]

Ihiraman,

Could you be more specific regarding the problem?

DIS-REFTA;

STA-HISTA:SEARCHB,2012-03-06/09:00,2012-03-06/13:00;

Substitute the date and times in the line above to check alarm history.

The example above will search back from 13:00 hours to 09:00 hours on the 6th March.

 

[lhiraman]

the STA-HISTA command returned nothing.

but the DIS-REFTA returned:

DIS-REFTA;
H500: AMO REFTA STARTED
+-------------------------------------------------------------------------+
| R E F E R E N C E C L O C K C I R C U I T S |
+--------------+---------+----------+---+------+------+------+-----+------+
| PEN | MODULE | DEVICE |PRI|ERROR |BLOCK |SUPP. |READY|SRCGRP|
| | | | | | | |BUT | |
| | | | | | | |ASYN.| |
+--------------+---------+----------+---+------+------+------+-----+------+
| 1- 1- 14- 0 | DIU2-M | S1CONN | 0| 0| N | | N | 1|
| 1- 2- 2- 1 | DIU2-M | S1CONN | 0| 0| N | | N | 1|
| 1- 2- 14- 0 | DIU2-M | S1CONN | 0| 0| N | | N | 1|
| 1- 2- 14- 1 | DIU2-M | S1CONN | 0| 0| N | | N | 1|
| 1- 1- 1- 1 | DIU2-M | S1COD | 90| 15865| N | | Y | 1|
| 1- 1- 1- 0 | DIU2-M | S1COD | 90| 9215| N | | Y | 1|
| 1- 2- 2- 0 | DIU2-M | S1COD | 90| 0| N | X| Y | 1|
+--------------+---------+----------+---+------+------+------+-----+------+


I believe 1-1-1-1 and 1-1-1-0 are two of our PRIs. Dont know what the 15865 and 9215 error means

 

[birdseye51]

The two PRIs that have errors against them could be the result of the Siemens tech unplugging and replugging the card as both of the circuits are on the same card.

If these circuits are stable then the errors will eventually decrease to 0, or alternatively you can

CHA-REFTA:CIRCUIT,1-1-1-0,,,,0; to reset the errors to 0 and do the same for 1-1-1-1.

Why have you got the same priority set to 90 on 1-2-2-0, 1-1-1-0 and 1-1-1-1. The PRI's need to clock from the network provider and with this set up the system does not not know which circuit to clock from for synchronisation.

This should be set up as e.g. 1-2-1-0 priority 90, 1-1-1-0 priority 85, and 1-1-1-1 priority 80.

CHA-REFTA:CIRCUIT,1-1-1-0,85;
CHA-REFTA:CIRCUIT,1-1-1-1,80;

To change the priority the circuit will first have to be de-activated using AMO-DSSU.

I would recommend correcting this first and then we'll take it from there.

 

[lhiraman]

Wow,

Thanks! The priority was set by Siemens during our inital install. I will bring the card off-line tonight and change the priortiy.

 

[lhiraman]

OK, I changed the priority and the Siemens tech also came in and changed out the PRI trunk card. This morning we are still having the issue. I did notice that on the A1 HW fan error. Could this be causing the problem?

 

[birdseye51]

What actually is the fault you are experiencing?

Is it one way transmission whereby the called party can't hear the caller?

Is the problem intermittent?

It won't be the fan alarm causing the issue.

From the previous refta it would appear that you have 3 PRI links.

Are these all in the same trunk group. DIS-BUEND;

If so is the search Ascending, Descending or Circular? We need to ascertain which link is causing the issue. As you said the Siemens tech has changed the PRI card. Once you establish which link is causing the issue which can be done by de-activating one link at a time you will then have to get the network provider involved.

 

[Iamnothere]

No, the fan would not cause one-way voice. But a fan failure can cause an entire system failure! The fans are located on either side of the cPCI common control shelf. It is easily accessible - just unscrew the cover plate on the left & right. Just do not touch any of the boards inside the shelf!!! You should be able to see, hear, and/or feel air flow. If not, the fan assembly probably needs to be replaced, or - more serious - the MCM needs to be replaced - which requires that the system be powered off.

If the Siemens tech has replaced the PRI board - and the problem continues to handle - the TELCO needs to check their end of the circuit. It is either the TELCO, the cabling, or the HiPath 4000 - period. Sounds like you have minimized the HiPath 4000's involvement.

Good luck.

 

[lhiraman]

The teleco people came and said that they tested all 3 of the PRIs. The Siemens tech said that he will have to come out and stay an entire day monitoring to see what is the problem.

As for the DIS-BUEND; here are the results: Seems like the PRIs are 1 trunk.

<dis-buend;
DIS-BUEND;
H500: AMO BUEND STARTED
TRUNK GROUPS (FORMAT=S)
NO. NAME CHARCON
1 (NEUTRAL)
2 GROUND START (NEUTRAL)
90 XPRESSIONS (NEUTRAL)
100 XXXXXXXXXX (NEUTRAL)
101 XXXXXXXXXX (NEUTRAL)
120 TMANI LOOP START (NEUTRAL)
121 TMANI GROUND STAR (NEUTRAL)

AMO-BUEND-111 TRUNK GROUP

 

[birdseye51]

Could you DIS-BUEND:1;

 

[lhiraman]

<DIS-BUEND:1;
DIS-BUEND:1;


+-------------------------------FORMAT=L-----------------------------------+|TGRPNUMBER:1TGRPNAME:MAXIMUMNO.:69||CHARCON:NEUTRAL||SUBGROUPNO.:1DEVICETYPE:S1CODTRACENO:0||SEARCHMODEESCENDINGACDTHRESHOLD:*||NUMBEROFASSOCIATEDROUTES:8PRIORITY:1||TDDRFLAG:OFFTDDRTHRESHOLD:SOURCEGROUPIDX:1||GDTRRULE:0ACDPMGRP:0||THEFOLLOWINGTRUNKS(LTG-LTU-SLOT-CCT)HAVEBEENALLOCATED:|+------------------------------------------------------------------------------+|1-1-1-01|1-1-1-02|1-1-1-03||1-1-1-04|1-1-1-05|1-1-1-06||1-1-1-07|1-1-1-08|1-1-1-09||1-1-1-010|1-1-1-011|1-1-1-012||1-1-1-013|1-1-1-014|1-1-1-015||1-1-1-016|1-1-1-017|1-1-1-018||1-1-1-019|1-1-1-020|1-1-1-021||1-1-1-022|1-1-1-023|1-1-1-11||1-1-1-12|1-1-1-13|1-1-1-14||1-1-1-15|1-1-1-16|1-1-1-17||1-1-1-18|1-1-1-19|1-1-1-110||1-1-1-111|1-1-1-112|1-1-1-113||1-1-1-114|1-1-1-115|1-1-1-116||1-1-1-117|1-1-1-118|1-1-1-119||1-1-1-120|1-1-1-121|1-1-1-122||1-1-1-123|1-2-2-01|1-2-2-02||1-2-2-03|1-2-2-04|1-2-2-05||1-2-2-06|1-2-2-07|1-2-2-08||1-2-2-09|1-2-2-010|1-2-2-011||1-2-2-012|1-2-2-013|1-2-2-014||1-2-2-015|1-2-2-016|1-2-2-017||1-2-2-018|1-2-2-019|1-2-2-020||1-2-2-021|1-2-2-022|1-2-2-023|+------------------------------------------------------------------------------+AMO-BUEND-111TRUNKGROUPDISPLAYCOMPLETED;

 

[birdseye51]

Looking at the trunk group configuration all outgoing calls will try and use the 23rd channel on circuit 1-1-1 (1-2-2-23). If that channel is busy then channel 22 of the same link will be used. All 23 channels of that link would have to be busy simultaneously for for an outgoing call to step on to the next link 1-1-1.

If you disable the circuit 1-2-2-0 using AMO-DSSU you will force all the outgoing traffic over the next circuit 1-1-1-1. If this clears your problem then you know that the issue is with 1-2-2-0, although you haven't stated clearly what the actual problem is.

It is very seldom that the problem will be the HiPath DIU card and from experience network providers are always loathe to admit that they have a problem. Given that you only have the DIU card the fault liability is more likely to be with network provider. The network provider should be able to identify the problem with an ISDN tester.

 

[lhiraman]

Birdseye, the telecom provider came in said they tested all three PRIs and can not find the issue.

The problem we are having is: randomly, when we make an outbund call, the person on the other end can not hear us.

After a few seconds, we call the same outbound number the call is clear as daytime.

 

[birdseye51]

Ihiraman, how did the telecom provider carry out his tests?

Change the search mode in AMO TDCSU to ASCENDING. The outbound traffic will now select channel 1 on link 1-1-1-0 and will always try this link first and will step on to 1-1-1-1 only when all 23 channels on 1-1-1-0 are busy. You only have to change the search mode on one of the PRI's and this will change the other 2 as they are in the same trunk group.
The circuit does not have to be de-activated to change the search mode.
Try this and see if the frequency of the problem decreases.

If you then DIS-BUEND:1; the search mode will now show ascending.

If you're unsure how to do this let me know.

 

[lhiraman]

Birdseye,

I am not sure how to do this. Can you let me know how to do this? Plus there have not seem to be any issues today. No one called our Help Desk complaining.

 

[birdseye51]

Could you DIS-TDCSU:1-2-2-0;

I need to know the B Channel group from this.

Do you still want to change the search mode if you've had no further reports or do it only if there are further recurrences?

 

[birdseye51]

Ihiraman,

I do not need to know the B channel group.

If you CHA-TDCSUEN=1-2-2-0,SRCHMODE=ASC; that will change the search mode to ascending. To change it back use the same command but substitute ASC for DSC. The other option is CIR which is circular searching which uses one channel after the other.

 

[lhiraman]

CHA-TDCSUEN=1-2-2-0,SRCHMODE=ASC;

What exactally will do? Change the channels to go in order?

 

[birdseye51]

Instead of always trying to use the last channel in the trunk group first and hunt upwards, descending mode, when dialling out the system will now use the first channel of the trunk group and hunt downwards, ascending mode. This way if the problem is on 1-2-2-0 it is highly unlikely that you would ever make an outbound call on that PRI unless under extremely busy conditions.

It's just a way of narrowing down the issue you may have had and identifying the actual link that the problem is on.

 

[lhiraman]

OK UPDATE:

Our Siemens Tech came in with our telco tech. The Siemens tech hit channels 22 and 23 as not passing anything, the telco tech tested the PRI on 1-1-1-1 and he said that he sees everything passing. Our siemens tech disabled channels 22 and 23 to see if the problem still continues. Guess what, the problem is still happening. The siemens tech came back in, can't find the problem. He totally disabled 1-1-1-1 to see if the problem still is happening. We have had two straight days with no issues.

What should I do next, have the telco company come back in and do what type of a test? Could the CSU be defective for the 1-1-1-1 PRI? HELP!