VARIABLE: bypass_media_sdp_filter
Can be set globally or per leg on the inbound side of a bypass_media bridge.
VALID FILTERS:
remove(): Removes the specified codec if it exists in the SDP.
only(): Removes all codecs besides the one specified (providing that it exists in the sdp) (will not remove telephone-event))
EXAMPLE 1 (remove everything leaving only g729):
<action application="set" data="bypass_media_sdp_filter=only(g729)"/>
<action application="set" data="bypass_media=true"/>
<action application="bridge" data="sofia/internal/1238@conference.freeswitch.org"/>
EXAMPLE 2 (remove everything leaving only g729 and also remove dtmf):
<action application="set" data="bypass_media_sdp_filter=only(g729)|remove(telephone-event)"/>
<action application="set" data="bypass_media=true"/>
<action application="bridge" data="sofia/internal/1238@conference.freeswitch.org"/>
EXAMPLE 3 (remove alaw and speex):
<action application="set" data="bypass_media_sdp_filter=remove(pcma)|remove(speex)"/>
<action application="set" data="bypass_media=true"/>
<action application="bridge" data="sofia/internal/1238@conference.freeswitch.org"/>
While reviewing code I noticed some dead code. It was not possible to
default to the channel variable because the parameter could not be
both full and empty.
If the parameter is not a non zero length string then the code looked
like it was intending to default to the channel variable
'presence_data_cols'. If neither of these are the case it is a noop.
By enabling the dead code, you now have access to set the
'presence_data_cols' in the dialplan or scripts like lua.
We hangup the channel after receiving 10 SRTP packets in a row with a
bad auth tag or that are replayed. Prior to this commit we were
indicating a normal clearing. When doing interop and looking first at
packet traces, this made freeswitch's behavior look surprising. With
this commit we'll indicate more loudly what's happening.
This assignment isn't doing anything, so it safe to remove it, but
there remains the question of whether there could have been some
actually necessary intention behind this line.
This seems to be a paradox when running a perl script from a session then executing perl again on the same session from a different thread.
I fixed it by converting any execution of perl in the execute_on_* family of operators to only run background mode which is to store the command in the session stack to be executed only by the session thread instead of on the spot by the outide thread. changing the execute_on_answer to perl::/path/to/script.pl would also eliminate the crash in code that has not been updated with this patch.
This is just a limitation of embedded perl we have to live with.
Brian West
Anthony Minessale
William King
Kathleen King
Travis Cross
Michael Jerris
Ken Rice
Seven Du
Nathan Neulinger