[SR-Users] Adding presentity_uri prefix for multi-tenanted presence/dialoginfo configuration

Rhys Hanrahan rhys at nexusone.com.au
Tue Mar 26 10:50:41 CET 2019

Hi Everyone,

I’ve recently just started working with Kamailio – thanks everyone for this amazing software.

Like many people, I’m in the process of trying to put Kamailio in-front of Asterisk to allow it to scale out, and my plan is for Kamailio to take over registrations, usrloc and presence/dialoginfo, as we’ve had issues where handsets are failing to get BLF updates/notifys, so I am hoping a couple of Kamailio boxes can scale better in this regard. DMQ is particularly exciting in how it will allow me to build a truly distributed platform. But I’m struggling to get presence to work the way I need it to.

Our environment is multi-tenanted, but we do not (and can’t really) use multi-domains. Instead, we prefix the SIP usernames with the “tenant name” such as tenanta101 and tenantb101. My problem is that all the BLFs are configured for 101 at PBX with no tenant name in the User part of the URI so that internal dialing and call pickup will work. Because in Asterisk we use “subscribecontext” this hasn’t been a problem in the past – Asterisk knows for subscriptions coming from that handset that it belongs to that tenant’s context in the dialplan and they are “isolated”, so having handsets subscribe as 101@ in their request URI was never a problem. Of course, with Kamailio I don’t have subscribecontext, and my main issue is that the “presentity_uri” being stored is 101@ while each of the SIP accounts of the handsets are registered as tenenata101@, and as such, no NOTIFYs are sent by Kamailio because it thinks that there are no watchers for the presentity_uri.

If I change the SIP account username to 101 to match the BLF key, NOTIFYs are sent as expected. But then this breaks call pickup and internal dialing using the BLF keys. I would rather handle this in Kamailio than in Asterisk and having to re-configure the BLF keys for hundreds of handsets.

I need to do something like:

  *   When a SUBSCRIBE comes in, I need to prefix presentity_uri with the tenant name so the subscription changes from 101@ to tenanta101@ in the active_watchers table.
  *   When Kamailio generates a NOTIFY, the notify would be built based on presentity_uri and would come out as tenanta101@, but the phone’s BLFs are configured for 101@ so I would need to *remove* the tenant prefix before sending out the notify.

Is there a good, or recommended way to handle this scenario? Maybe something entirely different to changing the presentity_uri?

I’ve written the following config to re-write the request URI and To field in any incoming subscribe requests, and successfully got the active_watchers table to store a presentity_uri containing my tenant prefix. But the problem I am having is that I can’t figure out how to modify the NOTIFY packets before they are sent – and looking at cfgtrace, it seems I might not be able to?

My “standard” presence + dialoginfo configuration was taken from here as a starting point: https://kb.asipto.com/kamailio:presence:k43-blf

Here is what I have so far in terms of trying to make my modifications – any guidance would be greatly appreciated. It feels like there’s probably a better way to do this than re-writing critical headers like To and Request URI?

@@ -466,6 +467,8 @@ request_route {
        # authentication

+       route(REWRITE_PRESENCE);
        # record routing for dialog forming requests (in case they are routed)
        # - remove preloaded route headers

# Presence server processing
route[PRESENCE] {
        if(!is_method("PUBLISH|SUBSCRIBE")) return;

        if(is_method("SUBSCRIBE") && $hdr(Event)=="message-summary") {
                # Asterisk is our voicemail
                # returns here if no voicemail server is configured
                sl_send_reply("404", "No voicemail service");

        if (!t_newtran()) {

        if(is_method("PUBLISH")) {
        } else if(is_method("SUBSCRIBE")) {
                # See REWRITE_PRESENCE - this should have been executed before we get here.

+       if (is_method("SUBSCRIBE")) {
+               xlog("Re-writing subscribe to include tenant prefix\n");
+                # The default presentity_uri needs to be prefixed with
+                # the tenant name
+               # So re-write the To header
+                route(TENANTINFO);
+                # Now grab the tenant name.
+                $var(subscribe_ru) = "sip:" + $var(tenant_name) + $rU + "@" + $rd;
+               xlog("Re-writing SUBSCRIBE To header as: $var(subscribe_ru)\n");
+                insert_hf("To: $var(subscribe_ru)\r\n", "From");
+               $ru = $var(subscribe_ru);
+               # Force change immediately:
+               # http://www.kamailio.org/wiki/tutorials/faq/main#why_changes_made_to_headers_or
+                msg_apply_changes();
+       } else if (is_method("NOTIFY")) {
+               xlog("Re-writing NOTIFY to remove tenant prefix\n"); # This code block does not get executed right now.
+               # We are storing the presentity_uri with a tenant prefix
+               # handsets do not expect this, only 101@, 102@ etc... In their BLF configs
+               # So this tenant prefix must be removed when building the reply.
+                route(TENANTINFO);
+               $var(notify_ru) = "sip:" + $(rU{s.substr,$(var(tenant_name){s.len}),0}) + "@" + $rd;
+               xlog("Re-writng NOTIFY to use: $var(notify_ru)\n");
+                insert_hf("To: $var(notify_ru)\r\n", "From");
+                $ru = $var(notify_ru);
+               # Force change immediately:
+                # http://www.kamailio.org/wiki/tutorials/faq/main#why_changes_made_to_headers_or
+                msg_apply_changes();
+       }

Thanks for your time.

Rhys Hanrahan
Chief Information Officer
Nexus One Pty Ltd

E: support at nexusone.com.au<mailto:support at nexusone.com.au>
P: +61 2 9191 0606
W: http://www.nexusone.com.au/
M: PO Box 127, Royal Exchange NSW 1225
A: Level 12 227 Elizabeth St, Sydney NSW 2000

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190326/2717e2a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 17043 bytes
Desc: image001.jpg
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190326/2717e2a0/attachment.jpg>

More information about the sr-users mailing list