Phone lines cut out randomly 2

[Quadnet]

After it drops, we restart the switch and it works until the next drop (about 2 times a day)
We've checked with BT and it seems is an internal problem.

Our system:
Phone switch: Avaya IP403 at software level 3.0(578);
IP Office manager 5.2(55)

We believe the problem is software related
Are they any known bugs/incompatibilities between these two versions?
What is the highest version for the switch we can install? and which version of IP office would correspond to it?

This is now becoming an urgent issue.

 

[Quadnet]

jamie, I don't know what a BP is but no, we don't have any support people behind this, we're a small company and I'm not sure if we could afford this kind of troubleshooting, but I always thought only BT does this kind os testing

 

[tlpeter]

A bp is a a Business Partner
A business partner is a company who is certified to do the implementation of the ipoffice (in this case)



ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Quadnet]

yes, when the lines drop we can do internal calls.
I can't find this lock to peb or lock to falc, are they options under teh filter settings?

 

[tlpeter]

In monitor go to filters and then select isdn
Select all and let the trace run
If you pull the isdn line you will see that your isdn line is down
plug it back in and wait untill it happens again


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Quadnet]

OK it happened again.
I'm posting part of the log where the fault happened.
Please let me know if the info isn't there, there is a cause=41 temporary failure recurrent message but I can't see what is it related to.

log:
70361945mS PRN: CALL: 0.2264.0 Deleted leaving 2 CMCall objects
70361946mS CALL:2008/01/2509:44,00:00:03,004,5956,O,6846,6846,AhmirS,,,1,,""
70361946mS CD: CALL: 0.2264.0 Deleted
70361947mS CMExtnTx: v=5956, p1=12
CMReleaseComp
Line: type=DigitalExtn 5
Call: lid=0 id=12 in=0
BChan: slot=5 chan=13
UUI type=Local [....] [0x03 0x00 0x00 0x0e ]
Timed: 25/01/08 09:44
70361953mS PRN: TFTPServer::RRQ(from 192.168.100.51) nasystem/call_list/$t%$'~ q/cs02
70361980mS PRN: CMIE::UnPack Failed to decode/unpack IE 6e (len=0)
70362001mS CD: CALLSYNC: cs02
70400524mS PRN: 1720 bytes @ffde8a1c were allocated by ff8880d8 00000000 at 86182321 mS
70400933mS ISDNL3Evt: v=5 stacknum=5 State, new=ReleaseReq, old=Active id=2255
70400983mS ISDNL3Evt: v=5 stacknum=5 State, new=NullState, old=ReleaseReq id=2255
70400987mS CMLineRx: v=5
CMReleaseComp
Line: type=Q931Line 5
Call: lid=0 id=2255 in=0
Cause=41, Temporary failure
70400987mS PRN: CALL: 0.2254.0 Deleted leaving 1 CMCall objects
70400988mS CMMap: a=7.5 b=0.3 M0
70400988mS CALL:2008/01/2509:37,00:07:04,009,5961,O,907968897716,6842,PaulT,,,0,181007968897716,""
70400989mS CD: CALL: 0.2254.0 BState=Idle Cut=0 Music=0.0 Aend="Paul T(5961)" (7.5) Bend="Imran M(6842)" [Line 5] (0.3) CalledNum=907968897716 () CallingNum=5961 () Internal=0 Time=424003 AState=Idle
70400990mS CMExtnTx: v=5961, p1=4
CMInbandTone
Line: type=DigitalExtn 7
Call: lid=0 id=4 in=0
BChan: slot=7 chan=5
UUI type=User2User [TB1\r\n] [0x54 0x42 0x31 0x0d 0x0a ]
Cause=41, Temporary failure
Timed: 25/01/08 09:45
70400990mS CD: CALL: 0.2254.0 Deleted
70401032mS RES: Fri 25/1/2008 09:45:02 FreeMem=5572976(14) CMMsg=5 (5) Buff=100 656 500 1423 Links=9700 ASNElements=0
70401273mS ISDNL3Evt: v=5 stacknum=5 State, new=ReleaseReq, old=Active id=6
70401325mS ISDNL3Evt: v=5 stacknum=5 State, new=NullState, old=ReleaseReq id=6
70401330mS CMLineRx: v=5
CMReleaseComp
Line: type=Q931Line 5
Call: lid=5 id=6 in=1
Cause=41, Temporary failure
70401331mS PRN: CALL: 5.6.1 Deleted leaving 0 CMCall objects
70401331mS CMMap: a=0.4 b=2.27 M0
70401331mS CALL:2008/01/2509:43,00:01:12,027,01932454306,I,6846,5959,,,,0,,""
70401332mS CD: CALL: 5.6.1 BState=Idle Cut=0 Music=0.0 Aend="none" (0.4) Bend="Ashraf F(6846)" [Ashraf F] (2.27) CalledNum=6846 () CallingNum=01932454306 () Internal=1 Time=39390 AState=Idle
70401333mS CMExtnTx: v=6846, p1=7
CMInbandTone
Line: type=DigitalExtn 3
Call: lid=0 id=7 in=0
BChan: slot=2 chan=27
UUI type=User2User [TB1\r\n] [0x54 0x42 0x31 0x0d 0x0a ]
Cause=41, Temporary failure
Timed: 25/01/08 09:45

 

[tlpeter]

You have a cause= 41

Here is what it means
I think it is a provider issue

Cause No. 41 - temporary failure.

This cause indicates that the network is not functioning correctly and that the condition is no likely to last a long period of time; e.g., the user may wish to try another call attempt almost immediately.
What it means:
This means that there is a temporary failure at the physical layer on the ISDN network. If you remove the ISDN cable from the Netopia, you would see this. It's usually temporary.


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Quadnet]

