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.

This effect can be multiplied in cases where a UCMA application maintains multiple audio/video calls with a conference, in order to provide separate services such as DTMF menus, recording, or hold music. Each of these individual calls requires a separate pair of media streams between the audio/video MCU and the UCMA application, as the following diagram illustrates.

Multiply this by hundreds or thousands of calls, and you can have some significant effects on network usage.

Often these audio/video calls between the UCMA application and an MCU or other Lync endpoint are there primarily to keep the SIP signaling session active, and not for sending or receiving media. In other cases, the application needs to deal with media, but only for brief periods or under certain conditions (e.g., if hold music is activated). This means that there is media traffic flowing to and from the UCMA application for no purpose, using up network bandwidth needlessly.

One way to help reduce this extraneous traffic is to put these calls on hold, using the AudioVideoFlow.BeginHold method in UCMA. Here is an example of the code you might use:

This will cause UCMA to send a new SIP INVITE message (a “re-INVITE” because it is not the initial INVITE that set up the call). This re-INVITE, like the initial INVITE, has a message body consisting of Session Description Protocol, but with a single line added:

a=inactive

This line indicates to the remote endpoint that audio media is temporarily inactive. If you try this out on a call from a UCMA application to an audio/video MCU, you’ll see that the network traffic decreases after the call is put on hold.

If your application is a trusted participant in a conference, there won’t even be a visual indication of the call hold; no one else in the conference will have any idea that something has changed. If the application is not a trusted participant, or is on a two-party call, the Lync UI will show that the application’s call is now on hold.

If your application needs to do something with media again (like recording the call or playing a message) you can take the call off hold just as easily:

If you put calls on hold immediately after they’re established, you may run into some situations where the AudioVideoFlow object for the call doesn’t exist yet. To get around this, you can create an event handler for the AudioVideoCall.AudioVideoFlowConfigurationRequested event, like this one: