La présente invention se situe dans le domaine du codage de données sans perte.

Elle s'applique plus particulièrement mais de façon non limitative pour le codage sans perte des données de transport utilisées pour le contrôle de flux multimédia conforme à un standard de la famille MPEG.

Dans l'état actuel de la technique, les standards MPEG-4 FF ( File Format ) et MPEG-2 TS ( Transport Stream ) offrent des solutions pour le formatage et le transport de contenus multimédias, notamment en termes de codage binaire du flux vidéo, du flux audio et de représentation de la scène.

Ce standard est bien adapté pour une utilisation statique du contenu multimédia dans laquelle l'interactivité entre le serveur de contenu et le client restituant le contenu est très réduite.

Mais les solutions connues à ce jour sont mal adaptées aux applications fortement interactives, et a fortiori aux applications collaboratives, le poids des données de transport des informations collaboratives pouvant être excessivement lourd.

L'invention vise un mécanisme de codage qui permet notamment de réduire considérablement le volume de ces données.

Objet et résumé de l'invention

Plus précisément et selon un premier aspect, l'invention concerne un procédé de codage de données sans perte mis en œuvre par un équipement émetteur, en communication bidirectionnelle avec au moins un équipement récepteur dans une session collaborative d'échange de contenu multimédia. Ce procédé comporte:

- au cours de ladite session, au moins :

- une étape d'échange, avec le ou les équipements récepteurs, au moins un attribut d'un message de collaboration susceptible d'être utilisé dans cette session et d'un index associé à cet attribut, l'attribut et son index étant utilisés par ces équipements pour mettre à jour un dictionnaire partagé d'attributs indexés, ce dictionnaire étant mémorisé par chacun de ces équipements pendant toute la durée de la session ;

- une étape de substitution, dans un message de collaboration destiné à être envoyé à ou aux équipements récepteurs, d'au moins un attribut par son index dans le dictionnaire partagé ;

- une étape d'envoi du message de collaboration à ou aux équipements récepteurs ; et

- une étape de destruction du dictionnaire partagé à la fin de la session.

Corrélativement, l'invention concerne aussi un dispositif de codage de données sans perte pouvant être incorporé dans un équipement émetteur apte à établir une communication bidirectionnelle avec au moins un équipement récepteur dans une session collaborative d'échange de contenu multimédia. Ce dispositif comporte :

- des moyens pour échanger avec le ou les équipements récepteurs, au cours de la session, au moins un attribut d'un message de collaboration susceptible d'être utilisé dans la session et un index associé à cet attribut, l'attribut et son index étant utilisés par ces équipements pour mettre à jour un dictionnaire partagé d'attributs indexés ;

- des moyens pour mémoriser le dictionnaire partagé pendant toute la durée de la session ;

- des moyens de substitution, dans un message de collaboration destiné à être envoyé à ou aux équipements récepteurs, d'au moins un attribut par son index dans le dictionnaire partagé ;

- des moyens d'envoi du message de collaboration à ou aux équipements récepteurs ; et

- des moyens de destruction du dictionnaire partagé à la fin de la session.

Selon un deuxième aspect, l'invention vise également un procédé de décodage de données mis en œuvre par un équipement récepteur, en communication bidirectionnelle avec au moins un équipement émetteur dans une session collaborative d'échange de contenu multimédia, ce procédé comportant :

- au cours de ladite session, au moins : - une étape d'échange, avec le ou les équipements récepteurs, d'au moins un attribut d'un message de collaboration susceptible d'être utilisé dans la session et d'un index associé à cet attribut, l'attribut et son index étant utilisés par ces équipements pour mettre à jour un dictionnaire partagé d'attributs indexés, ce dictionnaire étant mémorisé par chacun des équipements pendant toute la durée de la session ; et

- une étape de réception d'un message de collaboration émis par un des équipements émetteurs comportant au moins un index ; - une étape de substitution, dans ce message de collaboration du chacun de ces index par l'attribut auquel il est associé dans le dictionnaire partagé ; et

- une étape de destruction du dictionnaire partagé à la fin de la session.

