Disabling all SIP intelligence
-
There is no ALG, nothing to disable (assuming you aren't running siproxd), and the default 2.0 settings work in almost every circumstance with every provider. The only non-default setting that's needed on occasion is #2 here.
http://doc.pfsense.org/index.php/VoIP_ConfigurationOne nit: if you do not enable static port NAT, the RTP packets will tend to not get through (no audio inbound.)
Not true in the vast majority of cases, maybe some very rare, limited ones.
-
Maybe things have changed, but when I wasn't using static port some months back, what happened was pfsense was rewriting the RTP port numbers, so the remote media server was sending packets to the wrong port. No inbound audio. I freely admit to not being an expert on the different permutations of how different ITSP's do things, but this was my experience. If you are running asterisk on top of a modern TCP stack, there is no reason I can think of to not use static port for at least the RTP range of UDP ports, is there? I have changed providers recently (now using flowroute), so this might be worth revisiting. I will post results…
-
Should leave source port rewriting enabled for NAT purposes, greatly reduces the chance of a port collision.
I use flowroute for my home phone, it definitely works fine rewriting RTP's ports. We use a different provider using Asterisk as our business phones and all of us rewrite RTP with no issue. I've never seen that be an issue with Asterisk, or actually any PBX that uses standard SIP and RTP. Some proprietary VoIP implementations have issues with that.
-
I think it may have been freepbx.com (who I was with for a couple of years).
-
Chris, a question: when you use asterisk behind pfsense, are you using localnet/externhost or localnet/externip? I'm pretty sure I was and needed to. I can't find the reference now, but way back when, I saw a post where someone was explaining why this breaks sometimes and sometimes not (not the static port part, needing to rewrite the SIP headers). Had to do with how the remote end decides who to talk to; sometimes it goes by the SIP header and sometimes by who the remote host's WAN IP/port are - in the former case, you get no audio, in the latter it works…) I found that using externhost/localnet worked, except when the port number was rewritten, since in that case, the remote media server was sending audio to the pre-rewritten port, hence my use of static port. It gets even more confusing, since with some providers, the call treatment works differently depending on whether the call is made outgoing or incoming. I remember also trying siproxd and that didn't work - possibly for the same reason(s) I needed static port.
-
Sorry for the delay in coming back, thanks to BT for breaking my broadband… :)
To clarify, the scenario is that I have multiple phones inside pfsense and the sip hosting on the internet. I will test again but when I did a packet capture of the traffic passing out through pfsense I could see that the sip headers were being rewritten with the external wan ip address, replacing the originating LAN ip address
For us this matters as the hosted platform works strangely. Hence when I use a cable modem to nat instead it works fine, as the headers remain untouched.
Obviously I need the nat/pat to rewrite the ip but the sip headers need to remain untouched
Thanks, Chris
-
I don't think pfsense touches the SIP headers. Have you tried static port?
-
Chris, a question: when you use asterisk behind pfsense, are you using localnet/externhost or localnet/externip?
If it's NATed, yes you need nat=yes and externip defined.
To clarify, the scenario is that I have multiple phones inside pfsense and the sip hosting on the internet. I will test again but when I did a packet capture of the traffic passing out through pfsense I could see that the sip headers were being rewritten with the external wan ip address, replacing the originating LAN ip address
Unless you're running siproxd, it won't do that.
-
I was surprised that it did do it - I had been playing with siproxd but it was remove then. One way or another though these phones don't and never have worked when behind pfsense but work flawlessly behind anything basic and featureless like linksys.
I'll do a packet capture on a fresh install and report on the results. It might be posted from one of the guys I work with as he has all the kit at the moment and most importantly the phones themselves.Thanks
Chris
-
For the 3rd (and last) time, have you tried static port? Honestly, if you're not going to listen, it's hard to be motivated to help…
-
Sorry if something upset you, didn't mean it. I did say in the post above I would do some tests and get back to you…to be clear I will of course be trying that. I don't have the phones here so I can't test it immediately. I believe however I did try that but I have been working on this problem for 10-12 months and I can't remember exactly what I have done now.
Chris
-
Incidentally Dan note that my original question was not about hosting asterisk and not about the NAT of IPs, it was about phones and rewriting the SIP header, which causes issues with our hosted platform. As far as I understand from the docs, Static port is just releated to keeping the ports the same during NAT, which I made clear at the top was not an issue (as far as I can tell) - NAT has never been an issue for us and basic PAT (which is what cable/DSL modems do by default) changing source ports etc works absolutely fine.
I believe I understand NAT and PAT quite well on a general basis as I am CCNP and my day job is firewall based (but Cisco, Checkpoint etc and I can't get them to move to pfsense, though I try!) and I don't believe it to be a problem (unlike most SIP problems it seems!)