| Avaya Phone | Power Class | Max Allocated (Watts) |
| 4601 | 2 | 7.0 |
| 4602+ | 2 | 7.0 |
| 4610SW | 2 | 7.0 |
| 4621SW | 2 | 7.0 |
| 4622SW | 2 | 7.0 |
| 4625SW | 3 | 15.4 |
| 9610 | 2 | 7.0 |
| 9620 | 2 | 7.0 |
| 9630 | 2 | 7.0 |
| 9630G | 2 | 7.0 |
| 9640 with SBM24 | 2 | 7.0 |
| 9650 | 2 | 7.0 |
| 1603 with PoE Adapter | 2 | 7.0 |
| 1608 | 2 | 7.0 |
| 1616 | 3 | 15.4 |
| 1616 with BM32 | 3 | 15.4 |
| Quick Edition 4610 | 2 | 7.0 |
| Quick Edition 4621 | 2 | 7.0 |
| Quick Edition G10 | 0 | 15.4 |
In case anybody else’s struggling with ASD that stopped working after last update, here’s that missing DesignNotesExport.dll. Just unzip it and drop into C:\ges\bin or any other PATH directory.
Useful tip to access IPSI via SSH
from CM Linux shell:
1) disable any session to IPSI: ipsisession -d -c 01A (01A – replace with your IPSI)
2) enable session to IPSI: ipsisession -c 01A (01A – replace with your IPSI)
3) copy password that was created
4) access to your IPSI: ssh init@ipsi-a01a. respone to the “yes/no” question by typing “yes”. enter the password that is given
You may have to hit enter for the prompt but you’ll then see:
IPSI SSH Options:
——————————-
Enter ‘1’ for IP Administration
Enter ‘2’ for VxWorks Shell
This is where you’ll enter “1” then type: ispilogin and then enter login/pass for your IPSI
if you know what is VxWorks Shell and how to use it please leave comment.
Found an interesting document in my archive:
Avaya Platform Elements Component
Mean Time To Failure
Media Processor Board ** 35 years Protocol Preprocessor Board (C-LAN) ** 50 years Digital Line and Trunk Boards ** 72-77 years Avaya Media Server Complexes 10-90+ years Avaya Gateway Power Supplies ** 25-60 years ** Based on numerous internal Avaya studies assessing the results of millions of user-hours.
Nice, isn’t it? It must be especially heartening to know this when you’re out there in the field, replacing another faulty TN464.
Here’s the next part:
Avaya Availability Analysis S87xx
(Avaya Communication Manager Software 3.x)
(based on data as of March. 30, 2006)
Standard (or Duplex) Reliability Higher Reliability Sub-System Failure/ year MTBO (Years) Availability Failure/ year MTBO (Years) Availability S87xx Server Complex 0.1095 9.1 0.99995 <0.01095 >91.3 >0.999995 G650 Media Gateway – IP Connect – Simplex 0.131 9.0 0.99994 G650 Media Gateway with duplicated IPSIs 0.018615 53 0.999992 G650 Media Gateway with duplicated IPSIs and Media Processors <0.01095 >91.3 >0.999995
May be useful for preparing RFPs or alike documents.
It is well known problem that Communication Manager cannot synchronize time with Windows 2003 Server machines over NTP. Here’s the workaround recommended by Avaya Tier 3 support engineers:
The NTP client on the S8X00 server is rejecting the NTP server because it considers it as a not reliable source clock. The NTP server reports the ‘root dispersion’ value with 10 seconds and this is considered too high. This is a Windows 2003 server issue and it is not an S8X00 problem. Below is what you can do on the Windows server.
Change the LocalClockDispersion value in the Windows 2003 server registry, from the default value 10 to 0, the registry value is:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfigLocalClockDispersion
This can be done from the command line:
w32tm /config /LocalClockDispersion:0
Restart the Windows Time service, this can be done from the services application in windows or from the command line:
net stop w32time && net start w32time
I hope this helps.
It helped indeed. I haven’t checked this with Windows 2008 but if the symptoms are alike, the solution above may be valid.
Very often you need to trace communication beetwen AES<->CM and AES<->application. I find an interesting solution for that (including decode of Avaya PVD)
To enable and access the AES logging of TSAPI events:
Save and close file tracemask. Navigate to the ‘/opt/mvap/logs’ directory. When a TSAPI message is received, a new directory named ‘TSAPI’ will be created in it. The ‘TSAPI’ directory contains the log files related to the events occurring in different portions of the system that handle TSAPI messages. (g3trace* – CM<->AES, CSTA* – AES<->Application)
Remember to disable tracing when you are through since it does have a performance impact on the AE Server.
Did you know that you can assign aux-work button to any extension that is a member of non-ACD hunt group? You can, and while that button is depressed, the extension won’t get any calls from that hunt group–until the button is pressed again.
Mighty useful feature in my opinion, but should be used with care. Users tend to forget that they pressed something…
I am continuing the topic started in previous post, regarding cheap and simple BCMS statistics usage for a call center. In this part, we will use standard Avaya Site Administration software for report collection and Apache HTTP Server for report distribution. It is not very hard to implement this and process is not too complicated but will require software installation rights–or Administrator account–to do it so if you’re not sure you have those permissions you may have to ask your system administrator about it. One possible way is to dedicate some older lowly computer solely for this task, set it up once with administrator’s help and let users in on it.
For many call centers out there, BCMS statistics are more than enough and there is no real need for CMS. However, BCMS per se does not store historical data for more than a week–and that’s only for summarized day data, interval data is stored only for 48 intervals, that’s only a day with half-hour interval. There is BCMR Desktop software available from Avaya but it’s old, outdated, cranky and grossly overpriced in my opinion. There are alternative reporting systems like NetLert N-Focus or TASKE but they’re also relatively costly and not always justified for a small call center. So, BCMS that comes as standard with CM3/CC3 and higher becomes a valuable tool that is already there and can be very helpful if used properly.
The main BCMS disadvantage is that its data can be accessed only via text terminal on the PBX, not too user friendly and requiring that supervisors and/or managers should be given access to PBX that is, even if in read only mode, mostly too problematic for support personnel–people who manage people often are not too techy-savvy and tend to have trouble even with the most trivial tasks, not mentioning that mostly they’re afraid of anything not fancy-pretty-graphical and won’t touch a text terminal with a stick if they have any choice. This lack of affection for anything technical may be overridden with administrative pressure from above but, as always, will result in undercover resentment and resistance, creating a potential conflict point within company–but what is more important, it lessens effectiveness greatly not only because people are ineffective per se, but also because they refuse to bend to what they think those “tech freaks” are trying to force them do and won’t try to do their best even if just out of pure denial. Thus, some acceptable solution is needed for both technical and managerial personnel, giving the former an easy to support tool and the latter, an easy to use tool.
In my practice, I used variety of ways to achieve this, but eventually it boiled down to two parts: real time statistics via pre-programmed terminal and historical statistics via http. In this post, I will describe the first part.
Here’s one example of how to implement EWT announcements. I made it for one of my customers who were expecting rather a lot of their brand-new Avaya Call Center. By the time it was deployed they had awfully long waiting times in some queues and despite that, they wanted announcements as detailed as possible. This is how I did it.