<!--
Thanks for submitting a pull request!
In order to consider and evaluate your PR, it is mandatory to provide detailed information about (1) what is the issue the PR addresses, (2) how the PR is solving the issue (logic and coding), (3) what are (if any) limitations of the proposed PR and (4) if there are any known side-effects/ backward compatibility issues/SIP interoperability issues.
Note that if the PR is missing information, it might take longer to be merged, as extra resources have to be allocated by the maintainers to reverse engineer the changes, understand them, understand the motivation, etc. That is why it is important to provide as much information as possible.
-->

**Summary**
<!-- Summary of the PR - what the PR is aiming to solve -->

**Details**
<!--
Details about the content of the PR - is it a bug fix, a new feature or perhaps a hack? Explain the **motivation** for making this change.
What existing problem does the pull request solve? Is this a particular problem (i.e. only some particular scenarios are affected, only some UACs, etc) or a generic one?
Do not assume others understand what you're trying to do and provide as much information as you may have.
-->

**Solution**
<!-- Explain how your PR fixes the problem. Are there any remaining concerns that might need to be addressed? -->

**Compatibility**
<!-- Does your change break other scenarios, or do they need to be migrated in order to work similarly? -->

**Closing issues**
<!-- Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes (if such). -->
