dialog: Add setting to loop BYE through proxy

[gaaf]

The setting "keep_proxy_rr" will add the Record-Route headers added by the
proxy to the route_set stored in the dialog. When in use, sending locally
generated in-dialog requests will loop back to the proxy with a proper
Record-Route header, including any parameters.

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 on 5.1, compile tested on master
• Related to issue #XXXX (replace XXXX with an open issue number)

Description

[henningw]

@gaaf Thank you, can you add a bit here about the targeted use case for this functionality?

[miconda]

@gaaf - I see that dlg_update_rr_set() is used only for DLG_CALLER_LEG, no need to do it for CALLEE as well?

Having an option to update Record-Route sets within dialog can be useful, I think at this moment they are stored only during the call setup.

On the other hand, for what you try to achieve, I wonder if it would not be simpler to use somehow the caller/callee sockets fields, they are already stored inside the dialog record and they should overlap in address, port and transport with local record-route. So based on modparam, the local requests are sent to the caller/callee socket, with top record route built at storage time or at send time (store vs cpu question here, like none that relevant to decide for one or the other option) -- this just as an idea, I haven't really analyzed if it is a simpler solution, I just thought that those addresses are already stored.

[gaaf]

@henningw: In the current situation, the local Record-Route headers are stripped before they are stored in the dialog module. If a request is sent by the dialog module (forced BYE for example) it completely bypasses the routing script as it will be sent to the remote parties directly. With this PR the local Record-Route headers will not be stripped so the request will be looped back to the proxy as the first Route header is now the proxy itself. This causes the request to follow the routing script as if it was sent by one of the parties in the call and all processing that would normally be done for an "external" request would also be done for this request.

@miconda:

• The callee is handled only when the dialog is confirmed. As there is no previous RR set, no update is needed. The caller's leg is preliminary set when the request is handled, but the final RR set is only known when the dialog gets confirmed (dependent on the winning branch), hence the update is needed.
• Changing the RR in-dialog is not the intention of this PR.
• The sockets don't store (record-)route parameters so this would not be enough. As alternative, maybe using local_route is possible, but it still needs access to RR parameters to be complete. As this patchset predates the local_route functionality I have not investigated much into that direction.

In short, this PR makes the dialog module to not strip the local record-route headers, something I have always considered to be a bug.

[henningw]

Thank you for the explanation, understand it now. I will have a brief look to the patch and comment there if I spot something.

[henningw]

From the code change all looks fine to me. I've added some comments inline about a few things I noticed.

[henningw]

@gaaf This is apparently still open, I would like to resolve this for the upcoming 5.3 to actually merge it. I've had a minor few remarks/questions to the code, would be great if you can have a look to that.

[henningw]

Thank you!