c# - Lync UserEndpoint appears online to users but can't be called -

i have lync 2013-based application which:

1. connects userendpoint (hereinafter callcenter) redirects calls made callcenter according bla bla bla business logic.
2. at times, user see callcenter in standard lync 2013 client online, if user attempts start im call callcenter, user receives message "we couldn't send message because callcenter unavailable or offline."

i haven't been able identify process leads this, if it's happened 1 user, of other users experience same problem when attempting call callcenter. way have been able recover callcenter has been restart application. regular interaction callcenter resumes without problem.

if callcenter indeed "unavailable or offline", why it's presence appear "online"? there need renew / keep callcenter's connection alive every often?

for reference, connect callcenter so:

userendpointsettings settings = new userendpointsettings(useruri, _proxyhost, _proxyport); settings.automaticpresencepublicationenabled = true; settings.presence.userpresencestate = presencestate.useravailable;  _userendpoint = new userendpoint(_platform.collabplatform, settings); _userendpoint.beginestablish(res => {     try     {         _userendpoint.endestablish(res);         _userendpoint.statechanged += new eventhandler<localendpointstatechangedeventargs>(_userendpoint_statechanged);     }     catch (exception ex)     {         logerror(ex, errorreference.endpointestablishfailed);     } }, null); 

in client, when go offline or experience error, presence reflects (most of time, is). can lead believe status portion of presence [1] somehow tied actual availability.

when you're working ucma, given ultimate control on related endpoint. you've seen, can make ucma application things otherwise impossible in regular client. don't have publish any presence status (leaving "offline" users), yet service can still send/receive ims. and, you've seen, service can "available" , yet ... have no capability but publish status [2].

if fail wire appropriate modality (in case im), or application encounters exception results in particular modality no longer working (i suspect may actual problem), status of service still available.

begin/endterminate on userendpoint should publish offline automatically , publishing presence other available way guarantee presence won't "available" lifetime of application (and after application ends/dies prematurely, though rectified server -- sometimes).

here's how i'd attack resolving issue. ignore presence problem , ignore error. they're red herrings. many problems result in "unavailable or offline" message have nothing service being stopped.

instead, figure out why calls aren't connecting.

if call takes while before receive error, check deadlocks or circumstances thread pool has no room thread. troubleshooting involves reviewing code race conditions , myriad of other things multi-threaded applications throw way. if imcall fails instantly, check around parts handle incoming calls. in latter case, subscription may gone (too many causes list here, of .net related, not ucma related), or service may dead.

if importance of presence application show "available" or "offline" when able send/receive im, you're going want ensure application terminates endpoint during tear-down (including in case of critical failure: catch-terminate-rethrow or whatever appropriate in case).

[1] careful when thinking term "presence" relates lync. presence contains availability status, modality specific states, capabilities (im/voice, etc), "note" , contact information.

[2] seems bizarre thing do, however, gave me ability use applicationendpoint report on availability of web service (unrelated lync) wanted able view in mobile client without connecting via vpn. when doing this, it's important publish capabilities of endpoint -- explicitly signal connected clients service can , cannot do.

[final footnote] there few ways publish presence. mechanism you're using publish simplest , logical use if you're interested in telling users "service here"/"service not here" documented rather here: simplified presence publication endpoints