Reducing the SIP Packet Size in VoIP
UDP Fragmentation Problems with SIP
We know that UDP is the preferred transport protocol for VoIP applications. This is because it doesn't incur the high overhead of TCP and in any case, we can afford to lose a couple of SIP packets here and there as long as the general stream comes in quickly and without breaks. Unfortunately, the maximum size of the UDP packet is restricted greatly compared to TCP and since SIP is not a standardized protocol, many vendors add in their own pieces of data which tend to expand the size of the UDP packet. This can cause the UDP packet to be split up which can cause problems at several levels. To start off with, not all devices or even providers can handle fragmented UDP packets which breaks down the SIP protocol.
Also, since UDP doesn't possess the necessary tools for enabling the resending of data, the chances of a fragment getting lost irrevocably is greater, thus spoiling the entire set of packets. In addition, the SIP client and the provider have to negotiate the codecs used to make the call and the SIP header can get bloated with all the details of the various codecs being sent. Because of all this, it is best to reduce the size of the SIP packet as much possible by various means.
Limited Codecs and Compact SIP Headers
One of the ways to reduce the size of an SIP header is to pare down the number of codecs which are available with the SIP client. If you go to the advanced settings of most modern clients, users can restrict the codecs that are available. Specially programs like CSIPSimple that are meant to work with a large number of SIP provider systems suffer from this drawback. An SIP client that is created specifically by your SIP provider on the other hand will obviously work more efficiently out-of-the-box.
Another option is to enable compact SIP headers which abbreviates some of the fields typically found in them. For example, "from" is replaced with "f", "To" with "t" etc. again, because of the non-standardization of SIP implementation, some providers may not support compact SIP headers and this option will need to be turned off in the appropriate program.
Problems like this give an indication of why VoIP can still sometimes be a messy application to set up. Until and unless everything is standardized, there will always be some settings and parameters which cause problems with certain devices and certain hosted PBX servers. But we're getting there. A consensus is slowly evolving around the major issues and it's not a stretch to believe that sometime in the near future SIP providers will be able to get their act together and coordinate their standards.