With federation and hybrid deployments currently being the only way to get UCMA applications communicating with Skype for Business Online tenants, federation is even more important than before. This post details what a UCMA application can and can’t do when communicating across a federation boundary.
I’ve long felt federation is one of the most underappreciated Skype for Business features. It opens up some communication possibilities that don’t exist at all on legacy technologies. Maybe more importantly, though, it’s changed people’s day-to-day communication in some significant ways, yet so subtly that most people don’t notice federation as such – it’s just easier than before to communicate in real time with people in other organizations.
Since UCMA was first introduced, federation has made for some interesting delivery mechanisms for communication services, letting you host an application in an entirely different environment from the one where the users consuming it are. Now, with Skype for Business Online becoming increasingly popular, and so for no supported way to create UCMA-like services that operate in the cloud, federation is essential for keeping these applications available when users move to the cloud.
When doing this, it’s important to be aware of the limitations on what UCMA can do when federation is involved.
External Access Policy
First and foremost, in order to communicate with federated users at all your UCMA application will need a user or trusted application endpoint that is assigned the right sort of external access policy.
The external access policy controls, among other things, whether an endpoint can communicate via the Edge Server to federated SIP domains.
You can find out what external access policy is currently assigned to your trusted app endpoint by running the following command:
Get-CsTrustedApplicationEndpoint -Identity sip:email@example.com | Select-Object *
You can get details on all of the external access policies configured in your environment, and whether they allow federated communication, by running this command (no parameters):
To assign a new external access policy to your trusted app endpoint, run the following, substituting the SIP URI of your app endpoint and the name of the policy you want to assign:
Grant-CsExternalAccessPolicy -Identity sip:firstname.lastname@example.org -PolicyName MyPolicyName
If you don’t have the right external access policy assigned, your UCMA application will be unable to communicate with or get presence updates for federated users.
While you can send communications (calls, IMs, etc.) across a federation boundary to a federated user, you can’t use your UCMA application to sign in as a federated user or send communications on behalf of that user.
So, you can have your UCMA application register as a trusted application endpoint and send a message from sip:email@example.com to sip:firstname.lastname@example.org. What you can’t do is sign in from your trusted app as sip:email@example.com and send an IM to someone else.
By the same token, while you can publish presence updates for your own trusted application endpoint, which will be visible to federated users, you CAN’T publish presence updates for the federated users themselves. (You can’t change firstname.lastname@example.org’s presence, only email@example.com’s presence.)
Subscribing to Presence
Your application can subscribe to the presence of federated users, and vice versa (assuming the right policy is assigned; see above). However, keep in mind that the presence information that passes to/from federated contacts is more limited by default.
If you have a lot of federated users in your contact list, you’ll likely have noticed that they only ever appear as Available, Busy, Away, Do Not Disturb, or Offline. You can’t see whether they’re in a call or conference, you can’t see their status note, and some other details from their presence information are missing.
This is because, by default, federated contacts are placed in a more restrictive presence container (a way of categorizing users for presence-related permissions) than users from the same domain.
If you want, you can have your UCMA application explicitly place the federated users you’re communicating with in a different presence container so they can see more information on your UCMA application’s presence. (I’ll cover how to do this separately.) The opposite, though (letting your UCMA app see more presence details for federated users) is a somewhat painful process.
UCMA applications can schedule and join conferences in the on-premises environment in which they reside. Federated users can then be invited to these conferences. (Again, keep in mind that federated users may have different access to conferences by default. Check your conference permissions when scheduling.)
UCMA apps can’t, however, schedule conferences in federated environments. Keep this in mind when figuring out where the media streams will be going.
This is a bit of an odd one. If you’re accustomed to using the Conversation.Impersonate method, it will still work…sort of. You can send messages to a federated user with impersonation in effect, including impersonating the SIP URI of a user in the federated domain.
HOWEVER, there are a couple caveats.
First, from the perspective of the federated environment (or O365), the message will still be coming from a federated user, not a local user.
Second, only the SIP URI will show up in the incoming toast message, not the display name.