FreePBX | Register | Issues | Wiki | Portal | Support

Existing SIP extension stopped working


(Paul Hermann) #1

I have got some older SIP extensions (running chan_sip) which have recently stopped working. Really struggling to get to the bottom of this - partly because I have no idea what logs or where to look.

I was just going to not bother and upgrade the phones, but I have one modified ATA which integrates a doorbell to the phone system and that has stopped working too.

Can anyone suggest what log files I need to check and/or if there have been any changes recently which might have cause this?

UPDATED info
I have managed to get one of the devices working by doing a restore from a backup. Great I thought, now I can bring up the config screens and do a line-by-line check of the config and get the other phone (which I was adding to the network) to also work.

I checked line-by-line

  • The chan-SIP config files only changing the ‘secret’ and the extension number
  • The config screens on the devices again carefully ensuring only the secret and the extension numbers were different
    Still no luck (and yes I did save and apply the updates)

So, I thought I’d make sure the new device was correctly configured by logging it onto the working extension. Unplugged the working extension and changed the password and secret to match on the ‘new’ additional handset. Again, no success.

Now the obvious conclusion is that the phone is faulty - EXCEPT - I set it up first go on a 3CX pbx immediately when I could not get freePBX to work. Registers fine … I went back and triple checked again - line-by-line. Still no joy.

So now I am really confused. The log files (which I have now found) are only marginally helpful. I have to go out but I will post a further update on my return.

Second update
I have now returned from my meeting. I wondered as I traveled if the issue was with the IP address being blocked, so I have now changed the IP address using the DHCP (fixed) allocation tied to the MAC using an IP which has never been used to my knowledge and STILL no success.

I have checked the various log files … file2ban, freepbx_security.log, freepbx.log and full. When I try rebooting the phone, nothing shows up with even the correct timestamp let alone anything related to this extension.

Really really puzzled.


(Dave Burgess) #2

You can turn SIP DEBUG on in the server, but you will probably get enough information from the file /var/log/asterisk/full. Look through there and see what happens when you chan-sip phone tries to connect.

Note that recent updates to the system have moved the default Chan-SIP port from 5060 to 5160, so your phones might be connecting to the “new” default channel driver at 5060, which in many systems is PJ-SIP. If that’s the case, your going to get all kinds of “not working” things going on with these phones.


(Paul Hermann) #3

Thank you Dave, but I was already aware of the pjsip and chan-sip 'issues and port changes. It also does not explain how two identically configured extensions and identically configured identical phones (other than the etx number and secrets obviously) result in one working and another not. It also does not explain why the one which does not work still does not work when reconfigured to use the extension of the one which does work - ie when it’s configuration is completely identical line-by-line. Incidentally, chan-SIP was moved to 5061 on my machine, not 5160 - not sure if yours was a typo or mine is just different - but I had checked that anyway and it was all done a while ago - I try to keep my modules right up to date (for security reasons).

I assume the /var/log/asterisk/full file is the same as that reported by the logs drop down selection item ‘full’. Is this not the case? If so, NOTHING is written there - I checked that before posting too. It looks like the machine doesn’t allow it - but the phone is on the same subnet and apart from the PBX itself there is no firewall. The IP address is whitelisted, fail2ban shows nothing and neither does the IDS system from the System Admin - IDS reports, although it does look like something is stopping it which is why I tried an IP address outside of any range I have ever used.

To be honest, I am seeing more and more instability in freePBX to the point that I no longer update it without doing any updates on a full clone first. Only when I can sort the problems (and there are nearly always problems now) will I update my main PBX. Frankly, its really not as good as it should be. There is NO WAY I would entrust a commercial operation to freePBX the way it is atm and the only reason I am persevering is because of a single functionality which would cost me about £100 to get with 3CX which frankly just works and now also runs on Debian. I can live without that functionality, so I am VERY close to giving up on freePBX … I feel it has lost its way somewhat.

