VoIP calls come in, not out
-
Typically what fails here is the PBX sends the wrong IP address for the RTP audio (which is udp) to connect to resulting in one way or no audio at all. But the phone rings and call appears to complete because that is carried out over the existing SIP session.
The most common failure is the PBX sending it's local private IP to connect to which remote devices obviously cannot without a VPN. So typically in that situation you might find audio works to phones that are local to the PBX because they can reach the private IP.
However that would not be something intermittent, it would fail every time. So what could be happening is the PBX is using something detect it's external IP and that is sometimes failing. So maybe you have dual WAN or dyndns etc.In any case the way to solve this is to packet capture the SIP traffic and look at the call setup. Check the IP the PBX is sending to the phone to use for audio are correct. And if they're not the IP it is sending will probably make it pretty clear what's wrong.
Either way that's not a pfSense problem. The only time pfSense does anything with SIP traffic is if you have SIProxd installed and that almost always a bad idea.
Steve
-
I figured it might be the firewall not configured correctly.
The SIP server is on a remote network so have no way to capture in terms of pass-through.
However, I suppose I can capture from the SIP server itself and from the command line of pfsense.
I'll try what you suggested and see if I can find some leads.
Thank you very much for the help.
-
Yup, if it is a SIP issue you should still see it in a pcap at the phone end.
-
Sadly, I've not had much time to spend on this. Too many things at once. I was wondering if there might be any info, an article, examples on capturing this traffic from the firewall command line.
-
I would just use the gui for that in Diag > Packet Capture.
Just capture on the interface and filter using the phones IP address set to catch a few thousand packets. You shouldn't need that much but if it starts doing other things that might fill the pcap quickly. If you know the SIP port(s) it's using you can filter by those too to reduce the noise.
But you can pcap at the command line:
https://docs.netgate.com/pfsense/en/latest/diagnostics/packetcapture/tcpdump.htmlSteve
-
Thanks again.
I captured from the LAN interface. The SIP server is the 10.0.0.199.
The 208.x.x.x IP is voip.ms in LA.I see one error related to UDP in the entire call duration. This shows up a couple of times.
14:58:14.537091 IP 10.0.0.199 > 208.100.60.37: ICMP 10.0.0.199 udp port 30509 unreachable, length 100
The rest for this port are exactly the same but the length is always 172.
14:58:09.556749 IP 208.100.60.37.17224 > 10.0.0.199.30508: UDP, length 172
I have not diagnosed SIP stuff for nearly 10 years now.
-
@lewis said in VoIP calls come in, not out:
10.0.0.199 udp port 30509 unreachable, length 100
Hmm, well that looks like something is sending audio to the server on the wrong port. But that could be unrelated.
So this pcap was at the pbx end?
Really you want to look at the SIP traffic between the phone and the PBX. I may have misunderstood how this is configured.
Steve
-
Here's how things look.
I'm capturing on the desk phone network side.
When I call the desk phone from a cell phone, there is audio showing up between UDP ports 10000-31000 which is expected for this phone system.
When I try to make a call from the desk phone, I noticed there aren't any audio packets at all. I do see UDP traffic but it's on the call setup only.
I added a rule just for the sake of doing so and it made no difference, incoming call, no UDP ports in the audio range of 10000-31000.
Since the phone system is remote to this phone, you would think no matter if it's an outgoing call or an incoming one, the phone is already registered to the SIP server so there should be nothing blocking those ports since it's initiated from inside the building where the SIP phone is.
And this is how the SIP server side firewall looks. Again, this SIP server (Sipxecs) uses 5080 for the ITSP. SIP trunk and SBC's.
Confusing. -
Ok, so you need to capture the SIP call setup that happens when you try to place a call.
There's no reason the phone would be blocked sending audio outbound so if there is none arriving at the phone side firewall LAN that means either it's not being sent a destination to send it to or the phone is unable to send traffic to it. It has no route to it maybe or it's appearing as a local IP.
The fact you don't see an incoming audio either implies whatever is being sent to the provider is also inaccurate or blocked somewhere. Do you know if audio goes via the SIP server or direct?
Are there phones at the SIP server site? If you call them does audio work?
Steve
-
But isn't that the odd part in this problem? I can see the call setup working no matter if I call in or call out.
It's only the audio that's not working and only on outgoing calls. I can also see the missing audio but I can't tell why it's happening.
The firewalls don't seem to be blocking it. I'll check the ITSP, maybe there is a function for setting the UDP ports and maybe they aren't in the same range or something.
-
The audio and SIP traffic don't have to take the same path. The SIP goes via the SIP server where the phone is registered but often the RTP audio does directly between the end points. It depends what the server is sending to the phone to use and you need to look in the SIP call setup packets to see that.
That's why calls to a phone at the SIP server site might well work because traffic would be using the same route/IPs.
In some situations that's why audio might fail. If the PBX sends the local phones IP to connect to with RTP and the remote phone doesn't have access to that for example.
In both cases you can usually see what the problem is by looking in the SIP call setup.Steve
-
I just found an old email about this thread and had forgotten about it because once you read an email, it's no longer highlighted. I felt I should come back to close it.
The problem was unrelated to pfsense completely. What it was is that I had a test SIP system on another network using the same ITSP. When it would register with the ITSP, it would break registrations from the second SIP server, the one I was actually using now.
Once I shut down the original, everything started working again.
Sorry it took so long to come back and explain this and thank you for helping me.
-
This post is deleted!
