II.8.1- COMPORTEMENTS DE CLIENTS ET SERVEURS SIP

Précédent
Sommaire
Suivant

1) Le protocole SIP a été défini pour utiliser à la fois les protocoles de transport TCP et UDP ). De plus il fournit son propre mécanisme pour fiabiliser les sessions.

Les serveurs reçoivent une ou plusieurs copies des requêtes et retransmettent la réponse appropriée. Après avoir reçu une requête CANCEL d’un client, un PS renvoie une requête CANCEL sur toutes les branches n'ayant pas encore reçu de réponse finale.

Quand un UAS reçoit une requête, il compare le CALL-ID de cette requête à ceux des appels en cours :

· Si le CALL-ID correspond à l’un d’eux, il compare alors le tag de l’URL TO de la requête avec celui de l’appel en cours et rejette la requête s'ils ne correspondent pas. L’UAS compare également le tag de l’URL FROM de la requête avec ceux des appels existant. S'il correspond à l’un d’enx, les Cseq sont alors comparés. Si le Cseq de la requête est inférieur ou égal à celui de l’appel courant, la requête est une retransmission, sinon, c’est une nouvelle requête. Dans ce cas, si le champ d’en-tête de la nouvelle requête ne correspond à aucun de ceux des appels existant, un nouvel appel est créé.

· Si le CALL-ID ne correspond à aucun d’eux, un nouvel appel est créé.

Avant d’envoyer une réponse finale, un serveur doit constament envoyer des réponses provisoires. En effet, si un PS, RS, UAS ou RG ne peut pas répondre à une requête dans les 200 ms, il doit renvoyer une réponse provisoire(code1xx) dès que possible.

Les réponses sont associées aux requêtes grâce aux en-têtes TO, FROM, CALL-ID, Cseq et le premier Via d'en-tête. Elles doivent donner fin aux retransmissions des requêtes même si ces dernières possèdent un en-tête Via leur demandant d'acheminer les réponses jusqu'au client final.

Il arrive qu’un PS reçoive une réponse ne le concernant pas(le PS n’a pas enregistré de requête y correspondant). Si le champ d’en-tête Via indique que le prochain serveur auquel sera transmis la réponse utilise TCP, alors le PS contacté ouvre une connexion TCP à cette adresse. Ainsi, les PS doivent se préparer à recevoir des réponses aux entrées où sont ouvertes des connexions TCP passives, même lorsque beaucoup de réponses arrivent aux entrées où sont ouvertes des connexions TCP actives. Notons qu’une connexion TCP est dite active lorsqu’elle a été initialisée par un PS et passive lorsqu’elle est acceptée par un PS mais ouverte par une autre entité.

Les réponses de code 100 ne doivent pas être retransmises alors que les autres réponses de code 1xx peuvent l’être après que le serveur a retransmis les réponses en cours. Les réponses de code 2xx sont retransmises en accord avec le champ d’en-tête Via et une fois qu’un PS a reçu une telle réponse, il ne doit pas retransmettre de réponse d’autres codes (1xx et 3xx à 6xx ). Les réponses de code 3xx à 6xx sont retransmises par chaque PS jusqu’à ce que la prochain PS traversé jusqu'au client envoie un acquittement ACK ou un message d’annulation CANCEL.

Un PS doit conserver l’état d’une transaction pendant au moins 32 secondes après réception de la première réponse définitive autre que la réponse OK(code 200) afin de pouvoir retransmettre cette réponse.

2) Pour transporter des messages SIP, l’on a vu que les protocoles TCP et UDP(unicast et multicast) étaient utilisés. Les protocoles de transport ont besoin des adresses source et destination afin d’établir des connexions. Dans une même connexion, plusieurs sessions SIP peuvent être ouvertes.

Les réponses sont retournées à l’adresse listée dans le champ d’en-tête Via et non à l’adresse source de la requête directement.

Un client recevant une requête en multicast ne doit pas vérifier si l’identificateur de machine, contenu dans la requête URI, correspond avec son propre identificateur de machine mais doit renvoyer sa réponse en multicast aussitôt. Une telle réponse conserve alors le même temps de vie (ttl) que la requête, contenu dans le champ d’en-tête Via de cette dernière. Pour éviter toute inondation de réponses, un serveur ne doit pas envoyer de requête en multicast avec un code d’état autre que 2xx ou 6xx. De plus, le serveur retardera sa réponse d’une durée aléatoire et uniformément distribuée entre 0 et 1 seconde. Enfin, il ne doit pas non plus répondre à des requêtes CANCEL.

