Lync 2010 : SIP : Notions de base

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)

 

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

 

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