ceaser_t

Hi All,

We have Avaya 8710 runin on CM 3.1.2. Just recently we have been started receiving phantom calls on our trunks. The calls less than 10 seconds have increased per the ccall volume. Does any one have idea how to rectify ot do the diagnosis?

Thanks in advance

Ceaser

martinyoung

My first thought would be a trunk problem, especially since it seems to happen when your call volume increases.

The first thing to do is status all your trunk groups and look for any trunks that are not idle or active.

Then type "display error" and then on that screen set it to look at errors. See if there are any trunk errors.

Do you have more than one trunk group? If so, are these errors coming in on more than one trunk group?

__________________
Marty
Retired Avaya DSIC tech

PBXtech.info

 

el claypool

Is your PBX receiving any call volume that has been Transfer Connected to you?

If yes, then there are 2 possible causes:
1 - They are using in-band signaling and have a fail-over route-to step with an insufficient wait-time between the DTMF tones and the trunk-to-trunk.
2 - There are 2 Transfer Connect enabled call segments active in the provider's network when the sending switch played it's DTMF tones.

If it is #1, you should see a coresponding increase in call volume.

If it is #2, you should have people complaining that they are getting hung up on.

Of course, if no one is Transfer Connecting to you it is something else.

ceaser_t

Thanks Marty ! We have more than 1 trunk groups . For this particular LOB we have 3 Trunk groups how ever i do see error

04B1301 ISDN-TRK 0012/031 1793 0 07/24/17:06 07/25/13:43 177 8 21 r n
04B1301 ISDN-TRK 0012/031 18 0 07/25/13:43 07/25/13:43 1 0 1 r n
04B1301 ISDN-TRK 0012/031 1793 07/25/13:43 07/30/21:16 255 1 3 r n
04B1301 ISDN-TRK 0012/031 129 07/30/21:21 07/30/21:21 1 0 1 r n
04B1302 ISDN-TRK 0012/032 1793 07/24/17:06 07/25/13:43 178 8 22 r n
04B1302 ISDN-TRK 0012/032 18 0 07/25/13:43 07/25/13:43 1 0 1 r n
04B1302 ISDN-TRK 0012/032 1793 07/25/13:43 07/30/21:16 255 1 3 r n
04B1302 ISDN-TRK 0012/032 129 07/30/21:21 07/30/21:21 1 0 1 r n
04B1303 ISDN-TRK 0012/033 1793 0 07/24/17:06 07/25/13:43 178 8 22 r n
04B1303 ISDN-TRK 0012/033 18 0 07/25/13:43 07/25/13:43 1 0 1 r n

Does this error means something ? i m seeing these errors in more than 1 trunk group.

Appreciate your help

Thanks

Ceaser

martinyoung

Error type 18 is the channel is busied out, release it and see if that helps.

Error type 1793 indicate possible DS1 board failure, if you have a spare swap it and see if things are better.

Error type 129 is that the CO might have taken the channels out of service, give them a call.

The order I would look at these is 18, 1793, 129.

__________________
Marty
Retired Avaya DSIC tech

sczepan

If your trunks are set up as PRI make sure your Ts are in the correct order. We recently had a phantom call problem that got worse higher call volume. It turned out that the cableing was out of sequence, the 10th T was plugged in where the 4th T should have been. When we hit the 4th T we got the phantom call problem.

PBXtech.info

 

martinyoung

That is a very good point. If you are using NFAS on your PRI's make sure that you and the CO are in the same sequence.

__________________
Marty
Retired Avaya DSIC tech

ceaser_t

Thanks Marty for the update. I released the board and checked the error still persist i.e error type 18 . Then i replaced the DS1 card with the spare one , but again i could see the error type 1793. Regarding the 3rd error i need to check with the service provider if they may have placed the trunk under maintainence.

Also i didnt quite understand the cable sequence. The cabling was from my AVAYA to MDF is constant for all other E1's . Are you talking about the cabling from MDF to Passport ? We have Nortel Passport to terminate the E1's .

Thanks in advance again !

Ceaser

martinyoung

What the cabling is referring to is between you and the CO.

Let us say you have ten PRI T1s and we will call them 1-10 (very original, I know) and you are using NFAS for your signaling (that means all T1s are in one signal group). T1 number one carries D channel 0 (primary D channel), T1 number two carries D channel 1 (secondary D channel). T1s three through ten are terminated in the CO in that order. You will be receiving them with an interface ID of 0-9 from the CO. You must have them assigned in the same order in the signal group.

In the example above T1 number five will be coming to you with an interface ID of 4 and T1 number six will have an interface ID of 5. If you have not assigned them in that order in the signal group (lets say they are reversed), when calls land on those two T1s you will have problems like no transmission or dropped calls (phantom calls).

The only way to positively confirm you have them in the same order is to have your vendor tell you what order they have assigned them in, then trace the cross connects from the demarc all the way to the DS1 boards in the PBX. Once you know for sure which DS1 board is cross connected to each T1 make sure you have assigned the same interface ID in the signal group as the CO used.

__________________
Marty
Retired Avaya DSIC tech

ceaser_t

Thanks Marty for passing the info. I checked with the CO regarding the sequence . It doesnt seems to have any issue as other E1's are connected on it with no problems. How ever i checked with the service provider for these trunks and they were able to locate few errors on the ckts. Probably seems to a clocking issue as we have internal clocking provided to these ckts . Now we have changed to external source so that they would take these trunks under testing and let me know what is going on. I 'll keep posting regarding any +ve results . It may add some light on this forum regarding phantom calls.

Anyways appreciate your help !

Ceaser

ceaser_t

All,

Just a final update on this problem. Seems to be clocking provided to these circuits have rectified the problem. The only thing we did was changed the clocking source to external clocking device ( usually the ISP). After that the phantom calls gradually reduced on 2 ckts and is now completely eliminated as we have the ckts pointing to external clock source. Wonder how would clocking can make a real big difference ??? Least bit it solved the issue.

Thanks all for your help

Ceaser

martinyoung

All T1s require clocking to be stable. The normal procedure is to select at least one primary sync source (this would be an ISDN T1 as first choice) and if you have several T1s, pick a secondary sync source. When you status sync you will see the primary and secondary sync source, if it is 1A instead of the T1s you specified then disable sync and enable sync to get it back where it belongs. If your T1s are clocking internally they will begin to slip and will eventually fail.

__________________
Marty
Retired Avaya DSIC tech

mgp123

Hi,

It may happen due to clocking differences/slips.
Try changing the clock source for your trunks.....get them aligned with the service provider.