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.
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.
Adds app: enable_keepalive 0|<seconds>
This app can be run in the dialplan or with execute_on_* type variables for B-legs.
Adds sofia param: keepalive-method : defaults to MESSAGE can also be "INFO"
This param sets which SIP method to use.
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
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.
