Un paquet S.I.P : que contient-il?

Vous pouvez donc voir ci-dessus un exemple de communication S.I.P. Le client 1 voulant se connecter sur le client 2 envoie une requête INVITE. Le poste du client 2, précisant qu’il a bien reçu l’invitation, va répondre via un RINGING qui signifie en somme mon téléphone sonne. Dès que le client 2 aura décroché une requête ACK sera envoyée au client 1. Avant de démarrer le flux média le client va envoyer une requête OK. L’échange du flux média peut enfin avoir lieu. Lorsque ce dernier est fini le client voulant arrêter la communication (ici le client 2) envoie une requête BYE et pour acquitter celle-ci le client 1 lui répond par une requête OK.

Comme vous pouvez le voir sur votre droite, un paquet S.I.P peut se décomposer en deux partie : une entête et le message lui même

Dans l’entête, on retrouve des informations telles que :

• l’adresse IP de la source

• l’adresse IP de la destination

• le type de message (INVITE, ACK, OK, BYE, etc…)

• le type de contenu du message (souvent SDP)

• etc.

Dans l’entête, on retrouve des informations telles que :

• l’adresse IP et le port de la source qui seront utilisés pour le flux média

• le type de flux media qui sera utilisé par exemple du RTP

• etc.

Notre problème vient donc dû fait que Mary, se situant derrière un N.A.T, mettra dans le paquet S.I.P son adresse privée. Lors de son passage à travers le N.A.T l’adresse source du paquet sera bien évidemment remplacée par une adresse publique mais seulement au niveau IP et non applicatif. John ne se basant que sur l’IP inscrite dans le paquet S.I.P et non sur la provenance de celui-ci, ne pourra pas répondre à Mary puisqu’il ne verra que son adresse privée qui n’est pas routable sur Internet.

Pour palier à ce problème différents protocoles existent dont les protocoles STUN et TURN qui sont présentés dans ce site. Cependant pour bien comprendre leur fonctionnement, je vous invite à aller lire dans un premier temps la section décrivant les différents types de N.A.T existants.