SIP Standard

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.


IP Office DHCP Scope

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.

The options look like this:

OPTION 176  MCIPADD=xxx.xxx.xxx.xxx,MCIPORT=yyyy,TFTPSERVER=zzz.zzz.zzz.zzzOPTION 242  MCIPADD=xxx.xxx.xxx.xxx,MCIPORT=yyyy,HTTPSERVER=zzz.zzz.zzz.zzz

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:
OPTION 242 MCIPADD=192.168.42.1,192.168.42.2,MCIPORT=1719,HTTPSERVER=192.168.42.1,192.168.42.2
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.


IP Office Personal Directory with pauses

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.


Network failures and the Dell R620

So we recently installed a Dell R620 server with IP Office Server Edition 9.1. While troubleshooting an unrelated issue we came up with a big problem: The device could no longer be reached on the network! Well that's a huge problem since we have IP phones and all the bells and whistles on this server. Avaya support wasn't able to resolve the issue because...guess what? They couldn't get into it remotely...

So we replaced the server and I took a look once we had it back in the lab. It turns out that the devices had been renamed. ETH0 switched with ETH2 and ETH1 switched with ETH3. By plugging in to Port 3 (which should have been ETH2) and enabling the port (#ip link set up) I was able to get connectivity right away. But how could this have happened, and what can I do to make it work with the correct network port? It turns out there is an issue with the way CentOS uses UDEV to create network interfaces. So how do you fix it? Well it's not too hard. I was able to make it work exactly as it did before by looking at a few files and changing one.

In the root folder there are four interesting files. They are ifcfg-eth0, ifcfg-eth1, ifcfg-eth2, and ifcfg-eth3. These files each contain a single line of text with the MAC address of the server:

HWADDR="b8:2a:72:dc:17:28"

Trust these files. They are the gospel. I was also able to find the MAC address of eth0 (Port 1) printed on the circuit board inside the server. The four addresses should be sequential, but keep in mind that they are sequential in HEXADECIMAL. So...29 does not go to 30, 29 goes to 2a.

So you may wonder, now that we have these MAC addresses, what are we going to do with them?

That's easy. Use your favourite text editor (I personally like NANO) to edit the file /etc/udev/rules.d/70-persistent-net.rules. You'll see your interfaces and, I bet, incorrect MAC addresses. Or at least MAC addresses that are not associated with the correct device name. Simply change the MAC addresses to the correct address for each device and you're on your way.

For example, change:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:2a:72:dc:17:2a", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
 to:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:2a:72:dc:17:28", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"