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.
FS-353
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.
If pattern is null we're setting it to a non-null value, so this
branch will always be taken.
Use `git diff -w` or `git log -p -w` to see what's going on in this
commit.
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.
If we received an event without a content-type header we were
dereferencing a null pointer leading to a seg fault.
Reported-by: Ico <ico@voip-io.org>
ESL-90 --resolve
Raymond Chandler
Anthony Minessale
Nathan Neulinger
Chris Rienzo
Michael Jerris
Peter Olsson
Travis Cross
James Le Cuirot
William King
Dmitry Sobinov
Brian West
Ken Rice