Lync: comportamento incoerente con ContactEndpoints

Question

Sto lavorando all'interfaccia utente personalizzata per la directory aziendale basata su Lync. Utilizzando Lync 2013 eseguo questa ricerca:

Container.Instance.Lync.ContactManager.BeginSearch(SearchQuery, 
      SearchProviders.GlobalAddressList, 
      SearchFields.AllFields, 
      SearchOptions.IncludeContactsWithoutSipOrTelUri, 
      500, 
      ContactsAndGroupsCallback, SearchQuery); 

Per ciascuno dei contatti corrispondenti cerco di accedere ai propri endpoint per visualizzare il numero di telefono:

var cit = ContactInformationType.ContactEndpoints; 
var endpoints = contact.GetContactInformation(cit) as List<object>; 

Problema

Se trovato il contatto è in l'elenco dei contatti dell'account che uso per connettere Lync, quindi ottenere l'accesso ai dettagli completi (5 endpoint). Tuttavia, se non è nella lista dei contatti, ho accesso a solo 1 endpoint.

Tutte le idee perché sta accadendo in quel modo? C'è un ambiente di privacy globale che devo disattivare o qualcosa del genere?

Come posso ottenere l'accesso a tutti gli endpoint in ogni momento?

Grazie.

PS: ho provato a caricare ogni contatto nel risultato impostare individualmente e ancora ottenere lo stesso comportamento.

Answer 1

risposta dal supporto Microsoft:

Il comportamento che state vedendo è grazie all'ottimizzazione sottoscrizione di presenza per il client Lync in modo che la sottoscrizione è ritardata fino a quando le informazioni di contatto necessarie è richiesto dal client Lync. La foto è un esempio di questa ottimizzazione. Un altro esempio è ContactEndpoints. Si prega di dare un'occhiata a Contact presence subscription changes section della pagina Migration doc per Lync 2013 nei documenti MSDN. In particolare è necessario creare e mantenere la propria ContactSubscription per i contatti necessari per tutti i ContactEndpoints.

Answer 2

ho incontrato un problema simile quando si cerca di scrivere un programma per ottenere lo status di tutti gli utenti in Lync SDK 2010. Ha scelto tutti gli utenti e leggere è stato (online/offline, ecc). Ma sta funzionando bene solo con quei contatti che erano nella lista dei contatti dei clienti. Non so perché, ma le soluzioni non sono state trovate. Poco dopo uso UCMA 4 (con l'endpoint dell'applicazione), sebbene l'elenco sia stato ricevuto da AD e sia in grado di ottenere lo stato corrente.

Forse ha senso utilizzare la ricerca per AD? Trova il numero di telefono per utente sorso? In tal caso, provare a utilizzare questo filtro per DirectorySearcher:

searcher.Filter = "(&(objectClass=user)(msRTCSIP-PrimaryUserAddress=*))"; //put sip instead of * 

P.S. che sdk stai usando?

Answer 3

Ho affrontato lo stesso problema. Si può provare a caricare ContactCard della persona prima di chiamare la funzione GetContactInformation esplicitamente

Microsoft.Lync.Controls. ContactCard objContactCard = nuovo Microsoft.Lync.Controls.ContactCard(); objContactCard.Source = objContact. GetContactInformation (ContactInformationType.Indirizzi email);

  ContactSubscription _contactSubscription = lyncObj.ContactManager.CreateSubscription(); 

       _contactSubscription.AddContact(foundContact); 

       _contactSubscription.Subscribe(ContactSubscriptionRefreshRate.High, _ContactInformationList); 

Tuttavia, è ancora potrebbe ottenere qualche ritardo nell'ottenere le informazioni (numeri di telefono). È possibile scegliere di utilizzare Thread.Sleep o si può semplicemente volere riprovare. Spero che questo aiuti.

Answer 4

Problematico si basa sulle informazioni di contatto anche per l'utente del client lync. Nella nostra soluzione stiamo facendo qualcosa del genere:

Contact user = LyncClient.GetClient().Self.Contact; 
string email = user.GetContactInformation(ContactInformationType.PrimaryEmailAddress) as string; 

Mi aspetto che il contatto utente corrente di Lync sia sempre compilato correttamente. E se non lo fosse, mi aspetterei che il codice generasse un'eccezione o almeno restituisse null o una stringa vuota. Invece restituisce a volte il sip-uri del contatto senza il prefisso "sip:". Stranamente questo non è sempre riproducibile: la maggior parte delle volte il codice sopra restituisce correttamente l'indirizzo email principale (secondo la directory attiva), a volte si comporta come sopra menzionato.