From the “While I’m thinking about it” department, with help from the “maybe this will be useful for someone else” division.
I’d added a Analog Telephone Adaptor (ATA) to my home Asterisk system a while ago, but hadn’t really gotten a chance to work on it. About six months ago, I realized that it was misconfigured: when I received calls (which was 95% of the use, as it turned out) audio was fine, but I couldn’t initiate calls with it and get audio.
I realized this because I hadn’t been using Asterisk as my sole voice service, and so cursory testing of the ATA didn’t expose the problem – calls to it on my own network worked fine, so I assumed initiating calls would, too.
I thought about all the Fun with NAT that we always have to deal with, and assumed that was the issue. As is so often the case, ran off in that direction with no solution. Looked at the configurations, and everything there looked okay. Turned directmedia off, so that Asterisk would remain in the media stream, but still no audio. On the other hand, this ruled out NAT issues, didn’t it? And I’d never had NAT issues with Asterisk, even though I never actually modified the firewall on that host to open ports for RTP.
My Polycom IP550 (always) worked. Great. And the ATA didn’t. Looking at the network traffic, I saw that call setup looked pretty similar between the two devices… but then I noticed something interesting, that the ATA would get “destination unreachable/host administratively prohibited” replies from Asterisk with RTP.
I dug deeper, and noticed that the first RTP packets when using the IP550 were from the Asterisk server to the IP550, while with the ATA the audio started with the ATA – but there were those unreachable rejects, and no audio at all the other direction.
Stop reading here if this starts to make sense to you – once I put this all together, I started to come up with the answer.
I never had to open the RTP ports on the Asterisk server, because it turns out the IP550 was configured with progressinband=yes. (There was a note in my config that this was suggested by Polycom). Because I hadn’t really looked into it (and it was only suggested by Polycom), I never thought too much about it. But it’s the key, when running Asterisk on a host with a firewall: rather than having to adjust the firewall to manually open ports for RTP, progressinband has Asterisk generate audio to indicate call progress back to the terminal, which means that the Asterisk server “talks first” (starts sending from the negotiated port using RTP). This means that Asterisk effectively opens the port for RTP bidirectional traffic, and thus obviates the need for the firewall to do so.
It had nothing to do with NAT, but was still a firewall issue. I run firewalls on internal hosts – I think it’s just good practice. And I have to be honest: I figured all this out because when I did open ports for RTP, the ATA started working. That was what I needed to know to figure out the rest of it.
I haven’t yet figured out the drawbacks, if any, to progressinband, but in this case I’m happy to be through this particular issue. This is one of those occasions where a lot of work – many blind alleys – led, eventually to a fix that’s brilliantly obvious once you know it. That’s how life is in technology, though.
KMP on Technology 