Yealink Forums

Full Version: One-way audio issue with PJSIP: assincronous codecs
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi, following this discussion on FreePBX forums:

http://community.freepbx.org/t/fpbx13-rc...l/31042/51

It appears that Yealink phones are the culprit.

I captured pcap files that I believe will help understand the problem. The pcap is for a call from a Yealink T46g phone to an asterisk 13.5 box, the call is to the Echo service (*43).

The call should go like this:
- First, Asterisk plays a message that explains how the echo service works. This message lasts for about 25 seconds;
- Then the echo test begins and everything I say is echoed back to me.

Looking at the pcap, it happened like this:
- Asterisk on SDP offered codecs ALAW and G722;
- Yealink T46G offered G722 and ALAW;
- Asterisk started sendng G711 but then 1 second after, it switched to G722 to play the message. I could not hear anything that was played, the phone was silent;
- During this time while asterisk was sending audio in G722 format, the T46g phone was sending back in G711 format;
- After the initial announcement played, Asterisk went back to sending audio in codec G711 and I then could here the echo test.

Other notes:
- If on Asterisk I make G722 the first option than everything works fine.;
- With exactly the same codec priority as set on the T46g, my Bria Android client worked just fine and I could hear the announcement;
- However, grandstream phones also suffered the same problem, I could not hear the announcement from echo test.

Could Yealink please investigate this issue?
I just wanted to add my vote to this thread.

In my case, there is no "live" change of codecs, simply the final 200 OK containing multiple codecs in the SDP as allowed by RFC. The phone accepts that 200 OK, but only sets up the incoming media stream to the highest codec in the SDP, so any other codec sent is simply dropped.
Is this still an active bug? I'm experiencing the same problem using Freepbx and Asterisk 13. I noticed this only happens when using the phone as a pjsip extension. When I change it to chan sip it's working fine.
(07-27-2016 06:14 AM)1sae Wrote: [ -> ]Is this still an active bug? I'm experiencing the same problem using Freepbx and Asterisk 13. I noticed this only happens when using the phone as a pjsip extension. When I change it to chan sip it's working fine.

This certainly still *is* an issue with Asterisk-14.0.0-beta2/PJSIP and the T48G. Does Yealink not handle scenarios where different call legs use different codecs?
Hi Sir,

About the issue, we have solve it and modify it in the new firmware, you can download the firmware in the FTP link below, and it will be invalid in 2017.03.05:
http://ftp.yealink.com/?ShareToken=E4CDA...149227D803

Note: The link include the firmware of T46、T48、T49.

BR
Lucia
(09-06-2016 09:24 PM)Yealink_Lucia Wrote: [ -> ]About the issue, we have solve it and modify it in the new firmware, you can download the firmware in the FTP link below, and it will be invalid in 2017.03.05:
http://ftp.yealink.com/?ShareToken=E4CDA...149227D803

Note: The link include the firmware of T46、T48、T49.

The T48-35.80.0.137.rom firmware from your link seems to have resolved the issue with the T48G <-> Asterisk/PJSIP <-> DAHDI using the uLaw codec. Thank you.
I just tested this new firmware on a T46g and can attest it fixes the codec issue described in this thread when using PJSIP on Asterisk.

Kudos for Yealink for fixing it! Although the issue persisted for many months, Yealink is the first brand affected by this bug that has actually issued a fix.

Now.... can this fix ship on a "public" firmware release anytime soon?

(09-06-2016 09:24 PM)Yealink_Lucia Wrote: [ -> ]Hi Sir,

About the issue, we have solve it and modify it in the new firmware, you can download the firmware in the FTP link below, and it will be invalid in 2017.03.05:
http://ftp.yealink.com/?ShareToken=E4CDA...149227D803

Note: The link include the firmware of T46、T48、T49.

BR
Lucia
Lucia, when is Yealink going to release an official firmware with this fix? Please give us some news, this is an important fix that is long overdue.

Thanks!

(09-06-2016 09:24 PM)Yealink_Lucia Wrote: [ -> ]Hi Sir,

About the issue, we have solve it and modify it in the new firmware, you can download the firmware in the FTP link below, and it will be invalid in 2017.03.05:
http://ftp.yealink.com/?ShareToken=E4CDA...149227D803

Note: The link include the firmware of T46、T48、T49.

BR
Lucia
(09-06-2016 09:24 PM)Lucia Wrote: [ -> ]Hi Sir,

About the issue, we have solve it and modify it in the new firmware, you can download the firmware in the FTP link below, and it will be invalid in 2017.03.05:
http://ftp.yealink.com/?ShareToken=E4CDA...149227D803

Note: The link include the firmware of T46、T48、T49.

BR
Lucia

Lucia, I have begun to see this issue again and have been using firmware 35.81.0.20 on a T48G. There have been some changes in my Asterisk installation that may trigger this issue, though I do not see this issue on any of my other phones/devices/softphones. Can you elaborate on the "fix" that was provided? What did it do to improve the codec handling? I'd like to check in on the Yealink side first since it isn't affecting other phones.
Can you kindly provide the level 6 syslog, config.bin and pace trace for us to analyze. You can send the files to Lucia@yealink.com. Thank you.

Also, how many phones you have in total and how many of them have the issue?

Best Regards,
Lucia
Pages: 1 2
Reference URL's