I’ve googled around for the past few days and tried many of the solutions posted, but nothing is making a difference… Outbound audio only, and the call drops after 30 seconds. Everything I’ve read says it’s a NAT issue, but doesn’t suggest how you fix it… Here’s some screenshots from wireshark of a failed call:
Ports are opened in the firewall for 5060, and 10000-20000.
Generally you need the complete INVITE/SDP transaction, not just summary lines, and people are most familiar with the form in which the Asterisk logs show that (see the other thread about logging).
You haven’t explained what the addresses are, but your NAT setting do seem to be messed up. Does vpn in vpntranet.com mean this is an anonymising service, If so there is a good chance that it does things that are really inconsistent with running any sort of server.
In any case, without network topology information, and the complete transaction, there isn’t enough for me to start guessing.
Note you are getting port unreachable from the private network address 10.70.32.2. That normally means that the adress is valid, but the destination port either has no program running on it, or is blocked by a firewall.
Also note this isn’t the standard 32 second syndrome. I think it is probably being closed for lack of RTP, not lack of signalling. With lost signalling, there would be multiple re-transmissions of the signalling.
Try this:
IIRC: at least one side has to do this when making calls between two PBX’s I forward RTP ports to the PBX on both ends.
This should help debug and hopefully allow to calls longer than 30 seconds.
If it works mines a pint of Stella. ha ha
Cheers,
–
Andy.
Sorry, let me add some context:
10.70.32.2 is the private IP of the PBX
10.70.32.54 is my desk phone I’m testing with
There are 2 addresses used by my provider’s pbx, one of them you can see here:
209.235.168.29 and 30.
On the firewall side, we have a Fortinet 400f. I’ve opened up these ports and forwarded them to pbx:
80 (Let’s Encrypt)
5060
10000-20000
Disabling SIP ALG on a Fortinet is a huge pain… Also when I did so, our hosted phones started playing extension roulette (dial the same extension 5 times, go to 5 different phones). At the moment, I can’t turn that back off.
In that case, you are going to have to provide detailed protocol logging, so that we an understand how the Fortinet is mangling things, and compensate for that.
I would be happy to! I’d also like to provide the logs from Asterisk… I’m unsure how to do so.
Where was the wireshark capture taken from?
tcpdump from the pbx. I can enable full logging on the pbx and grab the log file. I’m dumb, that’s actually really easy to do. One sec, I’ll be back with that info.
Here’s a link to the asterisk logs today after trying to make an inbound call. (Sorry, can’t upload the file or paste in…):
When you say “detailed protocol logging”, are you asking for logs from the firewall? I can do that, but could you help me pinpoint what you’re looking for?
I mean the output you get, in your case, by issuing “pjsip set logger on” and then capturing a full log, without restarting Asterisk.
I’m looking for the c= lines, for the IP address, and m= lines for the port number.
I might also need sngrep or tcpdump to show actual addresses and port numbers, including for RTP, as against those referenced in the SDP.
You hadn’t said which channel driver you were using, so I didn’t know which CLI command to use.
Here’s the tcpdump:
and here’s the full log file:
There is no protocol logging in the full file.
The first call shows a classic missing ACK case. You are telling the other side to send the ACK to
sip:205.201.229.173:5060
but if it is doing so, it isn’t reaching you. You need to check if this is your address, and that it will get forwarded.
It does seem to be correct, though, as the received and rport information for the BYE response are good.
SIP/2.0/UDP 205.201.229.173:5060;received=205.201.229.173;rport=5060;branch=z9hG4bKPj36723fba-52e9-4a55-b7dd-45c6b1df0535
Your RTP is coming from a slightly different address from that used for signalling; it is the 30 version of the provider address, not the 29 version.
The incoming media is being addressed to port 12840, but your 200 OK says it should be sent to port 14776! You need to find out what is changing this and fix it.
It looks like it was heading for a 32 second failure, because of the lack of ACK, but actually hit an RTP timeout, first.
The address to which to send the RTP is only in the 200 OK, so, if that it not being received, at the far end, it may be a plucking an address out of the air. You need to do captures at the far end, to see what is happening from its point of view.
We have a static public IP, so that is our address. So what you’re seeing is that our PBX is telling it to send the ACK to the correct address? That’s interesting, because that’s not what my ISP is seeing on their side.
Having this same conversation with my SIP provider. What they’re seeing on their end is the ACK is being pointed to the internal private IP, which of course it can’t reach… I’ll quote him directly, because I don’t want to get it wrong.
I am still seeing something sending me the IP of 10.70.32.2.
I see the invite and message setup but when I try to ACK the info back it has been told to send to the 10.70.32.2 address so that part fails. That is in image called AckTo10.70.32.2. After that I see some RTP to the correct address but doubt that is working since the ACK fails.Then later I on I see another Invite and Ack but that has the same 10.70..32.2 in it so guessing it failed also and no audio or 1 way audio. That is image ReInviteMessage.
I think your SIP ALG is breaking two different things!