Corrélativement, l'invention vise aussi un dispositif de décodage de données pouvant être incorporé dans un équipement récepteur apte à établir une communication bidirectionnelle avec au moins un équipement émetteur dans une session collaborative d'échange de contenu multimédia, ce dispositif comportant :

- des moyens pour échanger avec le ou avec les équipements émetteur, au cours de ladite session, au moins un attribut d'un message de collaboration susceptible d'être utilisé dans la session et d'un index associé à cet attribut, l'attribut et son index étant utilisés par ces équipements pour mettre à jour un dictionnaire partagé d'attributs indexés ;

- des moyens de réception d'un message de collaboration émis par un de ces équipements émetteurs comportant au moins un index ;

- des moyens de substitution, dans le message de collaboration de chacun des index par l'attribut auquel il est associé dans le dictionnaire partagé ; et

- des moyens de destruction du dictionnaire partagé à la fin de la session.

Ainsi, et d'une façon générale, l'invention propose de substituer des attributs présents dans des messages de collaboration par des index associés à ces attributs dans un dictionnaire partagé entre l'émetteur et les récepteurs de ce message.

Conformément à l'invention, les messages de collaboration sont des messages échangés entre un émetteur et un récepteur, une fois que ceux- ci ont été localisés, par exemple en utilisant le protocole SIP. Il est important de noter que les messages de collaboration codés par l'invention sont par natures imprédictibles, au contraire des messages échangés au cours de la phase préliminaire à l'invention, dans le cadre par exemple du protocole SIP.

L'invention peut être mise en œuvre en complément ou non d'un autre mécanisme de compression du protocole SIP.

Le partage des données de collaboration conformément à l'invention requiert une extension du codeur pour la production des données codées et du décodeur pour leur exploitation.

Le fait de remplacer un attribut par un index peut être avantageusement utilisé pour crypter les attributs, les index étant par exemple constitués par un haché de ces attributs.

Dans un mode particulier de réalisation de l'invention, la taille d'un attribut est supérieure à la taille de son index dans le dictionnaire partagé. Le procédé de codage selon l'invention est alors un procédé de compression de données sans perte.

Dans un mode particulier de réalisation, la taille du dictionnaire partagé permet de déterminer le nombre de bits requis pour les index des attributs suivants partagés entre l'émetteur et le récepteur.

Dans un mode particulier de réalisation de l'invention, le contenu multimédia est conforme à un standard de la famille MPEG.

L'invention permet ainsi un procédé de codage sans perte des données de transport utilisées pour le contrôle des flux de communication MPEG. Elle offre un mécanisme de compression des données de transport particulièrement efficace dans le contexte des applications bidirectionnelles collaboratives pour lesquelles un nombre assez limité d'attributs est échangé un nombre très important de fois entre les différents dispositifs participant à la session.

En particulier, l'invention offre un taux de compression particulièrement important pour des applications dans lesquelles des informations des messages de présence ou de notification d'état sont régulièrement échangées entre des clients et un serveur central.

On rappelle que pour des applications de collaboration impliquant N participants connectés à une même session de collaboration, N*(N-1) messages de présence sont régulièrement échangés entre les participants, par exemple toutes les deux ou trois secondes. Ainsi pour 10,000 utilisateurs connectés et des messages de présence de 100 octets, 10Gb sont échangés à chaque intervalle de temps.

Pour de telles applications, l'invention permet de réduire ce volume d'un facteur 10 environ (1Gb).

Ce taux de compression peut être obtenu grâce à l'invention, du fait du partage pendant toute la session des index associés aux informations les plus coûteuses, par exemple les identifiants de l'espace de collaboration, noms de domaines, identifiants des participants, ...

Le dictionnaire partagé est avantageusement détruit à la fin de la session pour ne pas encombrer inutilement la mémoire des différents équipements.

Conformément à l'invention, le contenu du dictionnaire partagé entre le codeur et le décodeur augmente au besoin pendant le déroulement de la session. Cette caractéristique offre avantageusement une solution très flexible en termes de complexité.

Dans un mode particulier de réalisation de l'invention, la session met en œuvre le protocole RTP pour l'échange des données multimédia et le protocole RTSP pour l'initialisation et le contrôle de cet échange.

