Adventures in VoIP

I'm not going to tell you how to upgrade your IP Office, that's what the official training is for. I am, however, happy to discuss the various issues that I have experienced while performing upgrades, and the steps I take to ensure that the upgrade goes smoothly.

File Write Errors

I often see people struggling when transferring files to the IP Office during an upgrade. More times than I'd like to count I've seen the system pop up with an error stating "405 Method Not Allowed". While there are a number of things that can cause this issue the most common, by far, is the File Writer IP field in the system tab. If you're getting this error just check there and see if there is an address populated. I usually set the address to 0.0.0.0, which allows the writing of files from any address. While this may present a security risk, as long as you follow strong password management and don't leave any of the default passwords in place the risk should be next to zero. Alternatively you could specify the address of the PC being used to perform the upgrade, restricting the ability to write to the memory card to just that device. The third option is to set the address to 255.255.255.255, which will cause the system to update the address in this field the next time embedded file management is used to reflect the address of the system that is using embedded file management.

In some cases, even after making the change to the File Writer IP address, some installations still don't proceed. In these cases I've seen a couple of solutions. In some instances the system will allow the completion of the upgrade to the core equipment, and not the update of the files on the SD Card. When this happens it is often possible to simply log in to Embedded File Management and upload the system files from there. If that doesn't work, however, the cause is usually a corrupted SD Card. This happens most often on systems that have been through a number of upgrades, or potentially if you've forgotten that you have to step up from any release below 8.1(65) to 8.1(65) or 9.0 prior to upgrading to the current release. When this happens the best plan is to pop out the SD Card, put it in your laptop, and recreate the SD Card. Once this is complete pop it back in to the system and push your backed up config (and any embedded voicemail files, if applicable) back to the system. Once this is complete you should be able to access the system just fine.

Server Edition and Application Server Upgrades

Server Edition and Application Server upgrades appear to take forever, frequently appearing to stop around the 92% complete mark. This has caused panic for so many of my colleagues over the years. The first time I encountered this I panicked and rebooted the server. Let me tell you, this is a mistake! Now I've learned a thing or two and I have found a better way to keep an eye on the progress than simply looking at that 92% for what seems like an eternity. Log in to the server as root and type the following command:

tail -f /var/log/yum.log

This command will continuously scroll the output of the YUM application. YUM, or the Yellowdog Updater, Modified, is the Linux program that the IP Office uses to manage the installation of software. The yum.log file will scroll frequently even if the Web Manager progress indicator hasn't moved. This should keep your mind at ease while you wait.

It is possible that the updater may fail. Avaya has documented issues with the upgrade failing, and has even written code into the update software to identify issues with YUM failing to complete the upgrade. If you see the error "yum process died before completing its job" you have experienced an issue with the /boot/ partition being full. This happens, again, on systems that have been upgraded multiple times. If your system has been upgraded to at least 9.1.7 you should not experience this issue. If you do have this issue after 9.1.7 engage Avaya support right away, and anticipate a rebuild. If you are at a release older than 9.1.7 there is a quick fix. Download the file UpgradeKernelFix_v2.zip from Avaya. This zip file contains a patch that will allow you to expand the /boot/ partition. Extract UpgradeKernelFix_v2.sh from the zip file and upload it to your server using WinSCP, or your favorite SFTP client. Browse to the location of the file as root and type chmod +x UpgradeKernelFix_v2.sh - this makes the file executable. Run the file with ./UpgradeKernelFix_v2.sh and you should be off to the races. Of course, you will have to start the upgrade again. This issue should only affect systems running on VMWare, however I wouldn't rule it out for bare metal servers.

I can not stress enough the importance of making a full backup before you begin. For an application server this means assessing the applications used and ensuring that all application data is backed up off the system before you begin. For systems using embedded voicemail this means ensuring that you save all the dynamic contents of the SD Card before you even think of starting.

Let me know if you've experienced any other errors, and if so, what is your resolution. I'll try to help out anyone who is stuck if I can!

The VoIP world is dominated by SIP lately. SIP is a standard that is defined by a number of RFCs but searching through here for answers to questions is ridiculously difficult. I would like to use this post to answer any SIP questions that I come across in my daily travels. If you have a question that has not been answered feel free to drop it in the comments. I'll do my very best to find an answer for you!

Q: What is the maximum size of a SIP packet?
A: The maximum allowed size is equal to the maximum size of a UDP packet, or 65,507 bytes (65,535B - 20 B IP Header -8 B UDP Header). Some software may not accept packets of this size. Often software will limit the packet size to 4096B.

