Exchange your Mind

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

Archives d’Auteur

Lync 2013 : Disponible sur Windows Phone

Publié par Teruin laurent le mars 11, 2013


Bonjour ca y est la première mouture du client Lync Mobile 2013 est disponible sur le store dès aujourd’hui

À télécharger sur le store et à tester sur un environnement Lync 2013 Bien sur !

Cordialement

Pour en savoir plus : http://www.windowsphone.com/fr-fr/store/app/lync-2013/d85d8a57-0f61-4ff3-a0f4-444e131d8491

 

Laurent TERUIN

Publié dans Lync 2013, Lync Client | 1 commentaire »

Lync 2013 : Désactivation de la Vidéo

Publié par Teruin laurent le mars 8, 2013


Bonjour

Vous êtes nombreux a souvent demander comment l’on peut faire en sorte d’interdire l’usage des flux Vidéo dans Lync. Ceci bien souvent en raison des bandes passantes insuffisantes sur les réseaux étendus Alors voici quelques éléments de réponse :

Pour les conférences
Pour les conférences il suffit de modifier la stratégie de conférence ou d’en créer une nouvelle. Passer par le powershell en tapant la commande suivante :

Set-CsConferencingPolicy -Identity "Tag:<PolicyName>" -AllowIPAudio $false -AllowIPVideo $false

  • Le paramètre –AllowIPVideo
    Indique si la vidéo informatique est autorisée dans la réunion. La valeur par défaut est True. Ce paramètre s’applique à l’utilisateur qui organise la conférence : s’il est défini sur False, aucune conférence créée par un utilisateur affecté par cette stratégie n’autorise les données IP vidéo. L’utilisateur peut toutefois prendre part à d’autres conférences acceptant les données IP vidéo.
  • Le paramètre -AllowIPAudio Indique si l’audio informatique est autorisée dans la réunion. La valeur par défaut est True. Ce paramètre s’applique à l’utilisateur qui organise la conférence : s’il est défini sur False, aucune conférence créée par un utilisateur affecté par cette stratégie n’autorise les données IP audio. L’utilisateur peut toutefois prendre part à d’autres conférences acceptant les données IP audio

Pour que l’utilisateur prenne en compte cette stratégie il faudra qu’il se déconnecte et se reconnecte

Pour les utilisateurs

Les actions ci-dessous ne vont désactiver que les fonctions Vidéo pour les conférences. Si vous voulez désactiver intégralement les fonctions Vidéo pour un utilisateur alors il faut utiliser la commande suivante :

Set-CsUser -Identity <username or sipaddresss> -AudioVideoDisabled $true

Le paramètre AUdioVideoDisabled Indique si l’utilisateur est autorisé à passer des appels audio/vidéo (A/V) via Lync. Si la valeur est True, l’utilisateur n’aura le choix que d’envoyer ou de recevoir des messages instantanés. Vous ne pouvez pas désactiver les communications A/V si un utilisateur est activé pour le contrôle d’appel distant, Enterprise Voice et/ou le routage Softphone d’autocommutateur privé IP-PBX

Bon test !
Laurent Teruin

Publié dans Lync 2013 | Poster un commentaire »

Lync et Skype : Rendez-vous au mois de Juin au téléphone

Publié par Teruin laurent le mars 4, 2013


Le 19 février Tony Bates, (en photo ci-dessous) Président de la division Skype chez Microsoft


annonçait dans une session lors de la conférence Lync que la connectivité Skype portant sur les fonctions de messagerie instantanée mais aussi la voix serait disponible dès le mois de Juin de cette année.

Cette fonctionnalité sera disponible pour les environnements Lync on Premise et Lync Online. Cette nouvelle marque la première annonce entre les combinaisons possibles entre Lync orienté vers le monde professionnel et Skype plus orienté particulier. Au mois de juin prochain les utilisateurs de Lync auront donc la possibilité de discuter avec les personnes sur Skype et également de pouvoir y rechercher des contacts. Quant à la video, elle viendra plus tard.