Dans ce contexte, l'invention permet de réduire la charge utile additionnelle nécessaire au transport de des données de collaboration à son strict minimum et donc d'optimiser l'utilisation de la bande passante pour le transport du contenu multimédia à proprement parler (données audio, vidéo et de représentation de la scène).

Dans un mode particulier de mise en uvre de l'invention chaque équipement est apte à mettre en œuvre le procédé de codage et le procédé de décodage conformes à l'invention.

Par conséquent, l'invention vise aussi un dispositif de communication comportant un dispositif de codage selon tel que mentionné ci-dessus et un dispositif de décodage tel que mentionné ci- dessus.

L'invention vise aussi un équipement de communication comportant un dispositif tel que mentionné ci-dessus.

L'invention vise aussi un système de collaboration comportant au moins deux équipements tels que mentionnés ci-dessus.

Dans un mode particulier de réalisation de l'invention, la session collaborative est conforme au standard X PP. Dans un mode particulier de réalisation de l'invention, le procédé de codage et le procédé de décodage selon l'invention sont mis en œuvre par des programmes d'ordinateur.

Par conséquent, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de codage et/ou d'un procédé de décodage tels que mentionné ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous en référence aux dessins et aux annexes qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

- la figure 1 représente de façon schématique un exemple de système de collaboration conforme à l'invention ; et

- la figure 2 représente sous forme d'organigrammes les principales étapes d'un procédé de codage et d'un procédé de décodage conformes à un mode particulier de réalisation de l'invention.

Description détaillée d'un mode de réalisation

En premier lieu, et en référence aux Annexes 1 et 2, nous allons détailler un exemple de codage pouvant être utilisé dans l'invention.

Dans l'exemple de réalisation décrit ici, les messages de collaboration sont décrits en utilisant le standard XMPP (Extensible Message and Présence Protocol) ; l'encapsulation et le transport des flux multimédias utilisé est conforme au format MPEG.

On rappelle que l'invention est mise en œuvre, une fois que les émetteurs et les récepteurs ont été localisés, par exemple via le protocole SIP.

Dans l'exemple de réalisation décrit ici, les messages de collaboration codés par l'invention peuvent être de 4 natures.

Les messages de collaboration d'une première nature sont des messages d'énumération utilisés pour la mise à jour du dictionnaire partagé au cours de la session.

Les messages de collaboration des trois autres natures sont, dans cet exemple :

- les messages CIP spécifiant un état de présence de l'équipement émetteur ;

- les messages CIM comportant des informations destinées à l'équipement récepteur ; et

- les messages CIQ comportant des métadonnées d'administration ou de contrôle d'un système de collaboration dans lequel la session est mise en œuvre.

Pour les messages de collaboration autres que les messages d'énumération, on utilise, dans cet exemple, les attributs suivants: - « Type » : qui définit la sémantique de la nature et qui est codé avec une valeur prédéterminée pour chacun des types;

- « To » : qui définit le destinataire du message;

- « From » : qui définit l'émetteur du message; et

- « ID » qui définit une information permettant l'identification du message par l'application collaborative.

Dans le mode particulier de réalisation de l'invention décrit ici, le message de collaboration comporte :

- un champ représentatif de la nature du message; et, pour les messages de collaboration autres que les messages d'énumération :

- un attribut représentatif de la sémantique de la nature du message ; et

- un élément binaire représentatif de la présence ou non d'un attribut dans ledit message, suivi, lorsque l'attribut est présent, d'un corps comportant l'index associé à l'attribut dans le dictionnaire partagé.

Dans le mode de réalisation décrit ici, et comme représenté à l'Annexe 1, le codage des informations de collaboration utilise un champ de deux bits CIUNature pour décrire la nature du message de collaboration. Plus précisément:

- 00 représente un message d'énumération utilisé pour l'échange des données du dictionnaire partagé ETU;

- 01 représente un message CIP;

- 10 représente un message CIM ; et

- 11 représente un message CIQ.

Pour les messages CIP, CIM et CIQ, le champ de description CIUNature sur deux bits est suivi par :

