Is there an easy way to disable the SIP/PJSIP port conflict check?
public function validateNoPortConflicts() {
// Get all of our binds
$binds = $this->getBinds(true);
$allports = array("tcp" => array(), "udp" => array());
foreach ($binds as $driver => $listenarr) {
// We explicitly don't care about interfaces. Having
// chansip on 5060 on int1 and pjsip on 5060 on int2
// is just going to be a nightmare. We asked getBinds
// to return a flattened array, so we just disregard
// the interface
Having chansip on 5060 on int1 and pjsip on 5060 on int2 is literally the only way that I can get NTT’s (Japanese national telco) VoIP service working. In the past, I’ve just commented out that check and it’s worked well, but I would love to not get the message about how I’ve tampered with the files, and I’d like to be a bit more upgrade-proof.
At the very least, can I somehow exclude Sipsettings.class.php from the tamper check?
If you really need that, try setting up pjsip on some other port and overriding it in /etc/asterisk/pjsip.transports_custom_post.conf with something like:
[0.0.0.0-udp](+type=transport)
bind=0.0.0.0:5060
(replace both 0.0.0.0 with the relevant interface – it should match what’s in pjsip.transports.conf)
You must restart Asterisk after making these changes.
However, I find it hard to believe that you really have all the constraints you mentioned. I assume that you have one interface connected to an on-site SBC supplied by NTT, statically configured; the other interface connects to local extensions and the internet. If not, please describe the networking setup.
Does NTT require chan_sip? Or does it require pjsip? Although the PBX IP and port is often hard coded by the carrier (so you need port 5060), it’s very rare that these simple setups won’t work with either driver, since they generally don’t use registration or authentication. If otherwise, please explain.
Then, what do you have on the other interface that requires port 5060? If you have secondary trunking providers using registration, the port shouldn’t matter. If IP authentication, you can usually specify a port number on their portal, or you can specify a domain name with a SRV record that routes to any desired port.
First of all, thanks for the hack. It’s nice knowing that I can fall back on that if I can’t get it working using only pjsip.
This is an issue that I’ve been fighting with for a while, since pjsip came along, since I really want to use it for handsets (because of the multiple simultaneous registration thing).
NTT’s service is delivered as a separate fibre optic line with a media converter to deliver it as ethernet. You receive your IP and routing information via DHCP, as well as the SIP server username and address. It’s important to note that you receive an IP address that “looks like” a globally routable address, and the SIP server also looks globally routable, but this does not use the public internet. There is no route to these SIP servers unless you are connected via the fibre optic line, and the IP address that you get is not reachable from anywhere in the world.
I can use pjsip to register with NTT or to have the handsets register, but when I try to do both, I see a lot of instances where the SIP headers use the wrong IP address, or the wrong media address is presented to either the handsets or to NTT.
This issue: https://issues.freepbx.org/browse/FREEPBX-20268 certainly doesn’t help things, but even if I fix this by manually editing the config files, I still see NTT’s IP address being presented to the phones as the media address. My guess is that somewhere inside Asterisk or PJSIP itself, it says something like “oh, there is an IP address that doesn’t look like a private address, so I’ll override the media address with that”.
I’ll keep on plugging away at it, but typically what happens is that after about my third day poring through Wireshark logs and tracing through source code, I get fed up and just decide to use SIP for NTT and PJSIP for the handsets.
Is the address you get by DHCP on the VoIP line a real public IP (but they don’t route to you), or is it a CGN address 100.64-127.x.x ?
Do you register for incoming calls, or are they sent automatically to the address their DHCP assigned you?
Is the SIP server address in the same subnet as the DHCP assigned address?
Is the media address (on their end) the same as the SIP server address? If not, is it in the same subnet as the server? If not, is it always in the same subnet?
It seems to be a real public IP: At least in Tokyo, every site I’ve ever seen has been issued a /30 taken from the 118.177.0.0/16 network. You must register to be sent calls, although I’m not sure why. Your registration will be rejected if NTT sees anything “wrong” with the REGISTER packet.
The SIP server address, in Tokyo at least, has been 118.177.125.1 at every site I’ve ever seen. The media address, as of now, is always in 118.177.0.0/16 (which is a route delivered by the DHCP server).
What goes wrong if you do “nothing special” as below?
Assume that eth0 is the NTT line and eth1 is the LAN with the handsets at 192.168.1.2
You have only one transport bound to both NICs.
In Asterisk SIP Settings (General tab), you have
External Address: (your real public IP on the WAN interface of your router/firewall)
Local Networks: 192.168.1.0 / 24 and 118.177.0.0 / 16
At the OS level, 118.177.0.0 routes via eth0 with the gateway issued by DHCP. Default route via eth1 and 192.168.1.1 (replace with your actual firewall LAN address).
A separate issue: Given that the SIP server requires registration, I would assume that your port would not have to be 5060, unless it checks that just to be mean.
As far as I can tell, the only thing “wrong” with this one is that the Via: and Contact: headers contain my local private address, and to make it work on NTT it would contain the “public” address that NTT gave me.
Sure. I didn’t realize that pjsip isn’t smart enough to set Via, Contact (and for INVITE, the media address) to be the address of the interface from which it sent the request. So, the next step would be to use two transports, setting Local Network for the NTT interface to 118.177.0.0 / 16. Have you tried that?
Yeah, that gets a lot closer, except that FreePBX itself gets confused and writes the wrong media address into each handset’s configuration (bug listed above in this thread). Let me set it up so I can show what’s going on there.
OK, so after some more playing around, I got it down to “just” some errors in the FreePBX-generated config as long as I am using two transports. If I am using two transports, and do the following for the handsets:
Specify a transport rather than using auto
Comment out the “bind_rtp_to_media_address=yes” line in the extension, and
Change the media_address on the extension from the NTT interface (I think it just chooses the IP address of the first interface it sees) to the global address of the PBX
…then both NTT and the handsets do signalling and media correctly, at least in the limited testing I’ve been able to do.
This is a huge step forward! I think that I can adjust those parameters using pjsip.endpoint_custom_post.conf for now, and hopefully provide some useful information to that bug report to help it get fixed in the long run.
Wow, this is very helpful information. I hope that we can get Sangoma to fix this bug quickly, especially given that they are trying to get everyone off of chan_sip.
IMO, the bug can be summarized as “if you have two or more transports, it doesn’t work”.
And, given that pjsip is too dumb to put the selected interface address in the headers (when using a single transport), it can be further summarized as “if you have two or more interfaces, it doesn’t work”.
Have done some more experimenting today (I only get to work on it for little bits at a time while we’re sure it won’t matter if we miss any phone calls). For outgoing calls to work properly through pjsip, the disable_rport setting should be true (NTT rejects them instantly if the rport is present in the Via header while making outbound calls). This was just added in Asterisk 17.6.0, so the timing is really fantastic for my once-every-18-months-or-so crack at this.
Still hope Sangoma can fix the config file generation for the extensions, but this is a real concrete sign of improvement over my previous attempts.
I’m somewhat concerned about why this bug has apparently not bitten many users. One would think that almost any system with an on-site carrier-provided SBC would be affected. Is it possible that the single transport case works properly and the trouble you had was a routing problem in the OS?
When you tested this, did you confirm that the packet was sent out the 118.177.x.x interface?
(I assume that receiving an error response is confirmation; if sent on the wrong interface, it would be discarded and there would be no response. Is that correct?)
Since 118.177.125.1 is not in your 118.177.x.x subnet, if the default route (incorrectly) had higher priority than the 118.177.0.0/16 route, the packet would have been sent out the 192.168.101.141 interface, with the result you posted.
I had separate windows, each with tcpdump running for one interface. These were definitely going out the NTT interface. Never any response; I assumed it was because they were trying to reply to 192.168.101.141 and have no route to that.