Avaya has released UNIStim firmware 5.0 for their IP deskphones;
- 0621C8A for the 2007 IP deskphone
- 0623C8A, 0624C8A, 0625C8A, 0627C8A, 0626C8A for the 1110, 1120E, 1140E, 1150E and 1165E IP deskphones
- 062AC8A for the 1200 series IP deskphones
This release of firmware adds support for the following features;
- Support for wideband (G.722) codecs on 1120E, 1140E, 1150E, 1165E, 1220, and 1230 IP Deskphones.
- Support for Avaya Notification Solution (ANS) and Avaya Push API which provides the ability to push text, graphics, and audio messages to 1100 Series, 1200 Series and the 2007 IP Deskphones.
- Support for a Wireless Markup Language (WML) browser for 1140E, 1150E, and 1165E IP Deskphones.
Product Advisement for UNIStim 5.0 related to Zero Touch Provisioning:
For customers who have pre-configured the REG entries (which includes the MAC address, the TN, and Node) within the provisioning file to enable Zero Touch for the IP Deskphones, be advised that a problem can occur related to parsing of the REG entry that may result in the IP Deskphones not coming up as expected, and instead continuing to reboot when UNIStim 5.0 is loaded onto the units. The issue will impact IP Deskphones that have been pre-configured for Zero Touch and where the REG lines still exist in the REG entry. This is a known issue that will impact IP Deskphones that have a matching MAC address already pre-configured in the REG entry. This issue will be fully addressed in the upcoming UNIStim 5.1 maintenance release expected in March 2011, and customers may want to delay updating IP Deskphones and Call Servers until that time due to this issue.
In the interim, to avoid this issue the following workaround is recommended: Before loading UNIStim 5.0 onto the IP Deskphones, customers are advised to add a comma before the semi-colon of the REG entry. If UNIStim 5.0 is already loaded, and the issue exists (where the phones continue to reboot instead of coming up), the customer can then add a comma as specified above and the IP Deskphones will come up.
Example: reg= 0021e1ff59cb cs1k s1 3380 096 00 00 18,;
I also recently had a discussion with another telephony expert around the issues of running a PC at 100Mbps (connected to the IP phone) when the 1100 series IP phone is connected to the network via 1Gbps or vice-versa. Here’s the relevant blurb from the release notes that details the problem.
Throughput may be slow for large file transfers on conversions from GigE to 100Mbit (applies to the 1120E, 1140E, 1150E and 1165E IP Deskphones)
In networks in which a PC is connected to the IP Deskphone’s PC port and the PC’s NIC speed is 100Mbit but the network speed is at GigE, large file transfers to the PC can take quite a long time. This is an issue with large file transfers only. Due to the speed mismatch between the phone’s two ports the buffers in the phone can overflow resulting in retransmissions. Although the IP Deskphones support Ethernet flow control (802.3x), the support is only implemented on the phone’s PC port, not on the phone’s network port. Ethernet flow control is a mechanism were the IP Deskphone can request a brief “pause” from the transmitting Ethernet device if the IP Deskphone buffers are about to overflow.
Ethernet flow control cannot be implemented on the phone’s network port, since it impacts the phone’s voice quality. As a result, in environments were the network is GigE but the PC NIC is only 100Mbit, large file transfers from the network to the PC can take quite a long time. On the other hand, since Ethernet flow control is implemented on the phone’s PC port, in environments were the PC NIC is GigE but the network is only 100Mbits, large file transfers should be well managed by the phone’s Ethernet flow control mechanism.