Posted: January 17th, 2012 | Author: Michael | Filed under: Lync Development, MSPL | Tags: forking, MSPL | 10 Comments »
In previous blog posts on Microsoft SIP Processing Language (MSPL), I’ve explained how to essentially intercept SIP requests, such as the INVITE message that initiates a call, and pass them along to a UCMA application for handling by passing a parameter to the ProxyRequest method. In this post, I want to discuss what you can do if you want to “fork” a request, which means you are sending it to multiple endpoints simultaneously. Continue reading “Forking SIP requests in an MSPL script” »
Posted: January 12th, 2012 | Author: Michael | Filed under: Conferencing | Tags: AudioVideoMcuSession.BeginTransfer, AVMCU, conference escalation | No Comments »
If you’ve been digging through the archives of this blog, you may remember that, although UCMA doesn’t allow audio/video calls to be escalated to conferences using the Conversation.BeginEscalateToConference method, there is a sneaky alternative way to accomplish the same thing using AudioVideoMcuSession.BeginTransfer. (Incidentally, this technique, which I wrote about for UCMA 2.0, still works in exactly the same way for UCMA 3.0). This is not the only interesting thing you can do with the AudioVideoMcuSession.BeginTransfer method, however. Continue reading “Transferring an A/V call into a Lync conference” »
Posted: January 9th, 2012 | Author: Michael | Filed under: UCMA 3.0 | Tags: composing state, IM, instant messaging, typing notification | 2 Comments »
If you’re writing a UCMA application that handles instant messaging, you may at some point want to replicate the effect that users of the Lync client get where a message shows up notifying you when the other person is typing. This makes it a bit easier for people to carry on a conversation over instant messaging without constantly interrupting one another. Triggering and receiving this notification is actually quite easy in UCMA, but the way to do it is not immediately obvious. Continue reading “How to get the “is typing…” messages through UCMA” »
Posted: January 4th, 2012 | Author: Michael | Filed under: Lync Development, MSPL | Tags: DispatchNotification, Lync Server SDK, Managed SIP Application API, MSPL | 3 Comments »
The Managed SIP Application API, which I discussed in the previous post, allows you to manipulate the content and routing of SIP messages in some potentially very useful ways by running an application on a Front End Server. However, when the volume of messages is very large, dispatching them to managed code can have a significant effect on performance. For managed code applications that simply monitor messages, and don’t modify them or change the routing, there is a way to mitigate this performance impact by sending the message details to the application from the MSPL script in a sort of “fire-and-forget” mode, using the DispatchNotification method. Continue reading “Minimizing performance impact from managed SIP applications” »
Posted: December 30th, 2011 | Author: Michael | Filed under: MSPL | Tags: Lync Server SDK, Managed SIP Application API, MSPL | 11 Comments »
The Lync Server SDK includes an API, the Managed SIP Application API, which is essentially a more powerful and complex managed-code cousin of MSPL (Microsoft SIP Processing Language). It allows you to create applications that, much like MSPL scripts, reside on a Front End Server or one of the other Lync servers (Edge, Mediation, etc.). Unlike MSPL, however, these are created using managed code. The classes that make up the API, which are contained in the Microsoft.Rtc.Sip namespace, allow you to modify SIP messages and control message routing in a number of ways that are not possible with MSPL. Continue reading “Modifying SIP headers using the Managed SIP Application API” »
Posted: December 27th, 2011 | Author: Michael | Filed under: UCMA 3.0 | Tags: media | No Comments »
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” »
Posted: December 20th, 2011 | Author: Michael | Filed under: Conferencing, Lync Development, UCMA 3.0 | Tags: AVMCU, dial out, MCU | 10 Comments »
At times I find it confusing to how an MCU dial-out (as triggered by methods like AudioVideoMcuSession.BeginDialOut in UCMA) differs from a conference invitation (ConferenceInvitation class in UCMA). In my previous post I described what happens behind the scenes when a conference invitation is sent to a Lync user, so I thought I would take this post to explain the very different process that occurs during an MCU dial-out. UCMA does a very good job of putting a layer of abstraction over the extensive SIP signaling that goes on at a lower level during both of these operations, which is a good thing overall, since it frees up developers to focus on solving business problems using the API. However, at times it is useful to know things like the underlying difference between a conference invitation and an MCU dial-out in order to solve complex technical questions. Continue reading “Conference invitations vs. MCU dial-outs” »
Posted: December 15th, 2011 | Author: Michael | Filed under: Conferencing, Lync Development | 1 Comment »
From the Lync client, the process of inviting someone to a conference, or of being invited to a conference, seems simple and straightforward. The recipient clicks on the incoming call popup to accept the invitation, a Lync conversation window opens up, and he or she is connected to the conference. If you take a look at the SIP messaging that is going on during this process, though, it is quite a bit more involved than you might expect. Inviting a new participant to a typical audio conference involves three separate SIP dialogs. Continue reading “Lync conference invitations in SIP terms” »
Posted: December 8th, 2011 | Author: Michael | Filed under: Lync Development, MSPL, OCS Development | Tags: MSPL, SDP | No Comments »
Microsoft SIP Processing Language, a.k.a. MSPL, can be handy for changing Lync’s routing behavior, to do things like block or reroute calls based on their origin, or send all calls of a certain type to a UCMA application. In certain cases, when writing MSPL scripts, you may want your script to behave differently depending on whether it is dealing with an audio call or an instant messaging session. It’s not immediately obvious how to distinguish between these two types of calls in MSPL, so I wanted to write up a quick description of how you can do this. Continue reading “Distinguishing IM vs. audio calls in MSPL” »
Posted: December 1st, 2011 | Author: Michael | Filed under: UCMA 3.0 | Tags: forwarding, routing, SIP, voicemail | 1 Comment »
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” »