Lync conference invitations in SIP terms

From the Lync client, the process of inviting someone to a conference, or of being invited to a conference, seems simple and straightforward. The recipient clicks on the incoming call popup to accept the invitation, a Lync conversation window opens up, and he or she is connected to the conference. If you take a look at the SIP messaging that is going on during this process, though, it is quite a bit more involved than you might expect. Inviting a new participant to a typical audio conference involves three separate SIP dialogs.

The first one is to actually deliver the conference invitation. This is the message that goes from the “inviter” to the “invitee” giving the details of the conference. For purposes of illustration, let’s say we have a UCMA application joined to an audio conference, and the UCMA application is inviting a Lync user to the conference using the ConferenceInvitation.BeginDeliver method. The first thing that will happen is that the UCMA endpoint will send a special type of INVITE message to the Lync user.

Instead of having Session Description Protocol content in the message body, this INVITE message will have a content type of “application/ms-conf-invite+xml.” The XML message body will contain the conference URI and some other basic details:

<Conferencing version="2.0">
    <focus-uri>sip:mgreenlee.test@domain.local;gruu;opaque=app:conf:focus:id:JL3GPNYP</focus-uri>
    <subject />
    <audio available="true" />
    <im available="false">
        <first-im />
    </im>
</Conferencing>

Once the Lync user accepts this INVITE, the application will end the signaling session right away, since there’s nothing else to communicate. So much for signaling session #1.

The next step is for the Lync user to actually connect to the conference. The important concept to get here is that, at this point, the inviter is no longer involved. The UCMA application does not have any role in getting the Lync user connected to the conference. It simply sends over the conference URI and lets the Lync endpoint take it from there. (Depending on the the access settings for the conference, it may also add the invited user to the list of conference participants.)

In joining the conference, the first step is to start a signaling session with the conference focus. This time, the new conference participant contacts the focus directly with another INVITE.

This INVITE has a content type of “application/cccp+xml.” The CCCP stands for Centralized Conference Control Protocol, which is the protocol Lync uses for communications with conference server roles. The message body is an XML document that contains an “addUser” request. This is essentially the Lync user telling the focus, “Please add me to this conference.” If you look at the To header in the INVITE, you can identify the recipient as the conference focus:

To: <sip:mgreenlee.test@ccdev.claritycon.com;gruu;opaque=app:conf:focus:id:JL6GPNBP>

You can also see the ID of the conference:

To: <sip:mgreenlee.test@ccdev.claritycon.com;gruu;opaque=app:conf:focus:id:JL6GPNBP>

Once this session is established, the Lync user is connected to the conference, but does not yet have any media sessions established. (This is the point where you can see someone in the conference roster, but the phone icon, IM icon, etc. next to their name are still grayed out.) The next step is to get connected to the media. For an audio conference, this means dialing in to the audio/video MCU: our third SIP dialog.

This third INVITE message is addressed to the audio/video MCU, as you can see by looking at the To header:

To: <sip:mgreenlee.test@ccdev.claritycon.com;gruu;opaque=app:conf:audio-video:id:JL6GPNBP>

The signaling is actually handled by the conference focus again, while the media flows directly to the MCU. Unlike the other two, this INVITE is much like an ordinary two-party audio call, with SDP in the message body. The SDP is used to negotiate media transmission between the Lync user and the A/V MCU. One major difference is the presence of the a=cryptoscale attribute in the SDP, which I discussed in a previous post.

Once this signaling session is established, and media begins flowing between the Lync user and the MCU, the conference join is complete.

Any time your application invites someone to a conference, these three steps must occur for the invitee to successfully join the conference. Keep this in mind if you are looking at SIP logs for troubleshooting or if you are manipulating SIP messages using an MSPL script.