OK so lets see some validation of the config.
sorry for the delay people, got tied up with work
-
we have a leased fibre line, so the is no router in bridge mode, its a layer 2 IP WAN assigned to the mikrotk directly
-
output for the asterisk command
[root@voip meshagent]# asterisk -rx "pjsip show transport 0.0.0.0-udp"
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress....................>
==========================================================================================
Transport: 0.0.0.0-udp udp 3 96 0.0.0.0:5060
ParameterName : ParameterValue
=======================================================
allow_reload : false
allow_wildcard_certs : No
async_operations : 1
bind : 0.0.0.0:5060
ca_list_file :
ca_list_path :
cert_file :
cipher :
cos : 3
domain :
external_media_address : 217.14.xxx.xxx
external_signaling_address : 217.14.xxx.xxx
external_signaling_port : 5060
local_net : 192.168.28.0/255.255.255.0
method : unspecified
password :
priv_key_file :
protocol : udp
require_client_cert : No
symmetric_transport : false
tos : 96
verify_client : No
verify_server : No
websocket_write_timeout : 100
- the output above shows a local_net
to be honest no errors so far since removing the external ip address and rebooting the voip server
but its only been 24 hours and last time it took 2/3 days before it happened
so im keeping a close eye on it
do you still think u should change the timeout in the mirkotik for the UDP from the 10 seconds to 60 seconds?
You should probably turn the SIP Helpers off then in the Mikrotik. If you are getting a non-public IP on the Mikrotik’s WAN then there is double NAT in play.
i already have the SIP helper switched off on the mikrotik router
its the very first job i always do with ANY mikrotik device!
edit: the IP assigned to our mikrotik WAN is an external IP address, so the is no double nat, only single nat
This should be easy to find out what is going wrong (though it might not be easy to fix).
Asterisk should always include rport in the Via header of the outgoing INVITE, so Twilio should always send 100 Trying, 183 Progress, 180 Ringing and the 200 OK to whatever address and port the INVITE came from. You can confirm this by looking at the INVITE that was sent.
Next, look at the Via headers of the responses. Each should contain received= and rport= parameters, showing the address and port from which Twilio received the request. If properly configured, the router/firewall (or other network elements) should not have rewritten the source port number so you should see rport=5060.
If these are correct, I am guessing that the 200 OK was misdirected by a local network element.
Does the Mikrotik have your public IP address on its WAN interface? If not, please explain (modem configured as router, ISP does NAT, etc.)
Confirm that SIP ALG is disabled in the Mikrotik.
If you still have trouble, it may be useful to capture traffic on the WAN interface. Most routers don’t have enough file space for a long-term capture, even with filtering, but you can stream the capture to Wireshark on another device. For example, see
https://tojaj.com/packet-capture-from-mikrotik-to-wireshark/
Asterisk is using 10000-20000 for RTP/media, so the SDP media port Twilio sends media to will also be in the 10000-20000 range. Do you have Direct Media set to off in the trunk settings? Also make sure Rewrite Contact is set to yes.
I’ve got around 100 Mikrotik’s out at locations that either have cloud services (5 to 150 accounts/phones at sites) or on-prem PBX with SIP trunks back to my network. The Mikrotik SIP helpers have never been an issue. This is all sounding like a config issue either with the trunk on the PBX or even how the Mikrotik is configured.
so 4 days in and still going strong, no errors so far!
@BlazeStudios to answer your questions,
Direct Media is showing as OFF and Rewrite Contact is showing as OFF too
@Stewart1 to answer your questions,
if i check the pcap for the INVITE my freepbx sent twilio i get these headers
but i also checked the incoming RINGING 180 from twilio on the same call which talks to port 5060 returning no problem and these are the headers
it does indeed seem that twilio is setting the port 14299?
but i just cant work out where its getting that port from!?
ive checked my firewall and SIP ALG is 100% DISABLED! and the wan port has a external WAN ip assigned to it, then the mikrotik port forwards ANYTHING from ANY of the twilio IP ranges for SIP trunking, directly to the freepbx server
i am hoping as we had no issues so far for a few days we might be in with some luck! but case of wait and see!
The Via header in the 180 Ringing shows rport=14299, which means that Twilio received the INVITE from source port 14299. This could have been rewritten by the Mikrotik (post your port forwarding settings) or by another network element (does the Mikrotik have the 217.14.x.x address on its WAN interface?)
nope just standard dst-nat to dst-nat,
but i do have a few extra rules for the rtsp and 5060 as these are forwarded too but from a different address ip group, this just allows for me to have my phone connected at home to the server so i can monitor/testing etc
p.s. yes the mikrotik has the WAN ip attached to its WAN interface with a normal masquerade rule
ok so at site 2, the issue has just happened, even after all the changes first time round.
but its basically the same sort of output as above, all ok, then SDP goes to wrong port,
and checking the INVITE headers shows rport; (without a port number)
and checking the RINGING headers show rport=3560;
so something must be wrong!
i have also spotted on the calls that work, the RINGING headers do indeed show rport=5060
so i will try increasing the UDP timeout as suggested above
and also maybe enabling the Rewrite Contact for that trunk too
see how it goes from there, if its still not working, then it must be a firewall issue?
No. Do not set Rewrite Contact on a trunk.
What model are you using? What version of ROS is it on? And are you using the default firewall, if this is an RB device?
RB1100AHx4, 7.15.2, and yes it’s the default firewall that’s created I just added my port forwarding for twilio as shown in screenshot above
Then you should turn the SIP Helpers back on, it will keep the NAT as 5060 instead of changing it to a random port.
the problem i have is we have other voip phones on site that connect to an external sip provider (in the cloud), and if i enable the sip helper, then suddenly they cant make calls!
Bingo! If another phone is connected, UDP source port 5060 is occupied, so when the PBX initiates a connection, the Mikrotik must rewrite the source port to a random value.
Possible fixes:
- Configure the other devices to use a source port other than 5060.
- Configure the PBX to listen on a different port. Unfortunately, this requires changing the destination port on all extensions (and any registration-receive or statically configured trunks).
- Use a different transport (TCP or TLS) with Twilio.
That doesn’t make any sense at all. As I said before I can have anywhere from 5 to 150 devices at a location behind a Mikrotik and the SIP Helpers are always left on. It doesn’t stop them from making outbound calls.
There is a configuration issue somewhere in all this.
There are a lot of subtle issues here. Most SIP softphones and mobile apps bind to random ports, not 5060. Or, they connect by TLS to the servers, so no conflict there. Or, the on-site PBX is not using port forwarding, because frequent registrations and/or qualify requests are keeping the NAT associations open.
In my experience, SIP Helper and UDP port forwarding don’t play well together on Mikrotik.
Can you elaborate on that? I’ve got almost a 100 sites doing things with either a PBX on-prem or dozens of phones connecting to back to my cloud network. Every location has a Mikrotik in front of all the voice network with a public IP directly on the Mikrotik. In some cases there is multi-WAN failover and even with that…no real issues.
Also, the outbound requests have nothing to do with the inbound requests (port forwarding). When the outbound request is made the router creates a NAT rule for that request, any replies to that request will be considered part of that request. Now unless the firewall has been mucked with more than has been let on, there shouldn’t be any issues with this at all.
True, but they should! On (for example) an IOS router, the port forwarding command is “ip nat inside source …”, i.e. it reserves the port in question, so an outbound request from another LAN host will never use that port.
But the OP is doing both at the same time, which is where Mikrotik (and I believe also Ubiquiti) fall down.