Il faut avouer que Microsoft marque un point important vis à vis de la concurrence, car il offre la possibilité aux entreprises de facilement établir un lien direct avec le monde du consommateur final. Ces solutions vont également permettre à certain de pouvoir réduire leurs coût de communication vers leurs correspondants à l’étranger par une simple connexion vers l’environnement Skype. Si l’on y réfléchit bien c’est bien le monde du BtoC qui devrait en premier lieu en bénéficier car l’interconnexion Lync devrait permettre pour les entreprises qui souhaitent activer ses fonctions de rentrer directement en contact avec les « home user ». Je pense notamment aux agences d’intérim qui devraient être les premières intéressées, aux sites web interactifs de vente, aux sociétés de recrutement.

Ces annonces ne marquent pas vraiment une révolution technologique car cette fonction était déjà disponible avec Windows Live (La vidéo en plus ), mais en s’attaquant au monde Skype plus largement utilisé et donc les codecs ont largement fait leurs preuves, Microsoft dote Lync 2013 d’un nouvel atout qui dans certain contexte métier peut faire pencher la balance.

Ensuite reste à savoir ce que l’on entend par voix. S’agira-t-il d’un simple appel point à point, de possibilité de conférences audio à plusieurs mêlant des personnes Lync et Skype ? rendez-vous au mois de Juin !

Cordialement

Laurent TERUIN


 

Publié dans Lync 2013 | Poster un commentaire »

LYNC 2013: Lync Server 2013 Capacity Calculator/ Microsoft Lync Server 2013 Resource Kit Tools/ Microsoft Lync Server 2013, Planning Tool / CU1

Publié par Teruin laurent le février 28, 2013


Bonjour.

Quelques indispensables sont arrivés :

Cumulative Update #1

Product

Download

Lync Server 2013, February 2013 Cumulative updates

download

 
 

Microsoft Lync Server 2013 Resource Kit Tools

download

Lync Server 2013 Whiteboard Archiving Viewer

download

Lync Server 2013, Planning Tool

download

Lync 2013 SDK

download

 

Bonne lecture !

Publié dans Lync 2013 | Poster un commentaire »

Lync 2013 Conférence / San Diego

Publié par Teruin laurent le février 28, 2013


Bonjour pour ceux qui n’avaient pas la chance d’y être vous trouverez quelques sessions de la conférence Lync 2013

Cordialement

Laurent

http://www.lyncconf.com/

 

Publié dans Lync 2013 | Poster un commentaire »

Séminaire Web : Microsoft Exchange & répartition de charge

Publié par Teruin laurent le février 27, 2013


Bonjour

Nous animons avec Kemp, Exakis et Itpro.fr un séminaire sur la répartition de charge en environnement Exchange. Si vous êtes intéressé je vous invite à vous y inscrire ici

http://www.exakis.com/_layouts/exakis/formInscriptionWebCast.aspx

 

Cordialement
Laurent Teruin


Publié dans Non classé | Poster un commentaire »

Lync 2010 : SDP : Notions de base

Publié par Teruin laurent le février 10, 2013


Lorsque l’on initialise des téléconférences multimédia des appels en voix sur ip, que l’on utilise des flux vidéo, ou d’autre type de sessions, il est nécessaire d’utiliser une technique permettant d’acheminer les détails du flux média, les adresses, et d’autre description vers les participants.

SDP fourni une représentation standardisée indépendante du type de données transférée. SDP est un protocole qui va décrire simplement les sessions et ne possède pas de mécanisme de vérification liées au transport. SDP peut en effet tout à fait utiliser différentes couches de transport comme SAP (Session Announcement Protocole), Session Initiation Protocol (SIP), Real Time Streaming Protocol ou bien Hypertext Transport Protocol.

