1

FreePBX 14, VoIP.ms, Yealink T42G/T46G, varying firmwares. I’ve noticed a few things:

-one, calls aren’t reliably hanging up. I have a DID to my desk phone. If I call it using my cell, answer, and then hang up, the Yealink hangs up. If I do the same thing, or dial my cell with the Yealink, and hang up the Yealink first, my cell stays connected. I had the same thing happen with an internal (extension to extension call); the other end hung up but my Yealink thought it was still connected.

-Two, two of the T46G’s have expansion modules connected, with a BLF for every user. With no one using the phones, it has red lights next to about 15 of them. These phones are on the latest firmware.

-Three, on the dashboard, the FreePBX statistics looks inaccurate. The users online and offline is correct, but it says there are no trunks online (my trunk is working) and that 38 channels are in use. Anyone seen that since upgrading from 13 to 14? I’m not sure if it’s the upgrade or something else; I upgraded it before all the phones arrived and were connected.

5 Spice ups
2

Sounds like issues with NAT, but I thought your system was all local (from another thread).

Can you clarify?

3

Yeah, I’m running it locally.

4

I do not show any of those issues on my PBX (the only one I upgraded from 13 to 14).

My PBX is hosted on Vultr and using T42G and T46G phones at everyone’s home office.

The dashboard shows the right information. Obviously we are not busy on the phones today.

Selection_999(546).png

5

With your trunk, here is how I setup my SIP trunk to VoIP.ms for comparison.

Outgoing

username=my_sub_account
type=peer
trustrpid=yes
sendrpid=yes
secret=my_sub_account_password
qualify=yes
nat=yes
insecure=port,invite
host=chicago3.voip.ms
fromuser=my_sub_account
disallow=all
context=from-trunk
canreinvite=nonat
allow=ulaw

Incoming

my_sub_account:my_sub_account_password@chicago3.voip.ms:5060
1 Spice up
6

For your weird BLF status issue, are your SIP settings setup correctly?

Settings → Asterisk SIP Settings should have your External IP correctly and your internal network LAN since you are local.

For my hosted here is what it does by default (and yes I forgot to restrict the Local Network last year when I set this up. oops.)

Selection_999(547).png
Selection_999(547).png800×642 90 KB
1 Spice up
7

Thanks, I’ll double check things on the trunk though that’s been working well since I changed it from PJSIP to SIP. I can reliably get the no hangup issue dialing extension to extension though.

8

Yeah, that’s how mine looks, though with the internal LAN.

9

Are your extensions programmed as SIP or PJSIP? If SIP, what is the NAT setting in the Asterisk SIP Settings under the SIP tab?

1 Spice up
10

The extensions are all PJSIP.

11

Well, then I am a bit stumped without being in the system and poking.

12

The only other factor I can think of is it’s on a voice VLAN, but everything there works - phones get assigned to the VLAN and provision, everything else is working well. It’s just these oddities.

13

well, you could put a phone on the production network and see if it’s any different.

1 Spice up
14

I was hoping to avoid that, but if I have to I will. The PBX and phones are on that VLAN though so nothing should be getting in the way. It did start out on the internal LAN, so I was wondering if I missed changing an IP somewhere, but if I did I’m not seeing where.

15

You don’t gain anything by having a VLAN for voice, personally I’d go back to a single LAN, zero VLANs. Just one fewer thing to be in the way.

16

If you have a separate subnet, VLAN or not, then you have potential issues.

If you are confident that you setup the VLAN and subnet routing correctly, really all you can do is collect packet captures and look at it all in wireshark.

17

How could there be issues? The VLAN is completely isolated from inside and FreePBX and the phones are the only devices on it. I could see if the issue was solely inbound/outbound or if the server was on inside, but I’m curious why this could be?

18

I won’t speak for JB, but I don’t believe your VLAN is related to your issue at this point. But having it just tosses in a maybe. So having it just makes things more complex, needlessly.

19

Yeah, I don’t either, really. I did change to that and upgrade from 13 to 14 around the same time, so if it’s either I would guess the upgrade.

Regarding the VLAN, we are under NIST 800-171 and were advised it’d be best to use a VLAN. I know it makes the setup more complicated but I can easily show nothing can access voice that doesn’t need to and check off one more thing for the security plan.

20

Unless you’re doing SSL to the SIP provider, anyone sniffing that traffic on the internet can see your voice. And once it enters the PSTN, anyone there can too. The old school voice network is completely unsecure.