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.
Hi!
Thatās actually consistent with what BullFrog noted here: here: FPBX13 RC, G722 and 1-way audio - even to voicemail - #54 by Bullfrog
Thank you!
We are definitely getting somewhere now with your tests, Robās observations and what Bullfrog had noticedā¦
Have a nice day!
Nick
Another data point, ran into this āfeatureā again today on an HTEK UC806 with firmware ver. 1.0.3.91. 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!
2 Likes
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!
Nick
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!
Nick
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
Yippee!!!
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!
Nick
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.
Donāt worry, I knowā¦ ***
If I read the commits correctly it was committed to master, the Asterisk 13 and the Asterisk 14 branch so itās not like it was only committed to master and not yet backported to the other branchesā¦
That means that the next time they tag a new Asterisk 13 or 14 it should contain the fix (unless they revert the commit).
Have a nice day!
Nick
*** I am an IT guy and also a dev for a relatively well known open source app so I know a thing or two about the release processā¦
1 Like
Now tagged as target releases 13.13.0 and 14.2.0.
Hmm. I just installed 13.13.0 two days ago and ended up finding this thread just now because Iām having the exact same issue with my Yealink W52P. So either the fix didnāt work or it isnāt actually in 13.13.0.
Can anyone else see whether it was fixed for them in 13.13.0?
THANK YOU !
I had the same problem : pjsip, asterisk 13, no sound one way from incoming call. The communication was correct both ways during 1 or 2 seconds and after that external caller stop hearing from pbx.
It was not an Asterisk or nat problem but a codec bug in phone (Grandstream GXP2170).
I upgraded the phone to the last firmware (1.0.9.69) and it is now working.
This topic was automatically closed after 2 days. New replies are no longer allowed.