SDP a été conçu pour fournir un ensemble de description de session pouvant fonctionner dans un cadre relativement étendu de réseaux. . SDP est défini par la RFC 4566 dont une partie de cet article est tiré.

Conçu pour fonctionner dans le cadre de réseau hétérogène, son objectif principal est de convoyer des informations à propos des flux média dans le cadre de session multimédia, afin de permettre aux récipiendaires de participer à cette session. Il effectue en réalité deux actions bien précises qui sont les suivantes :

  • Fourni un moyen pour communiquer l’existence d’une session
  • Transporte les informations suffisantes pour permettre aux participants de rejoindre la session

Exemple d’usage de SDP

  • Lors de l’utilisation et de la création de session Multimédia les messages SIP qui vont décrire le type de session multimédia sont la plupart du temps écrits en SDP.
  • Le protocole Real Time Streaming Protocol (RSTP) qui contrôle l’acheminement de données temps réels est utilisé par des clients qui vont, via SDP, négocier des paramètres média.
  • Lors de l’utilisation de moyen de transmission comme la messagerie ou la navigation Web, la description d’un média de type application/Sdp permet d’associer via le navigateur l’application à exécuter.

Contenu d’une session SDP

La liste ci-dessous fourni les éléments nécessaires à la création d’une session SDP. Une session SDP comprend les éléments suivants :

  • Nom de la session et but
  • Informations de durée concernant la dite session.
  • Le type de média utilisé dans la session
  • Information requise pour recevoir ce flux média (Adresse, Ports, formats.)

Des informations complémentaires peuvent être adjointes à la session pour informations

  • Information de bande passante utilisée
  • Information concernant la personne responsable de la session

     

SDP décrit les informations média selon le format suivant :

  • Type du média : Vidéo, Audio, etc..
  • Information concernant le type de protocole de transport (RTP/UDP/IP/H.320 etc)
  • Format du média (H.261, MPEG etc..)

S’il s’agit d’une session multicast SDP fourni

  • Adresse du groupe Multicast relative aux média
  • Type de transport pour le média

     

S’il s’agit d’une session unicast SDP fourni

  • L’adresse distante relative au média
  • L’adresse du port distant relative au média

Dans le cas où la session est bornée dans le temps, le protocole SDP permet de véhiculer les informations suivantes :

  • Informations arbitraires relatives au démarrage et la clôture de la session
  • Informations de récurrence de la session dans le temps (tous les Lundi de 13 à 15h00)

La quasi-totalité des informations SDP sont décrites avec un type de média suivant : « application/sdp » au format ISO 10646

L’exemple suivant illustre une description de sessions SDP

Content-Type: application/sdp
Content-Length: 223
Message-Body: v=0
o=- 0 0 IN IP4 192.168.0.51
s=session
c=IN IP4 192.168.0.51
t=0 0
m=message 5060 sip null
a=accept-types:text/plain multipart/alternative image/gif text/rtf text/html application/ms-imdn+xml text/x-msmsgsinvite

Ou

  • V: va indiquer la version du protocole SDP. Généralement égale à zéro
  • 0: va indiquer l’adresse source du message ainsi que l’identification de la session. IN pour Internet format de l’adresse IP (4 ou 6) et l’adresse IP.
  • S : va indiquer le nom de la session
  • T : va indiquer l’information temporelle de début et de fin de session 0 0 signifiant que la session et supposée permanente
  • M : va indiquer la description du média. Il s’agit ici d’un message sip utilisant le port 5061.
  • A : va indiquer le type de format accepté dans la session

Ci-dessous un autre exemple de session SDP un peu plus orienté vidéo

v=0

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.example.com/seminars/sdp.pdf

e=j.doe@example.com (Jane Doe)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 99

a=rtpmap:99 h263-1998/90000

 

SDP fait naturellement partie des protocoles utilisés par l’environnement Lync dans la description de session. Description que vous retrouverez si vous examiner les journaux d’un client Lync 2010/ 2013.

