Aller au contenu principal

8. Comportement général de l'agent utilisateur (General User Agent Behavior)

8 Comportement général de l'agent utilisateur (General User Agent Behavior)

Un user agent représente un système terminal. Il contient un user agent client (UAC), qui génère des requêtes, et un user agent server (UAS), qui y répond. Un UAC est capable de générer une requête basée sur une stimulation externe (l'utilisateur cliquant sur un bouton, ou un signal sur une ligne PSTN) et de traiter une réponse. Un UAS est capable de recevoir une requête et de générer une réponse basée sur une entrée utilisateur, une stimulation externe, le résultat de l'exécution d'un programme, ou un autre mécanisme.

Lorsqu'un UAC envoie une requête, celle-ci passe par un certain nombre de serveurs proxy, qui la transfèrent vers le UAS. Lorsque le UAS génère une réponse, celle-ci est transférée vers le UAC.

Les procédures UAC et UAS dépendent fortement de deux facteurs. D'abord, selon que la requête ou la réponse est à l'intérieur ou à l'extérieur d'un dialog, et ensuite, selon la méthode d'une requête. Les dialogs sont discutés en détail à la Section 12 ; ils représentent une relation peer-to-peer entre agents utilisateurs et sont établis par des méthodes SIP spécifiques, telles que INVITE.

Dans cette section, nous discutons des règles indépendantes de la méthode pour le comportement UAC et UAS lors du traitement des requêtes qui sont hors d'un dialog. Cela inclut, bien sûr, les requêtes qui établissent elles-mêmes un dialog.

Les procédures de sécurité pour les requêtes et réponses hors dialog sont décrites à la Section 26. Spécifiquement, des mécanismes existent pour que le UAS et le UAC s'authentifient mutuellement. Un ensemble limité de fonctionnalités de confidentialité est également pris en charge via le chiffrement des corps à l'aide de S/MIME.

8.1 Comportement UAC (UAC Behavior)

Cette section couvre le comportement UAC hors dialog.

8.1.1 Génération de la requête (Generating the Request)

Une requête SIP valide formulée par un UAC DOIT, au minimum, contenir les header fields suivants : To, From, CSeq, Call-ID, Max-Forwards et Via ; tous ces header fields sont obligatoires dans toutes les requêtes SIP. Ces six header fields sont les blocs de construction fondamentaux d'un message SIP, car ils fournissent conjointement la plupart des services critiques de routage de messages, y compris l'adressage des messages, le routage des réponses, la limitation de la propagation des messages, l'ordonnancement des messages et l'identification unique des transactions. Ces header fields s'ajoutent à la ligne de requête obligatoire, qui contient la méthode, le Request-URI et la version SIP.

Des exemples de requêtes envoyées hors dialog incluent un INVITE pour établir une session (Section 13) et un OPTIONS pour interroger les capacités (Section 11).

8.1.1.1 Request-URI

Le Request-URI initial du message DEVRAIT (SHOULD) être défini à la valeur de l'URI dans le champ To. Une exception notable est la méthode REGISTER ; le comportement pour définir le Request-URI de REGISTER est donné à la Section 10. Il peut également être indésirable, pour des raisons de confidentialité ou de commodité, de définir ces champs à la même valeur (surtout si le UA originaire s'attend à ce que le Request-URI soit modifié pendant le transit).

Dans certaines circonstances spéciales, la présence d'un jeu de routes préexistant (pre-existing route set) peut affecter le Request-URI du message. Un jeu de routes préexistant est un ensemble ordonné d'URI qui identifient une chaîne de serveurs, vers lesquels un UAC enverra les requêtes sortantes qui sont hors d'un dialog. Communément, ils sont configurés sur le UA par un utilisateur ou un fournisseur de services manuellement, ou via un autre mécanisme non-SIP. Lorsqu'un fournisseur souhaite configurer un UA avec un outbound proxy, il est RECOMMANDÉ que cela soit fait en lui fournissant un jeu de routes préexistant avec un seul URI, celui du outbound proxy.

Lorsqu'un jeu de routes préexistant est présent, les procédures pour remplir le Request-URI et le champ Route header détaillées à la Section 12.2.1.1 DOIVENT (MUST) être suivies (même s'il n'y a pas de dialog), en utilisant le Request-URI désiré comme URI de cible distante (remote target URI).

8.1.1.2 To

Le champ To header indique d'abord le destinataire « logique » souhaité de la requête, ou l'address-of-record de l'utilisateur ou de la ressource qui est la cible de cette requête. Cela peut ou non être le destinataire final de la requête. Le champ To header PEUT (MAY) contenir un URI SIP ou SIPS, mais il PEUT également faire usage d'autres schémas d'URI (l'URL tel (RFC 2806 [9]), par exemple) lorsque approprié. Toutes les implémentations SIP DOIVENT (MUST) prendre en charge le schéma d'URI SIP. Toute implémentation qui prend en charge TLS DOIT prendre en charge le schéma d'URI SIPS. Le champ To header permet un nom d'affichage (display name).

Un UAC peut apprendre comment remplir le champ To header pour une requête particulière de plusieurs façons. Généralement, l'utilisateur suggérera le champ To header via une interface humaine, peut-être en saisissant l'URI manuellement ou en le sélectionnant dans une sorte de carnet d'adresses. Fréquemment, l'utilisateur n'entrera pas un URI complet, mais plutôt une chaîne de chiffres ou de lettres (par exemple, « bob »). Il est à la discrétion du UA de choisir comment interpréter cette entrée. Utiliser la chaîne pour former la partie utilisateur (user part) d'un URI SIP implique que le UA souhaite que le nom soit résolu dans le domaine à droite du signe arobase (@) dans l'URI SIP (par exemple, sip:[email protected]). Utiliser la chaîne pour former la partie utilisateur d'un URI SIPS implique que le UA souhaite communiquer de manière sécurisée, et que le nom doit être résolu dans le domaine à droite du signe arobase. Le côté droit (RHS) sera fréquemment le domaine d'origine (home domain) du demandeur, ce qui permet au domaine d'origine de traiter la requête sortante. Cela est utile pour des fonctionnalités comme la « composition abrégée » (speed dial) qui nécessitent l'interprétation de la partie utilisateur dans le domaine d'origine. L'URL tel PEUT être utilisée lorsque le UA ne souhaite pas spécifier le domaine qui doit interpréter un numéro de téléphone saisi par l'utilisateur. Plutôt, chaque domaine à travers lequel la requête passe se verrait offrir cette opportunité. Par exemple, un utilisateur dans un aéroport pourrait se connecter et envoyer des requêtes via un outbound proxy dans l'aéroport. S'ils saisissent « 411 » (c'est le numéro de téléphone pour l'assistance annuaire locale aux États-Unis), cela doit être interprété et traité par le outbound proxy de l'aéroport, pas par le domaine d'origine de l'utilisateur. Dans ce cas, tel:411 serait le bon choix.

