An issue that appears more and more frequently in my daily travails has to do with the growing number of IP-PBX implementations that can not reliably use UDP as a transport protocol.
First, the good news. Based on my own personal observations, deployments of IP-PBX equipment are seemingly on the rise, despite (or maybe because of) the tough economic climate. No doubt, this is partially because productivity-enhancing unified communications features are getting better, and there are a wide variety of very viable IP-PBX vendors from which to choose.
The bad news is that the growing feature list has introduced unexpected compatibility problems. The issue is that many modern SIP PBX makers put proprietary parameters into the SIP protocol headers. This extra content is used to define how calls are handled within the PBX environment. It can contain everything from XML code about which prompt to play, to snippets of audio needed for speech recognition. While this is allowed by the SIP protocol, a side effect is that the SIP header becomes larger, often exceeding the default 1500 byte maximum size for a UDP datagram packet. The result is that the SIP header becomes fragmented, spread across two or more packets.
Fragmented UDP packets can pose certain problems. Since UDP is a fire and forget protocol, there is no correction built into the the transport layer for dropped or delayed packets. This means that SIP endpoints must be smart enough to reassemble or otherwise compensate. And therein lies the problem.
It turns out that more than a few SIP implementations are not able to process fragmented SIP packets. In one extreme case (which I encountered today), a fragmented SIP INVITE message actually crashed a major vendor's SIP gateway. In other cases, packet fragments are either dropped or rejected. Obviously, this can cause havoc for IP PBX administrators.
One workaround is to use TCP instead of UDP. TCP allows for a greater packet size, and also incorporates error correction as part of the protocol. Some vendors (like Microsoft in its Office Communications Suite) have opted to support only TCP, even though the current SIP specification (RFC 3261) requires support for both. However, many older SIP implementations (those based on RFC 2543) do not support TCP at all because it was optional at the time. And, SIP implementors still consider UDP to be the least common denomiator for transport.
When you combine the packet fragmention issue with the lack of TCP support in older SIP implementations, it becomes increasingly likely that one will come across incompatible SIP implementations at the transport layer. Being aware of this added level of complexity in the SIP interoperability puzzle could save you valuable time in troubleshooting and diagnosis.
I am sure that the various vendors involved will get up to speed and either fix their handling of UDP fragmentation, or support TCP. In the meanwhile, think of this as just another growing pain along the road to an IP enabled world.
First, the good news. Based on my own personal observations, deployments of IP-PBX equipment are seemingly on the rise, despite (or maybe because of) the tough economic climate. No doubt, this is partially because productivity-enhancing unified communications features are getting better, and there are a wide variety of very viable IP-PBX vendors from which to choose.
The bad news is that the growing feature list has introduced unexpected compatibility problems. The issue is that many modern SIP PBX makers put proprietary parameters into the SIP protocol headers. This extra content is used to define how calls are handled within the PBX environment. It can contain everything from XML code about which prompt to play, to snippets of audio needed for speech recognition. While this is allowed by the SIP protocol, a side effect is that the SIP header becomes larger, often exceeding the default 1500 byte maximum size for a UDP datagram packet. The result is that the SIP header becomes fragmented, spread across two or more packets.
Fragmented UDP packets can pose certain problems. Since UDP is a fire and forget protocol, there is no correction built into the the transport layer for dropped or delayed packets. This means that SIP endpoints must be smart enough to reassemble or otherwise compensate. And therein lies the problem.
It turns out that more than a few SIP implementations are not able to process fragmented SIP packets. In one extreme case (which I encountered today), a fragmented SIP INVITE message actually crashed a major vendor's SIP gateway. In other cases, packet fragments are either dropped or rejected. Obviously, this can cause havoc for IP PBX administrators.
One workaround is to use TCP instead of UDP. TCP allows for a greater packet size, and also incorporates error correction as part of the protocol. Some vendors (like Microsoft in its Office Communications Suite) have opted to support only TCP, even though the current SIP specification (RFC 3261) requires support for both. However, many older SIP implementations (those based on RFC 2543) do not support TCP at all because it was optional at the time. And, SIP implementors still consider UDP to be the least common denomiator for transport.
When you combine the packet fragmention issue with the lack of TCP support in older SIP implementations, it becomes increasingly likely that one will come across incompatible SIP implementations at the transport layer. Being aware of this added level of complexity in the SIP interoperability puzzle could save you valuable time in troubleshooting and diagnosis.
I am sure that the various vendors involved will get up to speed and either fix their handling of UDP fragmentation, or support TCP. In the meanwhile, think of this as just another growing pain along the road to an IP enabled world.
Technorati
Del.icio.us
Slashdot
Digg
twitter
Leave a comment