UCMA 3.0 applications without Lync Server

One topic that I wanted to write about in Professional Unified Communications Development that did not make it into the book because of time and space considerations is how to create UCMA applications that don’t depend on Lync Server. Now, at first this may seem like a strange and clueless idea, akin to carrying around a cell phone when you haven’t got any cell phone service. But there are actually some very real reasons why you might like to build a UCMA application without Lync Server.

A simple and common example is interactive voice response (IVR) systems. It’s certainly possible to set these up as trusted endpoints that register with Lync Server. But if you want to route calls directly to an IVR (whether from a SIP trunk, a PBX, an Asterisk server, or something else) where Lync Server is not present, you can do this with a standalone UCMA application. In this post, I’ll show how to set up a simple UCMA application in this way, and how to place test calls to it using CounterPath‘s X-Lite softphone. Continue reading “UCMA 3.0 applications without Lync Server” »

Multiple calls to a conference from the same UCMA endpoint

There are a number of situations where it is necessary for a UCMA application to connect more than one call to a conference. One example that I’ve seen more than once is the situation where you want your application to play messages to a caller, but you also want to record both the messages and the caller’s response. The way to do this is to create two separate instances of AudioVideoCall, join both of them to the conference, and establish them. One of them can then play the messages, while the other can be hooked up to a Recorder object to record both sides of the conversation. Continue reading “Multiple calls to a conference from the same UCMA endpoint” »

The steps in a Lync transfer

The steps in a transfer have always confused me a bit, and since I’ve found that other people also sometimes get confused when working with Lync transfers in UCMA, I thought I would write up a few notes on how they work.

Before I knew much of anything about telephony, I had a vague notion that transfers worked as in the diagram below. Phone A would be in a call with Phone B, and B’s end of the call would sort of get passed over to Phone C.

If you think of transfers this way, you would expect that when you transfer a call, the original call between A and B stays active and becomes a call between A and C. You would also probably expect that Phone A doesn’t need to do anything in order for the transfer to occur, and that all the work happens between Phone B and Phone C as they switch places. Making sense so far?

In actual fact, what happens in Lync is very different. Here are the steps, in a nutshell:

• Endpoint B sends a REFER message to Endpoint A. This message has the SIP URI of Endpoint C.
• Endpoint A initiates an entirely new call to Endpoint C.
• The original call between A and B is terminated.

This last step, terminating the original call, can happen either immediately after the REFER message, or after the call from A to C connects successfully. In Lync, this is the difference between an unattended transfer (the former case) and an attended transfer (the latter case).

Here is a diagram of the actual process:

One case where this can be confusing is if you are looking at the call state changes. Let’s say you’ve hooked up an event handler to the AudioVideoCall.StateChanged event on the call between A and B, to record every state change. This is what you’ll see when you call the BeginTransfer method on that AudioVideoCall object:

• Established
• Transferring
• Terminating
• Terminated

This often confuses UCMA developers at first, because it appears as though the transfer has failed and the call has terminated. But what’s actually happened here is that the transfer has succeeded, and so the original call (between A and B, in our diagram) can terminate. If neither Endpoint A nor Endpoint C are managed by your UCMA application, you no longer have any control over the new call that results from the transfer, so you can’t track its state changes even if you want to.

There is another special type of transfers, supervised transfers, which I won’t go into here since I’ve covered them in a previous post. I also have a post showing how to perform a transfer in UCMA from back in the 2.0 days (the process hasn’t really changed in UCMA 3.0). Finally, if you want a more comprehensive discussion of transfers and other ways to have fun with audio calls in UCMA, you can always refer to the book.

Rerouting requests to a UCMA application with MSPL

One of the most useful (and most confusing) things you can do with Microsoft SIP Processing Language (MSPL) is change the routing behaviour of Lync Server. There are a variety of reasons why you might want to do this, but in this post I want to discuss a specific case: rerouting calls to a UCMA application. Continue reading “Rerouting requests to a UCMA application with MSPL” »