- un élément CIUType représentatif de la sémantique de la nature du message; et, pour chacun des attributs TO, FROM, ID, un élément binaire représentatif de la présence ou non de cet attribut dans le message, suivi, lorsque l'attribut est présent, d'un corps comportant l'index associé à cet attribut dans le dictionnaire partagé ETU.

Lorsqu'il est présent, le corps est codé en utilisant les index du dictionnaire partagé pour décrire les différents attributs, comme illustré sur un exemple à l'annexe 1.

Plus précisément, dans cet exemple, le corps comporte:

- un champ ΕΠ fournissant l'index du dictionnaire partagé pour décrire le du nom de l'élément principal ; - une collection d'attributs associés à cet élément principal et pour chaque attribut, signalé en avance par un bit, une paire d'index du dictionnaire partagé représentant dans l'ordre leur nom et leur valeur ;

- un contenu, de type texte, signalé par un bit et composé d'une chaîne de caractères ASCII terminée par un octet à zéro ; et

- une collection d'éléments signalés en avance par leur bit de présence suivi par leur description, récursive, comme pour l'élément principal.

On considère à titre d'exemple le message, de présence XMPP suivant, ce message étant destiné à être transmis par un client après une phase d'initialisation.

< présence from= 'iolin@somewriere.com' to='host(acollaborator.com' />

La longueur de ce message est 64 octets soit 512 bits.

Conformément à l'invention, ce message peut être transmis, tout au cours d'une session, par un équipement émetteur à un équipement récepteur en substituant deux attributs TO et FROM par deux index partagés par ces équipements pendant la durée de la session.

Ainsi, en appliquant le codage de l'annexe 1, on obtient :

ETU john@somewhere.com

2 bits de code 00 représentatifs d'une commande d'énumération; et 8 bits pour chaque octet des chaînes de caractères

1 octet de terminaison NULL, soit 19 octets au total.

L'index 00 obtenu implicitement sera utilisé suite à l'échange de cet ETU en substitution de ce premier attribut.

ETU host@collaborator.com

2 bits de code 00 représentatifs d'une commande d'énumération; et 8 bits pour chaque octet des chaînes de caractères

1 octet de terminaison NULL, soit 22 octets au total. L'index 01 obtenu implicitement sera utilisé suite à l'échange de cet ETU en substitution de ce deuxième attribut.

Le volume de données échangées pour la mise à jour du dictionnaire partagé est donc de 345 bits.

Ensuite, ce message de présence peut être codé en utilisant seulement 14 bits qui se décomposent comme suit :

- 2 bits CIP

- 3 bits pour coder le type (valeur 000 par défaut)

- 1 bit et 2 bits 00 pour l'attribut TO

- 1 bit et ,2 bits 01 pout l'attribut FROM

- 1 bit 0 (pas de type)

