Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Pages Menu
TwitterRssFacebook

Posted by on Aug 4, 2014 in Skype for Business® (Lync®)

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

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:ucma-app@thoughtstuff.co.uk>;epid=732E4388A6;tag=3337a42636
TO: <sip:O365User@thoughtstuff.co.uk>
CALL-ID: 55e99a32b7f940efa49ca37e876645d6
CSEQ: 9 SUBSCRIBE
CONTENT-TYPE: application/msrtc-adrl-categorylist+xml
Message-Body:
<batchSub uri="sip:ucma-app@thoughtstuff.co.uk"
name="sip:ucma-app@thoughtstuff.co.uk" 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:ucma-app@thoughtstuff.co.uk>;epid=732E4388A6;tag=3337a42636
To: <sip:O365User@thoughtstuff.co.uk>;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:ucma-app@thoughtstuff.co.uk" version="0" fullState="false"><resource uri="sip:O365User@thoughtstuff.co.uk"><instance id="0" state="terminated" reason="forbidden" statusCode="403" cid="O365User@thoughtstuff.co.uk" 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.

1 Comment

  1. Did Microsoft ever fix this issue?

Post a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share to Microsoft Teams