Q: What is a SIP User Agent (UA)?
A: A User Agent refers to a component in the SIP communication between two devices. There are two types of User Agents: Client and Server. A UA Client (UAC) sends a SIP request and a UA Server (UAS) sends a response. Most of the time a SIP server or endpoint will act as both a UAC and a UAS, depending on the circumstance. A call may terminate to a phone in which case the SIP server is the UAC and the phone is the UAS. The phone may then place the call on hold or conference another user, at which point the phone sends the request and becomes the UAC.

Q: What is a B2BUA?
A: A B2BUA (Back to Back User Agent) is a device that receives a request from a UAC and forwards that request out to another device, acting initially as the UAS and as the second leg as a UAC. A B2BUA will remain in the middle of the conversation so that the endpoints do not communicate directly for signaling purposes. It is still possible to have a B2BUA with direct media path for RTP packets.

Q: What is the maximum speed for faxing with SIP?
A: Contrary to what most people believe, there is no difference in the maximum speed of a fax machine on analog or PRI versus SIP. The SIP standard doesn't care - this is a function of the codec negotiation. But that doesn't answer the real question here. When I'm setting up a PBX I always suggest the customer limit their fax speed to 14,400bps. The PBX will see the 14,400 speed (or lower) and will use the T.38 codec for faxing. Most phone systems will only allow T.38 if the PBX will be holding up the RTP (i.e. no direct media path) as the system will switch to T.38 when it detects the fax tones being sent from the originating fax machine. Modern fax machines (also known as Super G3 fax machines) support speeds of up to 38,400bps, although the realized throughput is often lower. When using a Super G3 fax machine the codec will negotiate to G.711. Network reliability is incredibly important when using Super G3 speeds. These machines are incredibly intolerant to jitter and packet loss.

The IP Office has a built-in DHCP server that can be configured to provide addresses for all devices or just for Avaya phones, however many companies have their own DHCP servers that they manage. The IP Office phones look for one of two DHCP Options for their information, either 176 or 242. Both of these options use similar formats.

Option 176 is used for legacy IP Office phones (4600 and 5600 series phones). Option 242 is used for 1600 and 9600 series phones. The DHCP option provides the IP Office address, the H.323 port number, the TFTP or HTTP server used, and (optionally) VLAN information.

xxx.xxx.xxx.xxx is the IP Address of your IP Office that the phones will use for registration, and yyyy is the port number (almost always 1719). The TFTP or HTTP server address is almost always the same as the IP Office address, however some deployments may use an external server to support additional simultaneous connections.

In a scenario where you have multiple servers in a resilient environment you can have multiple entries for MCIPADD - simply separate them with a comma:

With Option 242 you can specify a folder on the HTTP server that contains the files needed by the IP Phone using the HTTPDIR=path_to/files.

Keep in mind that there is a limit of 127 characters in a DHCP Offer. If the scope would exceed this you can use OPTION 66 to specify the TFTP Server for Option 176.

When using VLANs to separate voice and data traffic you need to ensure that the VLAN details are specified in the default VLAN:
L2Q=1 enables VLAN tagging.
L2QVLAN=xxx where xxx is the VLAN ID for your voice VLAN.
In this scenario you would have your options as follows:Default DHCP Offer:

OPTION 242 L2Q=1,L2QVLAN=200

Voice VLAN DHCP Offer:

OPTION 242 MCIPADD=192.168.42.1,MCIPORT=1719,HTTPSERVER=192.168.42.1

The IP Phones will pick up their VLAN from the default offer then request a new DHCP scope in the correct VLAN, at which point they will receive their configuration from the voice VLAN.

Today I had someone call me to say they were trying to create a personal directory entry in their IP Office for someone with an external number and and extension. I couldn't conceive of why there would be any problem with this until I learned that the Personal Directory only allows entry of keypad keys (0-9, *, #). Since none of the allowable entries will make the call pause I had to find a way to make this work.

After some thought about how I could make this work for my customer I came up with a plan. I would try to dial a short code that would make the call for me!

First I created the PD entry:

Then I create a corresponding Dial Direct short code with the number I have put into the PD:

Once I had followed these quick and easy steps I was able to make a call from my personal directory to an extension. I was surprised that Avaya hadn't allowed pauses in the directory but the IP Office always provides a way! It is not necessary to use the phone number, I simply used this method to ensure that I was able to track what numbers were being manipulated at a glance.
Make sure to include the dial prefix if it is expected in the ARS. If it is not needed in the ARS you don't need to include it in the short code.