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.
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.
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. 🙂
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:
The chat server address. By convention, the chat server address is usually set to “[email protected]”.
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.
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?
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/18.104.22.168 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)