Une requête hors dialog NE DOIT PAS (MUST NOT) contenir une balise To ; la balise dans le champ To d'une requête identifie le pair du dialog. Puisqu'aucun dialog n'est établi, aucune balise n'est présente.

Pour plus d'informations sur le champ To header, voir la Section 20.39. Voici un exemple de champ To header valide :

  To: Carol `<sip:[email protected]>`

8.1.1.3 From

Le champ From header indique l'identité logique de l'initiateur de la requête, possiblement l'address-of-record de l'utilisateur. Comme le champ To header, il contient un URI et éventuellement un nom d'affichage. Il est utilisé par les éléments SIP pour déterminer quelles règles de traitement appliquer à une requête (par exemple, le rejet automatique d'appel). En tant que tel, il est très important que l'URI From ne contienne pas d'adresses IP ou le FQDN de l'hôte sur lequel le UA s'exécute, puisque ceux-ci ne sont pas des noms logiques.

Le champ From header permet un nom d'affichage. Un UAC DEVRAIT (SHOULD) utiliser le nom d'affichage « Anonymous », avec un URI syntaxiquement correct mais autrement sans signification (comme sip:[email protected]), si l'identité du client doit rester cachée.

Généralement, la valeur qui remplit le champ From header dans les requêtes générées par un UA particulier est pré-provisionnée par l'utilisateur ou par les administrateurs du domaine local de l'utilisateur. Si un UA particulier est utilisé par plusieurs utilisateurs, il pourrait avoir des profils commutables qui incluent un URI correspondant à l'identité de l'utilisateur profilé. Les destinataires de requêtes peuvent authentifier l'initiateur d'une requête afin de vérifier qu'ils sont bien ceux que leur champ From header prétend être (voir la Section 22 pour plus sur l'authentification).

Le champ From DOIT (MUST) contenir un nouveau paramètre « tag », choisi par le UAC. Voir la Section 19.3 pour les détails sur le choix d'une balise.

Pour plus d'informations sur le champ From header, voir la Section 20.20. Exemples :

  From: "Bob" `<sips:[email protected]>` ;tag=a48s
  From: sip:[email protected];tag=887s
  From: Anonymous `<sip:[email protected]>`;tag=hyh8

8.1.1.4 Call-ID

Le champ Call-ID header agit comme un identifiant unique pour regrouper une série de messages. Il DOIT (MUST) être le même pour toutes les requêtes et réponses envoyées par l'un ou l'autre UA dans un dialog. Il DEVRAIT (SHOULD) être le même dans chaque enregistrement d'un UA.

Dans une nouvelle requête créée par un UAC hors de tout dialog, le champ Call-ID header DOIT (MUST) être sélectionné par le UAC comme un identifiant globalement unique dans l'espace et le temps à moins de dérogation par un comportement spécifique à la méthode. Tous les UA SIP doivent avoir un moyen de garantir que les champs Call-ID qu'ils produisent ne seront pas générés par mégarde par un autre UA. Notez que lorsque des requêtes sont réessayées après certaines réponses d'échec qui sollicitent un amendement à la requête (par exemple, un défi d'authentification), ces requêtes réessayées ne sont pas considérées comme de nouvelles requêtes, et ne nécessitent donc pas de nouveaux champs Call-ID ; voir la Section 8.1.3.5.

L'utilisation d'identificateurs cryptographiquement aléatoires (RFC 1750 [12]) dans la génération des Call-ID est RECOMMANDÉE. Les implémentations PEUVENT (MAY) utiliser la forme « localid@host ». Les Call-ID sont sensibles à la casse et sont simplement comparés octet par octet.

  L'utilisation d'identificateurs cryptographiquement aléatoires fournit une certaine protection contre le détournement de session et réduit la probabilité de collisions involontaires de Call-ID.

Aucun provisionnement ou interface humaine n'est requis pour la sélection de la valeur du champ Call-ID header pour une requête.

Pour plus d'informations sur le champ Call-ID header, voir la Section 20.8.

Exemple :

  Call-ID: [email protected]

8.1.1.5 CSeq

Le champ CSeq header sert à identifier et ordonner les transactions. Il consiste en un numéro de séquence et une méthode. La méthode DOIT (MUST) correspondre à celle de la requête. Pour les requêtes hors dialog non-REGISTER, la valeur du numéro de séquence est arbitraire. La valeur du numéro de séquence DOIT (MUST) être exprimable comme un entier non signé de 32 bits et DOIT être inférieure à 2**31. Tant qu'elle suit les directives ci-dessus, un client peut utiliser n'importe quel mécanisme pour sélectionner les valeurs du champ CSeq header.

La Section 12.2.1.1 discute de la construction du CSeq pour les requêtes dans un dialog.

Exemple :

  CSeq: 4711 INVITE

8.1.1.6 Max-Forwards

Le champ Max-Forwards header sert à limiter le nombre de sauts qu'une requête peut traverser sur le chemin vers sa destination. Il consiste en un entier qui est décrémenté de un à chaque saut. Si la valeur Max-Forwards atteint 0 avant que la requête n'atteigne sa destination, elle sera rejetée avec une réponse d'erreur 483 (Too Many Hops).

Un UAC DOIT (MUST) insérer un champ Max-Forwards header dans chaque requête qu'il émet avec une valeur qui DEVRAIT (SHOULD) être 70. Ce nombre a été choisi suffisamment grand pour garantir qu'une requête ne soit pas abandonnée dans un réseau SIP quelconque en l'absence de boucles, mais pas si grand qu'il consomme des ressources proxy lorsqu'une boucle se produit. Des valeurs plus faibles devraient être utilisées avec prudence et seulement dans les réseaux dont la topologie est connue du UA.

