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


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!


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). :smile:

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… :wink:

Thank you and have a nice day!


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.


  • 1 Grandstream GXP2160 w/ firmware
  • 1 Mitel 6865i w/ firmware
  • 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
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

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.


That’s actually consistent with what BullFrog noted here: here: FPBX13 RC, G722 and 1-way audio - even to voicemail

Thank you!

We are definitely getting somewhere now with your tests, Rob’s observations and what Bullfrog had noticed…

Have a nice day!


Another data point, ran into this ‘feature’ again today on an HTEK UC806 with firmware ver. No audio until I forced it to use g722.

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.

Hope that helps!


Hi and thank you for your analysis of the problem!

Sounds like déjà vu

(I had similar problem for other network related RFCs…)

I am trying to convince some people (look in the “blog section”…) which are in a position to at least report the problem to do do but I have been unable to convince them to do so…

Thank you very much for your help and have a nice day!

Season’s greetings!


You can report it yourself. We have no priority because we work for Sanomga. Please do not think that. It’s a community project.

(sorrrry for the delayed reply…)

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…

Have a nice day and Happy New Year!


Worked for me. Thanks

Is this still an issue. I just bought the Yealink T46G phones and am having the same issue when setup with pjsip extensions. Working fine with chan sip.

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.

1 Like


https://issues.asterisk.org/jira/browse/ASTERISK-26423 is closed…

This is, as far as I know, the ticket that addressed this problem on Asterisk’s side (though I believed they still considered it a phone problem)…

Have a nice day!


1 Like

Mabled, you are right. However, it has not yet been tagged to any future release of Asterisk so it has not been released yet nor we know in which version it will be released.

Hopefully, it will be soon.