<!-- 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=&quot;23439394725296-103541137625012(a)192.168.10.130&quot;
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=&quot;15796302815379-26687127665413(a)192.168.10.130&quot;
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=&quot;15796302815379-26687127665413(a)192.168.10.130&quot;
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
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3240
You are receiving this because you are subscribed to this thread.
Message ID: &lt;kamailio/kamailio/pull/3240(a)github.com&gt;