SIP/Voip - callers can hear me, but I can't hear them

politicorific

Just today I switched my router from m0n0wall to pfsense in the hope that my trixbox setup would finally work. That is until I found out that the sip proxy support has been removed.

I've signed up with a free incoming number from IPKALL. I have a dynamic IP from my provider, I've setup a dynamic dns to point back at my home network.

Here is what I've setup so far:

NAT:
If WAN, Proto TCP/UDP, ext. port range 5060-5090, NAT IP TRIXBOX IP, Internal port range 5060-5090

Firewall rules
Proto TCP/IP, Source *, Port *, Destination TRIXBOX IP, Port 5060, Gateway *

I have setup trixbox to use ports 18000-19000 for RTP, but I am faced with 2 problems:

I cannot hear the incoming caller, but they can hear me - both my asterisk on hold music and my voice
My X-Lite shows "hung up" after 20 seconds, but my cell phone does not register a hang up

Is there a tutorial on what I must do in order to get this working? It's been 5 years since I studied for a CCNA(but never took the exam, it was a blow off course in high school) and the source/destination stuff is a little confusing. At least I'm already miles beyond what I accomplished in m0n0wall.

sullrich

pfSense by defaults scrambles the source port. Search the forum for static-port or "static port".

politicorific

@sullrich:

pfSense by defaults scrambles the source port. Search the forum for static-port or "static port".

I found this:
http://forum.pfsense.org/index.php/topic,3724.0.html

which I followed, I figured I should attach a couple screenshots

According to what came through on the "states" pages, it appears 5060 is working

udp x.x.x.x:5060 -> y.y.y.y:5060 MULTIPLE:MULTIPLE
where x is the external voip provider and y is my trixbox/asterisk server

mainly because this call
udp x.x.x.x:16420 <- y.y.y.y:18364 NO_TRAFFIC:SINGLE

and another made later:

udp x.x.x.x:16406 <- y.y.y.y:18472

there were no other states with the IPs of the voip provider

Where have I made an error?

nat.PNG_thumb

rules.PNG_thumb

sullrich

Instead of relying on ports, rely on the internal ip. Remove the ports and it should setup static-port entries for any traffic leaving the device. Chances are another port is in use and it is not being applied to the static-port entry.

politicorific

@sullrich:

Instead of relying on ports, rely on the internal ip. Remove the ports and it should setup static-port entries for any traffic leaving the device. Chances are another port is in use and it is not being applied to the static-port entry.

Sorry for being thick, but I don't quite follow. I should delete my firewall rules and nat port forwarding rules? This should leave just the single outbound advanced nat rule? What should this look like?

Without the single 5060 port forwarded NAT rule the call doesn't ring through. This is very strange, as most people with this problem have trouble getting themselves heard from behind pf sense, whereas I can't get external voice through pf sense.

cmb

I would suggest you use 1.2b1, as it automatically fixes this if you have Advanced Outbound NAT disabled.

Rip7id3

Verify 1.2 beta then create an Advanced Outbound NAT rule for your internal SIP device on bit range 32, then check the box 'static port' so that connectivity for any port on the internal device is not nat-ed out and therefore changed when coming in as well.

politicorific

@cmb:

I would suggest you use 1.2b1, as it automatically fixes this if you have Advanced Outbound NAT disabled.

I've been using 1.2b1 from the start. It still does not work with Advanced Outbound NAT disabled or Automatic outbound NAT rule generation (IPSEC passthrough).

@Rip7id3:

Verify 1.2 beta then create an Advanced Outbound NAT rule for your internal SIP device on bit range 32, then check the box 'static port' so that connectivity for any port on the internal device is not nat-ed out and therefore changed when coming in as well.

Have I not already done that? A faq, or some images, like the ones I've provided would be most helpful, I have used the search function, but all I find are references to other posters being told to search. I've also tried removing the port 5060 rule, but that makes the call go to my provider's voicemail system.

As a test I setup my asterisk server to automatically send the call to voicemail and tried to record a message - the message is completely blank - asterisk compresses it down so that there's a fraction of a second of silence and then I get the menu options to "repeat, delete, etc"

1.2-beta-1.PNG
1.2-beta-1.PNG_thumb

cmb

Disable Advanced Outbound NAT, make sure changes are applied, and go to a shell and run:
grep 5060 /tmp/rules.debug

see anything?

politicorific

@cmb:

Disable Advanced Outbound NAT, make sure changes are applied, and go to a shell and run:
grep 5060 /tmp/rules.debug

see anything?

Just to be safe I reset the system to factory defaults, changing only the password of the router and the internal IP address scheme 192.168.1.1 to 192.168.0.1
Once again I tried calling on default, with advanced outbound nat disabled and the call was not connected from my sip provider to my asterisk server.

without any rules being set I get this output from the shell:

nat on $wan from 192.168.0.0/25 port 5060 to any port 5060 -> (xl1) port 5060

with port 5060 being forwarded I get the following:

nat on $wan from 192.168.0.0/25 port 5060 to any port 5060 -> (xl1) port 5060
rdr on xl1 proto { tcp udp } from any to <my ip="">port { 5060 } -> 192.168.0.12
pass in quick on $wan proto {tcp udp } from any to { 192.168.0.12 } port = 5060
keep state label "USER_RULE: NAT "

I actually did the 2nd step first, then the first step (with 2 fresh factory defaults in between). Right now my software has only been changed the tad bit I've mentioned above.

The states table shows it connecting just fine through 5060, but the calls are not sent from my sip provider. I have it setup to timeout after 30 seconds.</my>

politicorific

Good news

I tried a friend's SIP provider and it worked fine. Even without anything in the rules/nat it worked, but took a couple more rings to go through(could be a fluke)

So disregard all of the above, I guess IPKALL is just junk, I'll have to find another provider.

Thanks for your help, but I'm going to chalk this up to being beyond my control.

cmb

It should work fine with 1.2b1 without any modification - as you see in your rules.debug output there, you have the NAT passthrough that's automatically generated.

Definitely something out of your control and unrelated to pfsense.