All seemed straightforward: a VMWare appliance, a few strategic port-forwards at the ISP firewall, bit of config in the PBX, job done.
\n<\/p>\n
So it should have been, as we were using people to install and configure the SBC, as at that point, I’d not had to troubleshoot SIP and had only vague ideas of what was involved, but hey, we’re paying experts here, huh? We had a list of ports to open, all looking good.<\/p>\n
Except, it didn’t work. Phones could register, and make calls, but no audio would pass.<\/p>\n
We were asked to get SIP Helper and SIP ALG disabled on the Fortinet Firewalls, and we did. At this point, things got a bit random: the PBX guys wanted more and more ports opening, we could see UDP packets hitting the SBC and nothing getting done with them. The SBC was rebuilt, more port opens were requested.<\/p>\n
[Screech of brakes]<\/p>\n
It’s now feeling like randomly changing things blindly and hoping it works. Time to read up on what SIP actually does.<\/p>\n
A SIP phone call, as nicely explained by Giampaolo Tucci here<\/a> and here<\/a> is very much two things: SIP actually does the call setup and control; the actual audio in the call is entirely separate and uses RTP, an application-layer protocol over UDP. The RTP can take a different path; in fact in some implementations, two phone handsets will talk to each other peer-to-peer, while the signalling traffic goes back and forth to the PBX.<\/p>\n A key part is that when the call is setup, the two ends of the conversation send an instruction on what IP address and port to send audio on. This is why one-way speech or no speech is a common problem, and also why firewalls have so-called “helpers”, because if the two ends are unaware of NAT<\/a> taking place, the stream might go to the wrong place.<\/p>\n We didn’t have that: we could see stuff arriving at the SBC, but being ignored: Our SBC should handle all that NAT-traversing stuff, so why is it ignoring the traffic?<\/p>\n Part of the negotiation sends a SIP attribute:<\/p>\n Where XXXX is the UDP port to send the stream to, and the other stuff is the details of the stream.<\/p>\n Time for the last refuge of the desperate: packet captures. I’m fortunate here that my home router runs OpenWRT<\/a>, so you can capture there, and the SBC does that too.<\/p>\n So, here is what we had:<\/p>\n Time to get the captures out and fire up Wireshark<\/a>, the kind of tool you’d have paid thousands for in the 90s, and not had the level of diagnosis. You can view the call setup conversation and see what the call setup is actually doing.<\/p>\n Pulling up the traces side by side revealed the packets getting mangled en route: the port numbers were altered, the Here’s the “same” packet, either end of the trace (the RH side being at my house, the LH at work). This is a part of the RTP stream, rather than the call setup.<\/p>\n The packets are being altered!<\/strong> Not just address-wise, for NAT, but the actual data is being altered. in the capture at my house, you can capture the audio and play it, but the other end doesn’t even get recognised as RTP.<\/p>\n Turns out that as well as SIP helpers, the Fortinet has a VoIP session-helper, which is trying and failing to help. It’s rewriting traffic in transit, transcoding ports instead of just passing it, like an older, simpler device would. Like so many things when computers try to be helpful, it’s confusing and gets in the way.<\/p>\n The answer? Ignore the voice guys clamouring for more open ports, which wouldn’t have worked and exposed more of the network. Present the ISP with the evidence, including full packet captures, and let them discover the additional helper and turn the damned thing off \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":" The ongoing Covid situation means I’m still working at home, and now there’s demands for more colleagues to be able to work more normally from home too: a big hole in this was answering phones. I’ve worked with IP telephony a long time: since around 2004 in fact, and we’ve had the ability to do … Continue reading Not Helpful<\/span> m=audio XXXX RTP\/AVP 8 0 96 98 99 97<\/code><\/p>\n![\"\"](\"http:\/\/www.piglet-net.net\/pigblog\/images\/\/network-300x152.jpeg\")
<\/a>m=audio<\/code> field was being altered too.<\/p>\n![\"\"](\"http:\/\/www.piglet-net.net\/pigblog\/images\/\/Untitled-2-300x169.png\")
<\/a>