I have an emotional attachment to getting this working, but my patience is almost evaporated.


(Paul Hermann) #4

How do I turn on the SIP debug? I am getting nothing and nowhere. NO new SIP accounts are able to register and only the original SIP devices are able to register.

I have one multi-account phone which I have tried to config to a new SIP account. The 3CX worked first time. The Asterisk/freePBX will not register, shows no sign of trying in the logs and is just doing nothing.

ANY ideas at this stage are welcome … because I have nothing left to try other than dumping freePBX for something else. Maybe I need to go back to an old version … because sure as hell this one is not working for me right now.


(Avayax) #5

sip set debug on, or sip set debug peer xxxx, or sip set debug IP xxxxxxx.

Also that:


(Paul Hermann) #6

Nope … still nothing. I got the old phone to reregister (no idea why its stopped) but all new SIP accounts will not register and nor will a ‘new’ (ie different) phone of the same type which I think I have configured identically (having the two config screens side-by-side) then turning off the first and setting off the second.

Asterisk (according to /var/log/asterisk/full) is not even seeing a request to register from the new extensions … but I have no trouble registering exactly the same phones using the same settings with a 3CX server. Registers immediately. When I say exactly, I mean the ONLY change I am making to the config is the server address. Password, extension etc are all unchanged (with the respective servers also set to the same values to facilitate direct comparisons obviously).

Two Yealink handsets, one older Grandstream and three softphones have all failed SIP registration. The softphones I got to work by using AIX so I believe it is not a firewall issue. It appears to be just SIP. Another Grandstream and another Yealink are working on SIP from earlier set up extensions.

I have tried cold booting the machine in case that might liberate some ‘issue’.

I am clearly missing something … any ideas? Start at the obvious, because I think I need to start all over again.


#7

what port are you relying on and does your firewall/router pass the right traffic to the right server.?


(Paul Hermann) #8

Thanks for the reply Dicko.

Port 5060. I am pretty sure the firewall is not the issue as server, firewall and devices (including the softphones which will not register on SIP but will register on IAX) are all on the same subnet, as for that matter are the devices which ARE working - all of which are long standing configs with the same hardware (so MAC address etc). The 3CX system is on the same subnet too (a fresh installation SINCE this problem started as a reference and test of a different option) and that works just fine - inbound calls work on both trunks as do outbound - at least to the working devices. Nothing else is giving me any problems just the SIP registrations - I suspect there must be some deep underlying issue, but I have no idea where to go from here to tackle it. Not only that, I have tried turning off the firewall altogether and that made no difference. I can access the Management console fine so there is no DNS issue either …

In searching the net I came across Ombutel which I thought I might try as well - so I fired that up too and tried to register the SIP devices on there - but that failed too, so now I am wondering if it is an underlying Asterisk issue in some recent update …

Maybe I should go back and install an older version of freePBX on a new VM and see if everything registers on that OK. As it is all on the same subnet I only need to try the local SIP registrations. I think I might try that tomorrow after I have had some sleep.


#9

From you machine just

tcpdump port 5060

(when only one server is active, lsof -i :5060)

Please don’t be pretty sure about anything, be instead be explicitly concise about everything.

If a SIP packet on 5060 arrives at your external network interface, it will need to be routed to your server, first off

tcpdump port 5060

would see it, and where it was routed to

If Asterisk “sip debug ip …” doesn’t see it, go back to your router.

If you have two servers trying to do SIP on your NAT’ed network, then just “DON’T DO THAT”


(Paul Hermann) #10

Hi dicko
As requested, here is as factual a summary of what I believe to be the relevant info as a base reference for further assistance (your help is very much appreciated). If you feel I have omitted anything – please just ask/direct me to do something.

1 – I have a perimeter firewall. Other than the freePBX firewall itself this is the only firewall.
The only pbx traffic through this firewall should be the trunks to my SIP service provider. All extensions which register are able to successfully make and receive external and internal calls. There are no external extensions.

