Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 7572: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging

Date de publication du RFC : Juin 2015
Auteur(s) du RFC : P. Saint-Andre (&yet), A. Houri (IBM), J. Hildebrand (Cisco Systems)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF stox
Première rédaction de cet article le 17 juin 2015


Ce court RFC décrit une correspondance entre deux protocoles standards de messagerie instantanée, SIP et XMPP. Cela permet de développer proprement des passerelles connectant ces deux mondes, autorisant ainsi Juliette, utilisatrice de XMPP, à parler avec son Roméo, qui utilise SIP. C'est aussi un exercice intellectuel rigolo, mais parfois difficile, comment faire se parler deux protocoles différents, qui n'ont pas exactement les mêmes sémantiques.

C'est vrai qu'on ne sait pas forcément que SIP (RFC 3261) est aussi un protocole de messagerie instantanée. On le voit plutôt uniquement comme un protocole de signalisation pour la téléphonie sur IP. Mais SIP sait bel et bien échanger de courts messages textes, grâce à l'extension MESSAGE du RFC 3428. Quant à XMPP (RFC 6120), ses capacités de messagerie instantanée sont spécifiées dans le RFC 6121. C'est pour des raisons historiques variées que l'IETF a deux protocoles standard de messagerie instantanée, sans compter l'ancêtre IRC.

Le concept de messagerie instantanée, à l'IETF, est décrit dans le RFC 2779. Le but est de communiquer, donc il serait ennuyeux que Roméo et Juliette ne puissent pas échanger simplement parce qu'ils ont fait des choix technologiques différents. Spécifier un mécanisme de passerelle entre ces deux protocoles peut se faire en développant une sémantique abstraite (elle existe déjà, dans le RFC 3860), puis en définissant une correspondance entre cette abstraction et chaque protocole (ce qui a été fait pour XMPP : RFC 3922). En pratique, c'est bien compliqué et notre nouveau RFC 7572 choisit une autre approche, définir une correspondance entre SIP et XMPP, sans intermédiaire. L'inconvénient est que cela ne se généralise pas à davantage de protocoles, l'avantage est que c'est simple à comprendre et à programmer. En pratique, cette approche est donc bien plus répandue.

Notre RFC repose sur un modèle simple, l'envoi de courts textes, les messages, de manière synchrone, entre deux entités (Roméo et Juliette dans les exemples du RFC), ce qui se nomme page mode. Il existe d'autres modèles comme celui de conversations stables sur une certaine durée (session mode) ou comme celui de communications à plus de deux participants. Le groupe de travail STOX de l'IETF est penché dessus et produira d'autres RFC sur ces modèles, comme le RFC 7573 sur les sessions. Notre RFC s'appuie sur le RFC 7247, qui définissait une architecture pour l'interconnexion de SIP et XMPP.

Donc, commençons par XMPP vers SIP (section 4). Un message XMPP est une strophe (stanza) XML <message/> de type normal (le type par défaut). Voici l'exemple envoyé par Juliette :


<message from='juliet@example.com/yn0cl4bnw0yr3vym'
         to='romeo@example.net'>
   <body>Art thou not Romeo, and a Montague?</body>
</message>

Si le domaine dans l'attribut to est un domaine SIP (section 5 du RFC 7247), le serveur XMPP que Juliette utilise va transmettre le message à une passerelle XMPP->SIP qui va traduire en SIP :


MESSAGE sip:romeo@example.net SIP/2.0
Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
To: sip:romeo@example.net
From: <sip:juliet@example.com;gr=yn0cl4bnw0yr3vym>;tag=12345
Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 35

Art thou not Romeo, and a Montague?

Notez que l'identificateur de ressource dans le JID (le JID nu est juliet@example.com, la ressource est yn0cl4bnw0yr3vym, cf. RFC 6120, section 1.4) a été traduit en GRUU (Globally Routable User Agent URIs, cf. RFC 5627) SIP.

Le serveur SIP de Roméo répondra automatiquement avec le code 200 (tout va bien) :

SIP/2.0 200 OK
Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
From: sip:juliet@example.com;tag=12345
To: sip:romeo@example.net;tag=vwxyz
Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
CSeq: 1 MESSAGE
Content-Length: 0

La correspondance entre les termes utilisés figure dans le tableau 1 dans cette section 4. Ainsi, le <body/> de XMPP est transformé en corps du message SIP, l'attribut to de XMPP qui indique le destinataire devient le champ To: de SIP, l'attribut xml:lang de XMPP (absent dans cet exemple) devient un champ Content-Language:, etc. Certaines valeurs n'ont pas de correspondance (comme l'attribut type de XMPP, inutilisé dans l'exemple).

