<div dir="ltr"><div>Hi Steve,<br><br><br></div><div>Could please provide your comments/suggestions on below quetions marked as Q ?<br><br></div><div>GISR. <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 9, 2015 at 8:35 PM, indra sena <span dir="ltr"><<a href="mailto:myforums.indra@gmail.com" target="_blank">myforums.indra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Steven,<br><br>Thanks for all your deep insights and bearing with interminable questions.<br><br>1) But I'd first look at why the B-leg isn't being offered more codecs. Avoiding transcoding would be more of an optimisation, you still need to look at why the gateway wasn't offered G711.<br><span style="color:rgb(61,133,198)">I have found the reason for why gateway wasn't offered G711, because form my dialplan is sending absolute_codec_string as 'ep_codec_string', i.e. "absolute_codec_string=\${ep_codec_string}". It is received by fs as "absolute_codec_string=G729@8000h@20i@8000b,PCMU@8000h@20i@64000b" but while parsing with switch_separate_string_string() it only assigning to first one upto first "," (there is a stmt Make sure you have single quotes ( 'PCMA,PCMU' ) around comma ( ',' ) separated list of codecs to protect it from parsing list of variables inside of {var1=val1,var2=val2,absolute_codec_string='GSM,PCMU'}). next cdecs are considering as separate vars and it is considering like this.</span><br><br><span style="color:rgb(61,133,198)">Q1: So do we need to send all codecs by substituting instead 'ep_codec_string' like absolute_codec_string='G729,PCMU' from dialplan or can we send 'ep_codec_string' any other way from dialplan so that it can parse properly?<br><br>After hardcoding absolute_codec_string='G729,PCMU' in dialplan , B-leg is getting offer with both G729, G711 and it is responding but due to transcoder is not there there no voice between these two.</span><br><br>2) Before the bridge to that gateway you could try renegotiating the aleg codec to G711, but it might not work with every client.<br><a href="https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg" target="_blank">https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg</a><br><span style="color:rgb(61,133,198)">Q1) As I need to avoid transcoder and IVR should be present. So after playing IVR can we need to renegotiate with A-leb by uuid_media_reneg , can we achieve this functionality through dialplan configuration ?</span><br><span style="color:rgb(61,133,198)"><br>3Q) FS-880 jeera <a href="https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-880/" target="_blank">https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-880/</a>, they mentioned that playing your ringback then using refer "deflect" app to blind transfer the call to the same box in proxy mode.How this will work.<br></span><br>Thanks for your suggestions.<br><br>Regards,<br>GISR.<div><div class="h5"><br><div><div><div><div><a href="https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg" target="_blank"><span><span style="color:rgb(61,133,198)"></span></span></a><div><div><div><div><div><span><br></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 9, 2015 at 6:57 PM, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><span name="Steven Ayre">> Like after receiving b-leg codec as G711 can we switch from G729 </span><span name="Steven Ayre"><span name="Steven Ayre">codec</span> to G711 in A-leg by sending reinvite/update to A-leg with SDP with G711 ? Is this procedure works ? currently is freeswitch supports this ?</span><div><br></div></span><div>Before the bridge to that gateway you could try renegotiating the aleg codec to G711, but it might not work with every client.<div><div><a href="https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg" target="_blank">https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg</a></div><div>But I'd first look at why the B-leg isn't being offered more codecs. Avoiding transcoding would be more of an optimisation, you still need to look at why the gateway wasn't offered G711.<span><br><div class="gmail_extra"><br></div><div class="gmail_extra">> After IVR , while giving answer to the A-leg why it is putting only one codec (with which it has playing IVR), not putting all the allowables codecs by A-leg ?</div><div class="gmail_extra"><br></div></span><div class="gmail_extra">Because at that point it's negotiated which codec to use for the call. The a-leg sends the list of codecs it supports, freeswitch compares that to its own list and picks the single best match.</div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 January 2015 at 11:22, indra sena <span dir="ltr"><<a href="mailto:myforums.indra@gmail.com" target="_blank">myforums.indra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi <span name="Steven Ayre">Steven,<br><br></span></div><span name="Steven Ayre">Thanks for your quick response and valuable suggestions. <br><br></span></div><span name="Steven Ayre">With out transcoding is there any way to achieve this ? <br></span></div><span name="Steven Ayre"><br>Like after receiving b-leg codec as G711 can we switch from G729 </span><span name="Steven Ayre"><span name="Steven Ayre">codec</span> to G711 in A-leg by sending reinvite/update to A-leg with SDP with G711 ? Is this procedure works ? currently is freeswitch supports this ?<br><br></span></div><div><span name="Steven Ayre">I have one below query.<br></span></div><span name="Steven Ayre">After IVR , while giving answer to the A-leg why it is putting only one codec (with which it has playing IVR), not putting all the allowables codecs by A-leg ?<br><br></span></div><div><span name="Steven Ayre">Thanks in advance.<br></span></div><div><span name="Steven Ayre"><br></span></div><span name="Steven Ayre">Thanks,<br></span></div><span name="Steven Ayre">GISR.<br></span><div><div><div><div><span name="Steven Ayre"><br><br></span></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 9, 2015 at 4:32 PM, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Default behaviour should be that it offers all codecs to the gateway and transcodes G729-G711 if required.<div><br><div>Check outbound-codec-prefs on the profile you're sending to the gateway from? Check it includes both G729 and G711.</div><div><div><br></div><div>Check disable-transcoding is not set to true</div><div><br></div><div>If you're using absolute_codec_string check it's including G711, this would override any other settings</div><div><br></div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 9 January 2015 at 10:54, indra sena <span dir="ltr"><<a href="mailto:myforums.indra@gmail.com" target="_blank">myforums.indra@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><div><div><div>Hi All,<br><br></div>Do any body have any suggestion on this ?<div><div><br><br>I
have observed in freeswitch that, In case of IVR scenario prior to the
bridge
FreeSwitch plays IVR with the 1st priority codec then invite
to the bridge endpoint (B-leg) with SDP containing only the codec
negotiated for IVR. Also the answer (183 ) to originator(A-leg) with SDP
containing only with IVR negotiated codec. <br><div><br></div>I am having one issue here for example.<br> <br>Originator(A-leg)
sends invite with G729, G711 and Freeswitch negotiated with G729 and
starts playing IVR with G729 and answered(183) to originator with SDP
containing only G729. And Invited to termination endpoint with SDP
having only G729 and termination gateway having support of only G711,
and it is rejecting call after receiving invite with only G729.<br><div><br></div><div>It
should be work like after IVR , invite can be having sdp with all the
originator supported codecs and if termination (b-leg) having different
priority codecs then it can send re-Invite sanding the same.<br><br></div><div>I have observed one issue in freeswitch Jeera (<a href="https://freeswitch.org/jira/browse/FS-880" target="_blank">https://freeswitch.org/jira/browse/FS-880</a>) , but there is no solution in that page.<br><br></div><div>Do we have any solution for this right now ?<br><br></div>Your answers will be very much helpful for me. I appreciate if you can quick response or give some solution for this. <br><br></div></div></div>Thanks & Reagrds,<br></div>GISR..<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 8, 2015 at 12:39 PM, indra sena <span dir="ltr"><<a href="mailto:myforums.indra@gmail.com" target="_blank">myforums.indra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi ,<br><br>I
have observed in freeswitch that, In case of IVR scenario prior to the
bridge
FreeSwitch plays IVR with the 1st priority codec then invite
to the bridge endpoint (B-leg) with SDP containing only the codec
negotiated for IVR. Also the answer (183 ) to originator(A-leg) with SDP
containing only with IVR negotiated codec. <br><div><br></div>I am having one issue here for example.<br> <br>Originator(A-leg)
sends invite with G729, G711 and Freeswitch negotiated with G729 and
starts playing IVR with G729 and answered(183) to originator with SDP
containing only G729. And Invited to termination endpoint with SDP
having only G729 and termination gateway having support of only G711,
and it is rejecting call after receiving invite with only G729.<br><div><br></div><div>It
should be work like after IVR , invite can be having sdp with all the
originator supported codecs and if termination (b-leg) having different
priority codecs then it can send re-Invite sanding the same.<br><br></div><div>I have observed one issue in freeswitch Jeera (<a href="https://freeswitch.org/jira/browse/FS-880" target="_blank">https://freeswitch.org/jira/browse/FS-880</a>) , but there is no solution in that page.<br><br></div><div>Do we have any solution for this right now ?<br><br></div><div>Your answers will be very much helpful for me. I appreciate if you can quick response or give some solution for this. <br> <br></div><div>Thanks in advance.<br><br></div>Thanks & Regards,<br>GISR..</div>
</blockquote></div><br></div>
</div></div><br></div></div>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div></div></div></div></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div>
</div></div><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div></div></div></div></div></div></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div></div></div></div></div></div></div></div></div>
</blockquote></div><br></div>