VOIP phones problem

Hello everyone,

I have a problem with some VOIP phones.

I have a server with IPFire 2.29 (x86_64) - Core Update 196 installed and three network cards.

The first (red) is connected to the router, the second (green) is 192.168.2.x and the third (blue) is 192.138.3.x.

The Green network accesses the Blue network and vice versa.

A VOIP switchboard is installed on the Green network and, in addition to all the telephones installed on the same network, there are two telephones installed on the Blue network.

These two telephones are correctly registered by the switchboard and can call telephones on the Green network without any problems, but there is no sound.

In practice, it is as if the microphone is not working.

Someone told me that it might be the SIP-ALG protocol that needs to be disabled, but I do not know how to do this.

Please help me.

Hi,
I had a similar problem. In my case, it was a port and QOS issue.
But in my case, the PBX was outside the network. I use it to have an Italian geographic number when I’m abroad.

Hallo @essecitech

Welcome to the IPFire community.

It can’t be due to the SIP-ALG as that and other Application Layer Gateways were removed from IPFire back in Core Update 155 in March 2021.

I read that too.
So what could be the problem?

On that I can’t help you as I don’t and have never used VOIP so have zero experience with it.

However there are other users who have so hopefully they will be able to help.

Maybe set up a

tail -f /var/log/messages

in a console or ssh terminal and then try the VOIP and when you have the problems see if there is anything in the tailed log that might give a clue.

Mmmh, I don’t know if that’s the right way to go.

Gentlemen,

You must should take into account that voip requires two connections: sip (registration) and rtp (sound). And take into account there is srtp (encoded rtp), too. srtp may need to exchange certificates from phone and voip board both ways.
You should prefer srtp to prevent listening to phone-calls using wireshark or something else.

I.
Sip often uses udp and port 5060-5063. You'll have to check this in the docs of your voip-board. It could be tcp-protocol and different ports.


Then try to put your voip-Board out of your green net and behave as if its ip-address was "firewall blue" using firewall rules:

source: (ip of voip-board)
Source-NAT: new source-ip-address: firewall blue.
protocol: udp(?), target port 5060-5063(?).

You may not need port 5060-5063 but one or two of these ports. Maybe your board needs one individual port to reach each individual phone. The port may be reserved for some time, like a lease time in dhcp.


And you have to allow the other way round

source (blue ip of phone)
destination nat firewall blue
host: blue ip of phone
protocol: udp(?), target port 5060-5063(?).

Some voip boards use different ports / protocols for traffic concerning phones and concerning phone provider. On some voip boards you are allowed to change these params.


In fact you take your phone out of your blue net and behave as firewall blue using firewall rules.
Let the devices match on firewall's blues ip-address.


II.

rtp often uses ports in the range of udp 49100-50500. So you have to set up firewall rules

as before.

III.

If you like, you can put your phone out of blue into green instead:

source: phone’s blue ip

destination net firewall green

target host fire voip board

protocoll udp, port 5080 (example internal phones)

And the other way round:

voip board’s ip destination nat firewall green

protocoll udp source port 5080.

… and same to match voip board and phone on firewall green’s ip to exchange sound in rpt protocol.

IV.

Don’t forget DNS. Maybe it’s enough to setup rules like:

source: standard network green

destination net: firewall-interface automatic

target: firewall all

ports 853 and 53 tcp and udp.

Don’t forget loopback source 127.0.0.1, target firewall green and firewall blue

And the other way:

source standard network green

destination net firewall automatic.

target firewall all.

ports 853 and 53 tcp and udp.

VI.

Maybe there is one of the network-admins in the forum to simplify may examples or give so hints about security improvement.

VII.

I never used pbx, but I wonder if pbx may need other requirements (except ports and protocol) as sip/rtp.

I never tested dhcp.

Its easy to end up with 90 firewall rules if you do the same for phone, printing from wlan-clients on blue to printers on green, wlan-clients on blue to network-storage on green.

Good luck.

Would recommend creating firewall goups.

blue can not reach green by default will need rules there.

May need rules on red if your sip server is in the cloud.

Thanks for your reply, firecherry.
I forgot to mention that I have a firewall rule allowing the blue network to access the green network.

Furthermore, the phones on the blue network are correctly registered by the PBX located on the green network.
In fact, I can call all the phones without any problems; the only thing is that the audio doesn’t work (if installed on the green network, everything works).
Based on the Blue->Green firewall rule I mentioned above, there should be no port restrictions, right?

PS.
All computers installed on the Blue network access the Green network without any problems.

Is the PBX firewall blocking the blue connections?

Just to explain shaun’s hint: the firewall of your voip board may block logins from devices with ip-addresses from outside of green network mask.

That’s why matching devices on firewall green instead of blue may be better.

Does your voip board have a mac filter? Your phone may change mac cause it feels to be in a new wlan.

Android does by default react this way, iphone too.

Normally this should only cause trouble with sip and not rtp. So check rtp-ports both ways. Normally rtp is a range.

Just look at Print from Android phone to LAN Printer

I don’t think so, otherwise the phone would not be registered by the PBX and it would not be possible to call other phones.

Perhaps I didn’t explain myself clearly: phones on the Blue network are correctly registered by the PBX on the Green network. It is possible to call all phones on both the Blue and Green networks; the phones ring.
The only thing that doesn’t work is the voice connection from the Blue to the Green network and vice versa.

Let me be more specific: if I call another phone on the Green network from a phone on the Blue network, I can hear them but they cannot hear me.
In short, it is as if the microphone on the phone on the Blue network has been turned off.

One-way audio, (they cannot hear me Blue to Green) strongly suggests ports used by RTP (Real-time Protocol used to carry audio) are being blocked from Blue to Green. Above, hvacguy wrote “blue can not reach green by default will need rules there”. RTP can use a wide range of ports.
One (insecure?!) temporary test to try is to create a firewall rule that allows all UDP (and TCP too, I think if it’s encrypted?) traffic from Blue to Green. It’s a start so you can narrow down ports. Firecherry gave an example of 49100-50500.

Everything that I read about VoIP will describe ports and protocols (TCP / UDP) as “often”, “usually”, “typically” … You need to check the documentation for your system. And/Or, if you have a softphone on a PC, call Green to Green and use netstat or ss to check what ports are being used.

edit: I’m assuming your VoIP handsets will negotiate a common codec. It’s possible for them to fail to negotiate a codec if they’re different manufacturers/models/ages. I don’t think that’s your problem, but can’t rule it out.