1

In a Trusted Application Endpoint I have to publish users states based on en external presence provider, and I can do that (clearing them later when the external source goes "Idle" is a different problem)

What is a problem though is that if I publish a new state for User A, that is not reflected on that users own Lync Client, though everybody else get the updates.

At this moment I'm using this snippet of code to do the publishing: 

    user.Endpoint.LocalOwnerPresence.BeginPublishPresence(
        user.categories,
        arBeginPublishPresence =>
        {
            try
            {
                user.Endpoint.PresenceServices.EndUpdatePresenceState(arBeginPublishPresence);
                logger.log("Published presence for {0} with state {1}.", user.SipUserUri, newState.Availability);
            }
            catch (RealTimeException ex)
            {
                logger.log("Failed publishing presence for {0}. {1}", user.SipUserUri, ex);
            }
        },
        null);

Where user.categories is:

            PresenceCategoryWithMetaData stateWithMetaDataForPersonal = new PresenceCategoryWithMetaData(++instanceId, 400, newState);
            PresenceCategoryWithMetaData stateWithMetaDataForWorkgroup = new PresenceCategoryWithMetaData(instanceId, 300, newState);
            PresenceCategoryWithMetaData stateWithMetaDataForColleagues = new PresenceCategoryWithMetaData(instanceId, 200, newState);
            PresenceCategoryWithMetaData stateWithMetaDataForExternal = new PresenceCategoryWithMetaData(instanceId, 100, newState);
            PresenceCategoryWithMetaData stateWithMetaDataForAll = new PresenceCategoryWithMetaData(instanceId, 0, newState);
            if (instanceId >= Int64.MaxValue)
            {
                instanceId = 1;
            }

            stateWithMetaDataForPersonal.ExpiryPolicy = expirypolicy;
            stateWithMetaDataForWorkgroup.ExpiryPolicy = expirypolicy;
            stateWithMetaDataForColleagues.ExpiryPolicy = expirypolicy;
            stateWithMetaDataForExternal.ExpiryPolicy = expirypolicy;
            stateWithMetaDataForAll.ExpiryPolicy = expirypolicy;

            stateWithMetaDataForPersonal.Expires = timeout;
            stateWithMetaDataForWorkgroup.Expires = timeout;
            stateWithMetaDataForColleagues.Expires = timeout;
            stateWithMetaDataForExternal.Expires = timeout;
            stateWithMetaDataForAll.Expires = timeout;

            user.categories =
                new List<PresenceCategoryWithMetaData>()
                        {
                            stateWithMetaDataForPersonal,
                            stateWithMetaDataForWorkgroup,
                            stateWithMetaDataForColleagues,
                            stateWithMetaDataForExternal,
                            stateWithMetaDataForAll
                        };

The categories are carpet bombing the presence state, and I just know I'm doing it wrong. It can not possible be this ... messy.

Please bear with me, I'm new to C#, .NET and UCMA, never touched any of it till a month ago.

A.Grandt
  • 2,242
  • 2
  • 20
  • 21

1 Answers1

0

This seems like the right behaviour to me. Lync will aggregate presence across ALL endpoints that the user is signed in on, to give a single presence state. For example, if the user is signed in to Lync on his PC with his presence set to "Away", and also on his mobile client with a presence of "Available", then all users will see an aggregated presence of "Available" - because he is available to reach on one of the endpoints. However, his Lync client will still be "Away".

So I think the same thing is happening for you. Your UCMA app is just another endpoint that you're publishing presence from. You may be publishing a presence of "Available", but it is presence from the endpoint in the UMCA app, so it won't affect any other endpoints he's signed in on, e.g. the Lync client. However, all other users will see the aggregated presence state.

This is more of an educated guess than anything I've proven with code. I've had a scout through the SDK, but I can't see any way to "override" the other endpoint's presence (and actually, doing that strongly feels like the wrong behaviour).

Paul Nearney
  • 6,965
  • 2
  • 30
  • 37
  • It turns out that adding ContainerId 2 actually seems to do this. – A.Grandt Apr 20 '12 at 22:23
  • That makes some sense I guess - you'll just need to make sure that the container ID does map back to the endpoint you want - e.g. if the user is signed in on Mobile and PC, do you want to change both, or just target the PC, and then you'll need to understand which container to update. Also, bear in mind if you do this and set the users state in Lync to e.g. busy, there is nothing to stop them changing it back ond overwriting your change – Paul Nearney Apr 20 '12 at 22:28
  • I know. I've tried to subscribe to presence updates as well, and it had bit me a few times when a posted presence resulted in a received event, which caused a new post...Instant log filler :) The one that does have me concerned is the state updates where the xml message itself returns one state, but the aggregatesState object is -1 and "None" – A.Grandt Apr 20 '12 at 22:44
  • To be exact, what I'm actually trying to do is to post an activity on a presentity, with for instance "Phone offline", where the user can change their status at will, but retain the notice, or if the Phone is busy, set the actual state to busy with a message "like "On the phone", and hold it there till the user is no longer talking on the phone. I can push these, though I'm not certain I am doing it right. My failures to clear the message once the phone reaches an idle state that does not require a custom message suggests that I am not. – A.Grandt Apr 20 '12 at 22:53
  • I found my bug, I used a new instanceId on every presence update, so calling BeginDeletePresence did nothing, as I still had a plethora of older presence states in the Lync system. – A.Grandt May 16 '12 at 13:57