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.
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…
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…
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.
Testing with Yealink T28P has exact behavior of the Grandstream. Making changes only to the codec priority on the phone (not to the PBX), it would never properly negotiate audio if both ulaw and g722 are included in the codec list, regardless of order. Remove one or the other and audio always works.
Whoa kids… this thread has generated a great deal of heat relative to light.
Part time outside Asterisk developer here.
The issue here, and the complexity around reproducing it, has to do with a common misreading of the SIP specification by a number of handset manufacturers, one that almost ironically may stem from hardware product development done against older versions of Asterisk itself.
In SIP, there is no requirement that your read and write codecs on a two way audio call leg need to be the same. When you configure a PJSIP endpoint to have ulaw and g722 (and your phone’s initial invite SDP contains those codecs), Asterisk properly assumes that the inbound RTP stream to the phone could be either codec, though the send SDP negotiation has determined the sending codec.
Asterisk is properly trying to avoid transcoding by conforming to both what the PBX configuration of the endpoint has said is allowed and what the device itself has confirmed it is capable of. It happens that a number of sloppy handset manufacturers simply expect to receive the codec they are sending on the ingress-to-handset RTP leg and just drop that RTP stream if it doesn’t meet format expectations. The real issue here is really with manufacturers of these devices. From my limited testing, Polycom, Digium, Aastra and most common softphones conform to the RFC and will work properly. Yealink, Grandstream, and Snom all improperly implement their SDP media expectations, giving you one way audio.
The immediate workaround is to simply restrict either what the phone sends via its own allowed codec configuration or to do what has been suggested in this thread, and lock the endpoint to g722.
It would also be great to put some pressure on these non-conforming manufacturers to do testing with Asterisk 13 + PJSIP in this configuration to see the issue for themselves. At least some of them should acknowledge the issue and produce corrected firmware.
While not necessarily the correct solution, in the interest of pragmatism, if enough people are interested, I might be willing to produce a patch to Asterisk 13 that would surface a new knob to resolve this issue in the Asterisk core. Let me know if there’s an appetite for this and we can discuss.
I didn’t mean to report them to Digium but actually to Yealink since the problem is most likely in their firmware and FreePBX/Sangoma now having a more direct access to their engineers was in a perfect position to do this.
Preston has contacted Yealink about this so hopefully they will be able to replicate the problem and since they have access to their phone source code they will most likely more easily find what might be causing the problem (what joshelson mentioned seems pretty logical, hopefully this is what they will test first).
As to reporting a problem to Digium, you guys (ie FreePBX/Sangoma developers/employees) have a much higher credibility than most of us as far as these things are concerned so I am sure that it would definitely help.
Before you say that’s not important to have that kind of credibility I once reported a problem to an open source/community project concerning the non-respect of an RFC and got my ticket closed by someone who thought their interpretation of the RFC was correct…
I actually had to contact and ask for the help of the RFC author to have them reevaluate the problem and agree that there was a problem with their interpretation of that RFC.
(This was an email related RFC by the way… Quite a few years ago I “played” a lot with mail servers at work…)
Hopefully not all open source community projects are like that (I sure hope the one I a dev on never gave people that impression) but every little bit of added credibility helps and you guys have a lot more than most of us…
Yes, still an issue. Tested with .95 Yealink firmware and it is not fixed yet. Grandstream has not fixed it either.
Maybe we need to wait until PJSIP is more popular for the firmware developers to start feeling the pressure to get this fixed.
Contrary to what has been said here, the issue is very easy to reproduce, but one does need to be on PJSIP and have both u/alaw and g722 enabled in the codec list both on FreePBX and on phone. Then run the echo test (*43) and most likely you will not hear anything for the first ~23 seconds which is when a voice was supposed to play explaining how the echo test works. After that you will start hearing the actual echo test (whatever you say is played back to you).
I believe that the explanation message is encoded in a format equal to or similar to a/ulaw so Asterisk prefers to send it using a/ulaw format. However, during the echo test itself, when the phone is sending the voice using G722 it is likely that Asterisk is preferring to play it back using G722 which avoids transcoding. Just my guess, not an expert in how the codec encoding/transcoding work under the hood.
Well that stinks. I just recommended the T46G phones for someone I just built a a system for and couldn’t for the life of me figure out what was going on. It was also my first time using pjsip for everything so I thought I was doing something wrong. In my case, I only had 722, ulaw and 729 enabled. I disabled alaw, but still have the problem.
I have a support ticket with Yealink, but I’m assuming you already went that route.