Based on some recent experiences, I wanted to write up a quick summary of how the UCMA runtime handles incoming SIP messages, which is somewhat different from how it works with the Lync client. Continue reading “How UCMA handles incoming messages” »
Microsoft SIP Processing Language (or MSPL), a part of the Lync Server SDK, is a fantastic and currently underused tool for overriding or extending Lync routing behaviour to meet business needs. I’ve written about some of its capabilities and how to use it in previous blog posts. It’s handy for things like intercepting and blocking calls with certain characteristics, filtering messages, logging or monitoring communications, or rerouting calls to different destinations. It’s also probably the Lync API that has remained the most unchanged from version to version. In Lync 2013, it’s managed to hang on to this distinction, with only a couple of additions, but one of them is really quite interesting and potentially useful, and I wanted to bring it to everyone’s attention here. The new RetargetRequest method allows you to have an MSPL script change the destination a message is going to, but without bypassing the rest of the scripts that are installed on the Lync server. Continue reading “New MSPL function in Lync 2013: RetargetRequest” »
In my past blog post on standalone UCMA applications, I described how to build a UCMA application that can answer calls totally independently of Lync Server. Since then, I’ve gotten a lot of questions about standalone UCMA applications, and I wanted to answer two of them in this post. The first is how to place outbound calls from a UCMA application that isn’t connected to Lync Server. The second is how to bypass Lync Server for certain calls from a UCMA application that is connected to Lync Server.
For both of these things, you can use an awesome, little-known UCMA class called ConnectionContext. Continue reading “Outbound calls from UCMA without Lync Server” »
One of the cool things about Lync that people often take for granted is that you can sign in from multiple computers (or devices), and any call that is sent to you will ring at all of those various locations. There’s quite a bit of complex routing logic that goes into this, but it mostly takes place under the covers, and even when you’re developing a UCMA application, you generally don’t need to worry about it. If you create a new AudioVideoCall object and call AudioVideoCall.BeginEstablish with a SIP URI, Lync automatically “forks” that call to all of the registered endpoints for that user. Basically when the call hits the Lync Front End Server, the Front End Server sends a branch to each of the endpoints where that user is signed in. The first one to answer gets to take the call.
While it’s very courteous of Lync Server to do all of this stuff on its own without bothering us, the branching behaviour can sometimes get in the way. You might want to send an IM or a call to a user at one specific location. Maybe you want a call to go only to the user’s IP desk phone, but not to the Lync client on the PC. What do you do in a case like this? Continue reading “Sending a call to a specific endpoint in UCMA” »
If you have a UCMA application that does call routing, particularly one that is designed to get callers to an available person, you may need a way to figure out whether your call has been answered by the person you were trying to dial, using Lync; whether it has been picked up by Exchange UM voicemail; or whether it has been redirected to another Lync user or a PSTN phone number. This way, you can avoid situations like sending an irritable customer who wants immediate assistance to the voicemail box of someone whose name they have never heard before. Continue reading “How to know when voicemail answers a Lync call” »
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?” »
UCMA 3.0 introduced the concept of a “default routing endpoint.” To put it very generally, a default routing endpoint is a single application endpoint that receives any messages that have nowhere else to go. I’ll illustrate further in a moment. When I first heard about this new feature, I could not understand what use it could possibly have. Gradually, over a period of months, situations came up where default routing endpoints turned out to be very handy. Since I figure that other folks might have the same initial reaction of complete confusion when hearing about the default routing endpoint feature, I thought I would write up a bit of explanation on this odd but useful creature in the hope that it will help in others’ development efforts. Continue reading “Default routing endpoints in UCMA” »