How to get SIP working again

I have a SIP soft-phone set-up using Linphone as the client, which used to work, but stopped working at some point in the last few months.
Now, calls appear to connect OK, I can see when the recipient has answered the call, but I don’t get any audio.
On the IPFire firewall log, I’m seeing a DROP_INPUT from one of my provider’s RTP server IP addresses to UDP port 7078. This is the port number configured in Linphone as the Audio RTP UDP port.

Has this stopped working as a result of the deletion of ALG from IPFire? I don’t have any record of when I updated to 155 but it is possible that the timing is coincident.

If it is that, what do I need to do on IPFire to get Linphone working again? I don’t need to receive inbound calls, only make outbound ones.

Hello Andy!

What IPFire version are you currently using?

There have been a few issues with SIP (and VOIP) . I am not sure if it was solved yet.

You may want to look at these threads:
https://community.ipfire.org/search?q=SIP%20order%3Alatest
-or-
https://community.ipfire.org/search?q=voip%20order%3Alatest
-or-
https://community.ipfire.org/search?q=Google%20Meet%20order:latest
-or-
https://community.ipfire.org/search?expanded=true&q=Microsoft%20Team%20order:latest

I have not experienced the problems myself even though we use a few different services.

If you want to see a list of your Core Upgrades, run this from the Terminal / Console:

for logf in $(ls /var/log/messages* | sort -rV) ; do zgrep --color -ai "CORE UPGR: Upgrading from release" $logf ; done

It takes less than 60 seconds to run.

Hi,

while not having any experience with Linphones, here are my thoughts on your issue:

  • In general, enabling transport encryption (SIP over TLS and SRTP) is a good idea since it ensures no network equipment between you and your ISP can tamper with the traffic in any way.

  • If possible, try to switch to “symmetric RTP”, so the phone emits RTP packets from the same port as it would listen on for receiving packets. Dealing with stateful packet inspection (SPI), this reduces the risk of RTP packets being dropped mistakenly.

  • Quite a while ago, I had similar problems with a German VoIP ISP, which was using a bunch of IP addresses for their VoIP services. Unfortunately, and similar to your case, they did not kept track of which IP address my equipment called for registration - instead, they sent back SIP and RTP traffic arbitrarily from any of their IP addresses.
    Since a firewall cannot know this traffic is intended, it drops it. My “solution” was to scrape all the IP addresses they were using, and create firewall rules for permitting incoming SIP and RTP traffic from these IPs only (!!!), forwarding them to my VoIP device.

It is very important not to open up a SIP port to the entire internet, as it makes your network vulnerable for both technical hacking and spam calls.

Hope to have helped. :slight_smile:

Thanks, and best regards,
Peter Müller

1 Like

Thanks Jon and Peter for the suggestions.

From the log I see that I upgraded from 154 to 156 back in May, and I know Linphone was working after that, so the deletion of ALG can’t be the issue. I’m on 161 now.

I guess either something changed in an update of Linphone, or something changed on the provider’s side. They do have a pool of IP addresses so the situation you described, Peter, could apply. I did try setting up a port forwarding rule for the port I was seeing in the firewall logs, 7078, but it didn’t seem to solve it.

I did find some settings in Linphone that enabled it to work again though. Bizarrely, turning off encryption (previously I had it set to SRTP) resulted in the audio working again. Turning on ICE (Interactive Connectivity Establishment) also fixed it, and I can enable SRTP again with that, but audio quality seems reduced (clicks and pops). I can’t find any setting in Linphone for Symmetric RTP.

Anyway at least it works. Thanks again.

Hi,

glad to hear this wasn’t breaking things for once:slight_smile:

That port may be dynamic, so a different destination port will be used by the ISP for every call.

Interesting. If SRTP would not work with ICE, I’d suspect the ISP not to support it at all. However, your case looks like a faulty SRTP implementation on either the Linphone or your provider’s side…

You’re welcome. :slight_smile:

Thanks, and best regards,
Peter Müller