Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Principe de connexion des clients Lync via des réseaux Natés (Partie 1)

Posted by Teruin laurent le février 8, 2013


Les fonctions de Nat sont un véritable problème dans l’environnement VOIP car ces dernières ne prennent pas en compte les spécificités du protocole SIP. Le problème est alors d’établir une connexion entre deux utilisateurs qui a travers une connexion nattée, tenteraient d’établir une connexion Audio-vidéo .Le principe est simple. Si l’utilisateur 1 possédant l’adresse Ip 192.168.1.1 est basé chez lui et qu’il utilise une connexion nattée en 61.1.1.1 à travers sa box internet il pourra sans problème se connecter sur le serveur Edge Lync. Même chose pour l’utilisateur 2 qui lui utilise l’adresse ip privée 192.168.1.2 d’entreprise natté également à travers une adresse IP 62.2.2.2 qui lui sera connecté sur le serveur Frontal Lync 2010/2013

Bien qu’il soit sur le même réseau IP domestique (192.168.1.x) le flux média point à point ne pourra pas s’établir pour des raisons évidentes puisque l’un est à la maison et l’autre au travail. Cependant comme vous pourrez le remarquer sur la figure suivante la signalisation SIP via TCP elle se fera correctement mais pas de flux Audio ou vidéo qui eux utilisent la couche de transport UDP.


Figure 1 :Media and nat

Dans le flux de signalisation ci-dessus, chaque partie indique son adresse IP dite Candidate. Une Adresse Candidate est une combinaison d’une adresse IP et d’un port de connexion. Pour l’utilisateur à la maison c’est la valeur a et pour l’utilisateur au sein de sa société c’est W. Cependant comme celles-ci sont cachées derrière une adresse Ip natté elles ne seront pas joignables directement par le flux média. La solution consiste donc à utiliser des protocoles qui vont aider à la publication de véritables adresses candidate des clients ou dans certain cas d’un serveur de relai de média. Dans notre cas de figure c’est effectivement le serveur Edge qui va assurer ce rôle Le serveur Edge comme son nom l’indique est un serveur de périphérie qui est joignable sur Internet via les enregistrements SRV des serveurs DNS. De ce fait, il va assurer ce que l’on appelle la fonction de proxy SIP pour les connexions provenant de l’extérieur. La figure ci-dessous illustre une connexion Sip vers un serveur Edge.


Figure 2 : Edge is a Sip Proxy serveur

L’utilisation des fonctions STUN (Simple Traversal Of UDP throught NAT) va permettre de transmettre les adresses IP Natée (b) and (e) et TURN de relayer les paquets média (c) (d) (x) (y) comme le montre la figure suivante.A propos du protocole STUN on notera que ce protocole est également utilisé en dehors du Protocole UDP et qu’on le trouve nommé de ce fait également comme Simple Traversal Utilities for Nat.


Figure 3 : Adresse Candidate

Quant au protocole ICE (Interactive Connectivity Establishement) ce dernier va déterminer le chemin optimal pour le flux média. Dans le schéma précédent, le client de la société va initier un flux de signalisation (en vert sur le diagramme) en SIP sur TCP et présenter une liste d’adresse candidate sur lesquelles il est potentiellement joignable. L’utilisateur de la maison va faire pareil. C’est ainsi que l’utilisateur Maison présentera les adresses A (comportant l’adresse IP réelle de son pc et son port de connexion), l’adresse B (Comportant l’adresse natée de sa box et son port de connexion) pour le flux média et l’adresse E pour la signalisation. D’une façon générale, nous allons trouver dans l’environnement Lync des clients dit client ICE dès lors qu’ils vont activer leurs fonctions audio – vidéo. Les clients Web de Lync 2010 à ce propose ne sont pas tout à fait des clients ICE sauf quand ces derniers se mettent à partager leurs bureaux (Desktop Sharing).

À propos de Ice

 

Pour établir une session média 5 phases seront nécessaires

  1. Provisionnement Turn et des informations de connexion (MRAS)
  2. Découverte des adresses
  3. Échange des adresses (SIP Invite /200 OK)
  4. Vérification la connectivité
  5. Promotion de la candidate

La figure suivante précise les différentes étapes de connexion lorsqu’un utilisateur distant se connecte vers un serveur Edge depuis le réseau Internet.


Figure 4 : Principe de connexion a travers un serveur Edge

Etape 1 et 2 : La première étape est représentée par la fonction sip register qui va se servir des enregistrements SRV pour localiser le serveur Access Edge. Le serveur Edge passera la requête au serveur frontal qui répondra par un message 200 OK et qui précisera les diverses stratégies, règle de normalisation et le paramétrage pour le client en question. Dans le message de retour du serveur Frontal via le serveur Edge, il est également préciser l’adresse du service d’authentification du serveur de relai média (MrasUrip) comme le précise la figure ci-dessus.

La figure suivante illustre le dialogue et l’annonce des fameuses « candidate »


Figure 5 : Adresse Candidate dans Sip invite

Etape 3 : L’étape suivante est l’envoi d’un paquet SIP précisant au serveur Lync frontal la localisation du client en question. Dans notre cas, le client est situé sur Internet et va donc avoir la nécessité de se connecter sur le serveur Audio-Vidéo pour établir un flux média.

Etape 4 : Le serveur Audio/Vidéo ne faisant pas partie du domaine Active Directory et n’ayant par conséquent pas accès à l’annuaire de l’entreprise, c’est alors le serveur Lync qui va demander au serveur Edge audio vidéo un compte et un mot de passe pour que notre utilisateur puisse l’utiliser afin de pouvoir se connecter. C’est l’échange que vous voyez en bas à gauche (Service / 200 OK)

Ci-dessous un contenu de l’échange capturé par snooper


Etape 5 : Une fois ce compte et ce mot de passe obtenu le serveur Frontal via le serveur Edge va établir une communication vers notre client sur Internet pour lui communiquer ses informations de connexion qui lui permettront de se connecter durant une période de 8 heures. (480 Minutes). Pour cela, il communiquera a notre utilisateur, le compte et le mot de passe mais également le port de connexion tcp et udp ainsi que le nom du serveur en question. L’intérêt de cette solution est quelle est rapide car à chaque fois que l’utilisateur externe va effectuer un appel il utilisera ce compte et ce mot de passe et s’adressera directement au serveur en question, et ce pour une durée de 8 heures.Pour ce qui est des conférences Anonymes on retrouve un peu se même comportement mais simplifié car l’utilisateur effectue une requête sip avec une connexion anonyme cette fois ci.

 


Figure 6 Principe de connexion avec une conférence


 

About these ads

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 224 autres abonnés

%d blogueurs aiment cette page :