Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avaya One-X Attendant - Slow Directory Search

Status
Not open for further replies.

Boulevard99

Technical User
Oct 29, 2014
32
US
Hi All,

Inquiring on any possible reasons why Avaya One-X attendant's phone book directory search would take a somewhat notably long time to produce search results?

(Approx: 3-4 seconds in result time)

Not familiar with 'attendant. And just looking into an issue that is currently in progress. Any info would help.

Thanks!
 
I've generally used a station export as its directory source. Are you doing that or connecting to a LDAP? I've found using the whole LDAP like dn=company,dn=com can be really long if all users are in a sub-folder of that.
 
I'm gather the history intel on this currently. It seems that this platform is using an LDAP source. Along with this, I believe the destination workstations are located quite far geographically from the One-X Server. And the One X is located just as far from the LADP.

Plus, this was an 'Upgrade'. So the end-users were very used to seeing results much faster as everything was local.

There's the old "End user Sensitivity" factor..

Right now, I'm trying to identify where all the pieces are located. I'm thinking geographic distance combined with an LDAP structure, might be the cause. But I was looking for another opinion on some 'Off the top of one's head' feedback.

Thanks!!

 
Follow up Reply:

After reviewing this issue further, it turns out that the application is functioning slowly for 'every' action performed. Not just a directory search, but other items like just logging in, or, transferring a call. The Windows circular icon just spins in place while the desktop client thinks about what it needs to do.

Looking further, turns out the VM server was relocated to a centralized location on the other side of the planet. (Please don't ask me why, as I am trying to find that out myself...)

I am theorizing that the root of the issue is geographic. There is just too much real estate between the desktop clients and the server over the LAN/WAN;because there are multiple sites located in the same region that use this same product off the same server and all of them are having the same issue.

Is there any documentation that can validate how the One X Att'd client 'always' refers back to the server for any operational function which would lend weight to this?

Thanks!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top