Et bien sûr pour en savoir plus…. La rfc comme toujours.

Cordialement
Laurent Teruin

 

 

 

 

 

.

Publié dans Livres-2010, Lync 2013 | Poster un commentaire »

Lync 2010 : SIP : Notions de base

Publié par Teruin laurent le février 9, 2013


Ce petit article détaille quelques éléments de base concernant le protocole SIP. Nous détaillerons également les principes de base via des exemples tirés de l’environnement Lync 2010.Pour plus de détails sur le protocole Sip, je vous invite à vous reporter à la source soit la RFC 3261 (http://www.ietf.org/rfc/rfc3261.txt)

Définition du protocole SIP (RFC 3261)

Le protocole SIP est un protocole appartenant à la couche applicative qui permet d’établir, modifier, et terminer des sessions multimédia (Conférence) tels que des communications téléphonique à travers Internet. Il permet en autre chose d’inviter des participants au sein de sessions déjà établie comme des conférences multidiffusion (Multicast). SIP permet la création d’infrastructure serveur (Proxy Sip) autorisant les clients à effectuer des opérations d’enregistrement, d’invitation etc… SIp ne constitue pas à proprement parler un environnement vertical mais se présente plutôt comme un composant pouvant servir de support a d’autre protocoles émanant de l’IETF permettant de bâtir une architecture complète multimédia.

Dans l’environnement SIP, on ne parle pas de client mais de d’agent Utilisateur (UA). Cet Agent Utilisateur ou plus communément appelé UA est généralement un programme permettant de créer ou de recevoir des messages au format SIP entretenant par la une « conversation ». Un UA ou User Agent client (UAC) envoi des requêtes vers un serveur SIP nommé souvent UAS ou Registrar. Dans l’environnement Lync ceci sera assuré par un serveur Lync 2010 frontal. Ce dernier recevant les requêtes client qui va soit y répondre soit les transférer. Les actions de ses deux acteurs UAC et UAS entretienne donc une conversation SIP lors par exemple d’un ‘un appel utilisateur. Une fois l’appel terminé le dialogue est interrompu.

Pour établir une conversation ses deux acteurs utilisent des méthodes et des formats de réponses codées. Le tableau suivant liste quelques méthodes fréquemment utilisés. (liste non exaustive)

Méthode

Réponses possibles

Invite 

1xx – Provisional 

ACK 

2xx – Successful 

BYE 

3xx – Redirection 

Cancel 

4xx – Request Failure 

Options 

5xx – Server Failure 

Register 

6xx – Global Failures 

 

Les requêtes sip sont généralement initialisées depuis un UAC ou UAS. L’intérêt du protocole Sip est qu’il est très explicite, d’autre diront qu’il est parfois un peu trop verbeux. Malgré, parfois certaine implémentation propriétaire, le protocole SIP est en réalité une suite de RFC validée et qui sont implémentées dans l’environnement Lync. Ces RFC font souvent référence au verbe dans le dialogue SIP et montre l’évolution de ce protocole.

Le tableau ci-dessous en précise quelque une

Méthode

Description

RFC en question

INVITE 

. Indique que un client est invite à prendre part a un appel

RFC 3261  

ACK 

Valide que le client a reçu le requête 

RFC 3261  

BYE 

Termine un call Terminates a call and can be sent by either the UAS or the UAC. 

RFC 3261  

CANCEL 

Annule tous les requêtes en suspens 

RFC 3261  

OPTIONS 

Queries the capabilities of servers.

RFC 3261  

REGISTER 

Registers the address listed in the To header field with a SIP server.  

RFC 3261  

PRACK 

Provisional acknowledgement. 

RFC 3262  

SUBSCRIBE 

Subscribes for an Event of Notification from the UAC. 

RFC 3265  

NOTIFY 

Notify the subscriber of a new Event.

RFC 3265  

PUBLISH 

Publishes an event to the Server. 

RFC 3903  

INFO 

Sends mid-session information that does not modify the session state. 

RFC 2976  

REFER 

Asks recipient to issue SIP request (call transfer).  

RFC 3515  

MESSAGE 

Transports instant messages using SIP.

RFC 3428  

UPDATE 

Modifies the state of a session without changing the state of the dialog. 

RFC 3311  

 

Pour illustrer notre propos, Voici quelques échanges de message avec deux Méthodes différentes utilisée dans l’environnement Lync 2010. Note : Pour qu’une requête SIP soit valide ils faut à minima quelle contiennent les entêtes suivantes : To, From, CSeq, Call-ID, Max-Forwards, and Via;

Le champ :

  • To : précise la destination
  • From : l’expéditeur
  • Cseq : un numéro incrémenté à chaque requête
  • Call- ID : Contient un numéro d’identification unique de l’appel
  • Max-Forwards : le nombre de saut maximum pour atteindre la destination. A chaque saut cette valeur est décrémentée de 1
  • Via : Contient l’adresse ou la personnes est sensée être capable de recevoir l’appel : Exemple Via: SIP/2.0/TLS 192.168.1.1:51344;ms-received-port=51344;ms-received-cid=4F900

Enregistrement SIP / REGISTER

L’enregistrement Sip est la première étape avant l’établissement d’une connexion de messagerie instantanée. Comme par définition un client Sip est mobile, un UAC peut s’inscrire auprès de différents serveurs. Dans le cas de Lync soit l’utilisateur est à l’intérieur et il fera sa connexion vers le serveur frontal, soit il est connecté sur Internet et celle-ci se fera vers les serveurs edge. Dans l’exemple suivant DavidP tente de se connecter vers le serveur IP 192.168.1.100 et négocie une connexion en TLS

Severity: information
Text: TLS negotiation started
Local-IP: 192.168.1.100:5061
Peer-IP: 192.168.1.1:51344
Connection-ID: 0x4F900
Transport: TLS

Dans le même temps Davidp envoi une demande de registration vers le serveur Lync en question. Vous trouverez ci-dessous une extraction du dialogue Sip en question

LogType: connection
Direction: Incoming
Peer: 192.168.1.1:51344
Message-Type: request
Start-Line: REGISTER sip:unifiedit.com SIP/2.0
From: <sip:DavidP@unifiedit.com>;tag=97152a1f83;epid=f4bced5b3a
To: sip:DavidP@unifiedit.com
CSeq: 1 REGISTER
Call-ID: 1b7168b487f5445c97d3674dc0d4c2ac

Contact: <sip:192.168.1.1:51344;transport=tls;ms-opaque=f6005201e2>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:E0233F84-0D8B-5465-8381-252C60B5B65C>"
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)

