Groupe de travail Réseau	G. Camarillo, Ericsson
Request for Comments : 5370	
Catégorie : Sur la voie de la normalisation	
Traduction Claude Brière de L'Isle	octobre 2008

Modèle de transcodage de pont de conférence du protocole d’initialisation de session (SIP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
Le présent document décrit comment invoquer les services de transcodage en utilisant le modèle de pont de conférence. Cette manière d’invocation satisfait les exigences de SIP concernant l’invocation des services de transcodage pour la prise en charge des personnes sourdes, mal-entendantes, et muettes.
Table des matières
1. Introduction	1
2. Terminologie	2
3.  Invocation de l’appelant	2
3.1 Procédures chez l’agent d’utilisateur	2
3.2 Procédures au transcodeur	2
3.3 Exemple	3
3.4 Échec d’établissement de session	4
4. Invocation de l’appelé	5
5. Considérations sur la sécurité	5
6. Contributeurs	5
7. Références	6
7.1 Références normatives	6
7.2 Références pour information	6
Adresse de l’auteur	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction
La [RFC5369] décrit comment deux agents d’utilisateurs (UA, User Agent) SIP [RFC3261] peuvent découvrir des incompatibilités qui les empêchent d’établir une session (par exemple, manque de prise en charge d’un codec commun ou d’un type de support commun). Quand de telles incompatibilités existent, les UA ont besoin d’invoquer des services de transcodage pour réussir à établir la session. Le cadre de transcodage introduit deux modèles pour invoquer les services de transcodage : le modèle de contrôle d’appel par un tiers (3pcc, third-party call control) [RFC4117] et le modèle de pont de conférence. Le présent document spécifie le modèle de pont de conférence.

Dans le modèle de pont de conférence pour l’invocation du transcodage, un serveur de transcodage qui fournit un service de transcodage particulier (par exemple, de parole en texte) se comporte comme un agent d’utilisateur de boucle locale (B2BUA, Back-to-Back User Agent) entre les deux UA et est identifié par un URI. Comme le montre la Figure 1, les deux UA, A et B, échangent de la signalisation et des supports avec le transcodeur T. Les UA n’échangent pas de trafic (de signalisation ou de supports) directement entre eux.

                  +-------+
                  |       |**
                  |   T   |  **
                  |       |\   **
                  +-------+ \\   **
                    ^   *     \\   **
                    |   *       \\   **
                    |   *         SIP  **
                   SIP  *           \\   **
                    |   *             \\   **
                    |   *               \\   **
                    v   *                 \    **
                  +-------+               +-------+
                  |       |               |       |
                  |   A   |               |   B   |
                  |       |               |       |
                  +-------+               +-------+
                   <-SIP-> Signalisation
                   ******* supports

Figure 1 : Modèle de pont de conférence

Les Sections 3 et 4 spécifient respectivement comment l'appelant A ou l'appelé B, peuvent utiliser le modèle de pont de conférence pour invoquer les services de transcodage de T.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

 	3. 	Invocation de l’appelant

L’agent d’utilisateur A doit effectuer deux opérations pour invoquer des services de transcodage auprès de T pour une session entre l’agent d'utilisateur A et l’agent d'utilisateur B. L’agent d’utilisateur A a besoin d’établir une session avec T et de fournir à T l’URI de l’agent d'utilisateur B afin que T puisse générer un INVITE vers l’agent d'utilisateur B.

 	3.1	Procédures chez l’agent d’utilisateur
L’agent d’utilisateur A utilise les procédures de la [RFC5366] pour fournir à T l’URI de B en utilisant le même INVITE qui a établi la session entre A et T. C'est-à-dire, l’agent d'utilisateur A ajoute à l’INVITE une partie de corps dont le type de disposition est recipient-list [RFC5363]. Cette partie de corps consiste en une liste d’URI qui contient un seul URI : l’URI de l’agent d'utilisateur B.

Noter que, comme décrit dans le cadre de transcodage [RFC5369], le modèle de transcodage décrit dans le présent document est modélisé comme un serveur de conférences en deux parties. Par conséquent, le présent document se concentre sur des sessions à deux parties qui ont besoin de transcodage. Des sessions multi-parties peuvent être établies en utilisant des demandes INVITE avec plusieurs URI dans leur corps, comme spécifié dans la [RFC5366].

 	3.2	Procédures au transcodeur
À réception d’un INVITE avec un corps de liste d’URI, le transcodeur suit les procédures de la [RFC5366] pour générer une demande INVITE sur l’URI contenu dans le corps de la liste d’URI. Noter que le transcodeur agit comme un B2BUA, pas comme un mandataire.

De plus, le transcodeur DOIT générer le champ d'en-tête From de la demande INVITE sortante en utilisant la même valeur que le champ d'en-tête From inclus dans la demande INVITE entrante, sous réserve des exigences de confidentialité (voir les [RFC3323] et [RFC3325]) exprimées dans la demande INVITE entrante. Noter que cela ne s’applique pas au paramètre "tag".

La description de session que le transcodeur inclut dans la demande INVITE sortante dépend du type de service de transcodage que fournit ce transcodeur particulier. Par exemple, un transcodeur qui résout des incompatibilités de codec audio va générer une description de session qui fait la liste des codecs audio que le transcodeur prend en charge.

Quand le transcodeur reçoit une réponse finale pour les demandes INVITE sortantes, il génère une nouvelle réponse finale pour la demande INVITE entrante. Cette nouvelle réponse finale DEVRAIT avoir le même code d’état que celle reçue dans la réponse pour la demande INVITE sortante.

Si un transcodeur reçoit une demande INVITE avec une liste d’URI de plus d’un URI, il DEVRAIT retourner une réponse 488 (1 URI maximum permis dans une liste d’URI).

 	3.3	Exemple
La Figure 2 montre le flux de messages pour l’invocation de l'appelant d’un transcodeur T. L'appelant A envoie un INVITE (1) au transcodeur (T) pour établir la session A-T. Suivant les procédures de la [RFC5366], l'appelant A ajoute une partie de corps dont le type de disposition est une liste de receveurs [RFC5363].

        A                           T                           B
        |                           |                           |
        |-----(1) INVITE SDP A----->|                           |
        |                           |                           |
        |<-(2) 183 Session en cours-|                           |
        |                           |-----(3) INVITE SDP TB---->|
        |                           |                           |
        |                           |<-----(4) 200 OK SDP B-----|
        |                           |                           |
        |                           |---------(5) ACK---------->|
        |<----(6) 200 OK SDP TA-----|                           |
        |                           |                           |
        |---------(7) ACK---------->|                           |
        |                           |                           |
        | ************************* | ************************* |
        |**       Support         **|**       Support         **|
        | ************************* | ************************* |
        |                           |                           |

Figure 2 : Invocation réussie d’un transcodeur par l'appelant

L'exemple suivant montre un INVITE avec deux parties de corps : une description de session SDP [RFC4566] et une liste d’URI.

   INVITE sip:transcoder@example.com SIP/2.0
   Via: SIP/2.0/TCP client.chicago.example.com
       ;branch=z9hG4bKhjhs8ass83
   Max-Forwards: 70
   To: Transcoder <sip:transcoder@example.org>
   From: A <sip:A@chicago.example.com>;tag=32331
   Call-ID: d432fa84b4c76e66710
   CSeq: 1 INVITE
   Contact: <sip:A@client.chicago.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
   Allow-Events: dialog
   Accept: application/sdp, message/sipfrag
   Require: recipient-list-invite
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: 556

   --boundary1
   Content-Type: application/sdp

   v=0
   o=example 2890844526 2890842807 IN IP4 chicago.example.com
   s=-
   c=IN IP4 192.0.2.1
   t=0 0
   m=audio 50000 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Disposition: recipient-list

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <entry uri="sip:B@example.org" />
     </list>
   </resource-lists>
   --boundary1--

À réception du INVITE, le transcodeur génère un nouvel INVITE vers l'appelé. Le transcodeur agit comme un B2BUA, pas comme un mandataire. Donc, ce nouvel INVITE (3) appartient à une transaction différente de l’INVITE (1) reçu par le transcodeur.

Quand le transcodeur reçoit une réponse finale (4) de l'appelé, il génère une nouvelle réponse finale (6) pour INVITE (1). Cette nouvelle réponse finale (6) a le même code d’état que celle reçue dans la réponse de l'appelé (4).

 	3.4	Échec d’établissement de session
La Figure 3 montre un flux de messages similaire à celui de la Figure 3. Néanmoins, cette fois l'appelé génère une réponse finale (4) non 2xx. Par conséquent, le transcodeur génère aussi une réponse finale (6) non 2xx vers l'appelant.

   A                           T                           B
   |                           |                           |
   |-----(1) INVITE SDP A----->|                           |
   |                           |                           |
   |<-(2) 183 Session en cours-|                           |
   |                           |-----(3) INVITE SDP TB---->|
   |                           |                           |
   |                           |<----(4) 603 Refus---------|
   |                           |                           |
   |                           |---------(5) ACK---------->|
   |<----(6) 603 Refus---------|                           |
   |                           |                           |
   |---------(7) ACK---------->|                           |
   |                           |                           |

Figure 3 : Échec d’établissement de session

L’ambiguïté dans ce flux est que, si la réponse provisoire (2) est perdue, l'appelant ne sait pas si la réponse 603 (Refus) signifie que le INVITE (1) initial a été rejeté par le transcodeur ou si le INVITE généré par le transcodeur (4) a été rejeté par l'appelé. L’utilisation du champ d'en-tête "History-Info" [RFC4244] entre le transcodeur et l'appelant résout l’ambiguïté précédente.

Noter que ce problème d’ambiguïté pourrait aussi avoir été résolu en faisant que les transcodeurs agissent comme un pur pont de conférence. Le transcodeur répondrait avec un 200 (OK) à la demande INVITE de l'appelant, et il générerait une demande INVITE sortante vers l'appelé. L'appelant obtiendrait les informations sur le résultat de la dernière demande INVITE en s’abonnant au paquetage d'événements de conférence [RFC4575] chez le transcodeur. Bien que ce flux résolve le problème de l’ambiguïté sans exiger la prise en charge du champ d'en-tête "History-Info", il est plus complexe, exige un plus grand nombre de messages, et introduit des délais d’établissement de session plus élevés. C'est-à-dire pourquoi n’a t’il pas choisi de mettre en œuvre les services de transcodage.

 	4.	Invocation de l’appelé

Si un UA reçoit un INVITE avec une description de session qui n’est pas acceptable, il peut le rediriger sur le transcodeur en utilisant une réponse 302 (Temporairement absent). Le champ d'en-tête Contact de la réponse 302 (Temporairement absent) contient l’URI du transcodeur plus un paramètre "?body=". Ce paramètre contient un corps de liste de receveurs avec l’URI de B. Noter qu’un certain échappement (par exemple, pour retour-chariot et saut à la ligne) est nécessaire pour coder un corps de liste de receveurs dans un tel paramètre. La Figure 4 montre le flux de messages pour ce scénario.

   A                           T                           B
   |                           |                           |
   |-------------------(1) INVITE SDP A------------------->|
   |                           |                           |
   |<--------------(2) 302 Temporairement absent-----------|
   |                           |                           |
   |-----------------------(3) ACK------------------------>|
   |                           |                           |
   |-----(4) INVITE SDP A----->|                           |
   |                           |                           |
   |<-(5) 183 Session en cours-|                           |
   |                           |-----(6) INVITE SDP TB---->|
   |                           |                           |
   |                           |<-----(7) 200 OK SDP B-----|
   |                           |                           |
   |                           |---------(8) ACK---------->|
   |<----(9) 200 OK SDP TA-----|                           |
   |                           |                           |
   |--------(10) ACK---------->|                           |
   |                           |                           |
   | ************************* | ************************* |
   |**       Support         **|**       Support         **|
   | ************************* | ************************* |

Figure 4 : Invocation d’un transcodeur par l’appelé

Noter que la syntaxe qui résulte du codage d’un corps dans un URI comme décrit plus haut est assez complexe. Il est en fait plus simple que les appelés invoquent les services de transcodage en utilisant plutôt le modèle de transcodage 3pcc de la [RFC4117].

 	5.	Considérations sur la sécurité

Les transcodeurs qui mettent en œuvre la présente spécification se comportent comme un service de liste d'URI comme décrit dans la [RFC5366]. Donc, les considérations sur la sécurité pour les services de liste d'URI discutés dans la [RFC5363] s’appliquent ici aussi.

En particulier, les exigences relatives à l’intégrité de la liste et aux demandes non sollicitées sont importantes pour les services de transcodage. Les agents d’utilisateur DEVRAIENT protéger l’intégrité des listes d'URI en utilisant des mécanismes comme S/MIME [RFC3850] ou TLS [RFC5246], qui peuvent aussi assurer la confidentialité des listes d’URI si nécessaire. De plus, les transcodeurs DOIVENT authentifier et autoriser les utilisateurs et PEUVENT fournir des informations sur l’identité de l’envoyeur original de la demande dans leurs demandes sortantes en utilisant le mécanisme d’identité de SIP [RFC4474].

L’exigence de la [RFC5363] d’utiliser des listes opt-in (par exemple, en utilisant la [RFC5360]) mérite une discussion particulière. Le type de service de liste d'URI mis en œuvre par les transcodeurs qui suivent la présente spécification ne produit pas d’amplification (une seule demande INVITE est générée par le transcodeur à réception d’une demande INVITE d’un agent d'utilisateur) et n’implique pas de traduction en un URI qui peut être par ailleurs inconnu de l'appelant (l'appelant place l’URI de l'appelé dans le corps de sa demande INVITE initiale). De plus, l’identité de l'appelant est présente dans la demande INVITE générée par le transcodeur. Donc, il n’est pas exigé que les transcodeurs qui mettent en œuvre la présente spécification utilisent des listes opt-in.

 	6.	Contributeurs

