Conference invitations vs. MCU dial-outs
Posted: December 20th, 2011 | Author: Michael | Filed under: Conferencing, Lync Development, UCMA 3.0 | Tags: AVMCU, dial out, MCU | 10 Comments »At times I find it confusing to how an MCU dial-out (as triggered by methods like AudioVideoMcuSession.BeginDialOut in UCMA) differs from a conference invitation (ConferenceInvitation class in UCMA). In my previous post I described what happens behind the scenes when a conference invitation is sent to a Lync user, so I thought I would take this post to explain the very different process that occurs during an MCU dial-out. UCMA does a very good job of putting a layer of abstraction over the extensive SIP signaling that goes on at a lower level during both of these operations, which is a good thing overall, since it frees up developers to focus on solving business problems using the API. However, at times it is useful to know things like the underlying difference between a conference invitation and an MCU dial-out in order to solve complex technical questions.
The primary difference has to do with the direction of the call. With a conference invitation, the invitation itself goes from the inviter (such as a UCMA app) to the user being invited. When a Lync client receives a conference invitation, it initiates the connection to the conference (actually two connections: one to the focus and one to the MCU).
In an MCU dial-out, however, it’s reversed. The UCMA application sends a request to the MCU that essentially says “please invite this user to the conference.” The MCU itself then calls the new participant. This means that the UCMA application has no direct contact with the user who is being invited to the conference.
So, to rehash that in pictures, here’s the conference invitation process:
First, the inviter sends an invitation to the invitee. The invitee then joins the focus, followed by the MCU.
For contrast, here’s the process for an MCU dial-out:
In this case, the inviter asks the MCU to dial out to the invitee. The MCU initiates a call to the invitee. The invitee then joins the focus and accepts the call from the MCU.
Now, you might be asking what advantage there is in using an MCU dial-out instead of a plain old conference invitation.
First of all, there are some types of conference participants that can’t receive a conference invitation. For instance, inviting a PSTN participant to join a conference by sending it an XML document with the conference URI is not likely to be successful. So you can use a dial-out instead to directly call that participant.
Second, for call flow reasons it may be necessary to have an outbound call coming from the MCU instead of an inbound call to the MCU. If you are trying to set up a BackToBackCall between the MCU and a new conference participant, for instance, you can have the MCU dial out to your UCMA application, and then have the application create an outbound call to a user and stitch the two calls together with the BackToBackCall class.
Regardless, the end result of both processes is the same: you end up with a new participant in the conference.
Hi Michael,
I have an application where I want to backtoback an outgoing call from a conference to a participant.
That works, thanks to your hint.
But now I want to setup multiple backtoback calls from the conference to different participants at the same time.
This doesn’t work, I get an error message like “The request failed with reason: userReplaced.” on the EndDialOut method of the first participant, when I dialout to the second participant from the conference.
Is there a way to achieve this?
Many thanks in advance.
Marcel – that’s a good question; I suspect there’s not a good way to get it working with multiple calls, because from the perspective of the MCU doing the dial out, it appears that it’s adding the same user (your application) multiple times. So it will remove the earlier call when you add the new one to the same SIP URI.
Probably the solution would have to be using multiple application endpoints to receive your dial outs and create the back to back calls.
Hi Michael,
I used your example described in http://msdn.microsoft.com/en-us/library/hh527751
But i figured out that when refer support is disabled, the self transfer failes most of the time.
What i then tried to achieve is the same behaviour by using a dialout from a conference with AudioVideoMcuDialOutOptions.RemoveFromDefaultRouting = true.
I didn’t care about care about the advantages of the BackToBackcall functionality at this time.
Although the conversation is joined as trusted i receive a ConferenceFailure exception saying: 7044:Requested AddUser not allowed by policy
I used the Lync logging tool to find out more information about this exception and found the following on the conferencing server.
An exception occurred while processing an ‘Add User’ request.
Sending response code: OtherFailureConference
URI: sip:application_endpoint@domain.com;gruu;opaque=app:conf:focus:id:JYXR06WK
User URI: sip:supervisor@domain.com
Exception: Microsoft.LiveServer.Mcu.AudioVideo.UnAuthorizedRequestException: ConfFilter can only be sent by Trusted endpoints
The trustedapplicationendpoint is granted all options of a conferencing policy.
This didn’t work unfortunately, so i tried the following.
I tried to achieve the same behaviour as the example (with b2b). But slightly different.
Instead of letting the supervisor selftransfer itself to handle an incoming call,
I made a dialout to another trustedapplicationendpoint associated with the same trustedapplication.
(So basically calling the application itself)
So i had a new incoming call, which i could b2b to the supervisor.
But now the EndEstablish method of the BackToBackcall class finishes succesfully, but the invite is never reaching the supervisor.
(With RemoveFromDefaultRouting enabled), if i set RemoveFromDefaultRouting to false, the request is coming in fine, but then the supervisor is in the default audio mix.
I also tried it without the BackToBackcall class. Establishing an AudioVideoCall to the supervisor. But the EndEstablish method of the AvCall also completes succesfully, without an invite.
I guess I’m missing something.
Could you please help me out a bit?
Many thanks in advance.
What failure are you seeing with the self-transfer?
We have been using the MCU dialout way together with a B2B call for a while to deal with outbound calls. It’s a good way of doing this. We used multiple application endpoints to get it working with multiple outbound calls.
One thing we have been observing is that the audio flow establishment seems a bit slow when using BeginDialout. The McuSession is monitored for McuSessionParticipantEndpointAttendanceChanged events. We get the event about 6 seconds after the outbound call is established. This is a bit annoying to have to wait that long before being able to manipulate the participant.
When establishing inbound calls with B2B to the conference the event arrives immediately after establishment.
Thanks in advance
Hi Michael,
I am trying to use a conference MCU dialout to a UCMA application so I can then do a backtobackcall and connect a Lync client to the conference, all based upon samples from chapters 11 and 12 from your book. It works fine when it is initiated as a two party conversation from a Lync client, but when I initiate the avcall as a dialout from the conference mcu the self transfer fails at _avcall.BeginTransfer(_avcall, …). The result is an InvalidOperationException with message “Cannot send transfer request as the remote participant does not support it”. Do you know what is causing the error?
Thanks in advance for your help.
Hi Jeff,
The AVMCU doesn’t support transfers (a.k.a. SIP REFER requests). But if you’re having the AVMCU dial out to your UCMA app, you should be able to use the resulting incoming call in your UCMA application as the first leg of a BackToBackCall without self-transferring it. Let me know if you’re having trouble getting that to work or if you have more questions about this.
Michael
Hi Michael ,
I have modified the basic conferencing example from UCMA to work for AV call instead of IM conference.
I want to create a scenario where i can send a conference between multiple virtual endpoints (created by UCMA example) and invite multiple other endpoints (logged in to different clients or phones) also .
i am now able to send invitation to multiple virtual endpoints (created by UCMA) to single user who is logged in to other client with :
invitation.BeginDeliver(_ocUserURI, deliverOptions, EndDeliverInvitation, invitation);
Instead of “_ocUserURI” alone , if i want to invite an list of users , is it possible ..
Please let me know if this is achievable .
Resolved ..Thankyou ..:)
Hi Michael
We are escalating a conversation to a conference. With lync users calls it works without problem. But with pstn user call conference is not establishing.
trustedParticipantConversation.ConferenceSession.AudioVideoMcuSession.EndTransfer
is not working. Declining one of participants. Who entered conference firstly then other user declining