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

[Colin Morelli]

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_
> codec_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/freeswitch-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/20170421/860c2a49/attachment.html