Voici une problématique de fonctionnement du client Lync Mobile 2013 que vous pouvez rencontrez si vous utilisez un Reverse Proxy de type Apache.

Toutes les URLs publiées via le Reverse Proxy semblaient fonctionner et les tests d’accès sur celles-ci étaient concluants mais le client Lync Mobile 2013 ne fonctionnait cependant pas correctement.

Le client Lync 2013 Mobile n’arrivait à se connecter qu’une fois sur deux et affichait « Désolé… Nous ne parvenons pas à nous connecter au serveur. Si vous utilisez le Wi-Fi, ouvrez votre navigateur pour voir si vous avez une connexion. Autrement, désactivez toute connexion à un point d’accès ou à un autre appareil. Si le problème persiste, contactez votre fournisseur réseau »

14_pb_ReverseProxy_MobileLync

Les autres symptômes une fois connecté étaient l’audio et la vidéo ne fonctionnant pas, le client se déconnectant régulièrement avec le même message d’erreur.

Il s’avère que le problème apparait avec un Reverse Proxy de type Apache. Le blog de Laurent Teruin m’a aiguillé et la problématique s’est avérée exactement la même.

Voici les logs d’un client mobile se connectant à l’infrastructure via le Reverse proxy

HttpHeader:Cache-Control no-cache
HttpHeader:Connection Keep-Alive
HttpHeader:Content-Length 0
HttpHeader:Content-Type text/plain
HttpHeader:Date Mon, 17 Feb 2014 22:50:52 GMT
HttpHeader:Keep-Alive timeout=15, max=300
HttpHeader:Server Microsoft-IIS/7.5
HttpHeader:StatusCode 204
HttpHeader:X-AspNet-Version 4.0.30319
HttpHeader:X-Ms-Namespace internal
HttpHeader:X-MS-Server-Fqdn FQDN
HttpHeader:X-Powered-By ASP.NET

…………

</ReceivedResponse>
2014-02-17 23:50:53.589 Lync[22700:6367000] ERROR TRANSPORT TransportUtilityFunctions.cpp/1767:Accept-types (application/vnd.microsoft.com.ucwa+xml) not found in Content-Type response from server (text/plain). Not decoding.

Comme on peut le voir, le Content-Type attendu par l’application mobile Lync ne correspond pas et a été remplacé automatiquement par le Reverse Proxy.
Apache change automatiquement le Content-Type à celui par défaut dans la configuration quand celui-ci n’est pas connu.
Si vous retrouvez donc ce message d’erreur, rapprochez vous de l’intégrateur/exploitant du Reverse Proxy.

Dans le cas d’Apache, il faut le configurer pour qu’il ne change pas le Content-Type quand celui-ci est inconnu (cf blog de Laurent Teruin).
Si la solution Reverse Proxy est de type Beeware (ce qui était le cas dans ma problématique – version 5), ce problème est connu chez l’éditeur et il faut se rapprocher d’eux pour mettre en place la correction.

Share