Les spécifications Jingle sont publiées
Après une longue période d’attente pour certains et de travail pour d’autres , la XSF a publié les spécifications Jingle en version 1.0 (statut ‘Draft’).
Longue attente, car Google avait publié les spécifications de son Jingle-voix en fin 2005, en même temps sa bibliothèque libre libjingle. Rappelons que le Jingle-voix de l’époque est présent dans Google Talk, l’application ‘lourde’, pas web, ni Flash, qui s’installe sur un bureau Windows. Ce qui explique une si longue attente, c’est le travail soigné apporté à la généralisation des spécifications (vidéo, fichiers, ICE), leurs implémentations, le feedback pour maturer les spécifications. Rappelons encore que Jingle est ‘très’ (tout est relatif) attendu, et qu’il est critique d’écrire quelque chose de bien chiadé. Tout cela prend énormément de temps. Un standard ouvert nécessite beaucoup d’attention et de mise au point.
Désolé pour les traductions manquantes, mais je n’ai pas trop le temps, voir le travail de Maclag sur le wiki de JabberFr. Merci Maclag ! ;-) Les mises en forme sont de ma main, ainsi que les commentaires.
Voici les spécifications en question :
- XEP-0166: Jingle
This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat, file transfer) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).
Il s’agit de la base du ‘protocole Jingle’, permettant un certain nombre d’applications, comme la voix, la vidéo et le transfert de fichiers pour ne citer que les plus évidentes. Pour bien repréciser le contexte, Jingle n’est qu’un protocole d’initialisation de sessions multimédia, qui n’a pas pour but de réinventer la roue (ou l’eau chaude, c’est selon), mais d’utiliser les avantages de XMPP pour apporter le multimédia sur XMPP et/ou d’amener les utilisateurs de XMPP vers le monde SIP (et/ou l’inverse). - XEP-0167: Jingle RTP Sessions
This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.
Là, on a affaire à RTP et UDP, je ne vais pas entrer dans le détail, c’est du protocole réseau de bas niveau. - XEP-0176: Jingle ICE-UDP Transport Method
This specification defines a Jingle transport method that results in sending media data using raw datagram associations via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology, which provides robust NAT traversal for media traffic.
Ici, c’est pour passer les NAT à peu près proprement, de manière standard ouvert. ICE est utilisé également par SIP. - XEP-0177: Jingle Raw UDP Transport Method
This specification defines a Jingle transport method that results in sending media data using raw datagram associations via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required.
On est ici dans un contexte sans NAT, donc beaucoup plus facile, disons plutôt moins difficile.
Il existe également d’autres spécifications encore expérimentales, mais avancées, très probablement Draft après un certain temps d’implémentation et feedback :
- XEP-0181: Jingle DTMF
This specification defines an XML format for encapsulating Dual Tone Multi-Frequency (DTMF) events in informational messages sent within the context of Jingle audio sessions, e.g. to be used in the context of Interactive Voice Response (IVR) systems. Note well that this format is not to be used in the context of RTP sessions, where native RTP methods are to be used instead.
Pour passer les sons d’un clavier numérique vers les serveurs interactifs (votre répondeur par exemple). - XEP-0234: Jingle File Transfer
This specification defines a Jingle application type for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used.
Avec cette méthode de transfert de fichiers, on espère se passer des (futures) anciennes méthodes, qui posent toutes un problème dans un contexte particulier. Je vous laisse lire l’intro de cette spec pour mieux comprendre.
Nous avons également d’autres spécifications, encore peu avancées, on ne peut pas encore dire à ce stade ce qu’elles vont devenir à terme (annulées, remplacées par d’autres, etc.) :
- XEP-0247: Jingle XML Streams
This specification defines a Jingle application type for establishing direct or mediated XML streams between two entities over any streaming transport. This technology thus enables two entities to establish a trusted connection for end-to-end encryption or for bypassing server limits on large volumes of XMPP traffic.
Utile dans de nombreux contexte : se passer du ou des deux serveurs interdmédiaire, une fois la session initialisée. - XEP-0251: Jingle Session Transfer
This specification defines an extension to XMPP Jingle for transferring a session (such as a voice call) from one person to another.
Pour ‘basculer’ un appel. - XEP-0260: Jingle SOCKS5 Bytestreams Transport Method
This specification defines a Jingle transport method that results in sending data via the SOCKS5 Bytestreams (S5B) protocol defined in XEP-0065. Essentially this transport method reuses XEP-0065 semantics for sending the data and defines native Jingle methods for starting and ending an S5B session.
Pour utiliser les proxies de type SOCKS5. - XEP-0261: Jingle In-Band Bytestreams Transport
This specification defines a Jingle transport method that results in sending data via the In-Band Bytestreams (IBB) protocol defined in XEP-0047. Essentially this transport method reuses XEP-0047 semantics for sending the data and defines native Jingle methods for starting and ending an IBB session.
Pour envoyer tout le flux multimédia dans une session XMPP, peu recommandable afin d’éviter une surcharge du ou des deux serveurs intermédiaires. - XEP-0262: Use of ZRTP in Jingle RTP Sessions
This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.
Pour chiffrer la VoIP. - XEP-0266: Codecs for Jingle RTP Sessions (de type ‘Informational‘)
This document describes implementation considerations related to voice and video codecs for use in Jingle RTP sessions.
J’y reviens en-dessous. - XEP-0269: Jingle Early Media
This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.
La XEP-0266: Codecs for Jingle RTP Sessions est très importante puisque les différents implémenteurs pourront utiliser les codecs qui leurs semblent les plus opportuns. C’est très ouvert : les éditeurs proprios pousseront leurs ’solutions’ proprio. Côté audio, c’est Speex et G.711 qui sont poussés, et côté vidéo, c’est Theora, Dirac et H.264. Gageons que les implémentations les plus importantes ou qui auront le plus de succès utiliseront des codecs libres et sans brevets.
Remarquons que SIP est beaucoup mentionné, preuve supplémentaire que XMPP ne réinvente pas SIP, mais cherche l’interopérabilité (j’en remet une couche, désolé).
La publication de ces spécifications n’est pas une fin en soit. C’est juste un passage en version ’stable’, comme un logiciel : ces spécifications contiennent sans aucun doute des bugs mineurs, qui vont être corrigées grâce au feedback des implémenteurs et utilisateurs.
Il s’écoulera encore d’autres années de travail pour que ces spécifications passent dans le girons de l’IETF.
Quoiqu’il en soit, plus rien ne peut retenir les implémenteurs désormais, excepté que le développement d’un logiciel multimédia est bien complexe qu’un client de chat.
