| | Essai | Tempo F ou | +--->| | Erreur transport | +---+ informe TU | 200-699 | | | rép. à TU | |1xx | +---+ |rép. à TU | | | | | Tempo E, demande V Tempo F | | envoyée +---+ ou Err. transport | | +---| | informe TU | | | |Traitement |--->|
| +--->| en cours |---+ | | +---+ |1xx | | | ^ | rép. à TU | | 200-699 | +---+ | | rép. à TU | | | V | | +---+ | | | Achevée | | | +---+ | | ^ | | | | | Tempo K | +---+ | - | V | Note : les transitions +---+ | sont étiquetées avec | Terminé |<---+
l’événement sur l’action | | à entreprendre +---+
Figure 6 : Transaction client non-INVITE
17.2 Transaction de serveur
La transaction serveur est responsable de la livraison des demandes au TU et de la transmission fiable des réponses. Elle le fait par l’intermédiaire d’un automate à états. Les transactions serveur sont créées par le centre lorsqu’une demande est reçue et que le traitement de la transaction est souhaité pour cette demande (ce qui n’est pas toujours le cas).
Comme avec les transactions client, l’automate à états dépend de si la demande reçue est une demande INVITE.
17.2.1 Transaction INVITE du serveur
La Figure 7 montre le diagramme des états pour la transaction de serveur INVITE.
Lorsqu’une transaction de serveur est construite pour une demande, elle entre dans l’état "Proceeding". La transaction de serveur DOIT générer une réponse 100 (En essai) sauf si elle sait que le TU va générer une réponse provisoire ou finale dans les 200 ms, auquel cas elle PEUT générer une réponse 100 (En essai). Cette réponse provisoire est nécessaire pour arrêter rapidement les retransmissions afin d’éviter l’encombrement du réseau. La réponse 100 (En essai) est construite conformément aux procédures du paragraphe 8.2.6, sauf que l’insertion des étiquettes dans le champ d’en-tête To de la réponse (lorsque aucune n’était présente dans la demande) est déclassée de PEUT à NE DEVRAIT PAS. La demande DOIT être passée au TU.
Le TU passe toutes les réponses provisoires à la transaction de serveur. Tant que la transaction de serveur est dans l’état
"Proceeding", chacune d’elles DOIT être passée à la couche transport pour transmission. Elles ne sont pas envoyées de façon fiable par la couche transaction (ce n’est pas par elle qu’elles sont retransmises) et ne causent pas un changement dans l’état de la transaction de serveur. Si une retransmission de demande est reçue pendant l’état "Proceeding", la plus récente réponse provisoire reçue du TU DOIT être passée à la couche transport pour retransmission. Une demande est une retransmission si elle correspond à la même transaction de serveur sur la base des règles du paragraphe 17.2.3.
Si, étant dans l’état "Proceeding", le TU passe une réponse 2xx à la transaction de serveur, la transaction de serveur DOIT passer cette réponse à la couche transport pour transmission. Elle n’est pas retransmise par la transaction de
serveur ; les retransmissions des réponses 2xx sont traitées par le TU. La transaction de serveur DOIT alors passer à l’état "Terminated".
Dans l’état "Proceeding", si le TU passe une réponse avec code d’état de 300 à 699 à la transaction de serveur, la réponse DOIT être passée à la couche transport pour transmission, et l’automate à états DOIT entrer dans l’état
"Completed". Pour les transports non fiables, le temporisateur G est réglé pour arriver à expiration dans T1 secondes, et n’est pas établi pour les transports fiables.
Ceci est un changement par rapport à la RFC 2543, où les réponses étaient toujours retransmises, même sur les transports fiables.
Lorsqu’on est passé à l’état "Completed", le temporisateur H DOIT être réglé pour arriver à expiration en 64*T1 secondes pour tous les transports. Le temporisateur H détermine quand la transaction de serveur abandonne les retransmissions de la réponse. Sa valeur est choisie pour être égale à celle du temporisateur B, la durée pendant laquelle une transaction client va continuer à essayer d’envoyer une demande. Si le temporisateur G arrive à expiration, la réponse est passée à la couche transport une fois de plus pour retransmission, et le temporisateur G est réglé pour arriver à expiration dans MIN(2*T1, T2) secondes. A partir de là, lorsque le temporisateur G arrive à expiration, la réponse est passée à nouveau au transport pour transmission, et le temporisateur G est relancé avec une valeur qui double, jusqu’à ce que cette valeur excède T2, auquel cas il est relancé avec la valeur de T2. Ceci est identique au comportement de retransmission pour des demandes dans l’état "Trying" de la transaction client non-INVITE. De plus, dans l’état
"Completed", si une retransmission de demande est reçue, le serveur DEVRAIT passer la réponse au transport pour retransmission.
Si un ACK est reçu lorsque la transaction de serveur est dans l’état "Completed", la transaction de serveur DOIT passer à l’état "Confirmed". Comme le temporisateur G est ignoré dans cet état, toute retransmission de la réponse va cesser.
Si le temporisateur H arrive à expiration pendant l’état "Completed", cela implique que le ACK n’a jamais été reçu.
Dans ce cas, la transaction de serveur DOIT passer à l’état "Terminated", et DOIT indiquer au TU qu’un échec de transaction est survenu. retransmissions de la réponse finale. Lorsqu’on arrive à cet état, le temporisateur I est réglé pour arriver à expiration dans T4 secondes pour les transports non fiables, et zéro seconde pour les transports fiables. Une fois que le
temporisateur I arrive à expiration, le serveur DOIT passer à l’état "Terminé".
Une fois que la transaction est dans l’état "Terminé", elle DOIT être immédiatement détruite. Comme avec les transactions client, ceci est nécessaire pour assurer la fiabilité des réponses 2xx à INVITE.
17.2.2 Transaction Non-INVITE du serveur
L’automate à états pour la transaction de serveur non-INVITE est montré à la Figure 8.
L’automate à états est initialisé dans l’état "Trying" et est passé dans une demande autre que INVITE ou ACK à l’initialisation. Cette demande est passée au TU. Une fois dans l’état "Trying", toutes les retransmissions de demandes ultérieures sont éliminées. Une demande est une retransmission si elle correspond à la même transaction de serveur, en utilisant les règles spécifiées au paragraphe 17.2.3.
Dans l’état "Trying", si le TU passe une réponse provisoire à la transaction de serveur, la transaction de serveur DOIT entrer dans l’état "Proceeding". La réponse DOIT être passée à la couche transport pour transmission. Toutes réponses provisoires ultérieures qui sont reçues du TU dans l’état "Proceeding" DOIVENT être passées à la couche transport pour transmission. Si une retransmission de la demande est reçue dans l’état "Proceeding", la réponse provisoire la plus récemment envoyée DOIT être passée à la couche transport pour retransmission. Si le TU passe une réponse finale (code d’états 200-699) au serveur dans l’état "Proceeding", la transaction DOIT entrer dans l’état "Completed", et la réponse DOIT être passée à la couche transport pour transmission.
Lorsque la transaction de serveur entrer dans l’état "Completed", elle DOIT régler le temporisateur J pour qu’il arrive à expiration dans 64*T1 secondes pour les transports non fiables, et zéro seconde pour les transports fiables. Dans l’état
"Completed", la transaction de serveur DOIT passer la réponse finale à la couche transport pour retransmission à chaque fois qu’est reçue une retransmission de la demande. Toute autre réponse finale passée par le TU à la transaction de serveur DOIT être éliminée pendant l’état "Completed". La transaction de serveur reste dans cet état jusqu’à l’arrivée à expiration du temporisateur J, et à ce point, il DOIT passer à l’état "Terminated".
La transaction de serveur DOIT être détruite à l’instant où elle entre dans l’état "Terminated".
17.2.3 Correspondance des demandes avec les transactions du serveur
Lorsqu’une demande est reçu du réseau par le serveur, elle doit être comparée à une transaction existante. Ceci s’accompli de la façon suivante.
Le paramètre de branche dans le champ d’en-tête Via le plus élevé de la demande est examiné. S’il est présent et commence par le cookie magique "z9hG4bK", la demande a été générée par une transaction client conforme à la présente spécification. Donc, le paramètre branche sera unique parmi toutes les transactions envoyées par ce client. La demande correspond à une transaction si :
1. le paramètre de branche dans la demande est égal à celui du champ d’en-tête Via de tête de la demande qui a créé la transaction, et
2. la valeur send-by dans le Via de tête de la demande est égal à celui de la demande qui a créé la transaction, et 3. la méthode de la demande correspond à celle qui a créé la transaction, excepté pour ACK, où la méthode de la
demande qui a créé la transaction est INVITE.
Ces règles de correspondance s’appliquent aussi bien aux transactions INVITE et non-INVITE.
La valeur send-by est utilisée au titre du processus de correspondance parce qu’il pourrait y avoir des duplications accidentelles ou malveillantes des paramètres de branche à partir de clients différents.
Si le paramètre de branche dans le champ d’en-tête Via de tête n’est pas présent, ou s’il ne contient pas le cookie magique, les procédures suivantes sont utilisées. Elles existent pour permettre la rétro-compatibilité des mises en œuvre conformes à la RFC 2543.
La demande INVITE correspond à une transaction si l’URI-de-demande, l’étiquette To, l’étiquette From, le Call-ID, le CSeq, et le champ d’en-tête Via de tête correspondent à ceux de la demande INVITE qui a créé la transaction. Dans ce cas, l’INVITE est une retransmission de l’original qui a créé la transaction. La demande ACK correspond à une transaction si l’URI-de-demande, l’étiquette From, le Call-ID, le numéro CSeq (et non la méthode), et le champ d’en-tête Via de d’en-tête correspondent à ceux de la demande INVITE qui a créé la transaction, et si l’étiquette To du ACK correspond à l’étiquette To de la réponse envoyée par la transaction de serveur. La correspondance est faite sur la base des règles de correspondance définies pour chacun de ces champs d’en-tête. L’inclusion de l’étiquette dans le champ
d’en-tête To dans le processus de correspondance de ACK aide à lever les ambiguïtés de ACK pour les réponses 2xx par rapport au ACK pour d’autres réponses à un mandataire, qui peuvent avoir transmis les deux réponses. (Ceci peut survenir dans des conditions inhabituelles. Précisément, lorsqu’un mandataire a fourché une demande, et ensuite a une défaillance, la réponse peut être livrée à un autre mandataire, ce qui peut se terminer par la transmission de plusieurs réponses vers l’amont). Une demande ACK qui correspond à une transaction INVITE à laquelle correspond un ACK précédent est considéré comme une retransmission de cet ACK précédent.
|Demande reçue |passée au TU V
+---+
| Essai |---+
+---+ |200-699 du TU | |envois réponse |1xx du TU |
|envoie réponse | | | Demande V 1xx du TU | envoie réponse +---+envoie rép. | +---| |---+ | | | Traitement| | | +--->| en cours |<---+ | +<---| | | |Err. transport +---+ | |Informe TU | | | |200-699 du TU | | |envoie réponse | | Demande V | | envoie réponse+---+ | | +---| | | | | | Achevé |<---+
| +--->| | +<---| | |Err transport +---+
|Informe TU |
| |Tempo J expire |
| V
| +---+
+--->| Terminé | +---+
Figure 8 : Transaction serveur non-INVITE
Pour toutes les autres méthodes de demande, une demande correspond à une transaction si l’URI-de-demande, l’étiquette To, l’étiquette From, le Call-ID, le CSeq (y compris la méthode), et le champ d’en-tête Via de tête correspondent à ceux de la demande qui a créé la transaction. La correspondance est établie sur la base des règles de correspondance définies pour chacun de ces champs d’en-tête. Lorsqu’une demande non-INVITE correspond à une transaction existante, elle est une retransmission de la demande qui a créé cette transaction.
Parce que les règles de correspondance incluent l’URI-de-demande, le serveur ne peut pas faire correspondre une réponse à une transaction. Lorsque le TU passe une réponse à la transaction de serveur, il doit la passer à la transaction de serveur spécifique pour laquelle la réponse est ciblée.
17.2.4 Traitement des erreurs de transport
Lorsque la transaction de serveur envoie une réponse à la couche transport pour être envoyée, les procédures suivantes s’appliquent si la couche transport indique une défaillance.
D’abord, on suit les procédures de [4], qui essayent de livrer la réponse à une sauvegarde. Si cela échoue, sur la base de la définition de l’échec dans [4], la transaction de serveur DEVRAIT informer le TU qu’une défaillance est survenue, et DEVRAIT passer à l’état terminé.
18 Transport
La couche transport est responsable de la transmission réelle des demandes et réponses sur les transports réseau. Cela inclut la détermination de la connexion à utiliser pour une demande ou réponse dans le cas de transports orientés connexion.
La couche transport est responsable de la gestion des connexions persistantes pour les protocoles de transport comme TCP et SCTP, ou TLS parmi eux, y compris ceux qui sont ouverts à la couche transport. Ceci inclut les connexions ouvertes par les transports client ou serveur, de sorte que les connexions soient partagées entre les fonctions de transport client et serveur. Ces connexions sont indexées par le tuplet formé de l’adresse, port, et protocole de transport à l’extrémité distante de la connexion. Lorsque une connexion est ouverte par la couche transport, cet indice est mis à la destination, port et transport IP. Lorsque la connexion est acceptée par la couche transport, cet indice est mis à l’adresse IP de source, au numéro de port, et transport. Noter que, parce que le port de source est souvent éphémère, mais on ne peut savoir si il est éphémère ou choisi par les procédures de [4], les connexions acceptées par la couche transport seront fréquemment non réutilisées. Il en résulte que deux mandataires dans une relation "d’homologue à homologue"
utilisant un transport orienté connexion auront fréquemment deux connexions en service, une pour les transactions initialisée dans chaque direction.
Il est RECOMMANDÉ que les connexions soient gardées ouvertes pour des durées définies par les mises en œuvre après l’envoi du dernier message ou sa réception sur cette connexion. Sa durée DEVRAIT au moins être égale à la plus longue durée dont l’élément aura besoin afin d’amener une transaction de l’instanciation à l’état terminé. Ceci est destiné à augmenter la probabilité que les transactions soient terminées sur la même connexion que celle sur laquelle elle ont été initialisées (par exemple, demande, réponse, et dans le cas de INVITE, ACK pour les réponses non-2xx).
Cela signifie habituellement au moins 64*T1 (voir au paragraphe 17.1.1.1 pour une définition de T1). Cependant, elle pourrait être plus longue dans un élément qui a un TU en utilisant une grande valeur pour le temporisateur C (point 11 du paragraphe 16.6), par exemple.
Tous les éléments SIP DOIVENT mettre en œuvre UDP et TCP. Les éléments SIP PEUVENT mettre en œuvre d’autres protocoles.
Rendre TCP obligatoire pour l’agent utilisateur est un changement substantiel par rapport à la RFC 2543. C’est venu du besoin de traiter des messages plus longs, qui DOIVENT utiliser TCP, comme expliqué ci-dessous. Et donc, même si un élément n’envoie jamais de gros messages, il peut en recevoir un et a besoin d’être capable de le traiter.