Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


The cause of 21(24) woes

The cause of 21(24) woes

The cause of 21(24) woes

IP Office stops responding to TFTP Requests
In the last few days Avaya SMBS tier 3 have received a number of field escalations regarding IP Office 2.1(24). The reported problem is that the IP Office Manager
application is unable to either send or retrieve a config.
At the same time there are also other symptoms such as the IP Office Phonemanager being unable to retrieve the user list from the IP Office, Voicemail Pro and Voicemail Lite
experiencing connectivity problems, as well as terminals being unable to change their divert or forwarding status.
This has now been confirmed as a problem related to the TFTP Reader/Writer in the IP Office running out of available TFTP sessions with which to handle the requests that these applications and functions require.
The root cause of this issue is a timing discrepancy that can occur when a TFTP read request and a TFTP write request occur simultaneously, resulting in the lockup of a
TFTP session on the IP Office. If all of the sessions available become locked, then the IP Office is unable to service any further TFTP requests.
The situation can be relieved by rebooting the IP Office Control unit.
If you believe that you are experiencing this issue, please contact your support
organisation referencing this technical tip.
The Avaya Tier 3 support team will be available to verify that the problem is valid and provide access to a temporary workaround whilst a longer term resolution is identified for inclusion in the next IP Office maintenance software release which is currently scheduled for November 2004.

RE: The cause of 21(24) woes

Why haven't they come out with this weeks ago? I installed 24 at a site, 406 with DT modules. All was ok from Friday evening till yesterday afternoon when I got a desperate call from the customer saying first of all users couldn't disable themselves from the hunt group, using the group key. Fair enough, that shouldn't happen! So I got them to try and manually take them out using Manager. They logged in, did as I said, then tried to go back in, but couldn't - by this time I had gone into a meeting. Came out an hour later, and NO CALLS we coming in, and the whole system had screwed up. Got them to power cycle the unit and all was fine.

I can understand there being problems with releases...but when our DISTRIBUTOR hasn't heard of the problem (our first point of contact) and then has to log a call via the States who put it in the queue - I find this very wrong by Avaya - they should make it public immediately when they know there is a known problem with a release which is meant to fix a load of bugs. I shall be complaining to our account manager at Avaya and will ensure I am told of any release problems!

Cheers and rant over!!

RE: The cause of 21(24) woes

I have a cuatomer with a 412 R2.1 (24) that worked fine for a week.  now their PRi's keep going up and down.  any idea if this might be related to the software load?

RE: The cause of 21(24) woes

The PDF I pasted this from was dated October 18th.

Business partners, FYI there is an online knowledgebase that is essentially the v2.1 HTML engineers tookit with additions and updates.  You have to login to the Avaya VPN to get to it.  That's where I got this new Tech Bulletin (number ~50 or so)

RE: The cause of 21(24) woes

The fix is 2.1.248901 , initialy they denied all knowledge,when i reported this fault.

Tier 4 were aware of this since 2.1 (11) and missed it in 2.1(15) and 2.1(24).

We have sites using this for the past 10 days so far so good, all our new installation will remain on 2.0 (18) until Avaya sort themselves out.


RE: The cause of 21(24) woes

I have one site using this (2.1.248901) since Oct 15, so far so good.

RE: The cause of 21(24) woes

do not be supprised if you start to get problems if your customer is using VM pro.

We have a cust that still experienceds the lockup problem on this setup. they are a heavy user of VM Pro.

RE: The cause of 21(24) woes

I think we are having this occur now.  
The TierIII tech said we may need to downgrade to VM 2.1(5) from (10)

RE: The cause of 21(24) woes

Jaynec what do you mean by the Avaya VPN?  Are you referring to the (useless) BP portal website?  I looked through that and it has nothing usefull as always, unless I'm totally missing a whole section or something.  I miss the days when they first set that up and they had all kinds of usefull techie stuff, now it seems to all be for the sales types.

I have a BP SSO login, where do I go to get access to this knowledgebase you're referring to?



RE: The cause of 21(24) woes

this website:
is behind Avaya's firewall.  You can get to it if you login to their VPN tunnel.  The BP website has info on getting access to the VPN, usually used for GES configurator.

RE: The cause of 21(24) woes

Thanks JayNEC, I'll look into this right away, sounds like a great resource.

GEE it would be nice if these BP news flashes would get sent out to BP's.....

Maybe I should ask for the bridge to hawaii instead (will that be 2 lanes or 4?)


RE: The cause of 21(24) woes

This 2.1(248901) release that people have been talking about - is it just new firmware for the main control unit, or is there a 8901 release for all the expansion modules too?


RE: The cause of 21(24) woes

Just the main control unit.  What I got from the Avaya tech was just a 412.bin file to place in the manager directory.

RE: The cause of 21(24) woes

