Hoping i can get some information on how to proceed with a setup or if i am correct on how i have done it so far.
My provider is giving me two outputs per say.
One is the Internet Access 212.xx.xx.84/28 On one output which i use for Internet Access. (Huawei Router)
The other is the VoIP output with IP 198.xx.xx.66/29 network with gateway 198.xx.xx.65/29 (Cisco Router).
I am taking the Internet Access and placing it on an RB750 MikroTik Router ether1 and creating a bridged
network range 172.17.13.0/24 on ports 2-5 on the RB750.
I then take the FreePBX which has two ethernet cards.
eth0 i use with ip 172.17.13.254/24 and gateway 172.17.13.1 from ether2 MikroTik.
eth1 i use directly to the Cisco and i add it as 198.xx.xx.66/29 with no gateway.
My ISP DNS is 195.xx.x1.200, 195.xx.x2.200 added to dnsmasq not added anywhere else.
route_eth1 has the ISP telephony routing to the Cisco Gateway via eth1.
I am using the RB750 to WireGuard to the premises.
Problem is that when i try to register my SIP trunks via PJSIP method it doesnât work it keeps getting rejected most of the times but sometimes it might register for a couple of minutes and then drop again.
Via Chan_SIP everything works fine no problems.
Question is, the way this has been implemented is it correct or do i have to go about it via a different approach meaning do i have to scrap the 2nd NIC and go via a sub interface and route the Cisco IP via the 750 and if that is the case can someone point how to implement the NAT section of the 750?
Anybody? I only need an advice wether this is correct or not and how to approach this, no need to analyse details as i understand how precious everyones time is.
I use Mikrotik for everything and Iâve never seen these issues. We would need to know who FreePBX is configured and how everything else is configured. This sounds more like a networking issues than a FreePBX issue.
I am assuming that you have two UDP transports for pjsip: 172.17.13.254-udp and 198.xx.xx.66-udp. You use the former for your local extensions and the latter for your trunks.
Here, I am assuming that you configured a trunk that requires registration with chan_sip and it works fine. However, you want to use pjsip (for long-term support), so you deleted the chan_sip trunk, created an equivalent pjsip trunk (same account with same server), but registration requests are rejected.
If either pjsip Port to Listen On or chan_sip Bind Port are 5060, itâ possbile that a SIP ALG in the Cisco router (or elsewhere in the path) is either causing trouble or hiding a config problem, so you might try switching the ports and see whether the trouble moves to the other channel driver.
I assume that trunk traffic never passes through WireGuard so it is not relevant here. If not the case, please explain.
If you canât figure out what is wrong, set up the working chan_sip trunk, turn on sip debug, wait for a successful registration and copy the SIP trace from the Asterisk log. Now set up the pjsip trunk, turn on pjsip logger, was for a failing registration, copy the SIP trace from the log. Redact the traces as desired, paste them at pastebin.com and post the link here.
Thatâs not possible at the same time. Do you mean that only one driver is enabled at a given time? Or that you switch the port numbers around when you change from one driver to the other? Or something else?
Not true, the default value of Bind Port for chan_sip is 5160 and your log for the chan_sip case clearly shows port 5160 being used. The default value of Port to Listen On for pjsip is 5060.
Unfortunately, pjsip logger was not on for your pjsip case. Note that it is turned off by restart / reload / apply config, so you need to turn it on again and wait for another registration attempt.
Do you have an outbound proxy set for either config? From here (Tokyo), ims.otenet.gr resolves to 195.167.16.30, different from xxx.xxx.16.182. If no outbound proxy, itâs likely the âspecialâ DNS you are using, which seems to be required. Confirm that your pjsip case is accessing the same server address as chan_sip.
Not true; the last line of your pjsip log shows there was no response at all, presumably because they were sent to the wrong address or over the wrong interface.
If an endpoint has the transport set to auto, then Asterisk will choose the first transport that matches the protocol being used. I.e. it will pick the first UDP transport in the config if the devices are using UDP. That would means devices that should be using a specific bind interface will not get it. If you have multiple UDP transports, you need to specify which transport an endpoint should use.
Sorry, I donât know how sysadmin handles this. However, as a workaround, try setting Outbound Proxy to sip:xxx.xxx.16.182\;lr\;hide
(replace xxx.xxx with the actual value from the chan_sip log)
If it still doesnât work but you now get responses, paste a new log.
Remove the outbound proxy when you fix the DNS issue.
Youâre conflating inbound vs outbound in this. The PBX is listening on both IPs/ports specified in the transports. When a device REGISTERs to the PBX the PBX will answer on either transport which then makes the replies go out the proper NIC interface/route back to the device. At this stage the PBX doesnât care which transport is being used as long as it is a IP/port bound to Chan_PJSIP.
Conversely, when the PBX needs to send an outbound request to the device, it will see the device is using UDP and grab the first listed UDP transport in the config unless one is specified. Which means it could be grabbing a transport that is bound to Eth1 when the device is on the network bound to Eth2 (or vice versa).
Now you could assign a transport to each extension or you can look at /etc/asterisk/pjsip.transports.conf to see which one is the first listed. Then only assign a transport for the extensions using the second listed transport.
This doesnât solve the actual issue. An outbound proxy is the destination to send to, the PBX needs to use the proper source IP/interface when routing to that destination. The outbound proxy will not tell the PBX which source IP or route to take to get there.
Show the log in which this works. If Asterisk canât resolve the host name it would fail and not give an error that it got no response from the destination.