2 – All internal devices (printers, scanners, servers, PCs, mobile devices, phones and WiFi connections) are on the same subnet … 192.168.1.0/24

3 – There is no NATing other than for the WAN->LAN gateway at the firewall, so local traffic is not affected by any NAT as far as I am aware.

4 – freePBX runs on a VMware ESXi VM on this same 192.168.1.0/24 as do several other servers all operating perfectly. I have several different servers operating web traffic which some of which is restricted from external access. There are no known issues with ports being sent to the wrong server/IP address. This may be relevant for point 5 below, or it may be that I misunderstand some networking points …

5 – The installations of 3CX and Ombutel I made are also on VMware VMs on the same subnet, but as they are different IPs with no NATing, I believe that should not be an issue. Neither installation has any trunking and is being used exclusively to test/compare the success or otherwise of local SIP registrations. I have disabled freePBX to test 3CX trunk registration successfully, before disabling the 3CX trunks and reinstating freePBX. As no calls were being attempted I made no change to the perimeter firewall to test the 3CX trunk registrations (which still registered fine). Most (but not all) of my registration tests have been conducted with only one PBX turned on at a time, this seemed to make no difference.

6 – On freePBX, existing SIP extensions using the originally configured hardware continue to operate fine. New SIP extensions fail to register. Existing SIP extensions with new hardware also fail to register. 3CX extensions register immediately (including existing working freePBX extensions which then reregister with freePBX just fine when pointed back at freePBX)

7 – tcpdump port 5060 produced the following (part only)

12:10:25.900036 IP fpbx.pchmt.net.sip > sipgate.co.uk.sip: SIP, length: 539
12:10:25.939275 IP sipgate.co.uk.sip > fpbx.pchmt.net.sip: SIP, length: 402
12:10:27.231410 IP sipgate.co.uk.sip > fpbx.pchmt.net.sip: SIP, length: 4
12:10:39.536475 IP sipgate.co.uk.sip > fpbx.pchmt.net.sip: SIP, length: 4
12:10:41.425783 IP sipgate.co.uk.sip > fpbx.pchmt.net.sip: SIP, length: 4
12:10:46.270267 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:10:46.782456 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:10:47.815251 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:10:49.846166 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:10:50.861145 IP dp2.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 4
12:10:53.731844 IP sipgate.co.uk.sip > fpbx.pchmt.net.sip: SIP, length: 4
12:10:53.876282 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:10:55.624942 IP sipgate.co.uk.sip > fpbx.pchmt.net.sip: SIP, length: 4
12:10:56.315175 IP fpbx.pchmt.net.sip > dp1.pchmt.net.sip: SIP, length: 571
12:10:56.340589 IP dp1.pchmt.net.sip > fpbx.pchmt.net.sip: SIP, length: 496
12:10:57.903790 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:11:01.935378 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:11:05.966053 IP dp5.pchmt.net.na-localise > fpbx.pchmt.net.sip: SIP, length: 507
12:11:07.928274 IP sipgate.co.uk.sip > fpbx.pchmt.net.sip: SIP, length: 4

dp5 is the failing extension device, dp1 and dp2 are successful SIP connections. What does na-localise signify?


(Paul Hermann) #11

Ummmm Apologies to everyone! I have found the problem(s). In case anyone else has a similar issue and comes across this, here was the problem.
1 - I THOUGHT I had whitelisted the ip addresses, but had not
2 - when (1) was combined with a quite tight security setup, it would not allow the phones to register
3 - when I did subsequently whitelist, it didn’t work initially which really threw me (I forgot I needed to restart the IDS service - I am going to blame a less reliable memory coming with increased years …)
4 - I am stupid and should not be allowed anywhere near a computer :frowning:

Thanks to all those whose patience I have tried. Sometimes the person you try to help is too stupid to warrant your time. Please accept my humble apologies.

Everything is working sweetly again …