8.1.1.7 Via

Le champ Via header indique le transport utilisé pour la transaction et identifie l'emplacement où la réponse doit être envoyée. Une valeur de champ Via header n'est ajoutée qu'après que le transport qui sera utilisé pour atteindre le prochain saut a été sélectionné (ce qui peut impliquer l'utilisation des procédures de [4]).

Lorsque le UAC crée une requête, il DOIT (MUST) insérer un Via dans cette requête. Le nom de protocole et la version de protocole dans le champ header DOIVENT (MUST) être respectivement SIP et 2.0. La valeur du champ Via header DOIT (MUST) contenir un paramètre branch. Ce paramètre est utilisé pour identifier la transaction créée par cette requête. Ce paramètre est utilisé à la fois par le client et le serveur.

La valeur du paramètre branch DOIT (MUST) être unique dans l'espace et le temps pour toutes les requêtes envoyées par le UA. Les exceptions à cette règle sont CANCEL et ACK pour les réponses non-2xx. Comme discuté ci-dessous, une requête CANCEL aura la même valeur de paramètre branch que la requête qu'elle annule. Comme discuté à la Section 17.1.1.3, un ACK pour une réponse non-2xx aura également le même identifiant branch que l'INVITE dont il accuse réception.

  La propriété d'unicité du paramètre branch ID, pour faciliter son utilisation comme identifiant de transaction, ne faisait pas partie de la RFC 2543.

L'identifiant branch inséré par un élément conforme à cette spécification DOIT (MUST) toujours commencer par les caractères « z9hG4bK ». Ces 7 caractères sont utilisés comme un magic cookie (7 est jugé suffisant pour garantir qu'une implémentation RFC 2543 plus ancienne ne choisirait pas une telle valeur), afin que les serveurs recevant la requête puissent déterminer que l'identifiant branch a été construit de la manière décrite par cette spécification (c'est-à-dire, globalement unique). Au-delà de cette exigence, le format précis du jeton branch est défini par l'implémentation.

Les composants maddr, ttl et sent-by de l'en-tête Via seront définis lorsque la requête est traitée par la couche transport (Section 18).

Le traitement Via pour les proxys est décrit à la Section 16.6 Item 8 et Section 16.7 Item 3.

8.1.1.8 Contact

Le champ Contact header fournit un URI SIP ou SIPS qui peut être utilisé pour contacter cette instance spécifique du UA pour les requêtes suivantes. Le champ Contact header DOIT (MUST) être présent et contenir exactement un URI SIP ou SIPS dans toute requête qui peut résulter en l'établissement d'un dialog. Pour les méthodes définies dans cette spécification, cela inclut seulement la requête INVITE. Pour ces requêtes, la portée du Contact est globale. C'est-à-dire, la valeur du champ Contact header contient l'URI où le UA souhaite recevoir des requêtes, et cet URI DOIT (MUST) être valide même s'il est utilisé dans des requêtes suivantes hors de tout dialog.

Si le Request-URI ou la valeur du champ Route header supérieur contient un URI SIPS, le champ Contact header DOIT (MUST) également contenir un URI SIPS.

Pour plus d'informations sur le champ Contact header, voir la Section 20.10.

8.1.1.9 Supported et Require

Si le UAC prend en charge des extensions à SIP qui peuvent être appliquées par le serveur à la réponse, le UAC DEVRAIT (SHOULD) inclure un champ Supported header dans la requête listant les balises d'option (Section 19.2) pour ces extensions.

Les balises d'option listées NE DOIVENT (MUST NOT) se référer qu'à des extensions définies dans des RFC de standards-track. Cela est pour empêcher les serveurs d'insister pour que les clients implémentent des fonctionnalités non standard définies par le vendeur afin de recevoir le service. Les extensions définies par des RFC expérimentales et informatives sont explicitement exclues de l'utilisation avec le champ Supported header dans une requête, puisqu'elles sont aussi souvent utilisées pour documenter des extensions définies par le vendeur.

Si le UAC souhaite insister pour qu'un UAS comprenne une extension que le UAC appliquera à la requête afin de la traiter, il DOIT (MUST) insérer un champ Require header dans la requête listant la balise d'option pour cette extension. Si le UAC souhaite appliquer une extension à la requête et insister pour que tous les proxys traversés comprennent cette extension, il DOIT (MUST) insérer un champ Proxy-Require header dans la requête listant la balise d'option pour cette extension.

Comme avec le champ Supported header, les balises d'option dans les champs Require et Proxy-Require NE DOIVENT (MUST NOT) se référer qu'à des extensions définies dans des RFC de standards-track.

8.1.1.10 Composants de message supplémentaires (Additional Message Components)

Après qu'une nouvelle requête a été créée, et que les champs header décrits ci-dessus ont été correctement construits, tous les champs header optionnels supplémentaires sont ajoutés, de même que les champs header spécifiques à la méthode.

Les requêtes SIP PEUVENT (MAY) contenir un message-body encodé MIME. Indépendamment du type de corps qu'une requête contient, certains champs header doivent être formulés pour caractériser le contenu du corps. Pour plus d'informations sur ces champs header, voir les Sections 20.11 à 20.15.

8.1.2 Envoi de la requête (Sending the Request)

La destination de la requête est ensuite calculée. Sauf indication contraire d'une politique locale, la destination DOIT (MUST) être déterminée en appliquant les procédures DNS décrites dans [4] comme suit. Si le premier élément dans le jeu de routes indiquait un routeur strict (strict router) (résultant en la formation de la requête comme décrit à la Section 12.2.1.1), les procédures DOIVENT (MUST) être appliquées au Request-URI de la requête. Sinon, les procédures sont appliquées à la première valeur de champ Route header dans la requête (si elle existe), ou au Request-URI de la requête s'il n'y a pas de champ Route header présent. Ces procédures produisent un ensemble ordonné d'adresse, port et transports à essayer. Indépendamment de l'URI utilisé comme entrée aux procédures de [4], si le Request-URI spécifie une ressource SIPS, le UAC DOIT (MUST) suivre les procédures de [4] comme si l'URI d'entrée était un URI SIPS.