Event: registration
Content-Length: 0
Message-Body: –

Dans ce type de dialogue et parce qu’il peut y en avoir plusieurs bien évidement, chaque dialogue est identifié par une chaine alphanumérique unique nommée TAG. Quant au client, il est identifié avec une autre chaque également numérique nommé epid. C’est ce que vous apercevez dans le dialogue ci-dessus.

Une fois que cette phase est terminée, le processus d’authentification peut commencer. Lync utilise pour cela trois méthodes d’authentification selon l’emplacement de l’utilisateur.

  • WWW-Authenticate: Kerberos
  • WWW-Authenticate: NTLM
  • WWW-Authenticate: TLS-DSK (Transport Layer Security – Derived Shared Key) / Par défaut.

Kerberos peut être utilisé en interne, NTLM & TLS-DSK en interne et en externe.

Comme la précédente demande était réalisée par le client sans préciser la méthode d’authentification, le serveur va répondre par un message lui précisant que la requête n’est pas autorisée et en présentant aux clients ses méthodes d’authentification. C’est ce que vous voyez dans le message suivant :

Direction: outgoing;source="local"
Peer: 192.168.1.1:51344
Message-Type: response
Start-Line: SIP/2.0 401 Unauthorized
From: <sip:davidp@unifiedit.com>;tag=97152a1f83;epid=f4bced5b3a
To: <sip:davidp@unifiedit.com>;tag=B69C844CB75A152A278AE2F0D9791097
CSeq: 1 REGISTER
Call-ID: 1b7168b487f5445c97d3674dc0d4c2ac

