J'ai constaté lors de plusieurs projets différents Lync serveur 2013 avec une intégration non IP avec un ou des PBX existants, le problème suivant:
Lorsqu'un utilisateur Lync reçoit un appel venant d'un téléphone du PBX en intégration non IP, le client Lync mobile notifie l'usager de l'appel entrant, mais avec le mauvais nom d'appelant. L'ensemble des autres clients Lync présente le nom correctement sauf lui. Étrange, le client Lync systématiquement montre le nom du premier contact de la liste de l'utilisateur, nous avons fait des tests avec pleins usagers différents, même constat.
Les PBX sont des Mitel, Avaya et Nortel, les passerelles des Audiocodes ou Dialogic.
Évidemment, on pense tout de suite à un probleme de RNL, mais c'est bien plus que cela.
A part cas exceptionnel, je configure toujours mes environnements voix en me basant sur les préconisations Microsoft concernant le format E.164.
J'ai ouvert un case il y a maintenant 6 mois de cela, après 4 mois d'explication et d'envoi divers de logs, Microsoft a confirmé que cela est un bug, la raison est la suivant
Lorsque le client Lync mobile reçoit l'appel, le symptôme est associé à une routine qui détermine le numéro de téléphone à partir du telURI. Cette routine emploie une expression régulière simple, qui ignore complètement l’extension présente dans le numéro en format E164. Par la suite, la recherche locale effectuée identifiera de manière consistante le même contact.
INFO APPLICATION CUcmpParticipant.cpp/2048:CUcmpParticipant::startRNLQuery()
INFO APPLICATION CUcmpParticipant.cpp/572:tel uri rnl search started
INFO APPLICATION CUcmpConversation.cpp/6986:Add a new participant to active participant collection. sipUri: [tel:+1514XXXXXXX;ext=1111] remoteHref: [/ucwa/v1/applications/...] displayName: [+1 (514) XXX-XXXX] personKey: [/ucwa/v1/applications/...]
INFO APPLICATION CPersonsAndGroupsSearchQuery.cpp/1159:Local search started. queryType=1; lookupKeyword=; lookupUri=; lookupEmail=; lookupPhone=+1514XXXXXXX
INFO APPLICATION CUcmpParticipant.cpp/2187:Displayname from local rnl search is Admin Lync
INFO APPLICATION CUcmpConversation.cpp/2744:tel uri rnl search completed
Je viens d'être notifié aujourd'hui que le bug vient d’être accepté par l'équipe de développement et sera corrigé dans une version ultérieure (reste à savoir laquelle!).
