Sure. I did it both ways you described and didn’t have an issue. Which is why I didn’t say anything (actually I was trying and @lgaetz was trying and @xrobau this morning. Before your next reply). I stand by my statement. In fact this isn’t an Asterisk issue at all, nor is it a FreePBX issue.
[quote=“Bullfrog, post:56, topic:31042”]
In fact, the whole nature the community exploded right after we purchased some Commercial Modules.[/quote]
I would just like to point out that it has no relevance if you have, or have not, purchased modules, and I don’t like the insinuation. I am even hesitant to recommend people to use commercial support in IRC, because I believe I’m abusing my status by doing so. I’m just going to take it as you saying ‘I’m doing my best to support the project’, and I appreciate that, but I tend to get a bit fidgetty about peoples passive aggressive, backhanded accusations, ESPECIALLY when you say this next:
There is no ‘FreePBX/Sangoma vs Ward Mundy’ debate. There is just Ward Mundy doing his best to abuse, discredit, and disrupt the FreePBX project. He has taken this so far that one of our developers had to create a new facebook account, and he’s publically posted other developers personal information - in fact, just the day before yesterday, he linked to @drmessano’s Google plus page, because … I don’t know why. And it’s not like drmessano is a developer, he’s just someone who knows how freepbx works, and offers free support in IRC.
I honestly have no idea what Ward’s trying to achieve by destroying the project that he bases HIS project on, and it appears amazingly counter-intuitive to do so. However, this is open source software, and if he wants to try to destroy it, then that’s his choice.
I ignore what Ward says, I ignore his tweets. I don’t block him on Twitter because I don’t think it’s fair that he would need to log out to see what (FreePBX-related) stuff I tweet about. We write open source code .We give it away. We care.
We, honestly, try to be the good guys. Quite a few times I’ve actively asked the rest of the guys ‘Are we wrong? Are we NOT being the good guys?’. Being yelled at for doing stuff wrong is awesome. Because then we KNOW we’re doing stuff wrong. But being yelled at for NOT doing stuff wrong, or even worse, being yelled at because he fundamentally doesn’t understand how FreePBX works, is emotionally draining.
So, I apologise for that rant, but that’s how I see things from my perspective. When he says ‘Module signing isn’t open source’, for example, and he is fundamentally wrong about that, and refuses to admit it, what can I do? It’s open source. It’s documented. He can do exactly what we do, with the tools we provide. Yet he claims he can’t.
This probably should have been ripped out into a different thread, but @tm1000 (who is literally sitting across the table from me at the moment) just grabbed me and said ‘More G722 issues’ and this was the first thing I saw.
On the downside, he’s literally just followed the instructions he gave, and didn’t have the problem. Even with the en_gb prompts.
@lgaetz (sitting next to @tm1000) suggests that it may be phone related, which sounds much more reasonable. That was the first thing I suggested, way up at the start of this thread. Try it with a different device .If it works with a different device, then it’s the device, or, asterisk.
Edit: Proof of @tm1000 actively trying to duplicate this:
Either way, it’s not a FreePBX issue. All FreePBX does is write the configuration files. Asterisk is what actually does the transcoding. We’re not trying to dodge the problem, we’re just saying that we can’t duplicate it. If we can’t duplicate it, we can’t fix it.
Thank you for the reply. I appreciate that you have confirmed you duplicated the scenario as best you could without the same result
To address the balance of this unfortunate turn of events:
@tm1000 - I was simply noting your quick confrontational reply where you attempted to argue that you weren’t being confrontational, without answering my simple question about your method of configuring the test in FreePBX. The irony was pretty awesome. Of course, your edits to your reply to me and your edits to my reply to you erased most of the evidence.
It is obviously pretty difficult to disagree with you on your own turf… especially when you have the power to remove the evidence from your reply and my quote of your reply. (I realize anyone can read the edits, but really, who is going to do that?) I can’t remove my words from your posts where you quoted me. Therefore, I’ll leave my comments in place.
I’m sorry I overreacted to your short response to my post. I was simply seeking clarification to the testing method you used. A simple confirmation would have been sufficient.
[quote=“xrobau, post:62, topic:31042, full:true”]
@xrobau - I agree with most of what you said. The community has obviously been able to observe the developments and draw their own conclusions. Many times I have read his words and recognized that he had gone too far. There is a very loyal community on his site and it contains a wealth of information that can benefit a person learning or troubleshooting Asterisk and FreePBX. However, the constant attacks are detracting from that reputation.
I have to commend Sangoma and the FreePBX team. Despite the attacks, Sangoma and the FreePBX team have not replied in kind. (Of course, I have no idea what has been said privately.) By refusing to retaliate publicly, the Sangoma and FreePBX reputation has been strengthened.
So, I apologize that my comments indicated there was a ‘FreePBX/Sangoma vs Ward Mundy debate’. It really has been one-sided. I intended to draw attention to the fact that things have changed over the last several months. Some good, some frustrating. I hope this all passes and is quickly forgotten. But, I also hope that the FreePBX team can appreciate they have millions of loyal users, and if we are made to feel as if we can’t discuss, troubleshoot, and ask questions, the support will begin to erode.
1 Like
Thanks for giving some meaningful feedback. It was very helpful. I was able to get my hands on an Aastra 6737i to test with. As you suggested, it worked fine. So, that leads to the fact that we know it doesn’t work on many Yealink models as reported in this thread. Also, there are these reports:
I’m not sure which 3 endpoints @lgaetz was using, but the problem has been experienced on Yealink, Grandstream, Linksys/Cisco, and Siemens. On the other hand, Aastra devices work fine. Is it possible this is a problem that affects many brands and devices?
@tm100 - That is a little different, you previously insisted this should be reported to Digium/Asterisk. Were you able to identify the problem? I would be interested to know what led you this new conclusion.
1 Like
When i experienced this issue, digium phone worked; GS and yealink didn’t. Will investigate further when I’m back home.
Hi!
Did they all code their G722 support from scratch or could they be using the same library (or something similar in concept to it, maybe even in hardware) to implement G722?
That might explain why all of them are failing while others are fine…
If G722 was a new protocol I would suggest this is an error in interpretation of something in the protocol by many manufacturer but as it is relatively old it’s kind of weird they supposedly all got the same thing wrong…
So it’s either all of these manufacturer getting something wrong, all of them using the same library (or something similar) or hardware or Asterisk having a problem with how they implemented G722…
edit: I found the following comment on Wikipedia interesting: “Consequently correct implementations represent the value 8,000 where required but encode and decode audio at 16 kHz.” ( G.722 - Wikipedia ). What happens if they get that wrong?
Have a nice day!
Nick
I edited your post to remove my snarky comments that had no relevance to anything. I can undo the edits but I don’t know what that would solve. It would just show my snarky comments (I didn’t remove your actual response. Nor did I remove any words of your own. Just my comments)
Seems as though you only have a problem with me in this thread but not with others. Sorry.
Edit: The posts were later restored. This was a mistake on my part. We are all human and I apologize for what I did. I shouldn’t have edited the post.
@tm1000 - Read my post again. Take your time, read carefully. I clearly said:
- You removed your snarky comments from your reply to me.
- You edited my post where I quoted your snarky comments and removed your words.
My point was, since you can remove the evidence from anyone’s post that you were confrontational, there isn’t much point in disagreeing with you. You can go to town to make sure anyone coming along later sees what a nice person you are and what a jerk I am. While the evidence above no longer shows it, you and I both know it isn’t true.
What is frustrating is that although you claim you are being helpful, trying to fix anything that can be identified as broken, you keep ignoring legitimate discussion on the topic and keep pointing the finger back at me. Again, if you read my last post, you will see I asked you a question:
You changed course. You firmly stated FreePBX was not the cause of the problem, and the problem should be reported to Asterisk/Digium. Something made you determine that this is not an Asterisk issue. Since you took a firm stand that it is not a FreePBX issue, nor is it an Asterisk issue, you must have based that on something you learned in your testing. Do you care to share it with us? What moved you to eliminate Asterisk as the problem? Did you identify where the problem lies?
You may also recall that I made note that the community had become confrontational and condescending. This is a prefect example. You apparently have some new information, but it is beneath you to share it with us? Stop arguing and answer questions about the discussion topic.
The problem is outside FreePBX. That’s what I am implying. I don’t think it’s an Asterisk bug anymore because I tried it on a Yealink T38g, Grandstream GXP 2200, Digium D70 and a couple of soft phones.
Look. I am saying the same thing. Above earlier before you pointed the finger at me that’s what I was saying over and over again and you got offended at that. Therefore I didn’t think it was productive to say “it works for me” any longer unless it wasn’t. But you also don’t seem to like that?
I never changed course. I said the issue isn’t FreePBX. It appears to be Asterisk. Then I said I don’t think it’s Asterisk. You are twisting my words around. I tested this in front of and with @xrobau and @lgaetz. In fact I asked them to work on it with me.
There is nothing I am not sharing. We (Rob & Lorne and I in person) discussed it and this thread for a good 30 minutes to an hour. Everything that I’ve done has been shared by Rob or Lorne or myself. I’m NOT hiding anything. If anything I’ve encouraged people to work on this thread (you don’t see that from YOUR perspective). By calling both Rob and Lorne and asking them to test individually and then when we are in the office. For you to assume or propose I am trying to hide something and/or therefore I am confrontational and condescending is strange indeed.
In case you want to know I’ve done your EXACT test. With:
linphone
JITSI
Yealink T38G
Digium D70
GXP 2200
You obviously have a big problem with me. I’m not fighting with you. I’m not hiding anything from you. I’m not trying to be condescending. I even apologized. I just don’t understand what the problem is. (Well I do. I just don’t understand why me?). You seem to get along fine with Rob and Lorne. Even after Rob replied to your first post about me (and it was basically the same rhetoric I’ve said this whole time?). SO perhaps it’s just me. I don’t know.
If anything you are being condescending right back to me?
Because this is such a huge deal with you I have restored the post and my comments in full. I shouldn’t have edited my post and then your post. Have a nice day.
What we’re saying is ‘we can’t reproduce this’. We’ve tried it, following your step by step instructions, and it works perfectly.
At this point, we’re pretty sure it’s the phone you’re using. So you should probably be speaking to the manufacturer.
If we could reproduce it, we would fix it, work around it, or document it. All we have, at the moment, is a couple of people saying ‘G722 is broken’ - when we use G722 all the time, so we’re pretty sure it’s not.
So how about ‘you guys’ with broken G722 get together and try to find what the common factor is? You’re all using NAT? You have some broken firewall in the way that’s trying to do ALG and is getting confused? Your Network cards have a hitherto-unknown bug that’s cropping up on an invite?
There’s lots of things it could be, but until we (as in, @tm1000, @lgaetz or myself) can duplicate it, we don’t know what it is.
Even a complete system backup of a broken machine, so we can actually see it broken would be good. Anything to help us duplicate it.
Edit: I’m serious about the backup. But, before you send it to me, make sure you restore it, and check that it’s still broken.
1 Like
Folks, please. I started this post, not because I necessarily felt there was a direct problem in FPBX, but possibly a bug in the way it was configuring Asterisk - I’ll admit, I felt it somewhat annoying that the first thing that was called into question was some simple customizations around RTP port ranges, but I understand the troubleshooting process and how sometimes even the simplest (and unexpected) things can be the cause.
However, I’d like to share something I discovered earlier this week. Grandsteam has a HUGE bug in their G722 codec - specifically causing it’s RTP timestamps to be all out of sequence (to the point the audio quality can easily become garbage). The 32xx phones were hit pretty hard by it, but so were newer firmwares on the 2130/40/60. Sure enough, testing an older 2140 (pre 1.0.4.x) worked fine with 722 calling into Asterisk, while the 32xx and current firmwares of the 2130/40/60 have this “dead air” issue.
Perhaps Asterisk or PJSIP interprets these as invalid data, causing no audio to flow. I don’t know, but I don’t believe it has anything to do with FPBX anymore, nor do I necessarily believe it’s Asterisk directly (merely how Asterisk interacts with phones that may have an oddity in their 722 audio stream).
That being said, why doesn’t everyone take a deep breath, go back to their corners, and think about why we’re all really here. This is a great system, a wonderful project, and frankly something that the smart guys need to continue focusing on rather than feel attacked. I know when I get attacked repeatedly for doing really cool things, it lowers my drive - Not that that would happen in this case, but why even put those folks through that.
My .02.
Thanks Andrew and Rob for at least digging into this - I know I tend to have a hard time seeing the difference between FPBX and Asterisk (as they’re all bundled into a great package in my mind), but I very much appreciate your efforts in supporting my insanity. 
3 Likes
I have seen a packet capture of this happening, and did see something to this effect, so yeah, i believe it. Honestly, the solution to this (and the 10000 other problems involving grandstream/yealink/whatever is to stop using, selling, and recommending anyone use them. You will continue to have problems, there will continue to be close to or zero support from the manufacturer, and the model you’re using will be EOL’ed faster than literally any other brand out there. At this point, there are seriously competitively priced options from all the reputable manufacturers. The best part, of course, is that they will work and the manufacturer will support them. How neat is that?
Hi!
What do they all have in common?
- G722: All of them… Actually nobody reported the same problem with another codec which was not a misconfiguration of some kind, right? Why don’t we see this problem elsewhere? Does the use of G722 require transcoding which would not be necessary with another codec and could this be causing problems? Everyone having this problem can fix it by switching to another codec so if their servers were misconfigured in some way, shouldn’t it affect more than one codec?
As for the rest of the things that were mentioned in this thread, for some people we don’t know if they were using it or not.
PJSIP: kistiandg, Bullfrog.
Asterisk 13: kistiandg, Bullfrog, Starlifter. (It would be verrrrrrry nice to know what the others are using…)
FreePBX 12: Bullfrog.
FreePBX 13: kistiandg, mbello, Bullfrog, Starlifter, czworks
Grandstream: kistiandg, Starlifter.
Linksys/Cisco: kistiandg.
Yealink: Bullfrog, Starlifter, czworks.
CPU Architecture: no information at this time
NAT: no information at this time
A few things that stands out:
- kistiandg didn’t have this problem with the same phone(s) but with another server. That server was running FreePBX 12 and Asterisk 13 though maybe that version of Asterisk 13 wasn’t as recent as the one we are now using…
- Bullfrog has a workaround here: FPBX13 RC, G722 and 1-way audio - even to voicemail , did anyone with the problem tried it to see if it fixes the problem for them?
- Starlifter has the problem with Yealink T38G, Grandstream GXV3175v2, Siemens Gigaset VoIP DECT but his Aastra 6755i is OK… If it was a misconfiguration on her/his part shouldn’t it fail with all of the phones?
- czworks only has this problem when he wants to use British English. I am the one who pointed out to her/him that it sounded like it could be this problem but what does switching language have anything to do with this problem???
- lgaetz had the same problem but it disappeared after a restart and did not come back… Was it actually the same problem or did it only have the same symptoms and why did a restart fixed it??? Was it a lack of resources or some kind of memory corruption?
The problem is most likely with the phones or with Asterisk so the FreePBX version surely has no impact… However if Bullfrog workaround works then maybe there could be some way to, at least temporarily, try to do it at the FreePBX level maybe?
Unless someone can explain to me why so many different brands are affected like them using the same codec libraries or some sort of hardware implementation of G722 or something similar my bet is on Asterisk being at cause here…
By the way I see that mbello mentioned this problem on Yealink’s forum, maybe those of you with Yealink could add their voice to his there: http://forum.yealink.com/forum/showthread.php?tid=8330
Good luck everyone with this problem and have a nice day!
Nick
When I reported the issue, I was on FPBX 13/*13
The previous server that worked was FPBX12/*13, even though it was warned to be “experimental” (I like living on the edge). 
Thank you!!!
Do you still have that server? Since you talk at the past tense I guess not, right? It would have been interesting to know if Bullfrog workaround worked for you…
As in FreePBX 12 / Asterisk 13?
Any idea of the version of that Asterisk 13? If Asterisk is the culprit it would be something that was added after that version…
Me too, especially when it’s my home server… 
Thank you and have a nice day!
Nick
If we’re going to try to nail this down, we need all the information. I mean everything.
Complete Asterisk version, CPU Architecture, NAT or Not NAT, Phones that are playing up with explicit firmware versions… Everything.
(And I’m serious about CPU Architecture, is anyone not using 64 bit?)
Now testing with two phones with g722, one with audio, one without.
Environment:
- 1 Grandstream GXP2160 w/ firmware 1.0.4.23
- 1 Mitel 6865i w/ firmware 4.1.0.128
- Asterisk 13.5.0
- FreePBX 13.0.6
- OS: SHMZ release 6.6 (Final)
- Phones are local on internal NAT network, PBX is hosted on non-natted ip
- both phones registered to PJSIP extension 2006 on same PBX, didn’t test with chan_sip
- Extensions codec fields are empty
- SIP Settings codec set to ulaw and g722 only in that order
dev2*CLI> pjsip show endpoint 2006 *snip* accountcode : aggregate_mwi : true allow : (ulaw|g722)
Mitel audio works, Grandstream audio doesn’t.
links to logs:
Mitel log: http://pastebin.ca/3221725
GS log: http://pastebin.ca/3221730
1 Like
The Mitel asked for G722 first:
m=audio 3000 RTP/AVP 9 0 8 101 (Line 32)
The Grandstream asked for G711u.
m=audio 38976 RTP/AVP 0 9 18 2 101
That’s why the Grandstream isn’t working. It’s negotiating G711U, but then trying to use it as G722.
Edit: If you do a ‘core show channel [tab]’ and figure out the channel of the call, asterisk will think it’s G711, no matter what the phone says.
Edit 2: I bet the ‘but it works when I do xyz’ comments end up disabling every other codec so the Grandstream has no choice BUT to negotiate G722 correctly. That’s why it sorta kinda works, sometimes.
So knowing the above, I went into the phone config GUIs and made some changes with the codec priorities, but without making any changes to the PBX. The Mitel always properly negotiated audio, always using g722 (when configured) regardless of what I set the codec order to, and if g722 was not configured it would properly use ulaw. The GS phone would NEVER negotiate codecs properly if the phone codec list included both ulaw and g722 in any order. The only way to get audio to work was to force all codecs to either ulaw or force all to g722, in each of these circumstances, audio worked.
1 Like