[SR-Users] Re-writing presentity domain for DMQ

Hi Everyone, I am trying to get DMQ working for presence/dialog notifications. Presence works fine locally on the same SBC. The DMQ part itself is also working fine and I can see that the entries in presentity are being replicated between my DMQ nodes. The problem is that when the presentity records are being replicated from another SBC, the domain for that record stays as the IP of the original SBC. Then when the local_watchers is populated, the presentity_uri doesn’t match, and no NOTIFY packets are sent as a consequence. What am I missing here? I can’t see anything in the docs about how to handle this, and I can’t find any examples in the list on how to handle this either, which suggests it isn’t as common of an issue at it seems. See example of what I see in the presentity table below. In this case handset 103 is subscribed to BLFs for 103 and 104. A call came into 103 and generated an early state dialog in the presentity table. MariaDB [kamailio]> select * from presentity; +-------+-------------+--------------+--------+-- | id | username | domain | event | +-------+-------------+--------------+--------+-- 27100 | nexusone103 | x.x.x.53 | dialog | I have modified my registrations and have re-written my SUBSCRIBE and PUBLISH packet headers so that everything uses a common FQDN for both SBCs, that does DNS RR to both SBC IPs. I am also registering from the handset using this FQDN now, and yet although my active_watchers table now expects a presentity URI of XXX@sbc.fqdn<mailto:XXX@sbc.fqdn>, the presentity table is still using the IP addresses of the individual node that originated the dialog. MariaDB [kamailio]> select presentity_uri,watcher_username,watcher_domain,event from active_watchers; +----------------------------------------------+------------------+----------------------+-----------------+ | presentity_uri | watcher_username | watcher_domain | event | +----------------------------------------------+------------------+----------------------+-----------------+ | sip:104@sbc.fqdn | nexusone103 | sbc.fqdn | dialog | | sip:103@sbc.fqdn | nexusone103 | sbc.fqdn | dialog | +----------------------------------------------+------------------+----------------------+-----------------+ I’m out of ideas unfortunately. Any advice would be appreciated. Thanks! Rhys Hanrahan | Chief Information Officer e: rhys@nexusone.com.au<mailto:rhys@nexusone.com.au> [www.nexusone.com.au]<http://www.nexusone.com.au/> [signature_1328564021] <http://www.fusiontech.com.au/> NEXUS ONE | FUSION TECHNOLOGY SOLUTIONS p: 1800 NEXUS1 (1800 639 871) or 1800 565 845 | a: Suite 12.03 Level 12, 227 Elizabeth Street, Sydney NSW 2000 www.nexusone.com.au<http://www.nexusone.com.au/> | www.fusiontech.com.au<http://www.fusiontech.com.au/> The information in this email and any accompanying attachments may contain; a. Confidential information of Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties; b. Legally privileged information of Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties; and or c. Copyright material Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties. If you have received this email in error, please notify the sender immediately and delete this message. Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd does not accept any responsibility for loss or damage arising from the use or distribution of this email. Please consider the environment before printing this email.