Exchange your Mind

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

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

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.

Joignez-vous à 223 followers

%d bloggers like this: