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
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@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@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@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@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 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Brian West
-
Colin Morelli