Date: Mon, 17 May 2010 14:09:40 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="LabPool.unifiedit.com", version=4
WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/Lab-Pool.unifiedit.com", version=4
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="Lab-Pool.unifiedit.com", version=4, sts-uri=https://int cspool.unifiedit.com:443/CertProv/CertProvisioningService.svc
Via: SIP/2.0/TLS 192.168.1.1:51344;ms-received-port=51344;ms-received-cid=4F900
Content-Length: 0
Message-Body: –

 

Le client va alors répondre avec le message suivant. On notera que le la valeur CSed est incrémentée au passage.

Direction: incoming
Peer: 192.168.1.1:51344
Message-Type: request
Start-Line: REGISTER sip:unifiedit.com SIP/2.0
From: <sip:davidp@unifiedit.com>;tag=97152a1f83;epid=f4bced5b3a
To: sip:davidp@unifiedit.com
CSeq: 2 REGISTER
Call-ID: 1b7168b487f5445c97d3674dc0d4c2ac

Contact: <sip:192.168.1.1:51344;transport=tls;ms-opaque=f6005201e2>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER,
BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:E0233F84-0D8B-5465-8381-252C60B5B65C>"
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)

Event: registration
ms-subnet: 192.168.0.0
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", targetname="sip/Lab-Pool.unifiedit.com", version=4, gssapi-data="…", crand="3f00eea3", cnum="1",
response="040400ffffffffff0000000000000000858957d8cf09fd1a4754d919"
Content-Length: 0
Message-Body: –

 

  • Proxy Authorization porte la signature du message sip et un jeton unique pour l’association de sécurité (SA)
  • Realm : identifie quelle information d’indentification est utilisée pour signer le message
  • Version : Précise la version du protocole utilisée.
  • Crand : valeur aléatoire utilisé pour renforcer le cryptage)
  • Cnum : Identifie une séquence de nombre et permet de pister quelles données ont été transmise. Cette valeur est augmentée à chaque nouvel échange avec le serveur.

Une fois le processus d’authentification réalisé, le client va se voir assigné un identifiant unique nommé Globally Routable User Agent URI (GRUU) et qui va formellement identifier le point de connexion client. La valeur Epid est utilisée pour construire la valeur GRUU mais ne sera plus utilisée pour identifier formellement le client.

SOUSCRIPTION (SUBSCRIBE)

Une fois que la connexion aux services est réalisée, DavidP va s’abonner à une liste de contact qu’il aura au préalable choisi.

C’est le dialogue que l’on voit dans l’exemple suivant :

Direction: incoming
Peer: 192.168.1.1:52848
Message-Type: request
Start-Line: SUBSCRIBE sip:davidp@unifiedit.com SIP/2.0
From: <sip:davidp@unifiedit.com>;tag=47d7d0882a;epid=f4bced5b3a
To: sip:davidp@unifiedit.com
CSeq: 1 SUBSCRIBE
Call-ID: e6befddced82439298f37b91333d7d54

Contact: sip:davidp@unifiedit.com;opaque=user:epid:hD8j4IsNZVSDgSUsYLW2XAAA;gruu
User-Agent: UCCAPI/4.0.7337.0 OC/4.0.7337.0 (Microsoft Lync 2010)
Event: vnd-microsoft-roaming-contacts
Accept: application/vnd-microsoft-roaming-contacts+xml

 