Le présent document est le résultat de discussions parmi l’équipe de conception de conférence. Les membres de cette équipe incluent Eric Burger, Henning Schulzrinne, et Arnoud van Wijk.

 	7.	Références
 	7.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3323]	J. Peterson, "Mécanisme de confidentialité pour le protocole d'initialisation de session (SIP)", novembre 2002.

[RFC3325]	C. Jennings, J. Peterson et M. Watson, "Extensions privées au protocole d'initialisation de session (SIP) pour l'assertion d'identité au sein de réseaux de confiance", novembre 2002. (Information ; MàJ par RFC8217)

[RFC3850]	B. Ramsdell, éd., "Traitement de certificat d'extensions multi-objets/sécurisées de messagerie Internet (S/MIME) version  3.1", juillet 2004. (P.S.) (Remplacée par RFC5750)

[RFC4117]	G. Camarillo et autres, "Invocation de services de transcodage dans le protocole d'initialisation de session (SIP) en utilisant la commande d'appel de tiers (3pcc)", juin 2005. (Information)

[RFC4244]	M. Barnes, éd., "Extension au protocole d'initialisation de session (SIP) pour les informations d'historique de demande", novembre 2005. (P.S.) (Remplacée par RFC7044)

[RFC4474]	J. Peterson et C. Jennings, "Améliorations de la gestion d'identité authentifiée dans le protocole d'initialisation de session (SIP)", août 2006. (P.S. ; Remplacée par RFC8224)

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; rendue obsolète par la RFC8446)

[RFC5363]	G. Camarillo, A.B. Roach, "Cadre et considérations sur la sécurité pour les services URI-List du protocole d'initialisation de session (SIP)", octobre 2008. (P.S.)

[RFC5366]	G. Camarillo, A. Johnston, "Établissement de conférence en utilisant des listes contenues dans des demandes dans le protocole d'initialisation de session (SIP)", octobre 2008. (P.S.)

[RFC5369]	G. Camarillo, "Cadre pour le transcodage avec le protocole d'initialisation de session (SIP)", octobre 2008. (Info.)

 	7.2	Références pour information

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

[RFC4575]	J. Rosenberg et autres, "Paquetage d'événement du protocole d'initialisation de session (SIP) pour l'état Conference", août  2006. (P.S.)

[RFC5360]	J. Rosenberg et autres, "Cadre des communications fondées sur le consentement dans le protocole d'initialisation de session (SIP)", octobre 2008. (P.S. ; MàJ par RFC8217)

 	Adresse de l’auteur

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland
mél : Gonzalo.Camarillo@ericsson.com

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.