La politique locale PEUT (MAY) spécifier un ensemble alternatif de destinations à essayer. Si le Request-URI contient un URI SIPS, toute destination alternative DOIT (MUST) être contactée avec TLS. Au-delà de cela, il n'y a pas de restrictions sur les destinations alternatives si la requête ne contient pas de champ Route header. Cela fournit une alternative simple à un jeu de routes préexistant comme moyen de spécifier un outbound proxy. Cependant, cette approche pour configurer un outbound proxy n'est PAS RECOMMANDÉE (NOT RECOMMENDED) ; un jeu de routes préexistant avec un seul URI DEVRAIT (SHOULD) être utilisé à la place. Si la requête contient un champ Route header, la requête DEVRAIT (SHOULD) être envoyée aux emplacements dérivés de sa valeur la plus haute, mais PEUT (MAY) être envoyée à tout serveur que le UA est certain d'honorer les politiques Route et Request-URI spécifiées dans ce document (par opposition à celles de la RFC 2543). En particulier, un UAC configuré avec un outbound proxy DEVRAIT (SHOULD) tenter d'envoyer la requête à l'emplacement indiqué dans la première valeur de champ Route header au lieu d'adopter la politique d'envoi de tous les messages au outbound proxy.

  Cela garantit que les outbound proxys qui n'ajoutent pas de valeurs de champ Record-Route s'écarteront du chemin des requêtes suivantes. Cela permet aux points de terminaison qui ne peuvent pas résoudre le premier URI Route de déléguer cette tâche à un outbound proxy.

Le UAC DEVRAIT (SHOULD) suivre les procédures définies dans [4] pour les éléments avec état, en essayant chaque adresse jusqu'à ce qu'un serveur soit contacté. Chaque essai constitue une nouvelle transaction, et par conséquent chacun porte une valeur de champ Via header supérieure différente avec un nouveau paramètre branch. En outre, la valeur de transport dans le champ Via header est définie au transport quelconque déterminé pour le serveur cible.

8.1.3 Traitement des réponses (Processing Responses)

Les réponses sont d'abord traitées par la couche transport puis transmises vers la couche transaction. La couche transaction effectue son traitement puis transmet la réponse vers le TU. La majorité du traitement des réponses dans le TU est spécifique à la méthode. Cependant, il y a quelques comportements généraux indépendants de la méthode.

8.1.3.1 Erreurs de la couche transaction (Transaction Layer Errors)

Dans certains cas, la réponse renvoyée par la couche transaction ne sera pas un message SIP, mais plutôt une erreur de couche transaction. Lorsqu'une erreur de temporisation (timeout error) est reçue de la couche transaction, elle DOIT (MUST) être traitée comme si un code d'état 408 (Request Timeout) avait été reçu. Si une erreur de transport fatale est rapportée par la couche transport (généralement, due à des erreurs ICMP fatales en UDP ou à des échecs de connexion en TCP), la condition DOIT (MUST) être traitée comme un code d'état 503 (Service Unavailable).

8.1.3.2 Réponses non reconnues (Unrecognized Responses)

Un UAC DOIT (MUST) traiter toute réponse finale qu'il ne reconnaît pas comme équivalente au code de réponse x00 de cette classe, et DOIT (MUST) être capable de traiter le code de réponse x00 pour toutes les classes. Par exemple, si un UAC reçoit un code de réponse non reconnu 431, il peut supposer en toute sécurité qu'il y avait un problème avec sa requête et traiter la réponse comme s'il avait reçu un code de réponse 400 (Bad Request). Un UAC DOIT (MUST) traiter toute réponse provisoire différente de 100 qu'il ne reconnaît pas comme 183 (Session Progress). Un UAC DOIT (MUST) être capable de traiter les réponses 100 et 183.

8.1.3.3 Vias

Si plus d'une valeur de champ Via header est présente dans une réponse, le UAC DEVRAIT (SHOULD) ignorer le message.

  La présence de valeurs de champ Via header supplémentaires précédant l'initiateur de la requête suggère que le message a été mal routé ou possiblement corrompu.

8.1.3.4 Traitement des réponses 3xx (Processing 3xx Responses)

Lors de la réception d'une réponse de redirection (par exemple, un code d'état de réponse 301), les clients DEVRAIENT (SHOULD) utiliser les URI dans le champ Contact header pour formuler une ou plusieurs nouvelles requêtes basées sur la requête redirigée. Ce processus est similaire à celui d'un proxy effectuant une récursion sur une réponse de classe 3xx comme détaillé dans les Sections 16.5 et 16.6. Un client commence avec un ensemble cible (target set) initial contenant exactement un URI, le Request-URI de la requête originale. Si un client souhaite formuler de nouvelles requêtes basées sur une réponse de classe 3xx à cette requête, il place les URI à essayer dans l'ensemble cible. Sous réserve des restrictions de cette spécification, un client peut choisir quels URI Contact il place dans l'ensemble cible. Comme avec la récursion de proxy, un client traitant les réponses de classe 3xx NE DOIT PAS (MUST NOT) ajouter un URI donné à l'ensemble cible plus d'une fois. Si la requête originale avait un URI SIPS dans le Request-URI, le client PEUT (MAY) choisir de récursivement rediriger vers un URI non-SIPS, mais DEVRAIT (SHOULD) informer l'utilisateur de la redirection vers un URI non sécurisé.

  Toute nouvelle requête peut recevoir elle-même des réponses 3xx contenant l'URI original comme contact. Deux emplacements peuvent être configurés pour se rediriger l'un l'autre. Placer tout URI donné dans l'ensemble cible une seule fois empêche les boucles de redirection infinis.

À mesure que l'ensemble cible croît, le client PEUT (MAY) générer de nouvelles requêtes vers les URI dans n'importe quel ordre. Un mécanisme courant est d'ordonner l'ensemble par la valeur du paramètre « q » de la valeur du champ Contact header. Les requêtes vers les URI PEUVENT (MAY) être générées en série ou en parallèle. Une approche consiste à traiter en série des groupes de valeurs q décroissantes et à traiter en parallèle les URI dans chaque groupe de valeur q. Une autre consiste à n'effectuer que le traitement en série dans l'ordre de valeur q décroissante, en choisissant arbitrairement entre les contacts de valeur q égale.

