Rob, I appreciate the detailed info, I’ll go ahead and do this in a couple days. Its relatively easy to do since I can export/import the extensions, but I am having a hard time finding the logic in this request. To me, this course of action is based mainly on the assumption that:
-you should never deviate from the default port ranges…
-NAT is involved for phones on the same subnet as the system…
-The codec change fixing the issue is not significant…
I’ve deviated from the default port ranges for years on hundreds of installs, never once having an issue with NAT (admittedly, this is technically “beta”. The main reason I’ve done this is to trim up the obscene 10,000 port count assigned to the box (IT security folks hate having such ranges open). I also have not heard a good reason why it’s assumed NAT is even involved in this workflow when the issue goes away with a codec change.
I’ll hold off on this rebuild for a couple days to see if anyone else has any thoughts, since it works fine on g711u (a change we make on the system, not the phones, which fixes the issue) - it can still function just fine in the lower definition codec. My mind makes me think the issue lies more in the software bundle that makes up the 722 codec library on the system (wording probably isn’t right, as I don’t know how those codecs are loaded/embedded in the system, but that seems a more logical location for the issue to me.
Unless you have a valid need to. That’s correct. By doing so, you’re just adding extra, and unneeded complexity. Don’t go out of your way to make things hard for yourself.
Again, something crazy is configured on the machine to make it need this. I don’t know what you’ve done to make it, and I - honestly - can’t even imagine why this would be happening.
That’s a symptom of your other problems. It’s a handy one as it’s simple to check.
Uh? That’s the standard for RTP ports. It’s not like it’s something unusual. I mean, it’s not like it’s a requirement, and the odds are things will work perfectly if you change it, but there’s no need to change it.
Then that IT security person is making a pretty fundamental mistake. The entire point of having such a large pool of ports is to make the rtp ports more random. By limiting the range, you’re making it less random. Ignore anyone who says that. They’re wrong. In fact, they’re fractally wrong – the closer you look at it, the more incorrect it is. It’s wrong all the way down.
As I said at the start, it’s not Asterisk. Asterisk works. I did suggest you try a different type of phone, how did you go with that?
But I would have thought you spending 10 minutes to quickly deploy a new machine to prove me wrong would have been a easy thing to do, too
I also experienced a very weird issue with G722 causing one-way audio on version 13.
I ended up disabling G722 everywhere. However, while investigating the issue and looking at the SDP messages (best way I know to see if it is some NAT issue), I saw that all IP addresses on SDP were correct but indeed my grandstream phones were often using ports in the 40000-50000 range, but the Yealinks were doing fine and suffering the same problem.
I never do any manual conf of my SIP phones, I have Endpoint commercial do that for me and I do not remember ever changing RTP port ranges from default (why would i?).
Anyhow, I never got to the bottom of this issue, but indeed it was just a matter of turning off G722 and my issues were gone.
I never opened any ticket because I was sure no one would believe me. Only some SIP phones were affected, but they were all on the same subnet, with same firmware, provisioned from the same template from EPM.
The down-side to just disabling 722 is that you don’t get to use the HD-audio codec. Sure it “fixes” the problem, but at a quality loss. I thought it was very cool that FPBX13 now offers the ability to transcode uploaded audio files into one of several options, so you can always make sure the optimum sound conversion is being played to the user. Very nice.
However, that did make me think maybe something’s off with “transcoding” (since voicemail sound files aren’t normally delivered in 722 format). I just tested calling into a queue that I had uploaded a sound file that I chose to convert to 722 - still no audio, so I guess that wasn’t it.
The other thing that popped into my head is that when I build a new server, it’s placed on a temporary IP, then “swung” into service. Maybe there was something funky with the System Management module’s changing of IPs that made it miss a spot (though I still say that shouldn’t be impacted by what codec is used).
Rob, sorry, I missed the “try another phone”. Tried a Linksys/Cisco 525 this morning - same issue (only on 722).
Loaded a new server this morning and imported my stations - none of them showed up in the PJSIP driver under asterisk status, so that was odd. And as much as I’d like to think it was something in the exported data, I then fresh-loaded the box again (anticipating pushback on the import) and GUI-built a single extension, which also didn’t show up in PJSIP… In the past this has been a function of something unsupported in the station config, but since this was a fresh build, it sure shouldn’t have failed to build a new station.
Looking at the PJSIP endpoint files - FPBX isn’t generating the configs - they’re still blank.
Out of curiosity I tried again and tested *43 (echo) with G722 enabled, I could hear my voice being echoed to me, but I could not hear the initial talking that explains the echo test (it was all silent).
You know, I completely forgot she talks to you first to explain the test, so my initial echo test probably didn’t work specifically because I didn’t wait long enough - After waiting 20-some seconds, I actually get the exact same thing you get. After she “finishes talking”, I hear myself just fine - and its in HD audio, as I’d expect.
I just experienced this same problem today. In my case, I decided to give Asterisk 13 and pjsip another shot, as I previously experienced issues and settled on running Asterisk 11 with chan_sip. Anyway, I made 2 changes:
Switched from Asterisk 11 to Asterisk 13, but kept FreePBX 12.
Changed each extension from chan_sip to pjsip.
After making those changes, I rebuilt the config for all devices and rebooted all of my phones. After doing this, I started having issues with receiving no audio from the voicemail when I dialed an internal extension. I had no problems when speaking extension to extension using the g722 codec, it was only with voicemail. Incoming and Outgoing phone calls also worked fine because my sip trunk provider was configured to use ulaw, not the g722 codec.
For the most part, my system is fairly standard. I haven’t changed any port assignments or anything of that sort.
So, it does seem that there is some problem with Asterisk 13, pjsip, and the g722 codec. If there is anything I can do to help, please let me know.
I’m going to create a PJSIP Extension, that only allows G722, and I’m going to connect to it from a SPA504 phone, as I have plenty of those handy (Edit: Used a softphone, so I could record everything) I’m then going to dial *43, and then hear Alison’s lovely voice.
If it doesn’t work I’m going to be amazed, but, I’ll figure out what the problem is.
They fixed this this afternoon. RC19 I believe, but it was indeed an issue that came out yesterday (as the last time it worked was yesterday afternoon before a series of updates).
now that I can make new extensions on the new system, I’ll re-test - that’s the only reason I couldn’t test on the fresh build (because they broke PJSip config writing yesterday - but have since fixed it).
There’s nothing about PJSIP in the changes. @tm1000 is working on HTML5 stuff for Recordings, and I’m usually the guy that does PJSip stuff, and as far as I know, nothing has been touched in pjsip in ages.
This is what worries me - you seem to be having a huge number of totally inconsistent and incomprehensible issues.
Let’s try to stay on topic folks. Yes RC1.8 was semi-related to this but it broke all configurations. This is still about g722 and one way audio, which has nothing to do with configurations which is not a freepbx issue.
In the Endpoint Manager, I rebuilt the config files for every endpoint and rebooted them to make sure any necessary changes were applied to the devices, just in case that could be causing the problem.
Interestingly, I decided to try this from a softphone as you did in the video. Guess what? It worked as expected. I was able to dial *43 for an echo test and could hear the recording with instructions with no problem. However, it still will not work using our desktop SIP phones. For reference, I am using Yealink T48G and T46G phones.
Rob - I would be curious if you could retest using one of your desktop phones…