Une simple connexion TCP peut transporter plusieurs transactions SIP. Une transaction contient aucune ou plusieurs réponses provisoires, suivies de une ou plusieurs réponses définitives. Le client maintient la connexion ouverte au moins jusqu’à ce que la première réponse définitive lui soit retournée. Si la connexion est fermée avant, elle sera traîtée comme une requête CANCEL par le serveur. De même, le serveur ne devrait pas fermer une connexion TCP avant qu’il n’ait envoyé sa réponse finale, mais peut le faire s’il le souhaite. Cependant, c’est le client qui est responsable de la fermeture de la connexion.

3) Etudions la fiabilité du transport des messages SIP, dans le cas de requêtes BYE, OPTIONS, CANCEL et REGISTER, avec UDP et TCP.

Avec UDP :

Le mécanisme du Slow-Start est utilisé pour fixer la taille de la fenêtre d’émission des requêtes(T1), suivi du mécanisme de Congestion Avoidment une fois la taille de fenêtre maximale atteinte(T2). Ces mécanismes sont utilisés par les clients SIP. Par défaut, T1=500 ms et T2=4 s. Avec le premier mécanisme, la fenêtre est doublée à chaque envoi d’un nouveau paquet (2*T1, 4*T1, 8*T1…) et quand T2 est atteint, le second mécanisme démarre. Les retransmissions sont alors espacées de T2 secondes : si le client reçoit une réponse provisoire, il continue à transmettre la requête associée toutes les T2 secondes jusqu’à ce qu’il reçoive la réponse définitive ou jusqu’à ce qu’il ait émis 11 paquets UDP. De son côté, le serveur SIP retransmet la réponse associée à la requête de retransmission du client. Après que le serveur a envoyé la réponse définitive au client, il doit conserver cette dernière en mémoire au moins 10*T2 secondes, le temps que le client la reçoive. En effet, si le client la réclamait à nouveau, il n’aurait pas à faire appel au LS (Location Server).

Chaque PS génère sa propre réponse finale à une requête CANCEL. Les réponses finales aux requêtes BYE et OPTIONS sont générées par les RS et UAS alors que la réponse finale à une requête REGISTER est effectuée par le RG(Registrar) associé.

Notons que les réponses à ces requêtes ne sont pas retransmises périodiquement ni acquittées par un ACK.

Avec TCP :

Les clients utilisant TCP n’ont pas besoin de retransmettre les requêtes car TCP assure la fiabilité du transport.

4) Etudions la fiabilité du transport des messages SIP, dans le cas d’une requête INVITE.

Voici quelques situations gênantes que l'on peut rencontrer :

●Un temps trop important s'écoule entre l'arrivée de l'invitation à un appel et la réponse définitive à cette invitation. Ce temps peut atteindre quelques dizaines de secondes.

●Il peut exister un décalage entre le moment où l'appelé accepte l’invitation (décroche) et le moment où la sonnerie correspondante s’arrête. A la mise en communication, la sonnerie peut persister.

●L'appelé peut décrocher au moment où l'appelant raccroche, ils ne seront pas mis en relation.

Pour y remédier, voici les solutions utilisées :

Avec UDP, on retrouve les mécanismes du Slow-Start, suivi du mécanisme de Congestion Avoidment décrits ci-dessus. La retransmission d'une réponse cesse dans les cas suivant : si un ACK, un BYE ou un CANCEL est bien reçu par l’appelant, en réponse à une invitation ou si la réponse a été transmise 7 fois de suite.

Les schémas suivants montrent les états successifs du client appelant (UAC) et du serveur de l'appelé (UAS) lors de l'émission d'une invitation :

Avec TCP,les requêtes ne sont jamais retransmises. Par contre les réponses le sont jusqu'à réception du ACK suivant le même algoritme qu'avec UDP.

5) Etudions la fiabilité du transport des messages SIP, dans le cas d’une requête ACK.

Une requête ACK ne génère jamais de réponse sauf si elle acquitte une requête INVITE. La requête ACK ne suit pas forcément le même chemin que la requête INVITE qu’elle acquitte et peut même susciter, pour être transmise, l'ouverture d'une nouvelle connexion TCP.