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/htmlen 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ého, má děvo spanilá, nenávidíš-li jedno nebo druhé.
</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).
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)