Excellent, thanks for that.

I managed to find the bin files and wanted to make sure it was just the main unit after their 406 kept locking up (our Disti would have had to log the call via the States and wait till the next day for an answer - really stupid process)

I hope the release isn't country specific - I'm in the UK and installed it at a client - since they have said some calls have been dropping and faxes not working - all randomly, so I think it is probably user error, I hope!

RE: The cause of 21(24) woes

I have a quandry...who wants to help?

Our crack sales team in my office is pushing me to "upgrade" our 403 and Small Office units to the latest and "greatest" 2.1.24.  I am very reluctant to upgrade for the sake of upgrading.  I would love to upgrade but don't want to spend my Saturdays in the office rebuilding or rebooting units because of the instability that I keep hearing and reading about.  So to the question!!!

Do I upgrade and make the sales weasel's happy, regardless of the impending consequences to the customer, or tell em to bugger off until it's a better more stable upgrade???  

I leave it to you, my peers, do or don't do it?

RE: The cause of 21(24) woes

Depends on your locale, my friend.  If in the UK, tell 'em to bugger off (or a sheep, whatever their preference, I'm not here to judge).

If however you are in North America and NONE of your sites use DT ports, although I know IPGuru will think I'm a loonie, I would say go ahead with the upgrade...


RE: The cause of 21(24) woes

Rule 1:


unless V2.1(xx) offers you features that you dont have and NEED then why bother with the risk?

RE: The cause of 21(24) woes

it's quite scary how many sites I have on 2.1(15) - forunately they are pretty standard setups, so hopefully they won't have too many problems! Most of our installs are DS rollouts, but these few sites are DT with 2030s - I dare put them on .24!

RE: The cause of 21(24) woes

Just so everybody is on the same page, this 2.1.24 is absolutely affecting NA IPO using DS phones.
I don't know what the recipe is, but I have found it on an install using:
ip403 2.1.24 w/44xx
vmpro 2.1.10
Problem seemed to start when I added the "Queue ETA" action to my Hunt groups queued action.
Agents cannot login/out or go DND, cannot pull config from IPO. Reboot fixes for a short period.
The TSO wants traces, copy of config, etc. & to bill me 1 hr for the 2.1.248901 fix.
I am quite insulted being a paying BETA tester/debugger.

RE: The cause of 21(24) woes

Heck, I'll insult you for only 1/2 their rate, photon!  

What kind of call volume are you hitting that poor 403 with if you feel the ETA action will work for you??  That might be what's making the difference for your system.  I have a 403 with 9 queues and about 1000 calls per day on 2.1.24 and no probs except the touch tone bleed through, and that only very intermittently.

IPOUK I would be more than scared, I would be waking up at night screaming if I were you... I would downgrade those 2.1.15 sites to 2.0.18 just on principle.  I had a VERY simple 403 site with about 7 users on 2.1.15 and I had problems with it.  Downgraded and it has been fine since.


RE: The cause of 21(24) woes

I just ordered and installed VMPro 2.1, I was instructed to upgrade IPO 403 to 2.1x first which i did (uninstalled existing version then installed 2.1.15).  I'm having trouble getting the processor configuration to let me select VMPro... keeps reverting to VM Basic.  What am I doing wrong?

RE: The cause of 21(24) woes

did you uninstall VMLite?
does your VMPro license show valid when you pull a config?
VMPro will run for 2 hours unlicensed & shut down.

The system is averaging around 500 calls a day, 2 seperate "agent" queues(1 of them is miserably understaffed with long wait times). I have a bail out option to leave a message on the still queued action so callers can get out if they need to. I thought it would be a nice, new feature to give callers a queue eta.
Unfortunately CBC is registering a lot of dropped calls, which I guess is the VM option. I don't know how to fix this or explain to the client,"Uh yes maybe those callers hung up or maybe they didn't"

I did apply the *fixed*ip403.bin file this morning and the system ran all day without incident.

RE: The cause of 21(24) woes

photon, I am aware of the dropped calls issue.  Every time a customer leaves a voicemail via your bailout option, it counts in CBC as a lost call (ack!!) and worse, unlike in 2.0.18, it doesn't also count as an answered call EVEN IF you tick the "flag call as answered by voicemail" option in the reporting tab of your leave mail token.

To further complicate things, I have a site that ALSO does an assisted transfer to an agent with a 5 second timeout, which serves the sole purpose of providing a call waiting beep to clue her in that there are callers in queue (she doesn't look at her phone much).  What I have found is this unanswered (as expected) call ALSO counts as a lost call.  So, call arrives, goes into queue, beeps the agent with assisted transfer, waits in queue some more, then bails out and leaves a voicemail.  Net effect on my stats?

Answered calls: 0 (no change)
Lost calls: +2



Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close