A/V MCU encryption fix in Lync CU4

The latest cumulative update for Lync was recently released, and one of the fixes deals with an interesting problem to do with audio conferences. I thought I would take the opportunity to discuss a few things about how media works in a Lync audio conference, and the implications of this change in the update.

The fix that I’m referring to (details here) resolves a problem where one-way audio could occur between a client and an audio/video MCU. For background, the MCU, or multipoint control unit, is the Lync component that mixes media for the conference and distributes it to the participants. What was happening in certain cases was that an audio conference participant would be audible in the conference, but could not hear other participants.

It turns out that the reason for this was an issue with media encryption in the MCU. Continue reading “A/V MCU encryption fix in Lync CU4” »

Blog recommendation

Paul Nearney, who recently started the blog CodeLync, has written up an excellent post on developing screen pop applications. If that’s something you’re looking to do, check out his post!

What is a GRUU?

The term “GRUU” comes up fairly often in Lync development, and I wanted to use this post to give a brief overview of what it means and why you would use one.

GRUUs in their natural habitat?

Contrary to what you may have been led to believe, a GRUU is not a large herd animal or a part of the small intestine. The initials actually stand for “Globally Routable User-Agent URI,” which may or may not clarify things for you at all. The definition of a GRUU is explained in an IETF document which you can find here. In a nutshell, a GRUU is a SIP URI which has a few properties:

Continue reading “What is a GRUU?” »

Adding custom menu items to the Lync client

One of the areas in which Lync can really streamline communication is in handling context. The term “contextual conversations” comes up a lot in reference to Lync, and for good reason. In traditional communication media, a lot of time tends to be wasted while one person or the other looks for necessary information, documents, or tools that are relevant to the topic at hand. As Lync becomes more and more integrated into people’s workflows, it can automate much of this sending and retrieval of appropriate context, saving time and increasing productivity.

In this post, I want to discuss one of the ways in which the Lync UI can be customized to help offer contextual options that are specific to your own business needs: by creating custom menu items. Continue reading “Adding custom menu items to the Lync client” »

Unexpected places to find information in UCMA

Once in a while I need to find a specific detail on a call or some other Lync object, and have to pore over the SDK documentation for long periods of time to figure out where to get it. After doing this many times, I’ve found that there are a few unintuitive places where useful pieces of information often turn out to be hiding. I thought I would share a few of these in this post. Continue reading “Unexpected places to find information in UCMA” »

Media troubleshooting and quality data in UCMA 3.0

There is a little-known feature in UCMA, introduced in version 3.0 of the API, that allows applications to receive a detailed report on the call quality metrics of each audio/video call when it concludes. The data reported to the application are essentially the same that are included in Lync Server’s call detail recording (CDR) records, and by receiving the information in a UCMA application in real time as calls conclude, you can correlate quality data with other information you collect or record about calls, or even adjust your application’s behaviour on the basis of call quality metrics. Continue reading “Media troubleshooting and quality data in UCMA 3.0” »

Manipulating SIP headers with UCMA

For the most part, UCMA keeps Lync operations at a high level, and allows you to ignore the details of the SIP messages that are going back and forth. At times, however, you may need to look at the actual SIP message that a UCMA application is sending or receiving, or add a specific header to an outgoing message. This post shows how to do both of these things. Continue reading “Manipulating SIP headers with UCMA” »

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.