Microsoft Lync has a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use them.

Advanced BackToBackCall features

Posted: January 27th, 2013 | Author: | Filed under: UCMA 3.0, UCMA 4.0 | Tags: , , , | 3 Comments »

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.

Figuring out when media has established on a back to back call

One of the tricky parts of using back to back calls is that the UCMA application isn’t a part of the media stream at all. Media is sent directly between the two other endpoints, even though the SIP messages are proxied through the UCMA application. So a back to back call doesn’t get an instance of AudioVideoFlow, and it can be difficult to tell when the media connection has been established.

Why does this matter? Well, one common use of the BackToBackCall class is to connect other Lync endpoints to an audio conference while retaining full control of the call. If you don’t know when the media connection has established, and you start playing messages, hold music, etc. too early, the first bit of the audio can get clipped off.

To help with this, the BackToBackCall class has an event called RemoteMediaFlowStateChanged, and a corresponding property called RemoteMediaFlowState. All you need to do is create an event handle for RemoteMediaFlowStateChanged, and hold off on playing any audio in your conference until the state has gone to Connected.

Customizing SIP headers

The BackToBackCallSettings class, which you use to set the incoming and outgoing calls for the back to back call, also has properties for an instance of CallEstablishOptions and an instance of CallAcceptOptions. You can use the Headers property on either of these to provide custom SIP headers for either the response to the incoming call leg or the SIP INVITE message for the outgoing call leg.

Setting pass-through headers

As an alternative to providing specific headers to be added to the outgoing INVITE, you can instead specify the names of headers that should be passed through from the incoming call to the outgoing call, using the SetPassThroughHeaderNames method.

When the back to back call creates the outgoing call leg, it creates a completely new SIP INVITE message, and plugs the media information from the incoming INVITE into it. By adding a SIP header name to this list of pass-through headers, you tell UCMA that the header should be copied over from the incoming INVITE to the outgoing INVITE. If there is custom context data of some kind in the incoming INVITE messages, perhaps from an MSPL script, and you need to preserve it in the outgoing leg of the back to back call, this can be invaluable.

If you want to find out which headers are specified as pass-through headers, you can call the GetPassThroughHeaderNames method.


3 Comments on “Advanced BackToBackCall features”

  1. 1 Joel said at 6:12 pm on February 28th, 2013:

    I am using MSPL to proxy all invite requests from Lync 2013 Server to my UCMA 4.0 application. If I create a backtobackcall to the original recipient(e.RequestData.ToHeader.Uri) The outgoing leg of the back to back arrives at the recipient and they can answer the call. However the call never ends been established correctly as the EndEstablishCallBack is never reached.
    The original recipient lync client shows the text ‘Connecting Call…’. The source lync client shows ‘Calling Lync…’. Is there something special that needs to occur in this scenario?

  2. 2 Michael said at 6:03 pm on March 11th, 2013:

    Have you tried running SIP logging using the Lync Server Logging Tool to see what’s happening during the call establishment?

    Is it possible that your MSPL script is interfering with one of the response messages, or is it set to pick up requests only?

  3. 3 Nuwan said at 6:18 am on November 19th, 2013:

    Hi Michael,
    I’ve been reading your posts and other help materials available on Microsoft; however I couldn’t find answers to my specific requirement. I need to implement a UCMA call platform which can answer incoming calls (A leg), do some processing (detect DTMFs, play audio messages) then create a remote call leg (B leg) from UCMA and join those legs together. Finally record the call. UCMA application should be standalone without a Lync server. I found your 2 posts “UCMA 3.0 applications without Lync server” and “Outbound calls from UCMA without Lync server” very helpful. Thank you for posting those 2 articles. The issue I’m having is how to join 2 call legs. Would you please be kind to point me on right direction?
    Thank you


Leave a Reply

  • Note: Comment moderation is in use because of excessive spam. Your comment may not appear immediately.

  •