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!