<div dir="ltr">And I lied here - it was working for a different reason.<div><br></div><div>I can't seem to get this to work quite right. The absolute_codec_string that is created by inherit_codec on the A-leg is wiped out on a re-invite (which is a good thing I think because it's possible the re-invite may not support the initial codec choice). Effectively all I really need for this to work right is a way to copy ep_codec_string from the B-leg into codec_string of the A-leg in pre_bridge. Unfortunately I can't seem to do this with api_before_bridge because the variables are evaluated when the api_before_bridge channel variable is set, not when it executes. At that time there is no B-leg or ep_codec_string for the B-leg.</div><div><br></div><div>Is there any way, aside from using scripts/event_socket to get this to work?</div><div><br></div><div>Colin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 21, 2017 at 10:46 AM, Colin Morelli <span dir="ltr"><<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@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">So I have no idea if this is just an absolutely horrible idea or not, but I believe I've found a solution for this.<div><br></div><div>Generally with codec_string=${ep_codec_<wbr>string} and inherit_codec=true, you can push the B-leg's codec back to the A-leg. However, it seems like this is lost after a reinvite. So I'm using api_before_bridge to set the codec_string of the A-leg equal to the ep_codec_string of the B-leg (plus some other options in case the A-leg doesn't support the codecs of the B-leg), the opposite of what is done earlier in the dial plan. I then use api_after_bridge to clear the codec_string of the A-leg after the bridge is done (this is probably optional).</div><div><br></div><div>Seems to work fine and solves my issue. Hopefully it can be helpful to someone else.</div><div><br></div><div>Best,</div><div>Colin</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 10:09 AM, Colin Morelli <span dir="ltr"><<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@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">Hey Brian,<div><br></div><div>It seems like what I'm talking about can be reproduced with a fairly simple dialplan (in a profile with inbound-late-negotiation=true)<wbr>:</div><div><br></div><div><execute application="set" data="inherit_codec=true" /></div><div><execute application="bridge" data="{codec_string='${ep_code<wbr>c_string},PCMU,opus'}sofia/<wbr>some/endpoint" /></div><div><br></div><div>Given an A leg (with codecs opus, pcmu), and a B-leg (with codecs pcmu)</div><div>As expected, with this dialplan, if the B-leg requests pcmu, then pcmu is passed back to the A-leg - that's absolutely what I'd expect. If the A-leg later sends a reinvite (or update), however, inherit_codec no longer applies and FS seems to fallback to its core codec negotiation. Because the A-leg prefers opus over pcmu, opus is negotiated and transcoding is required. This is what I'm trying to avoid. I know I can disable codec renegotiation on a re-invite, but I don't want that either because a re-invite <i>should</i> be able to change codecs if it needs to (if the A-leg later sends a re-invite that simply doesn't include pcmu, FS should select opus and transcode)</div><div><br></div><div>I hope that makes sense, happy to try to clarify more, though.</div><div><br></div><div>Best,</div><div>Colin</div></div><div class="m_-8605964483922581576HOEnZb"><div class="m_-8605964483922581576h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 9:49 AM, Brian West <span dir="ltr"><<a href="mailto:brian@freeswitch.org" target="_blank">brian@freeswitch.org</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">Going to need to know what you're doing in the dialplan to really understand whats going on.<div><br></div><div>/b</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-8605964483922581576m_-2332645970146111172h5">On Thu, Apr 20, 2017 at 7:14 AM, Colin Morelli <span dir="ltr"><<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-8605964483922581576m_-2332645970146111172h5"><div dir="ltr">Hey all, back again<div><br></div><div>Is there any option in FS to either:</div><div><ul><li>Keep inherit_codec working after the first invite</li><li>Try to reduce codec changes by attempting to use the existing codec on a re-invite</li></ul></div><div>Unless I'm missing something, FS seems to ignore both the current codec being used, and the inherit_codec setting on re-invites, so it defaults to essentially restarting codec negotiation. Ideally I could have it set to preserve inherit_codec if the call is still bridged (i.e. try to negotiate the B-leg's codec onto the A-leg if it's supported by the A-leg's new SDP). Consider the following call:</div><div><br></div><div>INVITE (this is good and what I'd expect):</div><div>A --- (opus, PCMU) ---> FS --- (opus, PCMU) ---> B</div><div>A <-- (PCMU) --- FS <--- (PCMU) --- B</div><div><br></div><div>Later Re-INVITE:</div><div><br></div><div><div>A --- (opus, PCMU) ---> FS</div><div>A <-- (opus) --- FS</div></div><div><br></div><div>Ideally, I could get something like:</div><div><br></div><div><div>Later Re-INVITE:</div><div><br></div><div><div>A --- (opus, PCMU) ---> FS (checks codec used on B-leg of call, if inherit_codec=true)</div><div>A <-- (PCMU) --- FS</div></div></div><div><br></div><div>Thanks in advance,</div><div>Colin</div></div>
<br></div></div>______________________________<wbr>______________________________<wbr>_____________<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" rel="noreferrer" target="_blank">http://www.freeswitchsolutions<wbr>.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.o<wbr>rg</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" 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.freeswi<wbr>tch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/ma<wbr>ilman/listinfo/freeswitch-user<wbr>s</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.frees<wbr>witch.org/mailman/options/free<wbr>switch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-8605964483922581576m_-2332645970146111172m_4769294200691292397gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div class="m_-8605964483922581576m_-2332645970146111172m_4769294200691292397gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">
<p><font face="courier new, monospace"><b><i><font size="4">Brian West</font></i></b><br><span style="font-size:x-small"><a href="mailto:brian@freeswitch.org" target="_blank">brian@freeswitch.org</a></span></font></p><p><b style="font-family:monospace,monospace;font-size:small"><i>Twitter: @FreeSWITCH , @briankwest</i></b></p><p><font size="2" face="monospace, monospace"><a href="http://www.freeswitchbook.com" target="_blank">http://www.freeswitchbook.com</a> <br><a href="http://www.freeswitchcookbook.com" target="_blank">http://www.freeswitchcookbook.<wbr>com</a></font></p><p><font size="2" face="monospace, monospace"><a href="https://freeswitch.com/appointment" target="_blank">Book a phone call (CST)</a><br><br>Allison prompts for FreeSWITCH:</font></p><table cellspacing="0" cellpadding="0" style="font-size:12.8px"><tbody><tr><td valign="baseline"><p><span><a href="https://www.gofundme.com/allison-prompts-for-freeswitch" target="_blank"><b>https://www.gofundme.com/allis<wbr>on-prompts-for-freeswitch</b></a></span></p></td></tr></tbody></table><p><span style="font-family:monospace,monospace;font-size:12.8px">Got Bugs? Report them </span><a href="https://freeswitch.org/jira" style="font-family:monospace,monospace;font-size:12.8px" target="_blank">here</a><span style="font-family:monospace,monospace;font-size:12.8px">! | Reddit: </span><a href="https://www.reddit.com/r/freeswitch" style="font-family:monospace,monospace;font-size:12.8px" target="_blank">/r/freeswitch</a><br></p>
<p><font size="2" face="monospace, monospace"><b>T:</b><a href="tel:(918)%20420-9001" value="+19184209001" target="_blank">+19184209001</a> | <b>F:</b><a href="tel:(918)%20420-9002" value="+19184209002" target="_blank">+19184209002</a> | <b>M:</b>+1918424WEST (9378)<br><b>Skype:</b>briankwest<br></font></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br>______________________________<wbr>______________________________<wbr>_____________<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" rel="noreferrer" target="_blank">http://www.freeswitchsolutions<wbr>.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.o<wbr>rg</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" 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.freeswi<wbr>tch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/ma<wbr>ilman/listinfo/freeswitch-user<wbr>s</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.frees<wbr>witch.org/mailman/options/free<wbr>switch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>