VoIP calls come in, not out
-
I have a strange situation where one week, calls in and out work fine, the next they just stop. Nothing changes on the old SIP server and nothing that I know of changes on the firewall but it keeps happening.
This SIP server (SipXecs) uses port 5080 and not port 5060 which the ITSP says is supported on their end.
Maybe the SIP ports are changing on their way out as well but since I'm not changing anything on the firewall, why would it work one week and not another unless that's just odd timing of noticing the problem.
NAT outbound is set to hybrid. I believe that was changed due to another suggestion in a question I asked here. I do notice that the SIP server is in here, 10.0.0.199. Disabling this changes nothing.
Today, I noticed this on the firewall but am not sure if this is a problem or not.
The single:no_traffic are the ones that caught my eye, like port 5060 is being blocked or maybe the remote is not responding. I don't know because I can also see data accumulated too.WAN udp 1xx.1x.1x.2x:5080 (10.0.0.199:5080) -> 1x.7x.6x.1x:5060 MULTIPLE:MULTIPLE 22.517 K / 22.515 K 11.14 MiB / 12.24 MiB
LAN udp 10.0.0.199:5080 -> 3x.2xx.9x.1xx:5060 NO_TRAFFIC:SINGLE 50.978 K / 1 1.56 MiB / 60 BDoes this say anything to someone here? I'm stumped.
-
Those are not the matching state pair the destination IP is different. I think you've just not chosen the right two states.
I assume 10.0.0.199 is your internal PBX?
The and two external addresses are your SIP provider?
-
@stephenw10 said in VoIP calls come in, not out:
Those are not the matching state pair the destination IP is different. I think you've just not chosen the right two states.
I assume 10.0.0.199 is your internal PBX?
The and two external addresses are your SIP provider?
Oh Hi, I didn't notice you had replied, I was still editing and adding what I could find :).
Yes, 199 is the SIP server.
Yes, the external IPs are the ITSP.
Guess I didn't have to hide those. I can update the image if you want. -
@lewis said in VoIP calls come in, not out:
50.978 K / 1 1.56 MiB / 60 B
Need to see the two states that match, both show the same traffic. That will show NAT working correctly. Or not.
You don't need that static source port outbound NAT rule for all of LAN like that. The single IP rule covering the PBX should be fine.
Do you have multiple WANs? Multiple public IPs with VIPs?
When this happens what do you do to recover?
-
You don't need that static source port outbound NAT rule for all of LAN
like that. The single IP rule covering the PBX should be fine.That must have been added automatically as I don't recall adding it. I'll remove it.
Do you have multiple WANs? Multiple public IPs with VIPs?
The firewall has only one WAN but a dozen public VIPs
When this happens what do you do to recover?
Nothing so far, just that outgoing calls seem to be a hit and miss.
Incoming calls seem to work fine.Need to see the two states that match, both show the same
traffic. That will show NAT working correctly. Or not.I'm sorry, I'm not sure what you'd like me to share?
Two states that match?
I have LAN, WAN and TCP and UDP states.I now notice that the calls seem to make it out after all but no audio.
-
@lewis said in VoIP calls come in, not out:
WAN udp 1xx.1x.1x.2x:5080 (10.0.0.199:5080) -> 1x.7x.6x.1x:5060 MULTIPLE:MULTIPLE 22.517 K / 22.515 K 11.14 MiB / 12.24 MiB
LAN udp 10.0.0.199:5080 -> 3x.2xx.9x.1xx:5060 NO_TRAFFIC:SINGLE 50.978 K / 1 1.56 MiB / 60 BI mean these states are not a matching pair so it doesn't help. We need to see some matching states to check the ports are being translated correctly. They almost certainly are though.
Do you get no audio at all or one way?
-
The firewall/sip server are remote to me. I have a SIP phone on my desk.
If I call into the system from a cell phone for example, then I get audio both ways. Everything works.
If I dial out from my local SIP phone, which means the call goes to the remote firewall/sip server, to certain areas codes like my cell phone, then it rings, I can answer but no audio.
If I call another area code, I get nothing, no ring, no audio but the call setup happens because I can see it completed in the CDR.
That must mean that 5060/5080 are working at least. This is consistent to my cell phone which is strange.
The local SIP phone is set for NAT as well.
This seems to be a UDP problem.
-
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?
Are calls from phones local to the PBX also failing?
Steve
-
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
