Twin Pri IP Office 406v2 trunk line errors

[tnlcom]

I Have an IP Office 406v2 with 4.1.15 software and contact store, 12 x VMPro licences, 2 x ISDN30e pri cards and 38 channels of ISDN30e

I have problems with this picking up all 30 trunks on the first card and in fact when the customer dials out we can make the service fail at around 14 trunks,after that it won't pck up any further trunks until it reaches the second card and then continues on happliy. I have the second card set to 8 channels avaiable but to be honest it has been set with both 8 and 30 and it makes no difference I have swapped services round as well and taken note of the clock source settings as well.

We have had this fault fo some time and in fact BT have sent their special faults epartment out to look at it and run test. They sya the fault originates from the system and not the lines.

Needless to say Ihave sent a config up to Avaya and they have said they have no issues that they are aware of in any of their software levels that cayse this problem.

Both services run as line group "0" incomming and outgoing and I would like to disable the second service to see if I can force the first card to fail on it's own but when I try changing the group on the second service it just puts it back to "0".

needless to say we hve replaced al the kit, checked all the cables back to the NTE looked at the LAN network with wireshark and can't see any issues.

Any one come across this before?

Also Jut in case you think I should change the software to 4.2 this fault has been with us as far back as 3.1 and has been upgraded through three or four levels of software. All the hardware has been eplaced at least once also.

I still feel this is a line fault but this is hard to argue with when BT brong in outside agencies to find the fault.

 

[amriddle01]

You need to put a Trend (or equivalent ISDN test set) on the lines and do tests and calls on the lines with that, BT tend not to argue then. You can also emulate the lines to the system using the Trend and see if it is that at fault. I assume you don't have one...they are not cheap

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers

 

[amriddle01]

It is strange that you can't change the line group of the second line, that is an issue, did you try to merge or do a reboot after making the change?

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers

 

[IPGuru]

How long is the cable between the IPO & The NTE?

 

[tnlcom]

Ok. cable is under 3m long from the NTTP.

Trends have been used by BT on both circuits with extneded tests but I feel that BT are not looking for a fault with their system so much as looking to pass the fault off to the maintainer.

I don't have a trend but it's getting to the point where I might have to get one just to fix this problem.

I did an immediate reboot in fact that is all it would let me do with a line group change and I have done it three times to check to see if it's me!

 

[amriddle01]

That's what BT do, I have caught them out before and coincidently also this morning, We have a site where outgoing calls are dropping and Incoming calls are getting crossed lines, rang up BT got a fault ref number as the lady could see live alarms on their NTE. They call back saying they can't see any faults on the line....so I asked why the lady I rang could see faults and also why the company next door on a seperate system in a seperate building running through the same exchange was having the same issue and after a long pause they hung up That's BT for you.

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers