Comme l’INVITE initial représente une demande en dehors d’un dialogue, sa construction suit les procédures du paragraphe 8.1.1. Un traitement supplémentaire est nécessaire pour le cas spécifique d’INVITE.
Un champ d’en-tête Allow (paragraphe 20.5) DEVRAIT être présent dans INVITE. Il indique quelles méthodes peuvent être invoquées dans un dialogue, lorsque l’agent d’utilisateur envoie l’INVITE, pour la durée du dialogue. Par exemple, un agent d’utilisateur capable de recevoir des demandes INFO au sein d’un dialogue [34] DEVRAIT inclure un champ d’en-tête Allow faisant la liste de la méthode INFO.
Un champ d’en-tête Supported (paragraphe 20.37) DEVRAIT être présent dans INVITE. Il énumère toutes les extensions comprises par l’UAC.
Un champ d’en-tête Accept (paragraphe 20.1) PEUT être présent dans INVITE. Il indique quels types de contenu sont acceptables pour l’agent d’utilisateur, à la fois dans la réponse qu’il reçoit, et dans toutes demandes ultérieures qui lui sont envoyées au sein des dialogues établis par l’INVITE. Le champ d’en-tête Accept est particulièrement utile pour indiquer la prise en charge des divers formats de description de session.
L’UAC PEUT ajouter un champ d’en-tête Expires (paragraphe 20.19) pour limiter la validité de l’invitation. Si l’heure indiquée dans le champ d’en-tête Expires est atteint et qu’il n’a pas été reçu de réponse finale à l’INVITE, l’UAC central DEVRAIT générer une demande CANCEL pour l’INVITE, conformément à la Section 9.
Un UAC PEUT aussi trouver utile d’ajouter, entre autres, les champs d’en-tête Subject (paragraphe 20.36), Organization (paragraphe 20.25) et User-Agent (paragraphe 20.41). Ils contiennent tous des informations qui se rapportent à INVITE.
L’UAC PEUT choisir d’ajouter un corps de message à l’INVITE. Le paragraphe 8.1.1.10 traite de la façon de construire les champs d’en-tête -- Content-Type entre autres – nécessaires pour décrire le corps de message.
Il y a des règles particulières pour les corps de message qui contiennent une description de session - leur Content-Disposition correspondant est "session". SIP utilise un modèle d’offre/réponse où un agent d’utilisateur envoie une description de session, appelée l’offre, qui contient une proposition de description de la session. L’offre indique les
moyens de communication désirés (audio, vidéo, jeux), les paramètres de ces moyens (tels que les types de codec) et les adresses pour les supports de réception de la part de celui qui répond. L’autre agent d’utilisateur répond par une autre description de session, appelée la réponse, qui indique quels moyens de communication sont acceptés, les paramètres qui s’appliquent à ces moyens, et les adresses pour les supports de réception de la part de l’offreur. Un échange offre/réponse se fait dans le contexte d’un dialogue, de sorte que si une INVITE SIP résulte en plusieurs dialogues, chacun est un échange offre/réponse séparé. Le modèle offre/réponse définit des restrictions sur le moment où peuvent être faites les offres et les réponses (par exemple, on ne peut pas faire une nouvelle offre tant qu’il y en a une en cours).
Il en résulte des restrictions sur l’endroit où les offres et les réponses peuvent apparaître dans les messages SIP. Dans la présente spécification, les offres et les réponses ne peuvent apparaître que dans des demandes et réponses INVITE, et ACK. L’utilisation des offres et réponses est encore limitée. Pour la transaction initiale INVITE, les règles sont :
o L’offre initiale DOIT être dans une INVITE ou, si elle n’y est pas, dans le premier message de non échec fiable provenant de l’UAS en retour à l’UAC. Dans la présente spécification, c’est la réponse finale 2xx.
o Si l’offre initiale est une INVITE, la réponse DOIT être dans un message de non échec fiable de UAS en retour à l’UAC qui est corrélé à cette INVITE. Pour la présente spécification, c’est seulement la réponse finale 2xx à cette INVITE. La même réponse exacte PEUT aussi être placée dans toute réponse provisoire envoyée avant la réponse. L’UAC DOIT traiter la première description de session qu’il reçoit comme la réponse, et DOIT ignorer toute description de session dans les réponses suivantes à l’INVITE initiale.
o Si l’offre initiale est dans le premier message de non échec fiable de l’UAS en retour à l’UAC, la réponse DOIT être dans l’accusé de réception à ce message (dans la présente spécification, ACK pour une réponse 2xx).
o Après avoir envoyé ou reçu une réponse à la première offre, l’UAC PEUT générer des offres ultérieures dans des demandes sur la base des règles spécifiées pour cette méthode, mais seulement si il a reçu des réponses à toute offre précédente, et n’a pas envoyé d’autre offres pour laquelle il n’ait pas reçu de réponse.
o Une fois que l’UAS a envoyé ou reçu une réponse à l’offre initiale, il NE DOIT PAS générer d’offre ultérieure dans une réponse à l’INVITE initiale. Cela signifie qu’un UAS se fondant sur la présente spécification seule ne peut jamais générer d’offre ultérieure jusqu’à l’achèvement de la transaction initiale.
Concrètement, les règles ci-dessus spécifient deux échanges pour les agents d’utilisateur conformes à la présente spécification seule – l’offre est dans l’INVITE, et la réponse dans le 2xx (et peut aussi être dans une 1xx, avec la même valeur), ou l’offre est dans la 2xx, et la réponse est dans le ACK. Tous les agent d’utilisateurs qui prennent en charge INVITE DOIVENT prendre en charge ces deux échanges.
Le protocole de description de session (SDP) (RFC 2327 [1]) DOIT être pris en charge par tous les agents d’utilisateur comme moyen de décrire les sessions, et son utilisation pour la construction des offres et réponses DOIT suivre les procédures définies en [13].
Les restrictions au modèle d’offre-réponse décrites ci-dessus ne s’appliquent qu’aux objets dont la valeur de champ d’en-tête Disposition-de-contenu est "session". Donc, il est possible que l’INVITE et l’ACK contiennent tous deux un corps de message (par exemple, l’INVITE porte une photo (Disposition-de-contenu : rendu) et l’ACK une description de session (Disposition-de-contenu : session)).
Si le champ d’en-tête Disposition-de-contenu manque, les objets de Type-de-contenu application/sdp impliquent la disposition "session", alors que les autres types de contenu impliquent "rendu".
Une fois que l’INVITE a été créé, l’UAC suit les procédures définies pour l’envoi des demandes en-dehors d’un dialogue (Section 8). Il en résulte une construction de transaction client qui va finalement envoyer la demande et livrer les réponses à l’UAC.
13.2.2 Traitement des réponses à INVITE
Une fois que l’INVITE a été passée au client de transaction INVITE, l’UAC attend les réponses à l’INVITE. Si le client de transaction INVITE retourne une fin de temporisation plutôt qu’une réponse, le TU agit comme si une réponse 408 (Demande hors limite) avait été reçue, comme indiqué au paragraphe 8.1.3.
13.2.2.1 Réponses 1xx
Zéro, une ou plusieurs réponses provisoires peuvent arriver avant qu’une ou plusieurs réponses finales ne soient reçues.
Les réponses provisoires à une demande INVITE peuvent créer des "dialogues précoces". Si une réponse provisoire a
une étiquette dans le champ To, et si l’identifiant de dialogue de la réponse ne correspond pas à un dialogue existant, il en est construit une en utilisant les procédures définies au paragraphe 12.1.2.
Le dialogue précoce ne sera nécessaire que si l’UAC a besoin d’envoyer une demande à son homologue au sein du dialogue avant l’achèvement de la transaction INVITE initiale. Les champs d’en-tête présents dans une réponse provisoire sont applicables tant que le dialogue est dans l’état précoce (par exemple, un champ d’en-tête Allow dans une réponse provisoire contient les méthodes qui peuvent être utilisées dans le dialogue alors qu’il est dans l’état précoce).
13.2.2.2 Réponses 3xx
Une réponse 3xx peut contenir une ou plusieurs valeurs de champ d’en-tête Contact fournissant les nouvelles adresses où l’appelé pourrait être joint. Selon le code d’état de la réponse 3xx (voir au paragraphe 21.3), l’UAC PEUT choisir d’essayer les nouvelles adresses.
13.2.2.3 Réponses 4xx, 5xx et 6xx
Une seule réponse finale non-2xx peut être reçue pour l’INVITE. Des réponses 4xx, 5xx et 6xx peuvent contenir une valeur de champ d’en-tête Contact qui indique la localisation où des informations supplémentaires sur l’erreur peuvent être trouvées. Des réponses fiables ultérieures (qui n’arriveraient que dans des conditions d’erreur) DOIVENT être ignorées.
Tous les dialogues précoces sont considérés comme terminés à réception de la réponse finale non-2xx.
Après avoir reçu la réponse finale non-2xx, l’UAC central considère que la transaction INVITE est terminée. Le client de transaction INVITE traite la création des ACK pour la réponse (voir au paragraphe 17).
13.2.2.4 Réponses 2xx
Plusieurs réponses 2xx peuvent arriver à l’UAC pour une seule demande INVITE du fait du mandataire "fourchu".
Chaque réponse est distinguée par le paramètre d’étiquette dans le champ d’en-tête To, et chacune représente un dialogue distinct, avec un identifiant de dialogue distinct.
Si l’identifiant de dialogue dans la réponse 2xx correspond à l’identifiant de dialogue pour un dialogue existant, le dialogue DOIT être passé à l’état "confirmé", et l’ensemble des routes pour le dialogue DOIT être recalculé sur la base de la réponse 2xx en utilisant les procédures du paragraphe 12.2.1.2. Autrement, un nouveau dialogue dans l’état
"confirmé" DOIT être construit en utilisant les procédures du paragraphe 12.1.2.
Noter que seulement une partie des états qui sont recalculés est l’ensemble des routes. Les autres parties de l’état, comme le plus haut numéro de séquences (distant et local) envoyées au sein du dialogue, ne sont pas recalculées.
L’ensemble des routes seul est recalculé pour la compatibilité amont. La RFC 2543 ne rendait pas obligatoire la réflexion du champ d’en-tête Record-Route dans une réponse 1xx, et seulement dans une réponse 2xx. Cependant, on ne peut pas mettre à jour la totalité de l’état du dialogue car les demandes de mi-dialogue peuvent avoir été envoyées au sein du dialogue précoce, modifiant le numéro de séquences, par exemple.
L’UAC central DOIT générer une demande ACK pour chaque réponse 2xx reçue de la part de la couche transaction. Le champ d’en-tête de l’ACK est construit de la même façon que toute demande envoyée au sein d’un dialogue (voir à la Section 12) avec l’exception de CSeq et des champs d’en-tête se rapportant à l’authentification. Le numéro de séquence du champ d’en-tête CSeq DOIT être le même que celui de l’INVITE dont il est accusé réception, mais la méthode CSeq DOIT être ACK. Le ACK DOIT contenir les mêmes accréditifs que l’INVITE. Si le 2xx contient une offre (sur la base des règles ci-dessus), le ACK DOIT porter une réponse dans son corps. Si l’offre dans la réponse 2xx n’est pas acceptable, l’UAC central DOIT générer une réponse valide dans le ACK et ensuite envoyer immédiatement un BYE.
Une fois que le ACK a été construit, les procédures de [4] sont utilisées pour déterminer l’adresse de destination, le port et le transport. Cependant, la demande est passée à la couche transport directement pour transmission, plutôt qu’à la transaction client. Cela parce que l’UAC central traite les retransmissions de l’ACK, et non la couche transaction.
L’ACK DOIT être passé au transport client chaque fois qu’une retransmission de la réponse 2xx finale est déclanchée à l’arrivée de l’ACK.
L’UAC central considère les transactions INVITE comme achevées 64*T1 secondes après la réception de la première réponse 2xx. A ce point des dialogues précoces qui ne sont pas passés à l’établissement de dialogues, ces dialogues sont terminés. Une fois que la transaction INVITE est considérée comme terminée à l’UAC central, il n’est attendu aucune autre réponse 2xx nouvelle.
Si, après l’accusé de réception de toute réponse 2xx à un INVITE, l’UAC ne veut pas continuer ce dialogue, l’UAC DOIT alors terminer le dialogue en envoyant une demande BYE comme indiqué au paragraphe 15.
13.3 Traitement de l’UAS