Comment mettre en œuvre la visio-conférence entre Lync et Polycom


Le Microsoft Technology Center (MTC dans notre jargon) est un lieu extraordinaire chez Microsoft pour toute personne férue de technologie. Certains diront que c'est notre showroom mais c'est surtout le lieu où l'on peut monter et montrer les plus belles démonstrations avec les technologies Microsoft ! C'est dans ce sens que j'ai travaillé récemment avec Polycom pour interconnecter Microsoft Lync avec les systèmes de conférence HDX 4000, HDX 8000 et le pont RMX2000.

Le but de cet article est de vous guider pas à pas dans la connexion de ces équipements avec Lync. Voici les grandes étapes :

  1. Configuration initiale et vérification des prérequis
  2. Interconnexion point à point entre Lync et HDX4000 / HDX8000
  3. Interconnexion avec le pont de conférence RMX 2000

Configuration initiale et vérification des prérequis

Les prérequis à la mise en œuvre d'une telle interconnexion est d'avoir les deux HDX en version 3.0 et d'utiliser Microsoft Lync 2010.

Les codecs HDX 4000 et 8000 ont la capacité de fonctionner selon deux modes :

  • Le mode H323 qui leur permet de communiquer avec des équipements utilisant ce protocole de communication
  • Le mode SIP qui leur permet de s'enregistrer sur un registrar SIP et en particulier Microsoft Lync

Pour que ces équipements puissent se connecter à Lync, il leur faut un compte dans Lync que vous pouvez créer avec le cmdlet suivant :

New-ADUser -SamAccountName "HDX4000FR1" -GivenName "HDX4000FR1" -DisplayName "HDX4000FR1" -name "HDX4000FR1" -AccountPassword (Read-Host -AsSecureString "AccountPassword") –Description "Account for HDX 4000" -UserPrincipalName "hdx4000fr1@immersion.fr" -EmailAddress "hdx4000fr1@immersion.fr" -Enabled $true -Path 'CN=Users,DC=immersion,DC=fr'

Note: il faut avoir installé le rôle "Active Directory Domain Services" et importer le module "activedirectory" depuis powershell pour pouvoir exécuter la commande.

Une fois que le compte a été créé dans Active Directory, il faut l'activer pour Lync. Après avoir importé le modue powsershell "Lync" on peut lancer la commande suivante :

Enable-CsUser -Identity "hdx4000fr1@immersion.Fr" -RegistrarPool cdu-lync-4.immersion.fr -SipAddressType EmailAddress

Dans notre cas, nous utilisons l'adresse email comme adresse SIP mais il est bien entendu accepté d'utiliser un autre identifiant SIP.

Les comptes sont donc maintenant créés et disponibles dans AD pour pouvoir s'y connecter. Il suffit de configurer le HDX pour s'enregistrer dans l'infrastructure Lync. Pour le faire, le plus simple est d'utiliser l'interface web du client HDX et une fois connecté de renseigner les informations comme indiqué ci-dessous :

Notez les points suivants :

  1. Le protocole de transport est TLS : c'est-à-dire que la signalisation entre le client HDX et l'infrastructure Lync se fait via un canal sécurisé.
  2. Le nom de l'utilisateur est l'identifiant SIP du compte que nous venons de créer. Dans le cas du HDX 4000 qui sera probablement affecté à un utilisateur, il est possible à cet endroit d'utiliser le compte de l'individu au lieu d'un compte générique.
  3. Le nom de l'utilisateur du domaine est utilisé pour l'authentification du client HDX
  4. Le mot de passe doit être renseigné une fois, ensuite, quand vous revenez sur cette page, la case sera non cochée mais le mot de passe reste valable.
  5. Le nom FQDN du registrar SIP qui, dans notre cas est le nom du pool Lync.
  6. Le nom FQDN du serveur proxy qui, dans une configuration simple, est le nom du pool Lync.
  7. La case "Microsoft Office Communications Server", doit être cochée même dans le cas d'une infrastructure Lync.

Après avoir saisi ces paramètres au niveau de l'interface web de configuration du client HDX, on peut vérifier s'il s'enregistre bien au niveau de Lync. Il faut aller dans l'onglet Diagnostics et vérifier que tous les indicateurs sont au vert comme ci-dessous :

Si un paramètre a été mal renseigné, ou si le client HDX n'arrive pas à se connecter à Lync, vous aurez un état similaire à celui-ci-dessous :

