VoIP calls come in, not out
-
So you mean pfSense with the PBX behind it is remote to you?
And your local SIP phone connects to the PBX directly with a
port forward? Over a VPN?Yes, the PBX is remote, on another network that has a pf firewall on it.
No VPN and the phone is correctly set to NAT'ing and of course, the SIP server is also since it's behind the firewall.Are calls from phones local to the PBX also failing?
Calls come in from anywhere to the PBX then on to the remote phone which is on my desk. Incoming, everything works, audio both ways.
Outgoing calls is what is not working. At my location, I also have a pf firewall so the phone is behind that.
The phone is registered to the PBX.
When I make outgoing calls from the phone, they make it to the PBX.
All of the outgoing calls hit the PBX.
All of the outgoing calls get a full SIP setup, they reach the destination.However, there is no audio.
-
This is almost certainly a SIP problem. Though quite why it would be intermittent is odd.
Is there actually no audio in either direction?
Really you need to check packet captures of the SIP call setup and see what ports and IPs are being sent. Something there is probably incorrect. Usually it's the PBX sending an internal IP to the phone to connect back to with RTP for audio which, of course, fails for connections from external phones.
Steve
-
Sorry for not being very active on this, just have so many things going on all at once and this phone problem isn't helping so using cell phones a lot with bad signals no less.
The audio is over UDP and the calls seem to get fully setup so can you expand on why you think this is a SIP problem?
Also, since it partially works, at least for incoming calls, I'm terribly nervous about changing anything that could cause that to fail also.
The phone is registered onto the remote SIP server so that part is fine.
The incoming calls have two way audio but outgoing calls get setup but no audio.
So where might the problem be, the firewall of the local phone or the firewall of the sip server?
I used to do a lot of VoIP troubleshooting but haven't done any in so many years, I don't even recall how to test this.
I suspect outgoing UDP packets on the SIP side firewall.
-
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!
