With the exception of perhaps Frank Sinatra’s voice, nothing in life is perfect. This is especially true for those of us in the software business. Of course, if the developers got it right the very first time, people like me would be quickly out of work. My job depends upon problems to fix and next releases to tout.
Even here in the land of SIP, I’ve seen lots of problems. Most were silly human tricks, but every so often a bonafide problem was uncovered. In the end, though, a problem is a problem and it doesn’t matter what caused it. What matters is how quickly it is fixed.
Over the next several paragraphs, I would like to document a few of the troubles I’ve come across in the recent past. Thankfully, all were fairly easy to solve once I figured out what was happening. I hope you find them useful.
You can’t put a round peg into a square hole and neither can you send UDP to a SIP entity that only accepts TCP. This, of course, is true with all potential mismatches. UDP servers want UDP. TCP servers want TCP. TLS servers want TLS.
Depending on the SIP components involved, you may not get an obvious error message when a protocol mismatch is encountered. In one case, the mismatch was found only by looking at how the SIP entity link was configured in Session Manager and how the SIP entity itself was configured on its maintenance console. From the outside, all I saw was that sessions could not be established. There were no 4xx or 5xx response messages to clue me into as to what was occurring.
The lesson here is to be aware. Don’t assume that something was configured correctly. Big problems are often due to fat fingers.
A second case of protocol mismatch actually generated a response message. Here, the customer was trying to get their Avaya Communication Manager to call a Polycom Distributed Media Application (DMA). When the call was placed, a 407 Authentication Required response was returned by the Polycom unit. This generally means that the INVITE needs to be resent along with encrypted credentials, but those credentials were unknown. What I eventually determined was that if we established the call using TLS, the Polycom unit was perfectly happy to accept the INVITE. It got the security it wanted with TLS without having to prompt for a password.
Too Much of a Good Thing
Another Polycom integration problem had me scratching my head for a while. In this case, a call was made to a Polycom conference bridge. The call was answered and after some time the bridge sent a re-INVITE with new SDP. This INVITE caused the server to return a 488 Not Acceptable Here (SDP Fault) response.
What baffled me was that the SDP contained plenty of acceptable codecs such as G.711, G.729, and G.722. However, there were also a slew of other lesser known codecs listed in the media description. In fact, there were 21 codes plus an entry for RFC 2833. So, while this was technically correct, the server’s SIP stack was not happy with such a large number of codecs and refused to accept the new INVITE.
The fix was to configure the Polycom bridge to not offer such a large number of codecs. This wasn’t the ideal resolution, but it worked and sometimes that’s good enough. Those extra codecs weren’t going to ever be used, anyway.
For a related article, please see, How to Debug SIP.
No Shirt, No Shoes, No Quality of Service
Voice over IP has come a long way since my original involvement back in the late 1990’s. Protocols have matured. Feature parity with older systems has been nearly reached. Reliability has gone up and costs have come down. However, none of that matters if phone calls sound awful and videos look shaky. Put another way, none of that matters if you send real-time data across a network not configured for quality of service (QoS) and expect that voice calls won’t get overrun by employees who use the company LAN to download movies.
My biggest run-in with this involved a contact center that had a branch office in Argentina. The agent functionality and call routing worked flawlessly, but people constantly complained about poor voice quality. The WAN provider (who shall remain nameless) assured me that Qos had been applied. However, a little spent time playing Wireshark detective proved that it wasn’t.
In the diagram below, note that Differential Services Field in the IP header is 0 (zero). This means that this RTP packet was not marked for QoS and subsequently will not be prioritized higher than any other data on the LAN/WAN. For voice and video, it needs to be set to 46 to invoke expedited forwarding.
It’s essential to realize that QoS is only present if every component in the RTP path is QoS enabled. One misconfigured router or switch and it’s bye-bye QoS. Thankfully, we were able to find the bad router, configure it properly, and complaints about voice quality went away.
To understand more about QoS, please see my article, No Shirt, No Shoes, No Quality of Service.
Even though perfection sounds very appealing, I have a mortgage to pay and a retirement that is woefully underfunded. So, until I am financially secure, keep those silly human tricks and software bugs coming. They add some excitement to my day and greenbacks to my bank account.
I proudly wear the sign, “Will fix SIP for food.”