Si contacter une adresse dans la liste résulte en un échec, comme défini au paragraphe suivant, l'élément passe à l'adresse suivante dans la liste, jusqu'à ce que la liste soit épuisée. Si la liste est épuisée, alors la requête a échoué.

Les échecs DEVRAIENT (SHOULD) être détectés via des codes de réponse d'échec (codes supérieurs à 399) ; pour les erreurs réseau, la transaction client signalera tout échec de la couche transport à l'utilisateur de transaction. Notez que certains codes de réponse (détaillés en 8.1.3.5) indiquent que la requête peut être réessayée ; les requêtes qui sont réitérées ne devraient pas être considérées comme des échecs.

Lorsqu'un échec pour une adresse de contact particulière est reçu, le client DEVRAIT (SHOULD) essayer l'adresse de contact suivante. Cela impliquera la création d'une nouvelle transaction client pour délivrer une nouvelle requête.

Afin de créer une requête basée sur une adresse de contact dans une réponse 3xx, un UAC DOIT (MUST) copier l'URI entier de l'ensemble cible dans le Request-URI, à l'exception des paramètres URI « method-param » et « header » (voir la Section 19.1.1 pour une définition de ces paramètres). Il utilise les paramètres « header » pour créer des valeurs de champ header pour la nouvelle requête, en écrasant les valeurs de champ header associées à la requête redirigée conformément aux directives de la Section 19.1.5.

Notez que dans certains cas, les champs header qui ont été communiqués dans l'adresse de contact peuvent plutôt s'ajouter aux champs de requête header existants dans la requête redirigée originale. Comme règle générale, si le champ header peut accepter une liste de valeurs séparées par des virgules, alors la nouvelle valeur de champ header PEUT (MAY) être ajoutée à toutes les valeurs existantes dans la requête redirigée originale. Si le champ header n'accepte pas plusieurs valeurs, la valeur dans la requête redirigée originale PEUT (MAY) être écrasée par la valeur de champ header communiquée dans l'adresse de contact. Par exemple, si une adresse de contact est retournée avec la valeur suivante :

  sip:user@host?Subject=foo&Call-Info=`\`http://www.foo.com\``

Alors tout champ Subject header dans la requête redirigée originale est écrasé, mais l'URL HTTP est simplement ajoutée à toutes les valeurs de champ Call-Info header existantes.

Il est RECOMMANDÉ que le UAC réutilise le même To, From et Call-ID utilisés dans la requête redirigée originale, mais le UAC PEUT (MAY) aussi choisir de mettre à jour la valeur du champ Call-ID header pour les nouvelles requêtes, par exemple.

Enfin, une fois la nouvelle requête construite, elle est envoyée en utilisant une nouvelle transaction client, et par conséquent DOIT (MUST) avoir un nouvel identifiant branch dans le champ Via supérieur comme discuté à la Section 8.1.1.7.

À tous autres égards, les requêtes envoyées à la réception d'une réponse de redirection DEVRAIENT (SHOULD) réutiliser les champs header et les corps de la requête originale.

Dans certains cas, les valeurs de champ Contact header peuvent être mises en cache au UAC temporairement ou en permanence selon le code d'état reçu et la présence d'un intervalle d'expiration ; voir les Sections 21.3.2 et 21.3.3.

8.1.3.5 Traitement des réponses 4xx (Processing 4xx Responses)

Certains codes de réponse 4xx requièrent un traitement UA spécifique, indépendant de la méthode.

Si une réponse 401 (Unauthorized) ou 407 (Proxy Authentication Required) est reçue, le UAC DEVRAIT (SHOULD) suivre les procédures d'autorisation des Sections 22.2 et 22.3 pour réessayer la requête avec des identifiants.

Si une réponse 413 (Request Entity Too Large) est reçue (Section 21.4.11), la requête contenait un corps plus long que ce que le UAS était disposé à accepter. Si possible, le UAC DEVRAIT (SHOULD) réessayer la requête, en omettant le corps ou en utilisant un corps de longueur plus petite.

Si une réponse 415 (Unsupported Media Type) est reçue (Section 21.4.13), la requête contenait des types de média non pris en charge par le UAS. Le UAC DEVRAIT (SHOULD) réessayer l'envoi de la requête, cette fois en utilisant seulement du contenu avec les types listés dans le champ Accept header de la réponse, avec les encodages listés dans le champ Accept-Encoding header de la réponse, et avec les langues listées dans le Accept-Language de la réponse.

Si une réponse 416 (Unsupported URI Scheme) est reçue (Section 21.4.14), le Request-URI utilisait un schéma d'URI non pris en charge par le serveur. Le client DEVRAIT (SHOULD) réessayer la requête, cette fois en utilisant un URI SIP.

Si une réponse 420 (Bad Extension) est reçue (Section 21.4.15), la requête contenait un champ Require ou Proxy-Require listant une balise d'option pour une fonctionnalité non prise en charge par un proxy ou UAS. Le UAC DEVRAIT (SHOULD) réessayer la requête, cette fois en omettant toutes les extensions listées dans le champ Unsupported header de la réponse.

Dans tous les cas ci-dessus, la requête est réessayée en créant une nouvelle requête avec les modifications appropriées. Cette nouvelle requête constitue une nouvelle transaction et DEVRAIT (SHOULD) avoir la même valeur de Call-ID, To et From de la requête précédente, mais le CSeq devrait contenir un nouveau numéro de séquence supérieur d'une unité au précédent.

Avec d'autres réponses 4xx, y compris celles encore à définir, un réessai peut ou non être possible selon la méthode et le cas d'utilisation.

8.2 Comportement UAS (UAS Behavior)

Lorsqu'une requête hors dialog est traitée par un UAS, il y a un ensemble de règles de traitement qui sont suivies, indépendamment de la méthode. La Section 12 donne des conseils sur la façon dont un UAS peut dire si une requête est à l'intérieur ou à l'extérieur d'un dialog.

