The BackToBackCall class is staple of more complex UCMA applications, especially those that perform some kind of third-party call control (brokering or providing services to calls between other users). In a nutshell, the BackToBackCall class allows a UCMA-controlled endpoint to keep a handle to a call that is going on between two other endpoints, rather than between a single remote endpoint and the UCMA application. But there are several features of the BackToBackCall class that you may not be aware of, that can be helpful in certain situations. Continue reading “Advanced BackToBackCall features” »
If your application handles audio calls with users, you may need to be notified when one of those users places the call on hold. It’s relatively easy to get these notifications in UCMA, but it can be a bit counterintuitive, because there is no event anywhere called HoldStateChanged or anything like that. Continue reading “How to tell if a call is put on hold in UCMA” »
One of the more common uses of UCMA is to create outbound dialer applications. Unfortunately, many people run into a frustrating problem at first when building dialers in UCMA: the first few seconds of audio seem to get lost somehow. When someone picks up the phone and says “Hello,” the first few seconds of audio back to the dialer get clipped, and there is often a delay before the recipient of the call hears the UCMA application play its message. Continue reading “Avoiding clipping with outbound UCMA calls” »
For complex UCMA applications that handle things like quality monitoring, call recording, or call flow management, the effect of the UCMA application on network traffic can become a concern. For a UCMA application to act as a participant in an audio, video, or application sharing call, there must be a media stream flowing from the application to the remote party on the call, and another media stream flowing from the remote party back to the application, as in the diagram below. Each of these streams will take up bandwidth on whatever network the media must traverse to flow between the endpoints, or on the connection to the public Internet if the remote endpoint is an individual user logged into Lync remotely. Continue reading “Reducing media traffic from UCMA using call hold” »
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” »