UNOBTAINABLE

[Vmail]

I have an IP403 running 2.1(27) load. Connected to a small LAN, via a 24 port Cisco switch. 2 Digital phones and abount 8 IP phones, 5 VOIP compression module. We have started getting many UNOBTAINABLE from the 4612 IP phones. Used to be once in a while, now it happens 1-2 times per day. We have to reboot the IPO then finally issue is fixed for a few days, then back again. Any ideas? No VLAN's are used but the computer port in the back of the phone is used for the pc's.

Secondly, all the ip phones have static ip's. All reboot fine by themselves when power is recycled, but one doesn't. It requires the extension and p/w be put in each time? I am missing something here too?

As always--thanks.

 

[ITfromZX81]

Hi,

Unobtainable generally means the phone cannot get a line - either a real or a Virtual Circuit.

Check to make sure that calls are not being left open - use the Call Status utility.

In my experience, this can happen when users mistakenly put their phone on DND using their phone, and not picking up the headset - this activates their speakerphone and leaves a 'line' open, even if they haven't dialed out - when enough people do this it starts causing unobtainable errors.

This can also happen if someone tries to dial an outside line and there are no lines available - all the phone lines are in use. Again, call status should pinpoint this for you.

Hope this helps,

- Mike

 

[intrigrant]

Do you run a VM Pro on the IP Office?

 

[Vmail]

mmount, I have verified many times that no lines are locked up? This is making me crazy as to what to look at next. Intrigrant, we are running vmpro.

 

[TivoNut]

I've had this same problem, but with the Small Office Unit. No lines were in use either. Try running a Monitor session while it's happening and see what you get. I did and got hundreds of lines per minute of the errors listed below. Nobody's been able to tell me what they mean, something to do with CallerID on the analog lines. It eventually recovers and starts working again, or a reboot fixes it.

542312mS PRN: AtmIO4: Trunk Release
542312mS PRN: AtmIO4: Block Forward OFF
542313mS PRN: AtmIO4: CLI Detection ON Equaliser OFF
542342mS PRN: AtmIO2: CLI Detection OFF Equaliser OFF
542460mS PRN: Monitor Status IP 401 NG 2.1(24)
542461mS PRN: LAW=U PRI=0, BRI=0, ALOG=4, ADSL=0 VCOMP=3, MDM=0, WAN=0, MODU=0 LANM=0 CkSRC=0 VMAIL=1(VER=0 TYP=3) CALLS=0(TOT=3480)

542623mS PRN: AtmIO4: CLI Detection OFF Equaliser OFF
543802mS PRN: AtmIO3: Trunk Release
543802mS PRN: AtmIO3: Block Forward OFF
543802mS PRN: AtmIO3: CLI Detection ON Equaliser OFF
544037mS PRN: AtmIO3: CLI Detection OFF Equaliser OFF
544391mS RES: Fri 7/1/2005 13:59:41 FreeMem=4978696(13) CMMsg=5 (6) Buff=100 638 500 1433 Links=9657
547252mS PRN: AtmIO1: Trunk Release
547252mS PRN: AtmIO1: Block Forward OFF
547252mS PRN: AtmIO1: CLI Detection ON Equaliser OFF
547393mS PRN: AtmIO1: CLI Detection OFF Equaliser OFF
547548mS PRN: AtmIO2: Trunk Release
547548mS PRN: AtmIO2: Block Forward OFF
547548mS PRN: AtmIO2: CLI Detection ON Equaliser OFF
547688mS PRN: AtmIO2: CLI Detection OFF Equaliser OFF
547827mS PRN: AtmIO4: Trunk Release
547827mS PRN: AtmIO4: Block Forward OFF
547828mS PRN: AtmIO4: CLI Detection ON Equaliser OFF
547962mS PRN: AtmIO4: CLI Detection OFF Equaliser OFF

 

[Vmail]

TivoNut,

I will check, but according to my memory, what you have in your post is exactly what I saw? Anybody have and idea's?

 

[intrigrant]

VMail, are VoIP users recording calls?

 

[Vmail]

Some times, but not always. I have programmed call record on each ip phone. Is that the issue?

 

[intrigrant]

Yes, this lockup VCM channels in 2.1.27 Avaya investigates on site right now for me.
I've got a special build 2.1.278905 but no luck so far.
I suggest to tell your customer not to use recording for a week or so and see what happens.

 

[myalias09]

I have experienced this at 2 sites. Both were upgraded to the 2.1 instead of a clean install. Go to "extensions" in the Manager. In the IP sets, on the second tab turn off "enable faststart". This appeared to fix the problem. On the other site I rebuilt the database from scratch by hand and defaulted the box and loaded it as a clean install of 2.1(27) this also fixed the issue and has been very stable since. However, I would try to turn off the faststart first. It is less painful and quicker. It took myself and Avaya about 4 months to figure that out. You can also get it stable by downgrading to 2.1(15) for the time. Hope that helps
-Chip

 

[Vmail]

Will do Chip, thanks soooo much. We tried to not use the record a call for a week but still same thing. I will wipe clean and install the 2.1.27 load and see.

 

[Morrack]

Don't downgrade to 2.1.15 you're just asking for more pain. If you must downgrade go all the way to 2.0.18 which was fairly stable.

 

[Vmail]

Should I default the box then go to 1.99 first then up? Will my existing config work or should i start from scratch.

 

[IPGuru]

V1.99 only needs to be installed the 1st time a system moves from V1.x to V2.x.
once a system has been upgraded to V2.0 or higher it is no longer required.

if you downgrade to V2.0(18) you will probably find that your CFG is still perfectly useable but open & resend it using a V2.0 manager too clean it up

 

[Vmail]

thanks ipguru, but if i dte reset the box. Don't I have to go to 1.99 first then 2.0(17)?

 

[IPGuru]

No V1.99 reconfigures the internal flash partitioning & updates the monitor loader

once it has been isnatlled once you can move between any version 1.0 through 3.0 or erase using the DTE port without ever needing it again.

reinstalling V1.99 will not do any harm.