Vous pouvez alors cliquer sur le lien "Serveur registraire SIP" pour obtenir plus d'informations.

Le client HDX 4000 est maintenant prêt pour communiquer avec les clients Lync.

Interconnexion point à point entre Lync et HDX

Depuis le client Lync, modulo le temps nécessaire à ce que les comptes HDX fraichement créés apparaissent dans l'annuaire, il est possible de voir les terminaux connecté et remonter leur niveau de disponibilité.

Les terminaux HDX remontent leur niveau de disponibilité dans l'infrastructure Lync comme le ferait tout client Lync agrégeant ainsi les niveaux de disponibilité des différents points de présence connectés sur ce compte.

Depuis le client Lync, il est possible d'appeler un terminal HDX pour établir une communication point à point et vice-versa. Une fois que la communication est établie, l'expérience sur le client Lync est celle-ci-dessous, c'est-à-dire très similaire à celle d'une communication point à point entre deux clients Lync :

Une fois la communication établie, il est possible d'avoir plus de détails sur les protocoles utilisés par le Codec du HDX :

Notez que les flux de communication sont les suivants :

  • SIP sur TLS pour la signalisation
  • G.722 pour l'audio
  • H263 / CIF pour la vidéo

Il reste à faire l'interconnexion avec le pont de conférence de Polycom.

Interconnexion avec le pont de conférence RMX 2000

Les systèmes de visio-conférence comme ceux de Polycom sont souvent destinés à établir des communications entre plusieurs terminaux. Dans ce cas, on doit utiliser un pont de conférence qui sert de centralisateur des différents terminaux. Ce scénario s'avère plus complexe qu'une communication point à point surtout dans le cas de l'interconnexion de systèmes différents car il faut adresser, entre autre, les points suivants :

  • Supportabilité du protocole de communications utilisé pour la conférence
  • Identification du pont de conférence RMX et autorisation en tant que serveur
  • Gestion des flux audio et vidéo

Pour l'établissement et le contrôle des conférences, Lync utilise le protocole CCCP (Centralize Conference Control Protocol) dont la définition est disponible à des deux adresses: http://msdn.microsoft.com/en-us/library/cc431498.aspx ou encore http://tools.ietf.org/html/draft-levin-xcon-cccp-04. Dans notre cas, les équipements Polycom ne supportent pas encore ce protocole. La seule solution pour réussir à mettre en conférence des terminaux Lync et Polycom est donc d'utiliser le pont de conférence RMX 2000. Regardons justement comment réaliser cette interconnexion.

Etape 1 : Configurer le pont RMX 2000 pour communiquer avec Lync

Afin de simplifier le contenu de cet article, nous allons considérer que la configuration IP, DNS et H323 du pont de conférence RMX 2000 est déjà faite pour nous focaliser sur la configuration SIP du pont de conférence.

La configuration se fait dans "IP Network Services"

Considérant que les éléments IP, DNS et H323 sont renseignés et déjà configurés, il faut aller dans l'onglet "SIP Server"

A cet emplacement, on va pouvoir procéder à la définition du serveur SIP (Lync).

Il faut commencer par assigner au pont RMX un certificat … sauf si vous souhaitez laisser circuler le trafic en clair sur votre réseau. Le bouton "Create Certificate" permet de générer le fichier de demande de certificat qu'il faudra transmettre à l'autorité de certification qui est utilisé sur votre réseau interne.

Lorsque vous aurez obtenu le certificat au format texte (extension .pf7 en général) vous le chargerez au niveau du pont RMX en copiant le texte reçu puis en l'émettant avec le bouton "Send Certificate" (sur la page principale de configuration ainsi que dans la fenêtre de pop-up qui s'ouvre):

Une fois le certificat chargé au niveau du pont, il faut configurer les paramètres suivants :

  • Transport Type : TLS
  • Certificate Method : CSR ou PEM/PFX en fonction du format de certificat que votre autorité de certification utilise.
  • SIP Server : Adresse IP de votre front-end et nom de domaine pour le nom du domaine SIP que vous utilisez. Le port est le port utilisé pour la communication en SIP. Par défaut en 5061 mais que vous avez peut-être configuré sur un port différent.
  • Outbound Proxy Server : Informations concernant votre serveur Lync. En général on utilise le même serveur pour le "SIP Server" et le "Outbound Proxy Server" sauf si votre architecture nécessite des serveurs différents pour ces deux activités.