Notez que le traitement de la requête est atomique. Si une requête est acceptée, tous les changements d'état qui y sont associés DOIVENT (MUST) être exécutés. Si elle est rejetée, tous les changements d'état NE DOIVENT PAS (MUST NOT) être exécutés.

Les UAS DEVRAIENT (SHOULD) traiter les requêtes dans l'ordre des étapes qui suivent dans cette section (c'est-à-dire, en commençant par l'authentification, puis en inspectant la méthode, les champs header, et ainsi de suite tout au long du reste de cette section).

8.2.1 Inspection de la méthode (Method Inspection)

Une fois qu'une requête est authentifiée (ou que l'authentification est sautée), le UAS DOIT (MUST) inspecter la méthode de la requête. Si le UAS reconnaît mais ne prend pas en charge la méthode d'une requête, il DOIT (MUST) générer une réponse 405 (Method Not Allowed). Les procédures pour générer des réponses sont décrites à la Section 8.2.6. Le UAS DOIT (MUST) aussi ajouter un champ Allow header à la réponse 405 (Method Not Allowed). Le champ Allow header DOIT (MUST) lister l'ensemble des méthodes prises en charge par le UAS générant le message. Le champ Allow header est présenté à la Section 20.5.

Si la méthode est celle prise en charge par le serveur, le traitement continue.

8.2.2 Inspection de l'en-tête (Header Inspection)

Si un UAS ne comprend pas un champ header dans une requête (c'est-à-dire, le champ header n'est pas défini dans cette spécification ou dans une extension prise en charge), le serveur DOIT (MUST) ignorer ce champ header et continuer le traitement du message. Un UAS DEVRAIT (SHOULD) ignorer tout champ header mal formé qui n'est pas nécessaire au traitement des requêtes.

8.2.2.1 To et Request-URI

Le champ To header identifie le destinataire original de la requête désigné par l'utilisateur identifié dans le champ From. Le destinataire original peut ou non être le UAS traitant la requête, en raison d'un transfert d'appel ou d'autres opérations proxy. Un UAS PEUT (MAY) appliquer toute politique qu'il souhaite pour déterminer s'il accepte les requêtes lorsque le champ To header n'est pas l'identité du UAS. Cependant, il est RECOMMANDÉ qu'un UAS accepte les requêtes même s'il ne reconnaît pas le schéma d'URI (par exemple, un URI tel:) dans le champ To header, ou si le champ To header n'adresse pas un utilisateur connu ou actuel de ce UAS. Si, d'un autre côté, le UAS décide de rejeter la requête, il DEVRAIT (SHOULD) générer une réponse avec un code d'état 403 (Forbidden) et la passer à la transaction serveur pour transmission.

Cependant, le Request-URI identifie le UAS qui doit traiter la requête. Si le Request-URI utilise un schéma non pris en charge par le UAS, il DEVRAIT (SHOULD) rejeter la requête avec une réponse 416 (Unsupported URI Scheme). Si le Request-URI n'identifie pas une adresse que le UAS est disposé à accepter les requêtes pour, il DEVRAIT (SHOULD) rejeter la requête avec une réponse 404 (Not Found). Typiquement, un UA qui utilise la méthode REGISTER pour lier son address-of-record à une adresse de contact spécifique verra des requêtes dont le Request-URI est égal à cette adresse de contact. D'autres sources potentielles de Request-URI reçus incluent les champs Contact header des requêtes et réponses envoyées par le UA qui établissent ou rafraîchissent les dialogs.

8.2.2.2 Requêtes fusionnées (Merged Requests)

Si la requête n'a pas de balise dans le champ To header, le UAS core DOIT (MUST) vérifier la requête par rapport aux transactions en cours. Si la balise From, le Call-ID et le CSeq correspondent exactement à ceux associés à une transaction en cours, mais la requête ne correspond pas à cette transaction (basé sur les règles de correspondance de la Section 17.2.3), le UAS core DEVRAIT (SHOULD) générer une réponse 482 (Loop Detected) et la passer à la transaction serveur.

  La même requête est arrivée au UAS plus d'une fois, suivant des chemins différents, très probablement en raison d'un forking. Le UAS traite la première de ces requêtes reçues et répond 482 (Loop Detected) au reste d'entre elles.

8.2.2.3 Require

En supposant que le UAS décide qu'il est l'élément approprié pour traiter la requête, il examine le champ Require header, si présent.

Le champ Require header est utilisé par un UAC pour indiquer à un UAS les extensions SIP que le UAC attend que le UAS prenne en charge afin de traiter correctement la requête. Son format est décrit à la Section 20.32. Si un UAS ne comprend pas une balise d'option listée dans un champ Require header, il DOIT (MUST) répondre en générant une réponse avec le code d'état 420 (Bad Extension). Le UAS DOIT (MUST) ajouter un champ Unsupported header, et lister dans celui-ci les options qu'il ne comprend pas parmi celles du champ Require header de la requête.

Notez que Require et Proxy-Require NE DOIVENT PAS (MUST NOT) être utilisés dans une requête SIP CANCEL, ou dans une requête ACK envoyée pour une réponse non-2xx. Ces champs header DOIVENT (MUST) être ignorés s'ils sont présents dans ces requêtes.

Une requête ACK pour une réponse 2xx NE DOIT (MUST) contenir que les valeurs Require et Proxy-Require présentes dans la requête initiale.

Exemple :

  UAC->UAS:   INVITE sip:[email protected] SIP/2.0
              Require: 100rel

  UAS->UAC:   SIP/2.0 420 Bad Extension
              Unsupported: 100rel

  Ce comportement garantit que l'interaction client-serveur se déroulera sans délai lorsque toutes les options sont comprises des deux côtés, et ne ralentira que si des options ne sont pas comprises (comme dans l'exemple ci-dessus). Pour une paire client-serveur bien appariée, l'interaction progresse rapidement, économisant un aller-retour souvent requis par les mécanismes de négociation. De plus, cela supprime l'ambiguïté lorsque le client requiert des fonctionnalités que le serveur ne comprend pas. Certaines fonctionnalités, telles que les champs de gestion d'appel, ne présentent d'intérêt que pour les systèmes finaux.

8.2.3 Traitement du contenu (Content Processing)

