SIP Software Release 3.2 for IP Deskphones

11
September 8, 2010
by Michael McNamara in

Avaya has released SIP software release 3.2 for their 1100 and 1200 series IP deskphones. This release adds support for the 1120e, 1140e, 1165e, 1220, and 1230 model IP deskphones.

Here are some of the enhancements made in the new software release;

  • Improved Licensing
  • SIP Support for 1220,1230 and 1165E IP Deskphones
  • Shared Call Appearances – CS1000
  • IPv6 Support
  • SRTP Media Security
  • TLS Signaling Security
  • Certificate-based Authentication
  • Enhanced Screensavers
  • Background images
  • Support for Avaya Aura™ Communication Manager / Session Manager

I was having a discussion with “Mike” in the comments section of any earlier post entitled, SIP Software Release 3.0 for IP Deskphones, in which he pointed out some of the issues with the new licensing model. Well it looks like Avaya was paying attention to that thread and made some changes to the licensing that should satisfy the majority of users. (I’m just going to quote directly from the readme.)

Improved Licensing

Licensing was introduced in the SIP 3.0 release. With SIP 3.2, the following changes are made to the licensing mechanism:

  • The Standard feature set is now available on all desksets without a token. This provides a basic set of SIP features conforming to RFC 3261 (SIPPING 19) at no additional cost.
  • Now, when the phone is registered to a recognized Avaya call server (Avaya AuraTM, AS 5300, CS1000 or CS2100), the Extended feature set is available as well without a token.
  • The Advanced feature set is reserved for Federal and DoD features on the AS 5300 call server only
  • The feature packages have been re-organized
    • Wideband is part of Standard feature set
    • IPv6 and Broadworks SCA are part of Extended feature set
    • Security is now part of the Extended feature set

If you connect your IP deskphone to a Avaya Call Server (Avaya AuraTM, AS 5300, CS1000 or CS2100), you’ll get all the standard features you would get with the UNIStim firmware. The licensing really only comes into play if you decide to connect your Avaya IP deskphone to a third party call server or SIP provider.

Please make sure to review the product bulletin and the readme for all the details.

Cheers!

Happy Labor Day!

0
September 6, 2010
by Michael McNamara in

Here in the United States we’re celebrating another Labor Day holiday and the unofficial end of the summer.

Cheers!

Remote Packet Capture with WireShark and WinPCAP

2
September 5, 2010
by Michael McNamara in

I’m just continually impressed with the quality of so many open source products available today. One such product that should be extremely high on any network engineer’s list is WireShark. WireShark has become the de-facto standard for packet capture software and is almost unrivaled in features and functionality.

Last week I had the task of diagnosing some very intermittent desktop/application performance issues at a remote site. I had installed WireShark locally on a few desktops but I wanted the ability to remotely monitor a few specific desktops without obstructing the users workflow to get a baseline for later comparison. I was excited to learn that WireShark and WinPCAP had (experimental) remote packet capture functionality built into each product. I followed the instructions on the WireShark website by installing WinPCAP v4.1.2 on the remote machine and then starting the “Remote Packet Capture Protocol v.0 (experimental)” service. With that done I then proceeded to launch WireShark on my local desktop and configure the remote packet capture settings. From within WireShark I chose Options -> Capture, changed the Interface from Local to Remote. Then enter the IP address of the remote machine along with the TCP port (the default TCP port is 2002). I initially tried to use “Null authentication” but was unsuccessful. I eventually ended up choosing “Password authentication” and used the local Administrator account and password of the remote desktop that had WinPCAP installed on it. If the remote desktop had multiple interfaces I could have selected which interface I wanted to perform the remote packet capture on. In this case the desktop in question only had an integrated Intel(R) 82567LM-3 network adapter. I clicked ‘Start’ and to my sheer amazement the packet trace was off and running collecting packets from the remote desktop. There will still be the occasional need to place the Dolch (portable sniffer) onsite when the situation demands it  but this is a great tool to have available.

Cheers!

Updated: Sunday September 5, 2010
The images appear to be missing above because the URL paths are wrong, not sure how WordPress messed up that. I don’t have time right now to fix it but I will fix it a little later.

Go to Top