VOIP calls don't end

  • Hi everyone,

    Recently we have set up an VOIP environment.
    We installed local VOIP hardware in our company.

    We use desktop phones, combined with mobile phones that are registered in our VOIP (believe it's called PBX?), so these mobile phones can use the VOIP environment. We use Avaya desktop phones and Avaya IPO 500 V2 unit VOIP System.

    Everything seems to work, we got voice on both sides.
    Calls aren't unexpectedly ended etc.
    The only problem we have, is that the call isn't ended on the DESKTOP phone, when an EXERNAL or MOBILE user ends te call.
    The desktop user needs to end the call on his/her phone manually or else it will stay 'connected'.

    If the desktop user ends the call, then on both mobile and desktop the call is ended.

    What could be te cause of this?

    We're using PFsense 2.4.4-release-p3

  • Did you open the SIP and RTP ports range like 5060 and 10000-20000 in PFsense .

  • Yes I did.
    I opened port 5060, 10000:20000 and 46750:50750

    It seems that PFSense is altering something in the headers? (as I've been told as probably the issue)

  • We just noticed another problem.
    It seems that if an mobile user wants to call with the company number, they dial the 'incalling' number, with an extension behind it.
    so for example +31 123 456789,201
    When they dial the first number, don't get the 'pause', it just dials and they keep hearing a double peep for 30 seconds. Then the connections is ended. So they aren't able to call with the company number.

    Perhaps this triggers anyone for a solution?

    these instructions were followed:

  • pfsense does not alter headers.

    Are you using any packages?

    Are you using 1:1 NAT?

    if not are you using static port?

  • I'm not using any packages.
    I'm not using 1:1 NAT
    An static port for what? The Avaya PBX? Or something else?
    I checked the static port in outbound as described in this link:

    Below some screenshots of the settings I've entered.
    I didn't make any further changes. Perhaps I'm doing something wrong?


    The Voip Ports

    Settings in the outbound:

  • Firewall rules are processed for traffic that enters an interface. (look at your interface and point your finger at it.. that direction)

    In order for traffic to get to your PBX interface from outside you need rules on your WAN pointed at (or destination of) your PBX address. (its LAN address).

    On your PBX interface (the LAN your PBX is on) you need a rule with your PBX net as the source and "any" as its destination.

    I believe from a quick look at your pictures above you are using "aliases"..??.. I do not personally so Im not familiar.

    In a rule above you show a "destination" address starting with 31.x.x.x That is obviously a public address of some kind. If that address is on your premises here (i.e. your WAN address) that is wrong. Your public IP WAN address should probably never show up in any firewall rules for any purpose I can think of other than allowing access to your firewall from an outside source (and even then it should probably be "destination" "WAN address" on your WAN interface. )

  • @chpalmer said in VOIP calls don't end:

    PBX net a

    Thanks for your reply.
    Let's see if I understand it correctly.

    I need to create a NAT Port Forward rule looking like this:

    Interface: The Interface where the PBX is located on (192.xxx.xxx.xxx)
    Protocol TCP/UDP
    Source address: same as the above mentioned interface (/ or should this be the IP address of the PBX itself (192.xxx.xxx.17?)
    Source ports: * (all)
    destination address: * (all)
    destination Ports: VOIP_Ports (5060, 10000:20000, 46750:50750)
    NAT IP: 192.xxx.xxx.17 (local ip of the PBX)
    NAT Ports: VOIP_Ports (5060, 10000:20000, 46750:50750)


    Also my rules with the public IP should be changed:
    Interface: fiberglass interface, containing my public IP
    Protocol: TCP/UDP
    Source address: SIPTrunk (containing few IP-addresses)
    Source Ports: * (all)
    Dest. address: The Lan on which the PBX is (192.xxx.xxx.xxx)
    Dest. Ports: VOIP_Ports (5060, 10000:20000, 46750:50750)
    NAT IP: 192.xxx.xxx.17 (Local IP of the PBX)
    NAT Ports: VOIP_Ports (5060, 10000:20000, 46750:50750)


  • @WillemC

    I actually said nothing about port forwarding. I only mentioned firewall rules.

    On your screen shots.. You do not have to hide addresses on your LAN from public view. Just hide your public addresses.

    Usually VOIP is all UDP with a few exceptions. It does not hurt to add TCP however if you trust your external addresses.

    On a port forward your source is "Any" unless you want to tie things down to specific users and know those addresses.

    Only you know what ports you have specified. 5060-5061 is standard usually but this is not set in stone.

    What RTP are you using? Usually you do not need 5000 ports open for that.

  • My bad :)

    So in the firewall rules, on the local LAN, I create a rule like this:
    Protocol: IPv4 TCP/UDP
    Source: localLan
    Port : *
    Destination: *
    Port: *
    Gateway: *
    Queue: none

    In my WAN firewall rules I have a rule like this:

    edit: regarding the ports I mentioned before, these were given to me as the correct ports by the company who installed the VOIP PBX.

  • @WillemC

    On your WAN rule.. what is "Siptrunk" and what does it relate to?

    Alias? Just to reiterate.. I don't do aliases myself so Im unfamiliar with how they work. Id have to tinker.

    That seems to be the source? Does it equal your providers servers?

  • 192.9.x.x is not a private IP address and should not be used as though. That is probably why its not working.

    This is a routable (reported unreachable right now) address and their servers will treat it as such. You break stuff when you don't follow the rules.


    Use addresses from the range below.

  • For nearly a year now, we have multichannel numbers and 800 numbers from Hottelecom. When it was connected, it was a problem, but not significant, so the support service instantly decided everything. Have you contacted the support team?

Log in to reply