I need some advice on how to handle a codec issue during a bridge setup with media bypass. Here is an example of what is going on.<div><br></div><div>I use freeswitch to allow potential customers to try our service before signing up. They can call the PSTN for a limited number of minutes - then freeswitch cuts them off. When they dial a PSTN number, freeswitch first tells them how many remaining minutes they have, then it bidges to the PSTN and then jumps out of the media stream with bypass_media_after_bridge - this all works and the call is setup, but without audio because the codecs are not negotiated correctly and I cannot figure out how to make freeswitch cooperate.<div>

<br></div><div>A concrete example;</div><div><br></div>
<div>The caller supports codecs X and Y, with X being preferred (SILK, PCMU).</div><div>Freeswitch supports codecs X and Y with X being preferred (SILK, PCMU). </div><div>The PSTN gateway supports codecs Y and Z with Z being preferred (G729, PCMU).</div>

<div><br></div><div>When freeswitch answers the inbound call using ESL pre_answer(), the codec in the 183 response is X (SILK). Freeswitch plays audio to the caller to tell them their remaining trial usage minutes and that works as expected.</div>

</div><div><br></div><div>Next, freeswitch does a bridge to the PSTN, offering codecs X and Y (SILK, PCMU). The PSTN gateway replies 200OK with codec Y (PCMU) as it does not support codec X (SILK).</div><div><br></div><div>
Freeswitch then does media bypass, first sending a re-INVITE to the PSTN gateway and getting it pointed to the caller&#39;s IP/port. It again offers codecs X and Y and the PSTN again replies 200OK with codec Y (PCMU).</div>

<div><br></div><div>Now for the problem (line 749 in the pastbin log);</div><div><br></div><div>Freeswitch then re-INVITES the caller, but with codecs X and Y instead of just Y and since the caller prefers X it replies 200OK with codec X (SILK).</div>

<div><br></div><div>The the call is set up. The caller and the PSTN gateway are bridged and talking to each other on the correct IP and ports - but with different codecs.</div><div><br></div><div>So how can I get freeswitch to re-INVITE the A-leg with the same codes that the B-leg accepted?</div>

<div><br></div><div>See the highlighted area at line 749:</div><div><a href="http://pastebin.freeswitch.org/18561">http://pastebin.freeswitch.org/18561</a></div><div>Also not that this was captured at our SIP load balancer, so you&#39;ll see all the messages passing on internal and external interfaces).</div>
<div><br></div><div><div>Configuration info:</div><div>FreeSWITCH Version 1.0.head <span style="font-size:13px;background-color:rgb(255,255,255);font-family:Verdana,Geneva,Helvetica,Arial,sans-serif">git-</span>b290936<span style="font-size:13px;background-color:rgb(255,255,255);font-family:Verdana,Geneva,Helvetica,Arial,sans-serif"> 2012-03-01 10-21-17 -0800</span></div>
<div>inbound-late-negotiation == false</div><div>inbound-codec-negotiation == generous</div><div>global_codec_prefs ==SILK,PCMU,H263,H264</div><div>outbound_codec_prefs == SILK,PCMU</div><div>I am implementing this with ESL.</div>
</div><div><br></div><div>Regards,</div><div>Paul</div>