The Only Thing You Need To Know About Lync Persistent Chat and Application Endpoints
I just came across this whilst doing some development work on the Persistent Chat SDK, and I wanted to share it in case anyone else came across the same problem.
TL;DR:
Persistent Chat Endpoints can only be created with User Endpoints. You can’t use Application Endpoints to create a PChat Endpoint – even though it looks like you can.
Persistent Chat Endpoints can only be created with Endpoints that match up to an AD object.
Update: 19/06/2014
Ben from MindLink (they do awesome things with PChat) has pointed out something I missed. Although it’s true that any Application Endpoints you create in the normal way (i.e. using New-CSTrustedApplicationEndpoint) won’t work…it’s not because they’re Application Endpoints. It’s because “The SIP URI used to create an ApplicationEndpoint must correspond to an Active Directory User object.”, a caveat cleverly hidden halfway down the How to: Connect to a Persistent Chat Server MSDN page. So, you can make it work if you have to. Thanks Ben. 🙂
Background
I was writing a UCMA application to do some Persistent Chat actions. Some of the work was basic room management: setting up rooms, adding users, etc. I’d assumed the Persistent Chat SDK was similar in nature to UCMA, so I thought it would sensible to use an Application Endpoint in the constructor.
From the MSDN documentation:
Parameters
groupChatServerAddress
Type: System.Uri
The chat server address. By convention, the chat server address is usually set to “[email protected]”.
ocs
Type: Microsoft.Rtc.Collaboration.LocalEndpoint
The local endpoint instance. This endpoint must be registered and connected independently, prior to instantiating a PersistentChatEndpoint, as it provides the conduit for all messages delivered between the PersistentChatEndpoint and the chat server.
As you can see, the endpoint that’s passed is a LocalEndpoint. Both ApplicationEndpoint and UserEndpoint derive from this class, so either can be used in the constructor.
The Problem
However, when you try to Establish the Persistent Chat Endpoint, nothing happens, at least for first minute or so. Eventually, EndEstablish returns with this error:
Microsoft.Rtc.Signaling.OperationTimeoutException:This operation has timed out. at Microsoft.Rtc.Collaboration.PersistentChat.Internal.AsyncResultNoResult.EndInvoke(Int32 millisecondsTimeout) at Microsoft.Rtc.Collaboration.PersistentChat.PersistentChatEndpoint.EndEstablish(IAsyncResult asyncResult) at MyUCMAApplication.EndEstablish(IAsyncResult ar)
If you replace the ApplicationEndpoint with a UserEndpoint, it will work fine. What’s happening here?
Logging Detail
Doing a trace with OCSLogger and looking at the logs in Snooper, we can see this message coming back from the server:
SIP/2.0 486 Busy Here FROM: “PChat Test”<sip:[email protected]> TO: <sip:[email protected] RETRY-AFTER: 300 SERVER: RTCC/5.0.0.0 PCS/5.0.8308.420 ms-diagnostics: 20010;source=”xxxxxx”;reason=”User rejected from the chat server due to provisioning of the user“;component=”PersistentChat”
So, the PChat Server is rejecting the Establish, because of the provisioning of the user?!
It would seem that you can’t use Application Endpoints after all, even though the SDK allows you to specify them without warning you. I see this as an error in the SDK – if the PChat Server can’t deal with all types of LocalEndpoint then it shouldn’t be specified in the constructor. Change the constructor to force a UserEndpoint instead, to stop people getting to this point where their application just seem to hang on establishing.
The really silly thing is that if you setup your application with a ProvisionedApplicationPlatform and then create a new User Endpoint, it’ll work just fine. (more here about the different sorts of Application Platform)
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.
Related posts:
UCMA Endpoints: Choosing between Application and User Endpoints
Walkthrough: Creating a UCMA Application & Application Endpoint
Creating UCMA Applications with a UserApplication instance. Example: sending IMs.
UCMA Application: This message was not delivered to [user name] because the service is not available.
Lync Client Feb 2014 Update
Hey Tom,
I think you’re falling foul of the gotcha hidden away in the PC SDK documentation:
“The SIP URI used to create an ApplicationEndpoint must correspond to an Active Directory User object.” from halfway down http://msdn.microsoft.com/en-us/library/office/dn465896(v=office.15).aspx.
This essentially means that you can use UCMA ApplicationEndpoint instances (we do in our products), but you can’t initialize these with SIP addresses created via New-CsTrustedApplicationEndpoint – the Persistent Chat server identity system can only handle users.
Wow, thanks for this – yep, didn’t see that gotcha at all! I’ll update the blog post – I should have known you’d know PChat inside-out! 🙂
-tom
You can’t use the recommended auto-provisioning with an ApplicationEndpoint (when trying to establish a PersistentChatEndpoint):
https://msdn.microsoft.com/EN-US/library/office/dn466123.aspx
“The recommended way to provision a UCMA-based application is auto-provisioning.”
… As you have to create the AD “User” object, SIP enable it, and then provide the SIP URI, and Lync proxy connection info for the ApplicationEndpointSettings (rather than ProvisionedApplicationPlatformSettings). So, no more RegisterForApplicationEndpointSettings on the collaboration platform, you just roll your own.
Somebody definitely dropped the ball at MS on this one with the SDK and the documentation. If there’s an issue it should be clearly documented (including the recommended workaround) rather than hidden in that one-liner Ben pointed out.
Apparently it’s something to do with Persistent Chat not synchronizing “Contact” objects (only “User” objects). Great.
🙁