Hot off the press (as of July 2015) is v5 of Sonus’ SBC 1k/2k firmware, and its “Third Party Presence” feature.

I covered the new features in my last post, but wanted to particularly highlight this one as it’s quite ground-breaking.

I think the potential for this is vast: *any* call that’s going through the SBC can set a user’s presence:

• A user who’s still on your PABX, only using SfB/Lync for IMs can still be showing as “in a call” when they’re on their PABX phone. (Yes, there’s possibly some overlap with SfB’s Call Via Work feature here – but this works on Lync 2013 as well!)
• A remote user – perhaps an executive – calls in from their home phone – they’ll show as “in a call”
• If you want to monitor calls to/from a given country, area code, partner organisation or even an individual, set the presence for a dummy user account you’re monitoring. (Awesome debugging tool or what?)
• Want to know if there are any active calls to UM, SA or some other service?
• See the presence each time the door intercom, paging trunk or boom gate is active

How it works

The key to this is that you add the SBC as a “Trusted Host” in your Lync deployment. (This duplicate use of the SBC’s FQDN in the Topology is valid from 5.0.8308.866 – the second of the December 2014 updates). As a Trusted Host, the SBC is then allowed to set the presence for a user.

The user – or users – it sets is typically determined using an AD Lookup, triggered as the call follows a slightly modified Transformation Table. I’ve written of the AD Lookup feature several times in the past (e.g. here and here), and its power and flexibility is now enhanced with this use.

New Input and Output field types are added to the Transformation Tables to support the AD Lookup, and the result of these tests won’t change whether the table is true or false.

Setting It Up

It shouldn’t take long to setup, and if your SBC is already using AD Lookups you’re already halfway there.

Topology Changes

First off we assume your Lync is at 5.0.8308.866 or you’re running Skype for Business Server 2015. That’s a minimum.

1. Determine the site you’re building this into:

   Get-CsSite

2. Create the SBC as a Trusted Application Pool:

   New-CsTrustedApplicationPool -Identity ux1000fxo.contoso.local -Registrar lync2013se.contoso.local -Site 4

   

3. Now create the Trusted Application. Note that it’s using port 5061:

   New-CsTrustedApplication -ApplicationId "Sonus-presence" -TrustedApplicationPoolFqdn ux1000fxo.contoso.local -Port 5061

   

4. And enable the Topology:

   Enable-CsTopology

   Add AD Lookups

5. Navigate to the Settings Tab / Auth and Directory Services / Active Directory / Domain Controllers
6. Click the “+” to create a new Domain Controller & fill in the details in a format as shown here:

   

Sonus suggests your LDAP Query should be “msRTCSIP-PrimaryUserAddress=*”, as this will only return Lync-enabled users. If you’re doing anything tricky with AD Lookups you might want to stick with the more generic “telephoneNumber=*”, “msRTCSIP-Line=*” or similar.

The User Name and Password are those of a basic Domain User account, with its password set to Never Expire. The SBC will use these credentials to run its AD queries.

7. Click OK to save this.
8. Now navigate to Settings / Auth and Directory Services / Active Directory / Configuration. Here we’ll enable AD Lookups, tell it what to cache and how frequently it needs to update:
   

   BEWARE: Normalize Cache may trip you up here. Read more under “Troubleshooting” below.

   TIP: I always add “displayName” to my cached attributes. I don’t use that attribute to route calls, but it’s really handy when you’re testing AD on the Diagnostics tab to have it pop the name of the user you’ve found.

9. Check your config thus far: Click “Display Statistics” and confirm the queries are successful. If there are problems here, go back and check the AD account you used in the earlier step.
    

   Add A “Presence Server”

10. Navigate to SIP / SIP Server Tables and create a new SIP Server. It’s probably going to be basically a copy of your Mediation Server, but with Monitor disabled and using port 5061:

    

11. New in v5 at the bottom of the “SIP” navigation tree is the option “Node-Level SIP Settings”. Set the “Presence Destination” as the SIP Server you created in the previous step:

    
     

    (If your server isn’t visible, you might have neglected to set it for TLS – only those SIP Servers set for TLS display in the pick-list).

    Modifying the Call Routing

    Assuming your SBC is already running and routing calls correctly, what we now need to do is modify one or more existing Transformation Tables in an effort to identify a user to set their presence.

    In the below setup I’m triggering a Lync user’s presence when a call comes in from an FXS port that I’ve married to that user in AD. It doesn’t matter who they call but as soon as the called party answers, the nominated (calling) user will update to show “in a call”. Realise then that this is only setting presence for calls where the caller’s number is someone’s “ipPhone” in AD.

