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.

Third-party manual audio routes: not possible

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

A while ago, in a post about how “manual audio routes” work behind the scenes, I mentioned I was planning to see if it was possible to set manual audio routes for endpoints other than the “local” endpoint for the call, by sending INFO messages manually to the audio/video MCU. In other words, can I join a conference from my UCMA application as a trusted participant, and then send manually constructed INFO messages to create a manual audio route between two other participants in the conference?

organ pipes

Manual audio routes in 1917

Over the holidays, I did some tinkering and found that, sadly, this “third-party” manual audio route control isn’t possible, even with manually constructed INFO messages. It seems that there is an A/V MCU policy that prevents an endpoint, even a trusted endpoint, from configuring manual audio routes for any other endpoint. An endpoint is only allowed to create manual audio routes to or from itself.

To test this, I set up a conference and joined it as a trusted participant from a UCMA application, and then sent an INFO message with a <modifyEndpointMedia> C3P command to the A/V MCU. This is the command that controls manual audio routes, among other things, and some of the details are in my previous blog post on how manual audio routes work. The message contains identifiers for the user and endpoint whose routes are being modified, and I changed this to represent a different user in the conference. At first, I got errors saying the message was improperly formatted, and it took a while to get the message syntax correct. I did eventually manage to figure out the message format, only to find that the correctly-formatted INFO messages were rejected by the MCU with an error saying the action was prohibited by policy.

I also tried sending the modifyEndpointMedia commands on behalf of another user in the conference – there is an attribute in the message that identifies the message sender, which you can change to effectively impersonate another conference participant. This didn’t work either.

This is unfortunate, but at least now it’s pretty clear that third-party manual audio route control isn’t possible today with Lync Server. The limitation appears to be in the A/V MCU itself rather than in UCMA. I don’t have any information on the reasons for the limitation – if anyone has any ideas, please feel free to comment.


2 Comments on “Third-party manual audio routes: not possible”

  1. 1 Kiel Howell said at 12:40 pm on August 16th, 2013:

    Michael, I’ve been trying to get the manual audio routes to work for my conferencing of 2 B2B calls, but I can’t get the DTMF’s to go through. Frustrated, I decided to try a different tack and just establish an AudioVideoCall to the outside customer (my cell phone in this test case) and attach a Player to the AudioFlow so that I could play a WMA of the correct DTMF that the other party pushes. It still won’t go through. Any thoughts or help?

  2. 2 Michael said at 10:27 pm on August 21st, 2013:

    Hi Kiel,

    Conferences don’t pass along DTMF tones by default. You need to set the IsDtmfEnabled property to true on the manual audio route object (IncomingAudioRoute or OutgoingAudioRoute). Let me know if that works for you.

    Michael


Leave a Reply

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

  •