<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] 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) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description Right now the `presence_reginfo` module does not perform any aggregation on presentities from the same AoR. While this is generally ok for new notifies driven by new publishes, when a new subscription is received only the most recent presentity is notified. This PR adds a new parameter, disabled by default to preserve compatibility, which merges all presentities for the same AoR into a single document.
For example, two registrations from the same AoR will create the following document: ```<?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="23" state="full"> <registration aor="sip:user2@example.com" id="0x7f9b6bbf9cf8" state="active"> <contact id="0x7f9b6bbf3ea8" state="active" event="created" expires="300" callid="23439394725296-103541137625012@192.168.10.130" cseq="38" received="" path="&lt;sip:172.23.42.1;lr;received=sip:uac.public.ip:60015;r2=on&gt;,&lt;sip:kamailio.public.ip;lr;received=sip:uac.public.ip:60015;r2=on&gt;" user_agent="MyUA 1.2.3.4"> <uri>sip:user2@192.168.10.130:5060</uri> </contact> </registration> <registration aor="sip:user2@example.com" id="0x7f46836f63b8" state="active"> <contact id="0x7f46836f64e0" state="active" event="refreshed" expires="300" callid="15796302815379-26687127665413@192.168.10.130" cseq="38" received="" path="&lt;sip:172.23.42.1;lr;received=sip:uac.public.ip:5099;r2=on&gt;,&lt;sip:kamailio.public.ip;lr;received=sip:uac.public.ip:5099;r2=on&gt;" user_agent="MyUA 1.2.3.4"> <uri>sip:user2@192.168.10.130:5099</uri> </contact> </registration> </reginfo> ```
Example of a body with two registrations with different bodies: ``` <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="21" state="full"> <registration aor="sip:user2@example.com" id="0x7f9b6bc55540" state="terminated"/> <registration aor="sip:user2@example.com" id="0x7f46836f63b8" state="active"> <contact id="0x7f46836f64e0" state="active" event="refreshed" expires="300" callid="15796302815379-26687127665413@192.168.10.130" cseq="36" received="" path="&lt;sip:172.23.42.1;lr;received=sip:uac.public.ip:5099;r2=on&gt;,&lt;sip:kamailio.public.ip;lr;received=sip:uac.public.ip:5099;r2=on&gt;" user_agent="MyUA 1.2.3.4"> <uri>sip:user2@192.168.10.130:5099</uri> </contact> </registration> </reginfo> ```
What is maybe missing: if the aor and id are the same on different presentities (is possible ?) we should not put it twice in the same body, because aor+id identify an unique registration.
Most of the code has been adapted from `presence_dialoginfo` so I have preserved the original authors, too. Since is a bit complex PR (for me, at least) I'm begging for a in deep review ;)
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3240
-- Commit Summary --
* [presence_reginfo] Add option for aggregating presentities
-- File Changes --
M src/modules/presence_reginfo/Makefile (19) M src/modules/presence_reginfo/add_events.c (17) M src/modules/presence_reginfo/doc/presence_reginfo_admin.xml (21) A src/modules/presence_reginfo/notify_body.c (322) A src/modules/presence_reginfo/notify_body.h (43) M src/modules/presence_reginfo/presence_reginfo.c (8)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3240.patch https://github.com/kamailio/kamailio/pull/3240.diff