L’entête vnd-microsoft-roaming-contacts va permettre d’identifier qu’il s’agit d’une liste de contact.
L’entête application/vnd-Microsoft-Roaming-contacts+Xml précise le fichier attendu pour récupérer les données de contact que le serveur va renvoyer.

SIP comporte bien d’autre fonction beaucoup plus élaborée et si vous êtes intéressé rien ne vaut la lecture de la RFC.

Cordialement
Laurent Teruin

Publié dans Lync 2010, Lync 2013 | Poster un commentaire »

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

Publié par 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


 

Publié dans Lync 2010, Lync 2013 | Poster un commentaire »

Exchange 2010 / Outlook 2010: Unable to download Address Book: 0×80190194 Through F5 Vip

Publié par Teruin laurent le janvier 25, 2013


Hello

We have experimented an issue with a F5 VIP and Outlook Address Book Download function. Outlook are not able on https to download the Address Book (Error : 0×80190194)

After searching and testing during one day we found the solution who consist to disable cache and compression (in Red in the script)

 

Best regards

Laurent Teruin

 

Exchange version :14.2 Build 247.5

Outlook Version : (version Outlook 14.0.6023.1000 32 Bits)

F5 Version 11.2.0 (build 2557.0)

 

The current script for the F5 is the following

 

## iRule to select pool and persistence method when all Exchange Client

## Access HTTP-based services are accessed through the same BIG-IP virtual

## server. This iRule will use an HTTP header inserted by a BIG-IP Edge

## Gateway for persistence (if that header is present); otherwise it will

## set persistence according to traditional methods.

 

## CHANGE ALL POOL NAMES TO MATCH THOSE IN YOUR ENVIRONMENT.

when HTTP_REQUEST {

## Offline Address Book and Autodiscover do not require persistence.

switch -glob — [string tolower [HTTP::path]] {

"/microsoft-server-activesync" {

## ActiveSync.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} elseif { [HTTP::header exists "Authorization"] } {

persist uie [HTTP::header "Authorization"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-Serveurs

COMPRESS::disable

CACHE::disable

return

}

"/owa*" {

## Outlook Web Access

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist cookie insert

}

pool Pool_EXC_Pub_CAS-Array-ServeursOWA

return

}

"/ecp*" {

## Exchange Control Panel.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist cookie insert

}

pool Pool_EXC_Pub_CAS-Array-ServeursOWA

return

}

"/ews*" {

## Exchange Web Services.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-ServeursOA

COMPRESS::disable

CACHE::disable

return

}

"/oab*" {

## Offline Address Book.

pool Pool_EXC_Pub_CAS-Array-ServeursOA


COMPRESS::disable

CACHE::disable

return

}

 

"/rpc/rpcproxy.dll" {

## Outlook Anywhere.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} elseif { [string tolower [HTTP::header "Authorization"]] starts_with "basic" } {

persist uie [HTTP::header "Authorization"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-ServeursOA

COMPRESS::disable

CACHE::disable

return

}

 

"/autodiscover*" {

## Autodiscover.

pool Pool_EXC_Pub_CAS-Array-ServeursAD

return

}

 

default {

## This final section takes all traffic that has not otherwise

## been accounted for and sends it to the pool for Outlook Web App

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-ServeursOWA

}

}

}

 

when HTTP_RESPONSE {

if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} {

ONECONNECT::reuse disable

ONECONNECT::detach disable

## this command disables NTLM conn pool for connections where OneConnect has been disabled

NTLM::disable

}

## this command rechunks encoded responses

if {[HTTP::header exists "Transfer-Encoding"]} {

HTTP::payload rechunk

}

}

 

F5 Version 11.2.0 ( build 2557.0)


 

Publié dans 1-EXCHANGE 2010, Cas-2010, Exchange 2010 SP2, Haute disponibilité | Poster un commentaire »

 
Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 184 followers