Asterisk is poor with codec negotiation . It does not check if it can avoid transcoding  by forcing codec available to both sides .. instead it will read it's config file and will select first allowed codec that  is also available on other device on each leg of call and happily transcode between them .There was a patch on digium submitted by someone for asterisk 
1.2.12  or so but it isnt updated from long time .  I am sure guys at digium are  aware about it and working on it . It's not  a bug  since asterisk is not a sip proxy and tries to keep media path through it to offer its pbx features but it would be a great feature nonetheless if implemented .
<br><br><div><span class="gmail_quote">On 05/07/07, <b class="gmail_sendername">Alex Balashov</b> &lt;<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Suggestions on how to use Asterisk to collect CDRs from a OpenSER-based<br>proxy / call routing setup?&nbsp;&nbsp;I need to get simple CDRs;&nbsp;&nbsp;not for detailed<br>settlement/rating, but just for reconciliation with an ultimate TDM
<br>carrier just to make sure we only get billed for what we&#39;re actually<br>using.<br><br>I&#39;d use the often-heralded approach of dumping a call from OpenSER into<br>Asterisk and having it bounce right back out toward the proxy by way of
<br>REINVITEs.&nbsp;&nbsp;I don&#39;t want the media running through Asterisk or Asterisk<br>being a limiting factor in that regard.<br><br>The problem is I don&#39;t have native G.729 support - we have no need for<br>it because neither the customer&#39;s network elements nor ours lack an
<br>implementation of their own they can negotiate on just fine.&nbsp;&nbsp;But<br>unfortunately Asterisk insists on natively homogenising the SDP from<br>both sides even if it subsequently removes itself from the media path!<br><br>
So, I end up with situations where on the one side, I get, say:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Customer MGW --&gt; OpenSER --&gt; Asterisk - sends call as G.729.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Asterisk --&gt; OpenSER --&gt; Our MGW - our MGW prefers G.711a
.<br><br>Now, if customer MGW &lt;-&gt; Our MGW were talking directly, as they do<br>when the deal is brokered through the OpenSER proxy, they would simply<br>negotiate upon what they agree.&nbsp;&nbsp;But for some reason with Asterisk
<br>this does not seem to be working as advertised;&nbsp;&nbsp;we get lots of failed<br>calls if we pass them through Asterisk because one leg is one codec<br>and the other is another.&nbsp;&nbsp;I am not sure how it arrives at that<br>conclusion despite the overlap of shared codecs (
G.729 on both sides,<br>I would expect it to pass thru licence-free), and to be honest, I<br>don&#39;t particularly care if it&#39;s a bug or a feature, I just need it<br>not to introduce codec issues if I use it as a billing target.
<br><br>Any help or insight would be greatly appreciated.<br><br>Thanks,<br><br>--<br>Alex Balashov<br>Evariste Systems<br>Web&nbsp;&nbsp;&nbsp;&nbsp;: <a href="http://www.evaristesys.com/">http://www.evaristesys.com/</a><br>Tel&nbsp;&nbsp;&nbsp;&nbsp;: +1-678-954-0670
<br>Direct : +1-678-954-0671<br><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br><br>asterisk-users mailing list
<br>To UNSUBSCRIBE or update options visit:<br>&nbsp;&nbsp; <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br>