En sens inverse, lorsque Roméo répond, il va utiliser SIP (avec l'extension du RFC 3428) et il va donc falloir traduire le SIP en XMPP. Sa réponse était (section 5 de notre RFC) :


MESSAGE sip:juliet@example.com SIP/2.0
Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
Max-Forwards: 70
To: sip:juliet@example.com
From: sip:romeo@example.net;tag=vwxyz
Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 44

Neither, fair saint, if either thee dislike.

Et la passerelle SIP->XMPP qu'utilisera le serveur SIP de Roméo traduira en :


<message from='romeo@example.net/dr4hcr0st3lup4c'
         to='juliet@example.com'>
  <body>Neither, fair saint, if either thee dislike.</body>
</message>

La correspondance entre les termes (tableau 2) est la même, mais inversée. Le champ To: est traduit en attribut to, le corps du message devient un élément XMPP <body>, etc. Notez que la passerelle connaissait le GRUU SIP (par un moyen non spécifié, peut-être parce qu'elle fait partie du serveur SIP) et l'a utilisé pour générer un JID complet avec identificateur de ressource (romeo@example.net/dr4hcr0st3lup4c).

Faire des passerelles entre deux protocoles indépendants, conçus de manière différente et sans coordination a toujours été délicat. Par exemple, la section 6 fait remarquer qu'il y a un problème... de taille. SIP met une limite de 1 300 octets aux messages (RFC 3428, section 8) alors que les RFC sur XMPP ne spécifient pas de limite. En pratique, les messages XMPP dépassent rarement cette taille et, de toute façon, les mises en œuvre effectives de XMPP ont souvent une limite (RFC 6120, section 13.12), mais plus élevée (au moins 10 000 octets doivent être acceptés, dit le RFC 6120). Si Juliette, qui utilise XMPP, essaie d'envoyer un message de 1 500 octets à son Roméo, la passerelle XMPP->SIP n'aura pas d'autre choix que de le rejeter, avec une erreur <policy-violation/>. (Des solutions plus sophistiquées existent, comme de passer en session mode mais notre RFC ne les spécifie pas.)

Autre cause d'incompatibilités possibles, mais en sens inverse, cette fois, les questions de format des données (section 7). Un message SIP peut contenir des données de n'importe quel type (dans les exemples ci-dessus, c'était toujours du text/plain mais ce n'est pas obligatoire). XMPP traitant le contenu de manière très différente, notre RFC impose aux passerelles SIP->XMPP de :

  • Accepter le contenu text/plain, comme dans les exemples ci-dessus, en le mettant dans le <body/> XMPP,
  • Accepter le contenu text/html en le transformant en XHTML qu'on met dans le <body/> XMPP (comme décrit dans le XEP-0071),
  • Faire ce qu'elle veut avec les autres types, aucune règle n'est spécifiée pour eux.

Et si on veut le dire autrement qu'en anglais ? Pas de problème, les deux protocoles permettent d'étiqueter le message avec la langue utilisée, et tous les deux permettent de transporter des caractères Unicode (en général en UTF-8). Si Roméo décide de parler tchèque :


MESSAGE sip:juliet@example.com SIP/2.0
Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
Max-Forwards: 70
To: sip:juliet@example.com
From: sip:romeo@example.net;tag=vwxyz
Call-ID: 5A37A65D-304B-470A-B718-3F3E6770ACAF
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 45
Content-Language: cs

Nic z obého, má děvo spanilá, nenávidíš-li jedno nebo druhé. 

La passerelle le traduira sans problème (j'ai utilisé ici les notations commençant par &#x mais ce n'est pas obligatoire, XMPP utilise XML et peut donc se servir d'UTF-8) :


<message from='romeo@example.net'
         to='juliet@example.com'
         xml:lang='cs'>
	 <body>
           Nic z ob&#x00E9;ho, m&#x00E1; d&#x011B;vo spanil&#x00E1;, nen&#x00E1;vid&#x00ED;&#x0161;-li jedno nebo druh&#x00E9;.
       </body>
</message>

Un mot sur la sécurité pour finir. L'introduction de la passerelle entre les deux protocoles ajoute évidemment quelques risques. Notamment, il est plus difficile de garantir une sécurité de bout en bout. Il existe des solutions standard peu déployées (RFC 3862 et RFC 3923) ou une solution non standard, OTR.

Parmi les serveurs qui mettent déjà en œuvre cette passerelle, on peut apparemment citer Cisco, Kamailio, ou AG Projects (dans Silk Server).


Téléchargez le RFC 7572

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)