An important UCMA Application restriction to be aware of – Hybrid Lync Environments

I’ve previously blogged about the restrictions on UCMA Applications in Office365 Lync environments, we know it’s not possible. UCMA Applications only work in on-premise setups.

However, there’s an important gotcha I want to make you aware of which might affect you today, but which could also end up breaking your existing applications in the future.

In summary: even though UCMA Applications do work on-premises, if you enhance your environment to a Hybrid setup, your trusted applications (using an Application Endpoint) will not be able to see any users homed on Office365.

Important: this isn’t a all-Office365 sort of problem. This happens in hybrid setups, where some users are homed on Office365.

(not sure of the difference between User Endpoints and Application Endpoints? It’s explained here.)

Identifying the Problem

In my case I was trying to subscribe to the presence of a user homed on Office365, from my trusted application which was on-premise.

No errors were thrown making the actual subscription, but following the events raised from SubscriptionStateChange showed that the subscription went from Idle to Subscribing, but never went anywhere else. Depending on how your code is structured and how many users you are subscribing to, this could be a real problem: because no errors are raised it’s not obvious that something is wrong.

Looking at the SIP traffic between the application and the server, we see this (some message headers removed for clarity):

TL_INFO(TF_PROTOCOL) [4]2078.379C::07/16/2014-10:17:57.003.00534084
Direction: incoming
Message-Type: request
FROM: "UCMA Application"<sip:[email protected]>;epid=732E4388A6;tag=3337a42636
TO: <sip:[email protected]>
CALL-ID: 55e99a32b7f940efa49ca37e876645d6
CSEQ: 9 SUBSCRIBE
CONTENT-TYPE: application/msrtc-adrl-categorylist+xml
Message-Body:
<batchSub uri="sip:[email protected]"
name="sip:[email protected]" xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe">
+ <action name="subscribe"
id="ID1">
</batchSub>
$$end_record

TL_INFO(TF_PROTOCOL) [2]2078.4C38::07/16/2014-10:17:57.137.005363bd Instance-Id: 1B54A30
Direction: incoming
Message-Type: response
FROM: "UCMA Application"<sip:[email protected]>;epid=732E4388A6;tag=3337a42636
To: <sip:[email protected]>;tag=AC5C0080
CALL-ID: 55e99a32b7f940efa49ca37e876645d6
CSEQ: 9 SUBSCRIBE
Record-Route: <sip:sipedgeSN20B.infra.lync.com:5061;transport=tls;opaque=state:Si:Ifi;lr>
Content-Type: multipart/related; type="application/rlmi+xml";start=resourceList;
Message-Body:
Content-Type: application/rlmi+xml
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:[email protected]" version="0" fullState="false"><resource uri="sip:[email protected]"><instance id="0" state="terminated" reason="forbidden" statusCode="403" cid="[email protected]" msDiagCode="2157"/></resource></list>
$$end_record


So, the SUBSCRIBE isn’t happening. But why? The response message body says that the request was forbidden (status 403) but doesn’t really say why. It does give a msDiagCode though – 2157.

Looking up the code, we can see that the reason is: Source network is not set for a single subscribe request when tenant identifiers of the To and From users are different.

Right.

It turns out that the problem is that my application server isn’t trusted by the Office365 infrastructure, so my trusted applications can’t subscribe to any users which are homed there (they’re not actually trusted). Even though the server is trusted in my own environment (so any subscriptions to used homed locally would work fine), Office365 won’t accept my requests.

A Growing Problem

Right now, this is an annoyance. However, as the number of organisations which opt-in to Hybrid grows, the problem will increase – making these organisations choose between Hybrid or UCMA trusted applications.

Temporary Workaround

As a workaround, it’s worth knowing that non-trusted applications which are provisioned with User Endpoints will work fine. They’re not as powerful trusted applications, there are things you can’t do with them, and they’re not as good a fit for long-running back-end services – but you might be able to use them to get around this problem before it’s fixed.

I think that ultimately Microsoft will sort this problem, because they’re keen to increase the usage of both Lync applications and cloud usage, and this problem affects both. However, for now it’s a restriction you should be aware of.

Written by Tom Morgan

Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.

---

Buy the book: Building and Developing Apps & Bots for Microsoft Teams. Now available to purchase online with free updates.

Related posts:

UCMA Application: This message was not delivered to [user name] because the service is not available. Walkthrough: Creating a UCMA Application & Application Endpoint UCMA Endpoints: Choosing between Application and User Endpoints Lync Development on Office 365: What’s Possible, What’s Not The Only Thing You Need To Know About Lync Persistent Chat and Application Endpoints