[Freeswitch-users] Use inherit_codec Codec on Re-invite

Colin Morelli colin.morelli at gmail.com
Sat Apr 22 19:12:43 MSD 2017


And I lied here - it was working for a different reason.

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.

Is there any way, aside from using scripts/event_socket to get this to work?

Colin

On Fri, Apr 21, 2017 at 10:46 AM, Colin Morelli <colin.morelli at gmail.com>
wrote:

> 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.
>
> Generally with codec_string=${ep_codec_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).
>
> Seems to work fine and solves my issue. Hopefully it can be helpful to
> someone else.
>
> Best,
> Colin
>
> On Thu, Apr 20, 2017 at 10:09 AM, Colin Morelli <colin.morelli at gmail.com>
> wrote:
>
>> Hey Brian,
>>
>> It seems like what I'm talking about can be reproduced with a fairly
>> simple dialplan (in a profile with inbound-late-negotiation=true):
>>
>> <execute application="set" data="inherit_codec=true" />
>> <execute application="bridge" data="{codec_string='${ep_code
>> c_string},PCMU,opus'}sofia/some/endpoint" />
>>
>> Given an A leg (with codecs opus, pcmu), and a B-leg (with codecs pcmu)
>> 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 *should* 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)
>>
>> I hope that makes sense, happy to try to clarify more, though.
>>
>> Best,
>> Colin
>>
>> On Thu, Apr 20, 2017 at 9:49 AM, Brian West <brian at freeswitch.org> wrote:
>>
>>> Going to need to know what you're doing in the dialplan to really
>>> understand whats going on.
>>>
>>> /b
>>>
>>>
>>> On Thu, Apr 20, 2017 at 7:14 AM, Colin Morelli <colin.morelli at gmail.com>
>>> wrote:
>>>
>>>> Hey all, back again
>>>>
>>>> Is there any option in FS to either:
>>>>
>>>>    - Keep inherit_codec working after the first invite
>>>>    - Try to reduce codec changes by attempting to use the existing
>>>>    codec on a re-invite
>>>>
>>>> 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:
>>>>
>>>> INVITE (this is good and what I'd expect):
>>>> A --- (opus, PCMU) ---> FS --- (opus, PCMU) ---> B
>>>> A <-- (PCMU) --- FS <--- (PCMU) --- B
>>>>
>>>> Later Re-INVITE:
>>>>
>>>> A --- (opus, PCMU) ---> FS
>>>> A <-- (opus) --- FS
>>>>
>>>> Ideally, I could get something like:
>>>>
>>>> Later Re-INVITE:
>>>>
>>>> A --- (opus, PCMU) ---> FS (checks codec used on B-leg of call, if
>>>> inherit_codec=true)
>>>> A <-- (PCMU) --- FS
>>>>
>>>> Thanks in advance,
>>>> Colin
>>>>
>>>> ____________________________________________________________
>>>> _____________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://confluence.freeswitch.org
>>>> http://www.cluecon.com
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/free
>>>> switch-users
>>>> http://www.freeswitch.org
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Brian West*
>>> brian at freeswitch.org
>>>
>>> *Twitter: @FreeSWITCH , @briankwest*
>>>
>>> http://www.freeswitchbook.com
>>> http://www.freeswitchcookbook.com
>>>
>>> Book a phone call (CST) <https://freeswitch.com/appointment>
>>>
>>> Allison prompts for FreeSWITCH:
>>>
>>> *https://www.gofundme.com/allison-prompts-for-freeswitch*
>>> <https://www.gofundme.com/allison-prompts-for-freeswitch>
>>>
>>> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit:
>>> /r/freeswitch <https://www.reddit.com/r/freeswitch>
>>>
>>> *T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002
>>> <(918)%20420-9002> | *M:*+1918424WEST (9378)
>>> *Skype:*briankwest
>>>
>>> ____________________________________________________________
>>> _____________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170422/afd0c5e3/attachment.html 


Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list