FPBX13 RC, G722 and 1-way audio - even to voicemail

Beta Program Issues
,
1

Good afternoon all. I had initially opened this as a bug for the FPBX 13 RC, but was told this wasn’t a bug at all and that I clearly need assistance from support or the forum. Personally, I don’t believe that’s true, but hey, I’m game - because this is just too weird. So, here goes:

Endpoints are Grandstream 3240/3275/2140 sets. Phone configs haven’t been modified from old FPBX system (no tweaks to the SIP settings).
We are using PJSIP for the endpoint drivers.

Phones calling something as simple as voicemail hear nothing (but they can transmit sound - so they can leave a voicemail). This 1-way audio is also occurring on inbound/outbound external calls. Station to station calling works fine (but paging does not). Dialing a feature code also is silent (no prompts, no beep).

I was able to narrow it down to having G722 permitted for the endpoints. When G722 is allowed, we get 1-way audio, when its disallowed (removed from allowed list), we get 2-way audio (granted, at the next codec in line - 711u/PCMU).

Since this wasn’t an issue on FPBX12 with the PJSIP driver, I’m very much inclined to say this should be classified as a bug, but my ticket was abruptly closed.

Phones and system are on the same subnet, so no firewall blockage or anything like that (and again, phones worked fine on FPBX12/PJSIP with g722).

Does anyone have any thoughts on how I could have possibly screwed up a fresh install to create 1-way audio directly into the system (where STUN/NAT isn’t in the mix)?

Thanks.

2

We say these things aren’t bugs when we (support + developers across the globe) actually test and can’t duplicate. In this instance we tested your issue and can’t duplicate it. In fact @xrobau runs with g722 all day long using FreePBX 13.

I’m sure this functions exactly the same as in FreePBX 12

3

That is very odd. If I change my phone’s server address to the old box, it works great on 722. When its pointed to the new box, the endpoint gets dead air (unless you disallow 722).

Is there anything I could look at to find out why the “13” system doesn’t like it, but the “12” system does?

4

This is a NAT issue. Check your forwarding rules. You probably have something trying to auto detect where to forward traffic.

5

one-way audio problems are always an Asterisk configuration issue. Are you sure you setup nat correctly for this extension? Really one way audio is NEVER a freepbx issue.

6

Phone was set to NO NAT, and it’s an internal call to voicemail. Local subnet is listed in FPBX so it’s aware that’s local (not to mention the server’s in the same scope as the phones so it shouldn’t think NAT is necessary).

7

What happens when you use *43?

8

For me, the echo test is *90, but that is also dead air. But as I said, if I call voicemail, I can leave messages, just not hear the prompts. Basically, anything that requires the server to be in the call somehow, I can’t hear it (station-to-station’s direct audio is fine - for obvious reasons).

Switching to G711u works - if it were a NAT issue, codec change would have no effect (i presume).

9

The echo test literally returns the data that was sent to it. Have you tried a different phone?

But stop messing around with voicemail and stuff - echo test is the first thing to get working, and it’s easy to check. You’ll also see that there’s very little dialplan involved, so you can paste logs easily.

But it’s sounding more and more like your phone is confused.

10

There’s really not a lot to screw up in that though.
External IP: my static IP
Local Networks: 192.168.1.0/24, 192.168.2.0/24, 192.168.101.0/24, 192.168.102.0/24 (the one actually involved here is the 192.168.101.0 scope)
Port Ranges (49152-49999) - but this should only be used when going outside the firewall, which a voicemail call would not.
I’ve tried two STUN servers, and when they’re bad/empty, I can’t even get the call to ring in (for obvious reasons).

And I still come back to, a codec change wouldn’t affect NAT, if it were in play.

11

Woah… That looks amazingly and awfully wrong.

Put that back to 10000-20000. There’s no reason to change it, unless you have another SIP server behind the same firewall. And if you have two sip servers behind the same firewall, you’re going to be having strange and awful problems like you are now.

Edit: You also should not be using STUN or anything, if you’re on the same network segment. Maybe you should just reset your phone to defaults, add the extension back in and don’t change anything else and see if that fixes the problem.

12

That’s precisely why I changed it. Its now in the dynamic port range instead of a range that other systems occasionally use. I’ll switch it back for giggles, but again - internal call - no NAT - outside calls work great on G711.

I want to make sure we’re not going down a rabbit hole because something isn’t the way we’re used to seeing it because a change in codec shouldn’t have any impact on NAT.

13

As the evidence suggested, port range back to 10000-20000 had no effect. I’ve put it back since that didn’t have any effect.

14

I’ve already defaulted a phone - no effect. Please explain how changing a codec impacts NAT? Also, why NAT would be in-play on same-subnet calls? And lastly, if it were an issue on the phone, why I can register it to the old server (no other config changes but the server IP) and it work fine on G722.

15

I agree - changing the codec makes no difference at all. But there are some holes in your story. You’re saying that without STUN, you can’t make a call at all - but, you then say you’re on the same network.

Those two things don’t make sense. If you need STUN, then there is a firewall in the way, and NAT.

You’ve also changed the RTP ports that “is in the dynamic port range that other systems occasionally use”. That … worries me too. What other systems? Why does it matter? Is it going through NAT or a Firewall after all? You said it wasn’t.

You appear to be doing an amazingly good job of overcomplicating things. This always leads to trouble, as you are now encountering.

16

External Calls don’t process when STUN server is removed. Internal works fine - station to station works fine whether STUN is populated. With or without STUN populated no calls process when Asterisk is in the mix.

17

How are you making calls without going through Asterisk?

18

Since phone-to-phone calling sends media directly between the endpoints, those calls work perfectly. However, when there is any type of call where Asterisk is involved in the media (calling voicemail, calling a feature code, external calls in or out), paging calls, announcements in a queue before the agent answers, these all are silent.

19

And to clarify - as you said, changing the codec “should” make no difference at all… But it absolutely, positively does. That’s how I know it’s not a NAT issue.

20

Shrug Sorry. You’ve changed a bunch of stuff on your machine. This has caused stuff to break - eg, the requirement for STUN.

I know for a fact it works, as I use Asterisk 13.5 with FreePBX 13 and G722 as my primary phone system.

From here I suggest you start doing some tcpdumps and check the sip headers coming from and going to the phone.

Another option is to deploy a NEW machine. Don’t change anything that you don’t have an EXTREMELY good reason for changing (eg, RTP ports.). Probably the only thing you want to change is to go to SIp Settings and move G722 to the top of the list there.

Then, try with a phone to get *43 to work. If, on a fresh built machine, with no changes, it doesn’t work, I will happily spend any amount of time figuring out what the problem is.

But I know it will work, because I normally build two or three new machines a day with Ast 13 and G722, and they all work. If you have somehow found a way to make it not work, that’s really REALLY bad, and I care deeply.