- only handles active dialogs in state 4 - wipes out a given dialog callously - no subcalls to dialog-ending functions - dialog is then removed by the recurring cleaning function execution - as discussed in sr-users in topic "[Dialog] Removing entries from dialog memory"
#### Pre-Submission Checklist - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
Hi,
As discussed in the sr-users mailing-list, I am proposing this PR to add a very simple new rpc command to the dialog module. dlg.kill_active_dialog kills any given active dialog from memory.
A paragraph in the dialog documentation precises the dangerous nature of this command, to be used with caution.
Please feel free to discuss about it.
Thanks!
Julien You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2111
-- Commit Summary --
* dialog: adding RPC dlg.kill_active_dlg command
-- File Changes --
M src/modules/dialog/dialog.c (56) M src/modules/dialog/doc/dialog.xml (5) M src/modules/dialog/doc/dialog_admin.xml (33)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2111.patch https://github.com/kamailio/kamailio/pull/2111.diff
I am wondering if we should turn this new rpc command in a generic one to set the state of dialog, or keep it like in the PR. Would anyone see benefits on being able to set any state?
I think a more global command would be nice to have.
As far as I am concerned dialog plugin implemented in DMQ module is perfectible and does not currently cover all the cases I am facing (and maybe will never be able to do so). So the ability to force a dialog state for handling some particular cases could be a solution.
I explained in the mailing-list that case "state 4 to state 5" seems to be the most important in my opinion because for the others we generally have shorter lifetime timeouts (for non-ACKed dialogs for instance). So they should not remain in memory for a long period of time, as opposed to active dialogs.
OK, I will merge this PR to get the foundation of code, but then update to change the function (name and code) in one generic for setting the state.
Merged #2111 into master.
The new rpc command is dlg.set_state, see commit f25bef926893e9efd495d3808dfad8f8753463c1 . Test and provide feedback if the functionality is not the same as for the previous version, when changing from state 4 to state 5.
Daniel,
Thinking about it further, I would rather replace this block: `if(ostate==DLG_STATE_CONFIRMED && sval==DLG_STATE_DELETED) {` by this one: `if(sval==DLG_STATE_DELETED) {`
Because if a dialog is changed to deleted state from a state < 4, it stays in the dialog memory for no reason. I think it would be cleaner to reset the timestamps each time the state is set to 5, whatever the old state was.
What is your opinion about this?