Ok I don't know why but when testing it this weekend it was working. I did not change anything neither did I reinstall and fresh setup.

Would this have to do with the static routing that was setup previously but the device it was pointing to was removed the same day it was setup till recently when the client went over to the new system and was installed again. I mean it makes sens that the pbx server was speaking to the firewall and the firewall was pointing to a device on the network that was not available.
NAT is now disabled and siproxd is kinda setup.

I'll arrange to test the DNS rebinding check to disable and the preferred work around and the same for Browser HTTP_REFERER enforcement and get back if it works now. Though the client registration check for the App was an issue even before static routing was setup.

Please let me know if there is clarity needed.

@viragomann Thanks, I adjusted the source address and mask to match my VoIP setup and now everything works!

Yes, you could certainly route between the firewalls. But you need to use a separate transport subnet between the two firewall interfaces and then add gateways and static routes between them.
That way you avoid asymmetric routing and can properly filter traffic at both ends.

If they have separate ISP uplinks you can also setup each as a failover for the other.

Steve

Sieht du denn Anfragen von der Fritz kommen?
Du kannst ja einfach ein Capture erstellen mit der IP der Fritz als Filter, dann hast du recht wenig anderes Zeugs drin.

@danievr said in Current pfSense (through to at least 21.05.2), SIP phone behind firewall, incoming call audio cuts out after 25-30 minutes, how to fix?:

@tea Have you fixed it? Things you could try: NAT keepalive of 15 seconds; Register Expires 30 secs; If supported, use TCP instead of UDP; If your calls are proxied through your provider's servers, they might terminate the call based on policy. dslreports.com has a lot of info on VOIP.

It turns out that this most likely was something in the interaction between the particular VoIP phone and the particular IP telephony provider through which I received most of my incoming calls.

For reasons unrelated to this issue, I ended up needing to switch VoIP providers. Having made the minimum changes necessary to connect to the new provider (essentially server and authentication details), the problem seems to have disappeared.

I wish I knew what the actual problem was, but at least it's working for me now.

@djohnson
This is a late reply but it may assist someone else in future.
The VOIP audio traffic (RTP) require separate UDP ports to be open. The exact range will vary depending on your VoIP system.

Hence, if the RTP ports are not open, you can experience a "working" system, but with a complete lack of audio.

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?

https://forum.netgate.com/topic/21817/recomendaciones-al-postear

https://docs.netgate.com/pfsense/en/latest/search.html?q=voip&check_keywords=yes&area=default

https://docs.netgate.com/pfsense/en/latest/search.html?q=sip&check_keywords=yes&area=default#

Bei mir funktioniert es inzwischen auch wie beschreiben. Leitung bleibt auch beim telefonieren stabil. Ich kann von meinem VOIP Telefon hinter pfSense nach aussen Telefonieren, und theoretisch auch "rein". Allerdings ist das nur für ca. 5 Minuten möglich (nach dem letzten Telefonat nach aussen). Das gleiche passiert, wenn ich mit meinem DECT Telefon (das direkt an der FB angemeldet ist) das VOIP Telefon Intern anrufe.

Ich vermute das es irgend ein NAT Timeout ist?

Hey @Derelict Thanks for the ideas. I've managed to find the issue, and it was an equipment problem on our ISP side.

I ran some packet captures on both the internal VoIP VLAN, and the external SBC interface(our phone comes in over the same fiber asour IP, but on a separate interface on the demarcation unit(T-340)), found a lot of dropped packets, moved onto our WAN switch, and saw that there was an EXCESSIVE amount of Tx/Rx errors and collisions on the demarcation interface. When I dug into the interface itself, found that it was only negotiating at half-duplex, which would explain the issues. When I went back through my old config files for the SG-8860, I found that I had to force it into full-duplex mode as the T-340 for some reason will not auto-negotiate to full-duplex, but if I force my side to full, it works just fine, and not a single error since.

Thanks again for chiming in.

@pet_nie

Na, das freut doch. :)

Die Anzeige der Rufnummer ist von Anbieter zu Anbieter unterschiedlich und wird in der Fritzbox korrigiert, wenn du dort auch Telekom hinterlegst. Bei "anderm Anbieter" passiert das nicht bzw. du mußt das manuell machen. im ip-phone-forum ist da einiges zu finden.

Gruß
pfadmin

Ich habe nun meine Konfiguration auf folgende Einstellung geändert:

bb37f9fa-dbac-41ca-b16a-aac46085cae5-grafik.png

Das scheint notwendig zu sein, da die Telekom für die IP-Telefonie in Zukunft nur noch DNS-SRV/NAPTR zulässt und nicht mehr die Registrierung über den Port 5060/5061 direkt per UDP oder TLS.