Third-party manual audio routes: not possible

Posted: January 3rd, 2013 | Author: Michael | Filed under: UCMA 3.0, UCMA 4.0 | Tags: AVMCU, manual audio routes | 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?

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.

---