Well, temporary, is being temporary for teh last 3 weeks.
Could it be a generic error message for certain faults?
What would be teh line of action under this circumstances?

 

[tlpeter]

I would call the provider (not the one overhere )
It is possible that the cabling in the street is bad
It must be something from there network
If your pri card was bad i think you would see other erros as well
You can ask if there are more people or company's have the same problem


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Quadnet]

We've called BT and they maintain that they've run some tests and the line is fine (what's new).
How can I prove to them their line has a fault? can I use this error message as certain proof that the fault is not internal?

 

[tlpeter]

You could try

If you ask here what some people think of BT then i wish you good luck

Ask for a long term test ,not just one from a computer somewhere else but one on location for a week or so




ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[Quadnet]

Right
Another try with BT, I've asked them to run a long term test.
THey've run a test while I waited and came back to me with the argument that the line is fine and there hasn't been any alarm/warning/fault for the last 7 days, without any alarm showing up on their system they can't start a long term test.
It seems the results we have here about our internal system (temporary failure) are no good for them

So Im in square one I supposed, I opened a case anyway and will be recalling it everytime I call.

Not sure which way to go really

 

[jamie77]

It's always a battle with BT. Are you delaing direct with BT Retail or going through a wholesaler and apeaking to BT Openreach???

I think you are going to struggle without a support contract to call on, If you were our customer (not trying to blag business before anyone thinks so!!!! ;-) ) we would come out with a Trend ISDN tester and set it to monitor the lines, would also probably leave it on site recording the info hoping to catch when it happens and then come get it and take a look.

Where are you based. The weather recently has caused us a few problems. We have an ongoing argument with BT at the moment at a customer in Pill, Bristol. BT say they have tested it and it is fine but the INDeX still has a red snyc error light on the PRI card.

Jamie Green

ACA:Implement - IP Office
ACS:Implement - IP Office

http://www.alliedcom.co.uk

Fooball is not a matter of life and death-It is far more important!!!!

 

[Quadnet]

Well funnily enough I got a call back from BT, fault reporting department (or something like that).
The chap said he can look further but needs some phone numbers that were being used at teh time of the fault or right beforeit happenned.
I got to my log file and got a few numbers (not the 10 he said he needed) but I've sent him also the log file as it should be of help for them.

We're based in east London and the weather has been OK lately, we are in a industrial state and there are no many households round here (maybe is a bit remote for their lines ??)

 

[Quadnet]

Guys, thanks a lot for your replies

It seems the BT engineers can maintain a fault case open for 48hours only.
So I'll get Monday and Tuesday to log the faults (if any) and get them 10 phone numbers which are actively on a call when the fault happens.
We'll keep you updated

 

[Quadnet]

The monitor application (SysMonitor) doesn't connect to the switch, keeps saying "trying to connect to 192.168..."

For some reason I've not been able to connect all morning with the Monitor but IP Office logs me in as administrator no problem.

Will this need a switch reboot to fix it? (not something I'd like to do),
Apart from that the switch seems to be working fine, no problems today.

 

[amriddle01]

Hi there, Well this may help you as I had a very similiar problem as you in Colchester! The lines were dropping every 5 to 6 mins in the end but started just as yours 2-3 times a day. Raised the issue with BT...same as you no faults so we changed the PRI card, still same problem, changed card again still same, Changed the IP500 out and card still same issue. This showed BT that the only common problem was their NTE even though it tested fine apparently. So they reluctantly agreed to send an engineer to site while I also attended. When the Engineer connected his laptop the line showed as very close to failing on attenuation but within tolerance also a flag came up saying one of pairs were crossed but this "should" not affect anything. He connected a cheapo Trend lookalike and made 15 call fine, i tested the same with a Trend and again 15 min+ call fine, however IP Office calls drop every 5 mins. After much head scratching I asked if he would correct the "not important" crossed pair anyaway and What do you know it solved the problem. It seems that the system tolerates the crossed pair until the attenuation worsens over time and then starts to drop the link.

P.s I was present as he reported the findings to his Boss and I heard his Boss say "Can you make it look like their fault so we can still bill them?" He replied "No cos he is stood here listening and watched me fix it". This was followed up with an extremely apologetic conversation between me and his Boss where he claimed he was just Kidding!!! Yeah right...That sums BT up exactly

ACS - IP Office Implement

 

[jamie77]

amriddle01
You get a star for having the proof about BT that we all new.

Bunch of cowboys.

YeeeeeeeeeeeeeeHaaaaaaaaaaaaaaaaaa

Jamie Green

ACA:Implement - IP Office
ACS:Implement - IP Office

http://www.alliedcom.co.uk

Fooball is not a matter of life and death-It is far more important!!!!

 

[ronromano]

Wow, this sounds like an international problem.

 

[Quadnet]

Today, I've sent BT the list of phone numbers at the time they drop with the times they happen (2 days collecting).

Same day they've put an engineer on the exchange and found a fault, it seems our system and theirs are out of sync.

I'm quite impressed at the speed at which action is been taken, also plenty of updates from BT all this in the space of two hours, i feel like this fault is going to be fixed pretty soon.

 

[Quadnet]

Right,
Anybody knows how to sync the switch with BT?
It seems since a power cut some weeks ago the switch and BT's network are not in sync thus everytime we reboot the switch it kind of runs on its own time and after a while the difference with BT's time is to wide and the lines get cut off.

This is the final result BT has given me and they looked convincing.
Is this something to do with IP Office's system's settings? (I can see a box for the IP address of a time server)
I need help here, as soon as I know how to get the switch (or just the card) in sync I can call back BT and get the switch working