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.
Previous commit actually broke the functionality since it was now returning if cfg->path[0] was not null.
Also since cfg->path can never be null, this check can be simplified to only check the first index.
William King [Fri, 25 Apr 2014 19:11:09 +0000 (12:11 -0700)]
BNPH-6470 follow up to commit 68d863a179c90d2524f8e761dedb3aebd09c3e75 removing the original line that performed the curl request to avoid a double request in mod_xml_curl
This appears to have been accidentally added in commit 79ebcb104b92fa37ed291e96ab2d611f297e6078 which sought to provide a
mechanism for disabling Sofia's chat interface. The abort(3) here
achieved that a bit too well.
On start DTMF packets we were showing the last write timestamp as a
signed value when it's an unsigned value, which could result in it
appearing incongruous with later packets where the value was displayed
correctly.
I found a problem here but it may not completely match your expectations.
I reviewed the RFC 4028 and checked against the code and I discovered we should not be putting a Min-SE in any response at all besides a 422:
section 5:
The Min-SE header field MUST NOT be used in responses except for
those with a 422 response code. It indicates the minimum value of
the session interval that the server is willing to accept.
I corrected this problem and implemented the 422 response so if you request a value lower than the minimum specified for the profile.
If the value is equal or higher to the minimum, it will be reflected in the Session-Expires header in the response and no Min-SE will be present.
FS-5997 regression from commit 70accd9f272472ac2081283f1927d901b409acb6 this caused some attended transfers to calls with multiple targets to get the abondoned channels to be stuck on write lock
James Le Cuirot [Fri, 11 Apr 2014 21:23:22 +0000 (22:23 +0100)]
Ungetlib libmemcached
Tested with several libmemcached versions between 0.31 and
1.0.18. Unfortunately the API is extremely volatile and awkward to
use. Packaging scripts still need addressing.
Previously we would continue considering phrase actions even after
receiving a break action; we would only break on the next input
clause. It appears the intent here was to break before the next
action.
We were leaking memory when break_on_match was set or when we received
back SWITCH_STATUS_BREAK from a callee as we were failing to free
field_expanded_alloc.
add switch_hashtable_insert_destructor so you can insert a pointer into a hash with a custom destructor and use it in spandsp to fix a leak on reloadxml with the tone_descriptor tables and fix a bunch of random tiny leaks etc
Suppress spurious warning in phrase macro playback
Prior to this commit, if anything at all went wrong in
switch_ivr_phrase_macro_event() we would generate a warning like this:
[WARNING] switch_ivr_play_say.c:348 Macro [macro_name]: 'pattern_name' did not match any patterns
This is clearly misleading. The natural thing to do on seeing that
message is to verify that the language files are there, and that the
pattern really does exist in that macro. But none of that was usually
the problem. The message would be generated if the language wasn't
found, or if the channel had gone away, for example.
With this commit, we verify that we actually tried looking for the
pattern before displaying the warning about the pattern not matching.
For years we've been generating spurious messages like:
[WARNING] switch_ivr_play_say.c:348 Macro [voicemail_ack]: 'saved' did not match any patterns
This would happen when the caller hangs up during the playback of
certain prompts in the voicemail system where we weren't checking the
return value of vm_macro_get(). Looking closely at the log, it's
clear we were calling down into switch_ivr_phrase_macro() long after
the channel was gone.
The message above is also misleading -- switch_ivr_phrase_macro()
would have been able to find that pattern just fine, but it never
actually looked because the channel was gone. We'll clean up that
message in a follow on commit.
This commit resolves issue #46. The GCM mode was using the wrong master SALT length. The master SALT should be 96 bits instead of 112 bits. Note, GCM mode uses the legacy CTR mode for the KDF. The legagacy CTR mode cipher implementations assume a 112 bit SALT. Changes to the cipher abstraction layer API are required to provide the ability to specify the SALT length. For now this commit modifies the SRTP layer to ensure the SALT is zero-appended before initializing the KDF. This commit also provides public definitions for the GCM cipher suite master key sizes to avoid confusion for application developers.