- 1 bit 0 (pas d'ID)

- 1 bit 0 (pas de corps)

Pour la transmission du premier message de présence, le codage selon l'invention permet un gain de 153 bits (512-359), mais l'homme du métier comprendra que le gain devient très important pour la transmission des messages de présence subséquents (14 bits au lieu de 512).

L'Annexe 2 donne un autre exemple de codage selon l'invention et sa taille pour un message plus complexe. Il s'agit d'un message de texte pouvant être utilisé dans une application de messagerie instantanée.

La figure 1 représente un système de collaboration conforme à l'invention.

Ce système comporte plus précisément un serveur SRV et 2 clients

CL1, CL2 chacun de ces équipements étant un équipement de communication conforme à l'invention.

Chacun de ces équipements comporte un dispositif 100 conforme à l'invention apte à mettre en œuvre un procédé de codage et un procédé de décodage conformes à l'invention. Pour des raisons de clarté, seul celui du serveur SRV est référencé.

Dans l'exemple de réalisation décrit ici, ce dispositif 100 a l'architecture conventionnelle d'un ordinateur. Il comporte notamment un processeur 11, une mémoire vive de type RAM 12, une mémoire morte de type ROM 13, des moyens de communication non représentés. La mémoire morte de type ROM 13 constitue un support d'enregistrement conforme à l'invention lisible par le processeur 11. Ce support d'enregistrement mémorise deux programmes d'ordinateurs PG_COD (codage) et PG_DECOD (décodage) conformes à un mode particulier de réalisation de l'invention, et dont les principales étapes vont maintenant être décrites en référence à la figure 2.

En référence à la figure 2, nous allons détailler un exemple de mise en œuvre de réalisation de l'invention.

On suppose dans cet exemple que deux clients CLl, CL2 participent, sous le contrôle d'un serveur SRV, à une même session collaborative.

Dans cet exemple :

le premier client CLl a pour identifiant unique cll@domaine;

le deuxième client CL2 a pour identifiant unique cl2@domaine;

- le serveur SRV a pour identifiant unique srv@domaine.

Nous supposerons que le premier client CLl, le deuxième client CL2 et le serveur ont chacun un espace de travail réservé pour la session collaborative, d'identifiants uniques respectifs cll@domaine/espace, cl2@domaine/espace et srv@domaine/espace.

Nous supposerons que le serveur SRV est en ligne et apte à accepter des requêtes des clients CLl, CL2 pour participer à la session collaborative.

Dans l'exemple décrit ici, on suppose que le premier client à vouloir se connecter au serveur SRV pour participer à la session de collaboration, après une phase d'initialisation et d'authentification connue en soi, est le client CLl.

Le client CLl prépare à cet effet, au cours d'une étape E40, un message de présence Ml, pour indiquer qu'il souhaite participer à la session de collaboration, du type :

Ml : <presence from="cll@domaine/espace" to="srv@domaine/espace"/>

Ce message nécessite deux identifiants, "cll@domaine/espace" et "srv@domaine/espace", qui conformément à l'invention doivent être échangés avec le serveur SRV et mémorisés dans leur dictionnaire partagé ETUI. Par conséquent, au cours d'une étape E10, antérieure à l'étape E40, le client CLl et le serveur SRV mettent en œuvre une étape d'échange au cours de laquelle le client CLl envoie au serveur SRV :

- l'attribut FROM cll@domaine/espace associé à un index 0001; et - l'attribut TO srv@domaine/espace associé à un index 0002.

Au cours d'une étape E20, le client CLl et le serveur SRV mettent à jour chacun leur dictionnaire ETUI avec les deux couples (attribut/index), à savoir (from=cll@domaine/espace, 0002) et (to=srv@domaine/espace, 0001).

Au cours d'une étape E30, le client CLl et le serveur SRV sauvegardent chacun leur dictionnaire ETUI.

Conformément à l'invention, le client CLl n'envoie pas au serveur SRV le message Ml qui a été préparé à l'étape E40, mais substitue, au cours d'une étape E50, chacun des attributs TO, FROM par son index dans le dictionnaire partagé.

Le message M2 résultat de cette substitution est par conséquent le message M2 : <0002 0001 >

Le client CLl envoie le message M2 au serveur SRV qui le reçoit au cours d'une étape F60.

Puis au cours d'une étape F70, le serveur SRV substitue, dans le message M2, chacun des index 0001, 0002 du message M2 par l'attribut qui lui est associé dans le dictionnaire partagé ETU.

Le message M3 obtenu (étape F80) est identique au message Ml mentionné ci-dessus.

Le client CLl et le serveur SRV se sont ainsi comportés comme un dispositif de codage et comme un dispositif de décodage au sens de l'invention.

On notera que dans une session de collaboration typique, le client CLl envoie régulièrement, environ toutes les 2 ou 3s, un message de présence au serveur SRV.

Dans cet exemple, le codage du message Ml nécessite, mise à jour du dictionnaire comprise, 36 octets de données, chaque message de présence subséquent, nécessitant seulement 2 octets.

Nous supposerons maintenant que le deuxième client CL2 souhaite participer à la session collaborative, et qu'il prépare à cet effet un message de présence M4 du type : M4 : <presence from="cl2@domaine/espace" to="srv@domaine/espace"/>

Comme décrit précédemment pour le premier client CL1, le deuxième client CL2 met en œuvre une étape ElO d'échange avec le serveur SRV, au cours de laquelle le deuxième client CL2 envoie au serveur SRV :

- l'attribut FROM cl2@domaine/espace associé à l'index 0002; et

- l'attribut TO srv@domaine/espace associé à un index 0001.

Le deuxième client CL2 et le serveur SRV mettent à jour leur dictionnaire partagé ETU2 au cours d'une étape E20 et le sauvegardent au cours d'une étape E30.

Le codage du message M4 nécessite encore 36 octets de données.

On supposera dans cet exemple que le serveur SRV doit signaler la présence du deuxième client CL2 dans la session collaborative au premier client CL1.

Dans cette phase, le serveur SRV et le premier client CL1 se comportent respectivement comme un dispositif de codage et comme un dispositif de décodage au sens de l'invention.

Le serveur SRV prépare donc le message M5 suivant au cours d'une étape E40 :

M5 : <presence from="cl2@domaine/espace" to="cll@domaine/espace7>

Le codage du message M5 nécessite l'envoi du nouvel attribut FROM cl2@domaine/espace au premier client CL1 associé à un nouvel index 0003 (étape E10).

Cette étape nécessite l'envoi de 19 octets.

Le serveur SRV et le premier client CL1 mettent à jour et sauvegardent leur dictionnaire partagé ETUI au cours des étapes E20 et E30 déjà décrites.

De la même façon, le serveur SRV notifie le deuxième client CL2 de la présence du premier client CL1 par l'envoi d'un message de 19 octets également.

Chaque client CL1, CL2 peut ensuite envoyer régulièrement des messages subséquents de présence de 2 octets chacun au serveur SRV qui les notifie aux autres clients.

Ce principe peut être utilisé pour l'échange d'informations d'autres types. A la fin de la session, chacun des équipements détruit le dictionnaire partagé au cours d'une étape E100.

Class ETU {

Bit(2) ETUType=0;

Bit(8) ETUValue[till null];

};

The Collaboration Information Units are as follows: Class CIU {

Bit(2) CIUNature; /* 01 :CIP, 10:CI , 11:CIQ */

Bit(3) CIUType; /* values depending on the preceeding nature field */

Bit(l) TOFlag;

If ( TOFIag ) {

Bit(maxETU) TOValue;

}

Bit(l) FRO Flag;

If ( FROMFlag ) {

Bit(maxETU) FROMValue;

}

Bit(l) IDFlag;

If ( IDFlag ) {

Bit(maxEETU) IDValue;

}

Bit(l) BODYFlag;

If ( BODYFlag ) {

BODYElement;

}

}

BODYElement {

Bit (maxETU) TAGName;

While ( Bit(l) ATBFlag ) {

Bit (maxETU) ATBName;

Bit (maxETU) ATBValue; }

If ( Bit(l) TEXT ) {

Bit(8) TEXTBytes[till null]; }

While ( Bit(l) MORE ) {

BODYEIement;

}

ANNEXE 2

message

from="john@location/viewer"

to="host@location/scenario"

type="groupchat"

id="one">

<x xmlns="ietf : urn : ns:jabber:client"

< data > bonjour </data >

</x>

/message>

Codage

Bi ts(2) 1 0 _. MESSAGE;

B ts(3) 0 1 1 _GROUPCHAT;

B t(l) 1 { Bits(etuMAX) FROM; }

Β' t(l) 1 { Bits(etuMAX) TO; }

B t(l) 1 { Bits(etuMAX) ID; }

B t(l) 1 {

Bits(etuMAX) TAGName; /* x */

Bit(l) 1 {

Bits(etuMAX) ATBName; /* xmlns */

Bits(etuMAX) ATBValue; /* urn:ietf:ns:jabber:client /* }

Bit(l) 0 /* End of Attributs */

Bit(l) 0 /* No Enclosed Text */

Bit(l) 1 {

Bits(etuMAX) TAGName; /* data */

Bit(l) 0; /* No attributes */

Bit(l) 1 { Bits(8) TEXT[till null]; } /* Bonjour */ Bit(l) 0; /* No nested élément */

} /* /DATA */

Bit(l) 0; /* No nested élément */

} /* */

Bit(l) 0; /* No nested élément */

} /* /MESSAGE */ Nombre de bits nécessaires

2+3+l+n+l+n+l+n+ 1 +

n+l+n+n+l+ 1 +

1 +

n + 1

1 + (8 * 8) + 1 +

1 +