There are a number of situations where it is necessary for a UCMA application to connect more than one call to a conference. One example that I’ve seen more than once is the situation where you want your application to play messages to a caller, but you also want to record both the messages and the caller’s response. The way to do this is to create two separate instances of AudioVideoCall, join both of them to the conference, and establish them. One of them can then play the messages, while the other can be hooked up to a Recorder object to record both sides of the conversation.
The problem that developers often face when they first try to do this is that a Lync conference will only allow a given SIP URI to appear in the conference roster once. So if your application simply creates two calls into the conference, using the same endpoint, you will run into trouble with the conference join.
There are a couple of possible solutions for this, and which one you use depends on what exactly you are trying to do.
In most cases, the reason why you need multiple calls to the conference from your application has to do with providing a number of different services to the call: recording, announcements, hold music, or interactive voice response (IVR) menus, for instance. Generally, it’s best to provide these services by having your application join the conference as a trusted participant, meaning that it will not appear in the conference roster and will have elevated permissions in terms of the conference actions it can perform.
When your application is joining a conference multiple times as a trusted participant, you can set the UseGeneratedIdentityForTrustedConference property on CallEstablishOptions to true when establishing the AudioVideoCall that you have joined to the conference. This will cause UCMA to join the conference using a special ad hoc identity rather than using the SIP URI that belongs to the application’s Lync endpoint, allowing you to create more than one of these calls without the SIP URIs colliding.
AudioVideoCallEstablishOptions options = new AudioVideoCallEstablishOptions(); options.UseGeneratedIdentityForTrustedConference = true; conferenceAvCall.BeginEstablish(options, OnEstablishCompleted, conferenceAvCall);
If you won’t be using trusted conference participants, you want your conference participants to be visible, or if you want complete control over the SIP URIs, there is another option. Before joining each call to the conference, you can call the Conversation.Impersonate method to set the SIP URI that your application will use for this call. Impersonation only works with ApplicationEndpoint, but generally any application that is joining multiple calls to conferences should be using ApplicationEndpoint anyway.
Conversation conv = new Conversation(_endpoint); conv.Impersonate("sip:firstname.lastname@example.org", "", "Fake User"); conv.ConferenceSession.BeginJoin(_conferenceUri, null, OnJoinCompleted, conv);
Again, as long as you use a different SIP URI for each instance of Conversation, you can avoid SIP URI collisions in the conference.
Another case where these two approaches come in handy is if you have several participants which you are connecting to a conference using instances of BackToBackCall. The “conference end” of the BackToBackCall will by default be associated with the SIP URI of your application. Depending on what you are trying to do, you may want to either (1) impersonate the SIP URI of the actual participant on the AudioVideoCall that is on the conference end of the BackToBackCall, or (2) if you are using trusted participants, set the UseGeneratedIdentityForTrustedConference property on CallEstablishOptions to true.