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.
Protocol Mismatches
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.
Still Employed
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.”
Tao, Zen, and Tomorrow 
Reblogged this on Dirigeant.societe.com.
Can you offer some assistance with trying to narrow down the cause for why our OneX CES 6.2.2 users randomly get Callback Failure messages and then after 24hours the issue goes away? Avaya support is actively working on SR to resolve the issue, but I would like to better understand the cause for the Callback Failed message so that I can make sure we come up with a permanent fix instead of having to worry the problem showing back up.
Hi Andrew! I am suffering an issue that’s starting to be quite painful and it seems something in this article points to the correct direction. I am trying to have my Avaya 9611G to talk to my Asterisk PBX using SIP over UDP.
As described in many places in this blog, my PBX challenges the REGISTER request send upon, but the phone never seems to react accordingly sending the encoded credentials, so I am wondering if there is a protocol mismatch. Do you think I could overcome this issue by using TLS instead of UDP.
Also it seems the Via header of the request is a bit odd, given the IP of the sender (the telephone is marked as 0.0.0.0).
Via: SIP/2.0/UDP 0.0.0.0;branch=z9hG4bK1_386d62f65b8f11e76h6d3gl6395h1v62t4q1zv1g304e5l14_R30020.0.0.0
I am quite confused as I don’t really know if my problem is being caused by a protocol mismatch or just because the config on my telephone is generating an incorrect Via header.
Did you read this? https://andrewjprokop.wordpress.com/2014/03/03/the-steps-involved-in-booting-an-avaya-sip-telephone/
That is a nasty via header and will ultimately cause you problems.
TLS may help fix your problem, but it may not. Good luck!
I have actually read that article and the following:
https://andrewjprokop.wordpress.com/2013/10/11/proving-it-with-sip-authentication/
which has helped me understand that REGISTER requests will be challenged by the PBX and then the telephone, as you describe in your article, should be resending the encrypted credentials and also increment the CSeq value.
In my case that is not happening. The phone is resending the REGISTER request without the Authorization header and the CSeq header value remains the same, and also with the very funny Via header.
Are you aware if there is extra configuration that needs to be done on Avaya phones in order to make them comply with the authentication sequence and/or populate correctly the Via headers?
Once again thanks for your help!
Are you receiving a 401 response for the first REGISTER?
I wonder if the Via problem has to do with how the phone is getting its IP address.
I am indeed receiving the 401, from the first REGISTER. I set the IP of the phone statically using the CRAFT procedure, so there was no DHCP involved.
On the meantime, I found in one of the support pages of Avaya that UDP is not a supported transport protocol on their SIP 6.X versions, which happens to be the one I am using.
https://support.avaya.com/public/index?page=content&id=SOLN259797&group=UG_PUBLIC
Just for the reference of anyone coming across this issue in the future. My issue was fixing by using TCP as transport protocol, and as soon I enabled this, the phone was able to register, make and receive calls.
UDP is not supported in any of the SIP 6.X firmware releases for Avaya phones, where as in previous releases it was just “Not Recommended” even though supported.
Thanks a lot for your help Andrew!
Just for the reference of anyone coming across this issue in the future. My issue was fixing by using TCP as transport protocol, and as soon I enabled this, the phone was able to register, make and receive calls.Voip Full Form In Computer
Hi Andrew,
I’m looking for some help if possible, can you advise where a SDP IP field is sent from? We have an issue where a 3CX phone system is intermittently sending no SDP IP back to the SIP trunk and therefore the calls fail. Is this field sent from the phone system, network on site or SIP trunk?
Many thanks,
Jemma
Is the phone system applying late media? In that case, the SDP will not show up until the ACK.