Le RMX est maintenant configuré pour communiquer avec l'infrastructure Lync, mais Lync n'est pas configuré pour communiquer avec le RMX, c'est ce que nous allons faire dans l'étape 2.

Etape 2 : Configurer Lync pour communiquer avec le RMX

Cette étape va permettre à l'infrastructure Lync de connaitre le pont RMX et de savoir router les appels vers lui. C'est aussi cette étape qui permettra d'éviter que Lync ne considère le flux provenant du pont RMX comme indésirable et le bloque.

Le principe général est donc :

  1. Créez une route statique depuis Lync vers le pont RMX
  2. Enregistrez le pont RMX comme serveur d'application

Uniquement si vous migrez depuis OCS :

Si vous migrez votre infrastructure depuis OCS 2007 ou 2007 R2 et que vous aviez réalisé l'intégration de OCS avec le pont RMX il faut supprimer l'entrée créée lors de l'installation avec le script vbs suivant :

cscript OCSTrustEntry.vbs /action:remove /type:trustedservice /cn:{le_guid_de_l'entrée_du_pont_rmx}

Voici le résultat sur mon infrastructure de test :

Ensuite, il faut relancer un import de la topologie OCS R2 dans Lync avec le Topology Builder pour importer la suppression de l'équipement RMX de la topologie. Ne pas oublier de faire une publication de la topologie 🙂

Vérifiez que le RMX n'apparait plus dans la liste des éléments de la topologie dans le Lync Server 2010 Control Panel avant de procéder aux étapes suivantes. Si l'entrée apparait toujours, les mécanismes de validation de la topologie de Lync empêcheront de créer une nouvelle entrée ayant le même nom.

Dans tous les cas :

Pour créer la route statique, il faut passer par la Lync Management Shell et saisir la commande suivante :

$route = New-CsStaticRoute -TLSRoute -destination "rmx2000fr.immersion.fr" -port 5061 -matchuri "visio.immersion.fr" -usedefaultcertificate $true

Dans cette ligne de commande il faut remplacer les noms FQDN par ceux de votre infrastructure. Nous utilisons TLS pour chiffrer les communications entre le pool Lync et le pont, c'est ce qui est définit avec le paramètre "-TLSRoute". La destination est le nom FQDN du pont de conférence RMX et le "matchuri" indique sur quelle correspondante d'URI cette route doit s'appliquer. Dans l'exemple ci-dessus, l'appel à 1001@visio.immersion.fr sera routé ver le RMX.

Il faut ensuite appliquer cette route avec la ligne de commande suivante :

Set-CsStaticRoutingConfiguration -identity global -route @{Add=$route}

Vous pouvez vérifier que la configuration est bien prise en compte par le cmdlet : Get-CsStaticRoutingConfiguration

Nous avons configuré Lync pour émettre des appels vers le pont de conférence mais si celui-ci essaye de faire quelque chose, il se recevra refuser les accès. Il faut donc ajouter le pont come hôte autorisé et cela passe par la déclaration du pont comme hôte de confiance ou Trusted Host. Mais dans Lync un Trusted Host doit faire partie d'un Trusted Application Pool qu'il faut donc créer. Ensuite, il faut créer une Trusted Application dans ce pool applicatif qui, dans notre cas, sera une représentation dans Lync du pont de conférence du RMX. Et comme une image vaut mille mots, voici ce que nous allons réaliser dans les prochaines cmdlets :

Voici les cmdlet à saisir pour arriver à notre but.

  1. Création du CsTrustedApplicationPool et affectation à un CsTrustedApplicationComputer (créé s'il n'existe pas déjà):

New-CsTrustedApplicationPool -Identity visio.immersion.fr -Registrar Registrar:cdu-lync-4.immersion.fr -site 1 -ComputerFqdn rmx2000fr.immersion.fr -ThrottleAsServer $true -TreatAsAuthenticated $true

La chaine utilisé pour le paramètre "-Identity" n'a pas besoin de correspondre à la route créée à l'étape précédente. C'est juste plus simple à gérer.

 

  1. Création de la CsTrustedApplication que nous allons associer au CsTrustedApplicationPool créé lors de l'étape 1 avec le cmdlet suivant :

New-CsTrustedApplication -ApplicationID VideoRouting -TrustedApplicationPoolFqdn visio.immersion.fr -Port 5061

Le ApplicationID peut correspondre à n'importe quelle valeur par contre le TrustedApplicationPoolFqdn doit correspondre au nom du CsTrustedApplicationPool créé précédemment; c'est ce paramètre qui réalise l'association entre le pool d'application et l'application en elle-même.

Le port indiqué est le celui sur lequel l'application fonctionne et dans notre cas, comme nous fonctionnons en TLS, il s'agit du 5061.

  1. Après avoir effectué ces opérations, il faut activer la topologie ainsi mise à jour avec le cmdlet suivant :

Enable-CsTopology

  1. Le denier point est lié à la version actuelle du pont RMX 2000 qui ne supporte pas le SRTP. Il faut donc modifier le niveau de chiffrement demandé par Lync pour le flux media.

    Set-CsMediaConfiguration –encryptionLevel supportencryption

    Vous pouvez vérifier que la configuration a bien été prise en compte avec un Get-CsMediaConfiguration :

Il reste à tester le bon fonctionnement de l'interconnexion en appelant l'une des salles de conférence configurée au niveau du RMX. Dans notre cas, nous avons créé une salle de conférence utilisant l'identifiant 1001, elle est donc joignable depuis Lync par l'adresse sip:1001@visio.immersion.fr.

A la connexion on a l'expérience suivante :

Qui se transforme avec le nombre de participants.

La disposition des vignettes est configurable et peut être changé en cours de conférence si l'administrateur du pont de conférence l'a autorisé lors de la création de la salle virtuelle de conférence hébergée sur le pont de conférence.

Les flux de signalisation et media utilisés entre les équipements sont les suivants :

Sans aucun doute la qualité vidéo pour l'interopérabilité entre les deux environnements va s'améliorer au fil de temps.

Conclusion

L'interconnexion entre des équipements Polycom et Microsoft Lync passe par plusieurs étapes :

  • Création de comptes dans Lync pour permettre aux équipements compatibles Lync (HDX 4000 et HDX 8000) de s'enregistrer dans Lync et de publier leur présence.
  • Validation du flux de communication point à point.
  • Création d'une route vers le pont de conférence RMX 2000 et association du pont de conférence à un pool d'application.

Au final, la solution mise en place nous a permis d'interconnecter Microsoft Lync avec les équipements de Polycom (en utilisant H.323 et SIP) et de reposer sur le transcoding des formats vidéo fournit par le pont de conférence RMX 2000.

L'avantage d'avoir le pont de conférence RMX 2000 est de pouvoir certes connecter avec Lync les équipements HDX mais aussi d'autres équipements qui ne supportent que le protocole H.323, le H320 (ISDN) et aussi le PSTN et de pouvoir établir des visio-conférences entre tous ces périphériques.

 


Comments (4)

  1. Damien Caro says:

    Bonjour Pascal,

    les versions que nous utilisons au MTC sont :

    – BetaRC 3.0.0.5794 pour les HDX

    – v6.0.0.105 pour le RMX

    A noter que seuls les HDX ont été mis à jour. Nous allons procéder à une autre mise à jour d'ici quelque temps sur le RMX pour améliorer encore l'expérience de visio-conférence intégrée.

    Merci,

    Damien

  2. Damien Caro says:

    Bonjour Michel,

    il n'est pas nécessaire d'assigner un certificat sur le HDX pour le fonctionnement en TLS. Je ne me souvient pas que l'on ait assigné la racine de certificat quelque-part comme nous avons du le faire pour le RMX. Je pense donc qu'il ne fait pas de vérification sur la CA émettrice.

    Merci,

    Damien

  3. Pascal CREUSOT [MVP Lync] says:

    Merci Dmien pour ce superbe post. Peux-tu nous indiquer la version minimum (ou Ă  dĂ©faut la version utilisĂ©e au MTC)  de Firmware des Ă©quipements HDX. Sinon, on posera la question Ă  des contacts Polycom.

    Pascal.

  4. Michel D says:

    Hello Damien,

    Le HDX communique avec le serveur Lync en TLS. Est ce qu'il faut aussi lui créer et assigner un certificat? Ou est ce que par défaut, le HDX trust tous les certificats et ne fait aucune vérification? Je vois qu'il faut un certificat pour le RMX mais pas pour le HDX.

    Très intéressant article!

    Merci.

Skip to main content