Hi Ming, Thanks for your response. Currently the pjmedia_codec_amr_pack function runs into a PJ_ASSERT_RETURN - so debug builds fail with assertion and release builds produce one-way audio (provided that the return value of pjmedia_codec_amr_pack is handled by the caller). We have a workaround in our application - we add one additional byte to pkt (and respectively pkt_size) so we are fine. It is just that it would be nice to have it fixed on the long term before someone else also runs into it and starts wondering why they don't get audio only with this bit rate. Regards, Zoltan On Wed May 28 02:28:08 EDT 2014, <ming at teluu.com> wrote: > Hi Zoltan, > > You are right. But unfortunately, there doesn't seem to be an easy way to > fix it without affecting backward compatibility. So what currently happens > when the framelen is set to 37. Does the client fail with assertion or only > one-way audio? > > Regards, > Ming > > > On Mon, May 26, 2014 at 9:33 PM, <Zoltan.Toth.ext at rohde-schwarz.com> wrote: > > > Hello, > > > > I found that the frame length definition for AMR-WB bitrate 12.45 is > > incorrect. This bitrate has a frame length of 285 bits, which corresponds > > to 36 bytes. > > However, pjmedia_codec_amrwb_framelen[3] is set to 37. This makes the > > buffer availability check fail in pjmeda_codec_amr_pack() if the caller > > does not provide an extra byte in the payload. > > > > Regards > > Zoltan > >