Handling conference calls in Lync Client

Note: this post is part of Lync Client development series. You can find the following topics here:

• Microsoft Lync Client Development,
• Sign in and out in Microsoft Lync Client,
• Lync Controls inside Lync Client SDK,
• Starting with Lync Client’s API,
• Handling some common scenarios with Lync Conversation,
• Handling transfers in Lync Client API,
• Handling conference calls in Lync Client,
• Availability (presence) in Lync Client.

Hello everyone!

This time, I’ll deal with some scenarios concerning conference calls. As you know, there are lots of ways you can start a conference: you can do it implicitly by clicking on ‘Meet Now’ button (on a main menu or when clicking Options button), or explicitly by inviting someone else in an existing conversation. In either way, a conference call is a special call (not just by number of participants) that could/should be handled.

First of all, as with a call transfer, there is no special state on a conversation level to indicate we are in a conference. Also, this is the case with an active audio/video modality. But, let’s see what can we track to be able to see how is conference going. We will be looking at one typical scenario: imagine a user who calls another user, and after that, this second user invites another user into this very conversation (albeight, audio call). In this moment a conference is being initiated and participants changed. Let’s see a workflow for it:

Scenario: user1 calls user2 , which invites user3 into the call (makes a conference).

This is what happens from the side of user2 (user which actually creates a conference out of an incoming call):

• user2 clicks on ‘People Options’ button and clicks on ‘Show Participant List’ to see who is in a call, and then clicks on ‘Invite by Name or Phone Number…’ option to invite user3,
• conversation’s property ConferenceEscalationProgress is changed to 2 (ConnectingToConference),
• ConferenceEscalationProgress = 4 (JoiningLocalMedia),
• ConferenceEscalationProgress = 6 (WaitingForPeer),
• user’s availability changes to Busy (activity changes to: In a conference call),
• AVModalityState = OnHold,
• ConferenceEscalationProgress = 7 (Completed),
• ConferenceEscalationResult = 0 (without errors),
• ConferencingUri = sip address of user1,
• ConferenceAccessInformation property is available,
• AVModalityState = Connected,
• ConversationState = Inactive,
• AVModalityState = Disconnected.

If you notice the changes in the GUI, firstly, picked (invited) user is in the Attendees list, and when he accepts the conference call, he is in the Presenters list, together with the user1 and user2. We will not deal with the details of sorts of participants in this post, but it is notable to say that it also could/should be handled if necessary.

After user2 ends the call/conference, ConversationState changes to Inactive state, and AVModaltityState to Disconnected state, which is quite understandable. On the conversation window a notification panel appears (in yellowish color) to indicate that ‘You have left the call’, whit an option to ‘Rejoin’ the conference.

ConferenceEscalationProgress is not changed after that, which is important, so you have to keep track on the active modality and conversation to know whether a conference has ended or still active.

So, from the perspective of a second user, what could we do to keep track on a conference call? We should store two important conversation properties – ConferenceEscalationProgress and ConferencingUri – when they are changed. Next, when audio call gets Connecting, we should query this Uri property and set the call to an incoming type and calculate values for the call.

And now, let’s see what happens from the side of user3 (user which is invited to a conference – as a third participant):

• new conversation added,
• new audio/video call registered,
• Conversation.ConferencingUri = sip address of user2,
• Conversation.Inviter = the same as previous,
• ConversationState = Active,
• AVModalityState = Notified (this indicates an incoming call from user2),
• invitation is accepted,
• ConversationState = Inactive,
• AVModalityState = Connecting,
• ConferenceEscalationProgress = 2 (ConnectingToConference),
• ConferenceEscalationProgress = 4 (JoiningLocalMedia),
• ConversationState = Active,
• AVModalityState = Joining,
• AVModalityState = Connected,
• ConferenceEscalationProgress = 7 (Completed),
• ConferenceEscalationResult = 0 (without errors),
• user’s availability changes to Busy (activity changes to: In a conference call).

Notice couple of things in this workflow: ConferencingUri property is (luckily) set very early in stack, so this should be indication that there will be a conference call pending. There is no OnHold (or Transferring) events, but rather some sort of ‘mix’ of events that usually indicate an incoming/outgoing call: Notified -> Connecting -> Joining -> Connected. So, you have to be very careful when dealing with these. Additionaly, there is no ConferenceEscalationProgress change to value 6 (WaitingForPeer), since this in an ‘incoming conference invitation’. And lastly, user’s availability status change is now last in the stack (i.e. when conference escalation is completed).

As you could see, a conference call is quite different from other sorts of calls, and should be treated differently. There are different kinds of conference call scenarios which are not taken into account in this post. And lastly, note that even when a single participant stays in a conference, conference is active (user is in state ‘In a conference call’), talking to himself.