Standalone UCMA applications: which features work?

Recently I’ve been getting lots of questions about standalone UCMA applications, by which I mean UCMA applications that don’t register at all with Lync Server, and I thought it might be helpful to write about which features of UCMA work with standalone applications, and which require Lync Server.

Inbound Calls

Standalone UCMA applications can easily receive audio calls from other SIP endpoints. There is one catch you need to pay attention to when setting up your application. Your application has a listening port (5060 is a common one) that it listens on for incoming SIP messages. However, UCMA will normally ignore messages where the To header doesn’t match the SIP URI of an endpoint managed by your application. If you want your application to receive all calls that arrive on the listening port (for an IVR application taking calls from a PBX, for instance), it’s best to set up an ApplicationEndpoint that is a default routing endpoint.

Outbound Calls

Like inbound calls, standalone UCMA applications can place outbound audio calls without much difficulty. The important thing to keep in mind is that the application will not have the benefit of a SIP proxy to figure out where the message should go. If you place a call from your standalone UCMA application, you’ll need to specify the exact network location where it should be sent.

Transfers

Audio calls are twice the fun when you add transfers. Thankfully, standalone UCMA applications can perform transfers, so long as the SIP endpoint on the other end of the call supports REFER messages. You can even perform supervised transfers, to “switch” participants on your calls.

Media Helper Classes

The various media helper classes, like Player, Recorder, SpeechSynthesisConnector, and SpeechRecognitionConnector, work just fine with standalone UCMA applications.

Conferences

Here we hit a sticking point. Creating and joining a conference requires a conference focus and an MCU, both of which are managed by Lync Server. Standalone UCMA applications, which aren’t on speaking terms with the Front End Server, have no access to these things. Try to join an ad hoc conference, and you’ll get the following confusing exception:

FaultCode=
ResponseCode=480
ResponseText=Temporarily Unavailable
Microsoft.Rtc.Signaling.PublishSubscribeException:The data session subscription to server failed. 
---> FaultCode=ResponseCode=480 ResponseText=Temporarily Unavailable
Microsoft.Rtc.Signaling.PublishSubscribeException:A 480 (Temporarily Unavailable) response 
was received from the network and the operation failed. See the exception details for more information.

Unfortunately, this means that if you want to use conferences in your UCMA application, it will need to depend on Lync Server.

Presence

When your UCMA application publishes presence updates, they go to the Lync Front End Server, which does some complex presence aggregation and determines what presence information to send out to all the other users that are subscribed to that application’s presence. Likewise, when your application wants to know the presence of another user, it consults the Front End Server. There’s no such thing as peer-to-peer presence, at least not in Lync.

You can create a RemotePresenceView object and call StartSubscribingToPresentities, but the subscription won’t work, because there’s no server for the subscription to go to.

And that more or less sums up what you can and can’t do with standalone UCMA applications. Another topic I’ve been getting questions about is whether you can register a UCMA app with a non-Lync SIP proxy server. I’ll cover that in a future post.