12. Assuming you’re doing this on a live system, let’s get serious and copy an existing Transformation table. Here’s the copied original:

     

13. I do this sort of development (playing in traffic as it were) by adding a mandatory test for where the Calling Address/Number = my mobile number, then adding a routing entry referencing that table higher in the Call Routing Table than the original. At worst, it stops me from ringing in! Once you’re sure it works you can disable and then delete the mobile test, then remove the now redundant entry lower down the Routing table. Here it is with the mobile added:
    
14. Now let’s add the presence test. In this example I’m testing the calling number to see if it matches any user’s “=ipPhone=” attribute, and if so, copying their “=msRTCSIP-PrimaryUserAddress=” attribute into the Calling party’s “Presence” field:

    

    Note towards the right of the bottom line that the Match Type says “Not Applicable”. This breaks the normal Transformation Table convention: the result of a Presence test now isn’t going to influence whether the Transformation Table is true or false.

    That’s it!

15. Now make a call and see if it works! I see the Node-Level Settings updates to indicate Presence is working successfully:

    

(I’ve never seen Publish Session Count budge from 0 BTW).

Troubleshooting

Normalize Cache

With “Normalize Cache” set to true, the SBC strips punctuation characters and the “tel:” prefix from AD results, reducing your effort to format the phone number into one that will hopefully match.

Unfortunately it also strips “sip:” from the front of a user’s “=msRTCSIP-PrimaryUserAddress=”, and derails Third Party Presence. The fix is to manually reinstate “sip:” in your Output field.

Here’s a good trace:

Successful regex match of "tfCallingPresenceValue" field for "=ipPhone=" (updated "\+61212345678") with input of "+61212345678"
Regex replacement output of "tfCallingPresenceValue" field is "sip:chode@contoso.net"

… and here’s a bad one:

Successful regex match of "tfCallingPresenceValue" field for "=ipPhone=" (updated "\+61212345678") with input of "+61212345678"
Regex replacement output of "tfCallingPresenceValue" field is "chode@contoso.net"

The fix is simple – just manually reinstate the “sip:” prefix to the Output Field’s value:

 

“=” or “==”?

If you’re testing for both the Calling and Called party in the same Transformation Table – which is perfectly valid – the second and subsequent AD Lookups must use the double-equals. If you stick with the single-equals, all of the follow-on tests in the table are likely to fail if the first test failed, or you might end up only setting “half” the expected presence: only the calling party and not that of the called one.

Won’t Work	Works

I wrote a little of the “==” when it was introduced back in v2.2 in my Mk-II AD Safety Net.

LX

LX Captures the presence change messages:

Variations on a Theme

In the introduction I suggested you could monitor lots of call types. Here’s a variation on the Presence Transformation Table. I’m hoping for a match on any 10-digit number that starts with “04” – a call to an Australian mobile number. I’m not looking up AD here: if the called number matches my Regex, I light Gilligan’s presence:

I tested this scenario with multiple simultaneous calls and the presence stayed lit as long as there was an established call – it didn’t go out when the first call cleared, which was what I was worried about / expecting.

Notes

Some words of warning: In the opening I enthusiastically suggested you could use this feature to keep an eye on all calls to a country or an area code. You might want to consider the potential presence traffic doing this will generate before you go there.

Just in case you’re wondering:

• Third Party Presence also works if the user’s offline – they pop back up “In a call” and then drop back offline at the end of the call
• It *won’t* work if the user has manually set their presence (like to ‘appear away’) but it will update for those that are away due to genuine inactivity
• Unfortunately i couldn’t get ‘stalker mode’ (aka “tag for status change alerts”) to fire when a user changed to ‘in a call’. A user who was previously offline would however pop when the call completed and they vanished offline

Action Sets

In the pre-release version of the documentation the feature was implemented using Action Sets and Action Configuration. I’m guessing this was before Sonus bypassed the “Match type” handling for Presence. If you still see it referenced in documentation, it still works to do it that way, but it’s a lot more cumbersome than the method demonstrated here. Here’s what the flow would look like:

Credits

Thanks to Sonus (& the Sydney team especially) for the sneak-peak of v5.

 

What other uses do you think you can put this to?

– Greig.

Revision History

29th July 2015: This is the original post