Hello all<div><br></div><div>we're using a Sangoma D100 card for transcoding. Our configuration, as far as the codec policy is concerned, basically does this:</div><div><br></div><div>-In the first offer to the b-leg we use the same codec list we receive (<action application="export" data="absolute_codec_string=${ep_codec_string}"/>)</div>
<div>-If the call fails with status 488, we repeat the call using all the codecs available. This includes changing from annexb to annexa and viceversa.</div><div><br></div><div>Let's suppose a-leg only supports g729 annexA, and B-leg only supports G729 annexB. My understanding is that those different codec flavours don't interoperate; in fact I've experienced many times audio problems when trying to set up a call between endpoints supporting different g729 variants. </div>
<div><br></div><div>In the described case, FS sends initially annexb=no, and B-leg rejects it with cause 488. We rebuild the offer with annexb=yes, and then the offer is accepted by the B-leg. Our concern is that no transcoding resources are used in this case, and we might run into audio problems because of that. The other concern is that in the answer to the A-leg (in 183 and 200), annexb=yes is included. I'm not sure if all devices would support different fmtp parameters in the offer and the answer (the RFC, as usual, won't be explicit about this).</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>Is there any way to force the transcoding in a situation like the one I described?</div><div><br></div><div>Thanks in advance</div><div>
<br></div><div>Javi</div><div><br></div><div><br></div>