How to tell if a call is put on hold in UCMA

If your application handles audio calls with users, you may need to be notified when one of those users places the call on hold. It’s relatively easy to get these notifications in UCMA, but it can be a bit counterintuitive, because there is no event anywhere called HoldStateChanged or anything like that.

Why would you need to be notified when the call goes on hold? If your application is interacting with the user in some way (like an IVR), you might want to “pause” the interaction until the user comes back from hold. If the application brokers calls between users in some way, it might be important to play hold music or notify the other user in some way if one user puts the call on hold.

At a SIP messaging level, what happens when a Lync endpoint puts a call on hold is that the endpoint sends a new SIP INVITE message within the same SIP dialog. This is usually called a re-INVITE, to distinguish it from the initial INVITE that started up the call. The re-INVITE contains new media information in Session Description Protocol (SDP) in the body of the message; this process is called media re-negotiation. The new SDP contains an attribute indicating that the call is on hold.

It just so happens that there is an event on the AudioVideoFlow class that is triggered by changes on a call that involve media re-negotiation. This is the AudioVideoFlow.ConfigurationChanged event. If you hook up an event handler to this event, it will be trigged when the call goes on hold (or off hold).

Unfortunately, the event arguments don’t have any information on what configuration change has actually occurred. So you need to check the properties on the AudioVideoFlow to figure out exactly what happened. You can check the AudioVideoFlow.HoldState property to see whether the call is currently on hold, and respond accordingly.