En supposant que le UAS comprend toutes les extensions requises par le client, le UAS examine le corps du message, et les champs header qui le décrivent. S'il y a des corps dont le type (indiqué par le Content-Type), la langue (indiquée par le Content-Language) ou l'encodage (indiqué par le Content-Encoding) ne sont pas compris, et que cette partie de corps n'est pas optionnelle (comme indiqué par le champ Content-Disposition header), le UAS DOIT (MUST) rejeter la requête avec une réponse 415 (Unsupported Media Type). La réponse DOIT (MUST) contenir un champ Accept header listant les types de tous les corps qu'il comprend, au cas où la requête contiendrait des corps de types non pris en charge par le UAS. Si la requête contenait des encodages de contenu non compris par le UAS, la réponse DOIT (MUST) contenir un champ Accept-Encoding header listant les encodages compris par le UAS. Si la requête contenait un contenu avec des langues non comprises par le UAS, la réponse DOIT (MUST) contenir un champ Accept-Language header indiquant les langues comprises par le UAS. Au-delà de ces vérifications, la gestion du corps dépend de la méthode et du type. Pour plus d'informations sur le traitement des champs header spécifiques au contenu, voir la Section 7.4 ainsi que les Sections 20.11 à 20.15.

8.2.4 Application des extensions (Applying Extensions)

Un UAS qui souhaite appliquer une extension lors de la génération de la réponse NE DOIT PAS (MUST NOT) le faire à moins que la prise en charge de cette extension ne soit indiquée dans le champ Supported header de la requête. Si l'extension désirée n'est pas prise en charge, le serveur DEVRAIT (SHOULD) s'appuyer uniquement sur le SIP de base et toute autre extension prise en charge par le client. Dans de rares circonstances, où le serveur ne peut pas traiter la requête sans l'extension, le serveur PEUT (MAY) envoyer une réponse 421 (Extension Required). Cette réponse indique que la réponse appropriée ne peut pas être générée sans la prise en charge d'une extension spécifique. L'extension(s) nécessaire(s) DOIVENT (MUST) être incluses dans un champ Require header dans la réponse. Ce comportement n'est PAS RECOMMANDÉ (NOT RECOMMENDED), car il cassera généralement l'interopérabilité.

Toutes les extensions appliquées à une réponse non-421 DOIVENT (MUST) être listées dans un champ Require header inclus dans la réponse. Bien sûr, le serveur NE DOIT PAS (MUST NOT) appliquer des extensions non listées dans le champ Supported header de la requête. En conséquence, le champ Require header dans une réponse ne contiendra que des balises d'option définies dans des RFC de standards-track.

8.2.5 Traitement de la requête (Processing the Request)

En supposant que toutes les vérifications des sous-sections précédentes sont passées, le traitement UAS devient spécifique à la méthode. La Section 10 couvre la requête REGISTER, la Section 11 couvre la requête OPTIONS, la Section 13 couvre la requête INVITE, et la Section 15 couvre la requête BYE.

8.2.6 Génération de la réponse (Generating the Response)

Lorsqu'un UAS souhaite construire une réponse à une requête, il suit les procédures générales détaillées dans les sous-sections suivantes. Des comportements supplémentaires spécifiques au code de réponse en question, qui ne sont pas détaillés dans cette section, peuvent aussi être requis.

Une fois toutes les procédures associées à la création d'une réponse terminées, le UAS rend la réponse à la transaction serveur de laquelle il a reçu la requête.

8.2.6.1 Envoi d'une réponse provisoire (Sending a Provisional Response)

Une directive largement indépendante de la méthode pour la génération de réponses est que les UAS NE DEVRAIENT PAS (SHOULD NOT) émettre une réponse provisoire pour une requête non-INVITE. Plutôt, les UAS DEVRAIENT (SHOULD) générer une réponse finale à une requête non-INVITE dès que possible.

Lorsqu'une réponse 100 (Trying) est générée, tout champ Timestamp header présent dans la requête DOIT (MUST) être copié dans cette réponse 100 (Trying). S'il y a un délai dans la génération de la réponse, le UAS DEVRAIT (SHOULD) ajouter une valeur de délai dans la valeur Timestamp de la réponse. Cette valeur DOIT (MUST) contenir la différence entre le temps d'envoi de la réponse et la réception de la requête, mesurée en secondes.

8.2.6.2 En-têtes et balises (Headers and Tags)

Le champ From de la réponse DOIT (MUST) être égal au champ From header de la requête. Le champ Call-ID header de la réponse DOIT (MUST) être égal au champ Call-ID header de la requête. Le champ CSeq header de la réponse DOIT (MUST) être égal au champ CSeq de la requête. Les valeurs du champ Via header dans la réponse DOIVENT (MUST) être égales aux valeurs du champ Via header dans la requête et DOIVENT maintenir le même ordre.

Si une requête contenait une balise To dans la requête, le champ To header dans la réponse DOIT (MUST) être égal à celui de la requête. Cependant, si le champ To header dans la requête ne contenait pas de balise, l'URI dans le champ To header dans la réponse DOIT (MUST) être égal à l'URI dans le champ To header ; de plus, le UAS DOIT (MUST) ajouter une balise au champ To header dans la réponse (à l'exception de la réponse 100 (Trying), dans laquelle une balise PEUT (MAY) être présente). Cela sert à identifier le UAS qui répond, résultant possiblement en un composant d'un ID de dialog. La même balise DOIT (MUST) être utilisée pour toutes les réponses à cette requête, tant finales que provisoires (encore une fois à l'exception du 100 (Trying)). Les procédures pour la génération de balises sont définies à la Section 19.3.

8.2.7 Comportement UAS sans état (Stateless UAS Behavior)

Un UAS sans état (stateless UAS) est un UAS qui ne maintient pas l'état de transaction. Il répond normalement aux requêtes, mais ignore tout état qui serait ordinairement retenu par un UAS après l'envoi d'une réponse. Si un UAS sans état reçoit une retransmission d'une requête, il régénère la réponse et la renvoie, comme s'il répondait à la première instance de la requête. Un UAS ne peut pas être sans état à moins que le traitement de la requête pour cette méthode ne résulte toujours dans la même réponse si les requêtes sont identiques. Cela exclut, par exemple, les registrars sans état. Les UAS sans état n'utilisent pas de couche transaction ; ils reçoivent les requêtes directement de la couche transport et envoient les réponses directement à la couche transport.

Le rôle de UAS sans état est principalement nécessaire pour gérer les requêtes non authentifiées pour lesquelles une réponse de défi est émise. Si les requêtes non authentifiées étaient traitées avec état, alors des inondations malveillantes de requêtes non authentifiées pourraient créer d'énormes quantités d'état de transaction qui pourraient ralentir ou arrêter complètement le traitement d'appel dans un UAS, créant effectivement une condition de déni de service ; pour plus d'informations voir la Section 26.1.5.

Les comportements les plus importants d'un UAS sans état sont les suivants :

  o  Un UAS sans état NE DOIT PAS (MUST NOT) envoyer de réponses provisoires (1xx).

  o  Un UAS sans état NE DOIT PAS (MUST NOT) retransmettre des réponses.

  o  Un UAS sans état DOIT (MUST) ignorer les requêtes ACK.

  o  Un UAS sans état DOIT (MUST) ignorer les requêtes CANCEL.

  o  Les balises To header DOIVENT (MUST) être générées pour les réponses d'une manière sans état - d'une manière qui générera la même balise pour la même requête de manière cohérente. Pour des informations sur la construction de balise voir la Section 19.3.

À tous autres égards, un UAS sans état se comporte de la même manière qu'un UAS avec état. Un UAS peut fonctionner dans un mode avec ou sans état pour chaque nouvelle requête.

8.3 Serveurs de redirection (Redirect Servers)

Dans certaines architectures, il peut être souhaitable de réduire la charge de traitement sur les serveurs proxy responsables du routage des requêtes, et d'améliorer la robustesse du chemin de signalisation, en s'appuyant sur la redirection.

La redirection permet aux serveurs de pousser les informations de routage pour une requête dans une réponse au client, s'ôtant ainsi de la boucle de messagerie supplémentaire pour cette transaction tout en aidant encore à localiser la cible de la requête. Lorsque l'initiateur de la requête reçoit la redirection, il enverra une nouvelle requête basée sur l'URI (ou les URI) qu'il a reçue. En propageant les URI du cœur du réseau vers ses bords, la redirection permet une évolutivité considérable du réseau.

Un serveur de redirection est constitué logiquement d'une couche de transaction serveur et d'un utilisateur de transaction qui a accès à un service de localisation de quelque sorte (voir la Section 10 pour plus sur les registrars et services de localisation). Ce service de localisation est effectivement une base de données contenant des correspondances entre un seul URI et un ensemble d'un ou plusieurs emplacements alternatifs où la cible de cet URI peut être trouvée.

Un serveur de redirection n'émet aucune requête SIP propre. Après avoir reçu une requête autre que CANCEL, le serveur refuse la requête ou rassemble la liste des emplacements alternatifs à partir du service de localisation et renvoie une réponse finale de classe 3xx. Pour les requêtes CANCEL bien formées, il DEVRAIT (SHOULD) renvoyer une réponse 2xx. Cette réponse termine la transaction SIP. Le serveur de redirection maintient l'état de transaction pour une transaction SIP entière. Il est de la responsabilité des clients de détecter les boucles de transfert entre serveurs de redirection.

Lorsqu'un serveur de redirection renvoie une réponse 3xx à une requête, il remplit la liste des emplacements alternatifs (un ou plusieurs) dans le champ Contact header. Un paramètre « expires » vers les valeurs du champ Contact header PEUT (MAY) aussi être fourni pour indiquer la durée de vie des données Contact.

Le champ Contact header contient des URI donnant les nouveaux emplacements ou noms d'utilisateur à essayer, ou peut simplement spécifier des paramètres de transport supplémentaires. Une réponse 301 (Moved Permanently) ou 302 (Moved Temporarily) PEUT (MAY) aussi donner le même emplacement et nom d'utilisateur que celui ciblé par la requête initiale mais spécifier des paramètres de transport supplémentaires tels qu'un serveur différent ou une adresse multicast à essayer, ou un changement de transport SIP d'UDP à TCP ou vice versa.

Cependant, les serveurs de redirection NE DOIVENT PAS (MUST NOT) rediriger une requête vers un URI égal à celui dans le Request-URI ; à la place, à condition que l'URI ne pointe pas vers lui-même, le serveur PEUT (MAY) proxyer la requête vers l'URI de destination, ou PEUT (MAY) la rejeter avec un 404.

  Si un client utilise un outbound proxy, et que ce proxy redirige réellement des requêtes, un potentiel de boucles de redirection infinies surgit.

Notez qu'une valeur de champ Contact header PEUT (MAY) aussi référer à une ressource différente de celle initialement appelée. Par exemple, un appel SIP connecté à une passerelle PSTN peut avoir besoin de livrer une annonce d'information spéciale telle que « The number you have dialed has been changed. »

Un champ Contact header de réponse peut contenir tout URI approprié indiquant où la partie appelée peut être jointe, pas limité aux URI SIP. Par exemple, il pourrait contenir des URI pour téléphones, fax ou irc (s'ils étaient définis) ou une URL mailto: (RFC 2368 [32]). La Section 26.4.4 discute des implications et limitations de la redirection d'un URI SIPS vers un URI non-SIPS.

Le paramètre « expires » d'une valeur de champ Contact header indique combien de temps l'URI est valide. La valeur du paramètre est un nombre indiquant des secondes. Si ce paramètre n'est pas fourni, la valeur du champ Expires header détermine combien de temps l'URI est valide. Les valeurs mal formées DEVRAIENT (SHOULD) être traitées comme équivalentes à 3600.

  Cela fournit un niveau modeste de compatibilité ascendante avec la RFC 2543, qui permettait des heures absolues dans ce champ header. Si une heure absolue est reçue, elle sera traitée comme mal formée, puis par défaut à 3600.

Les serveurs de redirection DOIVENT (MUST) ignorer les fonctionnalités qui ne sont pas comprises (y compris les champs header non reconnus, toute balise d'option inconnue dans Require, ou même des noms de méthode) et procéder à la redirection de la requête en question.